It’s time (perhaps even long overdue!) to tackle the thorny topic of Service Oriented Architecture. I’ve been preparing an executive presentation on this subject, drawing on one of our multi-company research projects, so it’s fresh in my mind.
The research was focused on business implications of SOA, as this was a perspective and context that the research team found was missing from many of the early forays into this space. Certainly, there are many worthwhile experimental and pilot projects going on in the name of SOA. These are mostly useful learning activities, but unfortunately, the way many of them are framed, they may well be missing the most important aspects of SOA, and the dramatic positive impact SOA can have on IT organizations and the businesses they serve.
The biggest mistake begins when SOA is perceived to be a technical issue, and is approached as a largely internal (to the IT organization) matter. Buried in the bowels of IT, most SOA initiatives are likely to miss the point, and fail to achieve their full impact – or, at least, take far too long for that impact to be realized.
Let me begin with the major business implications our research identified.
Over the next few posts I will take each of these points in turn and expand upon them.
1. A Market-Driven Ecosystem is Evolving
I’d like to illustrate this point with a quote by Eric S. Raymond from his 1999 landmark paper, The Magic Cauldron:
“…software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry.”
Disruptive forces are rapidly impacting the traditional business model of software vendors. At the same time, thanks to the Open Source movement and changing perspectives of what is “proprietary,” companies are re-thinking how they go about automating business processes. Of course, the reality has always been that companies never actually want to purchase software – they want the capabilities that have traditionally been provided through purchased software. If they can get those capabilities faster, at lower cost, with greater efficiency and flexibility, they will do so – at least, once the fear of shifting to a new business process design and automation paradigm has abated.
The “magic” behind SOA lies in the underlying standards and protocols that have grown out of the Internet – standards such as XML, ebXML, SOAP, WDXL, SAML, WS-Security and BPEL. In addition to these standards, methods such as Object Oriented Programming, with its concepts of loose coupling, autonomy, abstraction and composability, along with the principles of “service orientation” at long last bring the promise of reuse and “plug and play” modularity to reality. Together, these standards and methods provide for loosely coupled, coarse-grained, business-centric, reusable services. Such services no longer have to be “hand programmed,” or even “assembled” from an in-house library of building blocks. Now, and increasingly over time, they can be procured on the open market – often for free!
Think about the implications for an IT organization, circa 2017 (this blog’s title) when there is a thriving ecosystem of business services – from tiny micro widgets for activities such as name and address checking, to sophisticated business processes such as purchasing and supply chain management. Imagine, for example, that someone in your IT organization had programmed a widget that would make it easy to show all you customer locations as pins on a map, with the size of the pin representing the volume of business you conducted with each customer this month. Imagine further that an IT savvy business manager wants just such a capability. How is he going to know you have one? Chances are, he’s going to use Google (or another search engine) and locate such a widget in less time than it takes to make a cup of coffee. The reality is that, at least today, the web is far more easily searchable than your internal object library. And, of course, my hypothetical case that someone in your IT organization had already created such a widget is unlikely, so we are heading from a reality where:
1. Business users will meet their own needs by “pulling services from the cloud” rather than asking their friendly (but way too busy!) IT professional.
2. A vast supply of business widgets will become available to these business users.
Now, I don’t believe this is bad news for the IT profession – quite the contrary, it is great news! You see, at the risk of stating the blindingly obvious, not all business services are of equal value. We can help break down types of services based upon their contribution to value using ideas first articulated by Professor Noriaki Kano in the 1980’s, through what is known today as the Kano Model. Many services are simply ‘table stakes’ – they fulfil basic needs – they have to be done, but they don’t differentiate you in the marketplace. Name and address validation, credit checks, and so on are table stakes types of services. Other services go beyond table stakes to meet performance needs. They can, if done really well, provide customer value above your competitors. Finally, there are services that can literally “excite” the customer – deliver something they were not expecting, and don’t get from your competitors. These are the highest value, often innovative services that differentiate you in the marketplace.
So, the big opportunity, made possible through SOA, but not an automatic byproduct of using SOA unless you plan for it, is to focus the internal IT organization and resources on “exciter” services, and let the open market provide the basic and performance services. Over time, the market will provide faster/better/cheaper “table stake” and “satisfier” services than you can or should provide internally. Of course, I’m taking an overly simplistic position on this – focus the IT organization on differentiators, and obtain all other types of services on the open market if you can. I recognize that life is not that simple. But as a direction to follow, and a culture to establish, this perspective will take your SOA efforts in a potentially very different direction.
The challenges in moving in this direction are significant – not because of the technology, which is evolving rapidly, but because of “unwritten rules” that drive behavior. (See earlier post on Unwritten Rules.) Typical ‘unwritten rules’ that conflict with this powerful new direction for service provisioning include:
People are measured on the performance of their function, not the total enterprise – for software developers, ‘performance’ is typically equated to ‘writing code.’
Taking a risk that has a bad outcome can be career-limiting.
Working with ambiguity is heroic, clarifying ambiguity is non-rewarding.
Satisfying your boss is more important than creating a great customer experience.
Implying that someone else does something better than us is taboo.
The real trick of getting the most out of SOA – indeed, exploiting the transformative powers of SOA, will be in overcoming these (and similar) unwritten rules and other more structural impediments such as IT funding models (that tend to be project based and unfriendly towards infrastructure development) and governance models (which often position IT architecture governance as a policing rather than enabling activity.
We will pick up on additional business implications of SOA in subsequent posts.