Dion Hinchcliffe provides a detailed look at how we might run service orientated initiatives to maximize value of IT assets. He contrasts the state of Enterprise SOA initiatives to open API’s to public services available on the web; especially startups; in terms of adoption, time to market and overall return on investment and how to adopt some of that knowledge in Enterprise SOA. He says,
One of the more striking differences between IT and the online world these days is the contrast between traditional enterprise service-oriented architecture and its equivalent on the Web, open APIs.
He laments at the state of SOA initiatives in the enterprise. According to him, despite the goals of both initiatives are the same as they both “encourage interoperability between different business systems and enable opportunities that would otherwise be too difficult, expensive, or time-consuming to capture”, the SOA initiatives still do not demonstrate the vigor of the services available in the web.
SOA does not have the same business urgency and lacks critical focus in this regard in most organizations. […] Now, it’s also true that SOA initiatives in large companies generally don’t publicly announce their internal developments, so it’s much harder to get a sense of what is being created and used in most organizations. However it’s fairly clear that there are some significant differences and outcomes between these two approaches for open services, even as they ostensibly have the same goals on the face of it: To encourage interoperability between different business systems and enable opportunities that would otherwise be too difficult, expensive, or time-consuming to capture.
He attributes this contrast in these two faces of service enablement to the difficulty in measuring ROI directly in enterprises as SOA initiatives are traditionally internal to the company. On the contrary, public web API’s affording strategic agility to startups via interoperability and collaboration with 3rd parties and provide value to consumers in facilitating serendipitous reuse.
Based on his conversations with Burton Group’s Anne Manes and Oren Michels, CEO of Mashery.com, he observed that
IT groups should spend less time focusing on technology and infrastructure, and instead focus on delivering systems (aka services) that deliver measurable business value.
Taking advantage of the reach of the partners who incorporate your Web services allows you to focus on making those services better - in other words, focusing on what differentiates you.
He asserts that “traditional enterprise SOA has a lot to learn from the open API world” and provides guidance on how to run an SOA like a startup. Dion highlights some key considerations that drive value and he recommends enterprises borrow these ideas from the service API ‘s available in the web.
- Ease of Use. Making services consumable from any platform, tool, or programming language
- Reporting/Billing. Making sure customers understand what it costs, are encouraged to consume resources wisely, and can measure and see what they’re using ensures a wise and appropriate use of services with a positive feedback loop.
- Account Management. Open APIs are all strongly keyed to who is using them and is used for providing customer service, tracking usage, and creating accountability [and] essential for quality of service levels for difference classes of customers and other more sophisticated measures.
- Self-Service. One of the key aspects of public APIs is that they can be used without a lengthy company-to-company negotiation and partnership process.
- Developer Community. APIs depend upon providing an eminently attractive and usable option for developers to adopt. If initial proof-of-concepts work out, an API then becomes a business relationship.
- Fair license. An ideal license is one that gives permission for the consumers of API services to re-use its capabilities in running their business will provide the legal ability to use the API in as flexible a manner as possible.
Dion offers an interesting perspective on how SOA initiatives can be reprioritized to function similar to service API’s on the web; with respect to how they are developed, marketed and collaborated, such that it provides opportunities for partner outreach as well as leverage the emerging cloud architectures to maximize business value.