I recently gave a presentation (in German) at the Beschaffungskonferenz. This is a conference for the public sector to exchange round procurement of IT. There were several tracks some focusing more on legal aspects, different procurement processes and agile development while I presented in the tech track. In my talk I presented some of the more established new development paradigms of the past years. But the key message was that APIs need to become a key aspect of how IT projects are planned for the public sector. Specifically I named  transport.opendata.ch as a shining example of how providing existing data via a public API can lead to an entirely new economy of use cases on top of it. The idea is really: “Built it and they will come”.

Update : Another good example of a well documented API in the public sector is  api3.geo.admin.ch which we have used for various projects here at Liip in the past already.

Update 2 : An article which provides an additional perspective:  API First at data.gov.uk

APIs enable federalism

One key principle of Switzerland is that at all levels local authorities enjoy a lot of autonomy from higher level more central authority. However if we want to enable eGovernment or even just making internal processes more efficient, we need IT systems to communicate with each other. With APIs, villages, municipalities, cantons etc can provide functionality in a way that the data can be exchanged (f.e. data needed to be exchanged when someone moves within Switzerland).

Now of course ideally when possible and sensible they would share the code. Or they will at least agree on a common API. But even if not, wrappers could be created that translate between the APIs. In this sense if a canton wants to improve the efficiency they can launch an initiative to define a recommended API without forcing anyone to adopt a specific application. They can also build such a wrapper API to unify existing APIs.

APIs enable innovation

APIs enable the separation of business logic from the user interface. This means that it also becomes possible to remix logic into entirely new use cases. It also becomes possible to build dedicated UIs for specific use cases more easily and with smaller budgets. For example while companies and households might need similar functionality, companies might need a different UI that is focused on efficiency, while household users might need a UI that is more optimized for people that only use the UI once every few years.

APIs enable cheaper procurement with less risk

Right now public sector projects have a tendency to become quite monolithic. Often there are challenges in integration with different backend IT systems while also providing frontends. The larger the project, the smaller the amount of companies able to provide the requirements. Logically this means higher prices and can also lead to lower quality since rather than specialist companies, monolithic companies require generalists. Additionally when the backend integration fails, often the frontend is so tightly coupled that it also needs to be thrown away. Conversely if the frontend fails, the backend also needs to be thrown away. The same applies if later on the backend or frontend needs to be adjusted.

What are the challenges with APIs

Obviously there are challenges. For example if separate companies implement the backend and frontend, there is the question of how do these companies collaborate efficiently? The good news is that there are many well established standards for this. The important thing is that the public sector needs to become aware of these, make them part of the RFP and measure the compliance as part of the the project review.

API documentation

Documentation is key for an API. However where traditional documentation consists of pages of PDFs, API documentation can and should be generated for the most part direct from the code. This ensures that the documentation is always up to date with minimal efforts. It is also custom for API documentation to be interactive to enable users to test our API calls via embedded forms. Standards like Swagger and RAML can help with implementing API documentation.

api-docs

API protocol

It is important to base the protocol on a high level established standard. Today for server-to-server communication REST APIs based on XML are the standard, while REST via JSON is becoming increasingly popular especially for server-to-browser communication. But REST is still fairly low level, so it is worth considering standards such as HAL or JSON-API. For deeply nested content structures, GraphQL is becoming more and more interesting, but it is still to early to call the standard established. One of the qualities of established standards is that frameworks will have tooling that enable quick integration of such APIs.

API authentication

Here again it is important to leverage established standards. OAuth is the most popular option for user based authentication, while JSON Web Tokens are more or less the go to option when implementing server-to-client authentication. For single sign on SAML should be considered as the go to option.

API deployment

The topic of deployment is probably what is the most cumbersome today. In many cases deployment is handled by separate IT departments that require standardization of a small subset of often proprietary technologies. Deployments are often done manually and are therefore expensive and error-prone, which in turn means that deployments are done seldom. It is critical that for API projects deployments can be done without any delay otherwise the roll-out of client apps that each will come with their own release cycle will become a nightmare.

The good news is that with PaaS, IaaS and SaaS providers along with tooling for local development are making it easier and easier to automate deployment. IT departments can then focus their time on dealing with maintenance and security topics rather than pasting the same set of commands over and over from a deployment documentation. At the same time bugs can be resolved quickly and new features can be added within the release cycle of client applications. What should be noted here as well is that automated deployment goes hand in hand with automated testing.

Conclusion

APIs hold huge potential for the public sector, especially in a country like Switzerland that values federalism. They can enable lower costs, more innovation with small risks. However it is important to ensure that standards are leveraged to ease the data exchange between the different IT systems. Also best practices for automated testing and deployment need to be taken into account to prevent organizational issues with release scheduling that arise using traditional manual deployment strategies.

To realize this opportunity the public sector needs to start making APIs a required component the deliverables of projects including the use of open and established standards. The resulting APIs should also be collected in a public directory to enable release. In this sense a similar strategy for APIs is needed as for the  open government data is needed.

We are looking forward to to continuing the dialog around this topic with the public sector in Switzerland!