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

Hello, let me sell you snake oil...

Today I had a sales call from someone trying to sell me a spot at an "exclusive" executive conference. The chap did all the normal sales patter and as I tried to cut to the quick with "how much" he said I needed to understand how exclusive this was and how it was the most exclusive event in Europe.

I laughed and said "well not really the most exclusive is it?"

"Yes" he said "its the most exclusive event in Europe"

"What more exclusive than Davos?" I laughingly asked

"Oh yes much more exclusive" the sales guy said

Seriously I know that IT is important but an IT event in Europe more important than the World Economic Forum? Over selling doesn't make me want to go more.

Technorati Tags: SOA, Service Architecture

Vendors move away from SOA, can we get on and do some work now?

Over the last few months I've seen a very nice shift in the focus of software vendors away from SOA & Business Process towards their next piece of string, Complex Event Process (CEP). Now this is being pushed as "part of SOA" but this is really great as it really focuses the vendors as being in the technical SOA space over the business SOA space. Oracle are focusing on the Grid infrastructure for scalable and reliable SOA infrastructures. These are all very positive things as they more firmly underline the difference between the technology enablement of SOA from its business definition. This is a very good thing^TM as it highlights the missing area much more effectively than the confusion that was caused by the Web Service and BPEL focus that claimed to be business oriented but in reality was not.

This represents a real evolution of the T-SOA market, in particular with Oracle focusing more on the operational side of the technology over the bells and whistles approach.

Now the question is can SOA as a business concept be revived and establish itself as the way to think and deliver SOA with the vendors providing simply the platform on which it operates.

Technorati Tags: SOA, Service Architecture

Why relative metrics matter in delivering success.

George Bush today gave one of those great lessons in why its really important to think in relative terms when talking about metrics for success in any programme.

cutting wasteful or bloated programmes that will save tax payers over $18bn

Now this sounds pretty good until you realise that this is against a total budget of $3trn. Yes folks $3trn... in other words this "saving" represents 0.6% of the total budget.

This is something I've found with a lot of technology change programmes. Numbers that sound really good just don't stand up to scrutiny when you do the maths. So you see numbers like spend $2m and we will increase productivity by 10%. This sounds great, until you look at the yearly spend and find that they spend $5m a year, which means the ROI on that $2m is FOUR years. The trouble is that the following year they ask for another $2m for "new" technology and the expected 10% still hasn't been delivered.

The other thing that I see are another Bush speciality, fake unmeasurable metrics. So the 10% is a good one in IT, because in most companies there isn't a real measure of actual productivity. People shout "agile" in the mistaken belief that this means you magically get better. Unless you are measuring success in an open, honest and above all accountable way then its just your opinion of the improvement against those whose opinion will be that its just the same or worse.

The point therefore on any change programme, and especially when your company might be facing more troubling economic times is that an SOA programme should have three clear sets of metrics

1. Financial Metrics - Relative to today how much more bang for the buck will you get and how will you prove that.
2. Delivery Metrics - Absolute measures of productivity (concept-to-market cost/time, function point cost/time, etc) and how they will improve
3. Operational Metrics - How will the operation of the system improve (non-functionals, cost to support, fix/resolve timescales)

Everyone of these should be expressible simply and automatically measurable, requiring at most a spreadsheet calculation.

Otherwise you are just doing a George Bush and talking up a tiny piece as if it matters in the grand scheme of things while avoiding all the really big problems and genuine accountability.

Technorati Tags: SOA, Service Architecture