We all know the importance of design-time governance in SOA architectures. But how about design-time governance in the new API economy? An economy that’s going to boom. That is already booming while you were sleeping.
People tend to forget about mistakes made in the past and make the same mistakes again during paradigm shifts. New paradigm, same mistakes. Are we all that stupid? Or is it a generational thing (nah, we know better)? Or cultural (let’s first concentrate on happy flows and get the stuff working asap; now let’s put it in production :-)).
The same is happening now. I foresee API spaghetti. And, it’ll get far worse this time. You know why? APIs are for the business. SOA was for techies. Techies tend to at least think a little bit about the longer term behaviours. At least, some of them. The real developers I call them. But business people, responsible for exposing and consuming APIs in order for them to be able to build agile business processes that enable quick wins and sometimes strategic benefit? Will they worry about re-usability? Will they worry about granularity of APIs? Sustainability? I don’t think so.
So, we will still need an ICC (integration competence center) that takes care of guidelines around how to build and use APIs, how to expose them, how to document them and how to make them re-usable and findable. And secure and sustainable. Maybe we shouldn’t call it ICC anymore. But call it “ACC”. The API Competence Center.
What would such an ACC do? Here’s some guidelines:
- Design, document and guide the use of design principles (still a must read: “Principles of Service Design” grandmaster Erl) for development of APIs;
- Help the business make the right, sustainable business process solution decisions;
- Make sure that the right Application Platform as a Service functions are used;
- Educate the organisation on the right development and use of APIs;
- Make sure we indeed are building Microservices and not silos.
Let’s not put this stuff in documents, but in the API Management portal. With managed meta data. So that we can indeed find our APIs. And we can use the information at our fingertips, not buried somewhere in a document.
I’d say: If you’re serious about API’s, let’s get serious about the ACC.