IT architectures are made up of various systems, databases, processes and services. In a contemporary architecture strategy, you may choose an API approach in order to get all these elements communicating or synchronising with one another. It seems a perfect solution in multi-cloud or hybrid cloud infrastructures.
But the approach also comes with challenges. For example, how can you avoid increased complexity when using APIs? What should you do about security? What in-house knowledge do you need? And more…
During this session, we heard from Proximus and CIB, who jointly explained how they fit an API approach in an ecosystem with multiple partners. Then we learned about the Politie Antwerpen’s FOCUS application. Finally, we discovered the role of APIs in the digital transformation of Mutualités Libres - Onafhankelijke Ziekenfondsen.
The presentations and the recording from the event are available for Beltug members (after login).
API ecosystems – all about the right approach
“Proximus is creating an API ecosystem that is open for other parties, based on their telecom knowledge”, was the main message of Bart Van Vlierberghe, Product Manager API Solution at Proximus. He began by observing that internet access has become like electricity: a standardised product. The added value, however, is in the online services and the software. While some telecoms providers have acquired software companies, Proximus instead set up a small team in 2016 to tap into the API economy, and created Enco. Its business model:
(see slide 4).
Proximus built this around their existing WSO2-based API and identity gateway, using other classic building blocks such as Kubernetes, Splunk and Bamboo, and providing an SMS API, a CloudEngine API, a rented numbers API, etc. (see slide 6). Bart explained that this set-up provides a good gateway and security function, but fell short for planning, testing and retirement of APIs (slide 5).
Two to three years on, Bart continued, Proximus had a strong brand, broad sales knowledge and a strong organisation, but faced technical challenges to integrate 3rd party APIs. Among other things, the Belgian market is small and not international, and Proximus is still mostly seen as a telecoms provider, not a software vendor. Proximus decided not to become an API reseller. One important factor in this choice was the legacy software: even in March 2021, the majority of calls still come from legacy software (see slide 8).
Nevertheless, in order to adapt to the multi-cloud environment, Proximus will transform from the WSO2 environment towards a lightweight, custom solution. With multi-clouds, the network is split into different zones, each with its security gateway and API gateway (see slide 9). The custom solution will be home-grown, offering better performance in terms of portal, planning, testing, retirement and monetization (see slide 10).
Jonas Zaman, Project leader at CIB (the Flemish federation of real estate professions) then took over, to give the audience an example of how they used the Proximus ecosystem to create a new service. He started by explaining the difficult role of the property manager:
To enable a solution, every building under the management of a property manager was assigned a unique telephone number. When there is a problem, co-owners and tenants call that unique telephone number, and are greeted by a smart, automated voice that lets them know (if this is the case) that the problem has already been reported and then explains how they can register to be kept informed on the status of their problem. For the property managers, the system offers:
He then shared the architectural set-up with the front-end, the communication gateway at Proximus and the back-end (see slide 14). In this environment, the caller is helped by the APIs in the Proximus system, for e.g., receiving the calls, registering the problem and communicating the solution, for example via text message based on the SMS API. The Proximus APIs are fed with data from the back-end, and communicate back-to-back- and front-end.
User story: FOCUS, a modern police application
Next up was Mark Meeus, Software Architect, at the Antwerp police, who started off explaining that complexity rapidly increases when adding possibilities. To avoid this complexity, the architecture of FOCUS is almost modular. It is a pluggable app platform, where new apps can easily be added, because every app is a stand-alone service.
The request for an easier way to provide information to police officers came in 2014. Mark's team realised early on that the best way forward was to integrate at as high a level as possible in the architecture, because the services the environment needed to provide had very few common characteristics. For example, event management, verification of residence and making arrests all rely on different data. Seen from a high level, the user interaction occurs through a browser and a browser-based application (slide 3). The various plug-ins, or 'applications', for the police agents are vertically isolated to allow them to work independently, and correspond to what he calls the ‘services’ (see slide 4). For the security aspects, they rely on external parties, and authentication is done outside the services. Every developer providing a service is thereby guaranteed that all requests received by their service have already been authenticated (see slide 5).
Mark then explained that the architecture ensures the provision of real-time data, and is based on Web Socket. Police officers also receive push notification via Azure Notification Hub, even when FOCUS is not turned on (just like WhatsApp or Facebook). He also spoke about how the resource delivery, mobile app update and development workflow have largely automated the workflow.
User story: API Management as a foundation for the digital transformation at Mutualités Libres - Onafhankelijke Ziekenfondsen
The third and last part of the session was a dual presentation by Frederik Mulkers, Lead Architect, and Steve Adams, Deputy CIO / Chief Architect of the Mutualités Libres - Onafhankelijke Ziekenfondsen (MLOZ). They gave us an overview of how the use of APIs and microservices is laying the foundations for the delivery of more and more agile services in the future.
At the start of the API boom, MLOZ created a multi-channel API platform (MCA) of:
(see slide 11).
But as more and more services are added, keeping the MCA running correctly proved difficult. MLOZ decided therefore to adopt a microservices approach, defining a ‘microservice’ as 'a small component that lives independently from the rest'. They had implemented it in order to decrease development and testing, but discovered that it also had positive effects on scalability and versioning/retirement. Nevertheless, a big challenge was where to store the various data.
The organisation now combines the MCA (which still has the legacy services) with the different microservices.
Their MCA also has routing or gateway capabilities, and for security reasons is coupled with the ForgeRock stack. Consequently, microservices developers still have to think about security and routing. As with the FOCUS app, they want to move to a situation with centralised security and gateway elements, so that developers no longer need to worry about them.
In order to do so, they have turned to an API management system (which Proximus also mentioned in their presentation). They have analysed several systems and selected their preferred option, based on the possibility to licence per consumption (see slide 14 & 15).
Having chosen a partner, they intend to move towards an open system, in which other health insurance companies and unions can also develop apps or use their apps. Depending on the GDPR considerations, an application can subscribe to a certain model. This model will give the app the possibility to access a specific scope of services. If the application needs critical data, a tighter security policy will be imposed.
Frederik and Steve closed their talk with their target for their high-level architecture: applications accessing services through an API gateway, linked to ForgeRock for security. Monitoring will be done via Splunk and Kibana, a data hub will synchronise the data, with some crucial or sensitive data being stored at the service level. An API portal, part of the API management platform will interact with external developers so they can add services.
Access to more information about this topic and/or to download the paper is easy and fast, but exclusively for Beltug members (just login to get access).
Beltug gathers a lot of information. Here you find the advantages of Beltug membership
The Beltug Team
Click here to login