Keystones and Rivets

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.

Understanding Enterprise Architecture complexity

Nick Malik of Microsoft posted recently that

“For years, we've been living with Zachman and now TOGAF as commercially available EA frameworks, but honestly, they don't address the problems faced by large organizations with respect to complexity.”

This got me thinking about some of the pros, cons and limitations of the traditional frameworks used in Enterprise Architecture (EA).

This isn’t a comprehensive review but I’m going to briefly discuss three frameworks and their limitations in this blog, before I talk a little about OBASHI™ - my company’s own framework for capturing Business and IT related information.  Each framework details how information can be categorised, organised and presented to form the basis for governance and change.  The three traditional frameworks have some key differences which I’ll highlight below. 

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.

The debate about ERP

There has been a bit of a squall blowing through the IT blogosphere about the complexity of ERP systems and their value to the business.

This debate reignited following an article by Cynthia Rettig entitled The Trouble with Enterprise Software, in which she questioned the effectiveness of ERP.

Andrew McAfee  subsequently suggested that more research is required in order to come to a definitive conclusion about the value of ERP, although he believes that corporations wouldn’t continue to invest if it wasn’t providing some sort of benefit.

Thomas Otter of SAP says ERP is complex but manageable and “this stuff works”.  Vinnie Mirchandani thinks that all too often ERP forces the business to depend on expensive consultants and that only in the manufacturing sector has ERP had much of an impact.

The emergence of Workday providing On-demand Business Services over Web 2.0 has made Nick Carr think that we might be about to enter a “post-ERP era”.  Personally, I don’t see this happening.  It’s like saying that mySQL will create a post-Oracle era.  Workday may be great for some implementations, but the big spending multi-nationals are never going take the chance with their core strategic data.  It’s easier to sue SAP if it all goes wrong.

What may cause ripples in the ERP pool are systems such as thingumy, which manipulates data using completely new techniques.

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.