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

SOA - shoot the technologists

There are lots of statements made about SOA not being something you can buy from a vendor. I'm getting more extreme in my views... I think it isn't even something you can build. Clearly there can be technology delivered that meets an SOA, but can you actually do SOA if you are thinking about it as something that is just built?

People seem to be approaching SOA more and more as something that is resident in IT only, or even worse is where IT "understands" the business and builds things that are more responsive... without actually getting the business to own or define anything.

If SOA is going to actually make a difference to what is a failing industry then it needs to impact the structural problems, rather than just trying to deliver a new set of technology projects. 80%+ of IT spend is on "business as usual" aka "keeping the lights on" the support and bug fixing of current solutions, paying the maintenance licenses, patching things and generally just keeping them on life support. And then with the 70% or so of new projects that actually fail to deliver what was expected this means...

This means that around 6% of IT spend actually delivers new value to the business. This is fundamentally broken. Therefore if SOA is going to succeed it needs to help more projects succeed, and more importantly either reduce the 80% spend or help deliver more value for that 80%. This means that SOA truly has to be about how you govern and deliver IT, including how you continually deliver IT to the business once it has gone live.

This is why I'd argue that SOA isn't even something that gets built, its something that becomes a part of your culture, it changes all aspects of your IT organisation. Otherwise it really just will be yet another techy idea that delivers little or no value down the line.

IT is a broken industry, it takes more than an ESB, some Web Services and changing some design guidelines to fix a problem this large.

Technorati Tags: SOA, Service Architecture