Related Podcast: Peter Armstrong - Thinking Out of the Cubicle

Life in an IT department is not a bunch of fun nowadays. There is constant pressure from above to reduce costs, which results in people looking at options like outsourcing and offshoring. So, many (including DBAs) run around trying to protect their own jobs, and tend to lose sight of the bigger picture. Using offshoring or outsourcing to save money is often a quick way to lose money. For instance, how many offshore operations are motivated to reduce the number of incidents? How many outsourcers understand the relative priority of incidents? Offshoring and outsourcing can have a role to play, but greater benefits can normally be achieved by going back to first principles. If DBAs want to keep their jobs, they need to raise the profile of what they are doing. IT staff cannot afford to keep their heads in the sand and be seen by executive management as a cost centre.

Why Do We Use IT?

At the end of the day, the reason a business uses IT should be because it enables that business to deliver service to a user more cheaply, more efficiently, for longer hours, and so on. In other words, it is using IT as a business tool. So, IT needs to understand that its sole function in life is to enable the business to run better.

However, the IT department is between a rock and a hard place as they are being told to reduce costs. When budgets are restricted, the most important factor (and the one that often gets pushed down the list) is actually quality of service. Business managers come to IT and ask for 24x7 service. The IT department and the DBAs get excited about online copies, dynamic change, dual data centres, and so on, and have missed the fundamental questions: Why do you want 24x7, and how much is it worth to the business? Do you really mean 24x7, or can I have five minutes of downtime once a week or once a month? What level of service does the business really need, and how much are you prepared to pay for it?

Some managers see low cost and high quality of service as being mutually exclusive, but this need not to be the case.

Enter Best Practices

Many companies are now successfully using best practices like ITIL® to deliver a better level of service at lower cost. ITIL (IT Infrastructure Library) provides a framework of “best practice” guidance for IT service management and is the most widely used and accepted approach to IT service management in the world. Just over five years ago, the British Standards Institute took ITIL and made it a BS15000 standard worldwide for IT Service operations and management. This year, the International Standards Organisation (ISO) has declared ISO20000 the new international standard based on BS15000, and this new standard has now been released.

So, What is ITIL?

ITIL is a set of books, written predominantly by customers, giving best practice information on the various disciplines of running IT. Many people, when talking about ITIL, actually only talk about Service Support and Service Delivery — ITIL goes way beyond that:

1. Planning to Implement Service Management. This book answers the question, “Where do I start with ITIL?” It explains the steps necessary to identify how an organisation might expect to benefit from ITIL and how to set about reaping those benefits. It helps organisations to identify their strengths and weaknesses, enabling them to develop the former, and overcome the latter.
2. The Business Perspective. This book is concerned with helping business managers to understand IT service provision. Issues covered include business relationship management; partnerships and outsourcing; continuous improvement; and how to exploit Information, Communication, and Technology (ICT) for business advantage.
3. Service Delivery. This book covers the services that business requires of the provider to enable adequate support of the business users:

• Capacity Management
• Availability Management
• IT Service Continuity Management
• Service Level Management
• IT Financial Management

What Does All of This Mean to Me?

What all of this really means is that you have to start thinking about who is using the systems you’re administering. Most IT systems are measured and designed from the point of view of the IT department, and this is totally wrong. The systems are there to service end users, so they should be designed and measured from the end-user point of view.

If you are a DBA, and you are working on the reorganisation of a database, for instance, you should be asking questions such as:

• Why are you doing this task?
• What priority does it have from a business point of view?
• Who is impacted if I take the database offline?
• How long can I afford to have the service unavailable?
• Is this the most important thing I could be doing now, from a business point of view?

Who is using your IT systems? Why are they using them? What are you trying to sell with them? Is it easy to contact you if there are problems? Is the data up-to-date? Are the systems available and performing well? What are the availability and performance requirements (some systems perform better than what the business actually requires, which is a waste of money)? Do you have Service Level Agreements (SLAs) in place, and are you measuring against them? Are you measuring from the end-user point of view, or from your own point of view?

Service Level Agreements

The cornerstone of any managed services contract is the service level agreement. This agreement is meant to be the yardstick that measures how IT (a.k.a., the “service provider”) performs, but unless the agreement is written and reported on with measurable and meaningful values, it can lead to very difficult situations.

The more vague the service level agreement, the more chance of confusion about what should be, and has been, delivered as part of the contract. Service level agreements should be written with factual, measurable metrics included, and the “service provider” should regularly provide detailed reports based on these metrics.

The most common metrics tend to relate to issues such as call-response times and mean-time-to-repair faults. However, valuable as these are, they are measures after the fact. Never having to call in the first place because there are no problems is better than having access to good call-response times. Service level agreements should be based on service availability and performance — not just how fast is the reaction to failure. In fact, SLAs should really be based on what the business needs; most of the time, they are written from a pure technology point of view. These are not SLAs — they are internal IT operational agreements, not a description of what the business needs.

A Change of View?

IT departments tend to think from the bottom up, typically about databases, networks, job schedules, and so on. The line of business manager, on the other hand, is thinking about whether the back office functions are running, whether the customer-facing processes are operating efficiently, and what sort of service is being provided to the business partners.

A business service depends on a set of processes to ensure that it is executing and performing as expected. In not-yet-automated business services, the management is done primarily by business-side managers. When business services are automated, the IT department has to manage the infrastructure and software applications. This translates to the fact that some or all of managing the business execution is transferred to the IT organisation, and hence, businesses should understand that IT management is an integral contributor to the success of the business.

Automated business services provide many benefits. However, they also bring with them considerable inherent risks. Computing infrastructures are extremely fragile and “dumb” by nature, and all different. Due to the considerable inherent risks associated with IT-based business services, it is vitally important to the business that the environment in which the business service will execute is managed extremely well and cost effectively toward business needs and expectations. The most effective method to date to manage automated business processes is through a set of mature IT management disciplines like ITIL.

Just Buy Some Tools and Get Rid of the People?

Some IT departments see tools merely as a way of reducing their cost of operation by reducing the number of people required to manage the environment. However, using tools to manage technology can greatly increase the availability and performance of the infrastructure. By exploiting the functionality within the toolset and applying that functionality to best-practice standards such as ITIL, the business — and ultimately, the customer — receives the benefits.

This means that not only must IT and business learn to talk to each other, but they also need new tools to make their life business oriented. When a component fails or performs badly, you need to see the impact from a business point of view rather than a technology point of view. If you give IT staff five problems, they will typically work on them in a first-in, first-out order; they don’t have any information to tell them not to do so. When you add in a business criticality view, the order in which problems are resolved, performance tuning, infrastructure investment, and so on, becomes totally different, and IT begins to build value for the company, and so, will be perceived as a valuable resource for the company.

By implementing sensible IT processes, combined with business-related tools and methodologies, the business advantage is the true, and correct, exploitation of the company’s IT investment. This is why business and IT must  communicate far more effectively than they do today, and why it is so critical that IT staff, including DBAs, must understand why they have a job. To quote from ITIL, there are three key objectives of service management:

1. Align IT services with current and future needs
   • of the business
   • and its customers
2. Improve the quality of IT services delivered
3. Reduce the long-term cost of service provision

If you work from those objectives, the whole perception of the IT department will move from being a cost centre to being a business service provider, and your job will be secure.

--

Peter Armstrong joined IBM in 1976 and was the UK Country IMS specialist. He helped design parts of DBRC and wrote the Recovery/Restart procedures for IMS disk logging. He joined BMC Software in 1986; these days, he is a corporate strategist, responsible for the increasingly important domain of how business and information technology need to work together. Peter is also a prolific writer; he has authored Database Recovery Control (DBRC) in Practice, and maintains an active blog, Adopting a Service Mentality.