Observing current development practice in the sphere of Service Orientation, I have found (not without a surprise) three almost unrelated domains that have potentials of or already slow down an adoption of Service Orientation between Business and IT. These domains are:
1) Cloud Computing
2) Systems Operational Support
3) Outsourcing companies.
Are you surprised as well? Then let's analyse the cases together.
As we know, SOA is a global paradigm covering both Business and Technology, which is confirmed by the OASIS Reference Architecture Foundation for SOA. This means that a SOA Service is a cohesive composition of business manual and automated operations dedicated to particular business function. The role of Technology in this composition varies but usually it is very important if not crucial. The expression of one of the analysts - "The reality of the digital age is that your business is embodied in your technology - you don't have a business until you have it implemented in your technology base, and your business can change only as fast as your technology can" - becomes true for more and more industries.
The major consequence of this understanding of SOA is a need for a close relationship and collaboration between Business and Technology. For the business to be successful nowadays its technology arm has to breathe the same air with business. Service Orientation should become not only a model for the business products but also an organisational principle of the corporate business.
In this light, it is evident that SOA does not appreciate a tendency of departing Information Technology into the Clouds, which is frequently promoted in the Cloud Computing. Public Cloud Computing certainly has its niche (primarily in the companies of micro and small sizes that need but cannot afford IT Departments). When the companies grow, the need in strong ties between Business and Technology becomes inevitable. Natural Service Orientation in Business will necessitate coupling with Technology or, at least, a full business transparency of the technical parts of the business. This means that business investments will turn Cloud Computing into something much closer to the corporate business than the public Cloud Computing anticipates. For the mean time, the CIOs do not move forward being at the cross-road - whether to go where the monies are, i.e. with Business SOA, or to go where immediate capabilities are higher, i.e. with public Cloud Computing, which still has not proofed if it is good in the adopting business changes.
A more dangerous opponent to SOA is Systems Operational Support. Several years ago the technology leaders understood that SW products (and respectively business consumers of these products) suffer a great deal from the problems attributed to the inadequate belated testing. The SW development methodology was changed requiring testing functions to participate in the development cycle at the earliest stages of the business requirements study. Tested were able and had to study the architectural and design solutions to validate related implementations versus business requirements. The Systems Operational Support personnel have not been that lucky as testers and staid far behind the development 'a vanguard'.
The fundamental thing about SOA is its distributed nature. SOA implementation must scale from a couple of Virtual Machines to a Grids. Each SOA Service is an application on its own, with its own live-cycle and deployment policy. When we approach SOA design from the business practicality perspective, you find that the number of business services is not that large in an enterprise or in the a corporate division. This number barely reaches the level of a hundred, may be a few hundreds. However, if your Systems Operational Support is unaware of SOA distribution, you can expect a fatal confusion among the people when you drop a hundred new applications (instead of one) on the heads of the Support guys.
Let me refer to the recent discussion between Alexander Johannesen and Steve Jones (the author of the first book about OASIS SOA RM standard) - Alexander: "Seriously, even in the mires of dogmatic enterprise there is a huge push for better handling loads and volume, and the answer to that isn't faster CPU's, but distribution", Steve: "Yup I'm sure about that because 99% of people in IT can't handle distributed systems problems." Here is what usually happens in Systems Operational Support: when a sophisticated or complex in logic SW product is released for support, the chances for this product to survive are minimal because it is too difficult for the Support people. When Business SOA starts in the organisation, the Systems Operational Support gets a double impact - from the business people and from the technical 'complexity'. Who would like this?
Actually, SOA is not complex at all, it does not require or use any technology that has not been known and used before but the volume of the independently working Services that also share the same information resources simply exceeds the Systems Operational Support human and technical resources. IT development planning considers the capabilities of the Systems Operational Support with the least priority, and the Support pays back with the same currency. Business SOA will be successful in Technology only if you invest not only into development but into the production support as well. If you do this investment, the Systems Operational Support will be Your supporter; otherwise volume-related stress will overwhelm people and they will start 'simplify' or trick your SOA products, just to survive. A few failures in production caused by simplified deployment and ignorance to the proactive monitoring of dozens simultaneously interacting services hurts the reputation of the product and users start looking for alternatives. That is, a good product in over-simplifies environment heads to the end.
However, this 'enemy' may be converted into an ally if you properly manage it. This management includes up-front training and investment into the right tools. Yes, the monitoring tools for distributed SOA solutions are not cheap but the task these SOA solutions realise are the business tasks. Business has never benefited from cutting its ability to know how it works and what prevents it from working better. So, do not be afraid when asking for proper investments into the Systems Operational Support when you deal with SOA solutions (of course, if they are real Business SOA solutions).












Michael, nice posting. I especially liked the discussion about the Ops support personnel.
Thanks, Tarak. I hope, that the Part 2 about outsourcing would get your appreciation as well...
Just a slight comment (as I agree and like what you've written) that when it comes down to it, a load-balancing act - something terribly common and that any IT person actually understands - is a form of distribution. (And Steve's reply is put up as "John" which I think is wrong :) It's simply not true that distributed systems on the back-end are that hard nor mysterious. We all have a load-balancer, a switch, a multi-core CPU that we interact with, sometime configure and sometimes even develop for.
As to the fact that SOA doesn't change hardware is spot on; it's mostly a way of thinking, only sometimes a way of doing.
Alexander, thanks a lot for the clarification (I will correct my mistake about ‘John’ with apologies to Steve). Yes, we certainly use load balancing and “is a form of distribution�. What Steve said sounds to me as an emotional explanation of the fact purely distributed EJB 2.x components and the entire concept of Enterprise components has been killed in EJB 3.0 for the sake of OO programming (POJO). That is, majority of people resisted accepting distributed computing mindset in their daily job...