Keystones and Rivets

The HP consolidation

Hewlett Packard (HP) has been pursuing an aggressive campaign to reduce the number of applications used internally to operate its business.

The project, which has been gathering momentum since it was kicked off in July 2005, seems to be entering it’s final phases, and there have been quite a few articles written of late about how the project is progressing.

The consolidation majors on reducing the application count from 6,000 to about 1780, and reducing the number of HP data centres from 85 global centres down to just 3 pairs based in the USA.

Understanding SOA

Over the past year or so there has been a huge increase in the amount of discussion about Service Oriented Architecture (SOA), and the number of blogs and posts on the subject seems to increase daily.

So with over 25 million references to SOA discovered by Google, why bother writing another SOA blog post?

Much of the discussion amongst the SOA community is interesting to other technophiles, but only serves to confuse the majority of readers.  Bloggers like Mike Kavis try to bring the focus of SOA back to a business perspective, but the vast majority of articles concentrate on the technology debate.

In recent weeks the rise of a lightweight version of SOA, termed Web Oriented Architecture (WOA), has had the techno-bloggers tapping away at their keyboards.  OnStrategies gives us a quick digest of some of the highlights.

Rather than join the technology debate about SOA we’ll take a step back and explain simply how it works, how it can be used and, with the use of a real-world example, describe why a properly planned and implemented Service Oriented Architecture can create a flexible way of aligning business and IT.

Nuts and bolts and dataflows

“Morning…guess what?  The Bengals won yesterday”.

The Pebble loves American Football.

At this time of year, his mood on a Monday morning isn’t difficult to gauge.

If he starts to talk about his beloved team from Cincinnati, we know they won the night before and he is a happy man.  If he doesn’t say much about anything until lunchtime, then it’s a sure bet that they lost.

Mondays mornings have been a bit quiet lately.

This week, though, he was in high-spirits.  Not only had his team beaten “The Ravens”, he told us, but he had won the grand sum of £5 by betting on the match.

“All the drinks are on me”, he laughed.

We could hardly contain our excitement.

When indulging his gambling vice, The Pebble uses something called a betting exchange.  These exchanges are peer-to-peer websites that act as brokers between people who, instead of trading stocks or commodities, trade odds on the outcomes of sporting events.  The sites earn revenue by taking a commission from each winning bet.

Understand Value to Enable Communication

Last week FT.com and Techworld quoted some research from Micro Focus into the financial value IT systems provide to business.

Many companies have managed to control IT budgets by ensuring spend is focused through authorised procurement channels, consolidating supplier lists and rationalising software and hardware assets.  Others have gone the extra step of outsourcing to gain even greater visibility of IT spend.  There are plenty of techniques documented on cost management.

A nut which is more difficult to crack is how to value IT and quantify how this spend contributes to business performance, so the figures quoted in the research made for interesting reading:

Micro Focus research, carried out in companies with revenues from $100m up to over $1bn, shows that less than half of all CIOs & CFOs (48%) ever try to quantify the financial value of their IT assets. Only 37% of CIOs have tried, compared to 60% of Finance Heads. Less than a third of all respondents (29%) from both groups, ever try to quantify the contribution all their IT assets make to the business' performance.

Just over a third of CIOs have tried to find out the financial value of their IT assets.  And that is in an industry with a spend of over $1 Trillion per year.  Are there many other industries which could get away with that?

Are CMDBs worth the trouble?

During the past 12 months I’ve been asked with increasing regularity about the value of Configuration Management Databases (CMDBs).  In this post I’m going to summarise my answers to some of these questions I’ve been asked; as always with a bias towards how best to align business and IT.

On that note, it is worth pointing out that a CMDB is focused firmly on IT, not business. Sure there are some business benefits to be gained, but only as a consequence of CMDB implementation forcing change on the management and delivery of IT.  The great hope is that these changes will improve IT service, consequentially allowing IT delivery to become something that "just works", allowing IT to have more constructive conversations with the business.

To start with, there follows a brief description of what a CMDB actually is and what it often promises to deliver.

A CMDB forms the basis for much of the delivery mechanisms of ITIL v3. The concept is that you have a repository which holds relevant information about your assets, and how each asset relates to any other asset.  An asset, in the context of a CMDB, is termed a Configuration Item (CI) and may be an item of hardware, an application or a service.

So is the CMDB the repository, the data model (how the data in the repository is structured and used), or the data held within it? Unfortunately that depends which vendor is trying to sell you it.

Feature: IT exists for one reason

Never underestimate the degree of clarity that a fresh pair of eyes can bring to a complex situation.

Late one Sunday night a few years ago, my business partner and I were discussing the Oil & Gas markets our new IT company could service.

In particular, we were discussing how to best use IT to maximise the financial value of a) the oil and gas products flowing through a refinery belonging to one of our clients, and b) the huge quantities of data used by the business.

We had many ideas about creating applications to provide a joined up view of how the exploration and manufacturing businesses interacted, but we were struggling to define an appropriate methodology that would put IT in a business context.

Alignment? We need the big picture

Computing Business editor Mark Samuels asked an important question recently:

“It's just a shame that after years of writing about the need for integration between IT and business, alignment is still at the critical - rather than the taken-for-granted - stage. Who's fault is that - the IT department or the business?”

The answer is straightforward – neither.

Why?   Because traditionally Business and IT have not had a way of talking the same language.   And if they can’t speak the same language, and therefore understand each other, then alignment just isn’t going to happen.