One of the most surprising moments of my talk at QCon San Francisco last week was when I asked the audience who is ‘doing’ service oriented architecture inside their Enterprise.
Everyone raised their hand, or nearly everyone. There was no hesitation. The question was clear and the response was swift. Attendees didn’t look around to see if they were the only one riding this ‘dead’ trend. Instinct took over and hands shot up all around. The same question last year at the same conference yielded a positive response from less than half the respondents. Sure, this experiment is anecdotal with a mere slice of the relevant respondents and absolutely no control group, but I think it validates Gartner’s plateau of productivity for services. Productive yes, but maximally productive – no. For internal services to be realized more fully, SOA needs API management.
API Sharing – What’s That?
I talked to attendee after attendee, all with a similar story. The story was how their Enterprise decomposed their assets into programmable services using SOA and hosted their services on vendor platforms (IBM,Tibco, Microsoft) and/or open source. An informal survey yielded most developers using Spring, Jersey or Ruby on Rails as popular ways to host internal services. While services were plentiful, there was simply no single pane of glass, or single source of the truth for internal developers to go to discover and make use of disparate services.
APIs, which in one sense are the closest thing to any developer’s heart, were also the most elusive. For the day to day practitioner, the developer, there is still a significant mental gap between SOAP web services and “APIs.” Many attendees hadn’t heard of solutions for internal SOA governance of the registry/repository ilk and the distance between SOAP and API management seems like light-years. Public and open API programs didn’t seem to “apply” to the quandary of the day to day developer.
Even when valuable functionality is implemented, I heard horror stories of services being implemented twice or three times over in different parts of the Enterprise simply because developers didn’t know that this functionality already existed and had no good way to reuse the components. A service hiding behind a WSDL on Microsoft .NET with zero discoverability is like an invisibility cloak on your SOA. The functionality is there, but almost impossible to use unless you are the original developer or an asetic monk that regularly engages in <wsdl:definitions> tag torture.
It’s time for an API Management invasion. API management has optimized the process for developer on-boarding and fast time to market for services. Developer portals shine in solving this problem. Why? Because they’ve been battle-tested on the open Internet, with hundreds or thousands of “zero-trust” developers. The model is there, it just needs a way to invade the Enterprise. If you are like any of the attendees I talked to last week and already have a SOA that isn’t delivering value, consider how you might apply best practices such as an internal developer portal, fast on-boarding processes, interactive documentation, analytics and other best practices from the open API movement to evangelize and share your components from within. Invade your SOA with API Management.