If you can't measure it... don't claim it

Todd Biske wrote a blog post about SOA Expectations and Anne Thomas Manes followed up. One of the bits in there is around the agility question. Namely that organisations state they want more agility (and often more productivity) but don't have any formal metrics. Now I've said before about SOA and metrics but its worth repeating.

Measures really matter in what should be a professional engineering discipline. Stories abound of IT departments measuring their own success, and oddly improving year on year, while their business feels that its getting worse.

Investing in a proper measurement programme should be the base state for any professional IT organisation, with an SOA one it should be mandatory.

If you can't explicitly prove (and stories don't count) that things have improved then they most probably have not.

Technorati Tags: SOA, Service Architecture

Networked economies require Services not Processes

Back in the 80s the "Value Chain" was key, this was the series of steps and links that it took to deliver the value. Now the Value Chain really suited a process mentality. It was a pretty linear thing, everyone did their own bits in it and handed on from one place to another.

A Mr Porter created an image to demonstrate the Value Chain

and others have used the value chain approach to explain different markets

The point here is that process made sense in this world, A was followed by B which followed C etc etc. People mapped out simple processes and it just seemed to make sense.

The problem was, and most assuredly is, that Systems Theory was making itself more and more known in the business world. This is where collaboration becomes more about units (services in SOA terms) working together in complex networks than simply a chain which hands over responsibility. This led to the Value Network approach that business schools started pushing out in the late 90s.

Now SOA works very well in a Value Network as its all about the independent elements, their goals, their objectives, their measures and their conditions. A service is able to actively participate in a Value Network as it has a degree of autonomy of action that is not limited to a simple single goal process, a service can make decisions around what should be done across a range of capabilities and take responsibility for the negotiation and participation in a value network as an entity, something processes cannot do.

Unfortunately however IT lags significantly behind the business thinking and is still trying to push a 1980s view of the world, process, as being the important element of business. Now don't Value networks (from Verna Allee) remind you of something?


The current, and next, generation of businesses are about complex collaborations to deliver value, not simply about following a process. This collaboration approach requires a business service approach and a focus on interactions, objectives and KPIs. Its a much harder environment to be working in than simple Value Chains but the potential rewards, and dangers, are much more significant.

SOA can deliver Value Networks, POA cannot.

Technorati Tags: SOA, Service Architecture

SOA mentality - its about you, not me

On a discussion on the Yahoo SOA group there was a question on what is the difference between SOA and IT applications. The basic difference was simple

• IT Applications - about me, the producer. About a specific task and about being able to blame other people for the overall thing not working
• SOA - About you, the consumer, and providing a commitment to get things done across multiple areas and providing you with a single place to get it all done from.
  

This is just part of the SOA switch but its a big one. IT applications create a blame culture, SOA environments create a commitment culture.

Technorati Tags: SOA, Service Architecture