Six ways to run SOA as an internal cloud business
We probably could argue for another 10 years about the ROI of SOA. Is there ROI? If so, why isn't there more of it? How do we measure it? How should SOA be sold to the business? Why won't the business provide more funding?
Or, we could move to a model proposed by Dion Hinchliffe, who proposes that SOA-based services be deployed the same way cloud businesses deploy their open APIs. In other words, managing an SOA effort as an internal business, providing services to the rest of the enterprise, with profits or losses, a la cloud.
As Dion points out, cloud providers face the rigors of the marketplace and have to prove their value every day. So why not model internal service orientation efforts after the experiences of those external providers? As Dion observes:
"The most obvious successes with service-oriented approaches aren’t classical organizations at all. They are Web companies that offer APIs out of a basic need: To build a network of partnerships quickly and cheaply as well as tap into external innovation and inexpensive third-party investment."
This makes sense, as companies are becoming both consumers and providers of services. This providing and consuming also occurs internally as well as outside of the corporate boundaries. Dion proposes six ways to run an SOA effort along the same lines as a cloud business that has to meet market demands. Is the internal market any different?
Make services easy to use. These should be lightweight, Web-based services, versus the more complex technologies that have been associated with traditional SOA.
Itemize costs and charge as an outside provider would.
Manage internal customer accounts. "Open APIs are all strongly keyed to who is using them and is used for providing customer service, tracking usage, and creating accountability," Dion says.
Provide for self-service. Public APIs can be used "without a lengthy company-to-company negotiation and partnership process" -- it's all automated and online to accommodate as many customers as possible.
Build a developer community. Today's APIs nurture developers that build application that consume their services. This is the best way for SOA take off as well.
Allow for flexible use of the API by other business units. Nothing kills an SOA faster than if business units put the kibosh on the way their data is being deployed elsewhere. Dion says "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."
There's another dynamic that Dion doesn't mention, but worth mentioning. It's not too far-fetched to imagine that IT departments deploying SOA-based services may end up competing with outside service providers. But IT departments have a supreme advantage that the outside providers will never have with their customers. That is, IT executives are often in high-level partnership roles with the business leaders. There's no reason why internal services can't be well-focused and well-targeted to pressing business problems or opportunities, the kind only an insider would understand. (An insider would have a better grasp of the politics behind an implementation as well.) IT and SOA proponents need to really leverage and continually demonstrate this advantage to the business. Know the business.