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

When three heads are better than one

One of the most often stated goals in SOA is to promote single use and this is certainly a goal. However there are some occasions when actually having redundancy is a good idea. Now I've blogged before about SOA and reliability which is one area where redundancy can be good, it isn't the only one.

What happens if you have to get something right? It might be safety critical (people die if you get it wrong) or it might be business critical (if you get it wrong you lose money) or it might simply be that there are multiple different ways of deriving the answer and this helps you make smarter decisions (if you get it more right you make more money).

This is where the Cheshire Cat comes into play in that "what I tell you three times is true". These are cases where having redundancy is not about system reliability its actually about the reliability and performance of the developers of the software. Most of the time its not worth the effort or cost to do this (Boeing famously decided for the 777 that three independent primary flight control systems was too expensive) but in an SOA enabled business it is worth thinking about areas where it could be beneficial to have software duplication.

Areas that would suit this approach in a normal business need to have the following characteristics

1. High value or High impact - if you get it wrong (or less accurate) there is a business case for improvement
2. Its not about reliability - that is a hardware and infrastructure problem
3. There are multiple ways to skin the cat - It isn't a case (ala flight controllers) of one piece of software in three different teams, its actually three different approaches to solving the problem
4. There is a way to judge between the answers

Forecasting is one example that could suit a duplicate development approach with the "vote" going based on historical accuracy and consistency of trends.

The simple point is that as SOA takes off in businesses its time to look at investing as well as saving money, and sometimes investment might mean doing something more than once for the right reasons.

Technorati Tags: SOA, Service Architecture

SOA Vendors 2008 - A survey

For the last couple of years I've done a vendor assessment on what I thought of the various vendors. This year I've decided to do a Web 2.0 style ;) of thing as well. I've put online a survey form at http://spreadsheets.google.com/viewform?key=pz8YmsABxikMi-h8lTZTuQA where anyone can add in their assessment of vendors and how they are doing. What I will do once there is a reasonable bit of data in it is start publishing the graphs in summary form first and then at the end I'll release all theinfo so anyone can have a look at the raw stuff.

If there are any vendors I've missed off who matter let me know.

Cheers for the help

To be clear on the scoring - 1 = Rubbish or zero functionality, 10 = PERFECT and could NEVER be improved

The odds on a ten are pretty low.

Technorati Tags: SOA, Service Architecture

English and American or why formalism is better than English

Lets be clear, I'm a fan of formalism. The best pure programming language I've ever used was Eiffel, the best programming language I've ever used in a large team for delivering the best code out of average developers and minimising issues was Ada. At Uni I had to learn Z notation and formal proofs and I've even used some of that stuff in certain highly reliable systems I've worked on down the years.

Simply put I think that having a formal specification that can be measured and adhered to is good engineering practice and that it reduces the impact of muppetry and misunderstanding. So that is my cards on the table, I like formalism because its consistently worked in large and complex projects where the skills profile has been mixed and the number of companies involved has been large.

Two countries separated by a common language - George Bernard Shaw

I travel a lot so it always entertains me when people argue that formal specifications aren't as effective as "simple" English specifications. Putting apart the UML/OCL challenge this has some basic problems in that what English do you mean? "British" English? American English? Scots English? Welsh English? Irish English? Australian English?


When an Australian says that you "need to wear thongs at the beach because its hot on the sand" they mean that you should wear things like this on your feet. A Brit will think they mean something like this(link) which is more than a little different.


When a Brit talks about a "bungalow" the Americans look on with same sort of confusion that the Brit has when an American says that someone "fell on their fanny" in polite society. When Americans refer to someone as "liberal" meaning it as an insult the Brit hears it as at worst a statement that the person is a bit wet.

The problem is that language is open to huge interpretation based on locality, even within single countries there can be different meanings. Describing someone as a "Baggie" in West Bromwich means they are a loyal and reliable person, ten miles down the road it means they are criminal scum who can't be trusted.

This isn't about pronunciation (for instance to all Bartenders in America, its highly unlikely that a Brit is ordering a "bear") its about the actual semantics of specific individual words that can completely change the meaning and outcome of a sentence. One example that was used at Uni to explain what a bugger English was is the following phrase

"The pen flew across the page"

Now it makes perfect sense right? It means someone is writing quickly, but could it mean something else?

Starting with the first noun what definitions can we have?

Pen - A writing implement, a place to keep animals, a female swan

then to the last noun

Page - a piece of paper, a small boy

then the tricky middle section

"flew across" - went in the air over, went fast

So which is more logical from the original statement?

The female swan went in the air over the small boy

or

The writing implement went fast over the piece of paper

Now we know its the last one right? But legally if it came to the argument could you explain why it could never be the former? This is the issue with "plain" English contracts, they are open to interpretation and this interpretation leads to delays and errors, formal specifications help to minimise this scope and thus help to improve quality. There is no such thing as "plain" English when it can be used to create nonsense poems like "Jabberwocky" and result in lawyers arguing over the interpretation of specific words in contracts and laws.

Put it this way, if someone wandered up to a bloke in an club or bar in the UK and said "Excuse me mate, can I bum one of your fags?" they'd be fine, in certain areas of the US they'd have a life expectancy of less than 30 seconds.

Technorati Tags: SOA, Service Architecture