Why move to an open IS and how?

Written by Wilfried Kirschenmann, on 21 February 2019

Bousculés par la révolution digitale ou poussées par la réglementation, les entreprises sont contraintes à se 

Pushed by the digital revolution or driven by regulations, companies are forced to transform and embark on a more innovative strategy for more efficient products and services that are quickly available.

Companies are entering the era of APIs, an era whose foundations date back to the 1970s with "Message Oriented Middleware," passing through object-oriented programming, Service Oriented Architecture (SOA), and especially with the emergence of the first web browsers in the late 1980s. These developments have led to a convergence of data formats and internal interfaces within each application and inter-application, with HTTP interfaces and JSON data format ensuring the reliability, isolation, and interoperability required by the IT system and its applications.

Since then, each company has identified the essential drivers for its digital transformation: PSD2, new digital media, mobile-only cross-selling. To address these new challenges, companies must undergo a cultural, human, and technological change. These developments have led to a convergence of data formats and internal interfaces within each application and inter-application, with HTTP interfaces and JSON data format ensuring the reliability, isolation, and interoperability required by the IT system and its applications.

If APIs constitute one of the major pillars of system openness, the question remains: how and with what governance?

Why APIs? At your company and others

Following interviews conducted prior to the CIO Circle evening and through interventions with our clients in the midst of digital transformation, we have classified the various drivers into 4 categories while measuring their impact level on information system openness.


APIs and the new challenges to overcome

Implementing an API strategy involves several initiatives and presents new challenges for companies. To address this set of challenges and ensure good technical governance, there are several API management solutions (API Managers or APIM), both open source and proprietary.

These APIM solutions are widely used by present CIOs, all of whom claim explicit management of their APIs and a catalog that is constantly growing. However, while the "API reflex" has become commonplace in new projects, systematic API adoption is slow within legacy systems.


These solutions offer several services:


Depending on usage and openness level, we can categorize three major usage families of APIM:


A solution dedicated to the developer and operational community A solution promoting collaboration between business API managers and developers A solution more open to partners and the general public

These families also reveal the maturity level of companies in adopting an API culture: initially a technical platform for sharing, then a place for internal service exchange, and finally an asset that can be offered to other companies.

The majority of present clients (mostly from the banking sector) are currently at the "marketplace" stage and find it difficult to transition to the store stage, even though they observe these developments in other sectors.

The future of APIs

The European Union is funding projects whose results anticipate the next stage of maturity for API-enabled information systems. For example, the Open Cloud Computing Interface working group has been focusing on service quality and Service Level Agreements (SLAs) since 2010.

Services are now built as compositions of lower-level services. This composition is now explicit, and it's a developer who consults the API catalogs mentioned earlier.

This composition will rely on meta-services responsible for selecting and automatically implementing the appropriate service based on the required service nature (e.g., key-value storage) and the required performance or SLA level. For example, one could request to print on the nearest printer capable of printing a document within a given time frame with a resolution of 1000 dpi. The associated meta-service will then filter available printers capable of printing with this resolution and having the required print speed. It will then direct the call to the geographically closest one.

Such services are currently available, especially in telecom and IaaS services, and are expected to spread to higher-level application layers, offering enticing prospects for overall SI service quality. Given the unanimously shared observation that APIs reflect the responsibilities of the various entities of an organization participating in a digital process, a debate has arisen on the following question: "Do APIs also reveal an organization's frictions?"

Opinions are divided. Some believe yes, since APIs formalize service relationships between entities and push for clarification, which brings latent issues to light. Others, on the contrary, believe that these frictions would have emerged anyway. However, all agree that enterprise architects (or business) and IT architects must actively cooperate to offer relevant and coherent API ecosystems. Each company proposes its own organizational models, depending on its history. The last question addressed: "Are APIs accelerators of innovation?" All the present CIOs agree on the possibility of accelerating innovation through rapid and simplified application creation by aggregating API-enabled services in a "Lego" approach. While they already observe the effects internally, they are more reserved about the generalization of such an approach throughout the banking industry. While BlackRock or Goldman Sachs have already shown the way, it seems that in France, this concept of white label or even coopetition is not desired by decision-makers. Right or wrong? Only time will tell.