Keystones and Rivets

SAP and annual maintenance - a defence

Paul Wallis — Tue, 21 Apr 2009 21:54:59 +0100

If you are a regular reader of some of the popular IT industry bloggers, during the past year you will have noticed a backlash against SAP, caused in the main by its decision to increase its maintenance costs.

Two things have amazed me as the situation has unfolded. Firstly, to my mind SAP hasn’t done a very good job of defending the validity of its decision and as a result its reputation is suffering. Secondly, why have so few people placed those increased costs within the context of what SAP delivers for their enterprise?

Ah, but wait. Most of the people castigating SAP don’t actually use the software. Unlike the SAP users who they try to whip into a frenzy, their business model doesn’t rely on SAP at all!

In the past I’ve criticised SAP over issues like “business process rigidity forcing an increase in home-grown workarounds” and how “change can be difficult once the SAP concrete has been poured over a business”…but I’m batting for them this time. (I, and my company, have no business dealings of any kind with SAP)

Until about ten years ago I used to fly around the world doing IT stuff for one of the oil majors and part of my role was vendor clarification for ERP systems. Visiting new chemical manufacturing plants in places like Cilegon, Indonesia, then almost a one bar town on the edge of the jungle, was an eye-opening experience. And eye-watering – there is wildlife there that bite your body in places you don’t know you have.

Anyway, it was through scoring the ERP vendors against project criteria that I formed my opinion that, while SAP can be large, clumsy and unwieldy, it is actually a great product that can add huge value across a range of sectors...the oil companies wouldn’t buy it unless it was worth at least tens of millions annually to each of them.

SAP maintenance has been raised from 17% to 22%, a rise which came into effect on 1st Jan 2009. This was during a period where 85% of 203 SAP clients in a Forrester survey thought they weren’t getting the benefit of the existing 17% never mind 22%.

Is this a PR disaster for a good service? Or is it an increase in cost for an ongoing poor or unnecessary service? If it is a PR disaster, then should SAP base it’s business model on the mistaken perceptions of customers and pundits? Or is SAP simply capitalising on the fear and cost of changing to a competitor?

Reading the posts of regular SAP critics like Dennis Howlett, Vinnie Merchandani, Ray Wang, and many others, there are seven key themes which just keep being regurgitated:

1) Why a raise, and why to 22%?

Oracle and other competitors were already charging 22%. SAP isn’t just offering the same support at a higher price, it has increased the level of support. SAP gives 24/7 end-to-end support unlike most other vendors. Although we can question the merits of SAP’s move towards SOA, the integration of SAP with other systems is becoming tighter and tighter. And with that comes more complex support requirements.

2) We've just not seen the functionality gaps decrease and we’ve been asking for “xyz” to be added for the past 4 years.

This is a well worn argument. SAP has a development plan and it sticks to it. This will include some of the features requested by users - but usually software vendors only do this when it is in line with the strategic direction for the product.

3) We've not had value - the total support interactions divided by the cost of support makes SAP call off too expensive.

OK, but what if only a single call to SAP saved your organisation millions? Would it be worth it then? We’ve got to see the support and maintenance as an insurance policy too. Quantify the loss to the business should something go wrong and place support in that context. SAP covers sufficient areas of the business/supply chain that if support is needed the consequences of not swiftly receiving first class support can equally quickly affect a business financially and operationally, with knock on effects to business reputation and sales.

4) SAPs cost base for support has decreased with the advent of Off-shoring, Outsourcing, Knowledge Bases, Community Support, Regional User Group support etc., so why doesn’t the price of maintenance fall?

We can take the same argument about any product. Should we really look at the cost of the component parts of an item on sale and add, say, a 10% margin and only be willing to pay that price? I think not. We all like to feel we are getting a bargain and not being ripped off, but companies do have to earn a living and reinvest for the future. After all, making money is what your business, and my business, is all about. SAP is not a charity.

5) Established companies use less support than new adopters so why doesn’t the price of maintenance decrease over time?

Because of the way the sale was structured in the first place. Any ‘traditional’ software sale is based around an upfront payment and regular support payments. If you made an increase in support calls over the first few years and fewer towards the back end of the contract then sure, slap yourself on the back and consider you had the upper hand at the start. Perhaps things just average out over the length of a contract.

6) Other parts of the world seem to always be phoning for support and the profile of support requirements changes in different cultures, but there is a one price fits all mentality. Doesn’t that mean I’m subsidising another part of the world?

No. Just ensure you get your own value for money. You are not subsidising other cultures, you are allowing SAP to provide support for your organisation and you are funding the future of the product which is making your company money.

7) We’ve already bought the big ticket item and spent millions. The maintenance cost is way too high.

I think you should try to figure out if you are taking an aggressive stance for negotiating the next contract renewal, or if this was actually how you perceived the service to be. If it is perception, can I suggest you try to assess the value SAP contributes to your business. If it isn’t just a perception issue or you find SAP isn’t contributing then you should definitely change your vendor.

Equating the contribution that any IT makes to the business is very difficult to establish, so it’s no wonder that people don’t understand how to value the service SAP offers in financial terms in order to see if they are getting value for money.

In a previous blog, “Understand Value to Enable Communication”, I mentioned that a difficult problem to crack is how to value IT and quantify how this spend contributes to business performance. I quoted figures from some research that 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.

So because it has traditionally been difficult to assess the contribution IT makes to the business, it is easy to understand why the aforementioned 85% of those surveyed SAP clients thought they weren’t getting the benefit of the existing maintenance and support contract levied at 17%. In the main it is just their gut feeling.

There are natural, sensible and logical questions we should consider at this point.

How can we understand and value the contribution any part of our IT infrastructure (hardware or software) makes to the business? How can we see if we are getting value for money out of our contracts? How can we show the business in terms they understand (and that’s financial terms) why we should be paying for these contracts?

I’ll be blogging with my take on the answers to these and other questions during the next few weeks, but a short answer is that we have to understand precisely how data flows through the business.

Despite its faults, and there are plenty of blogs which highlight them, SAP's software can and does, give huge value to thousands of businesses across many business sectors.

The notion that these clients could get greater business benefit by changing to a competitor with lower maintenance fees is something other vendors will try to capitalise on, especially as SAP doesn’t seem to be doing a particularly good job of defending itself at least in public.

The sheer scale of the implementations of SAP within many multinationals give them a size and reach which perhaps gives the impression that they are complacent and aren’t too concerned about their client base. I don't know of many large software companies who never leave themselves open to criticism, and SAP certainly has its critics.  

What I would like to see, however, is that criticism made from a business standpoint. And that can only take place when it is set fairly and squarely within a business context, don't you think?

We all love lower prices but sometimes we need to make the distinction between cost, value and worth.

Next blog will be about how, if you understand precisely how data flows, you can connect silos, create clarity and minimise risk. If you would like to subscribe you’ll find the links on the right of the blog.

Auditing IT systems

Paul Wallis — Thu, 28 Aug 2008 01:46:14 +0100

“Yip, I’ve been promoted and I’m off to New York in a few weeks”, said Big D.

The other day I was chatting online with a former colleague who now works for a business process outsourcing company specialising in corporate information solutions. He told me he is going to be a new Director for the US, focussing on Strategic Solutions for the Americas.

I made the critical mistake of shouting this news down the corridor to my business partner Fergus.

“Start spreeeeading the nyoooosss, Haaam leevin’ tooodaaaaaayyy...”, he wailed.

Throughout my career, in each office or location, there has always been at least one person who was convinced, despite the reactions of their ‘audience’, that they are a good singer.

Fergus is very convinced. And very loud.

The window in my office was open. Outside, I could see squirrels throwing themselves off the oak trees.

The Pebble grimaced, and, above the racket, cried that it sounded like, “someone smothering a crow with a whoopee cushion.” Mercifully, he forced shut a couple of doors and calm was restored.

“The guys say ‘well done Big D’”, I typed back. Our chat continued.

“Thanks to all...what are you up to today...when’s the next blog coming out, what’s it going to be about?”

“I’m working on it now. It’s about systems... how traditional functional systems don’t fit with the business process view of an organisation.”

“Really? I was just in a meeting about that very subject. We take a look from the business process perspective, and it always spans lots of IT systems. The boundaries round processes are completely different to the demarcation between IT Systems...So why are you doing that one?”

I went on to explain that I’d been following a series of posts by bloggers Dennis Howlett and Francine McKenna about IT systems, auditing and the Big Four…

One of the frustrations for any IT Manager in a new job is trying to understand the wealth of IT systems and applications installed by their predecessors.

Previously I’ve described the analysis of the layers of systems deployed over time within an organisation as an “archaeological dig” through different technologies and integration techniques.

What typically happens is that managers in different departments use their budgets to put in place functional systems to make their departments more efficient in terms of manpower or speed of operation. As the business changes and technology advances, new applications are installed and interfaces are created to the legacy systems. It’s not unusual for new replacement systems to not fully implement the functionality of legacy systems – the result being that the legacy systems have not been totally decommissioned, which doesn’t help us simplify complexity.

The functional approach to IT systems has led to the creation of functional data repositories – the so called “silos of information” - which follow directly from the functional view of business operations.

Dennis Howlett recently wrote,

“I’ve long held the view that operating in functional siloes is not the best way to extract business value and hinders the ability to achieve transparency - another currently popular mantra. In my view, process solutions provide a better template for business...”

This hits the bullseye.

The thrust of Howlett’s article concerns the auditing of systems.

But what defines a system? If we look at functional IT systems in isolation we cannot audit effectively. Unless we take a process view which cuts across systems we are likely to miss areas which can lead to failures and miss key areas of risk.

Let’s take a look at a typical example of how a process cuts across the traditional system boundaries. Imagine that we want to send a mechanic out to fix a problem with a pump on a manufacturing site. Before the mechanic sets foot outside his workshop, he needs to be issued the job from the Job Scheduling system. He’ll then need to find the drawings of the pump from the CAD system. Next comes the Pump Specification Sheets from the Equipment Database, and the hook-up drawings from the Drawing Management system. He’ll need to have the spare parts allocated at the Stores from the Materials Management System or Requisition System, and finally a Permit To Work will need to be generated to let others know he is working in that area of the plant.

A failure in any one of these six systems can have an impact on fixing the problem with the pump. Only when we understand how the IT systems are used by the business and how integral they are to business processes can we assess the impact of system failure on an organisation.

In the article quoted above, Dennis makes reference to Francine McKenna, who regularly comments on the “Big 4” audit firms, regulation and globalization.

Ms McKenna believes that another large accounting firm will soon fail, due in no small part to the level of litigation brought against them because of poor auditing. In her article “When Another One Bites The Dust” she discusses a conversation with International Herald Tribune columnist and fellow audit firm critic, Jim Peterson. During 2007 Peterson wrote a blog post titled “The Big Four's Litigation Cost: A Matter of Survival” in which he discusses the demise of Anderson Consulting in the wake of Enron and the level of litigations against it already in the pipeline:

“These assumptions also make plain that the Enron-inflicted blow on Andersen was mortal. The firm's 2001 worldwide revenue was $9.3 billion. It confronted plaintiffs' lawyers claiming that the case would be the first against accountants to reach $1 billion. The crippled firm was already dealing with claims involving Baptist Hospital, Waste Management and Sunbeam, and it was about to receive the incoming bombardment of WorldCom and Qwest, among others.

So to blame Andersen's death on the Enron indictment misses the point. The firm was like a terminal patient on late-stage life support who happened to succumb to a fast-moving staph infection: Its demise was imminent, and inevitable.”

Whilst the Big Four concentrate on delivering financial audits, they must also include an assessment of, and quantify, the level of risk their clients would be exposed to if systems fail.

In the Sarbanes & Oxley (SOX) world which exists post the Enron catastrophe, the accuracy of this assessment has become critical to the survival of the auditors. Within the UK we have the Turnbull report and a new Companies Act which enforces the necessity to quantify these system risks through internal systems of control, governance and audit.

However, the problems in performing effective audits and risk assessments are only going to get worse, and there will be a rise in expensive litigations.

Here’s why...

The American Institute of Certified Public Accountants (AICPA) have a widely recognised auditing standard called SAS 70 which “represents that a service organization has been through an in-depth audit of their control objectives and control activities, which often include controls over information technology and related processes”. SAS 70 is generally applicable when an organisation receives services from a third party. Traditionally these third parties are “application service providers, bank trust departments, claims processing centers, data centers, third party administrators, or other data processing service bureaus”.

As the technology world moves on with the growth of provisions of services from “The Cloud”, third party services can become embedded within both vendor and in-house application solutions. Take, as an example, the use of Amazon’s S3 storage solutions. Amazon make it very easy for programmers to access its online storage facilities, which may prove attractive even for even the smallest of tasks when abstraction from local physical storage is desirable.

Applications which rely, even in part, on such a facility will need to be assessed by auditors in terms of risk and lack of control.

Any reliance on external web services, common in SOA deployments, will require similar assessment.

The growth of such embedded technologies takes us out of the realms of “archaeological digs” and into forensic analysis of how data flows through third party systems. If we are to properly audit a company’s reliance on IT it is essential that we have sight of how any third party assets through which the company’s data flows are managed. And we must clearly understand the controls the third party places upon the assets and the data flows.

Vinnie Merchandani makes this point in his blog post “A threat to clouds?” where he says:

“Over the weekend I had a conversation with Dennis Howlett and Francine McKenna about whether auditors are keeping up [with] newer issues coming up with SaaS and cloud computing - are the SAS 70 audits keeping up with unique multi-tenancy, virtualization, shared across customer asset issues?”

Francine McKenna’s answer:

“SAS70 issues are not getting resolved in the world of SaaS multi-tenancy and virtualized/shared compute resources.”

An assessment of third party controls can be critical. A point which won’t be lost on the Royal Bank of Scotland (RBS) after a computer, owned by one of its third party IT Service providers, was sold on eBay recently while still containing the bank account details, personal data and specimen signatures of several million RBS customers.

To be able to accurately assess risk of IT system failure, three things need to be clearly understood and easily communicable:

Which IT assets or resources support a particular business process or service - allowing the question, “Which parts of the business will be directly affected should this IT System, or part thereof, fail?” to be answered.
The value of those business processes to the company operation - allowing the question “What would be the financial impact should an IT system, or component thereof, fail?” to be answered.
How data flows between the IT Systems that enable the business services to operate - which, critically, allows an assessment to me made of “Which parts of the business will be indirectly affected should this IT asset fail?”

The complexity train has been rushing down the tracks towards the audit firms for some time. But they really haven’t had the tools to do anything about it.

A few years ago it became clear to my business partner and I that we could take the tried and tested techniques used to manage, govern and control assets within the Oil & Gas industry and apply them to Business and IT resources across any industry.

Those of you familiar with my company, Stroma Software (UK), or this blog, will have noticed the occasional reference in previous posts to our enterprise software tool, Stroma.

IT system auditing is just one of the ways in which Stroma can be applied. The three key enablers described above, as well as many others, were designed into Stroma at an early stage. Because Stroma captures the data associated with each asset and models the relationship between business and IT assets using a methodology called OBASHI: audits become easier; business and IT (mis)alignment can literally be seen pictorially; communication is simplified; and the financial contribution of IT to the business can be quantified.

It is only when tools such as Stroma are used to map out, document and understand how IT resources underpin business services, and how data flows across these functional IT systems in support of business processes, that we will be able to apply proper governance, assess and manage risk proactively, and audit effectively.

And at that point we will all be singing in tune.

IT (still) exists for one reason

Paul Wallis — Wed, 11 Jun 2008 01:24:37 +0100

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 Skeptic (Rob Englund) is a blogger I’ve subscribed to for some time. He ‘takes a critical look at IT’s absurdities, especially those relating to ITIL.’

As the name suggests he isn’t one for accepting anything IT-related at face value, and he regularly takes aim at dubious claims by analysts and marketers through his ‘crap factoid alerts’. Here is a great example.

The other day he suggested that perhaps IT should change its name and call itself ‘Business Improvement and Information’. He was keen to add ‘Engineering’ somewhere as well but decided it would be a bit ponderous.

His reasoning is based on an article in IT Week, an interview with Benoit Laclau of the French electricity company EDF. During March 2006 EDF reorganised and changed the name of its IT department to “Business Improvement and Technology”. In addition to providing a clear split between Op-ex and Cap-ex, the reorganisation reduced the conflict between day-to-day operations and project priorities. Interestingly, rather than developing the business and project management skills of its IT personnel, EDF has opted to take people from the business and enhance their IT and project management knowledge. Having had an initial “reluctance from business people to join what they regarded as an IT department in disguise” they appear to have now got buy-in from the business, and staff satisfaction indicators have shown that the name change has been a success.

The Skeptic’s take is

“Brilliant.

But still fixated on the technology. In this millenium technology is not what IT does. Technology is one enabler to what IT does (process frameworks are another). IT does information engineering.”

You may have read in some of my earlier posts some of the analogies I make with engineering disciplines when describing IT, and so it may come as a surprise that I disagree with Rob wanting to add “Engineering” onto his “Business Improvement and Information (BII)” renaming of IT.

I disagree because, in the same way as he believes that EDF’s rename is too fixated on the technology, for me Rob’s “engineering” is still too fixated on the nuts and bolts – how the assets are tied together.

Rather, I think we need to consider why the assets exist. Here is an example, which demonstrates the point:

Every so often my company’s financial expert, Stuart, phones my business partner, Fergus, because he wants to do a bit of finance work and he needs Fergus to send him something so he can continue.

Usually the work will entail dealing with some arcane accounting procedure that only a qualified professional can understand. The same sort of thing often happens with lawyers. The workings of their world are often a mystery to us, just as the IT world is usually a mystery to them.

I answer Stuart’s calls occasionally and he usually ends the conversation by saying something like, “...ok, when you find it fire it over and I’ll work it out and send back the results.”

At that point Fergus or I will take a look at a document or a spreadsheet, find the numbers he requires, input them into an email and then send it to him.

But in a complex accounting context the numbers usually mean little to us, because we don’t have the level of knowledge required to make useful sense of them. To us the numbers are just data.

Once we have discovered and recognised the correct data we use a keyboard to transfer the data into a computer, then we hit the email ‘send’ button. The data flows, through various pieces of hardware and cabling, (it may bounce off a satellite too), until it reaches Stuart’s computer.

Stuart reads the data and, applying his professional knowledge, adds it to a calculation, enters it in a spreadsheet or makes some other use of it which is valuable to the business. The data is put in context and becomes useful business information.

In the above example, Fergus and I can be considered as business assets along with the PCs, hardware, cables and satellites. The role of the assets is to enable the data to flow to where it is needed.

So if we are to rename the IT Dept, how about changing it to “Business Improvement and Data Flow Control”?

Let’s not use “Engineering” - IT can be engineered to optimise the flow of data but improvement in the performance of the business depends on how the data is used by people applying their knowledge.

IT exists for one reason: to manage the flow of data between business assets.

Blog Award nomination - help!

Paul Wallis — Tue, 27 May 2008 05:40:51 +0100

Computer Weekly UK is running the 2008 UK IT blog awards and my colleagues suggested I try to get nominated - an opportunity I've decided to dive into feet first.

Your comments and emails over the past few months have been very encouraging and I hope I can keep writing articles that continue to grab your interest.

If you've enjoyed my posts, may I invite you to email the magazine at

ITblogs@computerweekly.com

with a message along the lines of

"For the CIO/IT Director award I'd like to nominate Paul Wallis, CTO, Stroma Software, for his blog www.KeystonesAndRivets.com"

The closing date for nominations is the 31st May, the awards page can be found here

Thanks for your attention and support.

The HP consolidation

Paul Wallis — Tue, 27 May 2008 05:38:28 +0100

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.

Currently, HP have reduced the number of data centres by 65%, with a target of 95% completion by end Q3 this financial year, with an application portfolio count already down by a similar 65%.

The new data centres should be a showcase for HP’s data centre technology – Servers, Blades, Storage solutions, and not least the lights out management software which will be used to remotely monitor and control the hardware and infrastructure. HP CEO Mark Hurd is quoted as saying that,

"These facilities will serve as a model of the next-generation data center that HP believes represents the future of enterprise computing."

The project sets out to reduce IT spend by $1bn over the next few years, and improve environmental performance by reducing energy costs by 25%.

The project will also reduce employee numbers by 15,300, in line with HP’s restructuring plans, although acquiring EDS has just put another 130,000 employees back on the books.

As an outsider looking in, it would appear that this project has only managed to get this far by a CIO, CFO and CEO working closely together to force change aggressively through a business– not a partnership we usually see working well.

In fact, the opposite can often be the norm, and even the notion of kicking off a consolidation project less than a tenth of the size undertaken by HP would fill most IT managers with dread. As Eric Doyle says

"The reliance of corporates on their computer networks has increased massively in recent years and so has the server count. The army of staff required to maintain these critical systems, together with new requirements such as data sharing with business partners and mobile working for employees, is driving costs and complexity through the roof. Current research by market analyst Quocirca, in a report called Datacentre Asset Planning, highlights the problem.

The report, taken from a survey of over 300 senior IT managers, shows that 28 per cent do not know the exact number of servers they have, 22 per cent say it could take up to a day to find a server that has gone down, and another 20 per cent say it would take longer than that. With office space at a premium, the need to consolidate as much of the server population is obvious."

If these findings were presented to anyone outside the IT profession they would be greeted with incredulity. If the servers can’t even be located, how on earth can IT understand how the assets are being used by the business? And how can the business rely on IT to work for its benefit?

The problem is that IT has never been fully documented. Which means that ‘the big picture’ of IT’s relationship with the business has never been created.

As I said in a post last year “I’ve always found it extraordinary that some organisations will often spend, in one fell swoop, tens of millions on IT projects when they cannot see ‘the big picture’ of how business and IT interact.”

Which is one of the reasons why my company has spent the last few years developing an enterprise software to capture the business and IT relationship once, model the relationship, and create the long sought after ‘big picture’.

Regardless of how forceful the push to drive consolidation, to effectively consolidate you must know what you have and how it is used by the business, otherwise you can end up with the correct number of wrong applications.

Understanding SOA

Paul Wallis — Mon, 28 Apr 2008 20:01:34 +0100

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.

Let’s start by looking at what the term Service Oriented Architecture actually means.

The original definition of the word “architecture” can be described as “the art and science of designing and constructing physical structures”. Typically we associate the word “architecture” with the style of buildings, be it the Art Deco style of the Chrysler Building in New York, the modernist formalism of the Bank of China Tower in Hong Kong, or the grand scale of the gothic Milan Cathedral.

Recently the IT industry has used the term Architecture more and more frequently to describe how building blocks of hardware, software and interface protocols can be put together to create systems. The best recent description of its usage that I have seen described Architecture as:

“a subjective mapping from a human perspective (that of the user in the case of abstract or physical artifacts) to the elements or components of some kind of structure or system, which preserves the relationships among the elements or components.”

When it comes to Service Oriented Architecture (SOA), the term means designing a system where each system component provides access to its computational or business resources as a service to other components.

By way of explanation, let’s say that we have a simplified system which receives an order, generates an invoice and faxes it to the purchaser. The workflow of that function can be broken down into four distinct services:

1) Stock availability and pricing service
2) Order creation service
3) Document creation service
4) Faxing service

The theory is that by creating these distinct, separate and self contained services for each of the components we gain greater flexibility. Each of these services could be called from other business functions allowing re-use in subsequent areas of the business.

For example, the business could offer potential clients access to its stock availability and pricing information rather than utilising its own sales staff to process queries. Or it could expand the faxing service to cover email without changes to multiple larger systems - saving money, time and resources.

That, put very simply, forms the basis of all SOA. Those of you familiar with software development will recognise the re-use advantages of this approach which has been the main-stay of functional and object oriented design for many years.

So if this concept of re-use is not new, why all the hype surrounding SOA?

Although the concept is not new, software re-use traditionally required the code to be “tightly coupled”, meaning that the programmers had to understand how both the new code and the re-usable code could be linked together to create an interface which tied them explicitly together. Vendors are now trying to promote the technology, tools and standards that have been developed to allow services to be “loosely coupled” with each other, reducing the complexity of integrating services together. To understand how this works we need to look at how the service industries work in the real world.

Over the past few decades we have seen a growth in the service industry sector, driven partly by economic constraints. Companies have increasingly analysed their strengths and been concentrating on their core expertise, outsourcing those functions that they see as non-core and awarding contracts to companies to service those contracts. Remember in the 1980’s when the telephone sanitiser companies had the contract for wiping telephone handsets, or in the 1990’s when plant maintenance companies came in to water the peace lilies in the foyer?

Usually, each of these contracts would have an associated cost negotiated before the contract was awarded, and was subject to procurement rigours for value for money. They would also of had predefined deliverables and be monitored to ensure the service matched those promised. Finally, each contract commonly had a point of contact for efficient communication with that service organisation.

By building similar capabilities into SOA, the IT industry now has a way of creating re-usable services which can be used by third parties seeking “buy not build” functionality for their applications or for the support of their business functions. By implementing a standard contract approach into the implementation of services, they can be used without a detailed knowledge of bespoke interface considerations. As such, it is relatively easy to decouple from one service provider and move to another, hence the term “loosely coupled” as opposed to “tightly coupled”.

As well as adhering to a contract model and having the ability to be loosely coupled, services generally also allow abstraction, reusability, autonomy, statelessness, discoverability, and composability – depending on the specification and design brief of the service.

ARCHITECTURE
When an architect is commissioned to design a building his first requirement is a design brief. As well as understanding the style of the building, he must also gain knowledge of budget, environmental considerations, location specific requirements, building usage, decision authority, material availability, reasons for embarking on the project etc.

The answers to these questions will determine how the building will look and feel. It will also, however, determine the tools and equipment needed to undertake the task, the best approach to take, what skills are required to deliver the project, the scope of work, bill of materials and project timescales.

The same is true of SOA. Just as there is more than one way to design and construct a building, and more than one set of tools which can be used, so with SOA there are many technologies and methodologies which can be used to deliver an SOA solution and all have different advantages and disadvantages.

In the construction industry there are some people who prefer sustainable hardwood construction rather than metal. Within the proponents of metal construction, there are some which prefer aluminium to steel. Within the advocates of steel, some prefer rivets to welding.

Similarly, in the SOA community some advocates prefer SOAP/web services to CORBA, DCOM, REST, RPC or JINI. Some prefer complex messaging backbones and others simple state protocol transmissions. Some prefer closely coupled, others loosely coupled. Some use a top-down approach to architectural design, whilst others suggest bottom up.

Does it matter? Yes it does.

Which is best? Unfortunately that depends on your design brief.

SOA ARCHITECTURE PRINCIPLES
There are some well defined specific SOA architectural principles governing service design and service definition, namely:

Service encapsulation - Many web-services are consolidated to be used under the SOA Architecture. Often such services have not been planned to be under SOA.
Service loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other
Service contract - Services adhere to a communications agreement, as defined collectively by one or more service description documents
Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world
Service reusability - Logic is divided into services with the intention of promoting reuse
Service composability - Collections of services can be coordinated and assembled to form composite services
Service autonomy – Services have control over the logic they encapsulate
Service optimization – All else equal, high-quality services are generally considered preferable to low-quality ones
Service discoverability – Services are designed to be outwardly descriptive so that they can be found and accessed via available discovery mechanisms such as service repositories or directories

Further information about these principles can be found here.

There are two approaches to Service Orientated Modelling – “top-down” and “bottom-up”. The top-down approach starts with analysis at a business process level to evaluate re-engineering and workflow, ensuring that service delivery matches business requirements. The “bottom-up” approach starts in the IT stack, analysing systems and system functionality, before existing systems are wrapped using Web services to create a service layer.

In reality, despite much debate over a number of years, success will not come from “top-down” OR “bottom-up”. It is only a mixture of the two which will work effectively, a view shared by Neil Ward-Dutton in his recent post “Which comes first: process or service?”

Let’s take a look at a real life example:

Oncology Hematology Associates (OHA) is a company based in Southwest Indiana, USA, and provides coordinated patient-centred plan for cancer diagnosis and treatment. They have about 100 employees including physicians, nurses and other healthcare professionals.

Before obtaining a little help from Microsoft, OHA had many manual paper based business processes. The nature of their cancer care business meant dealing closely with third party companies, such as testing labs, with much of the information being faxed back and forth.

OHA wanted to find a way to integrate its multiple business processes to improve efficiency, support collaboration, serve patients better, and increase profitability – clear business reasons for adopting SOA.

So with two developers they set about building web services onto their six medical industry preparatory backend systems. They adopted an iterative approach – exposing services through a composition layer to give access to a broad variety of platforms – and integrated all the faxing systems.

They integrated external partners into the systems, such as testing labs, to consume their services. The integration was done with a perspective of maintaining business value rather than redesigning the whole IT architecture.

Creating web services has enabled them to add a new range of medical care products to their business portfolio, obtain results in days rather than weeks, provide better communications amongst physicians and much more. In short, they have increased productivity, increased business opportunity, reduced operating costs and enabled better governance and compliance.

You can read more about their case study here.

TECHNOLOGIES
At this point I considered talking about the tools and technologies that are available to create SOA services. However, this article is really concentrating on the principles of SOA, so I’ll discuss the tools and technologies in more detail in a future blog. Here is a list of some of them with links to their definitions:

Web Services, SOAP, REST, RPC, DCOM, CORBA, BPEL, JINI , WSDL and WCF

What I would say is that it is hardly surprising that there has not been widespread adoption of SOA. Many IT people, never mind the business, must be confused by the proliferation of marketing initiatives, acronyms, conferences etc. relating to the topic. The latest ingredients added to the mix are Web Oriented Architecture (WOA) and Platform Oriented Architecture (POA). Did you know, that SOA + POA + WOA = SOA?

On page 27 of the current issue of Information Age (UK) there is an advert for the SOA & Application Development and Integration Summit 2008 which states that “The question is no longer ‘Should we go SOA?’, its ‘How do we measure the value?’” and that “SOA is changing everything.”

To me these are bold statements to make, considering there has been, in the words of one prominent UK CIO, “no truly successful SOA application”.

The question of how we measure SOA value is key, but without a sound and rational business case those metrics can’t be put in place. Mechanisms to track the contribution SOA makes to the business post-implementation are extremely difficult to establish, but nigh on impossible if it was a technology solution that has been sold to the business. In her post “Looking for SOA success stories”, Anne Thomas Manes identifies this problem when she says:

“I've talked to many companies that have implemented stunningly beautiful SOA infrastructures that support managed communications using virtualized proxies and dynamic bindings. They've deployed the best technology the industry has to offer -- including registries, repositories, SOA management, XML gateways, and even the occasional ESB. Many have set up knowledge bases, best practices, guidance frameworks, and governance processes. And yet these SOA initiatives invariably stall out. The techies just can't sell SOA to the business. They have yet to demonstrate how all this infrastructure yields any business value.”

SERVICE DISCOVERY
When services have been designed to be used together within a single organisation the architect may elect to explicitly link the known services together. Although this is the easiest way to connect services, it is not always possible – especially between geographically (or domain) disparate systems.

Services which have been created for consumption by third parties also need a way to be discovered, so they can be used by third parties.

In order to facilitate this, mechanisms have been introduced to allow services to be discovered across networks, such as the internet. There are numerous protocols which have been created for this and their use depends on the technology used to create the service. Three noteworthy examples are:

Universal Description, Discovery and Integration (UDDI) which provides a way for Web Services to list themselves as discoverable on the internet. Businesses who have created web services can register them within a UDDI, which is split into three central directories:

White Pages — address, contact, and known identifiers

Yellow Pages — industrial categorizations based on standard taxonomies

Green Pages — technical information about services exposed by the business

JINI from Sun Microsystems can be used to advertise and discover Java based Web Services. One limitation with JINI is that it uses multicasts to advertise and discover and as such can only really be used within a local network.

SLP has been used for many years to advertise network resources such as printers and file shares. SLP can also be used to advertise web services, but does not have a facility to maintain a repository of services with descriptions, unlike UDDI.

IDENTITY MANAGEMENT
One of the challenges to be overcome for successful SOA deployment between third parties is that of identity management. When services are made available for use online, it is fair to assume that a payment mechanism will be built into the service contract description, or that sensitive information could be passed between the services.

In order for this charging mechanism to work effectively there is a requirement for an assurance that whoever consumes the service is the same entity that contracted the service. If a third party can assume the identity of the service requestor or the service provider (or both) there is the potential for serious security breaches. Once a transaction over the service begins, information about that transaction needs to be maintained at both ends of the transaction. When a connection between the service requestor and the service provider is terminated and needs to be re-established, protocols must be adopted to ensure the state of the transaction is not lost.

The problem identity management introduces is a need for tightly bound security on loosely bound services, and such tight security can defeat the purpose entirely of having loosely bound services. There are a number of security standards being driven forward to try to address these issues and an article by Eric Roch on IT Toolbox, which was written to specifically cover the security risks of SOA, is an excellent place to find out more background information on SOA security measures.

CONCLUSION
In its simplest form SOA can be used to put service wrappers around existing functionality to create a re-usable software infrastructure, which can help businesses move quickly in changing market conditions. It can simplify integration of existing legacy systems and help align IT services with business operations, as can be seen in the real-world example given above. SOA, when implemented on a small scale, can give benefits that can be easily demonstrated to the business.

But SOA can also be rolled out as an architectural vision across the enterprise, and many large software vendors and integrators are positioning themselves with products to try and achieve this vision.

As vendors try to differentiate themselves in the market place we see, yet again, the emergence of new abbreviations and technology-based terminology. Although this stimulates and progresses a technological debate within the IT industry, not for the first time a perception has grown in the business community that IT is overhyping a new technology.

The nature of IT is that it is continually evolving, and trying to sell a long term IT vision to the business has always been a stumbling block to adoption of new technologies. For SOA to succeed, the business has to believe that IT, having committed to an SOA strategy, will not be re-seduced by the finer points of some new technology.

Joe McKendrick at ZDNet recently wrote that:

“The business side needs to be educated that SOA is a goal worthy of shooting for. And key performance indicators need to be tied into SOA efforts. But SOA is a journey, not a destination, and organizations that expect overnight benefits to the business are bound to be disappointed.”

Even though SOA could generate huge flexibility and long term savings, there is an associated increased cost to large SOA implementations over and above non-SOA solutions.

At a time of short-term financial planning, entering a long-term technology relationship can be a step too far for the business, and I fear one of the first budgets to be cut will be SOA.

The Companies Act and IT

Paul Wallis — Wed, 19 Mar 2008 02:23:40 +0000

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.

Nestled within the Act is the UK’s version of the American Sarbanes-Oxley Act which, as with the US version, places extra legal responsibilities on company directors.

Under the existing UK Companies Act, company directors have a duty to run the company in the interests of the business, and in the interests of the owners of the business – the stakeholders. But the new Act redefines those stakeholders are expanded to cover not only the shareholders, but to also include company employees, the environment, the local community, suppliers, customers and others.

Section 172 of the new Companies Act states:

“A director of a company must act in the way he considers, in good faith, would be most likely to promote the success of the company for the benefit of its members as a whole, and in doing so have regard (amongst other matters) to —

(a) the likely consequences of any decision in the long term,

(b) the interests of the company’s employees,

(c) the need to foster the company’s business relationships with suppliers, customers and others,

(d) the impact of the company’s operations on the community and the
environment,

(e) the desirability of the company maintaining a reputation for high standards of business conduct, and

(f) the need to act fairly as between members of the company.”

In tandem, the Act now allows for a stakeholder to pursue a legal action, not solely with the company itself, but with an individual director where they feel there has been some form of negligence, or breach of duty. The result of such legal action can be a custodial term.

So come October 2009, a customer, supplier, shareholder, member of the local community or employee of a business, can serve legal proceedings on an individual director, the outcome of which can result in the director going to jail. All of which helps to focus the mind somewhat.

So how does this affect IT?

When the last iteration of the Companies Act was performed in 1985 electronic communications were not as widespread as they are today. The Act now brings these into play and, in the very near future, directors will be required to ensure that the appropriate IT systems are in place to store and retrieve documents and data. As a result, business continuity and risk management move up the business agenda.

Does the director in charge of IT know the impact on the business should a problem occur with a particular piece of infrastructure? Can he value the contribution made to the business from each application? Recent statistics would suggest this is not the case.

If we take new projects (public and private) into consideration, we need only read the headlines on the covers of “Computer Weekly” or “Computing” every week to discover the latest multi-million pound project which has been abandoned or gone massively over budget. Under the terms of the new Companies Act the director responsible for the failure could be prosecuted.

In previous posts I’ve discussed how business and IT can begin to start a meaningful dialogue. As the implications of the Act and knowledge of the new responsibilities of directors become more widespread we could begin to see a change in how the business engages with IT.

IT has a narrow window of opportunity to demonstrate that it has its house in order and can deliver with high levels of governance. If it can’t deliver, the engagement model we hoped for could slip from our grasp.

Cloud Computing

Paul Wallis — Thu, 21 Feb 2008 22:02:00 +0000

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.

In the past, there have been two ways of creating a supercomputer. Firstly, there is the Blue Gene style approach, which creates a massive computer with thousands (or hundreds of thousands) of CPUs. The other approach, as adopted by Google, is to take hundreds of thousands of small, low cost, computers and hook them together in a “cluster” in such a way that they all work together as one large computer.

Basically, supercomputers have many processors plugged into a single machine, sharing common memory and I/O, while clusters are made up of many smaller machines, each of which contain a fewer number of processors with each machine having it's own local memory and I/O.

There have always been advocates on both sides of the fence, and Nick Carr's article has done a fine job of stirring them into action again - but this time it has become clear that the concept of “The Cloud” is gaining momentum, a concept whose origins lie in clustering and grid computing.

John Willis seeks to 'demystify' clouds and received some interesting comments. James Urquhart is an advocate of cloud computing and thinks that, as with any disruptive change, some people are in denial about The Cloud. He has responded to some criticism of his opinions. Bob Lewis, one of Urquhart's “deniers” has written a few posts on the subject and offers a space for discussion of Nick Carr's arguments.

In order to discuss some of the issues surrounding The Cloud concept, I think it is important to place it in historical context. Looking at the Cloud's forerunners, and the problems they encountered, gives us the reference points to guide us through the challenges it needs to overcome before it is adopted.

In the past computers were clustered together to form a single larger computer. This was a technique common to the industry, and used by many IT departments. The technique allowed you to configure computers to talk with each other using specially designed protocols to balance the computational load across the machines. As a user, you didn't care about which CPU ran your program, and the cluster management software ensured that the “best” CPU at that time was used to run the code.

In the early 1990s Ian Foster and Carl Kesselman came up with a new concept of “The Grid”. The analogy used was of the electricity grid where users could plug into the grid and use a metered utility service. If companies don't have their own powers stations, but rather access a third party electricity supply, why can't the same apply to computing resources? Plug into a grid of computers and pay for what you use.

Grid computing expands the techniques of clustering where multiple independent clusters act like a grid due to their nature of not being located in a single domain.

A key to efficient cluster management was engineering where the data was held, known as “data residency”. The computers in the cluster were usually physically connected to the disks holding the data, meaning that the CPUs could quickly perform I/O to fetch, process and output the data.

One of the hurdles that had to be jumped with the move from clustering to grid was data residency. Because of the distributed nature of the Grid the computational nodes could be situated anywhere in the world. It was fine having all that CPU power available, but the data on which the CPU performed its operations could be thousands of miles away, causing a delay (latency) between data fetch and execution. CPUs need to be fed and watered with different volumes of data depending on the tasks they are processing. Running a data intensive process with disparate data sources can create a bottleneck in the I/O, causing the CPU to run inefficiently, and affecting economic viability.

Storage management, security provisioning and data movement became the nuts to be cracked in order for grid to succeed. A toolkit, called Globus, was created to solve these issues, but the infrastructure hardware available still has not progressed to a level where true grid computing can be wholly achieved.

But, more important than these technical limitations, was the lack of business buy in. The nature of Grid/Cloud computing means a business has to migrate its applications and data to a third party solution. This creates huge barriers to the uptake.

In 2002 I had many long conversations with the European grid specialist for the leading vendor of grid solutions. He was tasked with gaining traction for the grid concept with the large financial institutions and, although his company had the computational resource needed to process the transactions from many banks, his company could not convince them to make the change.

Each financial institution needed to know that the grid company understood their business, not just the portfolio of applications they ran and the infrastructure they ran upon. This was critical to them. They needed to know that whoever supported their systems knew exactly what the effect of any change could potentially make to their shareholders.

The other bridge that had to be crossed was that of data security and confidentiality. For many businesses their data is the most sensitive, business critical thing they possess. To hand this over to a third party was simply not going to happen. Banks were happy to outsource part of their services, but wanted to be in control of the hardware and software - basically using the outsourcer as an agency for staff.

Traditionally, banks do not like to take risks. In recent years, as the market sector has consolidated and they have had to become more competitive, they have experimented outwith their usual lending practice, only to be bitten by sub-prime lending. Would they really risk moving to a totally outsourced IT solution under today's technological conditions?

Taking grid further into the service offering, is “The Cloud”. This takes the concepts of grid computing and wraps it up in a service offered by data centres. The most high profile of the new “cloud” services is Amazons S3 (Simple Storage Service) third party storage solution. Amazon's solution provides developers with a web service to store data. Any amount of data can be read, written or deleted on a pay per use basis.

EMC plans to offer a rival data service. EMCs solution creates a global network of data centres each with massive storage capabilities. They take the approach that no-one can afford to place all their data in one place, so data is distributed around the globe. Their cloud will monitor data usage, and it automatically shunts data around to load-balance data requests and internet traffic, being self tuning to automatically react to surges in demand.

However, the recent problems at Amazon S3, which suffered a “massive” outage at the end of last week, has only served to highlight the risks involved with adopting third party solutions.

So is The Cloud a reality? In my opinion we're not yet there with the technology nor the economics required to make it all hang together.

In 2003 the late Jim Gray published a paper on Distributed Computing Economics:

Computing economics are changing. Today there is rough price parity between (1) one database access, (2) ten bytes of network traffic, (3) 100,000 instructions, (4) 10 bytes of disk storage, and (5) a megabyte of disk bandwidth. This has implications for how one structures Internet-scale distributed computing: one puts computing as close to the data as possible in order to avoid expensive network traffic.

The recurrent theme of this analysis is that “On Demand” computing is only economical for very cpu-intensive (100,000 instructions per byte or a cpu-day-per gigabyte of network traffic) applications. Pre-provisioned computing is likely to be more economical for most applications - especially data-intensive ones.

If telecom prices drop faster than Moore's law, the analysis fails. If telecom prices drop slower than Moore's law, the analysis becomes stronger.

When Jim published this paper the fastest Supercomputers were operating at a speed of 36 TFLOPS. A new Blue Gene/Q is planned for 2010-2012 which will operate at 10,000 TFLOPS, out stripping Moore's law by a factor of 10. Telecom prices have fallen and bandwidth has increased, but more slowly than processing power, leaving the economics worse than in 2003.

I'm sure that advances will appear over the coming years to bring us closer, but at the moment there are too many issues and costs with network traffic and data movements to allow it to happen for all but select processor intensive applications, such as image rendering and finite modelling.

There has been talk of a two tier internet where businesses pay for a particular Quality of Service, and this will almost certainly need to happen for The Cloud to become a reality. Internet infrastructure will need to be upgraded, newer faster technologies will need to be created to ensure data clouds speak to supercomputer clouds with the efficiency to keep the CPUs working. This will push the telecoms costs higher rather than bringing them in line with Moore's Law, making the economics less viable.

Then comes the problem of selling to the business. Many routine tasks which are not processor intensive and time critical are the most likely candidates to be migrated to cloud computing, yet these are the least economical to be transferred to that architecture. Recently we've seen the London Stock Exchange fail, undersea data cables cut in the Gulf, espionage in Lithuania and the failure of the most modern and well-known data farm at Amazon.

In such a climate it will require asking the business to take a leap of faith to find solid footing in the cloud for mission critical applications.

And that is never a good way to sell to the business.

If you enjoyed this post you might like these similar posts about SOA, Governance, CMDB, EA and ERP.

Stuck in the middle with you

Paul Wallis — Wed, 30 Jan 2008 23:51:48 +0000

“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.

What wasn’t so good after a hard day at the office was an unexpected attack by my kids using a sneaky pincer movement.

After ten minutes of hand to hand fighting I managed to beat them off with some heavy artillery from Black Sabbath, and then a volley of Prog Rock from King Crimson forced a full retreat.

At last I could close my eyes and dream of going back to the tranquillity of the Scottish Highlands.

I’d been in the heart of the Highlands a few months earlier attending a day of seminars about Product Lifecycle Management. The lure of great food served amidst spectacular scenery had nothing to do with my decision to attend the conference.

The central theme of the event was how to improve customer satisfaction with your software product. Unsurprisingly, a great deal of time was devoted to the role of the Product Development Manager, the person who acts as the interface between the customers and supplier.

The Product Development Manager (PDM) delivers a product to market and reviews and revises the product throughout its lifecycle. The PDM canvasses the customers' opinions on current and future products and sets a roadmap for the product’s development.

But as well as being client facing, the PDM has to be embedded within the business and understand the economic and budgetary requirements for the product. How much will the developments cost; what is the forecasted return on investment; how can the product be benchmarked against competitors? etc.

During the afternoon break, I spotted a former colleague across the room. He had been the long suffering IT Service Delivery Manager I liased with in one of my previous jobs. Poor John (not his real name) had been tasked with managing the IT delivery to the business, a post which commanded a few million pounds budget and one which he initially accepted with a great deal of enthusiasm.

But after just over a year, this otherwise competent manager had left the post, and the company, having been unable to gain the acceptance of the IT department. He had failed to deliver to the business the roadmap of change needed to match the company’s strategic goals.

What had caused this to happen?

Rather than rising through the ranks of the IT department and being promoted to the post from within the IT organisation, John had been drafted into the IT role from elsewhere in the organisation and senior personnel within IT couldn’t accept him as their “superior”.

John was put into the role by the business because they saw he had the right business skills for the job. But John’s skills were not valued within the IT department and because he was not a “techie” he was seen as a second-class citizen.

Without the support of his staff, he found he couldn’t translate the demands from the business onto a series of aligned deliverable projects.

In actual fact, the IT department took advantage to promote its own agenda, the business lost confidence and IT Service Delivery failed. John started to dread the monthly inter-departmental management meetings which left him exposed, nervous and wondering why he was trying to help an IT department which clearly didn’t want to be helped. He felt stuck in the middle between the demands of business and the failure of IT to recognise he was there to help.

So he resigned, and left the organisation.

Turning my attention back to the seminars, what came through loud and clear was that the PDM role is, actually, pivotal to the success of the business.

Without a good PDM there can be a mis-alignment between customer expectations and customer experience, which does not make for a successful long-term business strategy.

The PDM must be trusted by the business to be the broker between supply and demand, sitting as the linchpin between the product and its customers.

Sounds increasingly like the role of the IT Service Delivery Manager !

And talking of sounds, I’m back home again and I think the kids are about to resume hostilities with a salvo of Gwen Stefani…

Understanding and Valuing Data Flow

Paul Wallis — Tue, 11 Dec 2007 02:05:17 +0000

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.

A common theme in all of the companies we visited was an inability to relate the data flows to the physical IT assets which made the data flow possible. On the other side of the IT business divide, another common theme was the inability to see how these data flows were used by business processes to perform day to day operations for the business.

But these inabilities are not a surprise. The formal methods of designing and documenting data flows only consider the application layer of the IT stack and how these applications interact – and this, I feel, is their weakness when we try to communicate the importance of data flows to the wider (business) community...

This may get a little technical, but in this post I will scratch the surface of some of the formal methods used to capture and portray data flows. One thing to bear in mind is how these documents can be used to portray information to the business rather than being solely used by an IT department. I take the view that if we are going to the expense of spending time and effort in analysing and creating these diagrams, we should consider how we can get the most benefit from them.

So, let’s take a look at how data might flow along a supply chain as an example of how these methodologies portray data flow.

Imagine we have some sales people out on the road using laptops to take orders for some products. They use a bespoke application which, wirelessly, gets updated with the latest products and prices and forwards any orders to the head office for processing. At the Head Office, the orders are held in a SQL database which triggers an alert to the Supply department.

The Supply department fulfils the order and updates the SQL server that the order has been dispatched to the customer, in turn triggering a notification to the Accounts department. The Accounts department have their own HP server running Windows Server 2003 which processes completed orders to generate an invoice using an invoice generation function of the XYZAccounts package.

Obviously this is a much simplified example, but it will serve the purpose of describing the formal (and informal) methodologies for documenting and portraying data flow.

Pen and Paper

This remains the most common approach to data flow mapping.

Most organisations, and the professionals within them, start with the simple pen and paper approach.

As and when the IT department manage to get some free time to finish the documentation, more formal documentation can occur. Unfortunately, in many cases this simply doesn’t happen, and the pad of paper containing the documentation gets used for other meetings’ notes and is eventually lost or discarded.

The picture to the right shows a typical example of such documentation.

Yourdon/DeMarco

Edward Yourdon and Tom DeMarco developed a structured analysis methodology involving Data Flow Diagrams which become the methodology of choice in the 1980s, and was widely adopted by the Systems Analyst community.

The process of creating the diagrams involves creating a Context Diagram that details the external influences (entities) which exist outside of the process (or system) being analysed, with the analysed process being shown as a single process. As it’s name suggests, the Context Diagram shows the environment and major interfaces external to the analysis.

The process is then broken down into smaller component parts with data flows being itemised between the components. Further diagrams are then created for each of these components, a technique which is repeated until the only components being modelled are at sufficient detail to support a specification document.

One of the reasons Yourdon/DeMarco is not used today to the extent it was in the 1980’s and 1990’s is the perception that analysing or designing systems in this way could lead to systems centered around disjointed data files and “silos” of data. Analysts started to move towards more database centric methods of design, analysing how data is captured and re-used rather than how it is stored during a functional process.

SSADM

Structured Systems Analysis and Design Methodology was developed as a set of standards during the 1980s and took a foot-hold within government projects within the UK. Indeed, SSADM is now a registered trademark of the UK Government.

Rather than just concentrating on data flow, SSADM includes three main techniques covering physical design, logical process design and logical data design.

The logical data modelling & design focuses on analysing what data the system needs, and creating logical definitions (entities) of that data. The relationships between these entities is modelled to document the associations which exist between different types of data.

Data flow modelling for logical process design follows closely the approach taken by Yourdon/DeMarco, where the system is broken down into component parts and the entities from the logical data model are documented with the data flows to show which data is being passed between system components.

The physical design concentrates on how the logical and data flow models are mapped into program design. It considers how the system will be implemented to assess the requirements for mapping the logical structures to the physical medium in which the system will be modelled. An example of this would be the physical type of database a system will use, the stored processes that will be used to update and insert data and how the various functions of the program will interface with each other.

This is a more rigorous approach to design and analysis – which you would expect from a Government based initiative. As such, although laudable as an approach, the fact is that this methodology is often not delivered fully, even when that goal is strived for.

The overheads in designing a system through this approach are very high. Many IT professionals believe that weighting a project more heavily up-front avoids revisiting code (and even worse the design) at a late stage in development. Such re-work often increases the likelihood of developments going over budget and beyond time-scales anticipated by the business.

A move to agile programming is the antithesis of the SSADM approach, but tries to include prototyping and peer reviews at early stages in an attempt to prevent rework at a later stage.

Gane-Sarson

Very similar to Yourdon/DeMarco, the Gane-Sarson approach was introduced in the mid to late 1970’s and abstracts the data flow models from the physical design of the system. The thought is that by removing the physical aspect of the data flow it can be analysed and designed in a logical way. However, once modelled and modified, the physical design must again be taken into consideration to allow for implementation to occur.

Gane-Sarson provides a methodology for Systems Analysts to create top-level processes which are then decomposed into sup-processes. These sub-processes are then further decomposed until low-level diagrams are created.

An Object Oriented Approach

More recently an Object Oriented approach has been taken to modelling, with Jim Rumbaugh developing the Object modelling Technique (OMT) and Peter Coad working with Edward Yourdon to develop the Coad/Yourdon method for Object-Oriented Analysis (OOA). These dovetail with UML to portray user interaction with system design.

OBASHI

While the above data flow methodologies can be used to design how systems interact both internally and externally, they are all very IT focussed. None of these methodologies can be readily adopted by the business as a way of understanding how the IT systems interact with the day to day business processes which make the business “work”.

This is where my company’s OBASHI methodology can make a difference.

OBASHI provides a framework which enables us to map IT assets and Business processes. The OBASHI framework is divided into six layers: Ownership, Business Function, Application, System, Hardware and Infrastructure.

Mapping resources in these layers allows us to visualise which IT assets support which business processes.

As you can see from the Business and IT diagram (B&IT) on the right, we have mapped the physical and logical aspects of our example. The physical aspect involves mapping the hardware assets and detailing physical connectivity, whist the logical components have mapped business functions and ownership to the applications which support them.

This second diagram shows how the example data flow is portrayed.

You will note that all of the physical assets required for the logical data flow to exist are documented as a sequence. This sequence shows all of the IT & Business assets involved in the data flow.

By examining the sequence we can see every fail point which exists in the data flow. We are able to see not just which applications interact, but also which physical assets are required for the data flow. We can use these diagrams to highlight risk and vulnerabilities, spot areas for consolidation, monitor the alignment of business to IT resources, and portray the contribution which IT makes to the business.

So, while the above methodologies can be beneficial for (re)designing systems, they provide little benefit for analysis of what is actually needed to allow the data to flow. By aggregating data flows using the OBASHI approach, we can see how IT is used by the business. By attaching value meta data to data flows and cost information to IT assets, we can start to assess the ratio between IT support costs and the value of the contribution of IT to the business.

Mapping other data flow methodologies, such as those described above, to the OBASHI framework is a simple process, and one which will enable Business to begin to understand and gain added benefit from the work we do as Systems Analysts.

Governance and Government

Paul Wallis — Fri, 23 Nov 2007 01:26:07 +0000

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:

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

The government has launched an investigation to discover why these procedures were not followed in the HMRC, especially after previous problems in the organisation.

What is known, is that another government department, The National Audit Office (NAO), had asked the HMRC to send it records from the UK’s Child Benefit system. However the NAO did not want all of the data kept in each record, only some of the data.

Part of the explanation for the procedural failure is that HMRC was trying to save money. Rather than HMRC spending time and money querying the databases for the exact data required by NAO, HMCR decided to send the full set of tables so that the NAO would have to meet the cost of extracting the data.

Regardless of the data being re-discovered or used for criminal gain, it would certainly appear that the lapse in security was because well-founded procedures and processes were disregarded at some level within HMRC.

Those of us who have worked within a highly procedure-driven environment can understand the frustrations which are commonly felt, where what appears on face value to be the simplest of tasks seems to take forever to gain sign off through many layers of bureaucracy.

Similarly, those who have tried to implement processes and procedures to cover IT management and governance, such as those in ITIL, equally understand the frustration of trying to get staff to adhere to new ways of working.

Sometimes we, as individuals, may think we know why a process works in a certain way and, based on our limited knowledge, take shortcuts just to shorten the time taken to achieve the same results. But all too often, because we don’t have the experience of the whole community of practice which has developed the process, we unwittingly introduce risk.

Taking shortcuts can be a common occurrence, and trying to control this temptation has lead to a rise in the automation of workflow through software such as Microsoft Sharepoint and, specifically for service desks, Remedy.

Going back many years, we saw a similar trend within manufacturing industries, such as Oil and Gas. It used to be the case that valves and machinery were operated manually and, if the process was not adhered to, technicians could perform the wrong sequence of operations, leading to, at best, contaminated product or, at worst, a loss of life.

Process automation was used to prevent this from happening, and had the additional benefit of increasing efficiency.

Controls were enforced through software to ensure the correct sequence of events occurred at the right time. P&IDs (Piping and Instrument Diagrams) were adopted so each engineering and operational discipline could understand how every part of the plant interacted with the process – enabling weak points in the process to be identified.

A few days ago I had a meeting in Europe's oil capital, Aberdeen, Scotland, with a Sharepoint integration company, Sunnyside Consulting, who showed me how they analyse their clients existing business processes and then design a workflow system within Sharepoint to automate the process.

Checks, sign-offs, and form routing are controlled and managed by the software to make sure that the procedures required by the business are followed to the letter.

Documenting how the IT assets are used to support this workflow, however, has always been somewhat tricky. Trying to portray this to third parties, such as infrastructure designers, proves even more complicated, as this is usually out-with the domain expertise of the software integrators.

What is needed is a P&ID for IT which would allow each discipline to understand how every part of the IT portfolio interacts with the process.

Please excuse the naked self-promotion, but this is one of the reasons why my company invented Business and IT (B&IT) diagrams.

In the same way that the Health & Safety Executive (HSE) use P&IDs to apply auditing and governance to industry, B&ITs can facilitate both Internal and External Audits to take place quickly and easily.

P&IDs enable weaknesses within industrial processes to be identified and remediated, and B&ITs do the same for IT. B&ITs utilise the OBASHI methodology and enable a common language between IT specialists, business workers and management so all parties can understand why processes exists and explain the implications of non-adoption.

In reply to Prime Minister Brown’s opening statements in parliament, the Leader of the Opposition highlighted that: in the last year there were more than 2,000 breaches of security in HMRC; 8000 people receiving tax credits had their bank details revealed; that the details of 15,000 taxpayers, including private pension information, were lost in the post; and that HMRC lost an unencrypted CD-ROM containing data about UBS savings accounts – UBS being the market leader in retail and commercial banking In Switzerland.

People will always try to shortcut procedure and it is that human nature which we’ve seen tackled in other industries through communication, automation and implementing new approaches to cross functional governance.

With IT, unless we can clearly identify weaknesses in dataflow, easily explain process and make sure the true costs of taking shortcuts are clearly understood, it is only a matter of time before there are further catastrophic data breaches.

Nuts and bolts and dataflows

Paul Wallis — Fri, 16 Nov 2007 02:22:22 +0000

“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.

The Pebble likes using an exchange called Betfair because, as a complete technophobe, he says, “It does what I want it to do and it does it quickly and easily.”

Yesterday, by coincidence, I read that the CTO of Betfair is responsible for,

“processing more than five million transactions a day and more than 300 bets a second [peak load] - easily outdoing City institutions and stock exchanges…99.9 per cent of bets in less than one second”,

but, today I read that, that the company has developed,

“a new core betting engine that…. could demonstrate a throughput of almost 100,000 transactions per second, while also reducing the cost per transaction by 200 times.”,

because

“customer trends are moving towards a high volume of small-value bets, which, in turn, produce small-value commissions…..the only solution was to develop a system that could process exponentially more transactions for a lower cost than traditional betting engines.”

This made me think about how other industries process vast amounts of data.

Within the finance industry, APACS is the UK trade association for payments, and for those institutions that deliver payment services to customers. In their most recent Quarterly Statistical Release (5th Nov 2007) they disclosed that in the third quarter of 2007 there were 1.7 billion plastic card purchases made in the UK, and 718 million cash withdrawals from 61,297 cash machines in Sept. 2007 alone.

So that’s 277 withdrawals per second – figures surprisingly close to Betfair‘s existing transaction rate, which gives a sense of scale to Betfair’s operation.

Are there other industries that work on a scale that is larger?

During the 1990’s I managed and developed the Management Information Systems for a well know multinational in the Oil and Gas sector. The manufacturing complex on which I worked had a number of plants, each of which fed data into a real-time system allowing engineers to monitor operations from the comfort of their offices.

The real-time systems took feeds of data from the Distributed Control Systems which controlled the plants, and that data included meter readings about temperatures, pressures, density measurements, flow rates etc.

Information from every valve and transmitter was passed through to the Management Information System which logged, processed and stored the information for trending, analysis, reporting and even governance, compliance and regulatory purposes.

So how much data was logged? How many transactions were performed? We gathered about 120,000 values every 15 seconds – or 8000 per second. Each value was processed and used to generate statistical information about how the value had changed over time, recording maximum and minimum values, various averages and standard deviations, pushing the number of transactions even higher.

Of course, the Distributed Control Systems which controlled the plants and acted as the source of data for the Management Information Systems didn’t have the luxury of working at a 15 second interval – it had to continuously monitor and analyse its data feeds every few milliseconds.

Within the nuclear industry, the tolerances and quantity of information is even higher.

It was working with such real-time systems that I made reference to in my “IT exists for one reason” post:

“Through interpreting the numerous readings taken at a single point in the plant, rich information could be gleaned about how the product was flowing at that instant.

By expanding this single point into hundreds of thousands of points along the manufacturing process, it was possible to see ripples in the data as the product rippled through the plant.

The flow of data became analogous to the flow of product.”

Due to the manufacturing environment being a continuous process, these dataflows were processed 24x7 – and any loss in the dataflow could have a major impact on production. Data flows were clearly linked to cash flows.

If we take a look at the medical sector, the amount of information and processing requirements can be staggering. I have a friend who has become a little too familiar with the process of MRI scanning as a family member undergoes treatment.

Looking at how the images are produced, a typical fMRI data set consists of a 128 by 128 array of 16 bit complex values recorded for each of 32 two-dimensional slices at each of 450 time points spaced about 1.5 seconds apart.

Which amounts to approximately 1 gigabyte of data collected in under 12 minutes and with multiple scans often required, this leads to huge data sets being generated for image processing and analysis. MRI scanners typically have 72Gb of space to store the immediately scanned data and a further 72Gb for image processing, but need to be linked to disk farms on Storage Area Networks to afford them fast access to multiple datasets.

In each of the above industries, the quantity of data flowing through the technology is vast, and as Moore’s Law continues to provide higher processing power and storage capacities we find new ways of pushing the technology to provide us with more and more functionality.

So if we have all of this technology and it is so mission critical – life critical even - why does the business never seem to want to engage with IT and discuss its relative merits?

Let’s take a look at some analogies:

In the finance industry, the board aren’t interested in the Anticipatory dialling vs Predictive dialling characteristics of their sales agents’ call centre. But to the call centre Service Delivery Manager these characteristics have has a direct impact on the way (s)he performs daily tasks and plans for strategic goals.

In manufacturing, the Business Unit Manager doesn’t want to understand the virtues of moving from a Swagelok Metal Gasket Face Seal to a Rubber-Edged Composite Compression Seal. But to the plant engineer the choice has direct impact on the way (s)he performs daily tasks and achieves the levels of product required by the production planners.

In the Medical Industry, the Primary Care Executive Manager couldn’t care less about using the 2.5V Fibre Optic Halogen light sources in the Reister Ri-mini Otoscope. But to the paramedic, the ease with which he can change specula and obtain a clear view of the patient’s current state can save valuable time, and even lives – both of which are monitored as part of the Hospital’s performance indicators.

To the leaders and strategists of the respective industries these diallers, seals and scopes are seen as tools of their employees’ trade. They wouldn’t be expected to listen to presentations about their relative merits, and the department heads would never dream of inviting them to do so.

So why does it happen with IT?

Why should the senior management be interested in the latest Cisco VSS 1440 with its 1.4Tbps bandwidth capabilities, or try to understand the intrinsic worth of the IBM BladeCenter HS21 with quad-Core Intel® Xeon® Processors?

The business, pure and simple, is not interested. These are just tools of the trade.

It is not the technology that is important to the business, and it is not always technology which leads to competitive business advantage – it is how that technology is utilised to perform the tasks needed to solve a business need.

Consider the use of the telephone. The moves toward VoIP implementation can provide some real benefits for a business, but are those particular benefits the ones which are on the business radar. Should it be IT or the business that set the agenda?

By way of an example consider that a plumber and a City trader each use a telephone, but for very different reasons and to different effect. They both deliver a different value to their respective businesses by doing so, and require different levels of support for their Telephone Service provision.

What is important is that we shouldn’t forget that a telephone allows two people to share a conversation and exchange information. The technology allows data to flow through the networks to allow this to be achieved. The technology’s sole purpose is to provide the conduit for that data to flow.

Understanding this dataflow gives you the knowledge of how information is used in a business. It is how the information is used by the business that drives the Service Level Agreement requirements.

To the business, technology is just the “nuts and bolts” that enables data to flow. Ultimately, it is the information that is being shared which provides business advancement and competitive advantage.

Oil & Gas/Energy has led the way in this approach and now other sectors are catching up.

Betfair challenged its R&D department to develop an engine which could process transactions at a rate of 100,000/second because senior management realised they had to future proof their business. Director Mike Carter said: "It wasn't a case of whether we needed to do this, we have to do it. It's a question of survivability."

Okay, so this is an internet company and you would expect IT and the business to work hand in glove and have a trusted relationship, and we see here what happens as a result. IT work to provide a business solution which will ensure company growth in line with its business model. Clearly IT and business are working harmoniously together.

Interestingly, Betfair was judged as one of the UK’s “Best places to work in IT” both this year and in 2005.

Note 1: I, my colleagues, and my company, have no relationships, business or otherwise, with Betfair, its owners or its employees, other than the one described in the introduction to the above blog.

Note 2: The Pebble says he likes “the Giants -2½” against “the Lions” this weekend…whatever that means.

Succession Planning

Paul Wallis — Fri, 09 Nov 2007 11:42:17 +0000

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?

Isn’t it is better to identify key members of staff, understanding their strengths, weaknesses and the skill sets which define what makes them invaluable to the organisation?

We have to accept that sooner or later, these key players will eventually leave their current role, and every good manager understands the necessity of succession planning to ensure the least possible disruption should that time come more quickly than anticipated, or even at the “worst possible moment for the company”.

Time and money is spent with other members of staff – on training, personal development, mentoring, cross skilling, job rotation – to make sure that, should the worst happen, impact is minimised.

But is the same thing ever done with business critical systems and software? Sure, we have contingency plans if things stop working, but that isn’t looking to and planning for the future.

Over time, job functions change and we use HR techniques to analyse the performance of our employees, identifying new areas of weakness as their jobs change and they require training in new skills. Is the same true of our software systems? In a great many cases, software is created to fill a functional gap in the organisation, or to allow a particular area of the business to work with greater efficacy. The systems often outlive their stakeholders and developers, and even the sponsors who sought to have those systems created.

Business evolves, changes direction, has new priorities, objectives and ambitions. The business systems which support them need to be reviewed, just as we do with our employees, or we start creating more legacy systems. We wouldn’t consider retaining a member of staff in perpetuity, employing others to fill in the gaps in their performance – yet we do that with systems all the time.

Succession Planning is as necessary in IT as it is in HR, but to be able to achieve it we must be able to articulate the functions performed by the software – it’s job description, how it supports the business, the service it delivers.

And that’s the difficulty, especially in an outsourced environment where business needs to not only understanding how third party staff support key business systems, but also how IT business services operate to contribute to the business’s bottom line.

With employees, the HR departments have used tried and tested techniques for doing this for many years and these techniques are now built into software applications like PeopleSoft.

We need a new breed of software which enables us to capture how IT supports the business in order to create those job specs for our systems, to manage our business assets in the way we manage our staff.

Having visibility of how IT assets support the business is essential, and without it our documentation will never allow us to perform succession planning with the professionalism which IT needs to promote to the business.

Incidentally, those same managers I mentioned at the start of this article recently elected to roll out PeopleSoft Human Capital Management across the company... so business really can evolve, change direction, have new priorities, objectives and ambitions.

Enterprise Applications and User Interfaces

Paul Wallis — Thu, 01 Nov 2007 15:17:58 +0000

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.

The way I see it these are designed for a different audience and to serve a different purpose, and the user experience of using both will be significantly different.

In the competitive world of high volume, low cost, software applications it is essential to capture the user with a simple, beautifully designed interface which makes using the software engaging and satisfying. From a marketing point of view, offering a demo version of the software which shows off this interface is common practice. If the user doesn’t like what he sees he will quickly hit Google again for a different solution. If he likes it, he will buy it. It’s only $30 after all.

Given that Khoi Vinh graduated with a major in Graphic Design and founded a design studio, it is easy to see why he focuses on the user interface to an application, and rightly so. But what no-one needs is form over function.

When it comes to enterprise software, the push is on functionality, the back end, and how it integrates with legacy systems. Because of the significant costs involved, the software needs to enable strategic changes to the business and allow more profits to be generated. The application becomes integral to the operation of the business, and how user-friendly it is fades into the background somewhat.

Traditionally, in order to continue to drive sales, the enterprise software’s Product Manager focuses on expansion of functionality, and user feedback is sought from the business rather than the integrators and end-users, as it is the business which will provide the future sales.

So if this is the way of the world, will it always be so? No. I don’t think so.

There are changes afoot in the way enterprise applications are sold. Enterprise applications get so ingrained within a business that changing to a competitor is a very unpalatable proposition. So in order to find new markets enterprise software vendors are seeing that by changing their message slightly and using newer technologies, they can move away from the big, clumsy monolithic applications of old and start appealing to Small and Medium size businesses – essential if they are to expand their client base. New business from new market sectors.

This forces a change in price point. And that changes the sale more towards the high volume, low cost software application sector. And that forces a change in user interface. The most high profile changes we’ve seen have come with SAP and Oracle.

SAP’s introduction of SAP Business One, “SAP for the common man”, has been widely discussed elsewhere. As far as Oracle goes, only a few years ago I worked with companies that opted for Microsoft SQL Server rather than Oracle purely on the basis of the interface. Now, in my opinion SQL Server still has the better interface, but the latest version of Oracle Express is a big improvement, and Oracle Express is now free.

The reason I’ve found this topic interesting is that I’ve spent the last six years writing a piece of enterprise software.

It’s purpose is to enable business and IT to speak a common language and to easily show and value the relationships between business services, data flows and IT resources. But the main design goal right from the outset was that it should be scalable from single user use to being applicable throughout the enterprise.

Because of the extremes of user population, there was a strategic push on functionality AND the user interface, which had to be ‘drag & drop’, easily navigable, enable simple ‘one-time’ data capture and have a touch of ‘eye candy’, so it is a pleasant place to be working.

The complexity of some enterprise applications does not lend itself naturally to this, however. So in order to keep the user interface simple, clear and easy to use I had to spend two years inventing and developing a completely new modelling technology.

So I have to agree with Jakob Nielson of Microsoft, quoted by Dennis Howlett, "There is a curious paradox about design simplicity - it isn't that simple."

The figures below show screenshots of the User Interface in question. The idea was to make it simple to build intelligent diagrams of the relationships between business services, data flows and IT resources.

Starting from the left, the first graphic shows the UI. On the left of the UI is the module selector. The large section in the middle is the diagram itself, showing individual elements representing the individual business or IT resources of the organisation and how they are related. These elements sit in the diagram’s six OBASHI™ layers and each one is simply dragged and dropped into position from the detachable panel shown on the extreme right of the graphic.

The diagram acts as an interactive interface between the user and the back end stuff. Innovatively engineering this visual interface enabled complex back end configurations to be created and managed through a very simple UI.

To the immediate right of the diagram are Explorer panels for quickly navigating to specific elements and dataflows; and a data panel, where business/technical/financial information about individual elements and/or dataflows is entered, edited and displayed. An example of the kind of information is shown in the second graphic.

The third graphic shows an example output from the software (once opened, click to zoom in and out). There is more about just a few of the things the software can do here.

Making an enterprise application user friendly is not as simple as designing the user interface. Developing the back-end required to drive it requires imagination, inventiveness, ambition, boldness, enthusiasm, ingenuity, partnership and business.

Interestingly enough, there is one word which means all of these things ... Enterprise.

Trying to cross No Man's Land

Paul Wallis — Thu, 25 Oct 2007 17:18:43 +0100

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...?

If we think back, the strategic objective was to locate and destroy all of those date fields containing only two year digits which would cause mayhem and havoc if they weren’t fixed as the calendars changed to the Year 2000. In most large organisations this was done with the kind of precision you usually find only on the parade ground.

But the “War on Y2K” didn’t just consist of programmers fighting on the front line to remediate code. Business Continuity and Contingency Planning were used as a rear guard action to ensure that if any of those little bugs made it across No Man’s Land there was a mechanism in place to neutralise their effect on the business.

The often forgotten skills of the Systems Analyst were called upon once more. They became the “embedded journalists” within the business, reporting back in meticulous detail the inputs and outputs to the systems.

The Analysts mapped out how IT systems were used throughout all parts of the business, and how information was passed from department to department. (What I call the flow of data ).

New systems were developed, old systems were remediated, command and control buildings were established, and paper based systems were put in place just in-case the worst should happen. This was achievable only because, for the first time and at considerable expense, the relationships between business processes and the portfolio of deployed assets were investigated, catalogued and analysed. Capturing these relationships was key to planning disaster recovery, business continuity, contingency planning et al.

The current talk in ITIL v3 about maintaining similar catalogues of business services and technology assets will go some way to enabling business processes optimisation, enterprise architecture, governance, SOX, compliance and alignment, to name just a few. The problem faced by business, however, is how to achieve this with the minimum number of casualties – that is, at a reasonable cost.

Y2K still divides opinion. Some people say that resources were sacrificed needlessly and it was another huge waste of money by the IT department to fix a non-existent problem of their own making. Others feel that it was unprecedented hype and scare-mongering by the media to fill column inches and TV schedules. Many who worked on the problems, however, believe the operation was a success and the lack of system failures was testament to them doing a fine job and fixing all of the problems.

We’ll never know.

What is definite, however, is that for the majority of organisations, Y2K was the last real opportunity IT was given to interact with the business to fully understand how IT assets supported the business.

Although at its core Y2K was an IT issue, board members became acutely aware of the potential risks should any of the widely reported problems manifest themselves in any of their companies systems. They understood that IT was a pervasive enabler throughout every part of their organisations, governing every aspect from order placement, through receipt of component parts, to invoices and product shipments – throughout the whole supply chain.

It was this realisation which caused the business to engage with IT, and it acted as an enabler for communication. For the first time IT was invited into the boardroom and given a platform to speak and be heard.

Unfortunately, the information which had been gathered became obsolete and outdated. IT’s close strategic relationship with the business was never nurtured and it became a casualty of the Y2K war.

In the 21st century IT has become even more pervasive within the business, which means understanding and optimising data flows is even more critical.

The risk to the business of system failure causing financial loss is greater than ever – a point which is still understood by the board. However, until this is expressed in a clear way showing the services provided to the business and the financial consequence of system failure, IT's journey back to the boardroom will involve a long and arduous campaign.

“…so the harsh winter was a critical factor that helped the Russians begin to turn the tide.”

There were a few moments of silence.

I snapped back to reality. Thankfully my eyes had been open the whole time.

“You are a font of wisdom”, I said, in as comradely a manner as I could muster. With a smile, The Pebble took a sip of his coffee and sat down again.

“Do you remember the fuss about Y2K?”, I asked, quickly changing the subject. There was a danger the Pebble could go off again at any moment.

“All that hype about 99 and 00?”

“Well, I wouldn’t say it was all hype exactly. Within the process control systems we had some DCS concerns over the Y2K compliance of microchips in embedded systems which fed RS232 data through 4-20mA DACs and directly into the loops which ramped the set points, so we had to establish inter-company resource sharing across the industry to share information as and when it became available by manufacturers or by test programmes to ....”

It may just have been the way the light was shining, but I could have sworn The Pebble’s eyes began to glaze over.

Rolling Rocks and Landing the Catch

Paul Wallis — Thu, 18 Oct 2007 20:31:02 +0100

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?

If we take a look at what ITIL says about prioritising failures we find that the priority of an incident is usually calculated through evaluation of impact and urgency. But as ITIL is an IT centric approach, impact and urgency within ITIL focus on the impact to the IT domain, rather than the business domain. This does not help communication and alignment with the business.

For this reason, if we want to help the business, and thereby enhance our own reputations, we need to consider three things from a business perspective:

Severity / Impact: How many people are affected? What are the demographics of the user population? Are any VIP users affected? Does this impact any people outside of the organisation?
Risk to the business: Are there Health & Safety, Governance or Security issues? How likely is this to affect the profitability of the organisation? Is there any possibility of damage to the reputation of the organisation?
Urgency: Is there are window of opportunity which should not be missed? Are we losing money while we are not acting? What is the cost to the business of not taking appropriate action in a timely manner?

Manufacturers of Helpdesk or IT Support Systems have integrated prioritisation and escalation procedures into their offerings. If we consider HP Openview and take a look at their approach, we can follow the logic, mathematics and equations used to set the priority of any given task.

In the HP Openview example above, SLAs are considered as a primary source of determining priority. This is a great first step, and trying to quantify the impact to the business of a failure through impact on services is essential, but the major failing of existing systems is the inability to consider failures or change in a business context.

Each business service cannot be treated independently of other business services. One SLA will have an impact on other SLAs, and one IT asset can contribute to many services.

Bear with me for a moment while I go off on a slight tangent, but think of it like a fishing boat going out to sea. If the nets break then you’ll land fewer fish. This is what ITIL will tell us. Consequently, the crew won’t make as much money. That’s what SLA based prioritisation will tell us.

But that is not the full impact. The auctioneers at the fish market will have fewer lots to sell. In turn, the merchant buyers will have a restricted selection of product. Fishmongers will pay increased premiums which are passed onto the consumer... etc...

There is a chain of consequential loss which is triggered by an originating event, and the same is true of IT failure within the business. Traditional systems look at the immediate impact (the nets have broken) but fail to be able to consider the knock-on effects.

We need to model the business services in order to understand the “downstream” impact of failure or change.

This is key to prioritising where IT effort should be best directed and key to the business understanding the “what” and “why” of IT operations.

Understand Value to Enable Communication

Paul Wallis — Thu, 11 Oct 2007 16:20:48 +0100

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?

CFOs control the spend across all departments, so it is not difficult to see why 60% of them have taken on the task of imposing onto IT the more familiar rigours of financial governance experienced by the rest of the organisation.

Anyone who reaches CxO level in a large company is clearly a “smart cookie”, and has plenty of resource under their control to focus on the problem. So if we understand the costs of IT, why is it so difficult to quantify the return in business terms? After all, the projects were sanctioned with a ROI justification, right?

ROI justifications within IT tend to involve some degree of estimation. Usually, there is no track record of executing the same project in the same business circumstances leading to there being no sound historical evidence which can form the basis of the ROI predictions – so we make an informed estimate. The predicted project savings are rarely integrated into subsequent budgets, leading to the changes required by the project not being as widespread as sanctioned. Trying to track the return to see how it matches the basis on which the sanction was obtained seldom happens.

This echoes the findings above by Micro Focus, where only 29% of CIOs and CFOs try to quantify the contribution of IT to business performance. Of that 29% I’m sure many fail to realise an outcome, and my guess is the success rate is very low.

My business partner and I recently met with Neil Macehiter of independent analysts Macehiter Ward-Dutton. Neil is co-author of the excellent book “The Technology Garden”, and its contents formed some of the background for our discussion about Business and IT alignment. In particular we chatted about viewing IT as a range of services presented to the business in a way that they could easily grasp.

I believe that these Business Services (which I define as the combination of assets, resources and the dataflows through them) are key to understanding and communicating IT in a way that the business understands, namely in financial terms. Neil covers this where he describes the language of business:

“…it’s nevertheless clear from our research for this book that being able to talk about financial costs and business benefits is a crucially important part of the overall language that IT organisations have to develop. Whether you are having conversations about IT investment, giving feedback to stakeholders about how well the system resulting from an investment is delivering value or working through the complexities of how to change that system, you have to be able to be able to talk to business people in terms that make sense to them – and the language of business revolves around money.” The Technology Garden, p.61

What is needed to enable us to speak this common language is an approach that allows us to:

Define the services IT provides to the business.
Know which assets are used to deliver those services.
Understand the true cost of those assets.
Work with the business to value the services IT provides & what business processes and objectives they support.
Compare the costs with the value.

The business does not care about the “nuts and bolts” of IT so long as it provides a service they need.

Use cost/value as a basis of communication with the business and you will increase the likelihood of being accepted as a trusted part of the organisation.

Are CMDBs worth the trouble?

Paul Wallis — Fri, 05 Oct 2007 15:23:20 +0100

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.

There are a multitude of vendors who offer CMDB solutions, each ranging in cost and complexity, but the key thing to remember is that a CMDB by itself is useless. A CMDB is only ever of use when it forms part of a Configuration Management process which has four key sub-processes. These govern the identification of CIs, the control of the CIs, auditing the CMDB information, and CMDB status accounting.

By having a central database accurately filled with information about assets, we can improve IT Management and Delivery processes, such as Change, Problem, Incident and Service Desk Management.

A properly installed, configured, managed and integrated CMDB allows more informed IT decisions to be made to improve service delivery. It facilitates adherence to legal and contractual obligations such as Software Licensing and Contract Management. Assets can be re-deployed more quickly and reliably to save budgetary spend.

So that’s the basic “what?” and “why?” covered.

CMDB may seem a great idea but opinion is divided as to the business benefits of a CMDB, whether it can ever be properly populated, and whether the overhead is just too great to bear.

“IT Skeptic” sums this up quite clearly:

"CMDB can’t be done. Not as ITIL defines it. At least not with a justifiable return on the investment of doing it - it is such an enormous undertaking that any organisation attempting it is going to burn money on an irresponsible scale. The truth about CMDB is no secret. It is a “dead elephant”: a great putrescence in the corner of the room that everyone studiously ignores, stepping around it and ignoring the stench, because life will be so much simpler if they do not acknowledge the obvious."

This point is not lost on a client who recently told me about his CMDB woes, his company having spent over $4m (£2m) before deciding there was no tangible benefit and then scrapping the project.

Some analysts point to the problem being with the underlying database technology itself. Trying to keep track of the complex relationships between CIs is clearly an issue. Relationships governing where CIs are geographically located and the time-based nature of logging faults, fixes and changes in configuration lead others to believe that a new kind of Spatial Temporal GIS database is required. Personally, I believe that only a new type of modelling engine can create and maintain the relationships.

Earlier I mentioned the Configuration Management process which must be implemented as part of the CMDB roll-out. Let’s take a look at the four key sub-processes in more detail:

Identification of Configuration Items (CIs): Creating the scope which identifies which CIs should exist in the CMDB and the information associated with those CIs defines the cost of implementation. Be over ambitious and the manpower and integration costs will be too high. Don’t capture enough and the CMDB will be meaningless. There is no good reference point we can look back at to see what an ROI should be for CMDB. We sail in unchartered waters. My CEO was recently at a seminar hosted by a CMDB vendor who announced that “A full implementation can cost millions of dollars and take years to implement”.

Control of the CIs: In order to establish a control framework around the CMDB, ITIL recommend that you create a Configuration Management Policy document. In this document the roles and responsibilities must be defined governing who should add a new CI entry, who can modify a CI entry and who the process manager should be. Now, this is great when it comes to manual adds and changes, but in a real world implementation much of the CI information will be sourced from within other systems. Where this is the case, the policy needs to be extended to ensure the same restrictions are employed on the systems which act as tributaries of data.

Auditing the CMDB information: We’ve already established that the data held within a CMDB is critical to its success, but there are many ways in which the data can become obsolete or incomplete. There is a high chance that the tributary systems will fall short of supplying all of the information which is needed in the CI, so manual entry is also required to fill the gaps. More difficult to spot, however, is an incorrect relationship between CIs. Over time, relationships change and this can be difficult to capture, and easy to miss. It is this relationship based information which is used to make the more strategic, and consequentially higher value, decisions. Auditing is an essential part of Configuration Management. Without it, the CMDB cannot be trusted.

CMDB status accounting: Although usually tailored to individual company needs, there are some core statistics which are generated about CMDB performance. Examples would include: the number of changes for each CI type over a period of time; the number of software licences not used; who uses the CMDB; the number of breeched SLAs because of CMDB errors and the number of incomplete CI records. These, and others, all form part of the cycle of continuous improvement and help to force another turn of the wheel.

You may have noticed how "IT-centric" this post has become, reflecting my earlier comment that CMDB is clearly IT focused. This leads to a problem of project justifications being put in IT terms rather than in business terms. Speak to the business using this language and, given the huge costs for CMDB, your project will never (certainly should never) get sanctioned.

Even looking to suppliers for encouragement doesn’t help. Take BMC as an example. Here’s a quote from their website:

"The BMC Atrium CMDB provides the following business value:

Allows any IT process users to launch a view into the BMC Atrium CMDB to quickly view CI and relationship data relevant to their needs through Graphical Interfaces

Eliminates the fragmentation of IT tools and data sources by providing both a Common Data Model and service model to infuse business relevance into an industry standards approach to managing IT data"

So key business values are a graphical interface and a consolidated toolset? Clearly these are targeted at the IT fraternity, not the business minded CIO.

To make the case to the business, start talking in terms of how the service to your clients will improve, how the goal is to make the IT delivery more seamless, less error prone, and meeting the required Service Level Agreements signed off by the business. Start talking in terms of how security weaknesses can be spotted and how redundant kit can be pinpointed and removed from the bottom line.

There exists a huge opportunity to use a CMDB to provide a better service for the business, thus increasing confidence in the IT function. This confidence is essential if IT is to become a trusted part of the organisation, and it is only through trust that IT can build a relationship with the business, enabling the conversations to begin to achieve alignment.

To truly speak to the business, though, you need to talk in their terms, and that means talking financially. Unfortunately, CMDB is lacking a key component – a financial model. Rather than generating reports on how many CIs have not been updated, the business would really like to see a meaningful business report like “the cost to the business of email failure” or "the financial impact if the fulfilment service failed".

By opting for a CMDB you opt for change. Existing processes which define the IT Service to the business will need to be changed in order to utilise the CMDB otherwise the data will become out of date, meaningless and create problems rather than solve them. Process change affects people and this takes careful planning and implementation if it is to succeed. It provides a huge opportunity for failure should it not be delivered effectively.

So is a CMDB worth the trouble? If you can manage to get it installed, configured, integrated, populated, maintained and fully operational – yes, it will improve IT performance and it will eventually help align IT with the business. However, you are walking a tightrope with very little in the way of a safety net. Fail on any of the above points and you risk heading for an expensive fall, causing the rift between business and IT to widen even further.

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

Paul Wallis — Thu, 27 Sep 2007 20:47:44 +0100

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.

Taking a step back, IT systems are never the beginning or the end. All IT systems are only there to be middle of a bigger process, and the IT system is there solely as an enabler.

Is IT’s whole reason for being to simplify or streamline a process, or enable some process to happen which would otherwise not have been able to occur? Perhaps, but it is not the IT system per se which is important here. It is the flow of data through the system which is actually used to effect a change. IT's sole reason for being is to enable that flow of data.

Let’s take the case of a simple word processor, where thoughts and keystrokes can be processed and manipulated with the result being something which when read induces a change in thought or behaviour. The art of a good wordsmith is to ensure that such a result happens, and the word processor is simply a tool he can use to simplify the task.

Within a manufacturing environment, the Management Information Systems and Control Systems form the link in the chain to create a better product or more profit - a conduit to effect change.

If IT does not exist within a sequential process which alters an outcome, its role is meaningless. And it is the flow of data that links individual items together into this sequence.

This is why understanding how and why data flows around the business is critical to the alignment of IT and business. This understanding clearly highlights why IT exists and the role a system plays in the wider business context.

By looking at systems in this way IT can communicate more effectively with all parts of the business, and more informed and effective decisions can be made.

Understanding Enterprise Architecture complexity

Paul Wallis — Thu, 20 Sep 2007 20:49:06 +0100

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.

Zachman Framework

Zachman provides the ability to define an enterprise in a highly structured way, by using a 6x6 two dimensional matrix to classify components of the enterprise:

Horizontal: The horizontal cells of the framework are based around common questions: What, relating to data; How, relating to function; Where, being the Network or location; Who, identifies people or identities; When, pertaining to times; and Why covering motivation.

Vertical: The vertical cells relate to the stakeholder groups: Planner, details the scope (Contextual); Owner, defines the Business Model (Conceptual); Designer, documents the System Model (Logical); Builder, the Technology Model (Physical); Implementer/Subcontractor, shows detailed representations (out-of-context); and Worker, detailing functioning enterprise instances.

When filling in the framework each cell must be aligned with the cells immediately above and below it, and all horizontal cells must also be integrated. This gives the immediate indication and assessment of the alignment between the IT portfolio that is currently being analysed and the business.

Several software solutions are available to assist with the storing and manipulation of the information gathered by consultants. The output from such solutions is generally formed around the Zachman model itself.

Zachman, unfortunately, is reliant on a high degree of subjective data which is very granular in it analysis, and that is never a great combination. Trying to obtain a consistent model from multiple architects is a problem commonly summed up as: one architect’s “How?” is another architect’s “Why?”

The Open Group Architecture Framework (TOGAF)

TOGAF is “a detailed method and a set of supporting tools for developing an Enterprise Architecture”, developed by members of The Open Group Architecture Forum. TOGAF centres around four types of architecture which it sees as subsets of an overall enterprise architecture:

Business Architecture: defining the business strategy, governance, organisation and key business processes.

Data Architecture: describing the structure of an organisation’s logical and physical data management resources and data assets.

Applications Architecture: describing a blueprint for the applications systems deployed, their interactions and their relationships to the core business processes described in the Business Architecture.

Technology Architecture: a description of the logical software and hardware capabilities which are required to support the Business, Data and Application architectures. For example, Networks, IT infrastructure, middleware, standards, etc.

The Open Group is a non-profit organisation, but is backed by some major companies within the IT world. IBM, EDS and HP are all members of TOG and seek to promote tools and services based around TOGAF, thus raising its profile within the EA arena.

What is unclear, however, is how TOGAF fits with other frameworks endorsed by these companies. Much of the work currently being advocated by these companies, such as SOA, is inherently “bottom-up” and how the “top-down” nature of TOGAF fits with this model is ambiguous. (Personally, I believe SOA should be pursued through a top-down approach – but that’s a subject for another blog).

TOGAF requires tailoring to suit a particular enterprise and therefore requires strong knowledge of the methodology and the business model. Finding a team with such qualities can be difficult. Obtaining sanction to bring such a team onto the project requires much political will by a key influencer at a senior level within the organisation.

Department of Defense Architecture Framework (DoDAF)

DoDAF is a framework used by the US Department of Defense as a standard way to organise EA or SA (Systems Architecture) into consistent and complementary views. The US DoD insists that this framework is used on all major weapons or technology system procurements.

Central to the classification of artefacts (objects) within DoDAF is the concept of interoperability which is organised into a series of levels.

There are four basic views which can be applied to the artefacts:

All View (AV): provides descriptions of the entire architecture, and defines the scope, purpose, intended users, environment etc.

Operational View (OV): this view is unique to DoDAF systems and describes everything necessary to achieve a DoD mission such as tasks, activities, I/O, rules, command–control-coordination relationships.

Systems View (SV): provides system components, networks, logical data models, sequence activity timelines etc.

Technical Standards View (TV): allows for extraction of current standards and future standards.

DoDAF has been developed to deliver an incredibly rich environment of documentation. In order to evaluate tendors submitted during the procurement process every known item about an artefact must be catalogued and quantified in terms of speed, performance, interface requirements and applicability to a given task. Due to the nature of the types of systems to be specified for the DoD, DoDAF is an extremely complicated and rigorous framework to adopt.

There are a number of tools available which allow you to gather and report the wealth of data required to fulfil the DoDAF specification.

Conforming to DoDAF can be extremely man-hour intensive and therefore costs can prove a barrier to adoption into the business. Where DoDAF is a necessity for business development, such as in the defense industry, costs must be factored into the specific project which requires adoption of the framework.

I have discussed these frameworks because they highlight how Enterprise Architecture is split into three camps:

a) Static Models: Zachman is a structural framework which is static and can be used to classify artefacts.

b) Dynamic Models: TOGAF is a process model which is dynamic and requires to be configured to each implementation.

c) Hybrid models: DoDAF and derived frameworks are extended to cover artefacts of special interest to a particular vertical market.

Adoption of any of these three frameworks requires buy-in from the business in order to succeed. Enterprise Architecture is an ongoing process, not just a one-off exercise and as such there has to be a healthy commitment shown by the business. And this is where there can be a problem with these and other frameworks. There requires such an initial investment of not only money, but corporate will to succeed, that often other corporate prizes are within easier reach. Enterprise Architecture is just too much of an overhead.

What is needed is a lighter weight framework which is easy to apply, which can be focussed as necessary at particular target areas of the business, and which provides a rapid payback to the organisation ... the so called “low hanging fruits”, ripe and ready to be picked.

OBASHI™

My company’s framework OBASHI™, combines essentials from all three of the frameworks discussed above. It provides a static modelling environment based around six layers into which artefacts (or elements as they are known within OBASHI™) can be placed.

In order to take full advantage of the simplicity of the OBASHI™ approach my company had to design a new modelling technology. This Stroma® software automates the six types of relationships that exist within OBASHI™:

1) Connection: elements can be explicitly connected to show a direct and bi-directional coupling.

2) Dependency: elements can be explicitly connected uni-directionally to show how one element is dependent on another.

3) Layer: An implicit relationship which exists between all elements within a particular layer (for example, Ownership, Systems, Business Processes).

4) Spatial: an implicit relationship which is formed between elements which are placed above or below each other, such as Business Processes placed under a particular Owner.

5) Sequential: an explicit relationship denoted by a list of elements in which adjoining elements in the list have a connection relationship, i.e. a string of connected elements.

6) Zone: elements within a prescribed geographic area are implicitly related to each other.

The entire model can be formed from one or more (usually many) diagrams created using the OBASHI™ methodology. We term them Business and IT diagrams (B&ITs).

The horizontal and vertical position of elements within a B&IT diagram shows alignment, much in the same manner as Zachman, but with a more flexible relationship modelling capability. Elements can exist on any number of B&ITs, and thus form complex relationships with many other elements while still being easy to understand on each individual diagram.

Process modelling, work flow and data flow can be superimposed onto and across the OBASHI™ layers using sequential relationships to show how business processes utilise and are underpinned by IT.

As each element in OBASHI™ is based on an object, hybrid items can be created to reflect the needs of any particular vertical market. Each element can reference external documentation and core information about the physical or logical item it represents.

The models and methodologies used by Enterprise Architects tend to reflect the scale, complexity, breadth and depth of the Enterprise being modelled. For this reason there are often different views which can project the model in a meaningful way to different stakeholders. OBASHI™ only requires two such views.

Firstly, the B&IT View, where the Business and IT diagram input mechanism also serves as the graphical output. Secondly, the Dataflow Analysis View, which highlights the interaction between all of the artefacts used to perform a task (or sub task).

OBASHI™ facilitates diagrams which are clear and simple to understand by all levels of an organisation, not just the trained architects which created them.

Using OBASHI™ and Stroma® it is easy to see and communicate complexity and how IT supports any part of the business. This allows business and IT to talk the same language – a prerequisite to bridging the understanding gap between business and IT.

Feature: IT exists for one reason

Paul Wallis — Thu, 13 Sep 2007 14:06:00 +0100

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.

For days we had been trying to come up with a way of bridging the understanding gap between business and IT, but with little success.

On the table in front of us were a couple of A0 size Piping and Instrumentation Diagrams (P&IDs).

My business partner’s brother, a man who freely admits he has the technical knowledge of a pebble, wandered by and asked what the diagrams showed.

We patiently explained that the P&IDs were print-outs from a computer model of a nearby petrochemical complex. The computer model held a representation of the interactions between individual assets of the plants - things like pipes, valves, pumps, meters and sensors.

We described how the computer model and P&IDs displayed and communicated how the assets were connected; how the assets interacted with business processes; and how the flows of oil and gas products through a business unit were measured and valued.

Assets that did not add value to or support a business function could be easily identified and removed or reassigned. Also, the cost to the business of failure of an asset could be evaluated and steps taken to mitigate that risk.

“One of the great things about P&IDs”, I said, “is that by using them as a visualisation and communication tool, the engineers and the business guys quickly see the big picture and can easily understand each other.”

We paused for confirmation that the penny was beginning to drop.

After a few moments of silence, The Pebble, as we affectionately call him, frowned and asked,

“So why has this never been done for IT and business…I mean…isn’t IT the flow of data between assets?”

The silence resumed. For quite a while.

The Pebble had pointed us towards the solution to defining a methodology that would put IT in a business context.

We realised that by thinking of IT as data flowing between business assets, the tried and trusted methodology used by engineers to communicate with the business could be adapted and applied to IT.

Data flows in the Oil and Gas Industries

For the last thirty or so years accurate flow measurement and analysis has been the key to optimising the productivity of plant assets in the oil and gas industry.

As technology improved from the late 1970s onward, the flow of oil and gas products became analogous to the flow of data.

Flows of oil and gas through a plant used to be understood by reading values from analog flow meters. Each meter was inspected by an engineer and values recorded. Data such as temperature, pressure and product flow would then be manually entered into a computer for analysis.

Digital flow meters began to replace analog flow meters, which enabled readings to be entered into a model in real-time.

As more digital equipment came online the business gained a better understanding of how the product flowed through a plant.

Sensors could be attached to nearly every asset (things like pipes, valves, and pumps), providing more and more snippets of data and enabling a deeper analysis of the interactions between assets and product flows.

Through interpreting the numerous readings taken at a single point in the plant, rich information could be gleaned about how the product was flowing at that instant.

By expanding this single point into hundreds of thousands of points along the manufacturing process, it was possible to see ripples in the data as the product rippled through the plant.

The flow of data became analogous to the flow of product.

The business started to react and adapt to the changes it saw in the data flow faster than it ever could to changes in product flow.

By linking the model to the commodities markets the real costs/values of flow could be displayed, monitored and trended as dollars per second, rather than the more usual tonnes per hour. Why? So business processes could be optimised around value, and the contribution each asset made to the cost/value of the flow could be evaluated in business (monetary) terms.

The importance of avoiding system down-time became clear.

Data flow is critical today

Today, business resources and IT assets are either providers of data, consumers of data or provide the conduit through which the data can flow.

The flow of data between business assets is the life-blood of every modern organisation.

People provide and consume data daily, as do applications and systems. Hardware and cables act as conduits through which data flows: between desks, through office and corporate networks, across the internet, through deep sea cables and via satellites.

Across all businesses, the equivalents of the pipes, valves, pumps, meters and sensors of the oil and gas industry are the people, hubs, cables, routers, servers, and desktops through which data flows.

Data flow is at the heart of 21st century business. Supporting, processing and optimising the flow of data are critical to maximising business performance.

The sole reason for ITs existence is to manage the flow of data.

Alignment? We need the big picture

Paul Wallis — Thu, 13 Sep 2007 10:47:00 +0100

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.

Today’s organisations rely on complex IT infrastructures in which resources are employed in parallel by, and in support of, a number of business activities.

This complexity (and the limitations of traditional modelling technology) has meant that until now it has been almost impossible to fully document, analyse, understand, and communicate the relationships between business activities and IT resources.

And this has lead to inevitable problems. On too many occasions projects have insufficient planning and documentation, project deadlines are missed, projects incur huge overspends and all too often the delivered solution is not quite what the business needed.

I’ve always found it extraordinary that some organisations will often spend, in one fell swoop, tens of millions on IT projects when they cannot see ‘the big picture’ of how business and IT interact.

Think for a second about how other industries work.

Would you approve the extension of a factory, or the building of a new corporate HQ, without seeing and understanding the architect’s plans? Would you expect the construction to be attempted without such plans?

Would you expect engineers to build a bridge without using diagrams to communicate to you how they were going to do it? Would you expect construction suppliers to design and supply their products without such diagrams?

Despite the best efforts of change control these analogies are equivalents to what happens daily in the IT world. With overstretched IT departments documentation is often the last piece of the jigsaw, and often goes missing.

But what to do about this problem? There is an obvious need for a simple, clear and logical way to visualise the alignment of business activities with IT resources and dataflows.

Architects and Engineers use pictures to enable the business and the professional to easily understand each other. A few years ago my business partner and I started investigating if the same approach could be applied to the business and IT. That is, showing the relationship between business and IT visually, in a way that was generally understandable.

What we came up with, after a few years of research and development, is what we call a Business and IT diagram (B&IT).

B&ITs are produced from a computer model (called Stroma®). They map and document the logical and physical relationships between an organisation’s business operations and the IT resources that support them. In other words, they put IT in a business context.

B&IT diagrams accurately depict the complex inter-relationships and dependencies of business processes, IT resources and dataflows in an easy-to-understand visual format.

They do this by utilising the OBASHI™ methodology.

Imagine a landscape piece of paper split into six horizontal lanes. To the left of the top lane write “Ownership”, to the left of the lane beneath it write “Business Process”. Then come “Application”, “System”, “Hardware” and “Infrastructure”.

Now you have a framework for organising the elements that represent individual Business or IT resources in your organisation.

B&ITs enable the responsibilities, roles, risks and costs of every IT resource (or group of IT resources) employed in support of each business activity (and/or set of business activities) to be clearly visualised and, thus, understood.

By portraying the relationship of business and IT in this way both groups can understand each other and the process of alignment can begin.

If you would like to see and interact with some example B&ITs choose any of the ‘Embedded’ options here.

Save an example of a simple B&IT and an explanation of OBASHI™ here.

As always, your thoughts, questions and feedback are very welcome.

The debate about ERP

Paul Wallis — Thu, 13 Sep 2007 10:01:00 +0100

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.

Although still in development, Thingamy is courting interest from many quarters due to the way it uses the interaction of objects to replicate the interactions of items flowing through an ERP system. I’m hoping to make this the subject of a future blog as it touches on many areas in which I have a keen interest. This post by sig explains a little more about the technology.

My experience is that ERP can work and provide real business benefits, given the right set of circumstances. But it can also be an expensive waste of time, money and corporate effort.

It may be stating the obvious, but a green field site is an ideal opportunity to get things right when implementing ERP.

A few years ago I had the good fortune to work on a project which was establishing a new business venture in the Far East. A multinational corporation took a farsighted approach and decided against trying to impose the same business processes and systems used in the rest of the company. Instead, the decision was taken to involve an ERP provider early in the project (incidentally, not the cheapest provider) who had great local knowledge.

ERP was the first computer system to be specified on the project, and from that all processes and systems were put in place. The ERP provider was well paid but it was money well spent. The consultants’ experience of country specific business processes and regulatory issues was critical to successfully expediting the project. The project was on-time and under budget, and delivered everything it was engineered to do.

In a similar vein, another project centred on a new joint venture company between two large European chemical companies. By utilising one of the partners’ ERP systems the roll out and integration of the new business was extremely quick. The ERP provider quickly bespoked the supply chain, warehousing, HR, financial and manufacturing requirements to reflect the new enterprise, and the JV partners’ ERP systems securely linked to share common data. The project was on time and under budget, and delivered everything it was engineered to do.

Contrasting with these experiences is one huge implementation which I watched from a safe distance. It was decided to implement ERP across a large corporation with tens of thousands of employees in 46 countries. The business edicts surrounding the project were simplistic and showed a glaring disconnect between business and IT: “Implement ERP”, “reduce the number of legacy systems”, “rationalise applications”, and “consolidate hardware”. The project rolled on for years trying to enforce change around the globe, country by country. ERP was eventually installed, but the initial vision was far from realised. Most legacy systems remained, and the rationalisation of applications could not get standards adopted. Millions upon millions of pounds were over-spent in the drive to implement ERP, but ultimately that wasn’t ERPs fault.

Trying to force too much change onto a complex organisation because of what Denis Howlett calls “political necessity or ‘me too’ ERP envy” is doomed to failure.

You may have noticed I used the term “engineered” above. Perhaps the reason that ERP has been so successful in manufacturing (to take up Vinnie’s point) is that these businesses understand the value of a planned and documented approach to building something.

ERP can be very successful if it is planned and implemented properly.

A conversation with the management of the green field site a few years after I’d moved on did provide a cautionary sting in the tail, however. “It’s been great for us so long as we don’t want to change anything. Implementing ERP is like pouring concrete on the whole organisation”.

Scoring lines in the cement

Paul Wallis — Wed, 12 Sep 2007 15:09:00 +0100

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...

I’ve never been blessed with the patience and skill to perform DIY, and although I can see the fascination with power-tools, I can admit to having hands more suited to a keyboard. For this reason I decided I’d buy a new build house rather than fix-up an older property.

It was only when I moved into my new house (four months after the original entry date) I discovered my naivety and the process of “snagging”. For those not accustomed with the practice, snagging is going through everything with a fine tooth comb and building up lists of problems for the builder to come back and fix.

And there were lots of problems. Faulty wiring, plumbing problems, leaking windows, warped doors. There was even a place on roof-line where the builder had run out of bricks and filled the remaining space with cement. Admittedly they’d been kind enough to score lines in the cement so it looked like bricks, but this artistic solution would have to be replaced.

The kitchen work surfaces were not the ones I had originally specified, and had to be replaced. Twice, actually, because the first replacement was incorrectly fitted. Then there was the garden landscaping, and don’t get me started on the lack of documentation handed over with the house.

The cost to the builders of doing all the remedial work was not insubstantial, and took months to complete.

I’m sure this was, in part, due to the fact that the original team had moved onto another building project and left some poor support workers to manage the ongoing day to day maintenance activities without a proper hand over and the full level of resource that the original project team was blessed with.

Over budget, over-run completion dates, teething problems, solutions out-with expectations, poor project handover with insufficient documentation.

Sound familiar?

Archaeological Digs & IT Relics

Paul Wallis — Wed, 12 Sep 2007 11:27:00 +0100

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.

Portraying the IT Architecture is like providing the picture on top of the jigsaw puzzle box in that it shows the infrastructure upon which the organisation is running.

Very often this is at variance with what the business is trying to achieve, reflecting the tendency in most organisations for the systems development agenda to be driven by lower/middle management to improve the performance of their tasks, rather than by the Board or strategic management to improve overall business performance.

When IT Manager and Board share the total picture of the cost structure and systems architecture of the business then they have a solid platform upon which to manage future systems development to the strategic advantage of the business. They will also be able to factor foreseen benefits from IT expenditure into future budgets so as to ensure delivery or, in other words, secure a return on their investment.

For most medium - large organisations, the savings and profit improvements achievable from a systematic analysis and review of their IT operations are considerable and, in many cases, can amount to millions of pounds.

A better understanding of the strategic management issues involved also provides a confident platform from which to consider more radical options such as outsourcing or strategic partnering with specialised service-providers. This affords the prospect of further benefits from access to both the leading-edge technology and organisational thinking they can provide.

It is at this point that visualisation tools will be able to add value:

at the boardroom level, being able to see the organisation’s systems model affords the opportunity to re-engineer (and possibly understand for the first time the use of this term in its systems context) its business processes and systems and align them with strategic goals;

for the IT Manager, the model provides a platform upon which to superimpose the IT establishment. It identifies the cost to the business of: having to man the organisation for the unnecessarily broad range of expertise often required to service a proliferation of hardware and software platforms (because people tend to specialise in certain products and/or product mixes); overlapping functionality; high maintenance systems etc.

There are many Enterprise Architecture tools and methodologies which can assist with the archaeological explorations into the portfolio of deployed systems. But few, if any, can provide a clear picture of the interactions and relationships between business and IT.

It was this realisation a few years ago that caused my business partner and I to set about creating an enterprise applcation to fill this need.

The development process is now complete and we are on the hunt for the first reference client.