SOA Software recently published a new whitepaper entitled “SOA and API Convergence: What it Means for IBM Customers” that offers some engaging ideas on the future relationship between SOA and API technology. The whitepaper gives IBM customers some solid architectural ideas founded on the SOA and API strength of the IBM DataPower gateway partnered with SOA Software, but even more importantly on the premise that unification of SOA and API technology is the only sound direction available to the enterprise.
That paper did a good job making its case for a unified SOA and API convergence so I won’t repeat any of those details here. Instead, I wanted to take a look at the other side of the coin. What if we made the case for anything other than SOA and API unification in the enterprise? What if you build and evolve your API management solution independently of your SOA governance solution?
The first problem you will run into with an independent API management solution is access to backend enterprise data. Out of the gate you will realize some quick wins with your API program. You will publish some APIs for mobile consumption and start building a developer community. But soon your APIs will become more and more complex, requiring deeper and deeper access to enterprise data. That data won’t be immediately available to your API developers, and each new API project will spawn a host of integration questions like “who owns that backend data that I need?”, “how is it secured and exposed?”, and “how can I access it?”. Pretty soon you will realize that without an API program integrated with the SOA lifecycle of your backend data, your API developers will lack the backend support they need, hitting brick walls at every turn trying to complete their API projects.
Another problem you will run into is a breakdown of your runtime operational model. An independent API management solution will likely use a runtime API gateway technology different from the gateway technology that you already use for internal and trading partner uses, for example IBM DataPower. Having different gateway technologies means having to design and manage two or more distinct runtime platforms. Everything from gateway provisioning in the datacenter to service deployment models, staff training and the proper use of each gateway’s feature set will need to be considered and executed separately between your different platforms. Your runtime gateway technology is extremely important to the day to day success of your business. Having to manage and run two different gateway technologies will overburden your architects and operations staff, and lead to costly and inconsistent operational models.
A final problem relates to the need for a unified service lifecycle. If you think about it, every IT resource in the enterprise follows a lifecycle whose final goal is consumption by someone, somewhere. API is becoming a prime, but not the only, channel for consumption of these resources. Other channels include trading partners, internal applications, field applications, and end user mobile apps. If your APIs are not part of the same unified lifecycle as your backend resources as well as all your other channels, you are effectively forced to manage multiple overlapping lifecycles, or worse integrate among them. In other words, the exposure of new backend data needs to be a unified event for all channels, and mustn’t require the spawning of additional downstream lifecycles so that that data may be consumed by multiple channels.
So with these three key challenge areas we throw down the gauntlet. How do you move forward with your API programs and mobile initiatives without falling into the traps of lack of enterprise integration, disparate runtime gateways, and disjoint service lifecycles? By preparing for convergence. Ensure your SOA and API programs are unified, and that you are preparing for a future where the strengths of SOA and API technology come together for the benefit of a unified enterprise.