This week I had an interesting discussion with Anne Thomas Manes of Burton Group and Rob Eamon about where SOA has to be - in Technology/IT, or in Business, or anywhere else. I would like to represent the arguments and contra-arguments of this debate for you to make your own opinion.
The discussion has been started by Anne's recent post that once again explained her almost revolutionary statement: "SOA is Dead; Long Live Services" made in January, 2009. Many architects, managers, and bolgers responded that time because the statement was misread initially. Finally the discussion pacified due to the context of the statement that was very clear: ""SOA" as a term has lost its luster, but "SOA" as a practice is essential for all organizations going forward". It is almost obvious that the SOA term has been obfuscated in the industry by the details of implementations that did not in fact grasp the concept of service orientation. In reality, service orientation is very powerful and highly permissible concept of modelling actual life.
Among others, Anne has quoted John Rymer who said: "SOA died a marketing death", "When a technology becomes vital, it dies in a marketing sense," he explained. "It's time for SOA to 'die' since it's not distinguishable anymore since everybody's using it." I do not think that Anne's based her conclusion on the marketing trends; there is a fact that many organisations started to cut their investments in to SOA projects in IT because those IT failed to provide for their promises made about SOA economic efficiency. At the same time, we also have many examples of SOA success in other organisations. The question is: why SOA projects in IT have lost business trust to the degree that this become almost an industry trend?
In the comments to the Anne's post, Rob outlined that IT reached the stage where isolated individual "SOA initiative" (that I called 'SOA projects' ) have demonstrated their incapability to reach the value of service-oriented solution in "organically growing SOA", i.e. SOA must be treated at the enterprise level to be productive and should be driven by the Business.
I usually promote similar approach to SOA explaining it as a business-oriented consumer-centric architectural model. Any violations of mentioned characteristics lead to SOA failure. This, IMO, is the reason of multiple failures in SOA area - use of Web Services for integration of applications somewhere in the IT depth has a very far-off effect to the business, if any; composing existing legacy applications to satisfy immediate business needs without any perspective view on the changes that come tomorrow leads to the waist of IT resources and only increases the cost of IT efforts; disconnection between IT projects disallows appropriate project funding and planning of implementation of service oriented solutions (SOS); and, finally, still process-oriented nature of low-level business operations constantly conflicts with potential service-oriented technical solutions (because an effective IT solution can overcome the operational process while, instead, the process downgrades the SOS to the level of process actions and nothing more, i.e. potential efficiency of SOS is constantly compromised by inefficiency of the process).
Anne's response was a bit unexpected: "Given that the business (i.e., non-IT people) rarely gets involved in system architecture design, it doesn't really make sense to argue that SOA should be driven by the business. SOA is an IT architectural style. IT people are responsible for designing the architecture of the IT systems. Hence, SOA must be driven by IT. BUT: IT *should* direct its SOA initiative based on business requirements." The essence of my position is that business requirements derived from non-service oriented business implementation (i.e. business operational processes) kill SOA in IT; does not matter what IT does, SOS is not needed for such requirements.
For SOA to succeed in mass, Business has to be deeply involved in SOS and, correspondingly, has to influence system architecture design. Despite SOA was initially defined as "an IT architectural style", in nowadays we have achieved the understanding that service-oriented principles can drive Business even more effectively than IT; that SOA must be driven by Business and than cascaded into IT if an organisation wants to gain maximum efficiency from its service-oriented initiatives.
Only in the situation described above, IT will get service-oriented requirements and will be able to respond with service-oriented technical solutions. IMO, SOA, more accurately, service orientation, moves from IT into Business. I think, Anne and me were closing our positions when Anne said: "SOA must be business-driven (i.e., the goals of the SOA effort should be focused on generating positive business outcomes), but it should not be driven by business people.
(Business people don't grok the necessity of SOA, and therefore they will not be good leaders for the effort.)"
This is the crucial pint of the discussion - in my opinion, if SOA has its 'ceiling' in process-centric low-level business operations and locked in IT, there is 'no-go' for SOA. But it is not clear to me why it should be this way. In my findings, business people who are in direct contact with IT don't, indeed, 'grok the necessity of SOA' while the business people at a layer above, actually, do. At the top of the business hierarchy, people operate primarily in services, they deal with WHAT, WHY and WHO does the business, the lower business layers have to figure out HOW the business tasks may be relaised. If IT is not treated, at least, equally to these lower business layers and cannot really contribute into HOW technical capabilities can innovate business solutions, there is very little chance for SOS to be effective and, thus, survive at all (currently, IT is positioned UNDER the lower business layers and plays the role of 'forever follower').
Finally, who has to lead SOA efforts? Anne says: "I agree that senior business managers understand "services", but even they won't be motivated to lead SOA efforts. If you want to." Yes, if IT wants to. My work is to make SOA the need of senior business managers, and I believe, IT can accomplish this task, especially, if consider there is be no resistance from the 'service' understanding senior business managers...
Anne has concluded: "Improve the architecture of your IT systems by adopting SO principles, the effort must be led by EAs". If we use meaning of EA (Enterprise Architecture) as defined in TOGAF 8/9, i.e. where EA = Technical Architecture (in IT)+ Business Architecture (in Business), I think, we all have got the common and solid agreement on the subject.
Leave a comment