Keystones and Rivets

IT (still) exists for one reason

The Pebble groaned.  “Another big 2.0 conference is coming up...I’ll be reading about it for weeks.” 

My non-tecchie colleague, who freely admits that the average pebble possesses more IT knowledge than he does, spends a few hours each day trawling various media for news and information of interest to our company.

Something he hates is anything ‘2.0’.  “Who comes up with this junk...is the pen the pencil 2.0?”, is a rant I’ve heard on more than one occasion.

The other day he was scanning a few blogs and I could tell he was going he let rip once again.  It was like watching and listening to a volcano in the hours leading up to an eruption. 

“All the usual rubbish”...‘uber’...‘paradigm shift’...‘3.0’...“THREE point oh?!! - you have to be kidding me!”  At this point various items of stationery went into orbit.

After I’d stopped laughing and he’d calmed down he said, “Why don’t we set up a 2.0 Skeptic blog?”

“One blog is enough to be getting on with, thank you very much” I replied.  But I could see his point. 

The name The Pebble chose for his proposed blog was inspired by the blog of the IT Skeptic.

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.

The Companies Act and IT

How often has your business committed to an initiative and made announcements in the press about it, only to find that IT hasn’t managed to get its house in order in time for you to deliver?

Hopefully not very often.

Unfortunately, that was the situation that faced the UK Minister of State for Competitiveness, Stephen Timms, last November.

Significant parts of the new UK Companies Act were due to come into force on 1st October 2008.  However, Timms was forced to announce that the starting date has been put back by 12 months to 1st October 2009 because the government IT systems at Companies House needed to implement the changes would not be ready in time.

As you might expect this did not go down very well in some sections of the business community.

Stuck in the middle with you

“Doing a podcast and singing is a bad idea.  Just do a normal blog”

“OK”

"Well I don't know why I came here tonight,
I got the feeling that something ain't right,
I'm so scared in case I'll fall off my chair,
And I'm wondering how I'll get down the stairs,
Clowns to the left of me, jokers to the right, here I am
Stuck in the middle with you"

(Stealers Wheel, 1973)

Since the holidays ended it feels like I’ve been working non-stop. Thankfully, last Friday I found some time to relax and listen to some of my favourite music.

It was great to close the doors, kick off my shoes and slump into my favourite chair.

Governance and Government

We weren’t sure whose chin hit the floor first.

“He did say 25 million, didn’t he?” asked The Pebble.

“Yip”, I replied.

We had just begun watching a news broadcast about the latest data security breach by a British government department, Her Majesty’s Revenue and Customs (HMRC).

25 million personal records, including the banking information for every family in the UK with a child under the age of 16, had been written with only password protection onto two CDs which were subsequently “lost in transit”.

The UK Prime Minister, Gordon Brown, said that the security breach was down to “Failure in implementing the proper procedures.”

He went on to explain that:

1. “Only authorised staff should have access to protectively marked information”
2. “Information must not be removed without appropriate authorisation”
3. “Encryption should be used whenever information is being sent”

Succession Planning

A company I worked for a while ago had a novel approach to managing “indispensible” staff.

“It’s better for them to leave on our terms rather than theirs,” one of the senior personnel managers enthused.  “You never know when they might leave, and it could be at the worst possible time for the company, so better to just let them go during a quiet spell”.

Well, every department has a lynch pin, a person who can deliver to clients with consistency and who can be relied upon when the chips are down.  Surely, sacking them can’t possibly be the answer?

Rolling Rocks and Landing the Catch

A couple of years ago we were invited to visit a few companies in Silicon Valley to chat about what we were up to.  It was a great trip and one of the perks was being taken to some fantastic seafood restaurants.

During one meal there was a long discussion about the problems companies have with project prioritisation in complex environments. 

One humorous comment that stuck with me was, "I don't mind rolling the rock up the hill and getting near the top only to see it roll all the way back down again.  It's rolling the rock up the hill, getting half way and having to just hold it steady that I can't stand - an occasional change of scenery would be good."

Working in IT, we’re all rolling the rock up the hill.  It tends to be the nature of the industry to load IT staff with lots of work, all of which needs to be completed in a hurry. 

It could be that we’re involved in a couple of projects, busy with procurement, testing parts of a system, fielding user queries, fault fixing, or trying to catch up on the often neglected paperwork to keep either the change board or auditors off our backs.

When it comes to scheduling our work, we could all come up with differing priorities for new tasks depending on our current workload, or how we perceive a task’s relevance.

So if a problem or failure occurs, how can we ensure that it is given the correct priority from an enterprise perspective?  If we leave it to the individual to decide the priority we cannot guarantee that we get a consistent approach to IT delivery across the enterprise. So what can be done?

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.

If IT does not alter an outcome, its role is meaningless

This evening I was doing battle with a mountain of post that would rival Everest. It wasn’t physically the same size, but I felt like it would take about the same amount of time to conquer. I was just about to set up base camp in some utility bills, when my daughter called to me to tell her a bedtime story.

“Here's a quick one.  An oyster went to a disco and pulled a muscle”, was my reply as I got up to go and see her.

“No Dad. My English teacher says a story should have a beginning, middle and an end. That was just a beginning and an end.” shouted my son from across the hallway.

That’s what we were all taught in school. Everything should have a beginning, middle and an end.

Well, story time is over and I've started thinking about how everything can be described in those terms - a beginning, middle and an end. It doesn’t matter if you are making a meal, driving a car or dealing with your mailbag - everything starts, goes through a process, and completes.

Those of us in the IT industry tend to think about IT systems as possessing these same qualities. We iteratively break down complex tasks into sub tasks, each of which accept input, perform computation, and returns results. So this concept is not new to us. But the tendency is to focus on the IT systems and how they work, rather than why the IT system is used. This internalised perspective, although understandable, is a huge mistake which hinders how IT is perceived by its clients – the business.

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.

Scoring lines in the cement

Michael Krigsman writes a great blog about the issues surrounding IT Project Failures.  I was thinking today about how IT always seems to have its reputation dragged through the dirt by the rest of the business when it comes to implementing projects.

There are always the perennial problems of going over budget, completion dates overrunning, teething problems with new systems and how the solutions deployed don’t actually fit with what the business actually wanted to see.

This started me thinking about other professions which exhibit similar traits. One which immediately sprung to mind was the house-building trade, and my experience when buying a new house...

Archaeological Digs & IT Relics

Investigating the systems architecture and infrastructure of any reasonably established complex organisation is as revealing as an archaeological dig in turning up the relics of its evolution.

There will usually be a basic proliferation of hardware and software platforms with department or task specific functionality; overlapping or parallel systems; and instances of multiple input of data, with all the potential that has for conflicting information. Superimposed upon this may be more sophisticated systems based on database technologies which have resulted from or facilitated the re-engineering of its business processes.