Having scoped your data access and interoperability needs, and understood capabilities in the market, the Design phase is when you capture these needs in a clear statement of requirements. This will ensure that the service integrates with any current or future systems that may be required, and that the borough is able to access and control its data in the required way.
This section introduces LOTI's recently published Tender Requirement for Data Access and APIs, as well as providing some ancillary guidance for how to bake it into your design process.
Digital and IT Teams
IT teams should be responsible for defining the API and data access requirements, including all associated standards and documentation.
Service Teams
Service teams should be responsible for assisting the assessment of what integration and data access requirements the new system needs for their given service area: as well as supporting on an assessment of the weighting of these factors during evaluation.
Procurement Teams
If the procurement is being executed by a procurement team, they should ensure that the API and data access requirements are properly baked into the contracting approach and documentation, especially relating to continuous improvement and roadmap requirements.
<aside> <img src="https://s3-us-west-2.amazonaws.com/secure.notion-static.com/795edacb-2e6d-4fcd-8083-56c6359d8ef0/Ellipse_2_(1).svg" alt="https://s3-us-west-2.amazonaws.com/secure.notion-static.com/795edacb-2e6d-4fcd-8083-56c6359d8ef0/Ellipse_2_(1).svg" width="40px" /> Whilst harnessing this guidance, there are two important points relevant to focusing the scope of a borough's data / API requirements:
◾️ Not all the data hosted on the IT systems local government procure is data owned by local governments. This is because suppliers may host their own proprietary data sources, or may even license data from another provider in order to provide you with a service, but which they are not licensed to hand over to local authorities as raw data.
◾️ Not all APIs maintained by a software supplier are APIs of relevance to local authorities. This is because one must distinguish between APIs that suppliers host for their own systems to speak with each other internally, and APIs which speak with external systems, such as those developed by an innovative startup. Increasingly many software suppliers utilise a 'microservice architecture', where instead of building their product as one monolithic software they have built many modular components that speak with each other using APIs. Therefore, a blanket tender requirement to access every API your supplier's system features, including internal ones, will demand more than you need and may actually risk the integrity of the internal system. Having more APIs isn't always that helpful: APIs are valuable because they allow people to access data. Hence, make sure you request that APIs be available to access all user data, rather than to blanked request that all supplier APIs be made accessible to external users.
</aside>
.svg){kind=link}