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.
MOOSE?
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.
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.
So 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. 
While 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