« Understanding the Benefits of XForms | Main | Impressions from GITA 2008 »

March 09, 2008



I think your comment of only one successful SOA raised some eyebrows, though I suspect it may reflect on what you believe an SOA is and is not.
The reason way I see it, SOA is about a higher level of abstraction, where I can engage business functionality at a level where little is known about the actual implementation. Therefore, it behooves the business to specify what capabilities make sense to be shared as a service. That is, the same functionality is needed across the organization and if we abstract the fundamental elements that would make it useful, then it can be effectively shared (reused).

Consequently, I suspect it is somewhat difficult (based on my experience) to get people to think in terms of that level of abstraction. There seems to be a tendancy to drive it down to system functionality that is "wrappered" so that I don't know the implementation details, but I know that at end the customer database is updated. Though this is powerful, it is basically the Object-Oriented layer of separating the interface from the implementation and should be the modis operandi of could system design, but does not raise itself to the level of being an SOA abstraction.

So, I suspect that you are right, there may be lots of people doing things they call SOA and I'm sure they are doing things more service-based than they did before, but it terms of organizing around an SOA approach to architecture / the business, there are probably few success stories. I do hope you hear of more than one.


Anne Thomas Manes

Duane -- my measurement of "successful SOA" is simple: Has the initiative delivered any of the benefits specified as the goals of the initiative? Every company I have interviewed has said that the goals of the initiative are to reduce costs and increase agility. Only one company of the seven that I have interviewed has achieved these goals.

Duane Meade


I agree with the goal to reduce costs and increase agility. What I guess I was trying to say is if you don't raise the level of abstraction where "use" of the services can be very flexible because of the stability of the interface and also reduce costs because you have decreased the coupling (and thus dependencies between services), then it is likely you will not achieve the benefits of SOA. I can't decide that all band music doesn't sound good, if my only experience is with the 5th grade band at my kid's school.

Steve Rdzak

I think most businesses and the IT that support them do not have a good understanding of the conceptual model of their business. Many can't decouple their thinking from the application and database models used in their daily work.

To get to successful SOA you have to get both the business and the IT that support them to buy into delivering IT capabilities matching the conceptual model of the business.

But getting the two camps to collaborate on what that model is and governing projects to deliver shared capabilities aligned to that model is the biggest hurdle to overcome in most businesses today.

I think the value curve for SOA is going to be much slower to be realized than it was for Object-Orientation because of the fact that it really is way of thinking that is foreign to both business folk and technical folk.


Mike Kavis

The problem is many people don't really understand SOA. The problem with SOA is not SOA, it is people. I wrote a short post on this topic.


Anne Thomas Manes


I appreciate your comments, but I don't think that BPM is the "killer app" that will save SOA. In your post you describe "SOA" as a means to enable integration with legacy systems. Certainly legacy encapsulation can be a great enabler for BPM, but it doesn't make for an effective SOA strategy.

A successful SOA initiative focuses on reducing complexity, refactoring systems into services that implement core capabilities, and eliminating redundancy. It focuses on defining common patterns that apply to all business units and setting up software factories that enable the delivery of new products in a fraction of the time it used to take.

The goal of a SOA initiative should be to get the business units to look at the app dev group as an enabler, not a hinderance. To reach the point where the business says to the app dev group, "slow down -- you're giving me too much, too fast".

BPM is a valuable initiative in its own right, and organizations that fully embraced BPM typically realize a lot of value. But, as you say, BPM requires that you have services to assemble.

The reason why most SOA initiatives fail is that they can't reach the point where they have a portfolio of services. And that's because the business units aren't willing to sponsor the creation of services.

Catch 22.


Eric Roch

SOA is too much in the hands of the techies in most companies (I am one of course). I am afraid the business is about to pull the plug on a lot of these SOA technical exercises.


Mike Kavis

I agree with what you said which is why I say BPM is the killer app that makes the business care about SOA.

As I stated in this article https://blogs.ittoolbox.com/eai/madgreek/archives/selling-soa-a-true-story-18349
if you align SOA with a key business initiative you can get the support (and funds) that you need to make SOA a reality. The business doesn't understand SOA, nor should they. But they do understand BPM and we sold them on the fact that SOA allows the business to receive the value of BPM without the expense of IT having to blow up the legacy systems (which would take years). Our business understands SOA as a tool to extend the life of our legacy systems (legacy rejuvenation as Zapthink calls it) and BPM as the tool that eliminates waste, improves employee morale and customer satisfaction, and increases revenue.

Without linking SOA to BPM, we never would have been able to justify the expense of SOA. I know, because I had been trying for years.

Mike Kavis

Hopefully this link explains my point better.


pawel lubczonok

SOA is not a technology - it is abstraction and architecture. Also, I believe that SOA is overhyped and it will be superceeded by another type of technology. The current approach is to package old systems to participate in services bus. This enables archic systems that should be scrapped to survive. Of course, this means that existing groups behind these systems preserve their jobs and power as well as consultants earn from 'helping to implementing SOA' - another vested interest. So, in a way SOA can cause retardation of progress. It is just too difficult to get SOA to work as you have to get so many pieces (and people) to be organised and connected (all have to agree) that complexity is too great and benefits will come too late to be accepted. Tools and approaches to get SOA right are also inadequate.

The development of systems and architectures based on semantics/knowledge are the future. One can see now the beginings of interest in semantics (again!) - semantics web, ontologies etc. It is true that these are still in very early stages of evolution. However, in systems that are based on semantics, SOA should just happens behind the scenes just like various protocols happen behind email system. Once one operates on a knowledge level rather than information level a lot of things can become different and most importantly simpler. Of course, one must agree with the SOA objective to make things work together.

Pawel Lubczonok

James West

I have been and am continuing to promote SOA, to business and IT, as a way to get everyone on the same page process-wise and identify common services across business units. As Enterprise Architect with 25-years in the software development experience, that's valuable regardless of technology.

From a business standpoint, there is some buy-in (head nodding) and perceived value but most, unfortunately, are either overwhelmed with their own duties and/or think SOA is just another technology initiative that will soon be replaced with SOB.

Realize the that IT industry is its our worst enemy. Only months after a new strategy/technology is promoted, something else is promoted as superior. In spite of all the effort towards "open", "standard", "inheritance", the ego and profit of the creator still dominates the software landscape.

The majority of Corporate America's budgets, systems and staff simply can't react effectively to these ever-changing ideologies not knowing which has sustaining technology, fit and support. As such, most action is the action of "wait and see".


Thought-provoking Post Anne!
I think its SOA proponents responsibility to really showcase some authentic SOA success stories to the world. What we have all been hearing is that the tall promises and the actual process of crafting SOA solutions.
And We also say True SOA will re-organize IT from the way it works currently. And any change - nobody likes it!. It is as simple as that!
Its not just SOA, any change management initiative that needs to take place in the company, It will go thru the same hurdle that SOA has to go thru!.
Both in SOA and Web 2.0's case, it is the company's culture and people matter rather than technical solutions. And the problem is, the IT consultants or Architects or Managers do not have enough credibility to talk about change management initiatives!. It has to be talked by a Leader who understands the potential of SOA and articulates in a convincing manner and persuades people to join the bandwagon!. And the Leader should also be able to convince the Top Management to sponsor the initiative!. And thats not easy!.
Unfortunately, We dont have too many leaders available in the first place, who can understand SOA and has the Political Will to see thru the implementation!.

Steve Mack

I'm wondering where this discussion has migrated.

I am working on developing a strategic plan for a software development and management group within a large organization. My background is in business, not IT. In this effort, we were asked to include an element about planning for SOA implementation.

I asked one of my "techie" associates who is familiar with SOA technology to write this section, then I would edit it into the main document.

I am now baffled. I get (more or less) what the many pages of writing are saying but there is no hint anywhere of why implementing SOA makes any difference to the business people that these applications support. I take a lot of pride in my ability to translate technical discussions so that my fellow business people (whose eyes typically glaze over when the techies start talking) can realize why they should care about the latest in software development, architecture and so on.

Anne's comment above:

"A successful SOA initiative focuses on reducing complexity, refactoring systems into services that implement core capabilities, and eliminating redundancy. It focuses on defining common patterns that apply to all business units and setting up software factories that enable the delivery of new products in a fraction of the time it used to take."

...comes as close as any to helping to make the business case for SOA, but it is going to be real hard for me to make the case that the business folks need to care about this if this is all I can bring to the table.

If you have more, or can point to something more, please let me know! I will be tracking this discussion.Thanks!


Hi Steve,

If you ask me, I would say it would be risky to quote the generic benefits of SOA to the specific case you are handling.

And thats exactly the problem happening in the industry. Consultants/SIs are approaching SOA as cookie-cutter solutions. And it doesn't work.

Making a business case must be easy, if we have a good handle on the existing Business-IT landscape's painpoints. And that would be a good starting point for selling SOA.

Pls feel free to approach me for further discussions.


Gino Roy

I'm not sure if 7 companies is a good enough sampling. But to the point of the article, measuring success is dependant on the maturity of its IT Architecture prior to embarking on their SOA initiative. If the SOA Infrastructure did not eliminate any existing infrastructure, then an ROI would have to assume the incremental costs of all that new infrastructure.

If success is to be measured, you need to define the criteria because it would vary from organization to organization. For example one company might want to lower its TCO while one might want to increase its agility. These two factors can compete at times. Agility could drive an increase in TCO but the benefits of agility may outweigh the increased TCO.

I would be interested in finding out the timeframe the companies used to measure the success of their SOA initiative. Generally SOA success would be measured in the long term since benefits of agility or whatever criteria was defined to measure success can only be measured once a requirement for the criteria has been triggered through aspects such as regulation, market pressures, customer demand, etc.... These aspects don't occur that frequently so the benefits and success can take time to manifest itself.

In the mean time there may be small sucesses that should generate some benefits such as reduced time to deliver new solutions, reduced cost to deliver solutions, increased utilization of existing investments. Of course, there would be a manner to measure these as well.

I also believe that SOA cannot deliver on its promises without the need to look at complimentary architectures and concepts such as Event Driven Architecture (EDA) and Canonical Information Models (CIM). Business services and processes need to capture and respond to business events. Business events and business entities need to be defined in an information model to facilitate communication between services and business processes. SOA needs to provide the agility, reusability and loose coupling

Brian Cain


You absolutely hit the nail on the head with, "established strong positive and negative incentives that encourage ... sharing". No organizational change will succeed without this. And SOA requires that organizations change.

The comments to this entry are closed.

  • Burton Group Free Resources Stay Connected Stay Connected Stay Connected Stay Connected

Blog powered by Typepad