From Web Services to API Management
Contributed by Claus Jensen, @ClausTorpJensen - IBM Senior Technical Staff Member and Chief Architect SOA-BPM-EA Integration
Chances are that you have heard people say things like "SOA is yesterdays news, API's are the future" or "API management is completely different from SOA and SOA will bog you down." From my perspective this is a classical case of myth making in the wake of a new cool trend in the industry. Rarely is a new concept so disruptive that it does not build on the principles and technologies that came before it. With that in mind, let us consider some of the myths around service oriented architecture (SOA) and API management:
Myth: "API management is completely different from SOA, and SOA will bog you down". At a technical level there are more similarities than differences. In fact at the foundation of most good API''s is a well designed service, after all one of the most important parts of an API is its interface and the associated business contract. I assert that all API's are services, but not all API's are good services. Also not all services make good API's
Myth: "SOAP is dead, API's are always REST". While it is true that most modern API's are based on REST/JSON rather than SOAP, this does not mean that there is no use for the formalism of SOAP, merely that such formalism is not necessary for human based consumption of API's and services. In machine to machine communication, or simply when using formalized composition tools, there will still be plenty of uses for SOAP. Choose the right binding for the purpose, there are good reasons why the industry has invented more than one option.
Myth: "API management is SOA governance re-branded". No, not really. API's have product nature, hence need to be managed as products. SOA governance is less concerned with the productization of assets than it is of determining and governing the process of creating a good portfolio of reusable assets in the first place. In that fashion, API management and classical SOA governance are highly synergistic.
Myth: "No governance is needed with API management, this allows companies to innovate faster". Well, it may allow you to create things faster, but it also makes you lose control a lot faster Good luck with no governance...the API's that make up your company's external persona are an important part of your product portfolio and should be managed as that. That said, governance should be lighter for API Management than typically used for the lifecycle of a backend software service.
Myth: "API's are not versioned". That is like saying that you don't need to change a baby's diaper. Obviously, disruptive changes do happen and when they do we have to handle them. Claiming that versioning is not needed merely means letting the consumer of an API figure out the versioning themselves. With that said, as API's in many ways are business products, we should reduce version churn by only coining a new official version when in fact an update is not backwards compatible. So, versioning is still needed, but we must version wisely!
Bottom line, I assert that API management is not a replacement for SOA, rather it is a natural extension of SOA. API management appropriately refocuses on the business aspects of human and software interactions - while this was always part and parcel of the idea behind SOA, the business angle in practice often got lost in technology. The advent of API's allows us to separate the business concerns of making an API a product from the IT concerns of providing the service that implements the API. The journey from IT centric web services to business centric API management is not only appropriate, it is necessary for Enterprise's that build Systems of Interaction spanning an ecosystem that go way beyond their own enterprise walls. Good API management solutions provide not only the ability to define an API, but more importantly the ability to project that API into an ecosystem that the Enterprise cannot effectively reach through its own end user solutions - the focus for API management is on the developer experience and the business model, rather than on the architect and the portfolio of reusable assets.
For more on IBM's view on SOA, please access www.ibm.com/soa or follow @ClausTorpJensen and @SmartSOA on Twitter.