Tips for the buyer and owner: APIs of the built environment

A building is an enormous source of data and the built environment encloses a lot of integrations and programming interfaces, APIs. Those little digitized sockets provide data delivery for a complex process and service environment but can also enable emergence of new innovations. API is a gatekeeper to the source of information where besides the API, data can also be a product. 

‍

A good API is tested properly, documented and productized. However, even being an extraordinary API is not enough. Because API is a product transmitting other products, it should have an owner, a budget and a product strategy as well as a documented service and process environment. So, when tendering systems and solutions for any but in this case built environment, one must make sure that at least the following questions are answered. The answers may be anything, but the point is to take a stand on the matter and identify risks. 

‍

1. Does the API have an owner? API should be developed and maintained as any other software product as environmental requirements change. E.g. information security, data protection, authentication and authorization management are key issues among others. 
2. To whom the API is made for? Usually the software developers face the API related issues and opportunities first. Good experiences are shared in developer communities but so are the bad experiences as well. Developers want to use good, well-behaving and trustworthy APIs. They spare time and money and open new opportunities.
3. To whom are the API related services targeted for? How to communicate the topic and by whom? API encloses opportunities that API product owner can see as limited but combined with other services only imagination is the limit. So, ensuring continuity is important when it comes to long-term service and cooperation.
4. Who or which system or organization can use the API and the data provided by the API? With what kind of limitations? What kind of opportunities does the API create for the network that uses it? Is the use of the API and information product priced and how is the competence of the sellers and buyers of the service ensured? How will the price develop in the future? Who is responsible for the costs?
5. Who maintains the API? What is the process by which updates are made and how do they affect the systems using the API? Who is responsible for which stage of the production chain? Are there gray areas and what should be done about them? What is the target service level and is there a need for a partnership strategy?

‍

As a buyer, beware of the pitfall, because even if the API is for sale, it may not exist yet. This can especially come across in the construction and real estate industry that is digitizing quickly based on demand. On the other hand, as a seller beware of situations where your customer acquires a system whose API has not yet been properly tested. This creates extra work for your organization. The existence of the API, the possibilities and features it offers should be understood at the latest in the contract phase of the procurement, so as not to be surprised - whether you are in the role of a seller or a buyer.