Locations of Data and Systems

Identify the related systems and data sources from the API Canvas “Key resources” and “Key partners” sections.

Put them in the template according to geographic and network locations.

This helps to understand where the systems are situated and what are the geopolitical requirements: for example, some countries require customer master data or personal data to be stored inside country.

Network latency or volatile geology or political situations may require redundancy in data storatges or network connections. In some cases, due to the nature of the data and/regulations the APIs must only be used inside secure networks or traffic and data must be encrypted.

‍

Response time and latency

What is the maximum amount of time the API consumer can wait for a response to any request? What is the expected response time for API so they can keep their customers using their system?

Estimating response time requirements is a combination of capacity, network locations, and API consumer requirements.

Some API consumers are more sensitive to response times and there is more latency if the systems are far away from each other and there are multiple systems involved.

Also if there is a huge amount of traffic and the requests and responses are big and take lots of processing, the response times are going to be longer.

‍

How to fill in the "Locations of Data and Systems" template?

1. Interview the process owners and/or the owners of the current systems, information architect or solution architects who know the domain and the related systems.

2. Fill in the template names of systems to the correct location in the “map”.

• I.e. if the CRM system is related to the APIs in the API Canvas and it’s located in the local network, write it in the left bottom box.
• If the CRM system is providing APIs, for example for searching customers and creating and updating them, then mark it in the “Provider” box.
• If it is consuming APIs from other systems, mark the names of those APIs or those systems to the “Consumer” box.

3. Put applications that are accessible by partners to the “Partner network” boxes. Partners in this context mean customers, vendors, subcontractors, anyone with an agreement and access, typically via VPN, IP restrictions or specific partner user account but only to certain systems or parts of the network.

4. If some systems are accessible only from a certain country (country-specific organization or actually restricted by location) mark them to “Country-specific network” and also note which country or geopolitical area they can be accessed from e.g. Finland, EU, EEC).

5. Put systems and data that can be accessed from anywhere in the world and in public internet to the “Different locations globally”. It’s important to know if this means that the systems are located in multiple locations, if the same data and services need to be read fast from different locations or if different locations have and can have different systems and data, even data models.

6. If there are multiple systems or if the situation is otherwise very complex, use multiple templates, or better yet, write a short description and possibly a network diagram of the situation

7. Check you have also marked the API consuming applications in their correct places, at least those someone already knows about but also those in the near future. It’s almost always safe to assume there will be users accessing the API from at least public internet and company networks.

‍

‍

‍

‍