The Alignment Effect: How to Get Real Business Value Out of Technology

AAddvvaannccee AAccccllaaiimm ffoorr TThhee AAlliiggnnmmeenntt EEffffeecctt

“The companies that will get ahead and stay ahead in today’s inter-connected business environment will be those that take control oftechnology, not those that let technology take control of them.Business leaders who want grab the reins and steer IT in the samedirection as the rest of the business must read this book.”

– Charles B. Wang, Founder and Chairman of the Board,Computer Associates International, Inc.

“I found this book an enlightening and valuable read. The real worldstories coupled with the author’s interpretation of the CIO's businessrole today should make every business leader sit up and take notice.Everyone in a position of leadership should read this book beforethey set next year's IT budget.”

– Phil Fasano, Senior Vice President, Global Technology Group, JPMorgan Chase and Company

“The Alignment Effect paints a vivid picture of information technol-ogy’s worst-kept secret: IT cannot, by itself, solve your business prob-lem. To solve your problem, any new technology must be carefullyaligned with your business objectives and processes. Otherwise, saveyour money. Read this book if you want to ensure the success of yourown technology implementation!”

– Don Peppers and Martha Rogers, Ph.D., authors of the One toOne series of books on managing individual customer relationships

Front Matter_FINAL1.qxd 7/26/2002 11:54 AM Page i

“Faisal Hoque demonstrates that technology is no longer just therealm of engineers and programmers. The Alignment Effect challenges‘C’ level executives to drive IT value and provides them the pathwayto smart, integrated business decisions.”– Randolph C. Blazer, Chairman and CEO, KPMG Consulting, Inc.

“The strength and appeal of The Alignment Effect is that it provides aflexible but actionable approach that, if interpreted and applied well, can greatly increase the probability that alignment will—over time—occur.”

– Bob Zmud, prolific author,Research Director for the Advanced Practices Council of the Society for Information

Management, and Professor and Michael F. Price Chair in MIS,Michael F. Price College of Business, University of Oklahoma

“The examples of business/technology alignment and misalignmentspeak to every reader. Rarely have horror stories been explained soclearly, and Hoque shows how to ensure alignment so that next year’shorror stories don’t involve your company.”

– Don Tapscott, International best-selling author and Co-Founder of Digital 4Sight

“Faisal Hoque’s assertion that capturing the value of IT requires syn-chronizing business, process, and technology issues is right on. Myown sense in my field of research is that many companies need to doexactly what the author describes as important.”

– V. Sambamurthy, widely recognized researcher on business-IT alignment and Eli Broad Professor of Information Technology,

Eli Broad College of Business, Michigan State University

“Top executives have realized for years that closing the gaping dis-tance between technology and business can provide their organiza-tion with a strong, defensible, competitive advantage. However,knowing it and executing it are very different. The Alignment Effectfinally clearly lays out a process of how to do it, and do it right.”

– Chuck Martin, Author, Managing for the Short Term

“It occasionally happens that the producer of an innovative technol-ogy reaps rewards even if the customer fails to realize the promisedbenefit. It never happens that the customer reaps rewards under suchcircumstances. If you want to avoid being that customer, get to knowBTM as defined in The Alignment Effect.”

– Isaac Applbaum, Partner, Lightspeed Venture Partners

Front Matter_FINAL1.qxd 7/26/2002 11:54 AM Page ii

How to Get Real Business ValueOut of Technology

THE EFFECT

Front Matter_FINAL1.qxd 7/26/2002 11:54 AM Page iii

In an increasingly competitive world, it is qualityof thinking that gives an edge—an idea that opens newdoors, a technique that solves a problem, or an insight

that simply helps make sense of it all.

We work with leading authors in the various arenasof business and finance to bring cutting-edge thinking

and best learning practice to a global market.

It is our goal to create world-class print publications and electronic products that give readers

knowledge and understanding which can then beapplied, whether studying or at work.

To find out more about our businessproducts, you can visit us at www.ft-ph.com

How to Get Real Business ValueOut of Technology

FAISAL HOQUE

Prentice Hall PTRUpper Saddle River, NJ 07458

www.ft-ph.com

THE EFFECT

Front Matter_FINAL1.qxd 7/26/2002 11:54 AM Page v

Library of Congress Cataloging-in-Publication Data

Hoque, FaisalThe alignment effect : how to get real business value out of technology / by Faisal (i.e., Faisal] Hoque.

p. cm.Includes bibliographical references and index.ISBN 0-13-044939-3 (alk. paper)

1. Information technology--Management. 2. Economic value added. I Title.

HD30.2 .H664 2002004’.068--dc21

2002027866

Production Supervisor: Wil MaraAcquisitions Editor: Jim BoydEditorial Assistant: Allyson KlossMarketing Manager: Bryan GambrelManufacturing Manager: Alexis Heydt-LongBuyer: Maura Zaldivar

The jacket, interior pages, figures, and tables were designed by Lance SperringThe author photo on the jacket was taken by Peter Baker Studios

© 2002 Faisal HoquePublished by Financial Times Prentice HallAn imprint of Pearson Education, Inc.

All rights reserved. No part of this book may be reproduced, in any form or by any means, without permission in writing from the author and publisher.

The publisher offers discounts on this book when ordered in bulk quantities. For more information contact: Corporate Sales Department, Prentice Hall PTR, One Lake Street, Upper Saddle River, NJ 07458.Phone: 800-382-3419; FAX: 201-236-7141; E-mail: [email protected].

Company and product names mentioned herein are the trademarks or registered trademarks of theirrespective owners.

Printed in the United States of America

10 9 8 7 6 5 4 3 2 1

ISBN 0-13-044939-3

Pearson Education LTD.Pearson Education Australia PTY, LimitedPearson Education Singapore, Pte. LtdPearson Education North Asia LtdPearson Education Canada, Ltd.Pearson Educación de Mexico, S.A. de C.V.Pearson Education—Japan Pearson Education Malaysia, Pte. LtdPearson Education, Upper Saddle River, New Jersey

F

INANCIAL

T

IMES

P

RENTICE

H

ALL

B

OOKS

For more information, please go to www.ft-ph.com

Dr. Judith M. Bardwick

Seeking the Calm in the Storm: Managing Chaos in Your Business Life

Thomas L. Barton, William G. Shenkir, and Paul L. Walker

Making Enterprise Risk Management Pay Off: How Leading Companies Implement Risk Management

Michael Basch

CustomerCulture: How FedEx and Other Great Companies Put the Customer First Every Day

J. Stewart Black and Hal B. Gregersen

Leading Strategic Change: Breaking Through the Brain Barrier

Deirdre Breakenridge

Cyberbranding: Brand Building in the Digital Economy

William C. Byham, Audrey B. Smith, and Matthew J. Paese

Grow Your Own Leaders: How to Identify, Develop, and Retain Leadership Talent

Jonathan Cagan and Craig M. Vogel

Creating Breakthrough Products: Innovation from Product Planning to Program Approval

Subir Chowdhury

The Talent Era: Achieving a High Return on Talent

Sherry Cooper

Ride the Wave: Taking Control in a Turbulent Financial Age

James W. Cortada

21st Century Business: Managing and Working in the New Digital Economy

James W. Cortada

Making the Information Society: Experience, Consequences, and Possibilities

Aswath Damodaran

The Dark Side of Valuation: Valuing Old Tech, New Tech, and New Economy Companies

Henry A. Davis and William W. Sihler

Financial Turnarounds: Preserving Enterprise Value

Sarv Devaraj and Rajiv Kohli

The IT Payoff: Measuring the Business Value of Information Technology Investments

FinancialTimes_series.fm Page 1 Monday, July 29, 2002 10:10 AM

Nicholas D. Evans

Business Agility: Strategies for Gaining Competitive Advantage through Mobile Business Solutions

Nicholas D. Evans

Business Innovation and Disruptive Technology: Harnessing the Power of Breakthrough Technology…for Competitive Advantage

Kenneth R. Ferris and Barbara S. Pécherot Petitt

Valuation: Avoiding the Winner’s Curse

Oren Fuerst and Uri Geiger

From Concept to Wall Street

David Gladstone and Laura Gladstone

Venture Capital Handbook: An Entrepreneur’s Guide to Raising Venture Capital, Revised and Updated

Robert B. Handfield, Ph.d, and Ernest L. Nichols

Supply Chain Redesign: Transforming Supply Chains into Integrated Value Systems

David R. Henderson

The Joy of Freedom: An Economist’s Odyssey

Faisal Hoque

The Alignment Effect: How to Get Real Business Value Out of Technology

Harvey A. Hornstein

The Haves and the Have Nots: The Abuse of Power and Privilege in the Workplace…and How to Control It

Philip Jenks and Stephen Eckett, Editors

The Global-Investor Book of Investing Rules: Invaluable Advice from 150 Master Investors

Charles P. Jones

Mutual Funds: Your Money, Your Choice. Take Control Now and Build Wealth Wisely

Thomas Kern, Mary Cecelia Lacity, and Leslie P. Willcocks

Netsourcing: Renting Business Applications and Services Over a Network

Al Lieberman, with Patricia Esgate

The Entertainment Marketing Revolution: Bringing the Moguls, the Media, and the Magic to the World

Frederick C. Militello, Jr., and Michael D. Schwalberg

Leverage Competencies: What Financial Executives Need to Lead


D. Quinn Mills

Buy, Lie, and Sell High: How Investors Lost Out on Enron and the Internet Bubble

Dale Neef

E-procurement: From Strategy to Implementation

John R. Nofsinger

Investment Blunders (of the Rich and Famous)…And What You Can Learn From Them

John R. Nofsinger

Investment Madness: How Psychology Affects Your Investing…And What to Do About It

Tom Osenton

Customer Share Marketing: How the World’s Great Marketers Unlock Profits from Customer Loyalty

Richard W. Paul and Linda Elder

Critical Thinking: Tools for Taking Charge of Your Professional and Personal Life

Matthew Serbin Pittinsky, Editor

The Wired Tower: Perspectives on the Impact of the Internet on Higher Education

W. Alan Randolph and Barry Z. Posner

Checkered Flag Projects: 10 Rules for Creating and Managing Projects that Win, Second Edition

Stephen P. Robbins

The Truth About Managing People…And Nothing but the Truth

Fernando Robles, Françoise Simon, and Jerry Haar

Winning Strategies for the New Latin Markets

Jeff Saperstein and Daniel Rouach

Creating Regional Wealth in the Innovation Economy: Models, Perspectives, and Best Practices

Eric G. Stephan and Wayne R. Pace

Powerful Leadership: How to Unleash the Potential in Others and Simplify Your Own Life

Jonathan Wight

Saving Adam Smith: A Tale of Wealth, Transformation, and Virtue

Yoram J. Wind and Vijay Mahajan, with Robert Gunther

Convergence Marketing: Strategies for Reaching the New Hybrid Consumer


Front Matter_FINAL1.qxd 7/26/2002 11:54 AM Page x

Dedication

Tom, this one is for you. For your unyielding faith, your sincere

support, your continuous inspiration, and most importantly for

your true friendship.

In memory of Faez.– Faisal

In memory of Dennis.– Ryan

Front Matter_FINAL1.qxd 7/26/2002 11:54 AM Page xi

Front Matter_FINAL1.qxd 7/26/2002 11:54 AM Page xii

Contents

PART

II The Principles of BTM3 Modeling, Collaboration, Reuse 47

PART

III The Activities of BTM4 The End-to-End Perspective 795 Business Model Definition 956 Process Optimization 1157 Technology Automation 141

PART

IV Governing with BTM8 Direction and Control 1719 Promise to Practice 195

Conclusion 209

Appendix 213References 225Contributors 231Index 237

PART

I The Business/Technology Disconnect1 Real World Evidence 72 Approaching a Solution 27

Acknowledgments xv

Introduction xix

Front Matter_FINAL1.qxd 7/26/2002 11:54 AM Page xiii

Front Matter_FINAL1.qxd 7/26/2002 11:54 AM Page xiv

AAcckknnoowwlleeddggmmeennttss

THIS BOOK COULD NOT HAVE BEEN WRITTEN without the spe-cial talents and determination of Ryan J. Sheehan, ChristineAruza, Zoe Sochor, and Lance Sperring. A heartfelt thanks goesout to them for their patience and perseverance in seeing thisproject through to the end. I am also especially grateful to myentire company, enamics, Inc., for never losing its resolve in thequest to help others recognize and achieve the benefits of BusinessTechnology Management (BTM). Through their tireless effortsmy vision for BTM has been realized.

I will be forever indebted to the following for their personalsupport and for sharing their industry insights: Randolph C.Blazer, Chairman & CEO, KPMG Consulting, Inc.; Patrick F.Flynn, vice president and CIO, PACCAR, Inc.; Scott Hayward,managing director, JPMorgan Chase and Company; Dale Kutnick,

Acknowl_FINAL.qxd 7/25/2002 4:45 PM Page xv

chairman, CEO & research director, META Group, Inc.; Dr. JerryLuftman, best-selling author of Competing in the Information Ageand Distinguished Service Professor, Stevens Institute ofTechnology; Chuck Martin, best-selling author of Managing for theShort Term and Net Future and former associate publisher,InformationWeek; Jack Mollen, senior vice president, HumanResources, EMC Corporation; Honorio J. Padron, president andCEO, Business Services, Exelon Corporation; Don Peppers, best-selling author of the One to One book series and founding partnerof Peppers and Rogers Group; Chris Perretta, CIO, GE CapitalCard Services, Kevin Poulter, head of Business Integration, BritishAmerican Tobacco; John Sievers, president, Consumer and SmallBusiness Group, Southern New England Telecommunications;Howard Smith, CTO, CSC Europe; Tom Trainer, former CIO,Citigroup, Inc., Eli Lilly & Co., and Reebok International Ltd.;and Carl Wilson, executive vice president and CIO, MarriottInternational, Inc. The candor with which they recount theirexperiences provides us all with a rich set of didactic cautions,lessons, and guidance. I hold each of these individuals in the high-est regard.

I am also grateful to my editor, Jim Boyd, for the direction andcontinual support that he gave me throughout the entire process.No matter what unconventional request I made or zany idea Iproposed to him, he always listened with a receptive ear andresponded with patient suggestions that considered any alternativepossibilities. Without his guidance and the efforts of the folks atFinancial Times Prentice Hall, this book would never have madeit from brainchild to bookstore.

Special thanks go to Frank Ovaitt and Paul Berg for the innu-merable hours they have spent in support of this project. Timeand time again, they kept me headed on the right path withtheir reliable and experienced counsel. They always have mydeepest respect and I consider myself a fortunate recipient oftheir sage advice.

I also wish to extend my gratitude to the members of enamics’board of directors and advisory board in addition to the numerouscustomers, partners, and investors that have helped shape ourthinking and validate our direction. It is through their feedback,

xviAcknowledgments

Acknowl_FINAL.qxd 7/25/2002 4:45 PM Page xvi

contributions, and encouragement that BTM has been able tosuccessfully forge ahead in the marketplace.

Dale Kutnick and Meta Group also deserve special recognitionfor their commitment and support. From day one, they havedemonstrated their belief in these concepts. The same also holdstrue for Sathish Reddy and the hard work of his team at Itreya. Wewouldn’t be able to pursue our vision without their dedicatedlabors, nor without those of Paul Daversa and his company,Resource Systems Group.

I am deeply grateful for having been blessed with a wonderfulfamily and a few special friends. To my family, thank you forinstilling in me, from the earliest days, the passion required fortaking on a project of this magnitude and the drive needed tosucceed. To my friends, thank you for touching my life andcheering me on.

Most importantly, I am eternally thankful for my wife and bestfriend, Christine Hoque, whose faith has inspired me to nevergive up all these years. She has encouraged all of my radical ideasand has endured with me the ups and downs, the 4 a.m. conver-sations, the lost evenings, and the delayed plans, that often comehand-in-hand when you decide to chase your dreams. She makesliving worthwhile. Lastly, I welcome our son with my arms openwide as the finishing touches are being put on this book.

May, 2002Faisal Hoque

Acknowledgments

xvii

Acknowl_FINAL.qxd 7/25/2002 4:45 PM Page xvii

IInnttrroodduuccttiioonn

MY OBSERVATIONS OF BUSINESS AND TECHNOLOGY over thelast 15 years compel me to write this book and to answer thisquestion: Why aren’t we getting real business value out of tech-nology? One thing is sure—companies that continue to repeatthe mistakes of the past will never reap the rewards of the future.Most companies fail to capitalize on the technologies they alreadyhave; and many more are poised to meet this same fate with thenext big technology fad spawned in Silicon Valley and propelledby venture capitalists. Whether it’s wireless, Web services, or thelatest and greatest in nanotechnology, companies will never getvalue—real or perceived—without first solving the business/tech-nology disconnect.

This book will begin by illustrating some of the ways thedisconnect can manifest itself in the enterprise. These examplesreveal an unequivocal truth: In order to understand, communi-cate, and plan how they should utilize technology in the enter-prise, companies first need to align three key areas—business,process, and technology. But to achieve alignment among theseareas requires a fundamentally different approach than thoseused before—one that brings these disciplines together in a waythat all can understand. This approach creates unprecedented

Intro_FINAL.qxd 7/25/2002 4:44 PM Page xix

visibility into how business and technology decisions are made,and provides the means for tracing decisions back and forthbetween the two, so that companies can discover and commu-nicate interdependencies.

This approach is called Business Technology Management, orBTM. In the pages that follow, the principles, activities, and gov-ernance that make up BTM will unfold to provide the structureand the mindset to help any company in any industry get realbusiness value from IT.

I am not alone in my views on the disconnect, or in my ideasabout what’s necessary to solve it. Many chief executive officers(CEOs), chief information officers (CIOs), industry gurus andacademics—such as the contributors to this book (some of whomhave been grappling with the disconnect since the earliest days ofIT)—believe that the time has arrived for companies to adopt astructured approach to aligning business and technology.

WWhhaatt’’ss ttoo CCoommee??Whether you accept this premise or not, one thing is obvious:The approaches that companies have been relying upon to closethe disconnect aren’t getting the job done. So what needs to bedifferent in the way companies go about solving it?

To answer this crucial question, the approach should followseveral guidelines. First, the approach should view the problemprimarily from the perspective of the business. IT has a long his-tory of considering itself an island apart from the rest of the enter-prise. But, like every other business function, IT should service thebottom line first, and then its own needs. This doesn’t mean thatIT is only about dollars and cents; one of the biggest mistakesthat companies have made in the past is failing to recognize theintangible benefits that can come from IT—benefits such asimproved customer relationships and better communicationbetween business units. The people who are most likely to recog-nize and advocate these benefits are business professionals, since

xxIntroduction

Intro_FINAL.qxd 7/25/2002 4:44 PM Page xx

they are often the end-users of technology. It is a mistake not toget this crucial group sufficiently involved in making decisionsabout how technology can and should impact the business. If IT isto become focused on the business, this trend needs to change.

Second, the approach should focus specifically on the busi-ness/technology disconnect, and leave other, more narrowlyfocused techniques (such as scorecarding or systems design) out ofthe equation. This means that the solution should zero in on thethree key areas that need to be aligned—business, process, andtechnology—and specifically the connections between them.Often the easiest way to understand this is by forming a picture inyour mind similar to what appears in Fig. I.1:

Third, the approach should enable disparate groups of peoplewith different interests, capabilities, and objectives to visualizeand communicate about IT. This includes everyone from the CxOsuite on down to programmers and developers. To close the dis-connect, all of these people need to be on the same page.

Finally, the approach should solve the problem up front, beforethe disconnect is cast in stone by expensive and irreversible ITimplementations. The logical place for this to happen is in thedesign stage, where disconnects can be diagnosed, examined, andcured—all before the first line of code gets written.

Introduction

xxi

Figure I.1The three areas that need to be aligned in order to close thebusiness/technology disconnect: business, process, and technology

Intro_FINAL.qxd 7/25/2002 4:44 PM Page xxi

Obviously, these guidelines leave a lot of room for interpretinghow to go about closing the business/technology disconnect.Filling in these gaps is what The Alignment Effect is all about.

This book begins with Part I: The Business/Technology Disconnect,which introduces the disconnect and uses real-world examples toshow the profound effect that it can have upon the enterprise.These examples, which include scenarios from integrated financialsystems to human resources to call reporting, illustrate some typi-cal conditions that can result in disconnects, as well as some of thematerial losses that they can produce. To begin closing the busi-ness/technology disconnect, IT departments need to address sev-eral emerging challenges. These challenges point to the need for anew approach to align business and technology: the principles,activities, and governance that make up BTM.

Part II: The Principles of BTM, examines three underlying prin-ciples that must be in place in order to perform BTM. These prin-ciples include predictive modeling, which allows project teams tocreate blueprints that improve design decisions and facilitatealignment; collaborative decision-making, which includes a broadrange of stakeholders to make sure that competing needs are bal-anced; and making knowledge and assets reusable, which maxi-mizes the value of both intellectual and physical capital.

In Part III: The Activities of BTM, we explore business modeldefinition, process optimization, and technology automation—the three activities that companies undertake to align businessand technology. The purpose of these activities is to create anend-to-end blueprint of the enterprise architecture that is relevantto a given IT project. In order to create this blueprint, the projectteam relies on predictive modeling and the other principles ofBTM. The activities of BTM begin by capturing a model of thecurrent enterprise architecture, including business, process, andtechnology. The next step is creating multiple scenario modelsthat correspond with the directions that the project could take.After selecting a final scenario, the final step is implementing thedesign created in the corresponding model and updating the cur-rent model to reflect the changes.

xxiiIntroduction

Intro_FINAL.qxd 7/25/2002 4:44 PM Page xxii

Part IV: Governing With BTM, illustrates how the enterpriseshould administer BTM to achieve two goals. First, the blueprintdeveloped during the activities of BTM helps senior decision-makers (including the CIO) to set strategic direction for how thebusiness should put technology to work by managing the IT port-folio. Second, the design decisions captured in the blueprintbecome an important ingredient for helping the company main-tain tactical control over their IT projects, including control overquality and cost management. Finally, since governance implies aconcerted effort to incorporate BTM into the workplace, I willintroduce some key roles and responsibilities for helping BTMmake the jump from promise to practice.

TThhee SSuumm TToottaallTogether, these building blocks add up to a structured approach—BTM—which aligns business and technology so that companiescan get real value out of IT. This is the key message of BTM, andalso of this book. So even if you decide not to read a word beyondthis sentence, remember this point: “BTM aligns business andtechnology to get real value out of IT.”

Introduction

xxiii

Intro_FINAL.qxd 7/25/2002 4:44 PM Page xxiii

TThhee BBuussiinneessss//TTeecchhnnoollooggyyDDiissccoonnnneecctt

IIPPAARRTT

“The study of error is not only in the highest degreeprophylactic, but it serves as a stimulating introduction to thestudy of truth.”– Walter Lippman

IMAGINE FOR A MOMENT that you want to build your dreamhouse. After some research, you select Janet, a prominentarchitect, and Robert, a respected contractor, for the job. Tokick things off, you invite them over to your apartment to dis-cuss the project. After brief introductions and some cursorysmall talk, the three of you sit down at the kitchen table andget to work:

YOU: As the two of you know, I’m interested in buildinga house.

THEM: [Nodding]

PartI_FINAL.qxd 7/25/2002 3:21 PM Page 1

YOU: Not just any house. My dream house.

THEM: [More nodding]

YOU: For years now I’ve been picturing this house in mymind, so I know exactly what I want. First, it’s got tofeel like home. I’d like a breakfast nook, a whirlpooltub in the master bathroom…

THEM: [Jotting down notes]

YOU: …a deck off the family room. And a dramatic two storyentrance, of course. Also, I just love our neighbor’sfireplace…

THEM: [Scribbling furiously]

YOU: …So what do you think?

THEM: [Pause]

JANET: It sounds to me like you’d love the colonial revivalstyle. We could include a portico with ionic columns,and a dentil band to add an air of sophistication…

YOU: A “dentil” what?

ROBERT: And I know an importer who gets beige breccia marbledirect from Karnezeika…

YOU: “Karne”-where?

JANET: …and a hipped roof…

ROBERT: …cantilever walls in the family room…

JANET: …with sidelights and transoms…

ROBERT: …tensile strength, ASTM A615…

At this point, you’re probably lost. Or, at the very least you feellike you’re no longer in charge of the conversation. How does allof this technical jargon relate to your vision of a dream house?What do “tensile strengths” and “dentil bands” have to do with“feeling like home”?

2PART I


The problem here is common: you’ve hired two skilled associ-ates who instinctively view the project from their own specializedperspectives—which you definitely don’t share. But despite all ofthis, you’re still the boss, and you need to figure out a way tomake sure that everybody comes together to achieve your vision—no matter how limited your architectural and structural engineer-ing vocabulary may be.

But not to worry. Architects and builders have faced this prob-lem as long as they’ve been building for style as well as for shelter.To help communicate issues and align their expertise, Janet andRobert will follow an established approach that helps them tocollaborate and ultimately, to capture the design for your dreamhouse in the form of an architectural blueprint. The three of youwill then use this blueprint to bridge the gaps between their tech-nical knowledge and your general objectives: Janet could pointout the portico and the simple yet elegant design of its ionic pil-lars; Robert could explain how advanced structural engineeringallows continuous open spaces throughout multiple rooms; andyou could envision what it would be like to actually live in thehome. Without this approach, designing your house would meanceding control over the project to Janet and Robert; the endresult would presumably look impressive and be structurallysound, but there would be no way to ensure that it matched yourvision of a dream house.

Now let’s revisit this scenario, but with a twist. Picture thesame scene, with you, Janet, and Robert sitting at your kitchentable. Imagine a Hollywood-style special effect in which thatscene morphs into another. Instead of being a prospective home-owner, you’ve become a senior business executive. And instead ofbuilding a house, you’re managing a corporation.

Your company is an aggressive market leader, quick to adoptthe latest tools and practices to achieve competitive advantages.In recent years this has meant embracing technology to providethe infrastructure you need to do business. To plan, deploy, andmanage these IT investments, you’ve hired Janet (now a high-powered consultant) and Robert (now a respected CIO). Likebefore, the three of you are sitting together at a table—but nowit’s in a corporate boardroom rather than in your kitchen:

The Business/Technology Disconnect

3


YOU: As the two of you know, we’re beginning a project toget closer to our customer base.

THEM: [Nodding]

YOU: This project has been in the works for some time now,so I’ve got a pretty good idea of the things we need toaccomplish.

THEM: [More nodding]

YOU: First we’re interested in improving customer segmen-tation. This means we’ll have to gather informationacross all of our customer touch points…

THEM: [Jotting down notes]

YOU: …and analyze this raw data. Also, we’d like to auto-mate some field support activities and maybe do some-thing with our call center…

THEM: [Scribbling furiously]

YOU: …So what do you think?

THEM: [Pause]

ROBERT: This sounds like a CRM installation to me…

JANET: …with analytics…

ROBERT: …maybe WAP…

YOU: Huh?

JANET: …and load balancing…

ROBERT: …distributed architecture…

Once again, things seem to have spiraled out of your control,from business subjects you understand and appreciate—“cus-tomer base” and “segmentation”—to the arcane technologydetails required to implement your vision—“CRM,” “WAP,” and“load balancing.”

4PART I


In our dream house scenario, you (the homeowner) were ableto rein in the project by collaborating with the architect and con-tractor to produce an architectural blueprint. Inexplicably how-ever, most companies don’t employ an analogous approach to helpyou (the executive) visualize scenarios and incorporate domainknowledge in order to overcome a similar dilemma: the busi-ness/technology disconnect.

IInn TThhiiss PPaarrtt……As any researcher will tell you, the first step towards a conclusionis framing the proper question. So that’s what Part I: The Business/Technology Disconnect does. Before introducing an approach tosolve the disconnect, it first has to demonstrate that the problemitself is big and bad enough to warrant your attention. Part I doesthis by presenting real-world evidence that shows how the discon-nect manifests itself in the enterprise. Then, it makes the jumpfrom problem to solution by tracing the evolution of IT, identify-ing several emerging challenges, and showing how BusinessTechnology Management, or BTM, can help to overcome thesechallenges and bridge the business/technology disconnect.

The Business/Technology Disconnect

5


RReeaall-WWoorrlldd EEvviiddeennccee

11

WOULD ANY SELF-RESPECTING EXECUTIVE willingly throwmillions of dollars at an investment without knowing how it couldaffect his or her business? The sane answer to this question is“No.” But many company leaders make this exact mistake whenthey blindly allocate money to IT with little concern if it is put togood use or even for the objectives they are trying to meet in thefirst place. Imagine a pair of children who lob snowballs at eachother over a high wooden fence. Neither child can see wheretheir volleys are landing—or even the target that they’re trying tohit in the first place—but they keep throwing anyway. Now imag-ine each snowball costs a million dollars. It’s kind of like that.

Ironically, it took one of the most irrational periods in recenthistory—the New Economy bubble—to return companies to

Chap1_FINAL.qxd 7/26/2002 9:02 AM Page 7

rational thinking about how they invest in IT. After the dust set-tled from the dotcom collapse, companies surveyed the wreckageto find out what went wrong—and to ensure that it wouldn’t gowrong again. Not surprisingly, one of the major problems theydiscovered was the “business/technology disconnect,” a frequent,behind-the-scenes player that’s been wreaking mayhem and mad-ness since the earliest days of IT.

Don’t just take my word for it, though. The best way to illus-trate the true impact of the business/technology disconnect is tolook at real-world scenarios. These scenarios stretch from beforeAmazon.com was a twinkle in Jeff Bezos’ eye, to after Enron stockstarted showing up on eBay as laminated placemats. Throughouteach vignette, notice a recurring trend: When companies aligntheir use of technology with sound business objectives, the resultsare good; but when companies don’t, bad things can—and oftendo—happen.

8CHAPTER 1

�

Enterprise Disconnects andManaging for the Short Term

“One thing that we see over and over is that technologyevolution leads to disconnects with business. The obviousreason for this is that business and technology aren’t inno-vated hand-in-hand. A lot of technology is created in avacuum, simply because it can be done, and without acomprehensive connection as to how it should be used inthe business environment.

Look at the personal computer, for example. When thePC first came along some CIOs viewed it as an entry-levelsystem rather than something completely new and disrup-tive. Eventually, it got in the hands of middle managersand employees, and they led the revolution that molded itinto the powerful business tool it is today.

This same story has played itself out with the Internet.After lots of amazing innovation up front—the browser,ubiquitous access to information, global connectivity—executives decided that the Net would be used to sell


RReeaall-WWoorrlldd DDiissccoonnnneeccttss aanndd TThheeiirr RReeaall-WWoorrlldd RReessuullttss

Recent surveys by IT analysts identify the business/technologydisconnect as a top CIO concern. This should be no surprise. Onegroup that’s always recognized the critical role that the disconnectplays is the practitioners who run up against it every day: CIOs;the project/program management office (PMO); business profes-

Real-World Evidence

9

things. And this sells the Internet short the same way thatusing the PC as an entry-level mainframe did. The truth isthat the Internet—like the PC before it—really providesan opportunity for business transformation.

The thing that’s going to drive this transformation is aconcept that I call Managing for the Short Term. In theage of connectivity, companies face lots of externaldemands: from the stock market; from customers; frombusiness partners, etc. To respond to these demands busi-nesses need to be able to turn in a much shorter time-frame than they’ve had to before, and it is technology andthe Internet that’s going to enable that.

But most of the technology that we have in placetoday—CRM, ERP, and so forth—are just the tip of theiceberg; when they are done only by a department or evenseveral departments, they are not really end-to-end.

To successfully manage for the short term, all thistechnology needs to be connected all the way throughthe supply chain, from distributors to customers. This isgoing to drive a new emphasis on alignment within theenterprise.”

– Chuck Martin, Author, The Digital Estate, NetFuture, and Max E-Marketing In the Net Future; chairmanand CEO, Net Future Institute


sionals, including executives, managers, and analysts; and tech-nology professionals, including enterprise architects, developers,and process-focused IT analysts.

There’s no more compelling evidence of how seriously thesesoldiers in the field take the business/technology disconnect thanthe stories that they tell firsthand. These anecdotes, which run thegamut from engineering systems to enterprise resource planning(ERP), are powerful proof that the disconnect isn’t just the stuffof analyst reports and magazine articles; it’s real, and it’s outthere giving business and IT professionals headaches even as youread this.

One more thing before we get to these real-world examples:Until now, our discussion of the disconnect has been relegated toa superficial level. But the whole purpose of this chapter is to helpyou sink your teeth into what this means in a real business envi-ronment. This means fleshing out the definition of the busi-ness/technology disconnect a bit more. When I talk about thedisconnect, I really mean misalignment between three key areas:

– Business, which refers to things like the business objectives,drivers, strategy, and so on

– Process, which refers to business processes; the things thatthe enterprise “does”

– Technology, which includes the business applications andunderlying systems that companies use to support theirprocesses

The anecdotes that make up the rest of this chapter come fromin-depth interviews with respected business and technology lead-ers who have grappled with the disconnect on a day-to-day basisfor much of their careers. Consequently, their real-world examplesspan beyond any individual technology fad or era. This broadrange of experiences gives us a unique look at some specific gapsthat exist between business, process, and technology—and alsosome insight into what type of approach companies should followto close them.

10CHAPTER 1


IInn TThheeiirr OOwwnn WWoorrllddssOur first example of a real-world disconnect comes from PatrickFlynn, Vice President and CIO of truck manufacturer, PACCAR.Flynn’s story, from early in his career, is based on a customs-clear-ance project that was eventually abandoned by his employer atthat time. In many ways, it represents the prototypical example ofthe disconnect, where each side pursues its own agenda with littleregard for how it impacts their counterparts on the opposite side ofthe fence.

Flynn’s customs-clearance system was designed to do real-timeconfirmation of clearance for a logistics provider. If an itemneeded to get from Singapore to San Francisco, for example, thesystem would determine the documentation that was required topick up and export the item out of Singapore and into theUnited States:

It needed to know things like which data elements wererequired, what would be the sequence of transactions, and howwe would know that something had cleared. Plus, it had tohandle exceptions and special cases. A government could say,for example, “this is cleared on temporary or preliminary basis”and then say “no we want to hold this one.” The basic commu-nications standards were well defined—there’s actually a UNstandard for customs clearance—but the actual details wereflexible; they were left to the participants to nail down.

In an ideal world, these business details would have beensigned, sealed, and delivered before Flynn’s development team satdown to write the first line of code. As the project progressed fur-ther and further along, however, these details remained elusive:

We knew there was a regulatory change coming that we wouldbe mandated to follow. Then all of a sudden the change wasoff. And then it was on again—it was a continuous back andforth. As a result, our developers were constantly forced torevise their plans. Sometimes, the change would seem rightaround the corner, and we’d have to compress our plan andthrow out good practices. Other times, you’d sit back and say

Real-World Evidence

11


“wait a second, now it’s going to be six months before we’reready to go” and so we’d sort of back off. There was never aclear definition of what needed to be done and when, and alsowhether certain features—like supporting these new regula-tions—were mandatory or optional. And each of these condi-tions has very different characteristics in terms of how youmanage things.

Meanwhile, the development team was making importanttechnology decisions on their own. They decided to build the sys-tem using Smalltalk, an object-oriented programming languagethat was designed for component development. From the start,Flynn remembers, Smalltalk proved to be a mixed blessing: it wasgreat for developing the software (which was why they chose it inthe first place), but it was horribly slow in a production environ-ment, where time-sensitive communication was essential:

We had to communicate with governments, we had to commu-nicate with customs brokerages (to actually have the ability toclear a document you have to hold the broker’s license), andwe had to communicate with our own internal systems. Allthese were timing issues that needed to be worked out with thebusiness: when would we be able to say “yes this is clear or not”and so on.

These two decisions—to continually evolve the businessrequirements and to develop the software using Smalltalk—com-bined to have a devastating effect upon the project. On the onehand, Flynn’s team suffered through dozens of iterations of busi-ness requirements as regulatory agencies flip-flopped back andforth. With each change, it got harder and harder for the devel-opers to avoid rewriting code that they’d already finished. On theother hand, Smalltalk couldn’t keep up with the strict timingrequirements that the business required, and the system alwaysseemed to be operating a step behind. After a significant invest-ment and years of effort, it became obvious that the project wouldnever work, and it was canceled.

The problem with Flynn’s project was that business and tech-nology decisions were made independently, with little concernfor how each might impact the other. Changes in the business

12CHAPTER 1


requirements were based solely on shifting regulations, and theripple effects of those changes upon the code that Flynn’s teamwas developing never entered the equation. Similarly, the decisionto develop in Smalltalk was based upon a strictly technical con-sideration: how good it was for building components. But by cod-ing in Smalltalk, the team created a disconnect between thetechnology they developed and the strict time requirements thatwere critical to the business. As a result, business and technologyheaded in distinctly different directions (see Fig. 1.1). “It was liketrying to build a bridge from opposite sides of a canyon,” Flynnconcludes, “and it never quite met in the middle.”

UUnnddeerreessttiimmaattiinngg PPrroocceessss CChhaannggeessThis is far from the only way that the business/technology dis-connect can reveal itself. Our next example of a real-world disconnect is framed by a common dilemma that IT professionalsface: After installing a new enterprise application, they find a gap

Real-World Evidence

13

Business Business

Disconnect

Process

Technology

Disconnect

Technology

Figure 1.1Business and technology decisions in Flynn’s project were madeindependently with no connection to the other


between the business processes it supports and the processes thatare already in place. To bridge this gap, they face a criticalchoice—to either pay for expensive modifications to the software,or change how the company does business to fit what the tech-nology supports out of the box.

Carl Wilson, Executive Vice President and CIO of MarriottInternational, Inc., is a strong proponent and successful practi-tioner of alignment. Marriott, lauded for its progressive align-ment initiatives, enjoys the fruits of Wilson’s previous experienceand lessons learned. Throughout his extensive career in IT,Wilson has witnessed firsthand how disconnects caused by under-estimating the impact of process changes can bring about realdamage to the business. In this example, he recounts the story ofa CEO who wanted better visibility into his human resources(HR) information so that he could assess his company’s equalopportunity compliance:

The CEO started out with what he thought were some prettybasic questions: How many people do we have working at eachgeographical location? Can we figure out what skills each ofour employees has? What training have they received? Butwhen he approached his head of human resources, he foundthe problem was worse than he imagined. Not only was itimpossible to answer these questions, but the HR departmentcouldn’t even track straightforward data like the number ofpeople who worked at the entire company.

The CEO quickly kicked off what he expected to be a straight-forward project: implement an HR system for the company. Butin the end, the disconnect between the new software and thecompany’s established business processes, ended up costing thecompany millions.

From the start, the project was put on the fast track, and thecompany hired a large, high-profile consulting firm to implementthe system. After a short evaluation period, the consultants rec-ommended three ERP packages from leading vendors.

The consultants were under intense pressure from the execu-tive team to fix the problem as quickly as possible. To save time,they assumed that all HR processes were essentially the same, andbrokered a deal with a vendor whose product had been successfully

14CHAPTER 1


installed a number of times for companies in the same industry.The contract, Wilson remembers, was the standard consultant’scontract; there was minimal negotiation, and the company signedright away.

Early on, however, it became apparent that the installationwasn’t going according to plan. When the new system cameonline, employees clung to their familiar business processes anddemanded that the software be customized to fit the processesthey were used to. The team eventually yielded and undertook amassive customization program. As a result, the project, which wasoriginally budgeted at $4 million, instead ended up taking threeyears longer than expected and costing $9 million.

Consider what happened in this example: The project startedout with the sound business objective of better visibility into HR.But because process changes weren’t addressed until after the tech-nology had been designed and implemented, a disconnect croppedup between process and technology (see Fig. 1.2). Modifying thistechnology to match up with the processes cost millions.

Real-World Evidence

15

Business

Process

Technology

Disconnect

Technology

Figure 1.2In Wilson’s story, a disconnect resulted when process changesweren’t addressed until after new technology had been finalized


A better solution, of course, would have been to adjust whatwere essentially low-value HR processes to fit those that thesoftware supported out of the box. But the consultants on theproject didn’t make the connection between the new softwareand its affect on existing processes. They never collaboratedwith the end-users to find out how their processes were carriedout today, and never communicated how those processes wouldhave to change. As a result, Wilson says, end-users foughtchange from day one, even though doing so cost millions in cus-tomization:

Nobody likes change, and they don’t want it imposed uponthem. So they have to have the benefits clearly demonstratedto them before they’ll actually move along and accept any kindof change. So the problem wasn’t really the technology. Thetruth was, ninety percent of the functionality was there. But tomake it work they would have had to spend significant timeand effort reengineering their processes.

Projects that overlook processes when they make changes totechnology do so at their peril. Instead, Wilson argues, companiesneed to acknowledge that process management is a central com-ponent of IT change:

My early career background was as an industrial engineer, soI’m accustomed to applying the principles of process manage-ment. But some companies don’t want to invest in the up-frontplanning that this takes. This is a mistake.

People in leadership roles who kick these projects off oftenhave a good understanding of what the end result will do andhow it will affect them, but a lot of times they don’t bother tocommunicate this to other people to get them involved in theprocess. As a result, the first time people are brought into aproject is when it’s being implemented and they’re beingtrained on it. So you end up with a huge backlash and peoplefight this tooth and nail even though you tell them that even-tually it’ll benefit them. Until they can see it for themselves,they’ll resist embracing new business processes.

16CHAPTER 1


Early involvement through process management settles issuesup-front instead of forcing people to react later on. If they’rebrought in early and convinced that the new technology willimpact them on a day-to-day basis, they’re more willing toaccept it, buy into new business processes, and make it work totheir advantage.

When you just tell people to stand up and salute the flag they’lldo it. But they won’t believe it until they get involved and seefor themselves the benefits of changing their processes.

WWhhaatt iiss RReeaallllyy SSttrraatteeggiicc??This same struggle for process/technology alignment plays outwith a different result in our next vignette. In the previous story,Wilson described how a company elected to customize packagedsoftware to fit their specific business processes. These modifica-tions ended up costing millions and delaying the project for years.The alternative, Wilson noted, was to embrace process manage-ment and forgo expensive customization, to leave the software asis, and instead to change the processes to fit what the applicationdelivered out of the box.

Since no custom work is involved, this option immediatelysounds appealing. But before you can let an enterprise softwarevendor dictate exactly how your company does business, you firsthave to ask a key question: What is really strategic? If the processyou’re considering changing is crucial to the business model, anda source of competitive advantage, it’s probably best to let itdrive technology changes. If not, however, the simplest solutionmay be to leave the software alone, and instead transform theprocesses accordingly.

Honorio Padron is President and CEO of Business Services atExelon, an energy giant that was created by the merger of ComEdand PECO. During the merger, Padron tackled a project thatseemed straightforward on the surface: implementing an inte-

Real-World Evidence

17


grated financial system for the newly merged business. But becauseemployees didn’t do a good job of evaluating what was reallystrategic, they almost fell into the same trap that Wilsondescribed—customizing technology with great cost but smallbenefit.

It’s human nature to magnify the importance of the thingsthat take up most of our time and attention. It’s no surprise, then,that during his integrated financial system project, Padron foundthat employees overemphasized the importance of unique busi-ness processes:

In Exelon, you have two energy companies that are identical inwhat they do. Yet their financial processes had some significantdifferences that didn’t really bring any strategic advantages.And in trying to merge these two types of financial processes,people were trying to come up with a third different way ofdoing things. Which, again, wouldn’t have had any strategicadvantages.

Some employees—we’ll call them the “customizers,”—pushedfor making highly specialized modifications to the ERP package sothat it could support a new, third version of financial processesthat was a mix of PECO’s and ComEd’s old ways of doing things.But to Padron, this seemed like the wrong approach: “These arereally primitive processes. Unfortunately, even for these primitiveprocesses, the perspective always starts from ‘what I want to do’ asopposed to ‘let me see what the technology brings’.”

Padron recognized that Exelon’s unique HR processes weren’tessential to the business, and eventually steered the team on acourse that reflected this conclusion. Instead of making high-cost software customizations to fit low-value processes, he pushedthe alternative approach: customize the processes to fit the soft-ware out of the box. As a result, Exelon was able to avoid thehigh cost of modifying their new HR software without any down-side to the business.

In Padron’s story, the customizers, who pushed for expensivesoftware alterations, did so because their view of what was impor-tant was limited only to processes; in other words, there was a dis-connect between the processes they had designed and the business

18CHAPTER 1


objectives for the project (see Fig. 1.3). By not making this con-nection back to the business (and presumably forward to the tech-nology where they would have figured out the true cost of stickingto their processes), the customizers failed to ask a crucial question:What is really strategic?

There’s often a wrong assessment of what is strategic and whatisn’t. In my experience the things that are very strategic arealso very proprietary in nature, like a Coca-Cola recipe. Butbeyond these obviously strategic things, what’s really importantis the ability to implement. It sounds very pragmatic, but it’sessential.

This mistake is a common one in IT projects, Padron explains,because of how technology has been put to work in the businessenvironment in the past:

Real-World Evidence

19

TechnologyTechnology

ProcessProcess

Disconnect

Business

Process Process

Business

Technology

Figure 1.3Customizers pushed to modify technology to fit custom processes,while Padron elected to standardize low-value processes


At first we developed code from scratch that automatedthe processes that we were already doing. So we wentfrom doing things inefficiently to doing things inefficiently butfaster. Gradually, we’ve gotten to saying “now that I’ve got thistool maybe I can do it a little different.” But this requires sys-temic thinking, and a lot of people have not moved to thatlevel yet, of thinking of it in an integrated fashion.

Exelon’s integrated financial system demonstrates this bias.The team took a myopic view that was based on the old paradigm.They approached technology as a tool to automate the processesthat they designed in a vacuum. But Padron encouraged a more sys-temic approach: align business objectives with processes and withthe new technology being implemented, and then make trade-offsbased on an analysis of the complete, end-to-end picture.

TThhee SSyynneerrggyy ooff BBuussiinneessss aannddTTeecchhnnoollooggyy AAlliiggnneedd

These real-world examples should provide notice to companies tosit up straight and take the business/technology disconnect seri-ously. But remember that so far our examples have only focused onwhat amounts to one side of the story; all IT projects don’t end upbeing miserable failures, or at best, neutral results. When doneright—when business, process, and technology progress hand inhand—they can act as a catalyst that drives some fundamentalchanges in how companies approach technology. Consider anexample from Scott Hayward, Managing Director at JPMorganChase and Company and former chief operating officer (COO) ofInvestment Banking in the Americas at J.P. Morgan.

Industries like investment banking and consulting are notori-ous for their high employee turnover—especially in response tochanging market conditions and the introduction of new and dis-ruptive technologies. As a result, there’s a lingering fear amongbanks and consulting firms that when employees leave they’ll taketheir domain expertise and client relationships—the core of thebusiness—out the door with them. To institutionalize this knowl-

20CHAPTER 1


edge so that this information stays put even as employees comeand go, firms often turn to call-reporting systems that captureclient conversations. Other employees can then access these con-versations to brush up on the latest client needs or to help themcross-sell other products and services.

On paper, call reporting seems to be a no-brainer for invest-ment bankers. But in practice, Hayward received a less-than-enthusiastic response:

Before I got to investment banking and while I was therebetween 1994 and 1998, I think we probably tried to imple-ment call reporting—something that would capture our con-versations with the client—no less than three or four times.Each time, it was just assumed that if we built the system peo-ple would use it, even without looking all the way upstreamfirst. But instead, we found limited acceptance.

Despite the complimentary relationship between call-reportingtechnology and the banker’s need to institutionalize client knowl-edge and relationships, the system went largely unused, and mostclient information continued to be stored in the same place that ithad been before: in the employees’ heads. According to Hayward,this disregard stemmed from a failure to modify the processes thatthe employees were accustomed to:

The thing people overlooked was that they didn’t go through a complete process: What are the objectives of the business?What’s the strategy to achieve those objectives? What are the business processes to implement those strategies? And only then: what technologies do you use to enable you inthose processes?

But this isn’t Hayward’s only experience with call reporting.“The other place that I’ve seen it,” he says, “and the only placethat I’ve seen it work, in fact, is where I am now in investmentmanagement.”

Like before, call reporting was intended to service clients bet-ter, so that no matter where a client touched the organization, theemployees would know the last conversation they had, what wason the client’s mind, and what his or her needs and concerns

Real-World Evidence

21


were. These are crucial considerations anytime you have morethan one person interfacing with a client, such as in JPMorganChase and Company’s client-service model for investment man-agement, which includes three points of contact: client advisors,portfolio managers, and account managers.

The call-reporting system was designed to capture informationand share it between each of these groups, so that a client advisor,for example, wouldn’t have to pick up the phone and get updatesfrom the portfolio manager and account manager before talking tothe client. “Anytime someone met with a prospect they were try-ing to convert to a client, or anytime they met with an existingclient whether it was a telephone call or in-person meeting,”Hayward explains, “those things would get captured.”

Like in Hayward’s previous experience in investment banking,however, there was a risk that despite its promise, the systemmight go unused. Hayward’s team countered this possibility byestablishing a system of incentives that encouraged employees toactually modify their business processes and take advantage of thecall-reporting tool:

Basically, people were told that if information wasn’t reflectedin the call reporting tool, whether it was from the pipeline ornew awards we had won, then they wouldn’t get credit for it.So the head of sales would say “if I don’t see it in the system,then I don’t recognize you did it. You get no credit for it. Andwhen we sit down on a quarterly basis and review yourprogress, you won’t get credit for it then either.”

The metrics, then, were deliberately built around not justrolling out the technology, but instead encouraging the end-to-end, business-process-technology change that theproject required.

Not surprisingly, the client advisors took to the system andachieved the business advantages the project was intended for inthe first place.

22CHAPTER 1


Consider how Hayward’s successful call-reporting project cameto pass. At first, the business recognized an opportunity for inno-vation. Then, they tasked the IT department to build a new sys-tem. But at the same time they made it a priority to stress to theclient advisors (with a very big stick) why it was important to useit. So when the system finally arrived, the user base was already onboard (see Fig. 1.4).

How Alignment Goes Above and BeyondCompared to some of the horror stories recounted in this chapter,Hayward’s call-reporting vignette looks pretty good. In fact, itlooks really good. But, in a sense, it only represents a neutral out-come: there wasn’t any disconnect, but at the same time, beingaligned from business through process through technology hadn’tchalked up any pluses beyond what the system was designed to doin the first place.

Real-World Evidence

23

Process

Business

TechnologyTechnology

Process

Business

Figure 1.4Hayward’s call-reporting project maintained alignment betweenbusiness, process, and technology, with impressive results


Hayward’s account of this successful call-reporting system,however, doesn’t end with just implementing the system and see-ing end-users adopt it. As the employees became more familiarwith the system and saw firsthand what it could do for them, theirattitude towards it changed. Usually, just getting people to take alook at and consider using new features is a battle unto itself. Butthe most powerful advantage, Hayward concludes, is when youactually get end-users to ask for more functionality instead ofneeding to have managers cram it down their throats:

We started to have client advisors or client portfolio managerscall the technology team that built the system and the businessperson who had responsibility for it and say: “Can you build insomething so that when I write my call report and put inaction steps, it automatically sends a note to the person who’sresponsible for doing that action step? And as we get closer tothe due date of that action step, can it then monitor whetheror not it’s been completed, and send a reminder when it getsclose to the completion date?”

Now, management didn’t ask for that; the end user did. Thepeople who are actually on the front lines asked for that. That’snirvana, in my opinion, when you’ve designed technologydirectly into how you do your business.

These ideas from client advisors and portfolio managers gotHayward’s management team thinking about some enhancementsof their own:

One of the things that we had been trying to do for a long timewas to get the investment management team to cross sell more,so naturally we were looking for information about whetherthey were doing it and if so, how much (for example, they hadspecific targets on the number of private equity sales theyneeded to achieve, the number of real estate sales or conversa-tions they needed to achieve, etc.). Specifically, we wanted toknow how much time they were spending on new client acqui-sition or cross selling as opposed to retention.

24CHAPTER 1


All of this stuff is useful for managers, but it’s also useful for theusers, because then they can say: “you know I spent a lot oftime focusing on private equity, and that tells me that thenature of my client base is more focused on private equity. Andso, this type of enhancement would help users know the mindof their client better.”

What ultimately evolved in this case is really quite remarkable:the project put in motion a cycle of innovation that cross-polli-nated ideas across boundaries between business and technology.Managers have been known to gripe that IT specialists with littleunderstanding of the business are given too much control over ITprojects. At the same time, CIO’s worry that employees with onlya limited understanding of technology are asking coders for theimpossible. But by aligning business, process, and technology,Hayward’s call-reporting project shows that neither of these con-cerns has to be true. Innovative ideas can come from anywhere, beunderstood by everybody, and then be put into place with amutual understanding of opportunities, goals, and responsibilities.But this happens only after a crucial prerequisite has been met:alignment between business, process, and technology.

WWhhaatt TToo MMaakkee ooff TThheessee SSttoorriieessThese stories are a lot to digest all at once. But even if the partic-ulars of one anecdote vs another still seem a bit overwhelming,there are a couple of key conclusions that can be made.

First, the business/technology disconnect isn’t just the stuff ofanalyst reports and magazine articles. In one form or another, peo-ple grapple with the disconnect in every industry from old-linemanufacturing to bleeding-edge biotech, and when disconnectscrop up between business, process, and technology, it causes seri-ous problems that impact the bottom line. To make this point, I’velooked to acknowledged industry leaders—people whose opinionsand experiences carry real weight. So when they approach thebusiness technology disconnect soberly and seriously, then youshould as well.

Real-World Evidence

25


Second, and more important, a common undercurrent runsbeneath each of these scenarios: companies that employ technol-ogy in alignment with sound business objectives succeed, whileenterprises whose IT projects have fallen out of line with businessobjectives fail. This is an important lesson to learn for both busi-ness executives and IT leaders: without a dedicated approach tocoordinate their efforts, it’s impossible to make sure that IT proj-ects will work with—rather than against—the business.

26CHAPTER 1


AApppprrooaacchhiinngg aa SSoolluuttiioonn

22

THE DISASTER STORIES from the previous chapter shoulddebunk once and for all the myth that the business/technologydisconnect is just a figment of the imagination for business jour-nalists and industry analysts. Clearly, professionals need a solutionto fix the catastrophic losses, failed projects, and missed deadlinesthat the disconnect causes.

But, as any medical researcher would no doubt tell you, recog-nizing a disease and coming up with a cure are different proposi-tions entirely. To get from a problem to a solution, you often needto view the present through the discerning lens of the past. ForBTM, this means understanding IT’s evolution from a purely tac-tical exercise in its earliest days, to a full-fledged strategic partnerwith its counterparts in the business. As the function changed,aligning business and technology—a responsibility that had been


second tier—became progressively more important and intro-duced new challenges for the IT department. By addressing thesechallenges the principles, activities, and governance that make upBTM help to align business and technology and to avoid real-world disconnects like those presented in Ch. 1.

BBTTMM aanndd tthhee OOffffiiccee ooff tthhee CCIIOOAlthough the effort to align business and technology needs toinclude many stakeholders, ultimately, there is one group thatshould take primary responsibility: the chief information officerand his or her immediate staff, or the office of the CIO. Somecompanies prefer to give this position a different title—vice pres-ident of IS or director of IT, for example. At the end of the day,however, these positions are mostly interchangeable with the CIOin the sense that their primary responsibility is managing the cor-porate IT department.

IT, like any other major business function, is both highly com-plex and unique to individual companies and business units. Thischapter does not attempt to present an authoritative view onwhat functions an IT department should include—you couldwrite books and books about the responsibilities of the IT depart-ment and still hardly scratch the surface. Instead, what’s impor-tant to pick up from this chapter is that broad trends describehow the function has evolved (see Fig. 2.1), and emerging chal-lenges for the IT department point to a new approach for solvingthe disconnect.

The Operational EraMost early IT departments consisted of a few secluded program-mers huddled (figuratively and often literally) around a main-frame system that served the entire enterprise. In keeping with thepurely tactical human resources and financial systems that theysupported, these primitive departments were considered cost cen-

28CHAPTER 2


ters that fell under the responsibility of business unit heads or thecorporate CFO.

These early IT departments assumed responsibilities such assetting up mainframes, managing early networks of personal com-puters (PCs), and backing up corporate data. In the end, this wasjust a supporting role: IT departments either provided back-officesupport directly, (managing a database of customer information,for example) or developed systems (such as accounting platforms)that were designed to automate back-office functions. These oper-ational tasks didn’t give IT much clout with executives, and dur-

Approaching a Solution

29

Operational

1980's 1990's 2000 PRESENT

BU

SIN

ES

S F

OC

US

Reengineering

New Economy

Today

Figure 2.1As the IT function has evolved, its business focus has increaseddramatically


ing the operational era, the department frequently struggled toearn the respect and trust of their peers in the business.

Reengineering The second phase of IT’s evolution happened in response to theexplosion of business process reengineering, or BPR, during theearly 1990s. Advances in technology like client/server computingencouraged management to envision a world where enterprisesoftware could be used to automate business processes and stream-line operations. In a reflection of the period’s challenging businessclimate, reengineering was used as a pretense for downsizing:Technology, it was reasoned, would either replace workers out-right, or at the least improve their productivity and allow them toassume new responsibilities, which would make extra workersunnecessary.

The IT department evolved in response to BPR to include notonly back-office operations, but also deployment of the systemsthat promised to automate the enterprise. Still, however, the func-tion focused on the technology and let others handle businessdecisions: Representatives from business units would pass along adescription of the systems that they wanted—at times somethingas simple as a vendor and package—and then the IT departmentwould take over, develop or deploy the system, and hand a fin-ished product back to the business.

These reengineering programs weren’t always successful, sincehaving software that was able to execute a process didn’t auto-matically make people change their behavior, or guarantee forthat matter, that the process embedded in the software was animprovement over its manual predecessor. In any event, IT’s inter-action with the business expanded dramatically during this periodas they were asked to develop and deploy new systems that wouldautomate business functionality.

The New EconomyWhen the New Economy burst onto the scene, the IT depart-ment, like all things related to technology, became larger than life.Many companies responded to the astronomical market capitaliza-tion of dotcoms and other startups by creating semi-autonomous

30CHAPTER 2


“e-business” divisions and giving strategic control over them tothe office of the CIO and other senior IT managers. In radicalcases, companies elected to actually spin off a dotcom to handletheir Internet business, with IT executives as senior managers,and sometimes the CIO as the new company’s chief executive.

In either of these cases, both the office of the CIO and ITworkers in general found themselves with new, strategic (“e-strate-gic” perhaps?) accountability. One thing to note here, however, isthat these business responsibilities were limited to either thee-business division or the spin-off—they were largely distinct fromthe business as a whole.

Like many executives, pundits, and analysts caught up in NewEconomy hype, these newly minted executives frequently failed toreconcile dramatic advances in technology with sound businessobjectives. As a result, many e-business divisions and spin-offspursued a strategy that might best be described as technology fortechnology’s sake—where real business objectives took a back-seat to IT trends like CRM and e-marketplaces.

TodayToday, of course, mainframe-era IT, reengineering, and the NewEconomy bubble are all things of the past, and the IT functionhas changed once again. With the retreat of New Economyexcesses, it would be tempting to speculate that the departmenthas relinquished its strategic responsibilities. Instead, however,both the office of the CIO and the IT department in generalhave been forced to assume even broader business responsibili-ties. Companies aren’t abandoning ambitious technology proj-ects. Instead, they are demanding real, bottom-line results fromthem. And, more than any other group, it’s the office of theCIO and the IT department who are being asked to deliver.

While the specific responsibilities of the IT department canvary from company to company (and even from business unit tobusiness unit in large conglomerates), in general, today’s ITdepartment has business responsibilities that touch nearly everyaspect of the function: developing and customizing software thatimproves how the business functions; controlling costs and maxi-mizing efficiency through project management; implementing


31


32CHAPTER 2

�

The Changing Role of the CIO

“I’ve interviewed a lot of CIOs over the years, and it’salways interesting to see the migration of the profession. Ithink right now the best CIOs would come in and talk asmuch about the business equation as they would talkabout the IT infrastructure.

What today’s CIOs really have to do is get into theminds of the business leaders—the CEO, COO, divisionheads—and find out what differentiates their productlines, their businesses, from anybody else. What are theyhoping to gain in value against their competitors? Or indelivery to their customers? And once the CIO reallyfocuses on the drivers of business success, then they cantranslate that back into ‘how can I build my IT infrastruc-ture to get a better picture of where we’re going and wherewe stand on that strategy?’

Once they see that, then when they go into meetingsand start talking about technology investment, they canspeak not just in terms of ‘this software has a payback of ayear’, but instead about ‘how IT impacts the business driv-ers and strategic differentiators for the business.’ And ‘ifwe put these pieces in place it allows us to do these thingsthat do truly differentiate us.’

And that’s a whole different level of discussion thanCIOs have had in the past. It’s the value that IT is goingto deliver to the business, and it’s the stepping-stonetowards IT being an integral part of the way you pull off abusiness strategy. That’s the mindset that successful CIO’sare carrying with them now. So they have as much of anenergy to want to learn about the needs of the business asthey do about the data centers, hardware, networks, andso on.”

– Jack Mollen, senior vice president of HumanResources, EMC Corporation


new hardware and software; managing strategic suppliers (includ-ing vendors, consultants, and partners) to maximize the value ofthe relationship; supporting operations and infrastructure, includ-ing the systems that automate crucial components of the business(CRM, supply chain management [SCM], HR platforms, etc.)and the IT infrastructure (servers, networks, PCs, and so on);managing change in the business; and maintaining the crucialcorporate data that helps managers throughout the enterprise tomake intelligent and informed decisions. Each of these areas isclearly related to the function’s traditional technology focus. Atthe same time, however, each requires a sound mastery of thebusiness which hasn’t historically been IT’s strongpoint.

EEmmeerrggiinngg CChhaalllleennggeessObviously, the increasing business focus that’s demanded of the ITdepartment is having a profound effect upon the function. Someof the challenges that the department faced five, ten, and eventwenty years ago—such as delivering new technology faster andmore efficiently—continue to be crucial components of the job.However, the growing business focus of today’s IT departmentalso emphasizes new challenges:

– Identify opportunities for business innovation that comefrom technology, and then coordinate with the rest of thebusiness to hone strategy accordingly

– Speak the language of the business to improve IT’s credibil-ity amongst business peers

– Unify services across multiple, otherwise-distinct businessunits

– Mitigate the risk of change in the face of continuouslyevolving technology

– Do more with less by extending the lifecycle of human andcapital assets


33


Identify Opportunities for Business Innovation The first challenge facing today’s increasingly business-focused ITdepartments is to monitor technology advances for opportunitiesthat could facilitate business innovation. In effect, this representsthe logical evolution of the strategic role for IT executives thatemerged during the New Economy. Unlike during the bubble,however, today’s executives are expected not only to identifyopportunities, but also to coordinate with the business to chart asingle, coherent strategy for the corporation.

This process involves communication both from business totechnology and vice versa. The business-to-technology dialogue ismore straightforward: Important technology decisions—whichprojects to green light, what standards to set, which vendorsshould become preferred partners—should always be made withone eye on business impact. To promote this type of exchange, theCIO has to be both a technology visionary and an accomplishedbusiness executive.

Communicating from the technology side of the house to helpshape business strategy is important as well. One of the majorroles for the modern IT department is to interpret emerging tech-nology trends for the business. The CIO needs to be proactive inthis regard by taking potential innovations directly to the seniorleadership team, communicating the opportunities and pressures,and steering the business strategy appropriately. It’s the CIO, inother words, who makes sure that the leadership understands tech-nology, or at least the role that technology should play in trans-forming the business. To accomplish this, IT needs to be astoryteller who identifies promising technology scenarios; com-municates the benefits, risks, and challenges to the business; andthen helps to coordinate between business strategy and the tech-nology that supports it.

Speak the Same Language as the Business The second challenge is to rebuild the faith in technology thatwas lost with the collapse of the New Economy bubble. One wayfor IT to reestablish credibility is to speak the same language as therest of the business: that of profit, loss, return on investment(ROI), and so on. During the mainframe days, when IT was still a

34CHAPTER 2


tactical exercise, the department was able to pawn this functionoff to the finance department and the CFO. And during the NewEconomy, of course, IT was essentially given carte blanche to pur-sue technology projects with reckless abandon—and little concernfor financial metrics.

But now, the collision between IT’s continuing strategic rele-vance and the end of the era of irrational spending demands thatprojects be justified according to business value and risk—justlike any other company initiative. This is important for tacticalprojects, of course, where costs are justified by direct financialreturns. But it’s even more essential when the IT department hasidentified technology trends that it believes will contribute in thefuture, but that can’t yet be reduced to dollars and cents.

In a sense, the IT department’s role here is similar to that of theCFO and the finance department. Like the CIO, the CFO isresponsible for interpreting complex information (financial datainstead of technological advances), and then identifying trendsand opportunities that will impact strategy. Unlike the CIO, how-ever, the CFO has automatic credibility to the business by virtueof their financial focus. CIOs need to earn their seat at the table,and the most effective way to do this is to become bilingual: to beable to speak the language of technology to identify opportunities,trends, and threats, but then also to be able to communicate thisinformation to business executives in the language that theyexpect from their peers.

Unify Services Across Multiple Business UnitsThe CIO, unlike other business unit heads, doesn’t have a specificfocus limited to the unit that he or she manages. Some of thetasks for which the IT department is responsible (establishing adevelopment methodology or selecting preferred vendors andimplementation partners, for example), do service the departmentdirectly. But the vast majority of projects that IT undertakes aredesigned and deployed for end-users outside the department.

First, and most obviously, there’s the complete universe ofemployees who rely on IT for things like voice mail, PCs, andmobile handheld devices. Then, there are vertically integratedfunctions that rely on enterprise applications to do their jobs: an


35


HR administration system for human resources, CRM for the salesforce, and so on. And the complete group of “clients” for the ITdepartment extends even beyond the borders of the business toinclude external consultants who need input for a project, or busi-ness partners (like distributors) who want access to internal infor-mation (such as inventory levels and available to promise).

In this regard, the CIO’s role is somewhat similar to that of theCEO: their sphere of influence includes every part of the business.Dawn Lepore, the former CIO at discount broker Charles Schwab,tells Harvard Business Review that she believes the two positions“do share a number of characteristics. Most unit heads need tohave a very focused perspective,” she explains. “CIOs must also befocused; additionally, they must be able to consider the business asa whole, as the CEO does.”1

An important offshoot of this broad responsibility is that ITfrequently finds itself brokering a compromise between distinctbusiness units. For example: In order to move from a decentralizedIT environment where each business unit supports their own ITfunctions to a centralized model where the entire enterpriseshares certain common services, some units have to sacrifice theindividual customization to which they’ve grown accustomed.Each unit, of course, will lobby for central services that are asclose as possible to their previous, homegrown systems. It’s the ITdepartment’s role to arbitrate between these competing groupsand settle on the appropriate trade-offs that are necessary to findcommon ground.

Mitigate the Risk of ChangeThe IT department’s fourth challenge is to manage functional ITchange in the face of technology that, even after the NewEconomy collapse, continues to evolve at a blistering pace. Tomanage change, IT first needs to anticipate the impact of makingbusiness and technology decisions. This impact is then weighedagainst potential downside risks to separate smart ventures fromreckless gambles.

The idea that IT is closely linked to change management isn’tnew. Since the middle 1990s when reengineering and processautomation were hot topics, one of the IT department’s key

36CHAPTER 2


responsibilities has been to balance the promises of a new tech-nology against the disruption that it might cause in the business.(According to findings in an Emory University study, large-scalefailed technology initiatives can depress stock price by as much as1.75%.2) A big lesson that we can learn from ERP and e-com-merce disaster stories is to not underestimate the importance ofanticipating change to avoid delays, overcome employee inertia,and minimize unforeseen costs. This ability will be crucial todaygoing forward, as technology becomes even more pervasive.

Extend the Life Cycle of Human and Capital AssetsFinally, today’s IT department is being asked to tackle more proj-ects than ever before—while simultaneously grappling withshrinking head counts and limited budgets for new hardware, soft-ware, and services. The pressure to “do more with less” weighsheavily upon the shoulders of CIOs in both good times and bad.When the value of IT spending is being questioned, allocatingresources efficiently is obviously of the utmost importance. Buteven during good times, CIOs are still asked to do more with less:When IT spending is on an upswing, the market for skilledemployees becomes extremely tight, and companies have troublehiring new resources with in-demand skills.

HHooww BBTTMM MMeeeettss TThheessee CChhaalllleennggeessThese five challenges—identify opportunities for business inno-vation, speak the same language as the business, unify servicesacross multiple business units, mitigate the risk of change, and domore with less—combine to make the IT function more focusedon the business than ever before. Not surprisingly, then, theapproaches, tools, and techniques that IT has relied on in thepast—development environments, project management, andobject modeling, for example—aren’t perfectly suited to today’sincreasing business responsibilities.


37


To give the office of the CIO and the IT department theammunition they need to tackle these five challenges, we need anew approach: the principles, activities, and governance thatmake up BTM. By mapping each of these back to today’s chal-lenges, we can see how BTM represents the missing piece of thepuzzle that finally helps to close the business/technology discon-nect (see Table 2.1).

From Challenges to the Principles of BTMThe principles of BTM represent underlying capabilities that needto be in place before companies can tackle BTM. By themselves,the principles of BTM aren’t sufficient to align business and tech-nology. But in order to do business model definition, process opti-mization, and technology automation—the activities of BTM thatdo the lion’s share of aligning business and technology—compa-nies first need to be able to put three principles to work.

38CHAPTER 2

The Principles of BTM

Utilize Predictive Modeling

Instill CollaborativeDecision-Making

Reuse Knowledgeand Assets

The Activities of BTM

Business Model Definition

Process Optimization

Technology Automation

Governing with BTM

Strategic Direction

Tactical Control

Identify Opportunities for Business Innovation

Speak the Same

Language as the

Business

Mitigatethe Risk

of Change

Extend the Life Cycleof Human

and Capital Assets

UnifyServicesAcross

MultipleBusiness

Units

Table 2.1Five challenges for IT point to a new approach: the combination ofprinciples, activities, and governance that makes up BTM


The first principle of BTM, Utilize Predictive Modeling, helpscompanies to construct a blueprint during IT projects so that theycan preview change before implementation begins. This, ofcourse, is a powerful mechanism for reducing risk, since potentialproblems can be identified and avoided up-front, rather than lateron, when putting out fires results in costly recoding and aban-doned projects. At the same time, models can be powerful propsfor storytelling—a skill that the IT department needs in order tocommunicate opportunities for business innovation to a non-tech-nical audience of executives.

The second principle of BTM is to Instill Collaborative Decision-Making. Recall that matching technology opportunities with busi-ness strategy is an important aspect of the CIO’s role. This requirescoming to a consensus between the strategy team and the CIO.Without promoting a dialogue to help IT professionals speak thelanguage of the business, companies maintain by default the dis-tinct business and technology strategies that caused such cata-strophic harm during the New Economy bubble. Collaborativedecision-making is also a crucial skill for coordinating betweenbusiness units to determine which IT services to centralize andwhich to delegate to individual units.

Make Knowledge and Assets Reusable is the final principle ofBTM. Companies can help to mitigate risks during IT projects byrecycling designs and strategies that have worked in the past.Also, reuse can help to promote common enterprise standards forIT, and also to drive otherwise disparate divisions to make use ofexisting resources (such as applications and hardware) rather thanbuilding their own from scratch. Finally, IT managers recognizethat reuse enables them to wring the maximum amount of pro-ductivity out of their existing resources, allowing them to do morewith less in periods of both boom and bust.

From Challenges to the Activities of BTMThe activities of BTM—including Business Model Definition,Process Optimization, and Technology Automation—represent theformal design mechanism for developing a blueprint that alignsbusiness, process, and technology. These tasks help to constructmodels and create cross-links to check for alignment between the


39


three. During business model definition, teams capture a snap-shot of the enterprise in order to capture and communicate strat-egy. Process optimization, the second activity, identifies anddiagrams the processes that are required to support the businessmodel. Finally, during technology automation, the team identifiesthe applications and systems that will support their businessprocesses. Together, the business, process, and technology modelsmake up an end-to-end enterprise model, or a blueprint for enter-prise architecture.

To complete these activities, employees have to make impor-tant design decisions, evaluate multiple scenarios, and choosebetween imperfect solutions. By previewing these decisions in theform of models for business, process, and technology, the team cananticipate problems and reduce the risk of change. At the sametime, modeling helps business and IT professionals to discovernew uses for technology that can result in business innovation.

From Challenges to the Governance of BTMFinally, BTM helps to govern both the Strategic Direction of andTactical Control over IT. The mechanism that BTM uses to setstrategic direction is the IT portfolio, which views projects asa portfolio of investments to be optimized according to bothfinancial and non-financial metrics. By forcing teams to attachmetrics to projects, portfolio management helps IT professionalsto speak the language of business. And since enterprise modelsare crucial tools for identifying business opportunities, BTM canalso help to synchronize developments in IT with ideas for inno-vating business strategy.

Governance also helps the CIO to maintain tactical controlover IT projects to make sure that they deliver the maximumbusiness value by managing both quality and cost. The tacticalcontrol that BTM enables helps both to unify how projects arecarried out across multiple business units, and to establish stan-dards and best practices to mitigate the risk that projects will fail.Also, it promotes the reuse of assets across multiple projects inorder to extend the life cycle of human and capital assets.

40CHAPTER 2


AA NNeeww AApppprrooaacchhBy meeting the challenges that IT departments face in their searchfor alignment, BTM fills a void that had long been ignored despiteits yearly position on top ten lists of CIO concerns; despite its fre-quent appearance in magazine articles and analyst reports; anddespite its first-name familiarity among practitioners in the field.With BTM, however, the office of the CIO and the IT departmenthave a new weapon to wield against the disconnect. And while theIT community would undoubtedly preferred to have come acrosssuch a solution a long time ago, in a sense the timing couldn’t bebetter. Today, IT departments are searching desperately for an anti-dote to the pounding headache left over from their New Economybinge. This disruption has driven IT to reexamine its role in thebusiness, survey the damage that the business/technology discon-nect has caused, and ultimately recognize the opportunity for anew approach that aligns business and technology.


41


TThhee PPrriinncciipplleess ooff BBTTMM

IIIIPPAARRTT

“Important principles may, and must, be inflexible.”– Abraham Lincoln

THE DESIGN FOR YOUR IMAGINARY DREAM HOUSE is finallycomplete. Over the course of several meetings, you, Janet (thearchitect), and Robert (the contractor) have collaborated todraw up plans for your new home that live up to everybody’sexacting standards. As your last meeting wraps up, you walkboth Janet and Robert to the door, shake each of their hands,and thank them for a job well-done. Once they have gone, youreturn to the kitchen table, where the plans are still spread out.

PartII_FINAL.qxd 7/25/2002 3:28 PM Page 43

Even though the three of you spent hours poring through thedetails of the design—details that fall far outside your own archi-tectural comfort zone—the entire process went off without ahitch. You couldn’t possibly hope to understand most of the deci-sions that Janet and Robert grappled with, but thanks to theirexpert approach they were still able to tell a simple and concisestory about what it will be like to live in the house when it’sdone, which is exactly what you needed to know to help get thedesign right. Obviously, this method wasn’t just the result of goodfortune: Both Janet and Robert are highly trained professionalswho have spent years honing their crafts in academic and profes-sional environments.

Only by mastering a set of underlying principles can profes-sionals like Janet and Robert ensure that their approach runs assmoothly as it did in your dream house project. These principlesprovide the basic building blocks that are necessary for profes-sionals to design buildings that deliver the most value to theirclients. Three examples of the underlying principles that are nec-essary for designing a home are drafting (including subjects likeorthographic, axonometric, and oblique drawing systems; dimen-sioning, and the alphabet of lines), structural engineering (trademath; properties of materials; and designing the skeleton that sup-ports the building, including beams, joints, walls, and so on), andstandard blueprint notation (including recognized symbols forplumbing and electricity, as well as architecture and engineeringelements in the blueprint).

Without their expertise in areas like these, Janet (the archi-tect) and Robert (the contractor) wouldn’t have the tools thatthey need to bridge the gap between their specialties and yourdemands as a client. Similarly, Janet (the consultant) and Robert(the CIO) need to adhere to certain principles before they can useBTM to bridge the gap between business and technology. Noarchitect or contractor who expects to get a commission wouldapproach a potential client without an encyclopedic knowledge ofdrafting, structural engineering, and standard blueprint notation.And no CIO or consultant should expect to align business andtechnology if they can’t apply the three principles of BTM: UtilizePredictive Modeling, Instill Collaborative Decision-Making, and MakeKnowledge and Assets Reusable.

44PART II


IInn TThhiiss PPaarrtt……Part II: The Principles of BTM introduces the principles that pro-vide a solid underpinning for aligning business and technology.The first principle, to utilize predictive modeling, enables compa-nies to preview decisions and designs before beginning costlyimplementation. At the same time, it helps the team to embraceimpact analysis—a technique that replaces myopic decisions witha holistic view of the IT project. The second principle of BTM,instill collaborative decision-making, applies to both vertical col-laboration between members of the same project team, and hori-zontal collaboration, where amorphous “great ideas” arecommunicated across departmental and project team boundaries.Finally, the last principle, making knowledge and assets reusable,encompasses knowledge management, where companies capturedocuments and relationships that can be targeted to relevantemployees, and create a reusable repository of model designs,which helps to establish standards and minimize rework.

The Principles of BTM

45


MMooddeelliinngg,, CCoollllaabboorraattiioonn,,RReeuussee

33

AT A SOMEWHAT ABSTRACT LEVEL, everybody seems to havea pretty good idea of what a principle is: a “theoretical underpin-ning”, or maybe a “guiding purpose”, or a “pillar.” These amor-phous statements are well and good in the abstract. But for thepurposes of BTM we need to be more specific: Before you caneven think about using the activities of BTM to align business andtechnology, you first have to embrace three mutually supportiveprinciples of BTM:

– Utilize Predictive Modeling– Instill Collaborative Decision-Making– Make Knowledge and Assets Reusable


HHooww tthhee PPrriinncciipplleess WWoorrkk TTooggeetthheerrThe first principle of BTM, Utilize Predictive Modeling, is the mostimportant day-to-day task in BTM. In the broadest sense, predic-tive modeling is a technique that can be applied to any area whereunderlying details threaten to obscure overall decisions; wherereal-world scenarios can be decomposed into distinct elements;and where hidden interdependencies between these elementsmake it difficult to visualize the overall effect of modifying anindividual piece of the puzzle.

Once companies start to utilize predictive modeling, the otherprinciples of BTM automatically become important as well.Modeling is an inherently social activity that draws a broad com-munity of contributors, from executives to business managers toprocess analysts and technology specialists. Their broad base ofinterests and varying degrees of expertise makes it essential toInstill Collaborative Decision-Making, the second principle ofBTM. Modelers also need a way to capture and share the intel-lectual capital that they create. To achieve this, they need toMake Knowledge and Assets Reusable, the third and final principleof BTM.

UUttiilliizzee PPrreeddiiccttiivvee MMooddeelliinnggThe core benefit of the first principle of BTM, whether it goesby “modeling” or something else like “design” or “blueprinting,”is that it helps to visualize the end goal before beginningcostly—and often irreversible—implementation. In the broadestsense, a model is a virtual representation of a real thing. Bymanipulating this representation, modelers can preview a solu-tion and address design flaws before they manifest themselves inthe final product.

There’s a widespread and unfortunate misconception that mod-eling is a highly technical exercise that needs to be tackled by ateam of trained specialists. At times, of course, modeling can befound in pocket-protector-friendly environs like nuclear engi-

48CHAPTER 3


neering, macroeconomics, or genetics. But this is more a reflectionof inherent simplicity than any tendency towards complexity: Byhelping to simplify design and decision-making, modeling actuallyclears up complex problems, which is why it shows up in theseareas. When observers mistake modeling for a technical, compli-cated exercise, they’re essentially confusing the message (such asmodeling a complex chemical reaction) with the messenger (mod-eling itself).

Some of the most powerful varieties of modeling (such as thespreadsheet example we’ll look at in a moment) allow even non-technical users to preview change, or to “predict,” before puttingnew ideas into practice. This, of course, is where the “predic-tive” in “utilize predictive modeling” comes from. It’s also whymodeling is such an important part of BTM: It helps to predictthe impact of business and IT change by becoming the “aim” in“ready, aim, fire.”

BTM puts modeling to work as an innovation infrastructure forIT projects. During the design stage, it functions as a blueprint inwhich teams can set clear goals and flesh out a solution beforeactually writing code. In the build, test, and deploy stages, themodel acts as a reference point to orient ongoing work and tohelp guide last-minute modifications in the event that unfore-seen challenges and opportunities pop up. By playing these impor-tant roles, modeling helps the IT project team pre-empt costlymistakes and improve the quality of the systems that they develop.

BTM’s use of modeling isn’t just about making incrementalimprovements to an existing process, however. In addition to rel-atively modest gains in efficiency, modeling also empowers BTMwith other, more dramatic capabilities that can literally reinventhow IT projects approach the “aim” part of “ready, aim, fire.”This sounds like a bold claim. However, there is ample precedentfrom previous modeling revolutions—such as object modeling,computer-aided design/computer-aided manufacturing (CAD/CAM), and especially financial modeling and the spreadsheet—to suggest that modeling can indeed accelerate critical businessactivities.

Modeling, Collaboration, Reuse

49


Financial Modeling and the SpreadsheetBefore the personal computer revolution, Wall Street analysts per-formed complex spreadsheet calculations using only a simple cal-culator. This process was completely inflexible, prone to mistakes,and thoroughly mind-numbing. In order to make changes to amodel (whether to vary inputs or correct mistakes), analysts hadto rework the entire thing, a process that—needless to say—wasinefficient.

In 1978, Harvard Business School student Dan Bricklin recog-nized an opportunity to automate this tedious process using soft-ware and the rapidly maturing PC. He, along with former MITclassmate Bob Frankston, founded Software Arts, Inc., and intro-duced the VisiCalc spreadsheet to the market. Almost overnight,VisiCalc transformed how financial analysts worked.1

The obvious advantage to Bricklin and Frankston’s innova-tion was efficiency. Complex models that once took hours toupdate could now be modified with a few keystrokes. Not surpris-ingly, spreadsheets like VisiCalc became the de facto standard forfinancial modeling, and frustrated business school students andfinancial analysts clamored all over each other to put the newtechnology to use. The demand for spreadsheets was so over-whelming, in fact, that it is frequently credited with creating theinitial boom market for business PCs.

But the real revolution that the spreadsheet kicked off wasn’tjust about efficiency and automation. By unburdening analystsfrom the pedantic work of manual calculations, spreadsheets low-ered the marginal cost of evaluating new scenarios from thou-sands of dollars to almost zero. This, in turn, encouragedexperimentation and creativity. The same employee who oncespent days perfecting a single model could suddenly produce sev-eral alternatives in a single afternoon.

Spreadsheets kicked off an industry-wide movement towardsexperimentation that revolutionized how analysts—and the finan-cial services industry—worked. By allowing workers to easily cre-ate and analyze the impact of multiple scenarios, spreadsheets andpredictive modeling encouraged a culture of rapid prototypingand innovation, or impact analysis, that is as applicable for align-ing business and technology as it is for the financial world.

50CHAPTER 3


From Modeling to Impact AnalysisImpact analysis lets teams alter input factors, create multiple out-put scenarios, evaluate the end-to-end impact of each, and even-tually select and implement the optimal solution. This stands indirect opposition to conventional, linear problem-solving tech-niques, where decision-makers analyze sub-problems at each logi-cal step along the way, and then assume that the overall impact oftheir choices is the best one (see Fig. 3.1).

Like modeling in general, impact analysis can be used toaddress a broad range of activities. For example, it is often used insupply chain planning for advanced, data-driven calculations thatoptimize a particular function (such as inventory costs) givenunique inputs and constraints (such as market demand, logisticalrestrictions, and manufacturing capabilities). At the other end ofthe spectrum, impact analysis can address much simpler problems.A good example is Dell Computer’s build-to-order website, wherepotential buyers test multiple PC configurations until they find a


51

Impact AnalysisLinear Problem Solving

Decision A

Decision B

Decision C

Decision D

Final Decision

Final Decision

Decision A

Decision B

Decision C

Decision D

End-to-End Analysis

PartialAnalysis

PartialAnalysis

PartialAnalysis

PartialAnalysis

Decision A

Decision B

Decision C

Decision D

Figure 3.1Linear problem solving decomposes sub-problems along the way,while impact analysis examines the end-to-end impact of multipledecisions


good match between the features they want and the cost they canafford to pay. In both of these cases, individuals vary inputs, rulestranslate these inputs to outputs, and team members comparethe impact of multiple scenarios to choose the solution that fitstheir needs.

In order for impact analysis to work, the scenario being mod-eled should conform to three guidelines:

– It should have easily identified inputs, rules, and outputs:Impact analysis requires employees to define a set of inputsand then link these to outputs using predefined rules. Theseinputs and outputs are often quantitative (as in the supplychain optimization problem), but they can also be qualita-tive (such as the PC configuration options). To producegood results, these criteria—the rules that link them—mustaccurately reflect the real-world problem.

– It should have multiple configuration options and deci-sion factors: Problems that contain only a few inputs andoutputs aren’t suited to impact analysis because the effect ofaltering inputs is often obvious. When the outputs are lessintuitive on the other hand, impact analysis can help deci-sion makers experiment to identify good solutions.

– The relative cost of implementation to design is high:Scenarios that are inexpensive to design but difficult toimplement are ideally suited to impact analysis. Our ongoinganalogy to an architectural blueprint is a case in point here:It’s unrealistic for you to contract a builder to build fivehouses so that you can choose the one you like the most. It’sentirely possible, however, that you may choose to commis-sion an architect to draft five blueprints. You can then com-pare them, choose your favorite, and give it to the contractorto build. This is where the synergy between modeling andimpact analysis really comes into play: Predictive modeling isa powerful tool for lowering design costs, and so a crucialdriver for impact analysis.

Anticipating Unforeseen Ripple EffectsThese three characteristics combine to highlight a point thatis crucial to understanding why impact analysis fits well with

52CHAPTER 3


BTM. Disconnects between business, process, and technology areoften introduced when individual decisions have unforeseeneffects on the blueprint as a whole. “Projects lack a holistic view,”PACCAR CIO Pat Flynn says, “because we tend to look at it as alinear process: decompose the problem, decompose the problem,decompose the problem, make a decision. But it’s very hard to goback and say ‘that decision has a set of ripple effects’.”

Consider an example: A team of process analysts is working ona project for which they need to diagram the approval process forpurchasing non-production goods. Using conventional methods,their actions would be informed by an in-depth analysis of thedecision. They would start by gathering as much data as possible:the current approval process; the complete list of approved sup-pliers, products, and contract types; the organizational hierarchyand current purchasing limits for each employee; the existingtechnology assets that automate this process; and the supportingsystems such as hardware and networks. After pulling all thisinformation together, they would weigh the data, diagram aprocess flow that best fits the given constraints, and sign off onthe decision.

This sounds reasonable at first glance, but it fails to take intoaccount any ripple effects that might spread from this individualdecision. Let’s say, for instance, that one supplier relied on a legacyorder-processing system to interface with our example company’sprocurement system. Let’s also say that when our team reengi-neered their approval process, they did so in a way that made itincompatible with this legacy application. And finally, let’s saythat this particular supplier accounted for 40% of all purchases ofnon-production goods last year. Clearly, this should compel theprocess analysts to revisit their decision. But without impactanalysis they wouldn’t find out about the ripple effects until itwas too late.

The Perceived of Value of Models and the Whitespace ProblemBefore they can get started with modeling and impact analysis,companies need to overcome a couple of obstacles. The mostobvious is the common perception that the time it takes to


53


develop a model during the design stage is better spent on imple-mentation. This is due in part to previous experiences with mod-els that were frighteningly inaccessible to all but the most die-hardexperts. Since non-specialists (a group that frequently includesmanagers and other authority figures) couldn’t experience theirvalue firsthand, they assumed that the models were a waste oftime. The shorthand solution to this concern is to make the mod-eling environment friendly enough for a broad range of people topick it up and experiment according to their own level of comfort.A good example of this is a financial model whose inner workingsmay be exceedingly complex but whose overall purpose is clearlycommunicated to a non-technical audience.

In extreme cases, however, modeling can be a waste of time.This happens when people get stuck in an endless design loop; Bycontinuously tweaking the model in the quest for a perfect solu-tion, they never get around to actually implementing what they’reworking on. The way to counter this impulse is by linking a systemof real-time monitoring to metrics, goals, and objectives that areestablished at the beginning of the project. This implies a link toboth project and performance management that is crucial to anytype of modeling.

The other obstacle that stands in the way of modeling andimpact analysis is the gap that exists between multiple modelsand between models and the real world. These gaps are referred toas “whitespace,” and they’re familiar culprits in cases where mod-eling hasn’t been successful. Typically, the tools that are availableto IT workers to model business, process, and technology are dis-jointed, and so they tend to exacerbate rather than overcome thewhitespace problem. Most are geared either to a particular task(process modeling, object modeling, or knowledge management)or to broad horizontal activities (word processing, drawing, orspreadsheets). A consequence of these disjointed offerings is thatcompanies tend to use multiple tools and environments to developtheir models. When changes are made in one environment (say aprocess diagram) they aren’t automatically reflected in other areas(a requirements document or business strategy memo, for exam-ple). Without integrated tools, the project team has to proactivelyanticipate ripple effects to keep their models aligned.

54CHAPTER 3


The Advantages of Predictive ModelingThe advantages that modeling provides for BTM are closely anal-ogous to those that spreadsheets deliver in the financial world. Byutilizing predictive modeling to align business and technology,enterprises can:

– Mitigate risk by forcing teams to flesh out details in thedesign stage

– Enable creative impact analysis by lowering the marginalcost of experimentation

– Democratize design decisions by hiding underlying detailsfrom non-technical team members

– Communicate overall design to promote collaboration

Mitigate RiskThe first of these advantages, mitigating risk, is a key advantage ofmodeling in general. Initiatives can fail because of any number ofunforeseen obstacles: poorly defined business objectives; processesthat don’t map to application packages; system choices thatrequire heavy customization; even plain, old-fashioned installa-tion failures. By itself, modeling can’t guarantee a flawless initia-tive; but by forcing stakeholders to collaborate and produce anend-to-end design before beginning the actual implementation, ithelps work out kinks in the model—where they are far easier totackle than in the real world.

Mitigating risk is an important factor in any enterprise initia-tive, and it’s a compelling counterbalance to our first concernabout predictive modeling—that it isn’t worth the time and effort.Implementation mistakes can cost many times more than even themost thorough modeling.

Perform Impact AnalysisSecond, predictive modeling helps companies to perform impactanalysis. Most enterprise initiatives adhere to a linear planningprocess, where decisions made early on (the business driversfor the initiative, for example) become cast in stone as the projectprogresses. This is okay when both the initial guidelines are


55


completely static and the consequences of decisions only affectfuture decisions.

In IT projects, however, neither of these conditions applies.Early choices such as business drivers can become out-of-date at amoment’s notice in response to things like market changes andrecent moves by competitors. At the same time, choices madelater in the process (such as which application package to select)can affect decisions thought to have been nailed down earlier(such as the process flow that is to be automated). By locking indeterminations up front, teams forfeit flexibility that they mayneed down the road.

Also, linear planning assumes that what’s best for any individ-ual decision must be best for the project as a whole. This attitudeignores hidden ripple effects between seemingly unrelated deci-sions. For example, a consultant choosing an application packagemay sensibly select the one that fits the most requirements. Butthis decision assumes that all the requirements are equally impor-tant to the initiative. If the consultant chooses a package thatleaves out a few crucial requirements, he or she could introducean inconsistency between the best individual decision (the pack-age that meets the most requirements), and the best overall solu-tion (the system that best supports the overall business goals ofthe project).

To compound this situation further, ROIs are frequently lacedwith intangibles such as “improved customer relationships” and“strategic fit with other systems.” Managers who have been taskedwith making a particular decision in a linear process often feelcompelled to invent decision criteria to justify their choices, evenif these criteria fail to take into account the project’s overall,intangible returns. Eric K. Clemons, a professor at the WhartonSchool of Business, describes this phenomenon as “the ‘concrete’and ‘measurable’ driving the significant out of the analysis.”2

Impact analysis counters these concerns by letting teams com-pare end-to-end potential outcomes. Even in cases with intangiblereturns, the impact analysis technique improves decisions by mak-ing it easy to compare the relative value of multiple scenarios,rather than forcing teams to assign allegedly absolute criteria thatobscure more important, elusive goals. Seeing end-to-end designs

56CHAPTER 3


also helps to calm the impulse to enter an endless design loop byencouraging teams to select a final design, move from modeling toimplementation, and avoid the temptation to get stuck on anindividual decision.

Democratize Design DecisionsThe third advantage of predictive modeling is that it hides under-lying details from the non-technical audience. By simulating thegeneral behavior of real-world subjects while simultaneously hid-ing complex details, models encourage even non-technical teammembers to “play around.” This broadens the base of users whocan make important design decisions from IT professionals to alsoinclude business managers, process analysts, and even senior exec-utives. Collaboration between this variety of stakeholders to lever-age business and technical expertise leads to new scenarios andinnovative solutions to problems. Michael Schrage, the co-direc-tor of the MIT Media Lab’s eMarkets Initiative and the author ofSerious Play, describes how this phenomenon plays out in anothermodeling discipline, computer-aided design, or CAD:

Engineering organizations have found that nonengineeringmanagers and marketers want to play with CAD software totest their own product ideas and enhancements. Such “amateurCAD” signifies a growing democratization of design promotedby pervasive and accessible modeling technology. The chang-ing nature of the modeling medium is forcing design profes-sionals to manage the prototyping efforts of design amateurs.The declining cost and rising importance of prototyping isbroadening the community of designers.3

Communicate Design DetailsFinally, models can be compelling communication tools. This canhappen in the form of a business unit evaluating an existing enter-prise system to see if it could be reused in their division; a devel-opment team communicating a proposed project to a manager forapproval; or an enterprise architect team communicating interfacespecifications to an external business partner for integration pur-


57


poses. This communication is also the key to bridging gapsbetween distinct models and ultimately to overcoming the white-space problem.

IInnssttiillll CCoollllaabboorraattiivvee DDeecciissiioonn-MMaakkiinnggThe second principle of BTM is to instill collaborative decision-making. The concept of collaborative decision-making is fre-quently employed as a catchall that includes everything fromface-to-face communication to knowledge management to coor-dinating partnerships. This scope is too broad for our purposes, ofcourse, so this discussion is limited to the role that collaborationplays in the specific context of BTM: decision-making that iseither facilitated by modeling itself or undertaken to support themodeling initiative.

The idea of collaborative decision-making in BTM is a descen-dent of the broader concept of a virtual workspace, where poten-tially disparate teams can come together to access a common workenvironment, post and share supporting information, and com-municate in real time to solve problems. For BTM, this virtualworkspace equates to a combination of the model itself and threekey levels of collaboration:

– Direct Collaboration is when people discuss issues in realtime using tools like email, instant messaging, and notifica-tion services. These discussions are meant to facilitate dia-logue between decision makers or to solve a specific problem.For example, an implementation consultant may need toestablish which IT standards are in place through a directquestion-and-answer session with members of the client team.

– Model-level Collaboration happens when more than oneteam member contributes to any individual model. Thisoccurs quite frequently, such as when analysts require super-vision and input from managers, or individual models spanmultiple skill areas or business units. A good example ofmodel-level collaboration is a supply chain process model,where demand planners, plant managers, and supply plan-

58CHAPTER 3


ners come together to diagram an end-to-end flow of how amanufacturer plans and executes their supply chain. Model-level collaboration includes model check-in/check-out, ver-sion control, change tracking, and model comparison/mergeactivities. This level of collaboration can also include aspectsof document management to help teams share knowledgethat supports their decisions in the model. And it can alsoact as a gateway to direct collaboration, for example when aninconsistency between two versions of a model is discoveredand the team collaborates to determine which version is correct.

– Alignment-level Collaboration represents the highest levelof collaboration in BTM. It is driven by the necessity tocross whitespaces to align multiple models. Because BTMspans business modeling, process optimization, and technol-ogy automation, it by nature includes a variety of stakehold-ers with unique areas of modeling responsibility. To crossthese disciplines, team members often negotiate and come toa shared decision. This may involve a prolonged, robustexchange of information that includes elements of bothmodel-level and direct collaboration. To facilitate back-and-forth exchange, team members utilize a mini-impact analysisof sorts, where each side develops multiple scenarios until anacceptable compromise is reached. A good example of align-ment-level collaboration is when analysts from two businessunits compare process models to establish standards forenterprise processes.

Vertical and Horizontal CollaborationThe three levels of collaboration can occur both vertically (withina single business unit or team) and horizontally (across multiplebusiness units or teams).

Most day-to-day communication within an IT project fallsunder the aegis of vertical collaboration. Its goal is to improveexisting processes by sharing information and expertise. One man-ifestation of vertical collaboration is communication betweenteam members at different levels of the same business unit, fromexecutives to business unit heads to managers and so on. In the


59


worst cases, top-to-bottom communication between those whoset objectives and those responsible for meeting them resembles aversion of the children’s game, Telephone: The original message isgarbled along the way and disconnects crop up between strategyand execution.

Vertical collaboration improves this process by making surethat the directives passed between managers and their reportshappen accurately and in real time. For top-down communicationthis means that changes in strategy or goals are communicated intime to change course, and for bottom-up communication thismeans that needs and issues are passed back up to executives tomake small, corrective changes that don’t jeopardize the project asa whole.

However vertical collaboration isn’t necessarily limited tomembers of the same business unit. Another type of vertical col-laboration focuses on particular teams or business processes. Anexample here is product development, when representatives frommarketing, sales, and engineering define specifications, share newproduct designs, and make update requests. The impetus for thiscollaboration is improved communication and efficiency: Themarketing team knows which market niche to exploit, the salesteam understands customer needs, and engineers have the tech-nical capability to design new and exciting product offerings. Byimproving the flow of information between participants, toolsthat facilitate vertical collaboration in product development canimprove speed to market and reduce production errors.

In BTM, vertical collaboration shares important characteris-tics with both manager-to-report collaboration and process andteam-based collaboration such as product development. Byencouraging team members to share metrics, project manage-ment information, and relevant knowledge bits, collaborationencourages holistic decision-making, and ultimately reducesdevelopment time and cost.

While vertical collaboration is all about efficiency, horizontalcollaboration is focused on helping to share amorphous “greatideas” that can deliver unique insights that are especially powerful.Vertical collaboration is project and process-based, and includesstakeholders with multiple specialties. Horizontal collaboration

60CHAPTER 3


is quite the opposite: General trends and opportunities are sharedbetween employees with similar job functions, but who work indifferent business units or on different projects.

One example of horizontal collaboration could be the interac-tion between the customer service and product design teams in aconsumer products company. Suppose that over time, the cus-tomer service team notices that a large number of the calls totheir help desk are from users who can’t figure out how to use aparticular feature of a particular product. After documenting theissues, a service team member contacts the product design team.The two groups collaborate to determine the exact nature of theproblem and change future versions of the product to make itmore intuitive. In this example, two otherwise disparate teams(customer service and product design) collaborate to share aunique insight (user difficulties with a particular product feature)in a way that was outside the scope of normal processes and regu-lar communication.

The advantages of horizontal and vertical collaboration arepredictably unique from one another. In vertical collaboration, thefocus is on pervasive integration of well-defined team membersand processes in order to share knowledge and improve efficiency.Horizontal collaboration, on the other hand, requires employeesto identify and analyze important developments in their own workenvironment, and then to pass these along through free-forminteractions to whomever is most equipped to act upon them.This is the foundation for an integrated organization that recog-nizes broad trends and shares them across business lines to provideopportunities elsewhere.

T-Shaped ManagingBoth vertical and horizontal collaboration are essential compo-nents of BTM. Embracing both in tandem requires a managementtechnique that Morten T. Hansen and Bolko von Oetingerdescribe in the Harvard Business Review as the “T-shaped man-agement” model. In BTM, the vertical component of T-shapedmanagement encompasses most day-to-day work on IT projects,and focuses on individual modeling teams and their managers onup to the office of the CIO and the CxO Suite. But BTM also


61


requires teams to collaborate horizontally to share what Hansenand von Oetinger call “implicit knowledge, the type needed togenerate new insights and creative ways of tackling business prob-lems or opportunities.”4 These horizontal interactions couldinclude a marketing manager who identifies a sales trend andpasses it along to a product design team, or an IT professionalwho recognizes an opportunity to reuse an existing ERP system inanother department. Figure 3.2 illustrates the roles that verticaland horizontal collaboration play in BTM, and shows some typesof information that are commonly exchanged in each:

Contextual and Cultural BarriersBefore they can achieve T-shaped management, companies needto overcome both contextual and cultural barriers to collabora-tion. Contextual barriers are the biggest obstacle that stands in the

62CHAPTER 3

Business Unit B Project Team

Horizontal Collaboration(Key Insights, Business Opportunities, Broad Trends...)

Vertical Collaboration(Email, Meetings, Research...)

Business Unit A

Figure 3.2Vertical collaboration encompasses day-to-day work, whilehorizontal collaboration delivers key insights and opportunities


way of collaborative decision-making. Most collaborative systems,including groupware or virtual workspace applications, don’t inte-grate directly with everyday work environments, so employees areforced to leave their workspace—be it a word processor, spread-sheet, CAD/CAM tool, or even the factory floor—to interfacewith others. IT analyst IDC describes this phenomenon as a“schism between how people get information and what they cando with it.”5

For vertical collaboration, the contextualization problem ismore practical than anything else: Team members know what toshare and with whom, but many times lack the infrastructure tocommunicate within their familiar business applications. In hori-zontal collaboration, however, the impetus for collaboration isn’tas intuitive. Issues are less likely to be explicitly documented inthe first place, and it can be difficult to determine who to collab-orate with, as partners come from outside the immediate team orfrom different business units altogether. This means that not onlydo employees not know how to collaborate, but they also don’tknow when or with whom to do so.

People also fail to collaborate because of ingrained culturaland organizational issues. In the simplest case, they fail to recog-nize either the person with whom they should be collaborating orthe need to collaborate at all. A process analyst faced with choos-ing to modify either a current purchasing process or a new pro-curement application, for example, might not know that acolleague in another department recently grappled with a similarproblem, and so might be a good source of knowledge and advice.

A second, more deep-seated challenge is to overcome the strictconcept of ownership that impedes collaboration—especially hor-izontal collaboration between business units. There are innocentand not-so-innocent reasons why this happens. Sometimes, peoplesimply assume that they should solve their own problems, andconsequently miss opportunities to collaborate with peers whomay have valuable insight into their dilemma. Other times, cultural barriers get in the way. Information from outside theimmediate team may be considered untrustworthy. Or, in othercases, knowledge producers may fall prey to an ingrained tendencyto hoard information for their own personal advantage. In organ-


63


izations where employees compete internally (to acquire cus-tomers, for example), this last condition may require a system ofincentives and penalties to encourage open information exchange.

The Advantages of CollaborativeDecision-MakingCollaborative decision-making provides a number of importantadvantages for BTM. By combining vertical and horizontalcollaboration to employ a T-shaped management model, enter-prises can:

– Achieve the BTM equivalent of concurrent engineering:simultaneous and synchronized business modeling, processoptimization, and technology automation

– Maintain alignment and communication between decisionsmade in disparate environments

Achieve Concurrent Business, Process, and Technology DesignThe first advantage of collaborative decision-making is that ithelps companies to achieve the BTM equivalent of concurrentengineering, where manufacturers collaborate at every stage ofthe value chain so that all aspects of product development—fromengineering to marketing to manufacturing design—can be car-ried out simultaneously. Collaborative decision-making does thesame for IT projects by allowing each activity of BTM—businessmodel definition, process optimization, and technology automa-tion—to occur simultaneously. When both product design andBTM occur concurrently, cycle times decrease and critical issuesin quality control are addressed early on in the process.

Maintain Alignment Between Disparate DecisionsThe second advantage of collaboration is that it helps team mem-bers to make intelligent trade-offs that maintain alignmentbetween seemingly disparate decisions. When companies employmultiple tools for each of the three activities of BTM, they invitedisconnects between choices made in separate environments. Bycollaborating to unify decision-making across multiple environ-ments, team members can provide visibility into choices that are

64CHAPTER 3


made in other areas of the project. For example, an implementa-tion consultant may need to determine why a modification wasmade to a process in order to balance its relative importanceagainst the changes to the technology infrastructure that itrequires. By implementing collaborative decision-making, teammembers can identify and bridge these whitespace disconnects tomaintain alignment across the board.

MMaakkee KKnnoowwlleeddggee aanndd AAsssseettss RReeuussaabblleeThe final principle of BTM, to make knowledge and assetsreusable, encompasses two concepts that are well-known to bothbusiness and technology audiences. The first of these is knowledgemanagement, where companies capture, codify, and communicateknowledge to improve decision-making. The second is a repositorythat stores templates and previously designed models to encourageproject teams to reuse the unique knowledge captured in models.

Knowledge Management The first component of knowledge and asset reusability is knowl-edge management—an idea that first rose to prominence nearly adecade ago. Not surprisingly, knowledge management first caughton in businesses where knowledge is a key component of the valueproposition: “There’s too many terms that have been overusedrecently,” Scott Hayward, a Managing Director at JPMorganChase and Company explains, “but knowledge management hasalready become a reality in industries like financial services andconsulting, where knowledge is your main product.”

At the simplest level, knowledge management includes threesequential steps:

– Acquisition: Enterprise knowledge frequently exists inintangible forms such as individual expertise and shared culture. To disperse this knowledge throughout the corpora-tion it first must be captured in a concrete form such as adocument, knowledge bit, or contact information for a sub-ject-matter expert.


65


– Interpretation: Once knowledge has been captured it mustbe analyzed and codified so that individuals and intelligentsystems can use this context to push relevant knowledge toteam members.

– Delivery: The final step is delivering codified knowledge tothe point of decision. This delivery can be either passive(such as documents that reside in a searchable database orteam members who wait to be contacted about their specificexperiences and recommendations) or active (such as soft-ware designed to alert individuals regarding applicableknowledge bits).

This seems to be a simple process, but the hit-or-miss experi-ences with knowledge management during the last decade betraythe danger lurking behind the facade. To avoid the mistakes madein past projects, companies need to appreciate what it is thatmakes the outwardly simple theory of reusable knowledge any-thing but simple to implement in real life.

Two pervasive myths are largely responsible for companies’inability to harness the power of shared knowledge. The first isbased on the assumption that employees will automatically use anIT-based knowledge management system if it is in place. This mis-conception stems from the early view that knowledge manage-ment was considered purely an IT project. But companies foundthat building technology to support knowledge management isthe easy part—and overcoming cultural and political obstacles tosharing knowledge is much more difficult.

The second myth about knowledge management is that tech-nology will replace face-to-face knowledge transfer. Some earlyadopters assumed that in the new, virtual office, all interactionwould be mediated by IT. The truth is that people are far morelikely to share ideas when they’re face-to-face with their col-leagues, and IT-based knowledge management should be consid-ered a supplement to rather than a replacement for traditional,non-IT-based knowledge exchange.

Two Types of Reusable Knowledge: Documents and RelationshipsKnowledge management links people with two types of informa-tion: documents (which include pre-built process flows, existing

66CHAPTER 3


market research, network topologies, and other supporting infor-mation); and relationships, (which means referring to subject-matter experts—business unit managers, network architects, andIT team leaders for example—directly).

In keeping with knowledge management’s IT-focused history,most of the attention given to reusability centers upon collecting,indexing, and distributing electronic documents. For this to work,of course, knowledge must first be captured and saved in docu-ment form and then given context through associations with pre-defined subjects. When employees search for knowledge, theyeither perform a direct search (in which case context is providedby their search terms), or they browse the subjects until they findsomething that might apply, and then view the documents thatare associated with that subject. This type of knowledge manage-ment works best for information that is static, data-driven, andmeant to have a long shelf life: metrics, research reports, and basicdocumentation such as corporate policies, for example.

But sometimes sharing knowledge requires two employees tocollaborate directly to adapt their unique experiences to a newcontext. In these cases, document management systems—the tra-ditional cornerstones of knowledge management—don’t work sowell. Instead, companies need a mechanism for linking peopledirectly with other team members or experts. When employeeslook up information, they are directed not to a static document,but instead to the appropriate contact person.

Reusable Asset RepositoryThe second crucial component of knowledge and asset reusabil-ity is a repository that stores models developed during BTM.The concept of a reusable asset repository is closely related tothe knowledge management ideal of recycling enterprise knowl-edge. It differs from knowledge management, however, in thatthe knowledge being reused is captured in a structured modelrather than static documents or contact information for subject-matter experts.

Reusable asset repositories are familiar to component and objectdevelopers, who have long used repositories to encourage develop-ers to recycle existing code rather than writing from scratch.Component and object repositories act like a centralized ware-


67


house of pre-developed software that codifies the objects accordingto the functionality that they implement. Developers search therepository to find a piece of code that does what they need, andreuse it to decrease the development time for their project.

A useful analogy illustrating the advantages of a reusable repos-itory is to the manufacturing innovations realized during theindustrial revolution. By using standardized components as build-ing blocks for creating new products, innovative entrepreneurssuch as Eli Whitney incited a productivity revolution that led toassembly line manufacturing, the transition from inefficient arti-sans to moderately skilled line workers, and ultimately to the riseof mass production and inexpensive consumer goods.

Proponents of reusable repositories promise a similar leap for-ward for BTM: By using pre-built model templates from a reposi-tory, team members can concentrate on developing unique projectdetails rather than common, low-value designs. This providesimportant advantages for companies whose IT projects need to beagile to keep up with multiple acquisitions, fast product cycles, orhigh employee turnover.

Reuse in ContextAs with collaboration, it is necessary to establish context beforeyou can reuse knowledge and assets to give employees not just theright information, but also the right information at the right time.The very idea of reuse as a distinct practice betrays the funda-mental problem with most previous initiatives to reuse knowl-edge and assets. Like knowledge management, reuse isn’t justabout deploying business applications to save electronic knowl-edge for later use. Instead, it means enacting a cultural change sothat reusing decisions, policies, processes, technology, and stan-dards is indistinguishable from the normal, day-to-day tasks thatcreated this intellectual property in the first place.

One recurring pitfall of stand-alone systems for reuse is thetendency of employees to ignore them altogether. Integratingknowledge directly into the work environment solves this discon-nect and increases the likelihood that employees will embracereusability both as producers and consumers of knowledge. To dothis means facing two important challenges: establishing an infra-

68CHAPTER 3


structure for reuse that integrates directly with other enterpriseapplications, and defining a methodology for classifying documentsthat can be linked to enterprise applications to provide the contextfor determining which knowledge is relevant at any given time.

The Advantages of Reusing Knowledge and AssetsBy reusing knowledge and assets within the context of BTM,enterprises can:

– Give decision-makers the right information at the right time– Minimize rework and improve cycle times– Establish enterprise standards for processes, systems, and

infrastructure to promote best practices– Reuse existing enterprise applications, hardware, and net-

works

Give Decision-Makers the Right Information at the Right TimeKnowledge about business and IT initiatives is stored in the formof market research, documentation, vendor profiles, and consult-ing partner deliverables. By incorporating this information into aknowledge management system, teams can use context to pushrelevant information directly to the point of decision. This helpsteam members to access existing enterprise knowledge beforemaking key decisions, and ensures that documents remain up-to-date and relevant as the model is updated or changed altogether.

Minimize Rework and Improve Cycle TimesBy saving previously developed models in a reusable asset reposi-tory and then making these available as templates for later proj-ects, companies can reduce the amount of time and effort thatthey spend redoing crucial tasks. This lowers the cycle timerequired to plan and implement IT projects, and allows individu-als to concentrate on high-value decisions in their specific areas ofexpertise. Even after the dotcom meltdown, valuable IT workersare in short supply, and forcing skilled subject-matter experts tospend time on activities that don’t provide a direct benefit to theproject is an inefficient allocation of resources. By reusing models


69


from a centralized asset repository, IT workers can concentrateon specific, detailed customization that delivers real value andleverages their unique skill sets.

Establish Enterprise Standards and Best PracticesOftentimes, enterprise and IT standards are ignored by employeesbecause they are either unaware that the standards exist or theyremain unconvinced of the value that they provide. Knowledgeand asset reusability addresses this concern in two ways.

First, contextualized knowledge links standards and best prac-tices directly to the model itself. This can be in the form of sup-porting documents, research reports, or team member experiences.Also, it can link directly to subject-matter experts, such as enter-prise architects, who can pass along their accumulated knowledgeto those responsible for individual design decisions.

Second, new models based on templates that conform to stan-dards and best practices encourage teams to keep new modeling inline with the design parameters endorsed in the template. Toreplace an approved networking standard with a renegade design,for example, an IT architect would have to first deliberatelyremove the approved configuration. This is unlikely, especially ina culture where a standards-based approach is emphasized.Another way to enforce standards is to include models of tech-nology vendors and configurations in the repository. This makes iteasier for IT architects to stick with pre-approved configurationsthan it is to strike out on their own.

Reuse existing physical assetsBy recycling models from previous BTM projects, team membersare encouraged to reuse the design decisions captured in the modelitself. At the same time, however, it is important to note thatthese previously developed models are virtual representations ofthe actual business and IT environments. By recycling a portion ofa model, then, employees can often recycle its real-world equiva-lent—strategies, processes, software, and systems, for example.

Consider this scenario: A particular line of business develops amodel for a new CRM initiative, installs the software, and rollsout the project in their business unit. When IT workers from

70CHAPTER 3


another business unit go to reuse this CRM model, they not onlybenefit from improved decision-making, but by sticking with themodel’s design decisions, they may be able to reuse a portion of theactual CRM software itself.

By reusing actual enterprise assets rather than just the knowl-edge and expertise encapsulated in the model itself, companiescan reduce the cost of purchasing new hardware, software, andservices, and can unify enterprise architecture across multiple linesof business.

FFrroomm PPrriinncciipplleess ttoo SSppeecciiffiicc AAccttiivviittiieessThe three principles of BTM combine to form a solid foundationfor aligning business and technology. Without utilizing predictivemodeling, instilling collaborative decision-making, and makingknowledge and assets reusable, it’s impossible to do BTM. Thismeans that the principles of BTM merit a long and careful lookbefore you dive into your next IT project.


71

�

Who Should Lead the Drive toAdopt the Principles of BTM?

“Right now, many corporations don’t have a BTM herowho has been tasked with leading the drive towards mod-eling, collaboration, and reuse. And even where thosepeople exist today, they typically don’t have the budget tomarshal the resources to do it.

Like any important shift in IT planning, embracingpredictive modeling starts with the CIO. He or she mayassign somebody else to tackle it, but I think it’s got to bevery high level. I do think, however, that over the nexttwo or three years you’ll see process-focused technologypeople start to play this role by acting as purveyors ofmodeling concepts to both sides: to the business side to


Despite this enthusiastic endorsement, however, it’s importantto remember that the principles of BTM are only one piece of abigger puzzle. Early on in this chapter we defined the principles asprerequisites for performing the activities of BTM. This is a goodway to emphasize the importance of these principles and how they

72CHAPTER 3

help them understand what technology can do for them;to the IT group to actually get development done right.

It’s these same business process/technology leaders whowill be the lynchpins for driving collaboration, and put-ting the right tools and processes in place to make it hap-pen. And I’d also argue, by the way, that it’s these samepeople that have to start looking at reuse and knowledgemanagement because they’re the ones who see things on across-functional basis, whether it’s cross-departmental, orsometimes even across business partners. I think you reallymust have a group that is looking after the whole develop-ment area on reuse, because reuse starts at the processlevel: if you can’t establish shared processes it’s going to be difficult to establish component reuse at a technologylevel.

People are already arguing ‘yes’ about alignment, but Ithink we’re at the cusp of where we’re going to see thisdiscipline become a critical path, enabling better controlof IT spending, better management of projects, betterprioritization, and viewing the whole thing as a portfolio.I think that you’re going to see a much more coordinatedeffort. In the past, business/technology alignment hasbeen done more on an ad hoc basis. But today, you need amore architected approach: It needs to be more disci-plined, and you need to be able to put different areas towork in pursuit of alignment, including modeling, collab-oration, and reuse.”

– Dale Kutnick, founder, chairman, and CEO, META Group


fit with the other pieces of business technology management: It’simpossible to do successful BTM without utilizing predictive mod-eling, instilling collaborative decision-making, and making knowl-edge and assets reusable. But it’s also possible to do thesethings—to do them well, in fact—and still not make good on thepromise of BTM.


73


TThhee AAccttiivviittiieess ooff BBTTMM

IIIIIIPPAARRTT

“The great end of life is not knowledge but action.”– Thomas Henry Huxley

SEVERAL MONTHS AFTER FIRST HAVING MET with Janetand Robert to discuss your dream house, you’re almost ready tobegin construction. But before the first batch of concrete canbe poured and the first board nailed into place, you need amechanism to make sure that the design they’ve come up withmeets your exacting demands. To earn your confidence (and toavoid any late-stage misunderstandings that might result intearing down a part of the structure to make a change), Janetand Robert have put together an exhaustive architectural blue-print of your dream house.

PartIII_FINAL.qxd 7/25/2002 3:32 PM Page 75

Recently, this blueprint has ballooned from a couple of pre-liminary drawings that concentrated on the overall look and feelof the house to a heavy stack of detailed diagrams. Most of therecent drawings focus on details that are beyond your limited graspof architecture. But you’re excited for the house to be done, and soyou decide to spend a slow afternoon flipping through theunwieldy drawings and trying to imagine how the sectionexpressed in each might look in the final structure. After just a fewminutes, you notice that each of these working diagrams seemsnot only to focus on a distinct physical area of the house, but alsospecific subject matter: pipes in some, wires in others, and beamsand supports in still others.

In the preceding weeks, Robert, the contractor, hired a team ofspecialized tradesmen—plumbers, electricians, engineers, and soon—who will handle the day-to-day construction duties. Each ofthese focused roles needs a set of working drawings that explainsthe project from their individual point of view. Tony, the plumber,constructs a riser diagram to show how water will get from yourwell to each of the bathrooms and sinks, for example, while theelectrician, Willy, needs to plan circuits, outlets, and switches.The structural engineer, Emily, needs to design beams, trusses,and support.

Obviously, each of the detailed working drawings that you’vecome across has been constructed with a particular one of thesespecialists in mind; they represent distinct views, will be com-pleted at different stages, and, generally speaking, don’t eveninclude the same building blocks. But at the same time, it’s obvi-ous that each working drawing needs to fit seamlessly into anintegrated whole. They all refer to the same house, after all, and ifWilly were to try and install an electrical socket in the same loca-tion Tony had planned to put a shower and Emily had sited a sup-port beam, it would be a disaster.

The challenge for Robert (the contractor) is to make sure thatthe design decisions made from each of these three distinct pointsof view are compatible. Just like it’s up to Robert (the CIO) tomake sure that decisions from three analogous perspectives—busi-ness, process, and technology—all work together in the design ofa single IT project.

76PART III


Just like for your dream house, Robert (the CIO) puts togethera team of subject-matter experts that is responsible for detaileddesign decisions: Tony, a representative from the business unit,focuses on the business decisions for the project, such as customersegments, partners, and strategies; Willy, a process expert, designsprocesses to support these business objectives during processautomation; and Emily, a systems integrator, outlines the applica-tions and systems that will support these processes. All of thishappens during business model definition, process optimization,and technology automation—the three activities of BTM.

IInn TThhiiss PPaarrtt……It’s essential both to recognize that business and IT should bealigned and also to identify the underlying principles that help toaccomplish that goal. But without concrete activities that youcan perform to determine where you are today, to decide whereyou need to go, and to define how you should go about gettingthere, there’s no guarantee that alignment will finally become areality. Part III: The Activities of BTM begins by introducing enter-prise architecture, which functions as a blueprint for IT projects.Enterprise architecture should be designed using a combination ofmodeling and impact analysis during the design stage of IT proj-ects. (Just like you shouldn’t start drawing up architectural blue-prints after you’ve already dug the foundation, you shouldn’t waitto design enterprise architecture until after you’re writing code.)Next, it describes the three activities of BTM—Business ModelDefinition, Process Optimization, and Technology Automation—anduse a simulated case study to show how they might be put to workin a familiar business environment.

The Activities of BTM

77


TThhee EEnndd-ttoo-EEnnddPPeerrssppeeccttiivvee

44

THE THREE PRINCIPLES OF BTM—utilize predictive modeling,instill collaborative decision-making, and make knowledge andassets reusable—provide an essential foundation for aligning busi-ness and technology. Nevertheless, they’re more like tools than afinished product: you need them to get the job done, but, in theend, how they’re put to work is just as important as what they are. Ifyou’re trying to build a birdhouse, for example, you’ll need a ham-mer and nails. But the same hammer and nails can also be used tobuild a doghouse, a toolshed, or, for that matter, a dilapidated shack.

This same tenet holds true for modeling, collaboration, andreuse. Modeling often shows up in the form of data or object mod-eling, collaboration in groupware and virtual conferencing, andreuse in document management and repositories of code—allgood and useful in their own right, but not necessarily the best

Chap4_FINAL.qxd 7/25/2002 5:58 PM Page 79

approaches for meeting the specific challenges posed by the busi-ness/technology disconnect. To deliver on its promise, then, BTMneeds to include not just generic principles, but also a blueprint forhow to put those principles to work to solve disconnects. This iswhere the activities of BTM come into play. During businessmodel definition, process optimization, and technology automa-tion, companies leverage modeling, collaboration, and reuse todevelop an enterprise architecture that keeps IT projects firmlyaligned (see Fig. 4.1).

Business model definition, process optimization, and technol-ogy automation are by nature specific activities that need to beundertaken by someone somewhere in order to have an effect

80CHAPTER 4

Enterprise Architecture

Utilize Predictive Modeling

Instill Collaborative Decision-Making

Reuse Knowledge and Assets




Figure 4.1The principles of BTM combine with the activities of BTM to helpcompanies model enterprise architecture


upon the enterprise. If you’re thinking about practicing BTM,then, a logical question to ask is where and when should all thishappen? To answer this question, let’s turn back to the real-worlddisconnects highlighted in Ch. 1. Each of these examples points tospecific IT projects that somehow spun off course. This doesn’tmean that BTM should be confined to the PMO, however; thereare any number of methodologies and guidelines available to helpcompanies manage IT projects that don’t focus primarily uponalignment. But projects are the primary mechanism for designingand ultimately changing how IT functions (by installing a net-work, modifying a business process, or installing a new application,for example), so if we’re looking to make changes to close discon-nects that have cropped up over time, the IT project is nonethe-less the right place to start.

TThhee ““AAiimm”” iinn ““RReeaaddyy,, AAiimm,, FFiirree””Most project management disciplines divide IT projects into fivemajor stages:

– Conceive, where an initial proposal and cursory descriptionof the project are put forward

– Design, where a detailed plan is developed that lays outwhat needs to be done, when, and by whom

– Build, where new assets such as processes and systems areassembled

– Test, where the new assets undergo rigorous testing to ensurethat they perform as planned

– Deploy, where the new assets and behavioral changes areimplemented in the live business environment

Chapter Three, indicated that predictive modeling would helpcompanies go from a “ready, fire” approach to using IT in the busi-ness to a “ready, aim, fire” method that “aims” to make sure teammembers make decisions that keep business, process, and technol-ogy aligned. By mapping this crude analogy back to the five stagesof IT projects, as in Fig. 4.2, we see some obvious similarities.

The End-to-End Perspective

81


Most importantly, note the connection between aim anddesign. For BTM to really help companies aim to make betterdecisions, two assumptions should be true: first, the business/tech-nology disconnect should result primarily from mistakes and over-sights during the design stage of IT projects, and second, BTMneeds to provide a mechanism to improve this crucial design.

Studies show that the first of these assumptions does indeedhold. In projects of all kinds a huge percentage of the cost is fixedin the design phase, no matter how scrupulously the project teamadheres to best practices and careful management during thebuild, test, and deploy stages (which is where most project man-agement efforts aim to wring value from the initiative). For exam-ple, research indicates that although “80% of the money and timeinvested in supply-chain management information systems isdevoted to addressing execution processes…70% of a product’sreal cost is determined and decided in the early phases of productinnovation and design.”1

The second of these assumptions, that by improving the designof IT projects BTM successfully aligns business and technology, isthe focus of this chapter. Each of Ch. 1’s real-world disconnects—from Patrick Flynn’s customs-clearance system to Carl Wilson’sHR initiative to Scott Hayward’s call-reporting system—demon-strates that disconnects between three crucial areas—business,process, and technology—are the catalysts for financial, behav-ioral, and functional disasters. By using modeling to improve thedesign of these areas before moving on to the costly build, test,and deploy stages, companies can address disconnects before theycrop up. And, in fact, the activities of BTM—business model

82CHAPTER 4

Ready Aim Fire

Design Build Test DeployConceive

Figure 4.2By helping to improve the design stage of IT projects, BTM providesthe “aim” in “ready, aim, fire”


definition, process optimization, and technology automation—help companies to design enterprise architecture, a concrete blue-print that includes these three crucial areas, improvesdecision-making in their IT projects, and helps bring alignment toIT projects and the enterprise as a whole.

EEnntteerrpprriissee AArrcchhiitteeccttuurree:: AA BBlluueepprriinntt ffoorr AAlliiggnnmmeenntt

Enterprise architecture, of course, isn’t a new idea that’s unique toBTM; many companies already use it today to improve standard-ization, speed up development, lower the cost of implementingsystems, improve quality, and generally govern IT in the enter-prise. But BTM is somewhat unique in that it positions enterprisearchitecture as a blueprint for aligning business and technology.

In general, enterprise architecture is a holistic, end-to-enddesign that encompasses business architecture (which includesboth a big-picture design of the business and the processes thatsupport this design) and technology architecture (which includesthe applications that automate business processes, and theunderlying systems that support these applications). It’s impor-tant to note that this definition draws a distinction betweenhow BTM views enterprise architecture and other interpreta-tions of the term:

– Enterprise Architecture Isn’t Just Technology: Some peo-ple assume that enterprise architecture describes only ITassets. By ignoring business architecture altogether, this mis-conception encourages companies to develop a road mapthat innovates IT—but with no direct connection to busi-ness and process.

– Business Architecture Isn’t Just Processes: Others makethe mistake of interpreting business architecture to meanjust the business processes that the company performs. Thisignores the big-picture view of the business, and makes it dif-ficult for decision-makers to determine not just whatprocesses exist, but also why these processes are executedthe way that they are.


83


BTM requires a definition for enterprise architecture that is morecomplete than either of these two misconceptions. To solve thebusiness/technology disconnect, companies need to consider a com-plete, end-to-end road map that helps them make better decisionsabout where and how to put IT to work. This road map, pictured inFig. 4.3, includes both business and technology architectures, anddiagrams specifically how each architecture type fits together.

Like an architectural blueprint, enterprise architecture servesas a reference point during later implementation phases, whenteam members refer back to it to verify important decisions,update the design, and generally determine what they need to doto accomplish the project. But, also like an architectural blue-print, the primary value that enterprise architecture adds isn’t justas a reference point for project management; it also helps to pro-totype solutions during the design stage by identifying how theenterprise is designed today, where the opportunities are for theproject to innovate that design, how things will have to change totake advantage of that innovation, and what the final design ofthe enterprise will look like once the project is implemented.

84CHAPTER 4

Enterprise Architecture

Business Architecture

Technology Architecture

Figure 4.3Enterprise architecture includes both business and technologyarchitectures


This helps the project team to evaluate options, make trade-offs, and balance competing agendas. Consider Honorio Padron’sexample in Ch. 1, where a misunderstanding about the impor-tance of customizing a new financial system almost led to a barrageof unnecessary costs. In this particular case, developing a blueprintof enterprise architecture in the design stage would have revealedthe differences between the company’s current processes and thosesupported out of the box, helped to calculate the cost of modifying


85

�

Enterprise Architecture andService Providers

“One of the things that we have suffered from for a num-ber years—and I am sure that this is characteristic of largecorporate IT organizations—is that although we have uti-lized many of the leading consultancies and system inte-grators, we have actually gained very little in terms ofarchitectural intellectual capital for many projects.

The intellectual capital that these engagements gener-ate is captured in simple documentation form: it may bewritten documents, it may be diagrammatic, but it is cer-tainly not aligned and not interlinked. So you might haveVisio, PowerPoint, or Excel documents that make up themain artifacts for the project. Each document is discon-nected, and varies in the structure and detail in which itis defined. So if you’ve done one project with Accentureand another with PWC Consulting, actually putting thosetwo pieces of an overall enterprise architecture together isa whole new piece of work, basically.

By promoting interlinked models to design enterprisearchitecture, BTM gives organizations like ours the mech-anism we need to work with consulting organizations andactually take the intellectual capital they produce andintegrate it into our overall enterprise architecture.”

– Kevin Poulter, head of business integration, BritishAmerican Tobacco; co-founder, Ontology.org


the software, catalogued the strategic objectives for the project,and provided a platform to mediate between the importance ofmaking changes and keeping costs down.

MMooddeellss HHeellpp PPrreeddiicctt EEnntteerrpprriisseeAArrcchhiitteeccttuurree

Because enterprise architecture needs to be able to design changesbefore they are actually put into place during the build, test, anddeploy stages of a project, it is a prime candidate for predictivemodeling. Not surprisingly, then, each of the activities of BTMmakes good use of this trait by utilizing business, process, andtechnology models as important tools for developing enterprisearchitecture. Together, these three types of models make up acomplete enterprise model, which mimics the behavior of end-to-end enterprise architecture.

Like other models in general, enterprise models are composedof four primary building blocks: elements (things), attributes(descriptions of things), relationships (links to other things in themodel), and cross-links (links to other things in separate models).Elements within the model can be organized (into parent-childhierarchies, for example), tied together to imply causal relation-ships, and cross-linked with external elements from other modelsin order to create concrete connections. This final point is anextremely important one for the purposes of BTM. Any techniquethat promises to close disconnects between business, process, andtechnology must clearly rely upon a mechanism to enforce align-ment. By cross-linking individual elements in discrete modelstogether, BTM accomplishes this feat, and ensures that the rippleeffects of any specific decision are anticipated throughout eachmodeling environment.

Consider an example: An IT analyst creates an element in atechnology model that represents a new software package he orshe is installing. Beneath this package, the analyst creates childelements that describe the functional requirements for the pack-

86CHAPTER 4


age. Each of these functional requirements is then linked back tothe individual processes in the process model that it supports. If achange needs to be made to the package down the road, whoeveris considering the modifications can trace links back to theprocesses that would be impacted, and anticipate the full ramifi-cations of the decision before making the final call.

This ability to change models and to dynamically view rippleeffects both within an individual model and between multiplebusiness, process, and technology models is the primary reasonwhy conventional drawings aren’t sufficient for designing enter-prise architecture. In order to simulate the full impact of any indi-vidual decision, the design needs to respond dynamically whenmodels are modified. If designing enterprise architecture was anafterthought to IT projects, static drawings would be fine. Butbecause enterprise architecture needs to be developed during thedesign stage, only predictive models—business, process, and tech-nology models—can get the job done.

The process of designing enterprise architecture and carryingout the activities of BTM begins when the project team identifiesan as-is current enterprise model (which includes business, process,and technology) that describes the end-to-end architecture as itexists today. Then, the team leverages the capabilities of predic-tive modeling to develop multiple to-be enterprise scenario models(also called patterns), each of which previews potential changes tothe architecture. By comparing the current enterprise model andthe enterprise scenario models, team members can discover prac-tical opportunities for IT to benefit the company, and ultimatelyuse impact analysis to make better decisions about which oppor-tunities to pursue. Once these opportunities have been identified,the final enterprise scenario model becomes the basis for an IT proj-ect that implements these changes. After the IT project has beenrolled out, the final enterprise scenario model is folded into thecurrent enterprise model to make sure that the changes becomepart of a new, updated enterprise model (see Fig. 4.4).

Notice that before you can follow this sequence of events, youfirst need to have an accurate, current enterprise model. There aretwo ways to go about developing this model. The first is to chartera team headed by senior executives to review the current enter-


87


prise model (or create it from scratch if necessary) after regular,but reasonably long intervals (one to three years is typical). Thesereviews should be timed to coincide with reviews of corporatestrategy, so that changes in strategy ripple down immediately intothe model. The second method for developing the current enter-prise model is by accumulation. As projects finish, final scenariomodels are folded into the updated enterprise model, or becomethe updated enterprise model altogether if one doesn’t yet exist.Over time, and as projects touch upon different areas of the busi-

88CHAPTER 4

Impact Analysis

Implementation

EnterpriseScenario Model - 1



CurrentEnterprise Model

Final Enterprise Scenario Model

UpdatedEnterprise Model

Figure 4.4During the activities of BTM, companies perform impact analysisto evaluate multiple scenarios and select the appropriate optionfor implementation


ness, the effect will be to flesh out a complete current enterprisemodel piece by piece.

One final note about the current enterprise model is that itprovides a powerful vehicle for capturing and enforcing enterprisestandards. Since each enterprise scenario model is patterned afterthe current enterprise model, design standards such as standardprocess flows, approved application packages, and technical stan-dards are automatically passed along to each enterprise scenariomodel, and in turn to the implementation projects that makethem a reality. This helps enterprise architects to maintain tacti-cal control over how projects are implemented, a subject that Ch.8 discusses in more detail.

IInnttrroodduucciinngg TThhee AAccttiivviittiieess ooff BBTTMM Developing and maintaining these models—the current enter-prise model, the enterprise scenario models, the final enterprisescenario model, and the updated enterprise model—is the pri-mary purpose of the activities of BTM, which are introduced here,but described in more detail in Ch. 5, 6, and 7:

– Business Model Definition helps companies capture andcommunicate business objectives

– Process Optimization helps define and streamline processesto support the business model

– Technology Automation helps to select applications andsupporting systems to automate selected processes

Business Model DefinitionDuring the first activity of BTM, business model definition, proj-ect teams analyze their current business and develop multiple sce-narios that describe how technology might be used to improve it.First, they examine the current business model, a big picture thatcaptures a snapshot of the business and communicates strategy,objectives, opportunities, and constraints. Next, they solicit inputfrom relevant subject-matter experts to create a number of alter-


89


native business scenario models to accomplish their project’sobjectives. These scenarios, which form the basis for impact analy-sis, help to illustrate which aspects of the current business modelmight be impacted during the course of the project. (Typically, thisis a small number, since most projects result in incrementalchanges to the business rather then a wholesale reinvention ofhow the company works.) Each of the business scenario modelsbecomes the starting point for a complete enterprise scenariomodel (including process and technology scenario models devel-oped during process optimization and technology automation)that describes the end-to-end enterprise architecture for the proj-ect. After one of the business scenario models has been imple-mented, it gets folded into an updated business model, whichbecomes the basis for future episodes of business model definition.

Process OptimizationProcess optimization, the second activity of BTM, helps projectteams define business processes to support the objectives outlinedin each of the business scenario models, associate resources andrequirements with individual activities, identify process inefficien-cies and redundancies, and enforce standard processes across mul-tiple business units. First, the project team decomposes their currentactivities into an as-is process model that describes how the enter-prise behaves today. Next, they create process scenario models tosupport each scenario begun during business model definition.Since process optimization provides the link between business andtechnology, each scenario must take into account both processesthat are already automated by existing resources, and processes thatare good opportunities for future optimization projects. The teamthen performs a gap analysis between the current process model andeach scenario to help generate specific requirements that drivetechnology automation later on. Once a final process scenariomodel has been selected for the current project, the team folds itback into an updated process model to make sure that it remains anup-to-date snapshot of how the company does business.

90CHAPTER 4


Technology AutomationDuring the final activity of BTM, technology automation, projectteams identify applications and systems to support the activitiesselected for automation in each process scenario model; selectvendors and implementation partners; establish technology stan-dards, and determine how to integrate the new systems with thecompany’s existing technology architecture. First, the team exam-ines the current technology model, which includes two types ofinformation: software applications that automate businessprocesses; and supporting systems—including hardware, software,networks, and data—that support applications. Next, the teamidentifies technology scenario models to support each of the sce-narios developed during process optimization. They perform a gapanalysis for each of these scenarios to determine what applicationsand systems need to be purchased, developed, or modified. Finally,after the project has settled on and implemented a final technologyscenario, it is folded back into an updated technology model.

A System Not a SequenceSo far, we’ve scrupulously presented the activities of BTM as aseries of sequential steps that companies can follow to achievealignment in their IT projects. There is some merit to this view,since it makes sense to allow sound business objectives to lead theway and be followed by process innovation, and then finally, bytechnology automation. But, as is often the case, the real businessenvironment isn’t always so simple. There are times when thestraightforward business-to-process-to-technology sequence breaksdown, and changes made in any of these three areas can take thelead. Padron’s example from Ch. 1 demonstrates the expediency ofsticking to an out-of-the box software application rather thanapproving extensive modifications. Instead of following the spe-cialized processes employees were used to, Padron allowed tech-nology to lead, and made sure that process and business synced upto maintain alignment. In this sense, the activities of BTM aremore of an interconnected system than a sequence: it isn’t aboutdoing A, then B, and then C, it’s about making sure that all threework together, in concert, to guarantee that IT contributes to bot-tom-line business objectives.


91


TThhee AAccttiivviittiieess ooff BBTTMM aanndd EEnntteerrpprriissee AArrcchhiitteeccttuurree MMaakkee aa BBeetttteerr BBuussiinneessss CCaassee

By putting predictive modeling to work to create enterprise archi-tecture during the design stage of IT projects, companies canfinally put the business/technology disconnect to rest. But, beyondavoiding the types of disaster stories that presented in Ch. 1 (aworthwhile goal on its own, of course), what does this really meanin terms of how companies plan and execute their IT projects?

Recall from earlier on in this chapter that the five stages ofproject management—conceive, design, build, test, and deploy—roughly correspond with our “ready, aim, fire” analogy, whichexplains how BTM helps companies “aim” to improve their align-ment. This analogy is also useful for representing another keyadvantage of the activities of BTM. Most IT projects have to passthrough a number of approval processes as they move from con-cept to deployment. One of these approval processes happens afterthe design, or “aim,” stage, when the team develops a businesscase that tries to justify the money, time, and resources that will berequired to make the project a reality. The format for each busi-ness case necessarily varies according to the company and specificproject, but in general, they include things like the projected busi-ness benefit, costs, timeframe, required assets, and so on.

Historically, companies have struggled to develop businesscases that end up matching up with what really happens duringimplementation; cost estimates blow up, timeframes go out thewindow, and, with alarming frequency, the CIO gets booted outthe front door. There are many reasons for this trouble, but themost important is that the conclusions about cost, risk, and othervariables that show up in the business case aren’t based on anyreal, significant analysis of underlying design: companies developbusiness cases in a vacuum, throw them over the fence to IT, andthen hope that whatever final solution IT throws back hits closeto the mark.

But BTM forces the team to think through an end-to-enddesign of how the project will impact the business. The educated

92CHAPTER 4


guesses and approximations of past business cases are firmed upinto validated conclusions, and the CIO is empowered to makesmart decisions that are traceable back to a concrete source: theenterprise architecture developed during the activities of BTM.


93


BBuussiinneessss MMooddeell DDeeffiinniittiioonn

55

BUSINESS MODEL DEFINITION, the first activity of BTM, helpsto develop multiple business scenarios that describe how the proj-ect team might choose to put technology to work. Before describ-ing this crucial activity, however, it’s important both to explainwhat I mean by a business model and to show some of the infor-mation that’s typically included in one. Then, the chapter divesinto more detail about what happens during business model defi-nition, and why some current trends are making it more importantthan ever before. Next, it presents some vignettes from a simu-lated case study to illustrate how business model definition hap-pens in a real enterprise environment. Finally, it touches uponwho should be responsible for this important first activity of BTM.


WWhhaatt iiss aa BBuussiinneessss MMooddeell??Before you can appreciate why business model definition is a cru-cial activity for BTM, it helps to have a solid understanding ofwhat I mean by a business model. This is especially true since theterm is frequently used to describe things that are dramatically dif-ferent than what I mean in this specific context.

Misconceptions About Business ModelsOver time, a business model has come to mean very differentthings depending on whom you ask. So while you’re likely to hearacademics, professionals, and journalists use the term both fre-quently and familiarly, you can’t always be sure that one person’s“business model” isn’t another’s “value proposition,” “businesscase,” “revenue model,” “strategy,” and so on. Before explainingwhat the term means, let me mention two uses that are not relatedto BTM:

– The Cocktail Napkin One-Liner: The first way that “busi-ness model” is used mistakenly is when people—journalists,for example—associate it with a convenient one-liner aboutwhat a company does. The proverbial business idea scribbledon a cocktail napkin, for example, falls squarely into thiscamp. Although this gross simplification is too shallow toform an effective basis for business/technology alignment, itdoes, perhaps inadvertently, echo one of the crucial attrib-utes of a business model in BTM: it represents a big pictureof the business.

– The Financial Model in Disguise: Ironically, the secondway that people misapply the term is almost exactly theopposite of the cocktail napkin mistake: rather than grosslyoversimplifying the term, they dive in at a level of com-plexity that precludes a big-picture view. This happenswhen a business model is equated with a financial model.Before you can build even the most basic financial model,you have to first make some important assumptions (whichindustry to compete in, who the customers are, etc.) thatpreclude the unbiased, big picture that is integral to thebusiness model in BTM.

96CHAPTER 5


In the context of BTM, the term business model means some-thing different from both the cocktail napkin one-liner and thefinancial model in disguise. In our discussion, a business modelrepresents a big picture that captures a snapshot of the enterpriseand communicates direction and goals to other stakeholders.


97

�

Seeing How the Pieces Fit

“I’m not sure that many executives truly understand whatwe mean when we say ‘business model.’ It means more thanjust the way you operate. Having a strong business modelmeans that you have thought through the way you servicethe customer, the way you make money, the way you go tomarket—all these elements and how they fit together.

For many companies, the planning process is still veryfinancially driven instead of being focused on the businessmodel; they tend to take a look at financial performance,projections, and plans, and then try to engineer futurefinancial plans, all within the construct of their currentbusiness model. Not many established companies willassess their entire business models in a proactive way—dotcoms will do it because the market has crushed theirold business models, but Global 2000 companies tend tostart by examining their financial models and not rethink-ing their business models.

Often in existing companies that have been establishedfor some time, the managers today are typically not theoriginal architects of the current business model. Thus,they may not really understand their own business model orhave ever thought about why it’s constructed the way it is.

When we in corporate America go through our plan-ning processes, do we really sit back and think throughthe kind of business we are, how it’s put together, andthen how to improve it going forward? Too many of usmove right into the financial part of the planning processand let that drive everything, as opposed to really rethink-ing the business model. Without that thorough assessment


What a Business Model Should BeThe best way to visualize how business models add value to BTMis to show—rather than tell—the type of information that anexample business model might include. Figure 5.1 presents anexample business model that classifies elements into four broadareas:

– The overall identity of the firm: The firm’s identity mightinclude elements such as brands, the corporate mission, thereputation of the firm in the marketplace, the target market,and general differentiators for the firm. It might also includeelements that describe the company’s unique culture such asvalues, office rules, and behavioral expectations.

– The strategy for the firm: Elements in this category coulddescribe how the firm translates its mission and values intoconcrete action. An important component of this role mightbe the ability to coordinate between multiple businessunits—each of which presumably needs to play a unique roleto help meet common, strategic goals. Strategy mightinclude elements such as goals, a timeframe for achievingthose goals, the resources that are required, and custom per-formance indicators.

98CHAPTER 5

and by focusing just on financial plans, you tend to findonly incremental improvement as opposed to break-through insights about the business model. Not everycompany needs to dramatically change its business modelfrequently—that’s unnecessary. But you should examineyour company’s business model regularly and determineyour true strengths and weaknesses. Having a well-designed planning process forces your current businessleaders and the new generation of leaders coming up toreally grapple with these issues and think about how toimprove the business every year.”

– Randolph C. Blazer, chairman & CEO, KMPGConsulting, Inc.


– The internal assets that help the firm to achieve itsstrategic goals: Internal assets could include all of theresources that the example firm might muster to pursue itsstrategy. This might include things like products and serv-ices; organizational assets, including the reporting struc-ture, geographic distribution, roles/responsibilities, andindividual resources; financial resources; intellectual prop-erty; distribution channels; and physical assets such as realestate and machinery.

– The external business environment in which the firm com-petes: Finally, the example business model might alsoinclude a category of elements that describes the firm’s exter-nal business environment, including customers, suppliers,partners, and competitors. In addition, the external environ-ment could include demographics for the market and indus-try; potential entrants; information about compliance; andgeneral trends that influence the company’s position in theirmarket.

Each of these elements maintains textual and numeric attrib-utes (such as metrics, priority, and feasibility) that help give themodel the depth of description and interaction that distinguishes itfrom a simple diagram or drawing. For example, the elementlabeled “High Value” in Fig. 5.1 could include attributes such as atextual description of who is considered a high-value customer;numerical values that describe the estimated number of customersthat fall into this category; and the revenue a customer needs togenerate for the company to qualify as a high-value customer. Thisinformation provides an important basis for analyzing the model(while managing the portfolio of IT investments that Ch. 8 dis-cusses, for example) and for developing business scenario models.(Different scenarios, for example, could vary according to the rev-enue required to qualify as a high-value customer.)

Figure 5.1 provides some idea about the type of informationthat’s captured in a business model. But remember, explainingbusiness models by example poses somewhat of a problem.Although it explicitly differentiates a business model from mis-conceptions like the cocktail napkin one-liner or the financialmodel in disguise, BTM doesn’t limit companies to one empiri-


99


cally correct set of elements to make up the model. So while thecategories and elements expressed in Fig. 5.1 provide a pretty goodexample, they shouldn’t be considered a cookie-cutter mold afterwhich every business model should be patterned; each company’sunique culture will inevitably produce a unique approach to busi-ness modeling, none of which are necessarily “better”—or “worse”for that matter—than any other.

What Varies Within Business ModelsDifferent approaches to business model definition produce specificelements and attributes that are unique to particular companies,business units, or even individual projects. In addition to these dif-ferences in content, there are two primary ways in which businessmodels that are developed for BTM differ:

– The methodology that is used to define the model– The scale at which the model is developed

100CHAPTER 5

Example Business Model

OverallIdentity +

InternalAssets +

+Strategy

–

Suppliers

Partners

Competitors

External Business Environment

High Value Low Value

Customers –

+

+

+

Figure 5.1An example business model that includes four general categories ofelements—overall identify, strategy, external business environment,and internal assets


MethodologyThe first area where business models frequently vary is in themethodology that companies follow to define them. To be effec-tive, the business model must reflect the perspectives, personali-ties, and priorities that make each company and project unique.This is why there’s no one “right” set of elements that defines abusiness model; anyone who implies that there is underestimateshow different companies—and even business units within com-panies—really are.

In keeping with this spirit of flexibility, this book’s discussion ofbusiness model definition—and process optimization and technol-ogy automation for that matter—doesn’t introduce an exactmethodology; what works well for Company A’s IT project won’talways work for Companies B and C. In fact, the unique way thata company goes about defining its business model can be an impor-tant source of competitive advantage. But whichever methodologyis used should be accessible and familiar to the widest possibleaudience, so that even non-experts can pick up the business model,understand it, and eventually contribute to it themselves.

ScaleThe second area where business models vary is in scale. The scalefor a mom-and-pop convenience store is obvious: one store, onebusiness model. But in more complex business environments, thescale at which the business should be viewed isn’t always clear-cut.If, for example, you’re an IT professional at a huge multinationalcorporation, is it feasible for you to develop a business model thatdescribes the entire company? Should each line of business haveits own model? Or should each business model describe smallerentities like divisions or groups?

The answer to each of these questions is “Yes.” Business modelscan be developed to whatever scale the modelers need to analyzeat any given time, from a complete picture of a Fortune 500 con-glomerate all the way down to a group of regional salespeople. Thepurpose that the business model serves, of course, varies accordingto the model’s scale. For example, an enterprise-wide businessmodel can help to break down organizational silos and unify plan-ning across the whole enterprise. A business model scaled to a par-


101


ticular group of employees, on the other hand, can help decision-makers to think through details about how that group functions inorder to design IT systems that meet their specific needs.

The way that business models vary according to scale is roughlyanalogous to strategy—which similarly can be decomposed at anylevel of the enterprise. The strategy for an individual businessunit, for example, might include determining which new productsto introduce, how to market them, and so on, while strategy at thecorporate level would concentrate on general product lines, mar-kets, and the long-term future direction of the enterprise.

DDeeffiinniinngg tthhee BBuussiinneessss MMooddeell IInn BBTTMMHaving established what business model means in BTM, it makessense to move on to discuss how companies put business modeldefinition to work helping them develop better business cases fortheir IT projects. Skipping this crucial activity can lead to dam-aging oversights. First, developing a business case without firstmodeling the business makes it difficult to develop and comparealternative business scenarios—a step that is essential for per-forming impact analysis. Second, business model definitionrequires planners to think through a complete, big-picture view ofthe business. Since a picture is worth a thousand words, this viewmakes it easier for team members to visualize solutions, avoid amyopic focus, and contribute their expertise to the business case.And finally, since most business cases are simply paper documents,they can’t be counted on the same way that a business model canto provide the concrete links to process and technology that formthe basis for alignment. This last point is especially importantbecause of the unpredictable nature of IT projects. Even the mostthought-out initiative invariably faces unforeseen hurdles as itprogresses from design to implementation. By giving the IT spe-cialists, who are charged with finding these impromptu solutions,a mechanism for tracing back to the original business model, BTMhelps to ensure that even the worst snags are ironed out for thegood of the project as a whole.

102CHAPTER 5


Business model definition alleviates these concerns by provid-ing a mechanism to perform as-is/to-be gap analysis for the parts ofthe business that could be affected by the project. The first ofBTM’s activities involves four general steps: drawing the big pic-ture, understanding the as-is current business model, creating aportfolio of business scenario models that represent possible to-bestates for impact analysis, and incorporating changes made by theproject into an updated current business model.

Drawing the Big PictureSince business models represent big-picture snapshots of thebusiness (or business unit, division, or group), realistically theyaren’t likely to change all that often; established companies don’tcompletely reinvent their business models except in the mostextreme cases. Most IT projects, then, find that they’re able toleverage an existing current business model rather than developone from scratch.

There are cases, however, when project teams need to developa business model before beginning the activities of BTM—after amajor change to the business environment such as a merger oracquisition, for example. When this happens, it is essential toinclude input from as many subject-matter experts as possible.These contributors should work in the model directly to makesure that details aren’t lost in the translation, and to increase theirown understanding of the business by analyzing other parts of themodel. When it isn’t feasible to ask subject-matter experts todevelop the model directly, the team can gather input for thebusiness model either through surveys and data collection, or bytalking to experts face-to-face during a meeting or seminar. Nomatter how the current business model is developed the first timearound, it’s important to consider the infamous “80/20 rule”: 80%of the benefit comes from 20% of the effort. There’s no point inagonizing over every detail in the current business model since itsprimary purpose is to provide a general starting point for spawningmore specific business scenario models.

This highlights an important point about business model defi-nition: The direct benefits that companies derive from modelingthe business come from two sources. First, and most obviously,


103


there are the specific elements and attributes that make up each ofthe models—the end products of business model definition.Second, and of equal importance, is the actual process of research-ing and defining the model—whether constructing a current busi-ness model from scratch or developing scenarios for impactanalysis. The deliberate act of creating the model compels deci-sion makers to think through the complete business landscape,and ultimately uncover hidden opportunities for improvement.

Understanding the Current Business ModelThe process of creating or updating the current business model isan important one that companies will undoubtedly face fromtime to time. But it’s important to distinguish this endeavor frombusiness model definition as it’s typically practiced in most proj-ects. Recall that the purpose of the activities of BTM, (of whichbusiness model definition is the first) is to create a series of mod-els that express as-is and to-be versions of the enterprise archi-tecture. Since the as-is enterprise architecture rarely needs to beredefined from scratch, drawing the big picture isn’t a part ofmost IT projects. Instead, business model definition usuallybegins when the project team sits down, queries their repositoryof reusable assets, and ensures that they completely understandthe current business model.

Understanding the current business model before diving intodetailed process and technology solutions improves the process bywhich companies justify IT projects in two important ways. First,it makes it easier to put a project in the appropriate context, thusfreeing team members from the assumption that they need tojustify every process, technology asset, and resource on the basisof their current project alone. More importantly, examining thecurrent business model forces even technical experts to view theworld from the business’s point of view. IT professionals, forexample, might learn from the current business model thatimproving customer service is a priority in the upcoming calendaryear. As a result, they might be more likely to suggest that theircurrent project include an audit of the company’s call centerprocesses and systems.

104CHAPTER 5


Many IT departments have a history of making technologydecisions based on myopic, IT-centric justifications (such as thelatest technology trends) without anticipating how these deci-sions may impact the business. By employing the current businessmodel as a reference for IT, experts can help specialists who nor-mally focus on specialized tasks to understand essential businessbasics. In this regard, the current business model deliberatelycovers a lot of ground without going into too much detail in anyarea; the integrated, big-picture view forces the project team tothink through how the business works at a high level. They canthen base process and technology decisions directly on thatunderstanding.

Creating Business Scenario ModelsOnce the team understands the current business model, they canbegin to create the business scenario models that form the basis forend-to-end impact analysis in BTM. Each scenario represents aviable, to-be alternative for accomplishing the goals set out for theproject. For example, a procurement project may require one sce-nario to describe what it would take to join a public exchange, andanother scenario to describe what would be required to developand host a private exchange for preferred suppliers. By conductinga gap analysis between the current business model and each poten-tial scenario model, the team fleshes out which parts of the cur-rent model are relevant to their project. This helps planners tomeasure the scope of change that each scenario requires, includingthe people, assets, and internal and external business relation-ships that will be impacted. Also, the structured and visual natureof models makes it easy for the team to compare these scenariosand eventually combine the best of each.

Incorporating Changes into an Updated Current Business ModelAfter the project has been successfully implemented, the teamfolds its final business scenario (or an updated scenario if changeswere made before the project was completed) into the currentbusiness model, ensuring that upcoming projects have access tothe latest, most accurate design of the business. This is similar to


105


roundtrip engineering in software development, which ensuresthat the actual changes made to the real-world environment (thecode in roundtrip engineering and the business in BTM) arereflected in an updated model (the object model in roundtripengineering or the current business model in BTM). Businessmodel definition, then, helps to bridge the knowledge gaps thattraditionally exist between projects, and becomes a vehicle formaking sure that the current enterprise architecture remains acces-sible and up-to-date with a minimum of dedicated maintenance.

WWhhyy BBuussiinneessss MMooddeell DDeeffiinniittiioonn??Three emerging trends illustrate why business model definition isa necessary component for today’s IT projects:

– The continuously evolving technology environment pres-ents companies with opportunities to innovate the business

– The formal hierarchies in the enterprise that were onceresponsible for discrete components of the business modelare breaking down

– High employee turnover makes it essential that companiesinstitutionalize knowledge about their business environment

Technology Evolution Drives Continuous Business InnovationIn the past, much of the information captured in the businessmodel had been informally maintained and updated by word-of-mouth and general understanding of the business. Since the paceof business innovation was relatively slow, it was easy to keeptrack of seemingly routine knowledge such as the customer base,product portfolio, and company vision, and it was assumed thatevery manager knew this crucial information by heart.

But in the face of one of the enduring legacies from the NewEconomy—the recognition that technology advances can pro-vide a basis for innovating the business—this familiar paradigmmust change. Today’s companies have sped up their business plan-

106CHAPTER 5


ning to keep pace with trends like globalization, deregulation,and especially the torrent of IT breakthroughs that continue toflow out of laboratories and research and development (R&D)departments. To be prepared to capitalize upon the new opportu-nities offered by tomorrow’s technology innovations, enterprisesare moving from a paradigm where business priorities are re-eval-uated after regular but long intervals, to one of continuous re-examination of the business model. Analyst META Group, infact, predicts that “30% of CIOs will adopt a shorter planningcycle (no more than three months),” and eventually, “leadingglobal 2000 organizations will [implement] a continuous,dynamic strategic planning process.”1 By codifying the loose-knitinformation that makes up the business model and providing acentral location for storing business designs, business model def-inition helps companies cope with this perpetually shifting busi-ness environment.

Formal Hierarchies Are Breaking DownThe second trend that is driving companies to adopt businessmodel definition is the breakdown of traditional hierarchieswithin the organization. In the conventional, pyramid-shapedorganizational model, IT projects usually addressed only a narrowslice of the business. (The product development team, for exam-ple, might have sole responsibility for bringing new products tomarket and balancing the product portfolio.) This siloedapproach meant that members of a particular project team werevery familiar with their own area of responsibility, and rarelyneeded to look beyond the borders of their organizational unit tocomplete the project.

In many of today’s organizations, however, rigid reportingstructures have broken down, and IT teams are being asked todevelop solutions for a cross-functional audience. In order forthese teams to make design decisions to service this broad userbase, they need to develop a more complete understanding of thebusiness. At the same time, project teams are frequently staffedwith members that come from across the business, including thebusiness unit professionals for whom the project is intended, aswell as subject-matter experts ranging from process engineers to


107


enterprise architects to software developers. These diverse teams,regardless of their individual backgrounds, need an accessible,broad-based snapshot of the business around which they can dis-cuss alternatives and make intelligent trade-offs.

High Employee TurnoverThe final trend that is driving enterprises to embrace businessmodel definition is the high turnover of employees, especially inthe IT department. Before the development of structured businessmodels, crucial knowledge about the business was maintained onlyin the heads of relevant managers. Since the business was rela-tively static, these managers could be counted on to educate theirreports and make sure that individual decisions complementedoverall strategy and objectives.

But in the IT world, turnover runs rampant; specialists withsought-after skill sets are recruited for other projects, consultantswalk out the door after their engagement ends, and opportunitiesin a competitive job market lead employees to pursue new andgreener pastures. Information that was once safe with long-timeemployees might be gone tomorrow. By formally capturing thebusiness model and making it available to new hires or employeeswith new responsibilities, companies make sure that crucial deci-sions can be maintained even if the minds that first made themare long gone.

BBuussiinneessss MMooddeell DDeeffiinniittiioonn IInn AAccttiioonnThe variability in which the activities of BTM can be performedand the breadth of information they cover makes it difficult tocapture the essence of business model definition, process opti-mization, and technology automation without seeing them inaction. For this reason, Ch. 5, 6, and 7 each refer to a simulatedcase that illustrates how the activities of BTM might work in a fic-tional business environment.

108CHAPTER 5


Rauha Communications, a telecommunications company, haskicked off a project intended to roll out CRM in its wireless serv-ices division. This initiative, code named Project Alpha, has twostrategic objectives: First, the company wants to identify theirmost valuable customers and cross-sell new data services to them.Second, deregulation has increased competitive pressures on thecompany, and they want to improve their customer service tominimize the attrition of these high-value customers.

This simulated case provides a series of valuable glimpses intothe people and day-to-day tasks that are impacted when a com-pany undertakes the activities of BTM, and, more importantly,into some specific advantages that can follow from doing so. Forbusiness model definition, this example illustrates how RauhaCommunications goes about defining its current business model,and how stakeholders collaborate with one another and leverageinsights provided by the current business model to help buildcompelling business scenario models for Project Alpha.

Capture An As-Is Current Business ModelSoon after Rauha Communications kicks off Project Alpha, abusiness analyst staffed on the project meets with the project man-ager, and is tasked with meeting an important milestone: coordi-nating between multiple team members and external stakeholdersfrom the business to construct a current business model. This fitswell within the business analyst’s normal job function, which is toserve as a mediator between the requirements of the business andthe capabilities of the IT department.

Normally, Rauha Communications wouldn’t be starting fromscratch with their as-is state of the business; the project or programmanagement office (PMO) would provide a similar model thatcould be used as a starting point. But Project Alpha is the wirelessservices division’s first initiative to take advantage of BTM; pre-vious projects relied on unstructured, paper-based analysis of thebusiness. Before Project Alpha can really get underway, then, thebusiness analyst needs to put together a big-picture view of thebusiness to use as a starting point.

Putting this picture together will involve two major tasks. First,the analyst will need to create a general, high-level snapshot of


109


the wireless services division, since this is the functional unit forwhich the project is intended. The business analyst pulls infor-mation from the project charter, the current operating plan forwireless services, and some business cases developed for previousprojects to complete this picture. Figure 5.2 illustrates the big-picture view that the business analyst creates.

The second task requires the business analyst to define portionsof the business model that are relevant to Project Alpha in moredetail. This means coordinating in-depth with the business unit,so he reviews the project charter to determine appropriate contacts

110CHAPTER 5

DataServices

Rauha Communications:Wireless Services Division

Products /Services –

+

Strategy

Customers Organization

Timeframe

Cost

Goals Voice Services–

Cross- and up-sell to high value

customers

+

+

+

+

Handsets +Improve customer service to minimize

attrition +

+

+

–

Figure 5.2A high-level view of the current business model for RauhaCommunications that drills down to reveal the major goalsfor Project Alpha


from each division. This research yields three names: a marketingmanager, a director of sales, and a customer support supervisor.Since these three people will represent the end-user base for theCRM system, it’s essential that they be brought into the planningprocess early on.

Because the marketing, sales, and customer support divisionsare all located in the same physical location, the business analystis able to schedule a morning workshop that includes the threerepresentatives from the business. The workshop begins as thebusiness analyst walks through each of the high-level businessmodel elements that are defined, and asks the marketing manager,director of sales, and customer support supervisor to flesh out thedetails that relate to Project Alpha. For example, the marketingmanager describes each of the product and service offerings, aswell as the hardware and distribution partners; the director ofsales confirms the specific distribution channels, and refers to adata warehouse of customer information that can be used to iden-tify high-value customers.

By encouraging representatives from disparate parts of the busi-ness to collaborate and share information beyond their usual orga-nizational boundaries, the business analyst creates a currentbusiness model of the wireless services division that will function asa starting point for Project Alpha. When the next project is kickedoff, presumably with different objectives, business model defini-tion will begin with this current, as-is state. Over time, as individ-ual projects flesh out specific areas, the model will become a moreaccurate and complete picture of the wireless services division.

Develop Business Scenario Models For Impact AnalysisAfter the current business model is in place, Rauha Communi-cations’ project team moves on to developing each of the businessscenario models that form the basis for impact analysis. The teamcollaborates with marketing, sales, and customer support represen-tatives to examine the current business model as a starting point,and to identify areas where technology might be used to improvethe business. Once an opportunity has been identified, it is fleshedout as a business scenario model, or potential to-be state.


111


After examining Project Alpha’s current business model, amarketing assistant suggests that the project could help increaserevenue if it were timed to coincide with a campaign to cross- andup-sell to existing customers. This prompts a representative of thesales department to point out that the existing data warehouse ofcustomer information could be a powerful tool for segmenting thecustomer base according to total spend, demographics, and pastpurchases. The marketing assistant agrees, and adds that seg-menting this data would also help her to hone the discount struc-ture and improve margins. This multifaceted analysis of the modelleads the team to create a particular business scenario model thatpromises to increase revenue by cross- and up-selling to existingcustomers who are identified by a new customer segmentationcomponent (see Fig. 5.3).

112CHAPTER 5

Rauha Communications:Wireless Services Division

Products /Services +

+Strategy

Customers

Organization

Corporate

Consumer

Segments –

By total spend

+

+

+By demographics

+By past purchases

+

–

+

Figure 5.3A high-level view of a business scenario model for Project Alphathat drills down to reveal customer segments


By using the current business model as a vehicle for commu-nication and collaboration between beneficiaries of the project,Rauha Communications’ project team helps to ensure that thebusiness scenario models that they build pull together all of therelevant internal and external assets of the enterprise. In thisway, the as-is model acts as a vehicle for collaboration betweenotherwise disparate beneficiaries of the project, who, by con-tributing their personal expertise, are able to identify drivers forthe business scenario model that complements each of their areasof responsibility.

WWhhoo iiss RReessppoonnssiibbllee ffoorr DDeeffiinniinngg tthhee BBuussiinneessss MMooddeell??

The example of Rauha Communications illustrates a fundamen-tal advantage of business model definition: it encourages com-munication and coordination between the people who areresponsible for justifying IT projects to the business. This groupoften involves more actors than either of the other two activitiesof BTM. The primary responsibility for modeling the businessfalls upon business analysts—members of the IT department whospecialize in identifying how the business should put IT to work.These business analysts typically coordinate with representativesfrom different business units to collect the relevant design infor-mation (as illustrated by the inclusion of the marketing man-ager, director of sales, and customer support supervisor in theexample from Rauha Communications). In addition, processexperts should contribute to the model as well, since they willeventually be responsible for ensuring that the business processesdeveloped during process automation match up with each busi-ness scenario model.

Convincing each of these actors to embrace business modeldefinition is an essential requirement for companies who arelooking to adopt BTM. By making this move, they help to closedisconnects between IT and the business, breakdown the silos


113


that hamper holistic business planning, and end dependency onsimple, paper-based strategy documents. But business model defi-nition also provides another important advantage: it helps analyststo decompose abstract ideas about the design of the business intoconcrete elements. These elements can then be directly linked tothe business processes that will be impacted during process opti-mization—the second activity of BTM.

114CHAPTER 5


PPrroocceessss OOppttiimmiizzaattiioonn

66

THE SECOND ACTIVITY OF BTM, process optimization, serves asthe critical link between business model definition and technol-ogy automation. It is during process optimization that businessobjectives are translated from the business model into operationalprocesses—a coordinated set of tasks designed to produce a spe-cific outcome. These processes are then broken down (i.e.,“decomposed”) into sub-processes and activities in order to mapfunctional requirements to the technology that will eventuallysupport them. Our discussion of process optimization begins bydescribing what goes into a process model. Then, this chaptermoves on to discuss some of the primary tasks associated withprocess optimization and to explain why they are important in thecontext of BTM’s two other models (business and technology). It


also revisits the simulated case of Rauha Communications to illus-trate how process optimization takes inputs from business modeldefinition and creates outputs for technology automation, beforeconcluding with a discussion of the party responsible for this go-between activity.

WWhhaatt iiss aa PPrroocceessss MMooddeell??At one end of the spectrum, people associate a process modelwith a simple flow chart. At the other end of the spectrum, peopleassociate it with complex variants such as use cases and discreteevent models. BTM’s concept of a process model falls somewherebetween these two extremes. Process models are highly graphicalin nature. They are usually expressed as a diagram in which shapesrepresent tasks and line connectors represent links or flows. So itis easy to understand why, on the surface, they might resemblecommon flow charts. In addition to this visual diagram, however,process models also contain a rich set of attributes and depict acomplex series of relationships. Attribute information includingmetrics (average time to process a sales order, for example) can beuseful inputs for other activities such as discrete event model sim-ulation, while relationships help to capture process requirementsand identify dependencies between people, processes, and tech-nologies. The important distinction to make between a processmodel and its more simple and complex relatives is that it encap-sulates the correct amount of detail for timely, real-world analysisand decision-making, without going to the extreme of empiricalunreality.

In general, process models include four categories of items:– Process Hierarchies provide a logical structure that groups

processes into levels for easier viewing, understanding, andanalysis.

– Process Definitions and Flows describe how a companyperforms operational tasks and indicate both the order inwhich the tasks are performed and the information that ispassed back and forth during the execution of those tasks.

116CHAPTER 6


– Domains and Roles specify who is responsible in the organ-ization for carrying out particular tasks along with the out-right ownership or sharing of responsibility.

– Metrics and Rules describe how well a process should per-form and indicate how specific conditions dictate the way ortiming in which particular tasks are performed.

Process HierarchiesThe depth to which an organization chooses to decompose itsprocesses depends on how work activity is divided among the var-ious horizontal and vertical layers of the organization, and on theextent of the process analysis being conducted. At a minimum, aprocess hierarchy should include three levels—processes, sub-processes, and activities. The purpose of the hierarchy is to pro-vide a logical structure for drilling down from one process area tothe next. This is especially helpful given the complex nature ofenterprise processes. A beginning-to-end map of just a singleenterprise process—even without depicting any relatedprocesses—could easily span the walls of an entire conferenceroom. Organizing process elements into hierarchies makes it easyto group and traverse different levels. For example, the processInvoice and Service Customers could be broken down into thesub-processes Bill the Customer, Provide After-sales Service, andRespond to Customer Inquiries. The Bill the Customer sub-process could be further decomposed into the activities Develop,Deliver, and Maintain Customer Billing, Invoice the Customer,and Respond to Billing Inquiries (see Fig. 6.1).

Classifying processes into a hierarchy also facilitates the iden-tification of appropriate anchor points for cross-links between theprocess model and business or technology models. This makes iteasier to follow decisions from one model to the next to achievealignment. In the above example, the process, Invoice and ServiceCustomers, could be linked back to the business objective, Makeit Easier For Our Customers to Carry Out Transactions With Us,to show how requirements from the business model are inheritedinto process optimization. Similarly, the activity, Invoice theCustomer, could be linked forward to the application functional-ity, Electronic Bill Presentment, in the technology model to showwhere specific application and system decisions originate.


117


Process Definitions and FlowsThe purpose of process definitions and flows is to provide adetailed understanding of how work is performed from a beginningto an end point. They describe operational tasks in both graphical(diagrammatic) and textual terms. Shapes and text identify whattask is being performed and how it happens. While there is no cat-egorically right or wrong way to describe tasks with shapes, thereare commonly accepted representations. For instance, a rectangleis often used to represent a process, a diamond to represent a deci-sion, an upside-down quadrilateral to represent a manual opera-tion, a parallelogram to represent data, an ellipse to represent atermination point, and so on. Text that is associated with eachshape—expressed in clear business terminology instead of techni-cal jargon—provides additional information that explains the taskto a broad audience (see Fig. 6.2).

In general, there are two main types of flows: work flow andinformation flow. Work flow refers to the order in which tasks areperformed, and indicates whether tasks are carried out sequen-

118CHAPTER 6

Invoice and Service Customers

Bill the Customer

Develop, Deliver, and Maintain Customer Billing

Invoice the Customer

Respond to Billing Inquiries

Provide After-sales Service

Provide Post-sales Service

Handle Warranties and Claims

Respond to Customer Inquiries

Respond to Information Requests

Manage Customer Complaints

Figure 6.1An example process hierarchy for the Invoice and ServiceCustomers process


tially or in parallel. Information flow shadows work flow anddescribes how information and decisions travel between tasks.Line connectors graphically tie the tasks together and illustratethe type of relationships (input or output) between them. Thecombination of process definitions and flows provides insight intothe tasks that are manual, automated, out-sourced, or docu-mented; the interdependencies that exist between tasks; and theinformational or functional needs of each task.

Several notations are available that attempt to standardize howprocess definitions and flows are depicted, including Rummler-Brache, Integrated DEFinition (IDEF), Entry/Task/Validation/eXit(ETVX), Line of Visibility Engineering Methodology (LOVEM)®,and Role Activity Diagrams (RADs)1. These vary according to


119

InsuranceApplication Compute

Premium/Discounts/Taxes and

Penalty Fees

Update Customer

A/R Balance

Generate Bill/

Statement

Prepare and Distribute

Bill/Statement

Mailing

UpdateGeneralLedger

Generate ACH/Credit

Card Electronic

Payment File

Generate Policy Holder Notification/

Send to Processor

Is Receipt Through

Electronic Means?

YesNo

PerformTransactionProcessing

ProcessReceipts

ManageGeneralLedger

Figure 6.2An example process flow that depicts the billing process for a hypo-thetical automobile insurer


120CHAPTER 6

their application and intended audience. Each has its strengthsand weaknesses regarding its balance between uniform represen-tation and the need for practical and flexible use. The decision toadhere or not to a particular notation should be made by eachcompany independently based on the skills of its work force, thescope and objective of its process analysis, and the effort that willbe required to enforce compliance.

Domains and RolesDomains and roles identify the areas of the business and the indi-viduals that are responsible for executing processes. Domains moreor less correspond to the enterprise’s organizational units.Examples of typical, generic domains include manufacturing, sales,marketing, customer support, finance, and human resource man-agement. Examples of more industry-specific domains are claimsprocessing, store operations, and plant management. Roles (some-times referred to as actors) indicate who owns tasks at a moregranular level—departmental, group, individual, location site,internal, or external. Domains and roles are represented horizon-tally or vertically as swim lanes that are overlaid on process dia-grams to demonstrate how tasks are segregated or shared. Figure6.3 shows how swim lanes are applied to the previous example ofthe auto insurance billing process.

The focus on domains and roles sometimes creates confusionbetween aspects of process optimization and those of organiza-tional design. The primary intent of domains and roles is not torecreate or reengineer the organizational structure of a company.Instead, it is to group similar sets of processes, sub-processes, andactivities together in a way that approximates how the businesscategorizes its operations and to highlight where responsibilitiesare transferred between organizational entities. This makes it eas-ier to visualize how process changes might impact resource uti-lization, staffing, training, and cross-functional requirements.


Metrics and RulesCompanies generally apply a combination of performance metricsto their processes. Performance metrics specify how well a com-pany needs to execute certain tasks. They tend to focus on targetoutputs that are more external in nature, such as meeting cus-tomer requirements. These metrics are expressed in terms of fre-quency, volume, effort level, error rates, cycle time, forecastaccuracy, customer satisfaction, and such. For example, a com-pany that wants to decrease return rates for its products mightassign an accuracy performance metric to the order fulfillmentprocess. Or, a company following the Six Sigma® methodologymight assign a numerical value to the invoice-processing activityto indicate what the statistically valid ideal should be per hour.


121

InsuranceApplication Compute

Premium/Discounts/Taxes and

Penalty Fees

Update Customer

A/R Balance

Generate Bill/

Statement

Prepare and Distribute

Bill/Statement

Mailing

UpdateGeneralLedger

Generate ACH/Credit

Card Electronic

Payment File

Generate Policy Holder Notification/

Send to Processor

Is Receipt Through

Electronic Means?

YesNo

PerformTransactionProcessing

ProcessReceipts

ManageGeneralLedger

Polic

y Pr

oces

sing

Acc

ount

sRe

ceiv

able

Bill

ing

Figure 6.3Swim lanes in our example billing process flow indicate who ownseach task


The process model also includes rules, designed to act as checksand balances on the execution of a particular process. The busi-ness owner of the process (domain, department, group, etc.) deter-mines what rules need to be applied in order to ensure that certainprocess goals are met. Mostly, these rules are conditional—if con-dition A is met then do B. Benefits enrollment terms, seasonalpricing schedules, credit checks, inventory replenishment alerts,and purchase-level amount authorizations are typical conditionsthat might require the application of rules to a process. It is impor-tant to note that these are not application logic rules or databasetriggers that actually automate the process; they do however, guideapplication and system developers in translating these businessprinciples into programming code.

Metrics and rules are assigned in the process model as attrib-utes. Figure 6.4a demonstrates how metrics are assigned to thesub-process Pick Orders. Figure 6.4b illustrates how rules areassigned to the activity Perform Physical Inventory Count of theManage Inventory sub-process.

122CHAPTER 6

Move

PickOrders

A1

Ship/DeliverOrders

ManageTransportation

PackOrders

ManageInventory

ManageWarehouse

ManageDelivery/Shipping

Receiving(Non-Supplier)

MetricPerfect Order Fullfillment

A1

Figure 6.4aThe metric Perfect Order Fulfillment is assigned to the process Pick Orders


OOppttiimmiizziinngg PPrroocceesssseess iinn BBTTMMBefore the recent period of “technology for technology’s sake,” therewas an equally irrational time when corporations tackled “processfor process’s sake.” This phase, known as the business process reengi-neering (BPR) era, called for the radical reinvention of all processes


123

Manage Inventory

Confirm Material Receipt

Plan/Schedule Material

Movement Delivery

ManageInventory

Placement & Movement

Identify/Manage Material

Obsolescence

Receive Material from Production or

Receiving

Update Material Location (Master)

Receive Request for

Material Movement

Move/Deliver Materials

Perform Physical

Inventory Count

PerformCycle Count

Monitor Warehouse/Distribution

Center Performance

Update Inventory Value

& Reconcile

RuleSend alert to materials manager

if invetory falls below 66%

A2

A2

Start

Stop

Figure 6.4bA rule that indicates an alert should be sent to the materials man-ager if inventory falls below 66% is assigned to the process PerformPhysical Inventory Count


across the enterprise. BPR promised quantum gains in operationalefficiency and competitive advantage. However, it often wreakedhavoc on organizations, leaving them to wonder what value theyreceived in return for the millions they spent. It’s no wonder thatnow, when you even utter the phrase “process model” some execu-tives and managers go weak in the knees envisioning a return to the“bad old days.” So, I want to be clear that when I use the term“process optimization,” I do not mean revisiting BPR.

What I do mean by process optimization is the analysis anddesign of processes to provide a link between the business objec-tives and the supporting technology for a given IT project. Thewholesale revamp of the process environment is not required.Instead, process optimization focuses on improving the specificprocesses that support each proposed business scenario model.Working from the current process model—which depicts theexisting process environment—process analysts and domainexperts collaborate to generate to-be models that satisfy the aimsof the business scenario models. Next, they perform a gap analysisbetween the current process model and each to-be model to deter-mine which processes need to be eliminated, streamlined, auto-mated, or out-sourced, and to anticipate the potential impact ofthese changes on supporting applications and systems.

Drilling down from this high-level view of process optimiza-tion, there are four key steps within process optimization: translatebusiness model requirements, assess the value of existing processes,analyze process gaps, and develop functional requirements.

Translate Business Model RequirementsSince the process model acts as a lynchpin between the businessand technology models, it is important to first understand therelationship it has with the business model. Each process modeltakes its cue from to-be business scenario models that describethe objectives of the project, elements of the business that itimpacts, and scenarios the organization might pursue. This inher-ited information is then cross-linked to processes, sub-processes,and activities that can operationalize the business model alterna-tives. Cross-linking between models enables the process analysts,domain experts, and IT specialists to analyze the repercussionsthat each business scenario model has on operations, resources,assets, information, and supporting technology.

124CHAPTER 6


The benefits of linking particular elements of the businessmodel to those of the process model are twofold. First, by trans-lating what are essentially business model requirements intoprocess terms, it is possible to limit process improvements tothose that are practical and achievable. Assumptions made inthe business model scenarios (which may be based on superficialprocess knowledge) need to be validated against the intricaterealities captured by the process model. Certain business modelrequirements may not be feasible given constraints within theexisting process environment; nor may they be feasible (or evenadvisable) after changes are enacted in order to fulfill them. Forexample, a company may wish to assess the viability of their busi-ness objective to lower helpdesk support costs by bringing anout-sourced call center function in-house. By evaluating thisbusiness objective against current and alternative process envi-ronments, they may discover that it is more cost effective—whenconsidered against the staffing, facilities, training, and systemscosts required to support the function internally—to simply rene-gotiate the current contract and extend helpdesk service to busi-ness units not already covered under its terms. This approach toprocess optimization is iterative; lessons learned in the processoptimization phase can be passed backward to business modeldefinition, allowing requirements to be redefined or initiativesterminated if necessary.

The second benefit of linking business model requirements toelements in the process model is traceability. The rationale for cer-tain process optimization changes can be explicitly traced back tothe original business requirement driving the change. The result-ing audit trail helps teams to communicate to project stakeholdershow the organization plans to realize its objectives. Also, it canhelp the team to educate stakeholders regarding what it willrequire in order to accomplish specific goals.

Assess the Value of Existing ProcessesAssessing the value of existing processes and internal/externalparticipant relationships fulfills a vital step in process optimiza-tion. This assessment, which requires analyzing the current processmodel in the context of business goals, reveals inefficiencies and


125


redundancies; critical interactions and interdependencies betweenactivities; and opportunities for innovation. Because the currentprocess model provides an accurate and realistic view of howwork is carried out in practice—including typically undocu-mented workarounds that equate to hidden tasks or decisions—itcan help to uncover bottlenecks, unproductive and counterpro-ductive steps, time delays, hand-offs, and costs. Some activitiesmay be redundant and therefore represent waste that can beexcised from the process environment. Others that cross severaldepartmental boundaries may have no identifiable owner andtherefore, slip through the cracks. Still others may have outlivedthe original business rationale that justifies their usefulness. Thisstep is essential for gaining insight into which processes should beeliminated, streamlined, automated, or out-sourced. It also pro-vides the basis for developing to-be process scenario models thatdescribe potential alternatives for operationalizing proposed busi-ness model scenarios.

126CHAPTER 6

�

Spending Time on the FutureSaves Money

“It’s one thing to have a visioning session to discuss‘what we really want to be to our customers,’ but it’s awhole other thing to say how we actually should bringthis off. The future-state touch map is the first step inthat sort of actualization of the vision. When you’redesigning a future state, you’re designing it from a vision,and the vision is inherently holistic, because you arelooking at your business from the customer’s perspective.Once we begin designing processes around that futurestate, and when we outline the customer interactionsaround it, we will get a comprehensive, integrated view ofour real business.

There are some companies that are extremely self-reflective, constantly examining themselves and payingparticular attention to process. For them the kind ofvisioning that we’re talking about—setting up the future


Analyze Process Gaps Comparing current process models against process scenario mod-els allows process analysts and domain experts to analyze differ-ences and identify gaps between their existing and desiredenvironments. This analysis is important for understanding thetrue impact that proposed changes will have on process design,work and information flows, employees that perform the opera-tional tasks, external relationships such as customers and suppli-ers, and the underlying technology that must be in place tosupport it all. For example, process analysts and domain expertsoften need to ascertain which is more beneficial: reengineering aprocess to match the functional capabilities provided by a partic-ular application package or customizing the package to fit therequirements of the process. In order to make this type of decisionthey need to be able to consider a wide range of possible implica-tions (see Table 6.1).

What, at first glance, may appear to be a simple either/or deci-sion (reengineer or customize), actually involves making a series of


127

state touchmap—is a piece of cake; it might be a perspec-tive they haven’t thought of very seriously before, butnevertheless, it’s something that’s not hard to do. Forother companies it can be like picking hens’ teeth to gen-erate a touchmap of any kind, because they just don’t paya lot of attention to process. They may be too busy simplymaking sure that their head remains above the day-to-dayfinancial tidewaters. Done right, however, a future-statetouchmap will streamline your interactions, cut out waste,eliminate duplication, and give you a more rational feelfor your business, not only cutting out costs but pointingout additional revenue opportunities.”

– Don Peppers, best-selling author of the One to Onebook series, and a founding partner at the management con-sulting firm Peppers and Rogers Group.


sub-decisions. For instance: If we reengineer Process A whatimpact will that have on Sub-processes X, Y, and Z? Do we need torequire that our suppliers change their processes too? What levelof information access is required and does that mean we need tochange our security protocol? What is the amount of internaltechnical support that will be required if we make changes to thevendor’s application package? Is this same package already beingused by other business units for the same process? By analyzinggaps and determining impacts in this way, process analysts anddomain experts can make informed decisions regarding the bene-fits, risks, requirements, and trade-offs involved in implementingchanges. They can also use this same information to solicit buy-in

128CHAPTER 6

CharacteristicsArea

Processes – New, modified, or terminated activities

– Automation of manual tasks

– Cross-functional/cross-organizational dependencies

– Metrics, rules

Organization – Reassignment, hiring of staff

– Training, skills development

– Administrative, technical support

– Policies, procedures

Information – Cross-sharing data needs

– Data capture, location

– Data access, security

– Data flow, migration

Relationships – Physical, electronic interactions

– Customer, supplier, partner, service provider, distributor, regulatory interactions

Technology/Facilities

– Acquire, lease

– Build, develop

– Enhance, upgrade

– Consolidate, retire

– Customize

Table 6.1Modifying processes can impact the enterprise in a number of areas


on proposed process scenario models from the project’s businessand technology stakeholders.

Develop Functional RequirementsDuring gap analysis, process analysts and domain experts maymake the decision to automate specific activities with technologyor to enhance how previously deployed business applications func-tion. If this is the case, then the subsequent and final step ofprocess optimization is to develop functional requirements forthose activities. Functional requirements describe in non-techni-cal terms the steps and possible rules involved in executing theactivity. Take a typical insurance industry sub-process, Reviewand Approve Claims, for example. The functional requirementsfor automating select activities of this sub-process may look some-thing like this:

– Determine claim type by profile– Determine payment type by profile– View claims status– View claims payment record– Route approved claims for disbursement – Single sign-on to claims environmentDescribing functional requirements in this way helps process

analysts to communicate how work is performed from the per-spective of the end-user. The benefit of this is twofold: first, ithelps process analysts to carefully think through how processesare performed, which can prevent them from overlooking criticalsteps; second, it helps IT professionals understand the needs ofthe user community from more than a bits or bytes viewpointwhen trying to build or deploy supporting technologies. Thehand-off between these two domains, which is otherwise diffi-cult, must be as seamless as possible in order to avoid miscom-munication or misinterpretation of requirements.

After they are developed and prioritized, functional require-ments are cross-linked with application and system requirementsdefined later in the technology model. Creating linkagesbetween the two types of requirements ensures alignmentbetween process and technology domains. It also provides trace-ability for process analysts and IT teams to verify that all func-tional requirements are satisfied.


129


WWhhyy PPrroocceessss OOppttiimmiizzaattiioonn??Process optimization provides a mechanism to achieve the fol-lowing challenges and benefits:

– Integrate processes across the whitespace that canoccur between functions, departments, business units, or companies

– Achieve business-driven, rather than function- or compo-nent-driven process improvement and change

– Create a common requirements vision to mirror sharedservices across multiple organizational units and achievecontinuous improvement

– Improve visibility into vendor functionality to understanddegree of fit and reduce integration complexities

– Provide a basis for simulation or activity-based costing(ABC) process performance improvements

Integrate Processes across WhitespacesWhitespace, as defined in Ch. 3, is the gap that can occur betweenstrategy and operations, between organizational units, andbetween perceived or actual behaviors. Whitespace problems canlead to poor operational or financial performance, because respon-sibilities for tasks fall through the organizational cracks (the oldline, “But I thought you took care it!”) or because they hide weakor deficient processes. Process optimization helps to identify andeliminate whitespaces.

First, defining and assessing the value of existing processeserases corporate assumptions about how work is performedthroughout the organization. Everyone may think that they agreeon how processes work in their organization, but few actually pos-sess accurate, detailed process knowledge. Once companies cap-ture the realities of their operational environment with models,they can use them as a basis to detect unknown process breaks andweaknesses. Second, the swim lanes that are overlaid on currentprocess and process scenario models enable process analysts anddomain experts to visualize how processes cross back and forthacross organizational boundaries. By constructing models in thisway, it is possible to highlight who does what activities and when

130CHAPTER 6


during a process. This is especially critical when processes extendto external parties such as customers and suppliers, increasing thelikelihood that the execution or management of particular tasksmay be obscured. Third, archived models that serve as templatesfor future process optimization efforts essentially create an insti-tutional memory that can be recalled to fill in gaps left by employ-ees or contractors who have left the company.

Achieve Business-Driven Process ChangeSome companies still use and favor two process modeling tech-niques designed in the 1980s—the Zachman Framework2 and theSpewak EAP Model3. Given the mercurial nature of today’s busi-ness and technology environments, there are drawbacks to relyingon either. First, they focus on optimizing domain architectures. Asa result they are more function- and component-driven than theyare business-driven; and they require that a company invest sig-nificant time, money, and resources in an exhaustive analysis ofenterprise architecture. Traditionally, business stakeholders havehad a difficult time justifying the expense of such efforts because ofan unclear or lagging return. In contrast, process optimizationfocuses already scarce resources on analyzing processes and creat-ing improvements that can satisfy immediate or near-term busi-ness needs. Business value (not technological prowess) is the aim,and faster proof of concepts can be produced to sell change ideasto management.

Second, both methods were developed during a time in the1980s when the business environment and enterprise architec-tures evolved at a slower pace. In complex enterprise scenarios,completing such an endeavor can take up to two years. Nowadays,the rate of business and technological change is blistering, requir-ing companies to modify their process environments on the aver-age of every six to twelve months. Companies, and thereforeproject teams, must respond quickly to accommodate unforeseenchanges as they ripple throughout the enterprise architecture. Ch.1 provides evidence of how changes in the business climate canaffect the success of a project. Process optimization, whichinvolves the linking of process models to business and technology


131


models, provides teams with the ability to adapt in step as the ini-tiative’s business or technology requirements change.

For each of these reasons, the Zachman and Spewak methodsare complements to process optimization—they are more practicalas stand-alone improvement initiatives or as long-range planningexercises that can supplement the day-to-day design of IT projects.

Create a Common Requirements VisionThe increased sharing of IT services across business units and theneed to continually find ways to improve the operational envi-ronment has led some companies to create a common require-ments vision across multiple process activities. Through modelingactivities, process optimization facilitates the discovery and pool-ing of shared requirements. With this aggregated understanding offunctional requirements, companies can streamline activities,avoid redundancies, encourage adoption of process standards,manage change efficiently, and uncover customer service or time-to-market improvements. For example, process analysts may dis-cover that they can increase the efficiency of billing activitiesand offer customers a single point of contact for invoice inquiriesby processing all requests through one system. In another sce-nario, visibility into previously defined common requirementsmay lead IT analysts to reuse components, rules, interfaces, anddata related to an existing order processing application instead ofpurchasing a new application. From a change management per-spective, process optimization can also help to reveal the magni-tude of impact that changes in the technology architecture—suchas redesign, replacement, or upgrade—can have on an interde-pendent processes environment.

Improve Visibility into Vendor FunctionalityWith the ever-rising complexity and cost of enterprise applicationintegration (EAI) efforts, it is essential that project teams improvetheir understanding of how vendor offerings map to processesbefore purchase and implementation. The definitions, flows, andfunctional requirements encapsulated in the process model helpprocess and IT analysts to evaluate the fit between the two. Byexamining these elements of the process model and comparing

132CHAPTER 6


them against the capabilities of the application package, analystscan expose biases, assumptions, and constraints that are notrevealed during the typical feature/function checklist review. Let’stake the example of a company evaluating a vendor’s supply chainpackage to determine the fit between its automatic load-routingfunctionality and their transportation management process. Thedesign of the company’s Receive and Ship Orders sub-processrequires that carriers meet up-to-date contractual requirementsprior to receipt and loading of goods. The functional requirementcould be Verify Contract Rates Meet Approved Schedule. Theprocess, in effect, demands that the final package account for thiscondition in its transportation planning module. If the vendorcannot match this requirement with out-of-the-box functionality,this represents a constraint. Analysts will then have to decide ifthe requirement is non-negotiable, and if so, how they can satisfythe requirement through customization, alternate package selec-tion, or other means.

In the end, process optimization helps project teams make theright judgment call between end-user non-negotiables and appli-cation requirements earlier in the evaluation process, resulting inreduced integration costs and improved solution delivery.

Provide Inputs to Simulation and ABC EffortsSimulation and ABC efforts are extensions of process optimizationthat attempt to improve how the process itself performs.Simulation is generally practiced during BPR initiatives. Itinvolves conducting animated “what-if” experiments on currentprocess models to reveal bottlenecks or underutilized activities.These experiments (also known as discrete or continuous eventsimulations) help process engineers measure the effect of changeson variables such as timing, queuing, scheduling, resources, andcosts. ABC methods uncover waste or inefficiency by calculatingand analyzing cost consumption per activity (e.g., generate pur-chase order). This differs from traditional accounting methodsthat track lumped costs per department (e.g., marketing). Onceagain, current process models provide the basis for analysis, allow-ing process engineers to associate operating costs and capitalcharges with the activities represented in the model.


133


PPrroocceessss OOppttiimmiizzaattiioonn IInn AAccttiioonnLet me return to the example of Rauha Communications fromCh. 5. This example shows how process optimization acts as avital conduit between business model definition and technologyautomation. First, Rauha Communications’ project team willexamine their as-is processes to understand how the company cur-rently supports its customers and to uncover inefficiencies,dependencies, and opportunities for improvement. Next, the teamwill perform a gap analysis for the customer support process toflesh out the functional requirements that will meet the objectivesof the business scenario models and ultimately drive technologyautomation. Finally, process optimization provides the projectteam with visibility into unforeseen changes so that they canproactively respond as change ripples down from the businessmodel.

Examine the As-Is Process Environment Taking a cue from the goals outlined in the to-be business scenariomodel, process analysts assigned to Project Alpha begin to exam-ine the existing process environment to see what changes will berequired. The goals outlined in each business scenario model helpthem to prioritize and to concentrate their efforts on potentiallyimpacted processes. The bulk of their analysis focuses on sub-processes of the Manage Customers process in order to transformcustomer support operations into a 24-hour solution center.However, the ancillary business goal—to increase revenue bycross- and up-selling to existing customers—prompts them to alsolook at the high-level Market, Sell, and Manage Store Operationsprocesses. The process analysts enlist the aid of company businessprofessionals who possess detailed knowledge about the processesin question. Because these domain experts are responsible formanaging or executing the affected processes, it is essential thatthe process analysts solicit their guidance and buy-in as theyexamine and redesign Rauha’s process model. Figure 6.5 showsthe various domain experts involved in recommending and spec-ifying process improvements.

134CHAPTER 6


The cross-functional analysis of as-is processes highlights thatRauha Communications has redundant data capture and storageactivities occurring throughout the various functions (customersupport, marketing, sales, and retail operations). The project teamdetermines, therefore, that they should streamline the data entry,access, and maintenance activities for the various domains toeliminate this inefficiency.

Next, the team decides to use industry best-practice CRMtemplates to facilitate their design of the to-be process models.This helps the process analysts and domain experts to envision


135

Manage Pricing & Promotions+

+Measure Customer Satisfaction

...

Manage Field Operations+

+Manage Customer Records

...

Manage Distribution Channel+

+Manage Sales Force

Manage Customer Accounts

...

Fullfill Customer Service Requests+

+Process Transactions & Inquiries

+Suggest Products & Services

+Maintain Customer Accounts

...

+

Sales

Marketing

Customer Support

Retail Operations

Market – Manage Store Operations –

Sell – Manage Customers –

Figure 6.5Four domains and four processes that are decomposed during Project Alpha


opportunities to innovate such as self-service Web capabilities,online customer support chat sessions, and targeted Web promo-tions. Based on this input, the team identifies several new, auto-mated activities that will be necessary to operationally supportthese recommendations.

The process analysts then redesign aspects of the followingprocesses to accommodate all of the specified improvements:Market (Manage Pricing and Promotions, Measure CustomerSatisfaction); Sell (Manage Customer Accounts); Manage StoreOperations (Manage Customer Records); and Support Customers(Fulfill Customer Service Requests, Process Transactions &Inquiries, Suggest Products & Services, Maintain CustomerAccounts). Through the use of swim lanes, they are also able topinpoint the interactions and dependencies between functionaldomains, such as marketing and customer support for integratedcross- and up-selling activities.

Perform Gap Analysis and DetermineRequirementsAfter completing the to-be process scenario models, the projectteam performs a gap analysis between the desired and existingprocess environments. The project team calls upon the IT analystsin their company to jointly assess the impact that the proposedchanges might have on company operations and technology infra-structure. This helps the team arrive at more accurate conclu-sions concerning the feasibility, benefit, cost, and risk of pursuingeach option. Their analysis reveals that there must be seamlessintegration between call center and online customer support inorder to uphold the business pledge of improving customer service.Otherwise, Rauha Communications runs a high risk of alienatingloyal customers that are already accustomed to prompt and reli-able service.

Moving forward from the initial functional requirements, theteam continues to assess the implications of change and to flesh outrequirements that will drive the selection and development of sup-porting technology. Through this approach, they eliminate unfea-sible or out-of-scope requirements and prioritize the remaining

136CHAPTER 6


requirements. For instance, intelligent routing and a searchable,online solution knowledgebase are identified as non-negotiableitems, while online chat is tagged as a low priority, and customersatisfaction surveys that are based on interactive voice response(IVR) technology are dropped entirely. It is also known from busi-ness model definition that the marketing manager would like tosynchronize promotional campaigns with cross- and up-sellingefforts. The IT analyst proposes targeting promotional messages atspecific customer segments during any online sessions the targetcustomer conducts at the company’s Web site and so this require-ment is also added. The team continues along in this fashion,developing the full complement of functional requirements thatthey anticipate needing at this juncture. From all of those require-ments, they identify a few non-negotiable requirements that arekey to the initiative’s success (see Fig. 6.6):

– Integrate information from each touch point and productinto a single, unified view of the customer

– Restrict access to all online customer support functionsaccording to unique customer identification attributes (e.g.wireless phone number, password)

– Allow customers to search the online solution knowledge-base for self-assisted tutorials and installation, usage, andtroubleshooting information

– Provide customers with the ability to send email and onlineinquiries to customer support

– Automatically acknowledge receipt of inquiry and sendacknowledgment to customer via email or wireless device

– Intelligently route customer inquiries to the appropriatesupport representatives based on customer profile, type ofrequest, time zone, and integrated request queuing

– Display promotional offers during online customer supportsession based on customer profile

This collaborative process optimization approach allows RauhaCommunications’ project team to achieve consensus and buy-infrom the company’s process owners, while at the same time givingthese stakeholders from the business a sense of ownership over theoutcome. Allowing process owners to approve or veto processdesign early on in the process, increases the likelihood that process


137


changes will be accepted after they have been implemented. Inaddition, the development of accurate, prioritized functionalrequirements in easy-to-understand terms provides software devel-opers and system architects with the essential guidance they needto successfully map technology choices to end-user needs.

138CHAPTER 6

Determine type & query

solutions

No

Yes

Cust

omer

Cust

omer

Sup

port

Identify &authenticate

servicerequester

Send appropriate message to

sender based on business

rule

Requestapproved?

Is this a billing request?

No

To billing

Displaysolution scripts

ViaWeb

Requestlogged

Ability to submit online request

Access restricted by unique customer identification attributes (e.g., wireless

phone number, password)

Intelligent routing of request to

appropriate support representatives

based on customer profile, type of

request, time zone, and integrated request queing

Yes

Figure 6.6A process flow for the Fulfill Customer Service Requests sub-processand some associated functional requirements


WWhhoo iiss RReessppoonnssiibbllee ffoorr OOppttiimmiizziinngg PPrroocceesssseess

The Rauha Communications example demonstrates how processoptimization fulfills an important role as the critical link betweenbusiness model definition and technology automation. The pri-mary responsibility for process optimization falls upon process ana-lysts and domain experts who possess detailed, accurate knowledgeof how processes work. In some cases, companies will appointprocess owners that have overall responsibility for improving par-ticular processes. The discretion of these process owners spansmultiple business functions, freeing them from political andprocess restrictions generally imposed by organizational silos.Together, they model as-is and to-be states of the company’sprocess environment to help the company discover the best way tooperationalize business goals. IT analysts should also contribute tothe analysis of models, since they will eventually be responsible forapplying applications and systems to the business processes thatrequire technology support. In fact, the outputs of process modelsprovide useful inputs to component and class diagrams, data mod-els, sequence diagrams, etc., which make up a part of systems engi-neering and design.

The principal drivers of process optimization are the goals andobjectives inherited from the business model. These drivers keepteams focused on making changes that are in step with espousedmanagement vision and concrete corporate needs. In turn, theresults of process optimization drive the set of decisions made dur-ing technology automation. By approaching process optimizationin this way, companies avoid the costly disconnects that can occurwhen hand-offs between business, process, and technology are notstructured and managed effectively.


139


TTeecchhnnoollooggyy AAuuttoommaattiioonn

77

THE FINAL ACTIVITY OF BTM is technology automation, wherecompanies design the technology to automate selected processesand ultimately achieve the business goals of the project. In orderto appreciate technology automation it is important to have someunderstanding of the activity’s primary tool, the technologymodel. From there, this chapter moves on to describe how com-panies should approach technology automation during their ITinitiatives, explain some of the advantages that can follow fromtechnology automation, illustrate a simulated case of how RauhaCommunications puts technology automation to work, and finally,tell who needs to be responsible in the enterprise for this crucial,third activity of BTM.


WWhhaatt iiss aa TTeecchhnnoollooggyy MMooddeell??Since modeling is an inherently technical exercise, it’s anythingbut surprising that IT in has become fertile ground for a variety ofmodels. Two of the most popular are object models (which help todevelop new software applications) and data models (whichdescribe how data is distributed, communicated, and translatedbetween applications and systems). Although these two types ofmodels (and still others such as network diagrams) can be usefuland certainly have an important role to play in the IT department,it’s important to recognize that they’re not necessarily the best fitfor technology automation. This is because many of the importantdesign characteristics that have a profound effect upon whetherbusiness and technology are aligned happen at a higher level thanthat addressed by object and data models. For example, objectmodeling becomes useful only after a project team has determinedwhat type of software to build, a decision which itself has a pro-found impact upon alignment and must be dealt with duringBTM. Before drilling down to make the detailed decisions that aretypical of object and data modeling, IT project teams need amechanism to address the overall technology environment, makegeneral decisions about the applications and systems that will helpmeet the project’s goals, and get buy-in from their business audi-ence. This device, called the technology model, is the corner-stone of technology automation.

In general, technology models contain two layers:– The Applications Layer includes the business software that

directly supports certain processes. Some examples of appli-cations from this layer include customer relationship man-agement, enterprise resource planning, business intelligence,and supply chain management.

– The Systems Layer includes the underlying technology thatis necessary to implement and support the business softwarein the applications layer. The systems layer can includeservers (e.g., application server, web server, integrationserver, etc.), software (e.g., browsers, middleware), data (e.g.,databases, data warehouses), and networks.

142CHAPTER 7


The Applications LayerThe first of these layers, the applications layer, focuses on aspectsof the technology architecture that provide direct support forbusiness processes from process automation. The key cross-linkbetween processes and applications is provided by requirements,which can be traced either back to individual activities in theprocess model or forward to the specific applications in the tech-nology model that support this activity. The act of generatingthese requirements is shared between process optimization andtechnology automation, since the process involves give-and-takebetween each activity. Each application in this layer should alsoinclude some crucial attributes that describe it including stan-dards it adheres to, possible vendors, and whether the applica-tion exists today or is proposed for the future.

In general, the applications layer serves three important pur-poses. The first is to help flesh out application functionality, orhow requirements are supported by the components that make upeach of the applications. One of the major challenges of linkingprocesses to technology is that the two rarely match up one-to-one: a discrete business process may touch multiple applicationsand vice versa. For example, an insurance agent may directly orindirectly interface with distinct financial, document manage-ment, and customer support applications all during the course ofprocessing a claim—which is considered a single, discrete process.This mismatch makes it difficult for line-of-business employees,who tend to view their function in terms of the business processesfor which they are responsible, to communicate effectively with ITspecialists and developers, whose world view is framed by the dis-tinct applications that they develop and deploy. This disconnect ismagnified by today’s technology environment, which (because itemphasizes object orientation and distributed computing overmonolithic, process-based systems) separates user experience fromthe application functionality that is split between multiple build-ing blocks of code. Going forward, analysts and researchers predictthat Web services (where enterprise applications are broken downinto discrete chunks of code that communicate over the Internetusing open standards) will become the dominant paradigm forenterprise computing, a development that is sure to exacerbate


143


this challenge even further, and make the cross-links betweenprocesses and application functionality, such as those illustrated inFig. 7.1, even more critical.

In fact, this trend towards application distribution provides agood segue into the second purpose of the applications layer,which is to help integrate the various systems that make up manytechnology architectures. Although detailed, nuts-and-bolts inte-gration (such as the data-mapping and translation features pro-vided by EAI software) is too detailed for technology automation,the application layer should provide a mechanism for visualizingwhere to share information at an application level, and for makingsure that new applications are interoperable with existing plat-forms (see Fig. 7.2). This is especially true during gap analysis,where the project team works to design new applications thatneed to share crucial data with legacy systems.

Another time when application integration is crucial is whencompanies need to share information with customers, suppliers,and other entities outside of the enterprise. One of the great prom-ises of the Internet revolution was to make it easier for business

144CHAPTER 7

Procurement Inventory Mgmt. Financial

Requisitioning

Sourcing

Contract Mgmt.

Warehouse Mgmt.

Logistics

General Ledger

Accounts Payable

Accounts ReceivableCreate RFQ / RFP / RFI

Attach documents to RFQ / RFP / RFI

Customize contract parameters...

Figure 7.1Example requirements for the sourcing component of a procurementapplication in the applications layer


partners to electronically share information. But to actually accom-plish this, partners need to visualize the information that shouldflow across company boundaries, and how it integrates with theapplications on the other side of the gap. (An example of this inter-enterprise integration is when a sourcing application dispatches apurchase order to a supplier’s order-processing platform.)

The final purpose of the applications layer is to visualize appli-cation flow, or how the applications will behave from the per-spective of the end-user. Oftentimes, graphical user interface(GUI) mockups can be important tools here, because they allowusers to walk through a simulation of applications, and suggestimprovements and changes as they go. In fact, the applicationflow is most valuable for this very reason: It helps non-technicalbusiness representatives (whether they are executives responsiblefor giving the project a green light or end-users of the platform)visualize how the applications will work before they are irrevoca-bly put into place (see Fig. 7.3).

The Systems LayerThe technology model also includes a systems layer that capturesthe underlying hardware, software, data, and networks that arenecessary for implementing and integrating the applicationsdescribed in the applications layer. For reinforcement’s sake,


145

Financial

Inventory Mgmt.

Supplier

Marketplace

Procurement

RFQ / RFP / RFI

Figure 7.2An example view of application integration between internal plat-forms and an external business partner


remember that an application refers to business software such asCRM or ERP that directly supports business processes. A system—even though it may only be software—differs because it supportsan application or another system. Some common examples of sys-tems include middleware, hardware, networks, and data sources;some common attributes in the systems layer describe things liketechnology standards, configurations, and restrictions.

Within the systems layer, elements can be ordered according toeither logical or physical views. The logical view (of which Fig. 7.4is an example) partitions the systems into tiers according to thegeneral function that they provide. While BTM doesn’t prescribe

146CHAPTER 7

Buyer Login

RFQ Mgmt. RFQ

Supplier Search

...

...

Procurement Application Flow

Figure 7.3An example application flow illustrates a basic GUI mockup for abuyer logging into a procurement application

Presentation Tier

Application Services Tier

Integration Tier

Data Tier Systems Tier

Browser PDA

Figure 7.4An example logical view of the systems layer that includes five tiers,including a presentation tier with a browser and PDA


any definitive set, system tiers generally include things like a pres-entation tier (e.g., Web browsers, PDA’s, and dedicated devicesthrough which end-users interface with applications), an integra-tion tier (e.g., middleware, messaging, and enterprise applicationintegration servers that help exchange information between dis-parate applications), a data tier (e.g., databases, data warehouses,and legacy data), and so on.

The physical view, on the other hand, illustrates how systemsare physically distributed between machines that are connected tonetworks, similar to a network topology (see Fig. 7.5). This per-spective is valuable for IT developers, network engineers, and sup-port personnel, who oftentimes are challenged to maintain andupgrade physical systems while making sure that any changes theymake don’t have unforeseen consequences elsewhere in the tech-nology architecture.

AAuuttoommaattiinngg TTeecchhnnoollooggyy iinn BBTTMMSo far, this chapter has concentrated on what a technology modelis and what types of information are generally captured in one. Butto really paint a complete picture of how technology automationhelps to align business and technology, this chapter also needs to


147

Supplier

Marketplace

Web Server

Legacy Financial

Integration Server

Application Server

Application Server

Supplier Database

Internet

Figure 7.5A physical view of an example systems tier


explain how companies go about automating technology duringthe activities of BTM.

Technology automation follows the same general pattern asthe other activities of BTM: The team starts out by examiningthe current technology model, which is an as-is snapshot of theapplications and systems that exist today. Then they generatetechnology scenario models that correspond to each of theprocess scenario models inherited from process optimization.Next, they perform a gap analysis between the current modeland each scenario to determine the new applications and sys-tems that are required to pursue each. This analysis results in afinal scenario model, which becomes the basis for the full imple-mentation project, and eventually gets rolled into a new, updatedtechnology model.

Within this general framework, however, there are four keytasks that the team responsible for technology automation needsto focus upon: Develop requirements that link processes to appli-cations, design systems to the specifications required by eachapplication, develop technology standards and reuse applicationsand systems, and select vendors and packages.

Develop Requirements That Link Processes to ApplicationsSince each of the technology scenario models needs to align withat least one of the process scenario models developed duringprocess optimization, it makes sense that the first major task intechnology automation is to develop requirements that cross-linkindividual applications to processes. This general charge is a spe-cific manifestation of requirements management, a larger processthat also encompasses change management, prioritization, andother aspects of development that come into play during boththe design and implementation stages of the project.

The cornerstone for alignment between process and technol-ogy is the assumption that every application can be traced back tothe processes it supports. In some cases, such as an online salesplatform that supports the sales process or a call center applicationthat supports customer service requests, this is self-evident. Buteven applications that don’t obviously support individual

148CHAPTER 7


processes follow this paradigm. For example, it may not be clear atfirst glance how the information encapsulated in a business intel-ligence (BI) application—which slices and dices vast quantities ofinformation to identify trends within the business—is a natural fitto automate a process. However, if we consider that decisions arekey components of process models, and that BI can be crucial formaking informed decisions, we can still create direct cross linksbetween business applications and particular elements in theprocess model that they support. In other words, even when appli-cations don’t “automate” per se, they can still be associated withrequirements and in turn, processes, to maintain alignment.

Design Systems to The Specifications Required by Each ApplicationThe second key task that happens during technology automationis the design of supporting systems for each application. Generallyspeaking, the connection between applications and systems is sup-plied by specifications, which represent the specific technologyconditions that need to be in place in order for the application torun. These specifications, which are often captured as attributeswithin the model, can take many forms, depending on the specificneeds of each application. For example, one enterprise applicationmay require a database that complies with the Java DatabaseConnectivity (JDBC) standard, while another may need a data-base package from Vendor Bravo, while still another may requirea proprietary database that, in turn, requires a particular hardwareor software platform on which to run.

At first glance, the specifications that link applications and sys-tems look a lot like the requirements that play a similar role forprocesses and applications. There is a major distinction, however,that comes from the fact that specifications account for purelytechnical considerations, while requirements, by virtue of theirconnection to processes, are more oriented towards business. Inaddition, specifications differ from requirements in that they canconnect applications to systems and also systems to systems. Forexample, a CRM package that shows up in the applications layermay require a Structured Query Language (SQL) database (a sys-tem), which may in turn require a particular operating environ-ment or hardware configuration (also a system).


149


Develop Technology Standards and Reuse Applications and SystemsEstablished technology standards commonly show up as specifica-tions that cross-link applications and systems. This points toanother of the major tasks that makes up technology automation:Developing technology standards and reusing applications andsystems wherever possible. This, of course, is closely related tothe general principle of reusing knowledge and assets that Ch. 3discusses. It makes sense to mention standards and reuse explicitlyduring this discussion of technology automation, since this is theactivity of BTM in which this task plays the most prominent role.

Most IT professionals are familiar with common technologystandards such as Extensible Markup Language (XML), Busin-ess Process Modeling Language (BPML), or Open DatabaseConnectivity (ODBC). While these are powerful tools for achiev-ing reuse, formal standards such as these aren’t the only way thatcompanies can achieve reuse during technology automation. Inaddition, technology professionals can capture almost any designdecision in the form of a standard such as component libraries;packages; technologies for networking and data; and even logicalrules and conditions which developers are required to follow.The logical extension of this capability is the establishment of

150CHAPTER 7

�

Standards and Sourcing

“At GE, we have a strong sourcing function that we try toget involved very early, and there are incentives for doingso because they’re very good at what they do and they canget incredible leverage with vendors. Traditionally, there’sbeen a tension between technology and sourcing wheretechnology guys want to buy X and the sourcing guyswant to buy Y. But we just don’t seem to have a lot ofthose problems because we’ve streamlined the sourcingprocess with a couple types of technology standards.

On the one hand, there are some non-negotiablethings that we all need to adhere to, and violating them is


virtual platforms—complete standard operating environments forwhich the company’s applications can be written. Ever since thebeginning of the struggle between centralized and decentralized ITfunctions, companies have been challenged to set technologystandards and to make sure that dispersed teams adhere to them.


151

tantamount eventually to resignation. These are very seri-ous and they’re communicated quite well. Typically, theyhave to do with security or certain core infrastructurefunctions that are necessary for interaction with systemsacross the business unit. I’m not going to replace the mailsystem that I operate with a different mail system, forexample, because the Chairman will eventually sendemail to everybody in the firm and it won’t go throughand then I’ll be in deep trouble. These are kind of easy.

Then there are standards that we say are ‘highly recom-mended’, and they’re justified either because we havefavorable pricing or we have a lot of intellectual assets togo along with that vendor. These standards are wired intosourcing, so when I show up and say I want some randomserver to run this application, sourcing’s initial responsemay be ‘we get this great deal with another vendor becausewe’ve standardized on them’. In this case, it’s to my advan-tage to take advantage of the standards. They’ll be cheaperin the long run for me because I’ll either have more intel-lectual property at my disposal or more support at a corpo-rate level than I would have if I chose another solution.

So the sourcing and enabling functions that have avested interest in controlling cost are wired into the deci-sions for technology standards. You cannot buy aMacintosh; you can buy a Dell and you can have the Dellas long as it’s this model loaded with this software andthat’s what you’re going to get. And that’s a sourcing andfinancial decision, not a religious technology decision.”

– Chris Perretta, CIO, GE Capital, Card Services


By giving centralized enterprise architects a mechanism to capturetheir standard virtual platforms and disseminate them as tem-plates for far-flung projects, technology automation helps to medi-ate the struggle between standardization and specialization thattears many IT departments apart.

Select Vendors and Packages The final task that IT project teams have to tackle during tech-nology automation is the selection of off-the-shelf vendor/packagesolutions when they elect to buy rather than build applicationand system functionality. (In fact, the build, buy, or outsourcedecision itself is a crucial part of technology automation.) BTMdoesn’t advocate any method for selecting appropriate vendors.Instead, it provides key insights for performing impact analysis todetermine the right vendor fit. Since it is rare for even leadingvendors to meet every requirement for a project out of the box,the challenge while selecting vendors is fundamentally one ofmaking smart trade-offs between competing priorities, both posi-tive and negative. So, for example, one package may support aninventory management process that is similar to what the projectteam defined during process optimization, but would require theteam to purchase a new application server. Another packagemight not match the inventory management process all that well,but wouldn’t require any new technology purchases to integratewith the existing technology architecture.

Since selecting the best match for vendor/package solutionscan mean the difference between on-time, on-budget completionof a project and unmitigated disaster, making smart trade-offs dur-ing vendor selection should clearly be a top priority. BTM, byvirtue of its interconnected approach to business, process, andtechnology design helps to promote smart, holistic decision-mak-ing about vendors, so that the team responsible for selecting ven-dors/packages can visualize the end-to-end ramifications ofchoosing each solution. This is, of course, a specific manifestationof impact analysis, which is described in conjunction with predic-tive modeling in Ch. 3.

152CHAPTER 7


WWhhyy TTeecchhnnoollooggyy AAuuttoommaattiioonn??Technology modeling provides companies with a mechanism forkeeping up with five important industry trends:

– Team members and managers need to be able to trace indi-vidual technology assets back to the processes that they sup-port and ultimately to the business objectives that they areintended to facilitate.

– IT managers are being asked to control costs and maximizethe value of their investments in technology.

– More than ever before, technology specialists need to visu-alize integration points and improve how technology sys-tems work together.

– Companies need a single, unified view of their IT assets, sothat they can deploy and enforce standards and develop atechnology architecture that is both extensible and durable.

– The IT department needs to improve coordination withvendors, including software and hardware manufacturers andservice providers.

Technology Decisions Should Trace Back to Business and ProcessThe first and most important argument in favor of technologyautomation is that it provides a vehicle for the team to start witheach individual IT asset that is proposed for the project, and thentrace each asset back to the processes and business objectives thatit supports. This is, of course, the primary purpose of all the activ-ities of BTM, but it’s a point worth bringing up specifically duringour discussion of technology automation because some of the mostegregious cases of the business/technology disconnect are spreadby the “technology for the sake of technology” misconception.By cross-linking elements in the technology model to correspon-ding elements in the process and business models, managers cantrace back expensive IT decisions (to install an ERP package orpurchase a new application server, for example) to the businessrationale that is behind them, helping to reign in the notoriousfascination that technology specialists often seem to have with thelatest and greatest inventions.


153


Pressure is Increasing to Manage IT CostsThe second trend that is driving companies to examine technologyautomation is an increased awareness of how IT costs are weighingdown the business. Since many of the tangible costs that areinvolved in a typical project are either the result of specific ITassets (acquiring new or updated packaged solutions, hardware,and networks) or the indirect result of such systems (softwaredevelopment, package implementation, integration, support costs,and so on), a technology model can be a powerful tool for makingsure that companies get the most bang for their IT buck.

This is why it is important to link technology models directlywith IT asset management, a discipline that aims to catalogfinancial, contractual, and configuration information about keysoftware and hardware assets. Technology modeling helps com-panies make intelligent decisions about where to deploy existingassets, what new assets need to be purchased, and what assetshave become old or obsolete; it represents an ideal opportunity tomake sure that assets are used as efficiently as possible.Companies can achieve this goal by establishing standards in themodel that make it easier to develop and integrate new assets,and by identifying existing assets in the technology model thatcan be reused in upcoming projects. This last point is especiallytrue for legacy systems, which, although they may be a key part ofthe technology infrastructure, have been in place for so long thatthe current IT team has never taken the time to catalog their fullcapabilities. By examining legacy systems during the course oftechnology modeling, IT project teams often find that they canreuse existing functionality rather than reinventing the wheelwith newer technologies.

Research shows that technology models—especially when cou-pled with business and process models—help companies manageIT costs. In one extreme example, META Group describes how “aconsistent mapping of business drivers, the IT capabilities used toenable them, and the underlying IT resources (e.g., infrastruc-ture, applications) enabled IT executives to cut 30,000 workerhours and $135 million from their 2001 IT project list.”1

154CHAPTER 7


Integrating Disperse IT Systems Is More Important Than EverCost management isn’t the only reason that standards are impor-tant during technology automation. Standards also help to pro-mote unified technology architecture, making it easier to integrateand share data between otherwise isolated systems. Today’s ITenvironment is characterized by the increasing number and com-plexity of enterprise applications. But, with competing, propri-etary vendors jockeying for position within the market,integrating information from each platform remains a huge chal-lenge. Meeting this challenge, in fact, is one of the most impor-tant advantages that technology automation provides: Byproviding a unified view of IT assets it discourages one-off tech-nology architecture decisions that only take into account what isbest for the current projects. (This is similar to end-to-end impactanalysis which is discussed in Ch. 3, since it helps decision-makersavoid a myopic point-of-view and instead, take the complete, bigpicture into account at every decision point.)

Technology Architecture Needs to Be Extensible and Agile Another advantage of technology automation is that the stan-dards captured in the model promote extensibility in the technol-ogy architecture. Even after the “dotcom bust,” technologyinnovation continues to progress at a blistering pace, so companiescan’t afford to lock themselves into a static IT environment.Instead, CIOs need to make sure that their IT investments meettoday’s latest standards, and also whatever standards tomorrowmay hold.

Since predictive modeling is by definition preoccupied withdesigning the future state of a system, it makes sense that tech-nology modeling would be a prime predictor of upcoming ITchange. In the general sense, technology automation helps to pro-mote unified standards and holistic design decisions, which makeit easier to modify the technology architecture to reflect changingtechnologies, business processes, and so on. More specifically, theextensibility enabled by technology automation helps companiesto improve the speed and agility with which they can put newtechnology to work. Ultimately, this lowers the barriers against IT


155


change, and helps companies to focus on low-risk, short-term proj-ects that make incremental changes rather than long-term, high-risk projects that aim to make many major changes all at once.This shift, of course, has impacts that ripple out beyond BTM toinclude things like culture and the organization.

IT Departments Want Closer Communication andCollaboration With Vendors The final trend that is driving companies towards technologyautomation is the increasing importance of interaction and col-laboration with technology vendors who provide software, hard-ware, integration services, and out-sourcing. IT departments makehuge financial investments in technology vendors, both in termsof the actual contracts themselves and in related support, imple-mentation, and upgrade costs, so choosing the wrong vendor canadd astronomical costs and time delays to almost any IT project.

Technology automation helps to improve how project teamscollaborate with vendors to limit the risk of cost and time overruns.In general, technology models make it easier to link requirementsto the real software and hardware that supports them. In doing sothey provide visibility into how specific packages can (or cannotfor that matter) meet the project’s ultimate goals. One obvioustime when technology models can help to make better decisions isduring the vendor selection process; the project team can attach amodel to their request for proposal (RFP), and then compare eachvendor offering directly to the model to determine the appropriatepackage. This same interaction can also be facilitated in reverse,when vendors supply potential customers with models that describehow their offerings work off-the-shelf. In addition, technologymodels can function as an intermediary between the IT depart-ment and technology integrators or out-sourcing services. METAGroup, in fact, predicts that by 2005 over 40% of Global 2000companies will “promote architectural alignment in sourcing, asearly adopter successes become apparent.”2

156CHAPTER 7


TTeecchhnnoollooggyy AAuuttoommaattiioonn IInn AAccttiioonnOur simulated case of Rauha Communications and its CRM proj-ect in the wireless services division helps to illustrate how tech-nology automation addresses some of these industry trends. First,Rauha Communications uses technology automation to definerequirements for a new customer service application in a way thattraces back to business and process, and also includes the end-usersof the system early on in the project. Next, the company’s vendorselection process illustrates how technology automation improvescommunication between the IT department and third-party ven-dors and service providers. Finally, Rauha Communicationsenforces key architectural standards during technology automa-tion, and maintains a unified technology architecture that is bothrobust and extensible.

Define Requirements for the Customer Service ApplicationAfter completing process optimization, the Project Alpha teammoves on to technology automation. Their first task is to identifythe high-level applications that will be required to achieve theproject’s goal. After comparing some industry research supplied byan IT analyst firm to the requirements captured in the processmodel, they identify two major applications: campaign manage-ment and customer service (see Fig. 7.6).


157

Campaign Management Customer Service

Ad Management

Analytics

Reporting / Analysis

User Profiling

Portal Display

Knowledgebase

Figure 7.6Project Alpha requires a campaign management and customerservice application


From the start, one of the key objectives of Project Alpha hasbeen to improve service in order to minimize the attrition of high-value customers. The project team determines that to achievethis objective they will need to integrate the customer serviceexperience across two key touch points: their existing call centerand the Rauha Communications Web site. This will involveinstalling and integrating new software, so the Project Alpha tech-nology automation team begins by examining the current state ofthe wireless services division’s technology architecture. Then, theydefine requirements for the new applications that will be requiredto achieve their goals.

Technology automation kicks off in Project Alpha when anenterprise architect recommends an existing technology modelto use as a starting template. This model, which was developedduring a previous IT project, represents an up-to-date snapshot ofthe company’s technology architecture, and specifically the appli-cations that relate to customer service (see Fig. 7.7).

After spending some time examining this model and deter-mining how the current applications help support customerservice activity, a team composed of software engineers, customersupport representatives, a process analyst, and Rauha Communi-

158CHAPTER 7

Customer Database

CustomerBrowser

Customer ServiceWeb Server

Legacy Call Center Application

Disconnect

Figure 7.7Rauha Communications currently employs a legacy call center appli-cation and a customer service website that aren’t integrated


cations’ webmaster sits down to perform gap analysis and deter-mine what new systems are required. The customer support repre-sentatives begin by reporting that their existing call centerapplication, a legacy system developed some years ago, is bothfamiliar and efficient. The webmaster verifies that Internet sup-port is currently limited to a series of static HTML pages that listand answer some frequently asked questions. Clearly, the teamdetermines, they will need to improve Web support to include asearchable knowledgebase of problems and solutions, and perhaps,as the webmaster suggests, even live chat staffed by support repre-sentatives.

This conclusion leads the team to their first major decision:should the project aim to augment the legacy call center applica-tion, or should the team look to replace it with a single, inte-grated CRM platform? In general, they would prefer to reuse theexisting, popular system if possible. But since one of the require-ments for the project is to integrate information from each touchpoint and product into a single, unified view of the customer, theyrecognize that this could be a challenge. The team determinesthat both are viable options, and decides to create a technologyscenario model for each and postpone the decision until they havea better understanding of how both impact the underlying archi-tecture, the related support processes, and ultimately the overallbusiness objectives of Project Alpha.

First, they tackle the scenario where a new CRM systemreplaces the existing call center application, and develop require-ments for the new application. To address concerns early on, avoidbuy-in problems, and generally make sure that the requirementsservice the needs of the customer, they work with the customersupport representatives and the process analyst to develop require-ments and link them to individual activities in the correspondingprocess model. Figure 7.8, for example, illustrates how the cus-tomer sign-in process depends upon specific requirements thatmap to user profiling and portal display components within thenew Web service application.

The visual nature of the models that are developed during thisportion of technology automation helps the end-users, the cus-tomer support representatives, visualize how the new systems will


159


impact them. By getting these people to sign-off on the changes asearly as possible, the Project Alpha team helps to mitigate some ofthe cultural inertia that can weigh IT projects down. In additionto getting sign-off and preparing users for an upcoming change,technology models also help to democratize input into the design.Even though they aren’t technical wizards in any sense of theterm, the customer support representatives can provide valuableinsights into how they do their job and can make sure thatdetailed requirements make their way into the system before costlycoding or implementation begins. For example, after viewing thepreliminary model, one of the Rauha Communications’ customersupport representatives remarks that he would like to be able seeevery product that the current caller has purchased when taking asupport call, since it might help him to pinpoint confusion in billpresentation. This leads the development team to include a newrequirement detailing this request, and ultimately improves theutility of the Web service application that gets implemented.

160CHAPTER 7

CRM

User Profiling

Portal Display

Knowledgebase

Sign-on

Customer Portal Display

Search Knowledgebase

View Support Document

SSL Encryption

Single Sign-on

Ability to Group Users...

Figure 7.8Requirements that have been developed for Project Alpha map bothto an application flow diagram and also the application that providesthe underlying functionality


Examine Vendors and Make Intelligent Trade-offsEventually, after weighing the full impact of both scenarios, theteam responsible for technology automation determines thatsharing data between the legacy call center and new Web serviceapplications won’t be prohibitively difficult, and decides to pursuethat course of action. Since Rauha Communications doesn’t havethe capability to develop a leading-edge Web-service system in-house, they elect to purchase an off-the-shelf CRM application(which includes a Web services component) and then modifythat to achieve the project’s objectives. This decision leads to thenext phase of technology automation where a purchasing man-ager, technology architect, and an external consultant collaboratewith account representatives and sales engineers from leadingCRM software vendors to select an appropriate package andnegotiate a contract.

The external consultant, although she is an expert in CRMsoftware solutions, comes into the project with little in-depthunderstanding of either Rauha Communications or Project Alpha.In order to get up to speed, she sits down with the project teamleader who uses each of the business, process, and partially com-pleted technology models to describe the project’s objectives andscope, and to visually demonstrate the important decisions leadingup to the current vendor selection.

The consultant begins her research; identifies relevant analystreports, news articles, and product descriptions that pertain topossible vendors; and attaches them directly to the model itself.By contextualizing this information, she helps to make sure thateven after her engagement with Rauha Communications ends,the Project Alpha team can trace her decisions back to the sup-porting evidence. Eventually, the consultant submits RFPs andassociated technology models to each vendor. Although this par-ticular vendor selection is concerned only with selecting a CRMapplication, the package includes business and process models, aswell as the systems portion of the technology model. This givesthe sales engineers a better understanding of the requirementsthey are being asked to address, and allows them to generate amore accurate prediction of which requirements their software


161


meets out of the box, and which will require customization.Including the systems side of the technology model serves anotherimportant purpose: The new application will need to work withRauha Communications’ current technology architecture, includ-ing underlying systems. It is important for the vendor evaluationto consider not just functional requirements that link back toprocess optimization, but also technology requirements such asevent notification and work flow that are mandated by the currentsystems that make up the company’s technology architecture.

After the vendors respond to the RFP, the consultant sits withthe rest of the team to determine which package best meets theirneeds. Predictably, no single package is able to tackle everyrequirement out of the box, and the team will have to make sometrade-offs in order to minimize customization while maximizingthe project’s business benefit. But since each of the vendors’ pro-posals were generated against the end-to-end models developedfor the project, it is relatively easy for the team to evaluate theoverall impact of choosing each solution: One of the options,from Vendor Bravo, provides strong search and categorizationfunctionality for its knowledgebase, but doesn’t offer online chat.Another, from Vendor Charlie, touts its chat functionality as a dif-ferentiator, but is weaker in knowledge retrieval. The consultant isable to trace each of these requirements back to the processesthat they support and then from those processes to the originalbusiness model, which indicates that the knowledgebase is essen-tial for the project, but that chat is not. As a result, she recom-mends Vendor Bravo, and helps to assure that the final technologysolution delivers upon the project’s original objectives.

Establish and Enforce Application andArchitecture StandardsEventually, the project team selects a vendor, completes technol-ogy automation, and uses the end-to-end enterprise model to con-struct a sound business case for moving Project Alpha intoimplementation. Rauha Communications’ CIO and the firm’s ITinvestment committee approve of the design, the project is giventhe green light, and the new CRM system becomes a key compo-nent in the company’s wireless services division.

162CHAPTER 7


Project Alpha is a success. It is such a success, in fact, that thePMO decides to try and replicate Project Alpha in other businessunits. Specifically, a program manager wants to establish VendorBravo as the standard CRM package throughout the company.The program manager knows from experience that, left to theirown devices, far-flung project teams will often forget or ignorestandard packages, especially when doing so might benefitthem—even at the expense of the enterprise as a whole. ButBTM gives him a mechanism to counter this tendency. Recallfrom earlier in the case that in each of the activities of BTM, theProject Alpha team began with a standard template that it mod-ified to accomplish its own, specific objectives. The programmanager recognizes that by placing the models developed duringProject Alpha in a central repository and providing them toupcoming CRM projects, he can strongly encourage teams toadopt the standards that he sets, even to the point of reusing thereal software and hardware assets already developed for the wire-less services division.

BTM, then, provides benefits to Rauha Communications ontwo levels. First, it gives the team responsible for designing ProjectAlpha a mechanism to experiment, gain consensus, and validateconclusions before beginning a costly software implementationprogram. Business model definition helped the Project Alphateam to capture an as-is current business model and to develop busi-ness scenario models for impact analysis. Process optimizationenabled them to examine the as-is process environment, and performgap analysis and determine requirements. Finally, technologyautomation helped to define requirements for the customer serviceapplication, examine vendors and make intelligent trade-offs, and estab-lish and enforce application and architecture standards. Ultimately,addressing these concerns in the “aim” rather than “fire” phasesaves time, money, and helps to deliver a better end product. Buteven after these important tasks are accomplished, RauhaCommunications continues to derive real business benefits fromBTM: By helping the company’s program manager and his team todefine and enforce standards for enterprise architecture, BTMlowers the cost of and shortens the time that is required to com-plete similar upcoming projects.


163


WWhhoo iiss RReessppoonnssiibbllee ffoorr AAuuttoommaattiinngg TTeecchhnnoollooggyy??

As our simulated case from Rauha Communications illustrates,technology automation isn’t the sole responsibility of developersor even technical employees of any sort. This myopic approach, infact, is one of the key sources of the business/technology discon-nect in the first place. To engender a bigger-picture understandingof technology design, project teams should include end-users andbeneficiaries of technology as early on in the project as possible.Technology automation, because of its reliance upon models thatdemocratize user input, makes it possible to include a broaderarray of input and consultation than ever before. The primarydrivers of technology automation are the IT analysts and serviceproviders who are tasked with crafting the high-level technologydesign for the project. To make sure that this design conforms tocentrally administered technology standards and reuses existing ITassets, enterprise architects and the PMO should also play aprominent role. The final group that needs to provide input intothe technology automation process is domain experts. Thisincludes business managers and process experts who help to ensurethat the new technology will effectively support their own areas ofexpertise; vendor representatives who help to describe how theirofferings can contribute to the success of the project; and, mostimportantly, the prospective end-users of the systems who, by sign-ing off early on to the design of new applications and systems,minimize the cultural and organizational barriers that stand inthe way of the new technology being put to good use.

An End, But Also A BeginningAfter completing technology automation, selecting a final sce-nario model for business, process, and technology, and wrappingup the activities of BTM, the IT project team has an end-to-enddesign to help them create a better business case and get the fund-ing that they need to move on from the design stage to the build,test, and deploy stages—from “aim” to “fire.” However, this does-n’t mean that the models produced by business model definition,

164CHAPTER 7


process optimization, and technology automation become left-over artifacts from a bygone era after the activities of BTM wrapup. In fact, nothing could be further from the truth. At this point,the enterprise model becomes an anchor to which the implemen-tation team refers back to time and again to make sure that whatthey build matches what the project was designed to do.

As inevitable, unforeseen snags pop up along the way and theimplementation team is forced to modify the original design, theenterprise model assumes another important role: communicatingbetween technical implementers and the business and IT execu-tives who commissioned the project in the first place. When thedesign changes, the implementation team can update the modelto reflect their workarounds, and then pass these modificationsalong to the management team to get a final go-ahead and makesure that everyone stays informed of the progress.

Finally, the business, process, and technology models can pro-vide a useful segue into some of the more nuts-and-bolts disci-plines that come to the forefront during implementation. Forexample, the application functionality, interfaces, and flow thatare a crucial part of the technology model can provide a startingpoint for object modeling, a discipline that helps companiesdevelop applications in-house. And similarly, the IT assets in themodel—assets like application software, servers, databases, andnetworks—can be linked with asset management, which helps tomaximize the long-term value of IT resources.

These and other possible examples of how the models devel-oped during the activities of BTM might be put to work elsewherehighlight a crucial point about business model definition, processoptimization, and technology automation: their impact is feltthroughout the IT department and enterprise as a whole.Naturally, then, governing BTM to ensure that this impact is pos-itive rather than negative will be crucial to its success.


165


PPAARRTT

GGoovveerrnniinngg wwiitthh BBTTMM

IIVV

“Unless we change our direction, we are likely to wind up where we are headed.”– Ancient Chinese proverb

AFTER MONTHS OF CONSTRUCTION, you finally receive thecall you’ve been waiting for: It’s Robert, and he informs youthat your dream house is almost finished. “Sometime nextweek,” he says, “we should be all set.”

Obviously, you’re excited: You’ve been dreaming about liv-ing in a home like this one since you moved into your firstdingy apartment. At the same time, you’re surprised to noticethat you don’t feel even a pang of nervousness. Even thoughyour dream house represents a major investment for whichyou’ve been literally saving for your whole life, you’re not

PartIV_FINAL.qxd 7/25/2002 3:58 PM Page 167

worried. From their first sparks of inspiration through the day-to-day grind of construction, Robert and Janet have used the archi-tectural blueprint for the project to keep you appraised of theirprogress, to communicate design decisions, and to help you visu-alize the final product. You’re thrilled with the blueprint, and soyou know there won’t be any unpleasant surprises.

This is, of course, a selfish view. Building a house is a major job,and you aren’t the only person who has benefited from Janet andRobert’s expert approach. Besides the physical structure itself, thereare many other ingredients that need to come together to makewhat is essentially a pile of boards and glass into your dream home.

Just as important as the dimension of each room and the loca-tion of the windows, is the neighborhood in which your house willbe located and the quaint town that surrounds that. Many of themost desirable towns and cities are extremely careful about main-taining the character and charm that distinguishes them, and yourfuture hometown is no different. New construction has to adhere tostrict building codes that regulate everything from your home’sheight to its setback from the road and the style in which it is built.

All of this falls under the auspices of the local zoning board,which is responsible for approving or rejecting individual requestsfor new construction in order to maintain the integrity of thetown as a whole. The only way for this board to make a determi-nation about whether new construction is up to code is by exam-ining the architectural blueprints. These blueprints capture thedesign of the house in a format that is accessible and complete;without them the board would have no way to evaluate whetherthe new construction would compliment or clash with their care-fully maintained atmosphere.

Another ingredient that’s sure to factor into your satisfactionwith the project is its cost. In an ideal world, money would be noobject in this project. But for you—as for most of us—sticking toa budget is a must. No one is more important in this effort thanyour contractor, Robert, who gave you an estimate of what heexpected your house to cost up-front, and now needs to make sureto come in on time and under budget.

Like the zoning board’s decision, Robert’s estimated budgetwas based directly on the architectural blueprints, which allowed

168PART IV


him to calculate the materials he would need and how long itwould take to assemble them. Without a blueprint to work from,Robert would have had to pull an estimate for your dream houseout of thin air, and then would be left looking like a fool (orworse, a con man) when it came in way under or way over budget.

At the same time, Robert uses the blueprints to help minimizethe aggregate cost of all of the houses he’s currently building. Hedoes this by improving how he allocates expensive specialistsamong jobs, and by purchasing materials in bulk and then splittingthem up between projects. The blueprints help him to identifywhich projects will need who and when, and also what materialseach has in common.

For both Robert (the contractor) and the town zoning board,the blueprints produced during the design of your dream house area must. And their corporate-world equivalents are a must as well forRobert (the CIO) and another board—the IT investment com-mittee—which is responsible for managing the IT portfolio, a col-lection of projects and assets, the integrity and focus of whichshould be maintained on a case-by-case basis just like in our exam-ple. It’s also in Robert’s (the CIO) best interest to be able to accu-rately estimate and minimize the cost of getting projects done. Inthe architecture world, these are known as zoning and cost controls;in BTM, they’re called strategic direction and tactical control.

IInn TThhiiss PPaarrtt……In Part IV: Governing with BTM, will show how BTM helps togovern IT by setting strategic direction and maintaining tacticalcontrol. The mechanism for managing strategic direction is the ITportfolio. Enterprise models that are developed during BTM pro-vide the basis for analyzing this portfolio and making crucialinvestment decisions. The enterprise models also help to managequality by enforcing standards, and costs by reducing maverickpurchases and eliminating redundancies and waste. Collectively,these help maintain tactical control.

Governing with BTM

169


DDiirreeccttiioonn aanndd CCoonnttrrooll

88

THERE HAS BEEN AN UNFORTUNATE PERCEPTION for a longtime in many companies that IT somehow plays by a different setof rules than the rest of the business. At best, from an upper-levelmanagement perspective, it’s regarded as an enigma; at worst, it’sthe proverbial redheaded stepchild. This outlook often diminishesthe CIO’s credibility with his or her peers, compounding IT’sperennial struggle to demonstrate its true value to the business.

To counter the negative perceptions that have traditionallyplagued IT, CIOs need a mechanism for speaking the same lan-guage as any other senior manager: that of strategic direction andtactical control—or more commonly—governance. First, theyneed to be able to ask themselves, “Are we doing the rightsthings?” and then ask, “Are we doing the right things right?”


Being able to answer just these two questions well will better pre-pare CIOs to engage their business counterparts as equals.

While governance is not a new concept for IT, its recognitionas a suitable combatant against runaway technology investmentshas never been stronger. As it relates to the IT function overall,governance encompasses a plethora of management areas andactivities—including the management of portfolios, programs,assets, costs, human capital, service providers, etc. Obviously, thisentire subject is too broad for this discussion. In keeping with thescope of this chapter, I’ll limit the discussion to two primary sub-jects: strategic direction and tactical control.

SSttrraatteeggiicc DDiirreeccttiioonnRegardless of whether you primarily view IT as a financial assetor as a product (which is itself is a topic of much philosophicaldebate) the fact remains that, from the simplest standpoint, it hasintrinsic value and it can produce value. Therefore, its proposedallocation and actual assignment should be governed in the samemanner in which you would manage a portfolio of assets or ofproducts: being careful to consider balance, financials, risks, ben-efits, life term, and the like. Many can accept the basis of thisargument. What is not well understood, and what this chapterexplores further, is how the critical insights necessary to do soeffectively can be found in the models generated during theactivities of BTM.

The CIO is the Ultimate Portfolio ManagerAs the role of the CIO has shifted alongside that of IT, one of theresponsibilities that has risen to the forefront is setting the com-pany’s strategic direction with regard to technology. To managethis direction, CIOs need to be able to prioritize initiatives, justifydecision-making, measure risk versus return, and allocate resourcesin a way that maximizes their impact upon the business. The factthat this isn’t yet standard practice can be readily evidencedthrough industry surveys:

172CHAPTER 8


– 89% of companies are unable to adjust and align their budg-ets with business needs, other than once or twice a year.

– 66% of IT organizations are not “market-ready.” They haveno idea of their performance profile in terms of costs or busi-ness value generation.

– 89% of companies are flying blind. They have virtually nometrics, except for finance (which is sort of like flying aplane by monitoring the fuel burn rate).1

Most CIOs find it challenging to set strategic direction becauseof three factors. First, it is difficult to gain critical and timelyinsight into IT. Second, it is necessary to maintain alignment withthe business as conditions change or new directions emerge.Finally, the CIO needs a consolidated view of the resources undertheir purview before they can set direction. Together, these threefactors are driving many CIOs to adopt portfolio managementtechniques for setting strategic direction. In basic terms, thismeans gaining an aggregated view of IT investments across theenterprise, measuring them against established criteria, and thenstriking the appropriate balance within the portfolio that bestserves the strategic goals of the enterprise.

One overriding concern for portfolio managers is to balancethe risk and value in their investments. In one form or another,applying this balance is quite familiar to the CIO’s peers fromfinance, marketing, sales, and product development. If IT is to bemanaged like the rest of the business, it needs to follow this samepath, with the CIO playing the role of the IT portfolio manager.This doesn’t mean, however, that IT can be reduced to purelyfinancial metrics. IT is engineering-based; a company can’t simplyturn their CIO into a financial analyst and expect him or her tomanage strictly by a spreadsheet.

Discounted Cash Flow or Cash Cows?Portfolio management can be an equally important techniquewhether you choose to consider IT an asset or a product.Companies that ask their CIO to either report directly to theCFO or to function as a fund manager who doesn’t shy away fromfinancial accountability probably fall into the asset camp. Chancesare that they will gravitate towards portfolio management tech-

Direction and Control

173


niques that are inherited from traditional corporate finance man-agement. This type of portfolio management has roots reachingback to the 1950s with Markowitz’s Modern Portfolio Theory andto the 1970s with Black and Scholes’ Real Options Valuation.

The product camp, on the other hand, tends to prefer a moremarket-centric approach to portfolio management that drawsupon the Ansoff or Boston Matrix to strategically plot and manageproduct portfolios along composite dimensions, such as risk andvalue or growth and share. The inherent risk for this camp is thatcomplex IT investment decisions may not easily reduce to a four-,six-, or nine-quadrant box (see Fig. 8.1, which compares an assetcamp technique—discounted cash flow—with a Boston matrixfrom the product camp).

Regardless of which camp companies fall into, however, the ITportfolio helps them to evaluate the risks and rewards of theirinvestments as an integrated whole. By analyzing parametersincluding risk, return, capabilities, competitive intensity, marketvariances, and others, they can measure and understand the assets(or products) for which they’re responsible and determine whichto pursue, which to abandon, which to invest more heavily in, andwhich to simply maintain.

174CHAPTER 8

BOSTON MATRIXDISCOUNTED CASH FLOW

Star

Cash Cow

Market ShareHigh

High

LowLow

Dog

ProblemChild

Market Growth

Figure 8.1Discounted cash flow (an example of an “asset camp” approach)versus the Boston matrix (a “product camp” approach)


The general principle that is driving companies towards ITportfolio management is a simple one. An automotive companywouldn’t manufacture a car without first undergoing a compre-hensive analysis and design process to determine if the car wouldsell in a given market, how much it would cost to manufacture,what price it should garner, what features and functionality itshould have, how long it would take to produce, what resourceswould be consumed in its production, where the break-even pointwould be, how it fits in relation to the rest of the product line,what the relative life cycle and maintenance requirements of thevehicle would be, what competitive or environmental conditionssuch as new industry regulations would have an impact, and so on.And a corporation shouldn’t decide to invest in a particular tech-nology without following the same general rules.

The point of this chapter isn’t to carry on an exhaustive discus-sion of how to use any of the aforementioned methods; there areplenty of websites, articles, papers, and books that cover each, anddescribe how to apply them from A – Z. Nor is the point to endorseany one vis-à-vis the others. Each organization is different, and sothere is no “one-size fits all” answer for managing the IT portfolio.The point that you should take away from this chapter is that,generally speaking, portfolio management of one sort or anotherprovides a mechanism for the CIO to plot strategic direction. Asyou will see moving forward, it helps companies answer the essen-tial question, “Are we doing the right things?” more accurately.

Not Just Financial MeasuresIT has always been subject to financial scrutiny. But much of theanalysis has concentrated only on a partial picture, and hasresulted in the impression that IT has overspent and under-lever-aged its investments. If you are not convinced, just check withany CIO that lost a budget arbitrament (if not a career post) bymanaging solely by the numbers. This is a mistake. IT portfoliomanagement shouldn’t be reduced solely to financial measures.It’s simply not as easy as plugging numbers into a spreadsheetand making inferences from that. Just look at where relying onthe sacrosanct measure, ROI, has led the industry. For years, ITprojects have been subject to approval based upon the merits of


175


expressly quantified ROI. The line of thinking has been thatROI somehow equals project success—work the math, and aslong as two plus two equals four, things should turn out right.Unfortunately, countless projects have failed miserably and costcompanies millions of dollars (if not shareholder value), despitebeing justified according to supposedly solid ROI assertions.That’s not to say that ROI as a tangible measure is intrinsicallyflawed and should be discarded altogether. It is an importantindicator when formulating IT investment strategies, but it isjust one piece of the puzzle. Of equal, if not more importance, areintangible measures.

Intangibles are more qualitative and thus more subjective innature than tangible measures. Tangibles include operating costs,income, assets, liabilities, profit margins, return on assets, andother measures that lend themselves to being expressed as finan-cial ratios. Intangibles on the other hand, comprise a diverse rangeof measures, which may include strategic fit, goal alignment,opportunity costs, customer connectivity, competitive threat,return horizons, business impact, process optimization, intellectualcapital, skills, and innovation among others.

There are three problems with only relying on tangible meas-ures. First, there is a cultural proclivity to “work the numbers” tomake them say what people want them to say. Second, tangiblemeasures are largely reactive, while intangible measures lendthemselves to forward-looking views, since they often drive thetangibles. (Intangible measures often contribute directly to pro-ductivity, profitability, and ROI, for example.) Finally, many of thebenefits that follow from IT projects are hard to define in thedirect, financial terms that tangible measures require. For exam-ple, a company may notice that after installing a sales force auto-mation platform their revenue increased over previous quarters.But this says nothing about how much of the increase is due tothe software and how much is the result of other factors such as agrowing market or a new compensation structure for the salesteam. What IT is, meaning its life as a capital or physical asset,warrants evaluation with a tangible set of measures. But themajority of what IT actually does falls more into the sphere of theintangible.

176CHAPTER 8


A good balance of tangible and intangible measures allows ITportfolio managers to anticipate the potential value of technologyinvestments by providing:

– Visibility into future risks and causal relationships– Safeguards against slippery-slope conclusions– Counterweights to over-inflated promises and expectations– Flexible accommodation for rapidly changing environmental

influencesBy formulating a more holistic picture of the potential value

that resides within and that can be generated by the IT portfolio,CIOs can offer their business counterparts more realistic valua-tions of IT investment returns.

A Single View One primary advantage of utilizing a portfolio approach is that itprovides a single view into diverse IT initiatives that, after therecent wave of decentralization, may be spread across 40 or morebusiness units occupying hundreds of locations. That alone is oftremendous management value for the CIO, whose responsibilitiesgenerally span multiple organizational and budgetary silos. Suchan aggregated view typically encompasses the following categories,although a different or further stratification can occur dependingupon the organization:

– Infrastructure (e.g., networks and hardware)– Applications (e.g., commercial off-the-shelf or in-house)– Information (e.g., corporate and customer data)– Processes (e.g., value-chain activities)– Human capital (e.g., skills or experience)– Relationships (e.g., vendors or contractors) These IT resources are then associated with projects that have

specific attributes assigned to them, such as an owner, schedules,milestones, allocated resources, a budget, costs, risk, expectedreturns, scope, status, priority, and other criteria that can be usefulfor tracking or applying weighted scores. Projects are further clas-sified into programs (which represent logical groupings of projects)that help portfolio managers utilize a working framework for bal-ancing the portfolio, identifying similar projects to avoid “apple toorange” comparisons, and creating an additional layer of abstrac-tion for the office of the CIO from possibly hundreds of staggeredor parallel projects (see Fig. 8.2).


177


In this manner, CIOs and their extended team are able to viewaggregated cross-sections of information about the state of their ITinvestments for holistic—not stand-alone—decision-making. So,for example, the CIO could use this method to quickly assess allthe instances where a particular vendor’s solutions were slated foruse across the year’s remaining projects in order to ultimatelystrengthen purchasing leverage. Or, they could determine thatcore infrastructure investments are currently under-funded in rela-tion to the projected increase in demand that will occur as a con-sequence of adding a new subsidiary business location. Or, theycould find out what the distribution of IT spending is across all thedepartments that IT supports. It may be trite to say that trying todecipher this information otherwise would be like looking for aneedle in a haystack, but that is truly the case.

As a best-practice precursor to this type of strategic planning,a baseline assessment of existing IT resources needs to be in place.Recall from the activities of BTM that the very first step is toidentify a current enterprise model that describes the organiza-tion’s as-is state. Since this enterprise model contains the com-plete set of artifacts enumerated in the categories bulleted above,it helps to construct the portfolio. This baseline assessment is notto be confused with an asset inventory that would be assembled forthe purposes of managing an asset’s life cycle from procurement toretirement. An inventory, although useful, has limitations in thiscase. First, the baseline assessment is intended to assess the level offit between a company’s business requirements and its IT invest-ment mix. An asset inventory, by design, will not produce thiskind of insight. It would be insensible to base a go/kill decision for

178CHAPTER 8

Sub-Project

Sub-Project

Sub-Project

Project A

Sub-Project

Sub-Project

Sub-Project

Project D

Sub-Project

Sub-Project

Project B

Sub-Project

Project C

Program X

P O R T F O L I O

Figure 8.2A portfolio can consist of projects and sub-projects that canbe grouped into programs to identify similarities


a project on a rank list of assets. Second, the asset inventory doesn’t take into account the majority of the aforementioned cat-egories, such as processes. The vast store of information that isneeded to conduct such an analysis is better derived from theenterprise model, as it describes the allocation of the full range ofcategories in relation to the business objectives that they supportand the critical interdependencies that exist between them.

From the Bottom UpAnalysis is the heart and soul of any portfolio approach; it’s wheremanagers make the final call about how to allocate investments inthe portfolio. At the same time, analysis is far and away the mostdifficult step in the process. A common criticism of applying port-folio techniques to IT is that it is done in a vacuum, and so man-agers aren’t necessarily equipped with the underlying data theyneed in order to effectively evaluate opportunities, threats, andconstraints. You can’t measure what you don’t know about.Consider how effective the practice of CRM, which aggregatesdata about customers into an overarching view for strategic analy-sis and action, would be in the absence of sufficient underlyingcustomer data. Customer lifetime value (CLV), which helps com-panies determine the most profitable customer segments, is one ofthe most essential metrics in CRM analyses. Without havingaccess to the disparate data that combines to calculate this met-ric—such as frequency of purchase, amount of customer spend,and cost to acquire and service the customer—it is nearly impos-sible to assess CLV. The same would be true for conducting effec-tive IT analyses in the absence of any supporting information.

This vacuum is partially attributable to a gap between the ITportfolio and the resident data. The data is either buried in aspreadsheet or project plan or it is locked away in the heads of per-sonnel that perform specialized functions. In any event, this pres-ents a secondary set of complications. The more difficult it is toassemble the required data, the less likely that it will be main-tained or even gathered in the first place. The focus then alsoshifts from the analysis of pertinent data to the collection of it.Charles Popper of The Program on Information Policy Research atHarvard University states it thus:


179


Relying upon ad hoc, manual methods to collect and processdata, with support from standard productivity tools, is certainlypossible, but if more effort is expended on data collection andcorrection, then less time and fewer resources are available for the analysis and decision-making needed to manage theportfolio and its projects.2

The final complication is that the greater the distance betweendata and analysis or the more times information is translated dur-ing the course of moving from one point to the next, the greaterthe likelihood that inaccuracies and misinterpretation will occur.

The models produced during the activities of BTM help toalleviate these data difficulties. Business model definition, processoptimization, and technology automation surface the criticalunderlying data elements that are necessary for applying both tan-gible and intangible measures to the portfolio. The data elementsthat are generated as a natural by-product of these activities pro-vide managers with visibility into a wide range of insights that isotherwise missing. These can be insights regarding hidden costs,direct and indirect benefits, requirements (capital, functional,human), process capabilities, mix (customer, supplier, vendor,technology), performance, time-to-market schedules, trade-offimplications, standards and quality compliance, feasibility, etc.When funneled up, these insights enable portfolio managers todraw appropriate, non-skewed conclusions in relation to risk andreturn. That is not to say that it is incumbent upon portfolio man-agers, be it the CIO or his or her delegate, to sift through theminutiae. Rather, they benefit from the cumulative reasoning thatoccurs throughout the design activities and have a means to followthe cookie crumb trail of validated assumptions if necessary.

Consider a simplified example: The current year corporatestrategy of a large manufacturer entails a directive for increasedprofit margins via global expansion in a particular market.Executing on this goal requires the development of a series ofintegrated strategies across the functional domains of the com-pany. From there the decision has been made that product X hasthe greatest potential for distribution and sales. A central initia-tive (initiative A) to the business unit’s strategy is to connectwith key suppliers to reduce the cost of materials. The challenge

180CHAPTER 8


for the office of the CIO is to set a strategic direction for technol-ogy that will achieve that objective given the stated parameters(e.g., budget, time) for initiative A, and to meet it within thecontext of the company’s other running objectives.

The office of the CIO has the IT budget allocated among non-discretionary (maintenance and operations), discretionary (con-solidation and upgrade), growth (strategic), and venture(innovation) categories. These categories are likewise brokendown into respective projects and programs. Any IT strategy thatis devised to meet the objectives of initiative A (along with theassociated projects/programs) must be evaluated with respect to itsstrategic fit with the other categories.

A cross-functional team of business and IT analysts proposesautomating regional supplier relationships. But is this the direc-tion that IT should be taking both for the initiative itself and forthe portfolio on the whole? The CIO must be sure of this first,before he can sell it to the business unit co-sponsor.

The data that is required to validate this proposal comes fromthe activities of BTM, since they help to quantify the project’scost, risk, and expected benefits (see Fig. 8.3). The activities val-idate that automation will lower sourcing costs (business modeldefinition); sourcing and approval processes will have to changewhile procurement managers, demand planners, and purchasingagents will need to be retrained (process optimization); a newprocurement application will need to be purchased; and a con-sulting partner will need to be contracted to integrate the platformwith the legacy financial system and supply chain systems (tech-nology automation).

By using the data derived from these activities, the office of theCIO can make informed assessments of the proposed project’s spe-cific risk and value. Next, they can balance criteria like projectcost to hedge against unforeseen fiscal constraints, term lengthto allow the department to address perceived long-term trendswithout gambling entirely on an untested concept, and scope tomitigate against dramatic changes in the business. The CIO or amember of the PMO can then extend the initial project analysisto determine fit with the overall IT portfolio investment mix. Bycalculating the tangible and intangible measures derived from the


181


business, process, and technology models, the team is able todemonstrate that their project aligns with corporate objectivesand fits within the allocated spend for the IT investment growthcategory. In this way, the CIO can be assured that IT is doing theright thing and can ultimately demonstrate it to solicit businessunit buy-in.

Navigating and Negotiating Beyond providing the raw data to analyze IT investments, themodels produced during the activities of BTM facilitate two addi-tional objectives that relate to strategic direction:

– Monitoring the portfolio to periodically reanalyze risk andvalue

– Communicating decision-making criteria to other stake-holders

182CHAPTER 8

Business Strategy

Financial / ROI

Project Status

Resource

Processes Technology

Figure 8.3The models produced during the activities of BTM provide theunderlying data for analyzing the IT portfolio


Monitor and Periodically ReanalyzeEven after being given the green light, most project methodologiesdefine gates through which an initiative must pass in order toprogress. Gates often coincide with traditional project milestones(such as the selection of a technology vendor), but can also be trig-gered when total costs exceed a pre-defined amount or in responseto ongoing project audits. These are good opportunities for the ITportfolio manager to re-evaluate his or her investment in the proj-ect. Assessment should never be a one-time event. Changes in therisk or value of an IT project (and by proxy the whole portfolio)can quickly occur, for example, as the result of a new competitivepositioning for the company or a shifting business landscape. Recallfrom Ch. 1 the continual stream of changes encountered by PatrickFlynn’s team in their customs-clearance system project. The deci-sion criteria to stick with the project might have been dramaticallydifferent had there been visibility to these shifts in the business climate earlier in the process.

Until this point, the practice of managing by exception—whereby managers take corrective actions based upon proactivenotifications of problems—has been traditionally difficult. Itrequires that key decision-making information about the projectremains up-to-date at all times. Generally, standard approaches toproject management result in managers receiving lagging updatesconcerning a project’s status. The models developed during busi-ness model definition, process optimization, and technologyautomation can help to overcome this challenge, because theycapture an accurate snapshot of progress throughout each step ofits design. Decision criteria can be associated with individual ele-ments in the model, and when the model changes, the criteria canbe updated in real time to determine if an exception should behighlighted. This helps identify projects early on that are out ofvariance so that portfolio managers can recalculate their risk andvalue assessments.

Communicating through Visual AidsThe process of managing the IT portfolio is ultimately aboutdetermining the strategic direction in which the IT department isheaded. As such, it’s the office of the CIO that is the ultimate


183


portfolio manager, and the IT department that needs to be respon-sible for making sure that investments are aligned with overallbusiness strategy. Keep in mind, however, that the CIO doesn’thave sole budgetary control over every IT expenditure. Projectsmay be initiated and ultimately funded by the business units forwhom they are intended, or by an IT investment committee com-prised of the CIO, line-of-business sponsors, and representatives ofthe CFO. This means that senior IT leaders need to work withother stakeholders from the business to develop business casesand secure funding. It is far more likely that a line-of-businesssponsor or a financial executive will give the go-ahead if they canassimilate how the project will serve their aims. Again, the busi-ness, process, and technology models developed during BTM canplay a crucial role here. One of the key advantages of modelingthat Ch. 4 discusses was that models are powerful tools for visual-ization. They can help participants at the negotiating table toseparate the map from the territory and safeguard against fundingdeterminations that may be shortsighted or that may be driven bythe individual that wields the most power.

MIT professor Peter Senge’s seminal work, The Fifth Discipline,addresses how impasses occur between departmental or functionalareas of responsibility owing in part to the fact that people carrywith them ingrained “mental models.”3 People vigorously defendthese models, which contain their hidden beliefs and assump-tions. Historically, IT has had considerable difficulty in changingthe mental model that the business holds regarding IT’s efficacy.This leads to perennial conflict when it’s time to negotiate, espe-cially if neither side is particularly fluent in the other’s language.With three-quarters of the IT budget traditionally being allocatedto keeping the business up and running, it’s always a struggle toagree on how the remainder of the pie should be divided up toachieve the organization’s goals. This is even more so the case intimes of economic softening when executive decision-makers arerequired to take apart budgets and trim excess fat. The outsourcingcraze of the 1980s when IT itself was viewed as excess fat stillsends a shiver down a few CIO’s spines.

The models created during the activities of BTM can be usedto eliminate any entrenched biases and objectively demonstratehow IT plans to align to the business—and how it arrived at its

184CHAPTER 8


conclusions. These models represent fact, not fiction. By usingthe models as a point of reference in the negotiations, IT can’t beaccused of “voodoo economics” and business units can make intel-ligent concessions according to the dictates of a level playing field.In addition, models, through their visual nature, also provide acommon language, allowing an easier exchange of information tooccur between the two domains. Traditionally, each domain hashad difficulty in understanding the other. Models, however, createa shared language that can reduce the likelihood of misinterpre-tation between the “bureaucrat” and the “technocrat.” At the endof the day, both sides need to come together to prioritize and allo-cate IT spend in a manner that benefits the corporation as awhole, and models can help foster the rapport and dialogue nec-essary to do that.


185

�

Governance Pop-Quiz

“If you are CIO of a global business, just keeping track ofthe myriad of IT initiatives across the business units, andaligning these with each other and with corporate goals, isvery challenging. You have to make sure that initiativesare consolidated and that you have some sort of perspec-tive going forward, not just looking at the historical per-formance of the business but looking at the potentialfuture performance. Really, you should be consideringhow your answers stack up to the following questions:

– Do you have a mechanism to communicate in thesame language as the CxO community?

– Can you demonstrate how you are aligned with thedirections the business wants to go?

– Has your world become more complex than aspreadsheet can handle?

– Do you have a good picture of all your existingresources?

– Do you know the relationships and dependenciesbetween the business portfolio and IT assets?


TTaaccttiiccaall CCoonnttrroollUntil this point, the majority of the discussion has focused onhow BTM plays a crucial role in helping senior IT leaders governthe strategic direction of their enterprises, answering the ques-tion, “Are we doing the right things?” The other half of gover-nance is tactical control: “Are we doing the right things right?”Once strategic direction has been established and communicated,management needs to ensure that it is implemented in a way thatproduces the intended results. This quandary is reflected in thefact that nearly a third of all IT projects fail or are abandonedbefore completion. That adds up to a whole lot of waste.

Clearly, there are a multitude of reasons why projects fail. Somany so that I wouldn’t be able to address how to resolve them alland still do justice to the topic at hand. That said, this sectiondoesn’t conduct a “Project Management 101” lesson; nor is it a“Program Management for Dummies” primer. There are a numberof resources available in the form of associations, institutes, andpublished works that offer valuable assistance for the variousaspects of the project and program management disciplines. Thissection does, however, examine the intersection between thosedisciplines and BTM.

Quality is “Job #1”For years companies have worked hard to adopt and apply qualitymanagement techniques whose goal is to ensure that value-

186CHAPTER 8

– Can you explain your technology portfolio tobusiness management?

– Do you know where new vendor offerings fit andmay help you?

– How do you assess costs, risks, and the impact ofchanges before you commit to building systems?”

– Howard Smith, CTO, CSC Europe


creating activities are conducted in the most efficient and cost-effective manner possible. This formalized practice of modernquality management dates back to the early 1950s and W.Edwards Deming, Joseph M. Juran, and Armand V. Feigenbaum,whose work, in addition to contributions made by the Japanese(Dr. Kaoru Ishikawa, Dr. Genichi Taguchi, and Shigeo Shingo),resulted in the Total Quality Management (TQM) or TotalQuality Control (TQC) methodology. From there, a host of otherquality methods have evolved across industries and functions,starting in 1966 with Quality Function Deployment (QFD) inthe Japanese automobile industry and culminating more recentlyin 1988 with Motorola’s Six Sigma methodology. (Although, thattimeline could be extended out to 1994 with the introduction ofQS 9000 by the then big three automakers, Ford, GM, andDaimler-Chrysler.) So if you make use of Pareto and fishbonediagrams today, you can kindly thank Joseph M. Juran and Dr.Kaoru Ishikawa.

The underlying point here is not to advise that a companyshould run out and embrace a particular quality managementmethodology—the point is that companies have traditionallyinvested considerable time, resources, and money into figuringout how they can ensure that they are doing the right things right.Likewise, there should be mechanisms in place that help theminstitutionalize quality throughout their processes. Typically, com-panies formalize and/or enforce best practice quality methods bycreating standards; however, the difficulty often lies in embed-ding these standards in respective processes. This is especially truefor IT projects.

Much like the manufacturing product development process,IT projects are complex, with a myriad of inputs and outputsinvolved from the conceive and design stages on through thebuild, test, and deploy stages. As a consequence, there are a num-ber of opportunities for costly errors or inconsistencies to ariseduring the project life cycle. In response, project managers at var-ious levels rely on quality management techniques and standardsto get the job done right—meaning on time, on budget, andaccording to business requirements. These may be overarchingproject management standards such as those endorsed by the


187


Project Management Institute (PMI) or Six Sigma standards atthe business process level; or software engineering standards suchas the Capability Maturity Model (CMM); or still others that areproprietary and developed in-house. But how closely such stan-dards are followed depends on the ability of the organization toeffectively inject these standards into the daily workings of theseprojects. The far-flung realm of IT, in combination with the scaleand rapidity of the changes that IT is required to enact, make thisa formidable task for even the most efficient companies. At anygiven time in large organizations there are literally hundreds ofprojects in various stages of deployment, in which there are hun-dreds of individual resources assigned to thousands of tasks thatmust comply with prescribed standards. How can even the mostproficient project manager know or guarantee that these stan-dards are being adhered to? How can the resources assigned tothese projects be notified of these standards beyond traditionalmanagerial oversight?

Once again, the principles and activities of BTM play an inte-gral role—this time in facilitating the institutionalization of stan-dards. First, standards—whether they are component designstandards (e.g., Component Object Model [COM]), or engineer-ing methodology standards (e.g., MBase), or vendor-specific stan-dards (e.g., SAP solution map), or another variety—are capturedand codified in the business, process, and technology models pro-duced during the activities of BTM (see Fig. 8.4).

Incorporating standards in enterprise models is analogous toencapsulating the detailed information necessary to satisfy highlevels of quality compliance in the design specs for multi-phasedproduction of heavy machinery or automobiles. For example, ifyou are rolling out a large-scale enterprise software package tomultiple business units, you’d likely want to make sure that therollout is standard in each and every instance to reduce risk, con-tain costs, maintain scope and timetables, and consistently mapfunctional requirements to technology capabilities. In such a sce-nario, models would serve as the design specs for the IT initiative,enabling project teams to maintain consistent and repeatable lev-els of quality throughout each rollout. In the automobile manu-facturing world, design specs can indicate, for instance, what parts

188CHAPTER 8


should be used to guarantee that they are QS 9000 standard com-pliant; in the IT world, models can indicate what systems shouldbe used to conform to data-level security standards. If you fail tobuild a vehicle with QS 9000 compliant materials, then poten-tially you’ve failed to build a car that is safe or meets consumerneeds; if you fail to implement systems that conform to givensecurity standards, then potentially you’ve failed to deliver a sys-tem that can get the required data into end-user hands. Designspecs—and their BTM-equivalent models—keep designers andimplementers in sync with quality standards.

Once standards are defined in the models, they are communi-cated up-front to the various project team members in the form ofelement attributes, properties, requirements, process maps, appli-cation or system pictographs, and such. Despite the normal man-agement practice of regular meetings or the frequent release ofinternally documented guidelines, individual working groups


189

EJB COM/DCOM SOAP

Current Projects Using EJB

ConsolidationStrategicMaintenanceOperationsInnovation

Figure 8.4Standards (such as EJB) that are captured in models are can berolled up into the portfolio and provide the basis for analysis anddecision-making (such as determining what types of projectscurrently utilize EJB)


often fail to follow universal standards. Project plans, proceduralmemos or manuals, and meetings help to communicate informa-tion about standards, but the ability to reinforce this type ofknowledge is better provided by the models themselves.Traditional communication methods tend to fall short as theyare more static than models and therefore have a temporal effect.The unique visualization afforded by models, however, substan-tially increases each project participant’s awareness of (and ulti-mate adherence to) applicable standards at the time it countsmost in the process—during design and implementation. Byingraining standards in the models, project participants areexposed to this vital information on a day-to-day basis, resultingin contextual use at the activity level. Simply put, models makeinformation public knowledge, not tribal knowledge.

Finally, by following BTM’s principle of reusability, projectmanagers can make certain that even far-flung project teamsremain on the same page. They do this by creating and providingaccess to a repository of models that should be used as governingtemplates for upcoming projects. In this way, standards are glob-ally propagated across functional and physical geographies, pro-moting widespread adoption and use. This of course, can be ofparticular benefit when certain tasks are delegated to externalservice providers who may be located off-site from the project orwhose level of active involvement is irregular. Whether the proj-ect participant is internal or external, the use of templates helpsproject managers increase standards compliance, and by proxy,the derivative return that organizations receive on investment insuch methods.

A Dollar Saved Is…According to best practice approaches, quality management isonly one of several sub-disciplines belonging to the overall projectmanagement discipline. Likewise, cost management is one of several sub-disciplines belonging to the management of the proj-ect procurement process. Procurement management essentiallyfocuses on controlling the acquisition of the products and servicesthat are required to fulfill the objectives of the project. Cost man-

190CHAPTER 8


agement, in this regard, focuses on controlling costs so that theproject is completed within approved budget parameters. Modelsplay an integral role in the institutionalization of standards, so it iseasy to understand how they facilitate quality and cost manage-ment by:

– Reducing maverick spending to safeguard against improperprocurement

– Eliminating redundancies and waste to reduce or containcosts

Reduce Maverick SpendingThe rebuke that IT decision-makers sometimes receive from thebusiness side regarding inappropriate spending often stems fromincidents involving maverick purchases. These purchases are mav-erick in the sense that they involve non-approved vendors or serv-ice providers, don’t involve competitive solicitations, don’t followstringent vendor-selection criteria, don’t incorporate standard con-tract terms or clauses, and so on. Maverick spending is detrimentalin more than a few ways. Some of the most notable include disso-lution of corporate purchasing leverage, use of unqualified productsand services that quickly wind up consigned to the scrap heap,and unfavorable contract expenses and conditions.

It’s not that corporations hold a cavalier attitude toward pur-chasing or shrug off the responsibility of trying to prevent suchinstances of squander. Many corporations devote entire depart-ments to formalizing purchasing procedures for the express purposeof combating these errant expenditures. The problem is that theystill struggle to universally communicate and enforce these stan-dards. Guidelines and procedures prescribed in a five-inch thickbinder have a tendency to get lost in the organizational transla-tion process.

The last section explained how models codify and institu-tionalize quality and implementation standards. The same is truefor corporate purchasing standards. Through the use of models,project participants have immediate visibility and access to thesestandards at the most critical moment—during vendor evaluationand selection.


191


To illustrate what I mean, here’s a short example: The corpo-rate IT department for a large, multinational conglomerate determines that to save money on integration costs, all CRM proj-ects will be required to install a package from Vendor A. Toenforce this standard, the architects create templates that ear-mark elements pertaining to Vendor A’s offering (e.g., functionalrequirements, specifications, compatible operating systems andhardware, etc.) as the approved vendor. These templates thenbecome a part of the PMO’s repository for reuse on similar initia-tives. Subsequent use of these templates ensures that when a newCRM project is begun in any of the company’s business units,architects don’t deviate from the standards and Vendor A remainsthe selected provider. In this way, the models act as a powerfulmechanism for enforcing corporate purchasing standards and pre-serving spending integrity.

Eliminate Redundancies and WasteFrom a cost-management perspective, it is the program manager’sresponsibility to determine appropriate resource (physical, human)levels, develop cost estimations, allocate budget amounts to tasks,and control changes to cost structures.4 Bear in mind the scope ofthe task at hand—hundreds of projects running in parallel withhundreds of physical and human resources involved. The first stepin managing this process is to identify and eliminate redundanciesbetween projects. The decentralization of IT, mergers and acqui-sitions activity, and globalization are just a few of the major factorscontributing to the vast amount of redundancy that already existin many enterprises. New initiatives shouldn’t add to the currentlevel of waste; at the same time they should be used as opportuni-ties for right-sizing IT allocation.

Models are valuable tools here because they help to clearlyidentify elements that are currently shared or have the potentialto be shared between projects at the business, process, data, appli-cation, system, component, and functional requirement levels.It’s shocking, but more than a few organizations don’t really knowwhat resources they already have in-house and how they are beingutilized. I’m not talking about keyboards and mice here—I’m

192CHAPTER 8


talking about big-ticket items like rack-optimized servers or enter-prise software packages. Models contain dynamic linkages andreferences between elements that enable architects and managersto gain this critical insight. And, the depth of insight provided bythe models goes a long way toward promoting the reuse of func-tionalities, processes, and technologies that would otherwise goundiscovered. Through models, not only can project managershighlight and excise waste, they can also uncover opportunities tooptimize cost-benefit ratios.

TThhee AABBCCss ooff GGoovveerrnnaanncceeBy exercising strict governance over the strategic direction andtactical control of IT projects, CIOs can maximize the businessvalue of their IT investments. A portfolio approach gives seniortechnology executives, such as the CIO, a mechanism to aligninvestments with overall corporate strategy, and, where possible,exercise familiar, dollars-and-cents control over the somewhatpreviously inscrutable world of IT. Increasingly, IT is being askedto produce quick wins where the revenue distance (the lengthbetween the investment and the revenue producer it supports) isas short as possible. The natural tendency, therefore, is to focusmyopically on pure financial indicators such as ROI in lieu ofmore holistic indicators that incorporate a blend of both tangibleand intangible measures. Business and technology decision-makers must resist the temptation to overly emphasize thequantitative at the expense of the qualitative, lest they makeinappropriate assumptions regarding risk and value. The under-pinning data that portfolio analysts need to draw intelligentconclusions about the status and direction of an IT portfolio issupplied from the bottom-up, through the models that are createdduring the activities of BTM. In addition, these models help ITmanagers to reanalyze their investments with respect to current—not outdated—conditions and to communicate more effectivelywith their business counterparts during the budgetary process.


193


BTM’s principles and activities also ensure that IT projectmanagers maintain the same degree of control, accountability,and fiscal responsibility that is expected of projects in the rest ofthe business. In this manner, the CIO can feel confident that thepromises he or she makes when communicating the value of IT tothe business, come true when put into practice.

194CHAPTER 8


PPrroommiissee ttoo PPrraaccttiiccee

99

EVERY BUSINESS BOOK ASPIRES TO BE actionable in the enter-prise, and this one is no exception. But the transition from thewritten page to the real world can be tricky. In between the cov-ers of a book, ideas stand or fall on their merit alone. But in thereal world, these ideas demand that people—employees, cus-tomers, partners, whoever—act in certain, specific ways to makethem work. As a result, when many people are required to worktogether in pursuit of a single overarching goal, there’s often aconflict between an idea’s promise on the page and its practice inthe enterprise.

Until now, this book has focused on how companies can alignthemselves from the perspective of the activities of BTM and fromthe perspective of strategic direction and tactical control. But to


help you bridge the gap between promise and practice and getstarted with BTM in the real world, there’s another perspectivethat’s important as well: That of the people that make up theorganization. How should they—with all of their real-worldresponsibilities and competing priorities—tackle BTM?

So what’s the best way to take the ideas in this book and imple-ment them in your own organization? Remember that I’ve goneout of my way to emphasize that BTM isn’t a strict methodology.That’s important to mention since methodologies require peopleto perform specific tasks that may be different from the ones thatthey currently perform. This puts strain on the organization, and isone of the main reasons that a methodology may succeed in prom-ise but fail in practice: People can’t and shouldn’t be asked toturn on a dime to accommodate the latest management fad, espe-cially since there’s often a lot of knowledge and expertise builtinto the way things are currently done. But, at the other end ofthe spectrum, if people don’t change their behavior at all howcan we expect to do away with the conditions that lead to the dis-connect in the first place? This dilemma, in fact, points to a cen-tral question whose answer is crucial to understanding how theorganization should view BTM: Is it an art or science?

AArrtt VVeerrssuuss SScciieenncceeThe fact that BTM relies upon interconnected models should tipyou off that the unspecified genius of an artist isn’t consistentenough to solve the disconnect. But, on the other hand, BTMdoesn’t try to shoehorn very different organizations into the samestrict, step-by-step procedure the way a methodology does. Theright place to locate BTM on the art/science spectrum is some-where between the two extremes: It provides just enough structurewithout checking the individuality that each employee brings tothe job. This is why I described BTM as an approach that alignsbusiness and technology rather than a methodology or someamorphous “ten secrets of alignment.” The latter relies on too sci-ence while the former leans too heavily on art.

196CHAPTER 9


RRoolleess aanndd RReessppoonnssiibbiilliittiieessSo given this balancing act between art and science, what’s thebest way for the organization to approach BTM? Chapter Twoemphasized that it is the office of the CIO that needs to take ulti-mate responsibility for alignment. This statement is true as far asit goes. But by now it should be clear that the cast of charactersthat contributes to business model definition, process optimiza-tion, and technology automation extends far beyond any one per-son and his or her immediate staff. In BTM, to make the jumpfrom promise to practice, you should consider the five generalroles and responsibilities shown in Fig. 9.1.

Promise to Practice

197

�

A Recipe for BTM

“Is a recipe art or science? It’s science to some degree,since it includes measurements, temperatures, and cook-ing times, but there’s also an art to it. If two people fol-lowed the same recipe would they come out with exactlythe same outcome? A more accurate way to frame thequestion might be to ask whether it’s a bad thing if twopeople cook the same recipe and the results differ slightlybut are equally delicious?

One way to look at BTM is as a recipe which, if inter-nalized by the CIO and senior IT staff, can help to enablethe scientific aspects of their responsibilities more effi-ciently and effectively. But there still is that other, creativeside that includes who are you as a person or leader? Whatare your values? And how well do you communicate theissues and opportunities that emanate from IT to yourpeers in the business? It’s not realistic, in other words, toexpect everybody to approach alignment in exactly thesame way; we’re not little robots or clones. But at the sametime you need a recipe, and BTM provides that.”

– Tom Trainer, former CIO, Citigroup, Inc.; Eli Lilly &Co.; and Reebok International, Ltd.; chairman of theExecutive Committee, enamics, Inc.


– The CxO Suite, including the CEO, CFO, COO, and otherbusiness unit heads, which is responsible for understandingthe impact that IT has on the business so they can makeinvestment decisions accordingly, achieving general visibil-ity into IT portfolios and projects, and setting the examplefor how the firm as a whole should view the IT function.

– The Office of the CIO, which is responsible for identifyingbroad opportunities for using technology to innovate thebusiness, managing the IT portfolio, and overseeing risk andgeneral governance of IT.

– The Project/Program Management Office, or PMO, whichis responsible for controls, prioritization, consolidation, andstandards that span individual projects and programs.

198CHAPTER 9

CxO Suite

Project/ProgramMgmt. Office

Office ofthe CIO

TechnologyProfessionals

Business Professionals

Figure 9.1Five roles and responsibilities help BTM make the jump frompromise to practice: the CxO suite, the office of the CIO, theproject/program management office (PMO), business professionals,and technology professionals


– Business Professionals, who are responsible for contributingbusiness and process expertise to the activities of BTM,including visualizing and understanding the impact of IT,and for managing operational change.

– Technology Professionals, who are responsible for designingapplications and systems, coordinating with business profes-sionals to validate IT decisions, implementing the finaldesign, and managing technology change.

CxO SuiteThe CxO suite should assume three responsibilities that arerelated to BTM. First, they need to make smart IT investmentdecisions by understanding how technology impacts the business.They need this technology acumen for the same reason that theCIO needs to understand the impact of business decisions: tounderstand IT’s transformational capabilities and to allocate fundsaccordingly. Understanding the impact of IT will help the CxOsuite communicate their vision and goals for the company to boththeir IT colleagues and also to the board of directors—who shouldbe aware of how the CxO suite intends to leverage the company’sconsiderable IT investments to increase shareholder value.

The second responsibility of the CxO suite is to achieve gen-eral visibility into IT—to take the general pulse of IT programsand projects, in other words. Without the integrated view of theIT portfolio (supported by business, process, and technology mod-els) that is advocated by BTM, it is difficult for the CxO suite (orany other members of the general business audience, for that mat-ter) to become familiar with the basic workings of IT. Throughoutthe entire cycle from a project’s conception to rollout, the modelsdeveloped during the activities of BTM improve visibility intoIT, which is crucial for collaborating to develop a shared visionwith the CIO. In a broader sense, improving visibility into andcommunication with IT is really the core of BTM, since translat-ing between stakeholders who speak fundamentally different lan-guages—such as the CxO suite and the IT function in general—isa huge part of closing the disconnect.

The final responsibility of the CxO suite is to set an examplefor how the business should view IT, and create an environment in

Promise to Practice

199


which the CIO and IT can succeed. Surveys show that 78% ofCIOs still earn grades of D– or F with their companies because“they are perceived to be functioning as commodity-based ‘ordertakers’”1 rather than as strategic partners. To improve this mark,CxOs should include the CIO as an active, visible, and empow-ered member of the executive team. This may require changingtraditional reporting structures and turning over some discre-tionary powers regarding budget issues. By including the CIO inboth short-term and long-term strategic planning sessions, theCxO suite promotes the early integration of technology into thecompany’s goals, and a joint agenda that will reduce risk andincrease return.

Behavior and culture also come from the top down, and theorganization looks to the CEO to indicate what the company’sattitude is towards IT. (This focus could be extended to the entireCxO suite, but it is the CEO who ultimately sets the overarchingcultural tone.) Unfortunately, there are still a number of CEOsthat either choose to shun this responsibility or are not equippedto respond appropriately. Michael Earl, director of LondonBusiness School’s Centre for Research in Information Manage-ment, and David Feeny, director of The Oxford Institute ofInformation Management and vice president of TempletonCollege, group the IT management styles of CEOs into sevenarchetypes in their Sloan Management Review article, “How ToBe a CEO for the Information Age” (see Table 9.1).

Only one archetype, “The Believer,” actually combines theright behaviors and attitudes that help companies reap the rewardsthey expect out of technology. But even today, few CEOs actuallyqualify for inclusion in this category.2 Without strong CEO spon-sorship of the IT role in their organizations, the CxO suite andcompanies in general are destined to perpetuate the behaviorsand attitudes that thwart alignment and organizational success.

Office of the CIOThe next role that must tackle BTM is the office of the CIO. TheCIO, as Ch. 2 discusses, is ultimately responsible for alignmentbetween business and technology. This means that it is essential tomake the CIO and his or her office the BTM champion within

200CHAPTER 9


the organization. Typically, it is the office of the CIO who com-bines high-level strategies and priorities from the CxO suite withemerging technology trends to identify concrete IT programs andprojects. The mechanism that the CIO uses to make these crucialdecisions is the IT portfolio, which Ch. 8 describes. By managingthis portfolio, the office of the CIO can keep tabs on overallinvestment and risk, and provide a unifying authority for govern-ing IT.

But the CIO’s interaction with the CxO suite needs to run theother way as well. The CIO should participate in developingoverall corporate strategy by identifying opportunities for ITinnovation, and bringing these to the CxO suite. Again, modelsand the IT portfolio are important mechanisms here, becausethey help the office of the CIO identify trends, and more impor-tantly, explain trends in everyday terms to their counterpartswithin the business.

Promise to Practice

201

AttributesArchetype

The Seven Creeds of the CEO

The Hypocrite Espouses strategic importance of IT but negates belief through personal action

The Waverer Reluctantly accepts strategic importance of IT but is not ready to get involved in IT matters

The Atheist Convinced that IT is of little value and publicly espouses this belief

The Zealot Convinced IT is strategically important and equally believes he is an IT expert

The Agnostic Concedes IT is strategically important but needs repeated convincing

The Monarch Accepts IT is strategically important, appoints the best CIO, andsteps back

The Believer Believes IT enables strategic advantage and demonstrates belief through action

Table 9.1The seven creeds of the CEO: hypocrite, waverer, atheist, zealot,agnostic, monarch, and believer


Despite the well-recognized trend in the industry for CIOs tobecome strategic partners in the business, many companies stillleave IT out in the cold when it comes time to set strategies anddetermine goals. This especially happens when the CIO’s subor-dinate position is institutionalized by unit pricing or charge-backsystems, whereby the business pays for IT services. This is the

202CHAPTER 9

�

Thinking Like a CEO

“One of the most significant changes in the last five yearsis because of the rapid proliferation of technology. TheCIO definitely emerged at the forefront of the businesstable and has become the epicenter of the organization.Conversely, CEOs have become extraordinarily moretechnology savvy because they realize that effective use oftechnology whether it’s insourced or outsourced is goingto directly affect the bottom line. And so the role haschanged whereby the CIO is now viewed as a strategicbusiness partner. All of the things that a CEO thinksabout—acquisitions, divestitures, organic growth—theCIO needs to think about too.

What is required is for the CIO to be much more savvyabout where he spends his time, his money, and hisefforts. There is virtually no other function in any Global1000 organization that has a larger capital and expensebudget than the CIO. So in reality the CIO ultimately has the largest piece of business, virtually larger than anyother stakeholder or executive in a corporation. It’scaused the CIO to be much more business oriented, focusing on things like growing the top line, controllingthe bottom line, margins, and expenses.

So the CIOs that are not strategic, that are not busi-ness partners, that are not aligned—those guys are getting‘sunset-ed’ in the marketplace.”

– Paul Daversa, president & CEO, Resource Systems Group


right step if you buy into the argument that IT needs to become aprofit center, but it’s the wrong approach if you want IT to beaccepted as integral to the organization just like other functionssuch as manufacturing, sales, and marketing.

Project/Program Management Office (PMO)The next crucial role is that of the project/program managementoffice, or PMO. After the office of the CIO has identified newprojects to meet the strategic objectives of the enterprise, theyshould coordinate with the PMO to monitor, track, prioritize, andretain broad tactical control over these projects. The PMO, whichcan be organized as either an engaged internal consultancy ora hands-off repository of best practices and general project infor-mation, reports either to senior IT executives or to a joint steeringcommittee composed of business and IT leaders. The steeringcommittee is typically assembled in response to a specific ini-tiative, and includes members with a direct stake in that initia-tive’s success. For example, the PMO tasked with a CRMinitiative may report to a steering committee that consists of theCIO, vice president of Marketing, the CFO, and senior represen-tatives of the sales and support functions.

As projects move from concept to completion, the PMO peri-odically re-evaluates them to make sure that they remain on-trackto meet their initial promise. Both leading and lagging indicatorsof the project’s performance can trigger these re-evaluations.During each, the enterprise model helps to communicate progressand gives the IT steering committee the information they need tomake accurate and timely decisions about the initiative’s fate.After a project has been implemented successfully, the PMO rollsup design decisions made during impact analysis into a centralrepository of best-practice templates and company standards.These design decisions, which are the basis for reuse in BTM, cantake the form of standard processes, approved application pack-ages, network and technology configurations, or even complete,end-to-end project designs that can be reused in later initiatives.The PMO also helps to prioritize individual projects and tasks, sothat resources in limited supply (whether that means a specializedprogrammer, network bandwidth, or database storage space) can

Promise to Practice

203


be allocated intelligently to maximize their benefit to the enter-prise. Other key responsibilities of the PMO are to select a projectmanager, define project methodologies, secure funding, assignresources, and engage service providers for IT projects.

Business ProfessionalsThe fourth and fifth roles that are responsible for BTM—businessand technology professionals—collaborate closely to complete theactivities of BTM. The process starts with the capture of an as-isenterprise model, continues as companies develop potential to-bescenarios and perform gap analysis between the to-be and as-isstates, and concludes when a final to-be scenario is selected andmoved along to implementation. Every scenario should includethree general areas—business, process, and technology—each ofwhich corresponds directly to one of the activities of BTM: busi-ness model definition, process optimization, and technologyautomation.

Business professionals, of course, are more directly concernedwith the first two of these activities, and their expertise and in-depth knowledge of the subject matter should form the basis fordeveloping the business and process models that make up thebusiness architecture. But at the same time, business professionalsshould be familiar with technology automation so that they canunderstand the impact of IT and visualize how new and updatedapplications and systems impact how they do their job.

One final—and often overlooked—responsibility of businessprofessionals is to manage the operational change that is requiredto take advantage of updates to the technology architecture. Forexample, a new supply chain management system may requiredemand planners to adjust how they work. In this case, the busi-ness professionals need to make sure that these changes take place(through the use of incentives, training, or creating new posi-tions, for example).

Technology ProfessionalsThe final role that is responsible for BTM is technology profes-sionals, who can be either internal resources from the IT depart-ment or external service providers. Technology professionals are

204CHAPTER 9


responsible primarily for designing and implementing the tech-nology architecture, which includes the applications and sys-tems that are modeled during technology automation. But, atthe same time, they need to work with business professionals tovalidate the impact of IT decisions and make sure that the tech-nology architecture matches back to the company’s businessneeds and objectives.

Technology professionals, including developers, system ana-lysts, and other specialists, are frequently responsible for imple-menting the final project as well. Once a project receives fundingand moves into implementation, the to-be enterprise model devel-oped during the activities of BTM becomes a reference pointwhich helps to make sure that the project stays true to its initialbusiness goals. One other advantage that the enterprise modelprovides during this stage is that it helps to improve decision-making when the development team faces unexpected butinevitable design changes. In the past, these changes would havebeen made on a piecemeal basis. But BTM makes it realistic to doend-to-end impact analysis for almost any modification, so thateven last-minute technology changes are made with the overallgood of the project in mind.

CCoooorrddiinnaattiinngg BBeettwweeeenn RRoolleess aanndd RReessppoonnssiibbiilliittiieess

Obviously, these five roles and responsibilities impact a broadrange of people (from the executive suite on down to technicaldevelopers) and tasks (from overall corporate strategy to detaileddesign decisions and technology implementation). Coordinatingbetween these people and tasks so that the whole train stays onthe tracks is one of the major challenges that every organizationfaces when working with BTM. In order to put BTM’s principles,activities, and governance to work, companies need a formalizedmanagement infrastructure to facilitate this coordination betweeneach of the roles and responsibilities.

Promise to Practice

205


In the past, some argued for software solutions like groupwareor corporate portals to play this role, others claimed that all com-panies needed was a good spate of team-building exercises todevelop the lacking connections, while still others praised bal-anced scorecards. These are, respectfully, useful communicationmediums, HR techniques, and performance measurement tactics,but they aren’t specifically designed for the range of interactionsbetween the CxO suite, the office of the CIO, the PMO, businessprofessionals, and technology professionals that are necessary tohelp BTM make the jump from promise to practice. Althoughcompanies appear to recognize that there needs to be some mid-dleman between each of these players, British American Tobacco’sKevin Poulter observes that most companies still don’t have aninfrastructure dedicated to that goal in the same way that theyhave infrastructures for other parts of the business.

One of the things of which I am a strong proponent is that weapproach IT as a significant function in the organization thatneeds an infrastructure to automate interactions and decisionsjust the same way as operations or marketing. All of thosefunctions have their own systems to support their operations.For example, in our business, the marketing function is respon-sible for managing a portfolio of brands and operations isresponsible for managing a portfolio of manufacturing capabili-ties. Similarly, IT is responsible for managing a portfolio ofapplications and increasingly so, business services. In a lot ofmajor organizations, operations and the marketing portfoliosare supported quite well by information technology. But find-ing organizations that actually support their IT managementfunction using IT is somewhat less common. You could almostsay that the corporate IT department suffers from the “cobbler’schildren have no shoes” syndrome.

Although the overall effort to get BTM to work in the enter-prise is shared between the five general roles, the primary respon-sibility and accountability for putting an infrastructure in place tofacilitate this communication and collaboration resides with theoffice of the CIO. Today, most CIOs lack a management infra-structure that is analogous to those that are commonly available to

206CHAPTER 9


their business counterparts—CFOs and financial planners havefinancial modeling and analysis tools, sales and marketing execu-tives rely on sales force automation (SFA) and CRM infrastruc-tures, and manufacturing professionals have SCM at their disposal.These other functions are made more efficient and productive bysupporting management infrastructures—after all, I wouldn’trefute that just-in-time (JIT) manufacturing is made more feasiblebecause of SCM technologies—so it’s logical to demand that IT besupported in equal fashion.

YYoouurr OOwwnn UUnniiqquuee CCoonnttrriibbuuttiioonnNo matter which type of infrastructure you use to coordinatebetween these roles and responsibilities, you should feel free to addas many of your own contributions as it takes to make BTM workin your organization, just like master chefs might add a secretingredient or two to give a familiar recipe their own unique flair.For example, since business and technology professionals are pri-marily charged with carrying out the activities of BTM, one of thethings that they have to be able to do is predictive modeling. Butin describing these two crucial roles and responsibilities, I don’tsay anything in particular about how they should go about doingthis. Should they develop models using dedicated software, a sim-ple drawing program, or old-fashioned pencil and paper? Thereisn’t any right or wrong answer—this doesn’t mean that everychoice is equally good, but it does mean that BTM doesn’t makethe decision for you. Any number of specific approaches couldwork to meet each of the responsibilities described in this chapter,and each organization’s own unique needs should dictate whichthey choose.

The combination of basic roles and responsibilities with theflexibility of your own unique contribution is the basis for balanc-ing between art and science, and for making BTM make the jumpfrom promise to practice. This balance is one of BTM’s primarybenefits and at the same time one of the reasons that previousattempts to align business and technology have failed. Translating

Promise to Practice

207


an idea on paper to a solution in the real world is always compli-cated, and detailed matrices, frameworks, and methodologies thatlook brilliant in the classroom often seem rigid and impracticalwhen placed in the context of a real enterprise. But by rejecting aconfining, end-to-end procedure for getting started in favor ofgeneral roles and responsibilities around which you can fill in thegaps however you see fit, BTM makes it more likely that your ITinitiatives will look as good in the real world as they do on paper.And in the end, of course, that’s the only thing that matters.

208CHAPTER 9


CCoonncclluussiioonn

TODAY, TOO MANY IT PROFESSIONALS are overwhelmed orintimidated by the foreign world of business, while many businessprofessionals view IT as a tangle of incomprehensible ones andzeros. As a result, IT remains shrouded from the rest of the busi-ness in a way that is unlike any other function. I frequently dis-cuss this persistent struggle to demystify the black-box mentalitysurrounding technology with my friend and colleague, TomTrainer. As the former CIO of industry giants such as Citigroup,Eli Lilly, and Reebok, Tom has experienced the struggle firsthand.His remarks on the subject struck me as more befitting of a con-clusion for this book than I could ever pen:

When’s the last time you saw a $50 or $75 million marketingcampaign where other major functions of the business didn’thave top-to-bottom visibility into what was going on? Nomanagement team would ever agree to fund a $75 million

Conclusion_FINAL.qxd 7/25/2002 4:01 PM Page 209

Super Bowl ad campaign and then just switch on the TV athalftime and hope they got it right. But that still happens allthe time for IT projects with even bigger price tags than that.

Businesses are sick and tired of spending big-time money ontechnology without getting value. Right or wrong, there’s beena long-standing perception, particularly among large companieswho spend a large amount of money on IT, that IT is a chronicunderachiever that promises the world but reliably fails todeliver. And, unfortunately, there are too many stories thatreinforce that perception—stories about ERP initiatives spiral-ing out of control, about failed supply chain platforms thatcause devastating inventory shortages, or about million dollarsoftware that goes unused.

CIOs themselves recognize that the salad days are over andthey’re going to be scrutinized like never before. They have toact like any other function that has a seat at the CEO’s tableand describe not only where the money went in plain, under-standable terms, but more important, why it went where it did.Generally, other functional managers and the CEOs don’t getenough visibility into what’s going on in IT. It’s not necessarythat they understand every single aspect of technology, the bitsand bytes and all that. What is necessary is that they are ableto understand all the possible impacts (positive and negative)that technology can have on the business.

I find it amazing that the industry hasn’t realized before nowthat something better change when we start spending on ITagain. It’s like the elephant in the corner—nobody wantsto talk about it. Well now people are going to start talkingabout it a lot more loudly and I think that an approach like BTM, as outlined in this book, is arriving at preciselythe right time.

210Conclusion


There is absolutely a need for a repeatable infrastructure or setof management capabilities that will help companies close thedisconnect between business and technology. It’s a capabilitywhose time has come. When the tide’s in and companies startspending again, I don’t think businesses will be falling overthemselves to throw money at IT anymore without a set ofcapabilities that allows them to get real value out of technol-ogy. The combination of principles, activities, and governancethat makes up BTM will help them to do just that.

If I have learned one truism over the last 34 years of my career,it is this: Unless something fundamentally different starts tohappen, individual enterprises are going to be as they were yes-terday and last year and five years before that. And I don’tbelieve there’s a single company that can afford that.

Conclusion

211


AAlliiggnnmmeenntt MMaattuurriittyy MMooddeell

AAPPPPEENNDDIIXX

IT’S COMMON PRACTICE FOR MOST OF US when we encounter aproblem to seek a diagnosis that will tell us the nature, cause, andextent of the difficulty. When we have a medical problem, we goto the doctor knowing that he will examine us and potentially runa series of tests to ascertain what ails us. We do the same thingwhen we experience car trouble and turn to the mechanic whomwe expect will check under the hood or the chassis to properlyinspect the vehicle so that he can determine the source of thetrouble. And we do the same thing yet again when we encountercomputer difficulties, soliciting the analysis of technical supportrepresentatives whom we know from experience will run usthrough a series of probing questions to arrive at the root cause. Itshouldn’t be hard, therefore, to conclude that in business weshould follow the same practice.

Appendix_FINAL.qxd 7/25/2002 4:10 PM Page 213

If one looks at the statistics and surveys of the top researchfirms, they indicate that most companies believe they have analignment problem that needs remedying.1 These companies have,at the very least, a general sense of the nature of the problem andsome undoubtedly may already know the precise root cause. Butthe majority of companies still don’t know the full extent of theproblem nor do they agree internally on what the problem is orunderstand the reason why it has occurred. Ask a dozen differentexecutives and managers from various areas of the organizationabout their opinion as to whether or not business and technologyare aligned, and you are bound to receive a dozen differingresponses. It’s the influence of mental models, again, that makes itdifficult for business and IT leaders to achieve consensus. Whatthese two sides need is a formal mechanism, which will help themobjectively diagnose and agree on the level of their alignment.

GGeettttiinngg aann AAccccuurraattee RReeaaddThere are various means by which companies can assess their align-ment, however, the most comprehensive of these methods is theStrategic Alignment Maturity Model, developed by Dr. JerryLuftman, Distinguished Service Professor, of the Stevens Instituteof Technology. Based on a multi-year research study of Global 2000companies and his own two decades of practical experience as anIT professional, Luftman created this diagnostic tool to help organ-izations measure their alignment maturity.2 According to Luftman:

It is extremely important to recognize what the business thinksabout the relationship as well as what IT thinks about the rela-tionship, and then where they both agree that there are prob-lems/opportunities that should be addressed. Firms must haveIT and business executives working together to address thesealignment issues because both organizations tend to see theworld very differently. So the focus is on finding out where thefirm is by formally taking a look at what can be done to make itbetter. This includes an internal assessment as well as bench-marking against other firms.

214APPENDIX


The Strategic Alignment Maturity Model is patterned afterthe Capability Maturity Model (CMM), which was designed byCarnegie Mellon University’s Software Engineering Institute tohelp organizations measure and improve the maturity of their soft-ware development processes. In a similar fashion to CMM, butfocusing on a much higher level of the company, the alignmentassessment includes five levels of maturity. Companies aredescribed from the weakest Level 1—those that lack the processesand relationships needed to attain alignment—to Level 5, thestrongest, where IT and other business functions (marketing,finance, R&D, etc) adapt their strategies together using fullydeveloped processes that include external partners and customers.The evaluation criteria between the two are understandably quitedifferent. Dr. Luftman’s model focuses on six key criteria essentialfor the assessment and diagnosis of business/IT alignment: com-munications, metrics, governance, partnership, technology, andhuman resources. Each of the criteria is described by a set of attrib-utes, as shown in Fig. A.1.3

A team of both business and IT leaders assesses the six criteriaand sub components, using the results to converge on an overallassessment level of the firm’s maturity. The approach focuses onunderstanding the alignment maturity and on maximizing align-ment enablers and minimizing inhibitors. To help quantify per-ceptions, the attributes for each criterion are evaluated accordingto a Likert scale rating method of 1 – 5 (typically expressed as arange from strongly disagree to strongly agree). By examiningcomponents of the business/IT relationship through such a frame-work, both sides can objectively assess and then mutually agreeupon their level of alignment maturity. Business and IT leaderscan then use the diagnostic results of the assessment to betterunderstand what areas require improvement and why.

RReegguullaarrllyy SScchheedduulleedd CChheecckk-uupp How often a company assesses its business/technology alignmentdepends on the individual nature of the organization. Certainly, it

Alignment Maturiity Model

215


would be impractical to stop and assess the level of alignmentmaturity before the start or end of every project. However, theassessment frequency could occur on an annual schedule, or couldeven match the company’s strategic planning cycles. It may benecessary to conduct alignment checks on a more frequent basiswhen there is a significant degree of misalignment and then thecompany could shift to longer intervals between checks once thehighest level of alignment maturity has been attained. Anytimecorrective steps are determined and agreed upon pursuant to anassessment, these should be mapped against current/planned strate-gies, organizational/operational capabilities, and environmentalconditions so that actions are not formulated and executed in avacuum. Alignment is not a one-time or isolated event—it shouldbe part and parcel of the company’s strategy and operations.

216APPENDIX



217


218

Understanding of Businessby IT

Understanding of IT by Business

Organizational Learning

Style and Ease of Access

Leveraging Intellectual Assets

IT/Business Liaison Staff

IT management lacks understanding

Managers lack understanding

Casual conversation and meetings

Business to IT only; formal

Ad hoc

None or use only as needed

LEVEL 1Initial/Ad Hoc Process

Limited understanding by IT management

Limited understanding by managers

Newsletters, reports, group email

One-way, somewhat informal

Some structured sharing emerging

Primary IT/Business link

LEVEL 2Committed Process

COMMUNICATION

IT Metrics

Business Metrics

Link Between IT and Business Metrics

Service Level Agreements

Benchmarking

Formally Assess IT Investments

Continuous Improvement Practices

Technical only

IT investments measured rarely, if ever

Value of IT investments rarely measured

Use sporadically

Seldom or never

Don’t assess

None

Technical, cost; metrics rarely reviewed

Cost/unit; rarely reviewed

Business, IT metrics not linked

With units for technology performance

Sometimes benchmark informally

Only when there’s a problem

Few; effectiveness not measured

METRICS

Figure A.1

Dr. Jerry Luftman’s Strategic Alignment Maturity Model measuresalignment according to six criteria: communications, metrics,governance, partnership, technology, and human resources.

APPENDIX



219

Good understanding by IT management

Good understanding by managers

Training, departmental meetings

Two-way, formal

Structured around key processes

Facilitate knowledge transfer

LEVEL 3Established Focused Process

Understanding encouraged among IT staff

Understanding encouraged among staff

Formal methods sponsored by senior management

Two-way, somewhat informal

Formal sharing at all levels

Facilitate relationship-building

LEVEL 4Improved/Managed Process

Understanding required of all IT staff

Understanding required of staff

Learning monitored for effectiveness

Two-way, informal and flexible

Formal sharing with partners

Build relationship with partners

LEVEL 5Optimized Process

Review, act on technical, ROI metrics

Review, act on ROI, cost

Business, IT metrics becoming linked

With units; becoming enterprise-wide

May benchmark formally, seldom act

Becoming a routine occurrence

Few, starting to measure effectiveness

Also measure effectiveness

Also measure customer value

Formally linked; reviewed and acted upon

Enterprise-wide

Routinely benchmark, usually act

Routinely assess and act on findings

Many, frequently measure effectiveness

Also measure business opportunities, HR, partners

Balanced scorecard, includes partners

Balanced scorecard, includes partners

Includes partners

Routinely benchmark, act, and measure results

Routinely assess, act, and measure results

Practices and measures well-established


220APPENDIX

Formal Business Strategy Planning

Formal IT Strategy Planning

Organization Structure

Reporting Relationship

How IT is Budgeted

Rationale for IT Spending

Senior-level IT Steering Committee(s)

How Projects are Prioritized

Not done, or done as needed

Not done, or done as needed

Centralized or decentralized

CIO reports to CFO

Cost center; spending is unpredictable

Reduce costs

Don’t have

React to business or IT need

At unit functional level; slight IT input

At unit level; slight business input

Centralized or decen-tralized; some co-location

CIO reports to CFO

Cost center by unit

Productivity, efficiency

Meet informally as needed

Determined by IT function

GOVERNANCE

Business Perception of IT

IT’s Role in Strategic Business Planning

Shared Risks and Rewards

Managing the IT/Business Relationship

Relationship/Trust Style

Business Sponsors/Champions

Cost of doing business

Not involved

IT takes all the risks, receives no rewards

IT/Business relationshipisn’t managed

Conflict and mistrust

Usually none

Becoming an asset

Enables business processes

IT takes most risks with little reward

Managed on ad hoc basis

Transactional relationship

Often have a senior IT sponsor/champion

PARTNERSHIP



Figure A.1 (continued)



221

Some IT input and cross-functional planning

Some business input and cross-functional planning

Centralized, decentralized or federal

CIO reports to COO

Some projects treated as investments

Also a process enabler

Formal committees meet regularly

Determined by business function

At unit and enterprise, with IT

At unit and enterprise, with business

Federal

CIO reports to COO or CEO

IT treated as investment

Process driver, strategy enabler

Proven to be effective

Mutually determined

With IT and partners

With partners

Federal

CIO reports to CEO

Profit center

Competitive advantage, profit

Also includes external partners

Partners’ priorities are considered

Enables future business activity

Drives business processes

IT/Business start sharing risks, rewards

Processes exist but not always followed

IT becoming a valued service provider

IT and business sponsor/champion at unit level

Drives future business activity

Enables or drives business strategy

Risks, rewards always shared

Processes exist and complied with

Long-term partnership

Business sponsor/champion at corporate level

Partner with business in creating value

IT/Business adapt quickly to change

Managers are given incentive to take risks

Processes are continuously improved

Partner, trusted vendor of IT services

CEO is the business sponsor/champion





222APPENDIX

Primary Systems

Standards

Architectural Integration

How IT Infrastructure is Perceived

Traditional office support

None or not enforced

Not well integrated

A utility; run at a minimum cost

Transaction oriented

Defined, enforced at functional level

Within unit

Becoming driven by business strategy

TECHNOLOGY

Innovative, Entrepreneurial Environment

Key IT HR Decision Maker(s)

Change Readiness

Career-Crossover Opportunities

Cross-Functional Training and Job Rotation

Social Interaction

Attract and Retain Top Talent

Discouraged

Top business and IT man-agement at corporate level

Tend to resist change

Job transfers rarely occur

No opportunities

Minimal IT/Business interaction

No retention program; poor recruiting

Somewhat encouraged at unit level

Same, with emerging functional influence

Change readiness programs emerging

Occasionally occur within unit

Decided by units

Strictly a business-only relationship

IT hiring focused on technical skills

HUMAN RESOURCES



Figure A.1 (continued)



223

Business process enabler

Emerging coordination across functions

Integrated across functions

Driven by business strategy

Business process driver

Defined, enforced across functions

Begins to be integrated with partners

Beginning to help business respond to change

Business strategy enabler/driver

Also coordinated with partners

Integrated with partners

Enables fast response to changing market

Strongly encouraged at unit level

Top business and unit management; IT advises

Programs in place at functional level

Regularly occur for unit management

Formal programs run by all units

Trust and confidence is starting

Technology and business focus; retention program

Also at corporate level

Top business and IT management across firm

Programs in place at corporate level

Regularly occur at all unit levels

Also across enterprise

Trust and confidence achieved

Formal program for hiring and retaining

Also with partners

Top management across firm and partners

Also proactive and anticipate change

Also at corporate level

Also with partners

Attained with customers and partners

Effective program for hiring and retaining





RReeffeerreenncceess

Chapter Two1 Lepore, Dawn. “Are CIO’s Obsolete?” HSB Working Knowledge, October

23, 2000. [Online: http://hbsworkingknowledge.hbs.edu/item.jhtml?id=1748&t=operations&sid=1749&pid=0]

2 Poe, Jonathan. “The Negative Impact of Failed IT Initiatives.” METAGroup Research Note section, February 1, 2002. [Online:http://www.metagroup.com/metabits/mbDl0509.html]

Chapter Three1 Jacobs, Peter K. “A Class Inspiration Returns to HBS.” HBS Working

Knowledge, January 18, 2000. [Online: http://hbsworkingknowledge.hbs.edu/pubitem.jhtml?id=1271&sid=-1&t=topic%3Dentrepreneurship]

References_FINAL.qxd 7/25/2002 4:12 PM Page 225

2 The Wharton School of the University of Pennsylvania. “MeasuringReturns on IT Investments: Some Tools and Techniques.” From theManaging Technology section of the Knowledge@Wharton newsletter.[Online: http://knowledge.wharton.upenn.edu/articles.cfm?catid=14&articleid=396&homepage=yes]

3 Schrage, Michael. An excerpt from his book, Serious Play: How theWorld’s Best Companies Simulate to Innovate (Harvard Business SchoolPress, 2000). In “Playing for Keeps.” CIO.com, June 15, 2000. [Online:http://www.cio.com/archive/061500_new.html]

4 Hansen, Morten T. and Bolko von Oetinger. Introducing T-ShapedManagers: Knowledge Management’s Next Generation (Harvard BusinessSchool of Publishing). From the Product Overview page of the HarvardBusiness Review Web site, March 01, 2001. [Online: http://www.hbsp.harvard.edu/products/hbr/mar01/R0103G.html]

5 Mahowald, Robert. “From ICE Age To Contextual Collaboration.” Fromthe Analyst Corner section of CIO.com, June 29, 2001. [Online:http://www.cio.com/analyst/062901_idc.html]

Chapter Four1 Bairstow, Lynne. “Collaboration.” e-com, June 2001. [Online:

https://www.e-commag.com/]

Chapter Five1 Passori, Al. “Value at Stake: Making the IT Investment Portfolio Lean

and Well Done.” META Group Research Note section, ExecutiveDirections, Delta 186, September 7, 2001. [Online: http://www.metagroup.com/cgi-bin/inetcgi/search/displayArticle.jsp?oid=26355 ]

Chapter Six1 For more information on the LOVEM notation, refer to Soper, Paulette.

Business Process Reengineering and Beyond. IBM International TechnicalSupport Organization. December 18, 1995. Information regarding otherprocess definitions can be found in the following report: Bristow, David J.et al. Process Definition Guidebook. Lockheed Martin Federal SystemsReport, May 12, 1997.

2 Zachman, John A. Concepts of The Framework for Enterprise Architecture:Background, Description, and Utility (Zachman International: 1996).

3 Spewak, Dr. Steven H. and Hill, Stephen C. Enterprise ArchitecturePlanning: Developing a Blueprint for Data, Applications, and Technology(John Wiley & Sons: September, 1993).

226References


Chapter Seven1 Lynn, Doug. “Can’t Plan (Course of Action) Without a Map.” META

Group Research Note section, Executive Directions, Delta 250,November 15, 2001. [Online: http://www.metagroup.com/cgi-bin/inetcgi/search/displayArticle.jsp?oid=27581]

2 Handler, Robert. “Leveraging Architecture to Mitigate Issues and Risks With Outsourcing (Revisited).” META Group Research Note section, Executive Directions, Delta 131, August 27, 2001. [Online: http://www.metagroup.com/cgi-bin/inetcgi/search/displayArticle.jsp?oid=26152]

Chapter Eight1 Rubin, Dr. Howard. “Doing The ROIght Stuff,” InformationWeek,

August 6, 2001. [Online: http://www.informationweek.com/story/IWK20010802S0012]

2 Popper, Charles. “A Holistic Framework for IT Governance.” From theProgram on Information Resources Policy, Harvard University, February2000. [Online: http://www.pirp.harvard.edu/publications/pdf-blurb.asp?id=417]

3 Jones, Larry. “System Thinking and Managing Behavior,” From theArticles section of The Performance Management Homepage Web site.[Online: http://www.p-management.com/articles/9911.htm]

4 Project Management Institute. PMBOK® Guide (Newtown Square, PA:2000), pg. 190.

Chapter Nine1 Passori, Al. “CIOs Must Redouble Efforts to Make the Grade.” META

Group Research Note section, February 7, 2002. [Online: http://www.metagroup.com/metabits/mbDl0513.html]

2 Earl, Michael, and David Feeny. “How To Be a CEO for the InformationAge.” MIT Sloan Management Review, Winter 2000, Volume 41,Number 2.

Appendix1 Alignment between business and technology has been cited for several

years as a primary executive concern, typically ranking in the top third ofmost studies. These studies include the Computer Sciences Corporation.“14th Annual Survey of IS Management Issues,” January 2001; Duffy, Jan.“IT/Business Alignment: Delivering Results.” IDC Research Note section,

References

227


December 31, 2001; Poe, Jonathan. “Top CIO Issues for 2001.” METAGroup Research Note section; Executive Directions, May 17, 2001; andRosser, Bill and Carrie Smith. “Aligning Business and IT Strategies.”Gartner Research Report, September, 9, 1996.

2 The Conference Board (TCB) and Society for Information Management(SIM) are presently working with Dr. Luftman on a major research initia-tive involving the Strategic Alignment Maturity Model. The study isdesigned to produce benchmarking results and best practices that addressthe business/IT relationship. To date, Dr. Luftman’s research shows evi-dence that on the average most organizations only rank at a Level 2 interms of alignment maturity. Dr. Luftman also serves as Chief KnowledgeOfficer for enamics, Inc.

3 The Strategic Alignment Maturity Model is also reproduced in“Diagnosing Your Organization.” CIO Insight Whiteboard, November 1,2001. [Online: http://common.ziffdavisinternet.com/download/0/1278/0107whiteboard_screen.pdf]

AAddddiittiioonnaall RReeaaddiinnggBrown, Carol V. and V. Sambamurthy Repositioning the IT Organization toEnable Business Transformation (Pinnaflex Educational Resources: 1999).

Burke, Brian. “Enterprise Business Architecture: Defining High-Level BusinessProcesses.” META Group Research Note section, August 1, 2001. [Online:http://www.metagroup.com/cgi-bin/inetcgi/search/displayArticle.jsp?oid=26038]

Collins, Jim. “Aligning Action and Values.” Leader to Leader, No 1. Summer1996.

Davenport, Tom and Laurence Prusak. Working Knowledge: How OrganizationsManage What They Know (Harvard Business School Press: October 1997).

Federal Architecture Working Group (FAWG). “A Practical Guide to FederalEnterprise Architecture.” Version 1.0 produced for the Chief Information OfficerCouncil, February 2001.

Gerrard, Michael and Barbara Gomolski. “Driving IT Planning with BusinessStrategy.” Gartner Group Report, October 13, 2001.

Mahoney, J. “The Office of the CIO: What Is It and Why Do You Need One?”Gartner Group Research Note, June 14, 2001.

228References


Meyers, Paul S. “The Theory and Practice of Organizational Change” (Ernst &Young Center for Business Innovation: 1994).

Pickering, Chris. “Cultural Barriers to Business-IT Alignment.” CutterConsortium Interview, 1999.

Sauer, Christopher and Philip W. Yetton. Steps to the Future: Fresh Thinkingon the Management of IT-Based Organizational Transformation (Jossey-Bass:May 1997).

Schrage, Michael. Serious Play: How the World’s Best Companies Simulate toInnovate (Harvard Business School Press: December 1999).

Senge, Peter. The Fifth Discipline: The Art and Practice of the LearningOrganization (Currency/Doubleday: October 1994).

Strassmann, Paul A. “The Hocus-Pocus of Reengineering.” Across the Board,June 1994.

Thorp, John. The Information Paradox: Realizing the Business Benefits ofInformation Technology (McGraw-Hill: February 1999).

United States General Accounting Office (GAO). “Maximizing the Success ofChief Information Officers: Learning from Leading Organizations.” March 2000.

Vitale, Michael and Peter Weill. Place to Space: Migrating to Ebusiness Models(Harvard Business School Press: May 2001).

Weill, Peter and Marianne Broadbent. Leveraging the New Infrastructure: HowMarket Leaders Capitalize on Information Technology (Harvard Business SchoolPress: June 1998).

References

229


CCoonnttrriibbuuttoorrss

IInndduussttrryy CCoonnttrriibbuuttoorrssRandolph C. Blazer is Chairman and Chief Executive Officer ofKPMG Consulting, one of the world’s largest consulting and sys-tems integration firms. Under Mr. Blazer’s leadership, KPMGConsulting launched the second largest IPO of NASDAQ’s his-tory, had 18 consecutive quarters of double-digit growth (1997-2001), increased revenues from $800 million to nearly $3 billion,and institutionalized a “Client for Life” culture resulting in a 96%retention rate of KPMG Consulting’s top clients.

Contributors_FINAL.qxd 7/25/2002 4:15 PM Page 231

Paul Daversa is President and CEO of Resource Systems Group,one of the most sought-after executive search firms for enterprisesoftware and broadband communications by the venture commu-nity and the companies they back, as well as by Fortune 500organizations. Mr. Daversa, who personally architected the firm’sstrategy to support GE’s globally acclaimed e-Business executivesearch campaign, is frequently sourced by major national newsmedia on job market trends and conditions.

Patrick F. Flynn, Vice President and Chief Information Officer oftruck manufacturer PACCAR Inc., is a manufacturing and serviceindustry veteran who has implemented global client-server archi-tectures and software process improvements. He is responsible forthe design and implementation of award-winning electronic com-merce products, and is a sought-after speaker on enhancing multi-tier supply chain networks using electronic commerce.

Scott Hayward is Managing Director at JP Morgan Chase &Company, where his 14-year career with the company hasspanned strategy, operations, sales, service and technology. Heheads client service and marketing for the Americas in the invest-ment management business, was previously Chief OperatingOfficer of the Americas in the investment banking division, andspearheaded several reengineering efforts in swaps, private bank-ing, human resources, and finance.

Dale Kutnick, Chairman, CEO and Research Director of METAGroup, is a recognized authority in all phases of the IT industryand is sourced extensively by the business and industry trade press.Mr. Kutnick, whose analysis spans two decades, co-directs all ofMETA Group’s research and analytic activities, and contributes tothe company’s Executive Directions program, which prepares cus-tomized research for CIOs.

232Contributors


Dr. Jerry Luftman is Executive Director and Distinguished ServiceProfessor for the graduate Information Systems programs at theStevens Institute of Technology. Dr. Luftman, whose 22-yearcareer with IBM included CIO, is best known for his StrategicAlignment Maturity Model, which was developed from over tenyears of research and testing with Fortune 500 companies and isthe basis of a benchmarking study sponsored by The ConferenceBoard and the Society for Information Management.

Chuck Martin is Chairman and CEO of the NFI Research, aU.S.-based research firm exploring the future of electronic busi-ness (E-business) and the Internet. Mr. Martin helped shape theInternet landscape through his work as a corporate Internet strate-gist for a variety of industries and businesses, as author of the best-selling books Managing for the Short Term, The Digital Estate, NetFuture, and Max-e-Marketing in the Net Future, and as a journalistfor several high-profile print and electronic media.

Jack Mollen is Senior Vice President of Human Resources at EMCCorporation, where he is responsible for all global humanresources for EMC’s 24,000 employees. His extensive HR experi-ence includes senior management positions at Citigroup, where hemanaged the HR operations for 90,000 employees in 100 coun-tries for the merged global operations and technology organiza-tions of CitiCorp and Travelers, and at Harris Corporation, wherehe also had responsibility for information systems, engineeringservices, merger and acquisitions, facilities, and quality.

Honorio J. Padron is President, Business Services, Exelon, whereUnicom’s merger with PECO Energy brought to bear Mr. Padron’sexperience as both a business executive and an information tech-nology executive. Throughout his career, he has served as ExecutiveVice President of Process Engineering and CIO at CompUSA andhas held several executive management positions at companiessuch as PepsiCo, Flagstar and Burger King Corporation.

Contributors

233


Don Peppers, founder and partner of the management consultinggroup, Peppers and Rogers Group, is co-author, with MarthaRogers, Ph.D., of several highly acclaimed business books on cus-tomer relationship management (CRM), including The One toOne Future, Enterprise One to One, The One to One Fieldbook (co-authored with Bob Dorf), The One to One Manager, and One toOne B2B. Mr. Peppers has delivered countless keynote addresses,workshops and consulting projects for clients on six continents.

Chris Perretta is Senior Vice President and Chief InformationOfficer for GE Capital Card Services, which provides privatefinancial services to North America retailers and their privateand commercial customers. Mr. Perretta also served as ChiefTechnology Officer for GE Capital, and previously spent 13 yearswith Andersen Consulting in its New York, France and UK con-sultancy practices.

Kevin Poulter is Head of Business Integration at British AmericanTobacco, where his responsibility for the company’s overall busi-ness technology portfolio spans application architecture and inte-gration strategy to B2B integration and information management.Before joining British American Tobacco, he was Chief Tech-nology Officer at Computer Science Corporation, co-foundedOntology.org, and participated in several e-business standards ini-tiatives, such as ebXML, eCo and ICE.

Howard Smith is Chief Technology Officer for Computer ScienceCorporation’s European Group and co-chair of the BusinessProcess Management Initiative. As co-founder of BPMI.org hehas contributed to the development andadoption of BusinessProcess Modeling Language (BPML). Previously, as CSC’s directorof e-business strategy, he co-founded Ontology.org and through his involvement as an invited expert to CommerceNet’s eCoFramework Project, created the seminal ideas which led to manyof today’s well known XML standards for B2B e-commerce.

234Contributors


Tom Trainer is a recognized, 34-year industry veteran who spear-headed major IT efforts for the likes of Eli Lilly and Company,Reebok International, and Joseph E. Seagram and Sons, and wasmost recently Executive Vice President and CIO of Citigroup.Mr. Trainer has lectured extensively internationally on the role ofinformation technology in the consumer packaged goods, phar-maceuticals and electronics industries. He currently serves asChairman of the Executive Committee of enamics, Inc.

Carl Wilson is Executive Vice President and CIO of MarriottInternational, Inc., where he has global accountability for all busi-ness information technology resources. His extensive career ininformation technology spans the hospitality, paper, retail and foodand beverage industries, has made him a favorite source amongbusiness and industry media, and a repeat honoree of such distin-guished industry titles as CIO 100 and InformationWeek 500.

Contributors

235


SSppeecciiaall CCoonnttrriibbuuttoorrssRyan J. Sheehan is a Senior Research Analyst at enamics, Inc. Hisresponsibilities include developing leading industry analysis forthe company’s knowledgebase and advising enamics’ clients dur-ing their alignment initiatives. Previously, Mr. Sheehan was acontributor to e-Enterprise. He holds a Bachelor of Arts degree inComputer Science from Dartmouth College.

Christine D. Aruza is Vice President, Marketing of enamics, Inc.She is responsible for the company’s corporate and product mar-keting programs. Ms. Aruza has spent the majority of her careerhelping F500 multinationals succeed in their efforts to better aligninformation technology with corporate goals. She holds a B.A.degree in Liberal Arts & Sciences, graduating magna cum laudefrom the University of Florida.

236Contributors


IInnddeexx

AAABC efforts, 133

ABCs of governance, 193–94

Activities of BTM, 38, 82–83business model definition, 39–40,

89–90and enterprise architecture,

92–93process optimization, 39–40, 90as a system, 91technology automation, 39–40,

91

Agnostic archetype, 201

Alignment, 23–25

Alignment-level collaboration, 59

Application distribution, trendtoward, 144

Application standards,establishing/enforcing, 162–63

Applications layer, 142–45purposes served by, 143–45

Architecture standards,establishing/enforcing, 162–63

Art vs. science, 196

As-is process environment,examining, 134–36

Atheist archetype, 201

BBBack-office support, 29

Believer archetype, 200–201

Blazer, Randolph C., 98

Blueprint for enterprisearchitecture, 40

BTM, 27activities of, 38, 82–83

business model definition,39–40, 89–90

and enterprise architecture,92–93

process optimization, 39–40,90

technology automation,39–40, 91

benefits to RauhaCommunications, 163

governance of, 38, 167–169strategic direction, 40,

167–179, 172–186tactical control, 40, 167–169,

186–194governing with, 38, 167–169and IT department challenges,

37–40leading the drive to adopt

principles of, 71–72and modeling, 49and the Office of the CIO, 28–33principles of, 38, 47–48

Index_2.qxd 8/7/2002 11:36 AM Page 237

collaborative decision-making, 39

knowledge and asset reuse, 39predictive modeling, 39

recipe for, 197roles/responsibilities, 197–203

business professionals, 199,204

coordinating between, 205–7CxO Suite, 198, 199–200Office of the CIO, 198,

200–203Project/Program Management

Office (PMO), 198, 203–4technology professionals, 199,

204–5technology automation in,

147–52

Build stage, IT projects, 81

Business architecture, defined, 83

Business-driven process change, 130achieving business-driven process

change, 131–32

Business, misalignment betweenbusiness, process, and technology,10

Business model, 96 business scenario models,

creating, 105current, 103

incorporating changes into,105–6

understanding, 104–5defining in BTM, 102–6element classification, 98–100

external businessenvironment, 99

internal assets helping firmachieve goals, 99

overall identity of firm, 98strategy for firm, 98

misconceptions about, 96–97responsibility for defining,

113–14variety within, 100–102

methodology, 101

scale, 101–2what it should be, 98–100

Business model definition, 39–40,77, 89–90, 92–93, 95–114, 163,180

in action, 108–13business scenario models for

impact analysis, developing,111–13

capturing an as-is currentbusiness model, 109–11

emerging trends, 106–8continuously evolving

technology, 106–7formal hierarchies, 107–8high employee turnover, 108

purpose of, 95

Business model requirements,translating, 124–25

Business Process ModelingLanguage (BPML), 150

Business process reengineering(BPR), 30, 123

Business professionals, 199, 204

Business scenario models, 200–202creating, 105developing for impact analysis,

111–13

Business Technology Management,See BTM

CCCEO:

and IT, 200seven creeds of, 201thinking like, 202

CFO, 35, 207CIO compared to, 35

CIO, 9–10CFO compared to, 35changing role of, 32and the disconnect, 41and governance, 40–41interaction with CxO suite, 201

238Index

Index_2.qxd 8/7/2002 11:36 AM Page 238

Clemons, Eric K., 56

Collaborative decision-making, 39,58–65, 79

advantages of, 64–65achieving concurrent

business/ process/technologydesign, 64

maintaining alignmentbetween disparate decisions,64–65

alignment-level collaboration, 59contextual barriers, 62–64cultural barriers, 62–64direct collaboration, 58horizontal collaboration, 59–61model-level collaboration, 58–59T-shaped management, 61–62vertical collaboration, 59–61

Common requirements vision,creating, 132

Computer-aided design/computer-aided manufacturing(CAD/CAM), 49

Conceive stage, IT projects, 81

Contextual barriers, tocollaboration, 62–64

Continuously evolving technology,106–7

Control, tactical, 38, 40, 167–169,186–93

CRM, 9, 31, 33, 36, 146

Cross-linking between models,124–25

Cultural barriers, to collaboration,62–64

Current enterprise models, 87

Customer inquiries, intelligentlyrouting, 137

Customer lifetime value (CLV), 179

CxO Suite, 199–200

DDData-mapping, 144

Daversa, Paul, 202

Decompose processes, 115

Dell Computer's build-to-orderwebsite, 51

Deploy stage, IT projects, 81

Design stage, IT projects, 81–82

Developers, 205

Direct collaboration, 58

Direct search, 67

Direction, 171–94strategic, 38, 40, 167–169,

172–86

Disconnects, 53

Discretionary category, IT budget,181

Documents, as reusable knowledge,66–67

Dotcom collapse, 7–8, 155

EEE-marketplaces, 31

Earl, Michael, 200

80/20 rule, 103

Element classification, 98–100external business environment,

99internal assets helping firm

achieve goals, 99overall identity of firm, 98strategy for firm, 98

Email inquiry capability, providing,137

End-to-end enterprise model, 40

End-to-end perspective, 79–93enterprise architecture, 83–89

Enterprise application integration(EAI) efforts, 132

Enterprise architecture, 83–89and activities of BTM, 92–93defined, 83and enterprise models, 86–89as reference point in

implementation phases, 84and service providers, 85

Index

239

Index_2.qxd 8/7/2002 11:36 AM Page 239

Enterprise disconnects, 8–9

Enterprise models, 86–89attributes, 86cross-links, 86current, 87elements, 86enterprise scenario models, 87final enterprise scenario models,

87relationships, 86updated enterprise model, 87

Enterprise resource planning (ERP),9–10, 37, 146

Entry/Task/Validation/eXit(ETVX), 119

Exelon, 17–20

Existing processes, assessing thevalue of, 125–26

Extensible Markup Language(XML), 150

FFFeeny, David, 200

Fifth Discipline, The (Senge), 184

Final enterprise scenario models, 87

Finance department, 35

Financial modeling and thespreadsheet, 49, 50

Financial planners, 207

Flynn, Patrick, 11–13, 53, 82, 183

Formal hierarchies, 107–8

Functional requirements,developing, 129

GGGap analysis, performing, 136–37

Governance, ABCs of, 193–94

Governance of BTM, 38, 40,167–169

strategic direction, 38, 40,167–169, 172–186

tactical control, 38, 40, 167–169,186–194

Governance pop quiz, 185–86

Graphical user interface (GUI)mockups, 145

Growth category, IT budget, 181

HHHansen, Morten T., 61–62

Hayward, Scott, 20–24, 65, 82

High employee turnover, 108

Horizontal collaboration, 59–61advantages of, 61between business units, 63example of, 61

Hypocrite archetype, 201

IIImpact analysis, 51–52

guidelines for, 52

Information flow, 121–22

Information integration, 137

Integrated DEFinition (IDEF), 119

Inter-enterprise integration, 144–45

Interactive voice response (IVR)technology, 137

IT budget, dividing the pie, 184

IT department, 33challenges facing, 33–37

business innovation,identifying opportunities for,34

extending the life cycle ofhuman and capital assets, 37

mitigating the risk of change,36–37

speaking the same language asthe business, 34–35

unification of services acrossmultiple business units,35–36

and the disconnect, 41

240Index

Index_2.qxd 8/7/2002 11:36 AM Page 240

responsibilities of, 31–32

IT function, 28common criticism of applying

portfolio techniques to, 179complexity/uniqueness of, to

individual companies andbusiness units, 28

current state of, 31–32evolution of the function, 28–31

operational era, 28–30New Economy, 30–31reengineering, 30today, 31

IT projects, stage of, 81

JJJava Database Connectivity(JDBC) standard, 149

JPMorgan Chase and Company,20–24, 65

Just-in-time (JIT) manufacturing,207

KKKnowledge and asset reuse, 39,65–17, 79

advantages of, 69–71establishes enterprise

standards/best practices, 70gives decision-makers right

information at right time, 69minimizes rework/improves

cycle times, 69–70reuses existing physical assets,

70–71assets, 65in context, 68–69as a distinct practice, 68

Knowledge management, 65–66acquisition, 65delivery, 66documents, 66–67interpretation, 66myths about, 66relationships, 66–67

types of reusable knowledge,66–67

Kutnick, Dale, 72

LLLepore, Dawn, 36

Line of Visibility EngineeringMethodology (LOVEM), 119

Linear planning, 56

MMManaging for the Short Term, 8–9

Marriott International Inc., 14–17

Martin, Chuck, 9

Maverick spending, reducing,191–92

Mental models, 184

Misalignment, 10

MIT Media Lab's eMarketsInitiative, 57

Model-level collaboration, 58–59

Modeling, 48–59, 79advantages of, 55–58

communication of designdetails, 57–58

democratization of designdecisions, 57

impact analysis, performanceof, 55–56

risk mitigation, 55and BTM, 49perceived value of, 53–54ripple effects, 52

anticipating, 52–53varieties of, 49visualization afforded by, 190as waste of time, 54whitespace problem, 53–54

Mollen, Jack, 32

Monarch archetype, 201

Monitoring/reanalyzing, 183–85

Index

241

Index_2.qxd 8/7/2002 11:36 AM Page 241

NNNew Economy bubble, 7–8, 34, 36,41, 155

Non-negotiable requirements, 137

Nondiscretionary category, ITbudget, 181

OOObject modeling, 49

Off-the-shelf vendor/packagesolutions, selecting, 152–53

Office of the CIO, 200–203and BTM, 28–33IT budget, 181

Online customer support functions,restricted access to, 137

Online inquiry capability,providing, 137

Open Database Connectivity(ODBC), 150

PPPadron, Honorio, 17–20, 91

Peppers, Don, 127

Perretta, Chris, 151

Popper, Charles, 179–80

Poulter, Kevin, 85, 206

Predictive modeling, 39, 48–59, See also Modeling

Principle, defined, 47

Principles of BTM, 38, 47–48collaborative decision-making,

39knowledge and asset reuse, 39predictive modeling, 39

Process changes, underestimationof, 13–17

Process gaps, analyzing, 127–29

Process, misalignment betweenbusiness, technology, and process,10

Process model, defined, 116–23

Process models, 116 domains and roles, 117, 120–21metrics and rules, 117, 121–23process definitions and flows,

116, 118–20process hierarchies, 116–18

Process optimization, 39–40, 90,115–39, 163

in action, 134–39in BTM, 123–29challenges/benefits, 130–33

achieving business-drivenprocess change, 131–32

creating a commonrequirements vision, 132

improving visibility intovendor functionality,132–33

integrating process acrosswhitespaces, 130–31

providing inputs to simulationand ABC efforts, 133

purpose of, 130–33responsibility for, 139

Procurement management, 190

Project Alpha, RauhaCommunications, 109–14, 158–63

Project/program management office(PMO), 9–10, 198, 203–4

Promotional offers, displaying, 137

RRRauha Communications, 108–13,116, 134–37, 139, 141, 157, 158,160–65

and business model definition,108–113

and process optimization,134–139

project team, 137and technology automation,

157–164

Real-world disconnects, 9–10

242Index

Index_2.qxd 8/7/2002 11:36 AM Page 242

Receipt of inquiry, automaticallyacknowledging, 137

Redundancies/waste, eliminating,191–92

Reengineering, 30

Relationships, as reusableknowledge, 66–67

Request for proposal (RFP), 156,161

Requirements, determining, 136–37

Return on investment (ROI), 34,56

Reusable asset repository, 67–68

Reuse, 39, 65–71, 79advantages of, 69–71

establishes enterprisestandards/best practices, 70

gives decision-makers rightinformation at right time, 69

minimizes rework/improvescycle times, 69–70

reuses existing physical assets,70–71

assets, 65in context, 68–69as a distinct practice, 68knowledge management, 65–66

acquisition, 65delivery, 66interpretation, 66myths about, 66types of reusable knowledge,

66–67standalone systems, pitfall of,

68–69

Role Activity Diagrams (RADs),119

Roles, 117, 120–21

Roles/responsibilities, 197–207business professionals, 199, 204 coordinating between, 205–7CxO Suite, 199–200Office of the CIO, 200–203

project/program managementoffice (PMO), 198, 203–4

technology professionals, 199,204–5

Rummler-Brache, 119

SSSales force automation (SFA), 207

Schrage, Michael, 57

Senge, Peter, 184

Short term, managing for, 8–9

Simulation, 133

Six Sigma methodology, 121

Smalltalk, 12–13

Smith, Howard, 186

Sourcing, and standards, 150–51

Specialists, 205

Spewak EAP Model, 131

Spreadsheets, 49, 50

Standards, and sourcing, 150–51

Strategic direction, 38, 40,167–169, 172–86

aggregated view into ITinitiatives, 177–79

CIO, as ultimate portfoliomanager, 172–73

financial measures/security,175–77

navigating/negotiating, 182–86communicating through

visual aids, 183–85monitoring/reanalyzing, 183

portfolio management, 173–75

Structured Query Language (SQL),149

Supply chain management (SCM),33

System analysts, 205

Systems, examples of, 146

Systems layer, 142, 145–47example, physical view of, 147

Index

243

Index_2.qxd 8/7/2002 11:36 AM Page 243

TTT-shaped management, 61–62

Tactical control, 38, 40, 167–169,186–93

Cost management, 190maverick spending, reducing,

191–92redundancies/waste, eliminating,

192–93quality, importance of, 186–90

Technology automation, 39–40, 91,141–65

in action, 157–63customer service application,

defining requirements for,157–60

establishing/enforcingstandards, 162–63

examining vendors/makingintelligent trade-offs,161–62

in BTM, 147–52designing systems to

specifications required byeach application, 149

developing TechnologyStandards/reuse applicationsand systems, 150–52

selecting vendors/packages,152–53

and cost management pressures,154

responsibility for, 164–65and standards, 155technology architecture,

extensibility/agility of, 155–56technology decisions tracing back

to business/process, 153and vendor communication/

collaboration, 156

Technology, misalignment betweenbusiness, process, and technology,10

Technology model, 142–47applications layer, 142–45

purposes served by, 143–45

systems layer, 142, 145–47

Technology professionals, 199,204–5

Test stage, IT projects, 81

Trainer, Tom, 197, 209–11

Translation, 144

UU––VVUpdated enterprise model, 87

Vendor functionality, improvingvisibility into, 132–33

Venture category, IT budget, 181

Vertical collaboration, 59–61advantages of, 61contextualization problem, 63

Visual aids, communicatingthrough, 183–85

Von Oetinger, Bolko, 61–62

WWWaste, eliminating, 191–92

Waverer archetype, 201

“What-if” experiments, 133

Whitespaces, integrating processesacross, 130–31

Wilson, Carl, 14–17

Work flow, 121–22

ZZZachman Framework, 131

Zealot archetype, 201

244Index

Index_2.qxd 8/7/2002 11:36 AM Page 244

Index_2.qxd 8/7/2002 11:36 AM Page 245

The Financial Times delivers a world of business news.

Use the Risk-Free TrialVoucher below!To stay ahead in today’s business world youneed to be well-informed on a daily basis.And not just on the national level.You needa news source that closely monitors theentire world of business, and then delivers itin a concise, quick-read format.

With the Financial Times you get the majorstories from every region of the world. Reports found nowhere else. You get business,management, politics, economics, technology and more.

Now you can try the Financial Times for 4 weeks, absolutely risk free. And betteryet, if you wish to continue receiving the FinancialTimes you’ll get great savings offthe regular subscription rate. Just use the voucher below.

4 Week Risk-Free Trial VoucherPlease send me the Financial Times for 4 weeks (Monday through Saturday)Risk-Free, and details of special subscription rates in my country.

Name___________________________________________________________________

Company________________________________________________________________

Address _________________________________________❏ Business or ❏ Home Address

Apt./Suite/Floor ____________________City _________________State/Province_____

Zip/Postal Code_____________________Country _______________________________

Phone (optional) ______________________E-mail (optional)______________________

Limited time offer good for new subscribers in FT delivery areas only. To order contact Financial Times Customer Service in your area (mention offer SAB01A).

The Americas: Tel 800-628-8088 Fax 845-566-8220 E-mail: [email protected]

Europe: Tel 44 20 7873 4200 Fax 44 20 7873 3428 E-mail: [email protected]

Japan: Tel 0120 341-468 Fax 0120 593-146 E-mail: [email protected]

Korea: E-mail: [email protected]

S.E. Asia: Tel 852 2905 5555 Fax 852 2905 5590 E-mail: [email protected]

Yes!

www.ft.com

8 reasons why you shouldread the Financial Times for

4 weeks RISK-FREE!

To help you stay current with significant developments in the world economy ...

and to assist you to make informed business decisions — the Financial Times brings you:

❶ Fast, meaningful overviews of international affairs ... plus daily

briefings on major world news.

❷ Perceptive coverage of economic, business, financial and political

developments with special focus on emerging markets.

❸ More international business news than any other publication.

❹ Sophisticated financial analysis and commentary on world market

activity plus stock quotes from over 30 countries.

❺ Reports on international companies and a section on global investing.

❻ Specialized pages on management, marketing, advertising and

technological innovations from all parts of the world.

❼ Highly valued single-topic special reports (over 200 annually)

on countries, industries, investment opportunities, technology and more.

❽ The Saturday Weekend FT section — a globetrotter’s guide to

leisure-time activities around the world: the arts, fine dining, travel,

sports and more.

Where to find tomorrow’s best business and technology ideas. TODAY.

• Ideas for defining tomorrow’s competitive strategies — and executing them.

• Ideas that reflect a profound understanding of today’s global business realities.

• Ideas that will help you achieveunprecedented customer and enterprise value.

• Ideas that illuminate the powerful new connections between business and technology.

ONE PUBLISHER.

Financial TimesPrentice Hall.

Business-minds.comWhere the thought leaders of thebusiness world gather to share keyideas, techniques, resources —and inspiration.

InformIt.comYour link to today’stop business and technologyexperts: new content, practicalsolutions, and the world’s bestonline training.

ft-ph.comFast access to all Financial TimesPrentice Hall business books currently available.

WORLD BUSINESS PUBLISHER

AND 3 GREAT WEB SITES:

FT Book Insert (6" x9") final 9/23/02 10:53 AM Page 1