Climbing the SLM Maturity Ladder

Last week, one of my posts introduced Peter Armstrong's paper about IT-Business alignment. BMC has just published a new whitepaper by Peter -- Taking IT to the Next Level -- about the challenges IT organizations face as they evolve from a cost center to a creator of business value.

Peter uses the Gartner IT Management Process Maturity Model, pictured above, to represent the five possible maturity levels of IT organizations. This is an excellent way for companies to measure their progress in implementing systematic Service Level Management (SLM) processes. In his whitepaper, Peter is focusing on climbing the ladder from Level 3 (Proactive) to Levels 4 (Service) and 5 (Value).

It occurs to me that a Maturity Model may be the corporate equivalent of a Twelve-Step Program -- to get better you must first admit you have a problem. That's why so many companies are still stuck at Level 1 (Chaotic), while others who are forever coping with the problem of the day at Level 2 (Reactive) would be really happy to establish to firm foothold at Level 3!

Web Usability Books [4]

Today I am continuing my review of Web Usability books, from the perspective (described here) of someone who believes that Performance Matters:

4. Usability for the Web by Tom Brinck, Darren Gergle, and Scott D. Wood

Subtitled Designing Web Sites That Work, this book is about managing the design process, with the term design being used in its widest sense. In the introduction, the authors define Usability as the product of several design goals: functionally correct, efficient to use, easy to learn, easy to remember, error tolerant, and subjectively pleasing.

I particularly like the emphasis on the process of producing and maintaining a Web site. While The Design of Sites contains an introductory chapter summarizing the steps of the development process, here those steps are used as the central organizing principle for the book. On his own site, lead author Tom Brinck explains why:

Darren, Scott, and I were all involved in the genesis of Diamond Bullet Design, a web design company founded in 1996 with the goal of bringing usability to the web, and together we worked out how a web design and development process should reflect usability at every stage, while making this a feasible process within the business constraints of actual development.

The book's introduction continues:

To ensure high usability on our own Web projects, we defined a development process that incorporates proven techniques from software and usability engineering, graphic design, project management, and other disciplines. The process had to be practical and lean. It had to allow us to work on multiple projects of varying sizes with fixed budgets. It had to help us keep track of the details that can kill usability and destroy profitability. This book is about that process.

Tom's site provides some more detail:

Usability for the Web provides a comprehensive approach to the web design process, with a devotion to the principles of usability. The book is intended for web professionals and students of web design, with a practical focus.

The book is organized into 6 sections, according to the activities of the design process: Requirements Analysis, Conceptual Design, Mockups and Prototypes, Production, Launch, and Evaluation. We view Evaluation as an ongoing activity throughout the process, which is integrated at every step. Detailed chapters cover topics such as defining the target audience and target platform, user needs analysis, task analysis, information architecture, visual design, writing, software development incorporating usability, quality assurance, user testing, and usability inspection.

Numerous forms and checklists are included that are straightforward to apply in real-world design situations. These forms are designed to create a reliable, complete, and repeatable design methodology.

The publisher, Morgan Kaufmann, lists the target readership for this book as Web site designers and developers, Web site project managers, usability specialists and information architects, user interface designers, and graphic designers. While any of these readers may want yet more detail about their specialty, this book does provide almost 500 pages of carefully selected, well organized, well written, and attractively presented material. Indeed, the book itself is a fine testament to the integrity of Tom Brinck's stated Usability Philosophy.

Finally, for those interested in Performance Matters, the authors devote a full chapter to Usability in Software Development. This includes a statement about the crucial importance of Response Time, a short discussion of what contributes to it, and a sidebar on Why Software Engineers are Critical for Usability.

Granted, one 24-page chapter cannot cover the subject of performance properly. But this is the only book on usability I have ever seen that explains 3-Tiered Architectures, and how to map the flow of control and data through those tiers using static design diagrams and dynamic request traces. And its discussion of latency diagrams highlights the need for a systematic way of analyzing where the time goes, like the one I wrote about in an earlier post on The Web Site Response Time Model.

After reading the story of Tom Brinck's diverse background (Apple, Stanford MS in Computer Science, Toshiba, Bellcore, Michigan MA in Psychology, founder of Diamond Bullet Design), it is easy to understand why his ideas about usability and his book are so balanced and well rounded.

Thoroughly recommended!

[Next book review: Speed Up Your Site ...]

Web Usability Books [3]

Today I am continuing my review of Web Usability books, from the perspective (described here) of someone who believes that Performance Matters:

3. The Design of Sites by Douglas K. Van Duyne, James A. Landay and Jason I. Hong

As its title suggests, this book is written for anyone involved in the design of a Web site. In the preface and on their site the authors say: Its focus is tilted more toward Web design professionals, such as interaction designers, usability engineers, information architects, and visual designers. Since the book comprises over 800 pages of densely-packed design advice, its main audience is pretty clear.

But the authors claim that it is a resource for anyone on a Web development team, from business executives to advertising managers to software developers to content editors. Its value to this wider audience is well explained by Mike Tarrani in his "spotight" review of the book on Amazon, so I will intersperse Mike's comments below:

Tarrani ... Nearly every book on user interface and site design I've read is aimed at the professional designer who understands the nuances of color, fonts and graphics elements, as well as aesthetics in general. Many of the subtle points are lost on the non professional.

The first 100 pages (Part I) are devoted to Foundations of Web Site Design, and include chapters on Knowing Your Customers, Involving Customers with Iterative Design, and the Site Development Process. The authors describe the last of these as ... a rough guide to designing, implementing, and maintaining a Web site. I concur -- it is a useful summary of the major stages, but no more than that. The real meat of the book is Part II, which comprises 517 pages. Here, 91 Design Patterns are organized into 12 pattern groups (A-L), and illustrated with examples of real Web sites.

Tarrani ... It leads you through each example, showing you how a particular design or design concept works and why. This is akin to the Rosetta Stone for the non-professional designer because the authors do not assume any talent of skills in design, and subtle points are highlighted and clearly explained. Because of this approach I finally understood concepts that had eluded me in the past.

In addition to the clear explanations that distill design into patterns, the book is lavishly illustrated, using copious full color examples and a structured format that gives the background, frames the problem and provides a solution to each of the 12 design goals.

Not everyone agrees, of course. If you study the Amazon reviews, you'll find a few that rate the patterns as shallow, incomplete, or out-dated. But that is inevitable given the authors' approach -- a book like this can never be complete or up-to-date, because the technology and people's use of it is a continually moving target. In fact, the authors state this in their introduction to Part II. In my view, they made a valiant attempt to classify important Web design patterns, and the great majority of reviewers do find a lot of value in the result.

Tarrani ... Material in the appendices is also invaluable, including advice on running usability evaluation, and associated plan outlines and forms. For a development group this is an extra bonus that will make it easier to incorporate the principles in this book into a quality process that gives customer-focused usability the same weight as technical quality criteria.

I'm so enthusiastic about this book that I've recommended to the company for which I work that a copy of this book be provided to each of our developers who are programming wizards, but who stumble when it comes to the user interface.

My own special interest in Performance Matters is served by the last pattern group, Speeding Up Your Site, which comprises five patterns: Low Numbers of Files, Fast Downloading Images, Separate Tables, HTML Power, Reusable Images. While these are not original or surprising, they certainly do address some of the most common page design problems that can affect performance.

[Next book review: Usability For The Web ...]

Web Usability Books [2]

Today I am continuing my review of Web Usability books, from the perspective (described here) of someone who believes that Performance Matters:

2. Designing Web Usability : The Practice of Simplicity by Jakob Nielsen

Jakob Nielsen is a famous usability guru. He writes, speaks, and consults on Web site design and usability, and his 1999 book is a classic. It is surely the best-seller on this subject, having been translated into 21 languages. According to the New Riders Press publisher's introduction over 250,000 Internet professionals around the world have turned to this landmark book. Nielsen's site lists plenty of good reviews, this one from BusinessWeek being just one example:

KEEP IT SIMPLE. Nielsen ... is a usability engineer and Web-design consultant given to strongly held ideas and sweeping statements, like fast response times are the most important criterion for Web pages. His certitude might be insufferable if he weren't right so much of the time.

The basic principles of good design, according to Nielsen, are very simple: If your pages don't load quickly, your customers won't wait. If customers can't find what they want, they won't buy it. If your pages are confusing or hard to read, customers will look elsewhere.

But while easy to state, such general principles are very hard to implement. Here Designing Web Usability shines, with hundreds of screen shots of actual Web pages, successful and unsuccessful, with a narrative that highlights just what their designers did right or wrong. You'll probably find plenty to disagree with in Nielsen's conclusions. But you whether you're a designer or someone with responsibility for your company's online presence, you'll come away from the book with a much deeper understanding of how to use the Web as an effective sales and communications tool.

Yet, as BusinessWeek hinted, Jakob and his book generate strong opinions both pro and con. The book's subtitle, The Practice of Simplicity, sums up his world view, and also accounts for much of the controversy. Jakob writes in his book's preface:

I wrote this book with two clear goals. The highest-level goal was to improve quality of life by reasserting humanity's mastery of technology. On a day-to-day basis, you may think of usability as a way to increase sales (for public websites) or productivity (for intranets), but in the aggregate, if we make websites and intranets easy to use, we will increase users' quality of life by eliminating a lot of frustration and the feeling of inadequacy that follows every time you are stumped by a computer.

My more immediate goal was to promote a new philosophy of web design: simplicity. When the book was originally published, this was a controversial goal and I was often in the distinct minority at industry conferences. Eyeballs ruled the day and it didn't matter much whether users could actually accomplish anything. I am now happy to declare victory. Usability has become accepted as an important component of almost all professional web design projects, partly as a result of the success of this book, but mainly because it works.

On the second page of Chapter 1, Jakob writes:

Art Versus Engineering: There are essentially two basic approaches to design: the artistic ideal of expressing yourself and the engineering ideal of solving a problem for a customer. This book is firmly on the side of engineering. While I acknowledge that there is a need for art, fun, and a general good time on the Web, I believe that the main goal of most Web projects should be to make it easy for customers to perform useful tasks.

As you can imagine, I am in violent agreement with this viewpoint! However, Jakob's approach to Usability comes in for plenty of criticism from his own profession. To see why, you need only browse Jakob's web site. People like me who use the Web primarily to find information, and who value responsiveness, don't mind the way it looks, as long we can find what we are looking for. But most designers and graphic artists, who value aesthetics, hate the rather primitive appearance of Jakob's site -- and as a result probably feel justified in ignoring his advice.

For examples of their views, scan the Amazon book reviews. A blog post, on How Usable is Jakob Nielsen? by usability professional Frank Spillers, which is referenced in Jakob's Wikipedia entry, provides a good summary of the anti-Nielsen viewpoint. And Spillers' company, Experience Dynamics, has a simple, responsive, and nicer-looking site, too!

Having said that, this is a book review and not an assessment of Jakob Nielsen's place in the pantheon of Web designers -- if there were an actual Pantheon for these modern-day gods, he would surely have a place.

Jakob makes no pretense of offering advice on how to construct a site, saying ... this is not a book about HTML or how to draw an icon or other Web implementation technology. But he does devote 9 pages of his chapter on Page Design to discussions of the importance of fast and predictable response times, quoting Robert B. Miller's classic 1968 research paper on Human-Computer Interaction, which I wrote about previously. So I recommend this book, not just because of its classic status, but for the emphasis Jakob places on the Responsiveness dimension of Usability.

[Next book review: The Design of Sites ...]

Web Usability Books [1]

I have twice promised to recommend books on Web Usability, so it's about time I got on with it. I have organized the books I like on a scale from simplest to most comprehensive. Today I will review the first, and simplest, of my recommendations.

Before we start I have to point out that I am not an expert in the subjects these authors devote most of their pages to, which I have labeled Clarity in my four-dimension usability model. My particular interest in writing these reviews is not primarily in the authors' expertise in the Clarity dimension, but in the extent to which they also acknowledge or discuss the dimensions of Availability, Responsiveness, and Utility.

[To understand what I mean by that, you must first read at least yesterday's post on The Dimensions of Usability. The previous post, where I introduced this model, was Web Usability: A Simple Framework.]

That is not to say that I am completely ignorant about their subject matter, either. I own a copy of each book I will discuss. I did my homework before buying them. I have spent time studying them. So I don't have a problem in offering my observations about their content. It's just that I do not have to use a lot of this material on a day-to-day basis in the course of my job. So think of my reviews as Web Usability books for people who don't already specialize in it.

1. Don't Make Me Think, by Steve Krug

Subtitled A Common Sense Approach to Web Usability, this is an excellent introduction to the subject. It is widely praised for its simple approach -- in fact, it's hard to find a bad review of this book anywhere, starting with over 250 reviews on Amazon. At under 200 pages, the worst criticisms are from people who think it should be longer. Published by New Riders, the style and mix of text and illustrations is similar to the Visual QuickStart Guide Books from Peachpit Press. If you like those, you'll probably like this. The first edition that everyone likes was published in 2000, but you can see from Steve's site that he has a 2nd edition just out. I have ordered it but not seen it yet. Apparently it is updated, and is about 30 pages (and three chapters) longer. If you're buying a copy from Amazon anyway, you can double the author's royalty by ordering it though his site.

Finally, as you might have guessed from its title, this book is all about site Clarity. It doesn't have anything to say about Availability, Responsiveness, or Utility.

[Next book review: Designing Web Usability ...]

The Dimensions of Usability

Whenever specialists attach technical meanings to everyday words, they tend to create confusion and make their profession harder to penetrate. Some professions are masters of this. If you heard the words party, service, and cases in a sentence you might be looking forward to a celebration -- unless they were spoken by your lawyer.

In the world of information systems, Usability is a case in point. Model is another -- especially since it can be a noun, a verb, or an adjective. All the same, today I am going to use a model to help me discuss the concept of usability!

In a previous post, I presented a framework for thinking about Web Site Usability. I divided usability into four dimensions, each of which is essential to the ultimate success of any site -- Availability, Responsiveness, Clarity, and Utility. The graphic illustrates the four dimensions of usability, and its layout reveals some further characteristics (Technical or Functional, Core or Refinement) of the four dimensions. This further classification scheme is not strictly essential to an appreciation of the underlying four-dimension model, but may be helpful when thinking about differences among the four aspects.

Horizontally, the Functional dimensions pertain to the purpose of a site and how it is used, the Technical ones concern its construction and delivery. Vertically, the dimensions I have labeled as Core represent the essential implementation of a site's function or of its delivery, the ones labeled as Refinement represent the form (or quality) of that implementation. For the architecturally minded reader, this distinction follows the classic saying of architect Louis Henri Sullivan that Form ever follows function. For the engineering-minded, the practical implication is this -- why worry about responsiveness if your site is not available consistently, and why work on refining the user interface if the site does not deliver the function the user needs?

Having said that, in practice people do recognize the need to address all four dimensions of usability, and tend to think about them about independently, and to work on them in parallel. This turns out to be both good and bad. It's good because it allows specialists in each of the four areas to focus on what they do best. Typically this means that:

• Business experts provide the content or specify the behaviors that are the site's purpose (Utility).
  
• Design and Usability specialists make it easy for customers to navigate the site (Clarity).
  
• Site developers build the site in ways that determine download speed (Responsiveness).
  
• IT staff manage the systems that keep the site up and running (Availability).

But this division of labor also has a drawback -- it encourages Web Usability professionals to focus almost exclusively on what I call clarity. In fact, they have expended far more energy on internal debates about issues such as design vs. usability than on incorporating a focus on the other dimensions.

In one sense, I am objecting to something that is simply a matter of semantics. The English language meaning of usable (with a small 'u') is more inclusive than the professional definition favored by Usability experts (with a capital 'U'). As my opening paragraph implied, it may be confusing, but I can't expect an entire profession to redefine itself just because I don't like their choice of terminology! But given this difference in scope, it is interesting to see that the International Organization for Standardization (ISO) actually does define usability in a way that seems (on the face of it) to be closer to the viewpoint of a business:

ISO 9241-11: Guidance on Usability (1998)

Usability is the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

This standard (which is part of the ISO 9241 series) provides the definition of usability that is used in subsequent related ergonomic standards.

ISO 9241-11 explains how to identify the information that it is necessary to take into account when specifying or evaluating usability in terms of measures of user performance and satisfaction. Guidance is given on how to describe the context of use of the product and the measures of usability in an explicit way. It includes an explanation of how the usability of a product can be specified and evaluated as part of a quality system, for example one that conforms to ISO 9001.

It also explains how measures of user performance and satisfaction can be used to measure how any component of a work system affects the quality of the whole work system in use.

Ultimately, what really matters to the business owner is their site's utility -- the degree to which customers can achieve specified goals with effectiveness, efficiency and satisfaction. And unless you address all four dimensions of usability, you will not accomplish that. Rather you will drive away all but your most loyal customers, and those who are forced to use your site for other business reasons. Those who have choices will not be satisfied. They will abandon your site and find other ways to get the job done.

At least where Web sites are concerned, the Usability profession has defined its role more narrowly. Most articles and books on Web Usability focus on the (many) aspects of clarity, and make only passing references to the importance of the other three dimensions. In my opinion, if writers and teachers would adopt the rather broader scope of the ISO definition (and that of the English dictionary), it would help to promote a more holistic Web site development process, and lessen the chance of the other dimensions being downplayed.

Some authors have done better at this than others. Tomorrow I will review a few books by leading authors on Web Usability, in the light of the four-dimensional Usability Model.

Armstrong on IT-Business Alignment

If you research the business case for SLM on the Web, eventually you're sure find yourself reading something published by NextSLM.org, a site sponsored by BMC Software. One contributor is a former colleague of mine, Peter Armstrong.

Peter and I started our careers at IBM UK in the 70's as SE's supporting IMS customers. Although information technology has evolved a bit since then, our interests apparently have not diverged much. Peter now writes a blog called Adopting a Service (Management) Mentality, which focuses on the increasingly important domain of how business and information technology need to work together -- the area he is responsible for at BMC.

Buried in the archives of the NextSLM site is an essay by Peter entitled Why IT and Business Need to Talk: Two Nations Separated by a Common Language? I will extract some key paragraphs, adding my own emphasis in each section. Written (as best as I can tell) in 2003, it is peppered with stories of IT and business not communicating, for example:

Your IT department has spent days gathering all the information on server availability, and 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.

Peter sets out to explain why IT and business have to learn a common language. He writes about the cultural and historical reasons for the divide between the two sides, and the challenges they face in achieving the much-desired state of alignment. Being familiar with how IT works, he observes that:

Many IT departments focus on the technology and delivery of availability of platforms, databases and applications. But 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 ...

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 it is helping you increase revenues ...

However, the IT department is between a rock and a hard place as they are being told to reduce costs, and by far the most important factor is actually quality of service. But when budgets are restricted, it is also the one factor that often gets pushed down the list of selection criteria. Some managers see low cost and high quality of service as being mutually exclusive but this need not to be the case.

This article claims to be the first of two parts, but its link to the second part -- How Good is My Service -- is broken. But Google found me this PDF, which seems to contain the original essay before it was split into parts. In the second half, Peter discusses several aspects of SLM. Looking first at Web sites, Peter highlights how vital it is that companies doing business online understand their customers' point of view. Someone needs to ask:

Who is using your IT systems? Why are they using them? What are you trying to sell them?

Is it easy to contact you if they have problems? Is the data up-to-date?

Are the systems available (and this includes performance)?

What are the availability and performance requirements (some systems perform better than required, 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?

Turning his attention to service management and the nature of SLA's, Peter writes:

The cornerstone of any managed services contract is the service level agreement. This is meant to be the yardstick that measures the performance of the service provider, but unless the agreement is written and reported on with measurable and meaningful values it can lead to very difficult situations ...

I was visiting a major customer last year, whose IT operations are outsourced to one of the major outsourcing companies. The contract is, of course, couched in terms of CPU (processor resources) used, number of housekeeping jobs run, number of tape mounts etc. -- totally and utterly wrong in my opinion. The bank wants a service -- how the outsourcer actually implements it technically should be of no concern as long as it is safe, reliable and conforms to the business SLAs ...

Reporting is another critical area that can get overlooked. A good IT department will not only provide good service but also prove it by providing meaningful reports. These reports should relate directly to the service being provided to the customer and also show the value that the IT department is bringing to the equation. They should be couched in language that the business people can understand -- Oracle availability is meaningless, ability to print invoices on time is significant.

Like me, Peter is a strong advocate of measurement tools, which should be deployed within a systematic SLM framework such as ITIL. [Since we work for companies that sell tools and services, you might be inclined to discount our views. But I'm sure Peter would agree with me that this is a "chicken and egg" situation -- we work for tool vendors because we believe in the value of their tools and services, and not vice versa.] Peter writes:

At a technical level the key issue is how the IT department actually proposes to manage the environment. The use of industry-leading solutions and best-practice methodologies should be common to all good service providers, but they are surprisingly often absent.

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, the use of 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.

Through implementation of sensible IT processes, combined with business-related tools and methodologies, the advantage to the business is the true and correct exploitation of the IT investment. This is why the two parties need to learn to talk to one another.

It is clear that Peter's thinking has subsequently found its way into BMC's more sanitized (and glossier) marketing materials on this topic, like his whitepaper on Seven Strategies for Enabling IT to Activate the Business, and this corporate strategy brochure on Business Service Management. But Peter's original essay reveals better the strength of his personal belief in the importance of SLM to the business.

I share that belief, and endorse his conclusions.

SLM: Learning from Dot-coms

In life, wisdom is generally thought to come with age. But in business, years of experience do not always lead to best practices. This often seems to be the case when it comes to the systematic application of performance management or service level management (SLM) practices.

Lately I've been working on the business value of SLM. In particular, I've been focusing on how to establish the value of SLM activities devoted to improving the availability and responsiveness of Web sites and e-business applications. In the process I've been speaking to several companies about how they approach this question.

Personally, as I said in my previous post, I'm convinced that there is always a good business case for SLM, if it's implemented properly. But I've spent many years advancing this proposition, so my opinion probably does not count for much. For any advocate, what matters more is the listener's own predisposition. In this case, regardless of how strongly a company seems to be embracing e-business approaches, their history and culture can still affect their readiness to embrace and justify SLM programs to support that business.

It's now more than five years since the dot-com bubble burst in 2000, wiping out billions of dollars that had been invested in speculative Web businesses. The survivors may have picked a better idea for an online business, but more importantly, they knew how to make a profit running that business. Those who did not quickly joined the ranks of eToys, Pets.com, Webvan, and hundreds of other long-forgotten companies.

At successful e-business companies, because business is conducted entirely over the Web, the value chain connecting SLM process to site usability to customer satisfaction to revenue and profits is an ever-present fact of life. At older companies, where e-business components are now being added to existing offline businesses, the corporate culture is not nearly as attuned to that e-business value chain.

Years of investment in IT infrastructure and applications were designed primarily to deliver the back-office systems that supported "bricks and mortar" businesses. Back-office systems are used by company employees, not customers. Although poorly performing applications may annoy employees, and even lower their productivity, it's usually safe to assume that they do not drive away business.

But when the company starts adopting e-business, those old assumptions must change. Older companies must learn what successful dot-coms must already know -- SLM is important, because it affects the bottom line.

Performance matters!

The Business Case for SLM

These days everyone has an opinion about aligning IT with the business. If you think I'm exaggerating, just Google that phrase and read a few of the 800+ references you get back. You will quickly see that this subject generates very strong feelings, the trajectory of which depends largely on whether the writer views the world through the prism of IT or the business.

Bob Evans summed up the strength of these feelings very well in the first sentence of his amusing Information Week column, A Trip To The Cafeteria--With The CFO! Contentious issues abound -- squeezing more productivity out of already overworked IT employees, cutting technology spending, the pros and cons of outsourcing, getting the business to understand what it takes to keep up with technological advances, not to mention Sarbox regulations. Or sometimes, just getting the business to settle on a direction, any direction -- N? E? NE? NNE? -- so that IT alignment can begin!

To express opinions hastily on this subject would be like chasing butterflies into a minefield. Fortunately, I can sidestep that minefield. The issue at the core of the debate is the value obtained by a business in return for its investment in IT. And no matter what your opinion about the politics of IT/business alignment, investing in Service Level Management (SLM) is always worthwhile.

SLM is not a passing IT fad to be adopted then discarded like the latest technical buzzword. It is an essential way to maintain and improve the quality and effectiveness of your business. And when your business is online, implementing a systematic SLM program can -- as suggested in the graphic above -- benefit both revenues and costs.

This is not a recent revelation, triggered by the debate about IT and business alignment. In 1998 I wrote an article on Controlling Application Performance: What Every CIO Should Know, which began ...

CIOs face complicated issues of data center infrastructure, a portfolio of widely differing application workloads, and rapidly changing business requirements. Strategically, CIOs need to react quickly to competition. Tactically, they must create common processes across business units to make collection and dissemination of information simpler and to slash the cost of new applications.

Compared with these concerns, application performance lacks glamour. Nevertheless, a systematic program of performance monitoring and tuning almost always produces surprising cost savings for large companies.

CIO sponsorship is vital for such a program to succeed. In the first place, only the CIO can negotiate the transfer of funds between the capital equipment, salary, and software budgets. Second, management prioritization and employee motivation are required to convince lower-level managers and technical professionals of the importance of application performance. The CIO can provide the necessary emphasis.

That article emphasized the cost savings achievable through application tuning, and little has changed since 1998 in that respect. In today's world of e-business, equally important opportunities also exist for system and application tuning efforts to increase revenues, by making an online business more available and more responsive to customers.

CIO sponsorship is still an essential first step to success with SLM, for the same reasons as before. As a CIO seeking to better align IT with the business (whatever that means this week), a proposal to beef up your SLM processes may seem at first to be just another expense to be placed under the cost-cutting microscope. Proponents of SLM programs should welcome such scrutiny. When the applications to be managed are important to the business, opportunities always exist for significant cost savings, revenue increases, or both. I would be willing to bet that the initial investment will more than pay off over time, in applications that help the business by serving customers better.

In fact, I'm convinced that there is always a good business case for SLM, if it's implemented properly. Future posts will consider some of the areas where SLM pays off, and ways of calculating the ROI of SLM investments.

Keeping a Public (Site) Healthy

Browsing the Web can lead to useful insights, even when you don't find what you're looking for. Today I was searching for information about an aspect of Web site performance management. As often happens, Google returned many links to pages where the term performance management was used in contexts having nothing to do with managing Web applications.

On one site, Turning Point, the graphic shown here immediately caught my eye. It was so obviously relevant to my world of application performance management that I studied it for a while before noticing that Turning Point ... is an initiative of The Robert Wood Johnson Foundation and the W.K. Kellogg Foundation. Its mission is to transform and strengthen the public health system in the United States by making it more community-based and collaborative.

This sounds like a worthwhile cause, but in a profession whose technical, management, and political challenges I know little about. Nevertheless, the site's definition of performance management, and its description of the four key components illustrated in the diagram, written for the world of public health, apply equally well to the task of managing your Web site health!

To demonstrate the parallels, the following paragraphs are quoted directly from the Turning Point site, except that I have made some minor edits:

Performance management is the practice of actively using performance data to improve the public's your site's health. This practice involves strategic use of performance measures and standards to establish performance targets and goals, to prioritize and allocate resources, to inform managers about needed adjustments or changes in policy or program directions to meet goals, to frame reports on the success in meeting performance goals, and to improve the quality of public health SLM practice.

Performance Management components include:

1. Performance Standards: establishment of organizational or system performance standards, targets and goals and relevant indicators to improve public health SLM practice.


2. Performance Measures: application and use of performance indicators and measures.


3. Reporting of Progress: documentation and reporting of progress in meeting standards and targets and sharing of such information through feedback.
   
4. Quality Improvement: establishment of a program or process to manage change and achieve quality improvement in public health SLM policies, programs or infrastructure based on performance standards, measurements and reports.

A Performance Management System is the continuous use of all the above practices so that they are integrated into the organization's core operations. Performance management can be carried out at multiple levels, including the program application, organization Web site, community line of business, and state corporate levels.

It seems that whatever your professional focus, you can always find parallels in other fields. Those technical details you've been wrestling with to speed up your Web site may not be a hot topic of conversation at your next dinner party. On the other hand, the process of performance improvement seems to be a concept everyone can relate to.

If you chose your words really carefully, people may not even realize you manage a Web site. Just tell them you're a health specialist -- maybe the diagram above will help with your explanation. It worked on me!

Keeping it on the Road

Yesterday I introduced the subjects of time series and probability. Today I want to show how they apply to one aspect of service level management -- working with service availability data, which you are probably collecting from several different measurement tools.

Suppose you need to improve the availability of a critical e-business application. And let's assume you have collected historical availability statistics, or estimates you are comfortable with using, for all components of your Web environment. You'll need these for the devices and services you control yourself, and for those you don't, like your ISP and its connection to the Internet. Hopefully, many of those numbers will be close to 100%. But if you are having service quality problems, at least some of those availability scores must not be good enough.

Barring catastrophic outages that bring down an entire data center, the components that support your Web applications generally operate independently of one another. That is, Web server crashes are unrelated to database server problems, which are not affected by a back-end application service being down. So if you know the availability of each one separately, it's intuitively clear that you should be able to derive an estimate for the availability of the whole interconnected system, for a given application. In other words, you can estimate of the level of application availability a customer experiences.

Here's how you can use the Web Site Availability Model to do that:

1. Based on my conceptual diagram, create a spreadsheet model listing all your services, where each row of your sheet corresponds to a service that's used to deliver your Web site or Web-based applications.


2. Check that the target application does not depend on any unlisted services. This would be most likely to happen in the bottom row, called Application Services, because what goes in that row will vary from one application to another.


3. For each separate page of the target application, set aside one column of an availability model.


4. In each column, highlight only the cells that correspond to services needed to serve that page. These cells are the only ones you will use in this instance of the model. Not every service listed is required for the delivery of every page. Simple applications may require only a small subset of the services you manage.


5. In each row of your completed model, record the percentage of down time (100% minus availability) of each service in the first cell where that service is used (highlighted). At this point, the spreadsheet is already a useful document that can help refine your focus and tackle the biggest problems.


6. Summing the percentages in each column will now give you the probability that your application will fail on any particular page. A customer may be equally upset if your home page is down, the product catalog is down, or the checkout process times out. But to improve overall application availability, you need to know which pages face the most problems.


7. Summing the column totals for whole model will tell you the overall chance of an application failure.

How's the Weather in Your Data Center?

Although it may not be immediately obvious, the above method assumes that your devices and services behave a lot like the weather in California (to use the example I described yesterday). Just substitute up and down for sunshine and rain! Service outages do not happen for a single instant, then go away. Normally a service is 100% available, but when it goes down (becoming 0% available), it is stays down for some time.

Therefore, the proposed method assumes that if a service is available the first time it's needed by any page of an application, it will remain available for all subsequent pages. Making this assumption greatly simplifies the challenge of aggregating device and service availability data from disparate sources.

If on the other hand you have reason to believe that an underlying service behaves independently from page to page of a Web transaction, the weather analogy breaks down. In that case, you have a bit more work to do to complete the cells of your availability model. First you must count the number of pages of the transaction that use the service, then you must compute the probability that none of those pages will fail when using the service.

This situation is what statisticians call a sequence of independent trials, like successive rolls of a dice. For n pages, the probability of no failures is service availability raised to the power n. For example, if a service is 90% available overall, the probability that two pages will succeed in using that service is (.9)(.9) = .81, three pages (.9)(.9)(.9) = .729, and so on. Subtracting that result from 100% gives you the percentage of down time for that service, during your application. Now proceed as in steps 5-7 above -- enter this result in the first highlighted cell (the first page requiring the service), sum the component unavailability data by page, and sum the columns to derive the overall probability of an application outage.

Note that all the possibilities for a service failure have once again been recorded in the first column (page) that uses the service, which does not matter if you are focused only on overall application availability. If you really want to estimate the probability of a particular page failing, you will have to spread the probability of failure across all the pages that use the service. This requires computing the conditional probabilities of each page failing, given that its predecessors did not. That, as they say in the textbooks, is left as an exercise for the reader.

Details, details, ...

Astute readers may have noted that my suggested method glosses over a couple of important details:

1. If you use a group of parallel servers (for example, with load balancing), you should treat the group as a single logical service in this model. The customer does not care whether one of those servers is up or down, if they can still obtain service from another server in the group. Of course, that is one reason why you are using parallel servers -- the goal is to achieve 100% availability for this service, regardless of whether an individual server is up or down.


2. In practice, customers may take different paths through your applications, where those paths (usage scenarios or use cases) require different sets of devices and services. If service availability differs significantly based on application usage, you should treat each scenario a separate application, or add weights to your model. Then you can combine the different use cases and come up with an overall availability estimate for the application. How you deal with this kind of detail will depend on your purpose in using the model.

Finally, my aim has not been to provide a rigorous exposition of data center forecasting as an application of probability theory. And I am aware that a probability is a quantity between 0 and 1, whereas percentages run from 0 to 100%. But for descriptive clarity, it seems easier and more natural to use the terminology interchangeably. But if you are actually doing the calculations, be sure to pick one or the other and not to mix them!

Probability: The Rain in Spain ...

Today I was going to write about probability theory, statistical independence, and correlation, and their importance when analyzing performance data. But I know those subjects have a tendency to induce severe attacks of fear and loathing. So instead I'm going to talk about the weather -- specifically about the difference between British and Californian weather.

When I came to the US, having previously experienced only the notorious changeability of British weather, I was quite surprised to discover that Californians enjoyed almost the exact opposite.

You may have heard the song It Never Rains in Southern California (but man it pours). And if it's sunny today, chances are good it will be sunny again tomorrow -- and probably for the rest of the week too! But during the winter months in Northern California it often rains for several days. And when it's raining, expect the rain to continue for a few days.

A friend of mine used to joke that the talents of weather forecasters were wasted here. British weather forecasters are equally redundant, but for the opposite reason; it's almost impossible for them to get it right. To cope with this, they have evolved umpteen ways to say unpredictable -- sunshine with occasional showers, cloudy with sunny intervals, overcast but brightening later, and so on.

Maybe you're wondering why I am telling you this, since you probably already know why Surfin' USA is a lot better known than Surfin' UK. Or maybe you've figured out that my sudden interest in the weather is really just a cover for my original purpose of discussing probability theory. So let me explain.

Consider any weather-related variable that's measured daily, like hours of sunshine, or inches of rain. The technical term for this set of measurements is a time series. Suppose you want to analyze such a time series and use it as a basis for forecasting tomorrow's weather (and assume for purposes of this example that no other meteorological data exists). If the two conditions you care about are rain (R) and sun (S), then you can do a lot better than simply calculating the long-term probability of rain, which a statistician writes as p(R).

That naive approach might be OK for forecasting the weather in Britain. But not in California, where a forecaster needs to consider conditional probabilities -- the probability of an outcome given what we already know, which is written p(outcome|condition). If it's raining in California today, what really matters are the conditional probabilities of rain tomorrow [p(R|R)] and sun tomorrow [p(S|R)].

For a time series, these kinds of conditional probabilities depend upon a statistical property of the series called independence, and its opposite, autocorrelation. When the results of successive measurements are independent, knowing the history does not help you to forecast future outcomes. This is the challenge facing the BBC's weather forecaster, whose unpredictable weather is such that p(R|R) = p(R|S) = p(R).

But for the weather forecaster in Sacramento, California, prior knowledge is crucial. During a typical year it rains on 58 days, so p(R), the probability of rain on any given day, is 58/365 or 0.158. However, those 58 days are not randomly spread across the year. Like the Aspens in Colorado, they come in clusters. So if it's raining today, the probability of rain tomorrow [p(R|R)] is significantly greater than 0.158, because for Sacramento weather, the time series is autocorrelated.

So ... this has been today's science lesson from your Web Weather station. Tune in again tomorrow, and I will explain how understanding the statistics of weather forecasting can also help you forecast your Web site availability. And you thought those weather forecasters on the nightly news were just there for comic relief!