THE FUTURE OF API MANAGEMENT... 4.0

Gravitee Edge has started yesterday and we got notable takeaways out of these thoughtful sessions. It converges actually fairly well with our previous publications on integration platforms and API governance.

Rory Blundell , Gravitee's CEO, has exposed in an inspired opening keynote entitled "The future of API Management" a comprehensive and consistent vision of the evolution of his platform, which now relies on 4 pillars:

- Full lifecycle governance, as a core legacy for previous generations of API Management,

- Event-Native, where Kafka, Solace or RabbitMQ logos are clearly visible as enablers,

- IAM, which highlights the prominence of security in the world of APIs,

- Federation, an inevitable topic actually indissociable from the notion of governance.

Clearly API Management is becoming more. You may call it API Management 4.0 or Unified Middleware, but in a nutshell it really looks like a way to platform real-time integration.

In this race of building the most complete environment by connecting siblings domains such as EDA or IAM, Gravitee begins to overlap (and compete) with players like Boomi, Workato or Snaplogic.

Right now, an API Manager and an iPaaS still keep their specific flavours (and their respective Gartner quadrants), but we can see borders falling down here and there - Boomi's recent acquisition of APIIDA, micro-integrations announced by Solace, are so many clues dropped on the offer side to prove it, if necessary.

On the demand side, we currently observe integration RFP run by our clients where these players now face each other.

On both sides, they still supply different value propositions by now, where the definition of governance varies in significant proportions.

With often times decades of track record on integration, iPaaS players consider governance as a method for integration and an operating model, whereas governance in Gravitee's definition is more about Enterprise Architecture and the capability to master the proliferation of digital assets like Data, APIs and Events.

Nobody is right or wrong. These two definitions complete each other. We need ways to manage these assets. But we also need ways to understand who the governance tools are designed for. And for which part of the process, be it upstream, in the discovery phase (when architectures are designed), or downstream (to measure the KPIs and performances of an API Fabric).

We have seen previously that developers cannot be the single population of an API ecosystem. The practice of API Management has widened to a point that a multitude of IT professionals needs to embrace governance. And among them, architects, with their own toolset.

This is something the keynote has not given many details about: who is API Governance designed for? Which tools allow it? Which processes will these tools secure and accelerate? How can we build architects and stakeholders views next to the ones of the developers?

And eventually, which operating model can increase the maturity and the structure of an API Management practice?

A good source of inspiration would be for the API management platform to expose its own set of APIs so that we can build views into custom applications.

An easy-to-custom Enterprise Architecture repository such as Ardoq would be a good option to build a custom metamodel and/or consume these APIs. It could also be an interesting use case for composable application frameworks such as Entando Inc. 's.

Therefore, we could consider that the race to partnerships or market consolidation are far from being over on that matter, and that we can expect in a next future newer generations of API Management beyond this current 4.0.

Fran?ois Rivard is the CEO and founder of Astrakhan, a consulting firm expert in architecture and governance of innovation and new technologies