After doing a number of API (rollout) projects I thought it was interesting to share the different stages op API maturity that I encountered during those projects.
The first is easy, there is nothing. If data needs to be sent it’s via mail. This of course has a whole lot of consequences for security, audit, stability, ….
The second is what I call ad hoc or opportunistic. Teams start to connect different applications. This is often done with (not really stable) file transfers such as SFTP. As teams grow without evolving their maturity this tends to become a “spaghetti” with an overload on”run” or “fix” tasks.
When maturity evolves those ad hoc connections become more centralised and specific tools get implemented (ESB, APIM, …). One tries to evolve to a functional model with RESTand SOAP calls.
Once a central setup has been determined the next 2 phases are dependable on the use case of the API’s. If the API’s are only needed internally, the managed phase is the last step where one tries to get monitoring and security in place. Message systems can be used to enhance reliability. If the API’s are also there for public use one tends to go to an “ecosystem” setup where also IAM, caches and so on will pop up. Note that monetization often is only possible on this stage, unless the client is willing to accept low SLA’s and security.
Note however that all of this depends on the maturity of your backend systems as well. It’s not only the front that needs to be scored.
No responses yet