[RECAP] API Community Belgium – The API Management Journey of Fednot

A WHOLE NEW EXPERIENCE FOR CITIZENS

Before a company is registered online officially, citizens have to pass through several steps. When a citizen signs in to the “Start My Business” web application using their eID or ItsMe, they can create a “Constitution Request‘ ‘ and assign a notary. During the process, the citizen is able to collaborate with the notary in order to fill in all the company details.​ The act can then be reviewed during an online video call. When finished, the act can be signed – you can guess it – completely digitally again. Afterwards, the notary does the necessary registrations, the digital archiving and the publications and registrations in the KBO register.

When the act is registered and the company is created, there is a post-act process where information is given back to the company owner (cfr. company number). Resulting in an end- to-end digital journey and a whole new experience both for citizens and notaries.

This way, Fednot aims to serve as a bridge to connect citizens and notaries. With ‘Start My Business’, Fednot offers a complete end-to-end process to entrepreneurs and notaries with a citizen platform and a notary platform that are interconnected, bringing notaries and citizens closer together.

However, since this platform is heavily integrated with other platforms, both within and outside Fednot, it came with various challenging API issues.

Bridging the gap between citizens and notaries also brought various interesting challenges from an API Management point of view. Serving citizens did not only require a new infrastructure for example, but also policies that were exclusively designed for notaries needed a revision as citizens haven’t been using these systems directly in the past.

Some of the main IT related challenges:

• Infrastructure: as security policies were only made for notaries originally, they needed to be reassessed in light of the citizens. But this was not the only challenge, since not only Belgian, but also European citizens needed to be taken into consideration.

• Identity Coupling: European citizens could be national or international citizens. How to get these identities linked together, came with complex security considerations.
• Service variants: at Fednot, development teams work both on front- and back-end projects. This led to many APIs closely coupled to the front-end. As a result, when a new type of consumer is added, a new API needs to be created in order to accommodate them. As a solution, Fednot launched one particular API that could be re-used for all different kinds of consumers.
• Hybrid Applications: For all of those potential citizens facing those applications, Fednot was concerned about the scaling ability of the on-premise platform. As a solution, they opted for the Google Cloud Platform, launching Fednot into a hybrid scenario. This shift to the cloud meant a reassessment of the existing security policies, both internally and externally, resulting in a brand new policy for cloud applications.
• Integration: Many different systems come with many integrations. As everything was standardised, Fednot was able to plug into functionalities and services very easily. They even expanded the functionality of the Notary API to include a new way to search for notaries. This shows that by building an ecosystem, Fednot is able to continue adding value to existing services.
• Sprint Iterations: the use of an ‘API first strategy’ may have given the impression to the developers that this was a waterfall process. However, it was of high importance that the whole process fitted within the scrum methodology used by the development teams.​
• Compatibility: Fednot uses many different tools and technologies, with various capabilities. When creating APIs, this needed to be taken into account. By adding rules to the contract design standards, Fednot was able to work around the limitations of the used technologies.

‘Start my Business’ doesn’t stop here! The goal is to make it an ecosystem with other partners involved. This means that APIs will come into the picture again. As Fednot processes lots of private data, security policies need to be reassessed constantly. Also the hybrid infrastructure comes with future challenges in terms of how to deal with it.

The Fednot team expanded heavily during the last couple of years: in 2016 the team counted 5 members, today 16 (gateway developers, java developers, analysts, architects, testers…). Which came with a big snowball effect: the demand of the business was very high, so the workload of the team grew tremendously and the snowball got bigger and bigger. A re-organisation of their way of working was inevitable.

To stop the snowball from rolling and growing, Fednot decided to offload some of their work to other development teams and business clusters.

First, they handed over everything related to the API contract design. By launching the API Connect Developer Portals, all developers within Fednot were enriched with self-service, autonomy and a more open view on the API catalog, making this shift possible. However, development, quality reviews and governance in terms of API design still stayed within the integration team.

You might think: great, now the integration team can finally relax!

…Well, this wasn’t the case as other development teams needed to work harder now in this scenario. When offloading work, this has an impact on all business clusters as they need time to get up to speed. On the contrary, offloading API design brings teams flexibility as they don’t depend on the integration team in terms of API design and efficiency. However, this was still an extra effort for the development teams as they lacked knowledge of API Design. Through intensive hands-on coaching, Fednot brought all development teams up to speed very fast.

When confronted with these challenges, Fednot came to the realisation that API design should be centralised in the organisation. The Center of Excellence was born! The main goal of the center is to support other (development) teams, give advice to everybody involved and provide all stakeholders with the necessary documentation.

Immediately, a new challenge arose. When exposing APIs to partners, API Design standards are indispensable. This is why Fednot still has a review process to check if the guidelines and standards are followed.

Early on in the process, Fednot realised that they had to reassess a very important question: who actually is our customer? The business, or the development teams?

A shift in mindset had to be made: not the business, but the development team are now the main customer. Because when they are no longer able to meet the business goals, the development teams will be the first ones to be heavily affected as they were given a lot of extra work in designing the contract. To make their job as comfortable as possible, an ecosystem of tools was introduced. A few examples:

Documentation – Confluence

A lot of the present information was not well structured nor explained. Therefore, new, easier to understand and less technical documentation was provided for the development teams.

Stoplight Spectral

Stoplight Central is a linting tool for open API Contracts. When somebody breaks the API Design rules, this will be pointed out. Another huge advantage was the possibility to create devined custom rules for Fednot. By offering a linting tool to developers, they are able to immediately see if they made mistakes, contradicted rules or misinterpreted standards, cutting down on their effort to comply with the standards.

Graylog

Graylog is a centralised logging tool, and they wanted to plug into this. It is requested from developers to get insight into what’s happening on the API gateway level, insights that can be provided by logging into graylog. Part of that is enforcing global transaction ideas, to see how messages are travelling through systems.