Keystones and Rivets

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.

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.

Cloud Computing

LUNKWILL:  Are you not as we designed you to be, the greatest, most powerful computer in all creation?
DEEP THOUGHT:  I described myself as the second greatest …Deep Thought… and such…
LUNKWILL:  Yes yes but…
DEEP THOUGHT:  …I am.
LUNKWILL:  But, but, but - this is preposterous! Are you not a greater computer than The Milliard Gargantu-Brain at Maximegalon, which can count all the atoms in a star in a millisecond?
DEEP THOUGHT:  The Milliard Gargantu-Brain, a mere abacus. Mention it not.
FOOK:  And are you not a more fiendish disputant than The Great Hyperlobic Omnicognate Neutron-Wrangler? Which can destroy -
DEEP THOUGHT:  The Great Hyperlobic Omnicognate Neutron-Wrangler can talk all four legs off an Arcturan Mega-Donkey but only I can persuade it to go for a walk afterwards. Molest me not, with this, pocket calculator stuff!
LUNKWILL:  Then what's the problem?
DEEP THOUGHT:  I speak of none, but the computer that is to come after me.

(The Hitchhiker's Guide to the Galaxy)

Nick Carr recently commented on IBM's new initiative called Project KittyHawk, which sets out to use their Blue Gene technology.  The project aspires to create a “global-scale shared computer capable of hosting the entire Internet as an application”.

There have been a range of online discussions on the back of the article as, once again, Nick Carr manages to hit more than a couple of raw nerves.

The premise of the article is that IBM Blue Gene technology is creating computers of such power that data centres can offer vast amounts of  computational power that businesses can plug into and use according to need at a particular time.

These supercomputers can emulate many individual smaller servers (virtualisation) so businesses can migrate their IT services to this new model.

Rather than data centres just offering a place to put your own servers, they can start to offer virtual servers or services, enabling new business models to be adopted.

The IBM technology is so fast that Project Kittyhawk can emulate the entire internet. 

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.

Understanding and Valuing Data Flow

My business partner, Fergus, and I were on our travels last week around the UK.

We used a couple of planes, a few trains and an automobile.

For a change, the journeys on the trains and the planes were smooth and on-time.

The car was a different matter though.

We hit a number of traffic jams that delayed us quite a bit.  The worst was on a motorway near Leeds where we sat without moving for well over an hour.  A truck had over-turned and stopped the flow of traffic.

During our fifth game of “I Spy” we got a call from The Pebble, and explained our situation.

“You know what?  That reminds me of our discussion the other day about network routing”, he said.

“The motorway is just like a cable and you are sitting there like little packets of data when a server goes down.”

I could tell he was taking a little pleasure in our predicament.

“Well, networks don’t quite work like that...”, I began to reply.  Mercifully, another call came to my rescue before I had to go into the intricacies of communication protocols between hosts.

Eventually we got going again and during the next couple of days met a few companies, each working in different industrial sectors.  A regular topic in our discussions was how data flows through and across an organisation – and more importantly, how it is documented and portrayed to non-technical stakeholders of that data.

To investigate, analyse and communicate the data flows, some of the companies had Systems Analysts who used formal Data Flow methodologies such as Yourdon/DeMarco, SSADM and Gane-Sardon.  Others had only basic Visio diagrams to try to document how applications and functions within those applications interfaced with other applications.  Some companies, however, had no documentation at all.

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”

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.

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?

Enterprise Applications and User Interfaces

Nick Carr recently made reference to an article by Khoi Vinh, Design Director at the New York Times, about “the user-unfriendliness of enterprise apps”.

Khoi made an interesting point, that “...enterprise software rarely gets critiqued the way even a US$30 piece of shareware will.”  His basic premise is that the $30 software reaches a larger audience than an enterprise application, an audience which is more vocal and that helps shape the User Interface (UI) and software’s future development.  In contrast, an enterprise application doesn’t receive the same level of feedback therefore it remains an unfriendly application.

But to me that’s like saying that because the affordable Volkswagon Golf is the most used car in Europe, with lots of feedback through the dealer network, it is easier to drive than a 6.6L V12 660bhp Lamborghini Reventón.

Trying to cross No Man's Land

The Pebble and I work well together.

But he is an Arts graduate, so I have to humour him from time to time.

This entails having to listen every so often to one of his “stories” about history or politics. 

Today, for some reason, he decided to explain why the Red Army initially collapsed during the German invasion of Russia during 1941. 

“Barbarossa”, “Lebensraum”, “OKW”,  “Timoshenko”, “Smolensk”, “Stavka”…

The Pebble often talks about interesting things but occasionally he uses too much terminology.  As is sometimes the case, after a few minutes I felt my eyes glazing over.  My mind started to drift into that strange state where you feel conscious and unconscious at the same time.  The lights were on, but there was definitely nobody home.   

His talk about matters military must have had some impact though.  Through the haze I began asking myself - when did IT last go into battle with a genuine understanding of what the business was trying to do?

When did Business and IT last plan together strategically, agree tactics, and march together with clear objectives?

How about ten years ago...?

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?

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.

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.