How is SOA and BPM going to improving the ability to serve and exceed quality while cut in the 30% cost of IT MOOSE? I´m convinced that SOA and BPM is NOT the answer. The discussion on ROI of SOA caused by my Blog-item SOS voor SOA andmultiple discussions with Max J. Pucher and reading his blogs, but also the posting of Ben Tels and others blogs and several papers have strengthen me in my thoughts that SOA althoug a great Architectural concept has lost its meaning. But I´m open for other insights and discussions, so feel free to react after reading this post.


The term MOOSE comes from Forrester. Executives often look at IT spend as a black box and compare it as a percent to overall revenue. Maintenance and operating the IT organization, systems, and equipment (MOOSE) takes approximately 70% of IT budgets (Forrester: the October 18, 2005, “Defining The MOOSE In The IT Room” report.). The remaining 30% comprises investments to support business growth, to cut business cost, and to cut the cost of IT MOOSE.

it moose

Macro-economics conditions shaping the CIO´s job currenlty. The reality is that any business at any time may need to shift its executive focus toward running lean.

The question is how will SOA and BPM help the CIO Invest more in New and Improved Capabilities to support business growth and therefore to Reduce the Cost of Business and above all Cost of IT MOOSE. Seriously, I doubt that we can hold our claim that SOA and BPM are bringing the CIO those benefits. Besides the argument of Cost saving, we also hear the arguments for Business Agility and Compliancy. I will not go into Compliancy and connected to it Security, it´s to broad for this blog but Agility is also something to think somewhat more on.

SOA has lost his meaning

Burton Group VP and Research Director Anne Thomas Manes recently said,

“I’ve talked to many companies that have implemented stunningly beautiful SOA infrastructures that support managed communications using virtualized proxies and dynamic bindings,” says Manes.

“They’ve deployed the best technology the industry has to offer – including registries, repositories, SOA management, XML gateways, and even the occasional ESB. Many have set up knowledge bases, best practices, guidance frameworks, and governance processes. And yet these SOA initiatives invariably stall out.”

Well maybe these companies should have spend less time installing software and building frameworks and more time understanding what business processes could be impacted by removing poor interfaces or eliminating bottlenecks or providing needed information faster.

jabowsSo what happened to our simple view of SOA? How many services do I need to be able to talk of a SOA? Do I need an ESB, Governance tool, Registry to be SOA compliant? Or is just enough to have Just a bunch of Webservices (JABOWS) with a ping function to see if the Services are still alive? What happened is that software vendors have hijacked the SOA term for their marketing needs, analysts have created new categories with accompanying revenue streams and many consulting firms have turned SOA into big-bang infrastructure projects. With all the vendor hype SOA has lost its meaning and in many cases has lead to exorbitant costs with little or no business value.


What About Agility?

Max J. Pucher have some interesting thoughts on it, which are in line with my thoughts when it comes to BPM and Agility as you could read in my blog-item on “What does Route Planning has to do with Business Process Management?”

As much as some business management theorists might disagree, a business is not a machine but a complex adaptive system because it consists of people and has people as customers. We need to understand that it is not the process that shapes the business by shaping what people do; it is the people that shape the process and that in turn shape the business.

Agility is a human skill and will never be a software property. The more software is used to replace people and the more processes and decisions are automated the less agile businesses will become.

Max mention in his blog an example coming from M. Hammer which is a comparison with an American football team. footballWhile the coach trains with the team possible plays (processes) he does not step out on the field and controls the game. A player (process owner) called the ‘offense coordinator’ dynamically selects and positions players for each offense. Players all have very different roles like workers in business. They are trained by special ‘position coaches.’ Offense coordinators and position coaches draw from their extensive experience to shape the team to dynamically react to any opponent. It is this teamwork between coaches, coordinators and players that we need to achieve in daily business operations. Strict process management or vertical applications are unable to provide that. What a business would need is a software system that can learn to act as an ‘offense coordinator’ and ‘position coach’ from its user’s experience. It assigns work to user roles and supports these in how to act in the current play without restricting their ability to shape the play.

Using the football team comparison offers another insight. While the team is given the freedom to play the game as it sees fit, it still has to follow the rules of the game. The same is true for business. Therefore it is essential to understand that user role coordination and coaching does not replace or interfere with the (business) rules that make up the game. Rules are rigid by design, coordination and coaching cannot be.

But the conclusion must be a business is what it does, despite what the CEO or organization department wants and what is modeled in a BPM tool either using a SOA or not.

Call for Innovation

Let us stop reinventing the wheel as correctly pointed out by Ben. My goal is to fullfill the one of the 7 challenges pointed out by Gartner this week in Las Vegas. Let us improve developer productivity with a factor 100 and let us do this with in our mind that its the (business) people that shape the process and they should be helped and not hindered.

Kind Regards

Freddie van Rijswijk

Will SOA and BPM bring the MOOSE Savings and Business Agility?
Tagged on:

4 thoughts on “Will SOA and BPM bring the MOOSE Savings and Business Agility?

  • April 18, 2008 at 7:44 am

    Hi Freddie,

    About three weeks before this post, you discussed the need for an SOS for SOA (in Dutch on Now you rightfully quote “SOA has lost his meaning”. I can’t agree more. I kinda ignored SOA all the time and now time has come to move on. At least for me.

    Why? Some of the good things (loose coupled, re-use, separation of concern) were already there when SOA was invented and did not need SOA to be used in real life. Some bad things (lack of management of service, versioning) were known issues from day 1 and never truly solved. Some promises (building business applications like Lego, ROI) never came true.

    I well recall the early samples that illustrated a scenario where a manufacturer sends out a SOAP message to a broker to find an offer for nails of a certain size and quality. Several responses came and the best was automatically selected. It’s a good example of how the thought-process went: IT heads acting as if they understood business.
    Yes it works great for me privately. To which shop should I go to get the best deal. Look at all the comparison sites on consumer goods. I deliberately said ‘best’ and not ‘cheapest’ deal. Why? Because there are so many factors that play a role in my decision and some of these (e.g. how good is their service?) might lead me to another than the cheapest deal.

    It does not work for companies. They need more than just nails and build relationships with suppliers that influence buy decisions. Terms and conditions need to be factored in into the decision as well. If it gets large financial positions and liability comes into play. No way an IT solution is going to replace human agility that is needed in such a scenario.

    Is it fair to say that SOA has failed? That SOA has not reached beyond its hype? Can we from now on ignore SOA and just laugh at the people that still believe it’s the holy grail? From a business point of view I think the answer is YES. Except for the laughing part. Let’s instead educate them. On IT side let’s cherish to good stuff. And if IT needs to develop software to solve business needs, let them do so in the best interest of business. Without a rigid ‘it must be SOA’ mindset.


  • April 16, 2008 at 7:24 am

    let me start with giving the credits for the remark to Max J. Pucher.
    I think that no Business Manager is able to define the process they can set goals, instruct their team, give them tactics and rules, but the interaction between two people doesn´t follow a predefined route. To make it easier to understand just look at sports. You have the rule of the game that everyone needs to follow and you have the preparation on the game or race by simulating situations and train patterns. But if everyone would follow these patterns without interacting with their opponent it would be boring, predictable and we are not talking of patterns anymore but cookie cutters. Lucky us we are human beings and therefore always interacting with the environment being the opponent, the supporters, your own team-mates, the wind, unpredictable situations, etc.

    You can even start a discussion on the usefulness of Business Intelligence, the past is indeed no guarantee for the future. It´s the current that counts.

    BPM is to me as useful as tactics and training are for sport teams. You discuss possible situations, you think on how your reaction can be, and you train these patterns again and again in the hope that some of them will happen in reality. Why…… To WIN the game of course 🙂

    Best regards

  • Pingback:Gridshore » Blog Archive » Letting go: yet another traditional problem in the SOA world

  • April 13, 2008 at 11:30 pm


    I’ve rereadyour post a few times now; I think you’ve hit te nail right on the head, especially with the remark that “[a]s much as some business management theorists might disagree, a business is not a machine but a complex adaptive system because it consists of people and has people as customers.” It is this very dynamic quality that makes business processes difficult to capture in a static model that can be decomposed in a top-down fashion into a SOA landscape.

    The original promise of SOA was to take the implementation of the corporate IT landscape and wrest control from the IT architects, replacing a technology-driven mode with a business-driven mode. However, such a strategy is belied by the inability to capture the business process in a top-down model.

    At the same time the business agility promised by SOA implementations is limited by the same dynamic nature of the business markets. The main promise of SOA was to introduce reusability of software components at the macro level, allowing reuse of business-level complex components. However, the dynamic qualities of large companies (or even divisions within large companies) and the emergent properties of such dynamic systems often make for components that are not reusable since each business unit is different and often has (partially) incompatible needs when compared to other business units. This implies at the very best that if one considers a tree of service components in one SOA, there is an upper bound to the level of complexity of the components that can truly be reused in any sensible way.

    Another question that also occurred to me is how realistic it is to expect business management to be able to define the business process in a way that can sensibly be used to create a SOA landscape. Divisional managers may be able to define the needs of their departments but often cannot look over the boundaries of their division. The IT people may notice similarities in implementation but are not in a position to make the leap to the full business overview. And upper management of larger companies is often full of people who don’t really know the business (consider for example the Dutch Top-500, which is full of companies run by job-hopper professional managers whose only qualification to lead the company is that they led the last company they worked for, in whatever industry that was).

    Wonder what you think….


Comments are closed.