Introduction
In
The Canterville Ghost (1887), Oscar Wilde wrote: “We
have really everything in common with America nowadays except, of
course, language.” I have an English-American/American-English
dictionary in front of me as I write this, and have learnt over the
years that Americans think chips are crisps, whereas we British expect
them to come covered in salt and vinegar and wrapped in a piece of
newspaper. However, I digress.
All of
this musing came about because I have the distinct feeling that IT
and business people speak two totally different languages.
Business
— “IT spends too much and delivers nothing.”
IT
— “They give me no budget and expect Rolls Royce service.”
Business
— “I don’t have time to learn all that techy nerd
stuff.”
IT
— “I don’t understand all that business mumbo-jumbo.”
Business
— “I never understand the IT part of our board meetings.”
IT
— “I never understand the business part of our board meetings.”
Business
— “All I get from IT is a string of reasons why they can’t
do what I want without lots of cash.”
IT
— “They never invite me to explain what IT is doing
/ can do for them.”
Both
— “I just get the blame for everything that goes
wrong.”
Let
me try and explain why IT and business have to learn a common language
and talk about some of the steps you need to undertake to get IT really
working for your company.
A
Typical Scenario
Your
IT department has spent days gathering all the information on server
availability, and has come to the board meeting ready to prove that
they have been delivering 99.99% availability for the last week and
cannot understand why anybody is complaining.
Unfortunately,
the application is being used by online options traders who need a
response time of less than 12 seconds in which to make a trade. Availability
is meaningless to them without performance (a bit like giving me a
Ferrari with no petrol in it: I am sure it is beautiful and works
well, but frankly it is absolutely useless to me as it stands).
This
is a simple example (which, actually happened), and you would think
that it was obvious from both sides what was going on. The problem
was that no one thought of explaining the issue in terms that the
other side would not only comprehend, but also act upon sensibly.
Had the IT department understood the fact that trades have a very
short time in which they can be made, then the design of the system
would have been totally different. However, would they then have had
the chance to present the options available?
Many
IT departments focus on the technology and delivery of availability
of platforms, databases, and applications. Although all of these are
important, it is how these elements interact to provide a business
service that is the key issue. It is vital that the IT department
understands not only the technology, but also the way that the technology
interacts to deliver service. Dealing with technology in isolation
can lead to huge problems when it comes to diagnosing service outages.
Say you
are a car manufacturer who has just had the opportunity to try out
one of your competitor’s offerings, and you think that their
paint finish (or whatever) is better than yours — what do you
do? You go to the manager in charge of the production line, give her
a sample of the competitor’s product, and ask why you haven’t
got the same quality. That manager will probably go away and do some
cost estimates for various levels of finish, and present them back
to you, possibly with some samples to match, and you will make a business
decision based on costs, possible increased sales, and so on. Each
side can rapidly understand what the other side wants.
The question
is, if you were to ask your IT department about, say, availability
for your applications, would you get the same level of response, or
an answer couched in language that you don’t want to hear, leaving
you thoroughly confused? Does IT truly understand your business requirements
and the options that it should be evaluating? Have you explained to
them what you want in terms that they can understand?
Where
the Problem Comes From
Background
IT managers
and business managers have tended to be different types of people
with different training. More and more, the need is arising for each
party to be “trained” in the other’s area of competence.
This does not mean that business managers have to understand control
blocks and log records, but they do have to understand that disaster
recovery, for instance, can have multiple solutions involving varying
levels of expense. How much data are you prepared to lose, how much
time are you allowed for the recovery, how much money do you want
to spend? The IT department can provide a solution if they are armed
with the necessary business requirements, but they must also present
the options in a clear and non-jargon-ridden way. They similarly need
to have a fundamental grasp of business thinking. This is why more
and more CIOs are being taken from the lines of business rather than
a pure IT background, but they must be prepared to learn enough of
the IT language to truly understand what is going on, and the IT department
must learn how to communicate their options (and frustrations) to
the CIO.
Mainframe
to Distributed
The IT
landscape has also become infinitely more complex. In the old days,
you put in a big, central box — a mainframe — attached
dumb terminals to it on a network, and that was it. The advent of
distributed computing, with multiple storage options, all sorts of
networks, and a plethora of ways to join it all together, has made
it difficult for the IT manager (let alone the business manager) to
keep track of all the options.
Dot.com
Madness
Next
came the era of dot.com madness, when systems were installed because
it was possible to do so, not because this made sense. This meant
that IT got the reputation of being able to do anything, but also
the reputation for spending huge amounts of money with little (or,
probably, negative) financial return. This era, thankfully, is now
over. However, the pendulum has swung violently the other way, with
all technology spending being seen as an extravagance, and with an
almost frenzied demand for the IT department to squeeze every last
drop out of the investment they have made already.
Obsolescence
Unfortunately,
all computer equipment is designed with inbuilt obsolescence, and
if you lag too far behind, it is difficult to get spare parts, maintenance,
and so on. Also, user demands tend to escalate almost exponentially.
In the old days, there was little or no direct contact with the end
user, and hence, you could implement simple systems with crude interfaces,
to be used by internal personnel only.
Then
came the Internet revolution, and suddenly your systems were being
presented directly to the end user, who wanted graphics, sound, video,
and more. As a result, your network demands changed dramatically,
the amount of data you had to store (for all those digital pictures
and videos and audio clips) went through the roof, and you wondered
what happened to all that money you spent on IT infrastructure.
How
We Should Use IT
Requirements
Back
in the “good old days” (actually they weren’t totally
good, but at least we did not have to watch those awful reality TV
programmes), computer systems were usually designed based on user
requirements. This approach got completely ignored for some years
during the great dot.com fiasco, when a new method was used:
Can
it be done technically?
>YES, then do it and spend lots of money.
>NO, try to do it anyway, and spend lots of money.
You will
notice a frightening lack of business principles being applied here
— will it save me money, will it make me money? Not difficult
questions, but basically fudged for many years as they were made up
from weird and wonderfully inaccurate, meaningless projections of
how we were all going to use e-systems 24 hours per day and could
not live without them. Not surprisingly, IT developed a reputation
for spending money on stupid systems for reasons that were neither
clear nor justified. A lot of the people in the dot.com arena were,
unfortunately, technically brilliant, but totally business-naïve.
People
then got more and more paranoid about what systems they should be
using. Magazine management became common — “it says in
this magazine that UNIX/Oracle/SAP/SQL server/LINUX/Java/XML/SOAP/Web
Services/whatever is the cornerstone of the future, we must have it.”
All of these are excellent in the right environment — but are
they necessarily the correct solution for every application? No. The
fact that someone else is using a particular combination does not
mean that you should be using the same combination — the only
advantage is that they may find the bugs (errors) first.
System
Choice
So, what
system should you be using? The only answer that I can categorically
state as being correct is that there is no correct answer to this
question. The choice should be based on the requirements, and they
will include interface, performance, ease of use, availability, cost,
and so on. Do not get hung up on what other people are running. Yes,
you want to know if the combination works, but the fact that someone
else is running a particular combination does not mean that it is
correct for you.
There
has also been a dreadful fear that you might be missing out on something.
A few years ago, a lot of IT decisions seem to have been driven by
magazine articles and comparison with other companies as opposed to
the fundamental requirements of the business.
There
is no single combination of platform, operating system, database,
and so on, that is correct for all applications. Every business will
run something slightly (or significantly) different, and that is correct
for that business.
Service
At the
end of the day, the reason you are using IT should be because it enables
you to deliver service to a user more cheaply, more efficiently, for
longer hours, and more. In other words, you are using IT as a business
tool, not to keep some IT techy happy. There are no IT projects nowadays;
there are only business projects, which may or may not use IT.
So, IT
needs to understand that its sole function in life is to enable the
business to run better. This means that it is either helping to reduce
costs, and/or helping to increase revenues. If it is not achieving
either of these functions, then why are you using it?
Of course,
the IT department is between a rock and a hard place as they are being
told to reduce costs. So, what is by far the most important driver
for IT — quality of service — is also the one that often
gets pushed down the list of selection criteria when budgets are restricted.
Some
managers see low cost and high quality of service as being mutually
exclusive, but this need not to be the case. By using best practices,
leveraging economies of scale and focusing on service delivery, IT
departments really can deliver on their promises.
This
also means that you have to start thinking about who is using the
systems. Most IT systems are measured and designed from the point
of view of the IT department, which is the totally wrong approach.
The systems are there to service end users, so they should be designed
and measured from the end-user point of view. The following are two
examples to show you what I mean.
A few
years back, my UK bank wrote to me offering 24x7 online Internet banking.
Because I travel the world, and the ability to handle my bank accounts
whilst on the road is very useful to me, I signed up. I started using
the service, and it was frankly awful. It was nearer 19x6 than 24x7,
the performance was poor, and the system was frequently down for hours
at a time. So I used one of my company’s products to measure
the service from my point of view, printed the reports and took them
to my bank manager. His response? “Thank you, Mr Armstrong, I
have been asking for reports like this for years, you are the first
person to show me what you are seeing. Can I have a copy?” I
gave him a copy and also told him what was causing the problems (one
of my colleagues used to work for them and knew what was wrong). I
am glad to say the problems have now gone away, the users are much
happier, and they now have an online service that is competitive,
and is saving them money. And yes, I am a lot happier and decided
to remain a customer.
Probably
the longest-running, and in my opinion, best e-business service, is
the ATM (cash machine). Here is the intelligent application of technology
to provide a useful service to the end user, that saves transaction
costs (it is much cheaper to service me via an ATM than via a human
being in a branch of the bank).
Part
2: “How Good is My Service?” and other questions ...
About
Peter Armstrong
Peter
Armstrong is the corporate strategist for BMC Software, Inc. (NYSE:BMC)
with specific responsibilities for the increasingly important domain
of how business and information technology need to work together.
Peter has helped to develop the company’s Business Service Management
(BSM) strategy. In his current role, he is responsible for educating
BMC Software’s customers and employees, the media, and analysts
about the company’s vision and strategy. Peter joined BMC Software
in 1986 after ten years with IBM, where he was the country specialist
for IMS, specializing in disaster recovery. During his tenure with
BMC Software, he has helped set up the UK office, led the European
Specialist Group, and helped establish the BMC Software Business School.
Peter works for BMC Corporate in the US, but is based in the UK and
works closely with the European Management Team. He spends most of
his time traveling the world, meeting and talking to customers, to
understand where the marketplace is going. Peter is a renowned speaker,
and is well known throughout the world as a presenter, educator and
author.
