Zeek the Geek (Ahead of the IT Curve)

hbr.org | July–August 2007 | Harvard Business Review 29

D an

ie l V

as co

n ce

llo s

HBR CASE STUDY

RESHLY SHOWERED AND COOLING DOWN after their squash

game, Max Berndt drank iced tea with his board chairman,

Paul Lefl er. Max, a thoracic surgeon by training, was the

CEO of Peachtree Healthcare. He’d occupied the post for

nearly 12 years. In that time the company had grown – mainly

by mergers – from a single teaching hospital into a regional net-

work of 11 large and midsize institutions, supported by ancillary

clinics, physician practices, trauma centers, rehabilitation facili-

ties, and nursing homes.

Together, these entities had nearly 4,000 employed and

affiliated physicians, who annually treated a million patients

from throughout Georgia and beyond. The patients ranged in

age from newborn to nonagenarian; represented all races, eth-

nicities, lifestyles, and economic conditions; and manifested ev-

ery imaginable injury and disease. Many of them, over the course

of a year, would be seen at more than one Peachtree Healthcare

facility. Max’s marching orders were to ensure quality, consis-

tency, and continuity of care across the entire network – and to

Too Far Ahead of the IT Curve? Peachtree Healthcare’s patchwork IT infrastructure is in critical condition. Should the CEO approve a shift to risky new technology or go with the time-tested monolithic system?

by John P. Glaser

F

HBR’s cases, which are fi ctional, present common managerial

dilemmas and offer concrete solutions from experts.

1284 Glaser.indd 291284 Glaser.indd 29 6/7/07 9:05:23 AM6/7/07 9:05:23 AM

30 Harvard Business Review | July–August 2007 | hbr.org

MANAGING FOR THE LONG TERM | HBR CASE STUDY | Too Far Ahead of the IT Curve?

deliver all that with the highest levels

of efficacy, economy, and respect for pa-

tients and staff.

Max, still sweating lightly, finished

his tea and ordered more. He and Paul

commiserated over the steady vanish-

ing of squash courts in the metro At-

lanta area. This particular block of

four courts was located in a health

club not far from Peachtree’s Marietta

headquarters. Apart from the one Max

and Paul had used, the other three

were dark.

“By next week,” Paul predicted, “at

least one of those courts is gone.”

In Paul Lefl er’s worldview, things al-

ways happened fast. Paul was the CEO

of Wyndham Trust, the region’s leading

retail bank and mortgage lender. Hav-

ing overseen Wyndham’s rapid growth

through mergers and acquisitions, he

was an avid believer in brute-force stan-

dardization. His management team

had honed the art of disciplined con-

version, changing everything from sig-

nage to systems and processes in very

short order, “like ripping off an adhe-

sive bandage.”

Squash courts weren’t the only

thing vanishing from Max’s universe.

So was a comfortable management

consensus about Peachtree Health-

care’s long-term aims and how best to

achieve them. Paul – like other board

members and some in Max’s manage-

ment inner circle – was applying con-

stant pressure on Max to follow the

example of others in the health care

industry: Push ahead on standards and

on the systems and processes to sup-

port them. “You’ve got all the hospitals

doing things differently. You’ve got

incompatible technology that’s held

together by sweat and ingenuity and,

possibly, prayer. Just do what other

institutions are doing. Common sys-

tems, broad standardization… It’s the

competitive reality, and it’s the right

long-term play! So, what the hell are

you waiting for?” But then the iced tea

arrived, and Max used the interrup-

tion as an excuse not to answer Paul’s

question.

They’d been having this conversa-

tion for several months – sometimes

informally, other times in full board or

committee meetings. Max listened, to a

point. Eventually, he always fell back on

his clinical experience. “You can stan-

dardize the testing of ball bearings for

manufacturing defects,” he said. “But as

far as I know, you can’t – at least not

yet – standardize the protocol for treat-

ing colon cancer.”

As a physician, Max believed that

the last word in all matters of patient

care should rest with the doctor and

the patient. But as a CEO he believed in

best practices. So his compromise posi-

tion was to favor selective (Max called

it “surgical”) standardization. Indeed,

many areas of clinical treatment – im-

munizations, pharmacy record keeping,

aspects of diabetes care – could safely

be standardized around best practices

over which there were few disagree-

ments. In other areas, though, standard-

ized practices could have scary patient-

safety consequences, and physicians

had to be free to form their own judg-

ments about which treatments were

best for which patients.

Lately, however, worrisome develop-

ments were eroding Max’s confidence

that he could hold out against Paul’s

brute-force prescription.

Remember The African Queen? Days before, there had been a meltdown

of the clinical information system at

Wallis Memorial Hospital in Decatur.

(Wallis was Peachtree’s most recent ad-

dition.) Since Max had been lunching

with his chief information officer, Can-

dace Markovich, when the alarm came

through to her PDA, he drove her over

to Wallis to investigate.

On the way, Candace reprised her

concerns about ensuring uptime and

performance quality across Peachtree’s

patchwork infrastructure. “More and

more, I feel like Humphrey Bogart in

The African Queen, trying to keep the

blasted engine running on the boat,” she

said. “So much of our energy and bud-

get goes into just treading water. And

the more we grow, the worse it gets.”

At Wallis, Max saw cold panic on

the faces of the IT staff as they rushed

around trying to repair and reboot the

system. Doctors and nursing super-

visors stood around looking helpless

or angry, sometimes a mix of both.

Clinicians, having finally been per-

suaded to use information technology

as a primary tool in delivering care,

now depended on it to work reliably.

When it didn’t cooperate, they – and

their patients – were basically screwed.

Now Max witnessed the routine

nightmare that many doctors recoiled

from. Talented, hardworking, highly

paid people were being kept from do-

ing their jobs by the too-unremarkable

failure of what had become an indis-

pensable tool. Although everyone in IT

was working diligently to fix the prob-

lem, diligence wasn’t enough to keep

disgust at bay. Wherever Max looked,

he saw pain.

John P. Glaser is the chief information of-

fi cer for Partners HealthCare System, in

Boston; a senior adviser to the Deloitte

Center for Health Solutions, in Washington,

DC; and president emeritus of the eHealth

Initiative, whose mission is to improve the

quality, safety, and effi ciency of health care

through information and IT. He is a coauthor

of Managing Health Care Information Sys-

tems (Jossey-Bass, 2005).

“ You’ve got incompatible technology that’s held together by sweat and ingenuity and, possibly, prayer. Just do what other institutions are doing. Common systems, broad standardization.”

1284 Glaser.indd 301284 Glaser.indd 30 6/7/07 9:05:32 AM6/7/07 9:05:32 AM

hbr.org | July–August 2007 | Harvard Business Review 31

And yet Max was also that rarity in

medicine – a physician leader who

recognized and embraced the value in

technology. An early enthusiast of tele-

medicine, he had participated in long-

distance, computer-assisted research

conferences and consultations on behalf

of his own and other doctors’ patients.

He had easily been converted to the

view that computerized, consolidated

patient records were vastly superior to

manila file folders scattered through-

out various specialists’ offices, subject

to eccentric clinical and record-keeping

habits. As CEO, he had shown consis-

tent leadership in visibly championing

IT-based innovation. And he enjoyed

a close, positive working relationship

with Candace.

Even so, all he was hearing from Can-

dace lately was that the IT infrastruc-

ture was consuming so much mainte-

nance energy that further technical

innovation was becoming a luxury, an

afterthought. At Wallis, Max had got-

ten to see the nature of the problem up

close and personal.

Luckily, the situation ended up being

resolved without major consequences

to patients – this time. But Max was

now convinced that something urgently

needed to be done. The African Queen

was headed toward the rapids.

Medicine Is Different The day after the squash match, Max

sat in a budget meeting in his office

attended by Candace and Peachtree

CFO Tom Drane. Max wanted to know

what it was going to cost to rearchitect

technology across all of Peachtree’s

facilities. Candace and Tom cataloged

the results of a request for informa-

tion Candace had put out earlier in

the year. Max paid nervous attention.

_ g _ / / / g

1284 Glaser.indd 311284 Glaser.indd 31 6/7/07 9:05:38 AM6/7/07 9:05:38 AM

32 Harvard Business Review | July–August 2007 | hbr.org

MANAGING FOR THE LONG TERM | HBR CASE STUDY | Too Far Ahead of the IT Curve?

The combination of IT and big, hairy

numbers was certainly not unheard of,

but it was still intimidating, mysterious,

and worrying. Moreover, it was hard

for Max to reconcile the task of stan-

dardization with all the realities of the

health care mission.

Sometimes Max envied Paul Lefl er

the dispassionate nature of the banking

business. No patients, only customers –

and most of them just wanted some-

thing simple: a loan, a place to put their

money, a way to get at it easily. Paul

could choose end-to-end standardiza-

tion with a clear conscience.

Health care, though, was different.

It was a matter of life or death. Doc-

tors – not wizards of finance – were

the authority figures of greatest con-

sequence. Any effort to control or oth-

erwise interfere in physicians’ duties

was scrutinized in the long shadow of

the Hippocratic oath. For that and other

reasons, mergers were not typically a

feature of market behavior among

hospitals. Often when they were tried,

hospital mergers failed. Each institu-

tion had its own idiosyncratic, doctor-

dominated identity. Put one together

with another, and you’d constructed an

oxymoron – a health care “system.”

Or so the wisdom went until Peach-

tree did its first merger and created

a potent synergy between two great

teaching hospitals. Now Max presided

over a federation of 11 hospitals of as-

sorted sizes and special purposes, each

with its own proud history and culture,

each with its own weird mishmash

of IT systems of various vintages and

vendor pedigrees. Soon, depending on

just how much standardization he ul-

timately decided to pursue, Max was

going to rock the whole boat either

a little or a lot.

Presently under consideration were

proposals for what Candace called

monoliths – massive systems running

massively ambitious enterprise soft-

ware that would compel the arduous

redesign of every business process. The

hardware and software, she explained,

“are the tip of the iceberg costwise. It’s

everything that comes next that makes

this so expensive.”

Tom reached across a small con-

ference table and turned the page in

a three-ring notebook assembled for

Max’s edification (Max was famously

scornful of PowerPoint). “Looking

at benchmark data for implementa-

tions of comparable size,” said Tom,

“you see there’s potential for the cost

to multiply two or three times over

budget.”

Max admired the way Tom could con-

vey a thoroughly terrifying possibility

without betraying the slightest vocal

stress – the CFO version of bedside

manner.

“Really?” said Max. “Two or three?

Depending on what?”

“Mainly on consulting services,” said

Candace. “The time it takes. How hard

it is to change the processes, get buy-in,

roll out the system without too much

scope creep, train the people, make cus-

tomizations, fix problems that crop up

after implementation.”

“The good news?” asked Max.

“It can work,” said Candace. “It gets

the job done. It leaves us with a brand-

new homogeneous infrastructure, a

single set of systems and applica-

tions, complete interoperability and

consistency across all of the hospitals,

a unified patient records database.

Unified everything, really. It’s like we

become a single institution with mul-

tiple campuses.”

“Okay,” said Max, looking now at Tom.

“Is there a number you’d like to leave

me with?”

“Five hundred million to a billion,”

said Tom. “Spread out over five to seven

years.”

“But it could be more?”

Tom shrugged. “It could. But I’m com-

fortable with a billion at the high end.”

Caveat Emptor Everywhere On an evening a few weeks later, in mid-

July, Candace appeared at Max’s door,

obviously in the grip of a fresh enthu-

siasm. Max was trying to get out of the

office for his son’s tenth birthday cel-

ebration (the boy already regretted his

summer birthday, because most of his

friends were scattered to family vaca-

tions and camps).

“Five minutes,” said Max. “It’s Teddy’s

birthday.” Candace proceeded to take

nearly ten.

“As you know, we’ve been goofing

around some with SOA,” she told him,

pronouncing it “SO-wuh,” a gentle-

sounding locution that suggested a sea-

weed wrap at a Japanese spa. “Nothing

too intense, just some prototypes to get

a feel for it. My view has been that it’s a

couple of years away from being ready as

an option we’d have a lot of confidence

in. But maybe there’s a way to manage

the risk of being more aggressive.”

Max understood service-oriented ar-

chitecture in a limited way. It was the

latest hyperbolic promise of technol-

ogy magic, a way of parsing informa-

tion systems into modules that perform

discrete services. Built out of reusable

strands of programming code, these

modules could be reconfigured, Lego-

like, into new applications at a dimin-

ishing future cost. With Max’s blessing

Candace had funded some SOA experi-

ments; the results had been mixed but

still were encouraging in the proof-of-

concept sense.

“What’s good is that this would give

us a lot of agility. We could easily change

a system. We could try something out

on a limited scale and move forward in

small steps to keep the risk lower. But

Each institution had its own idiosyncratic, doctor- dominated identity. Put one together with another, and you’d constructed an oxymoron – a health care “system.”

1284 Glaser.indd 321284 Glaser.indd 32 6/7/07 9:05:47 AM6/7/07 9:05:47 AM

hbr.org | July–August 2007 | Harvard Business Review 33

the thing for you to bear in mind is that

SOA gives us the fl exibility to go after

selective standardization. It’s not a

my-way-or-the-highway kind of deal.”

Max nodded, intrigued. Neverthe-

less, he remained standing and edged

toward the door – he had to stop at the

bakery on the way home to pick up

the cake his wife had ordered. Candace

talked faster. “The problem is, the SOA

market’s not mature yet. There’s a lot of

unpredictability. The vendors are still

feeling their way along, and the risk for

us is we become a victim of their – and

our own – steep learning curve.”

After a couple of further ambigu-

ous upside and downside observations,

Candace released Max. In the car he

continued processing the conversation.

It was the devil you know versus the

one you don’t. But the thought of sur-

rendering on the question of selective

standardization continued to nag at

Max – it was a choice with huge im-

plications for the indigenous clinical

cultures of Peachtree’s original parts.

A monolithic system would render

the surgical approach difficult to the

point of impossibility. But SOA might

blow up in everyone’s faces, leaving

Peachtree with selectively standard-

ized chaos that was scarcely better than

what existed today.

At the bakery Max was impressed

by the colorful sheet cake. It was toma-

hawk themed for the Braves – Teddy

was a big fan of Andruw Jones.

A Femur Meeting At Max’s urgent behest, Candace pre-

sented the pros and cons of the SOA

option to a small strategy task force,

whose deliberations would inform

Max’s recommendation to the board

of directors. They met in a 12th fl oor

conference room known as Femur (all

of Peachtree’s meeting spaces were

named for least-disagreeable body parts,

mainly bones).

“No choice is perfect,” Candace said by

way of introduction. “But who knows?

Maybe there’s something here for us.”

At a meeting two days earlier she had

sketched out the monolithic system,

scaring everyone with its price tag.

The team had originally been impan-

eled to give more shape and detail to

Max’s goal of surgical standardization.

It had made progress toward identify-

ing best-practice opportunities and fl ag-

ging areas where physicians and institu-

tions should – for now, at least – be left

to their own devices.

At the outset of this process, Max

had framed what for him was the key

issue: “We could declare that everyone

in this building will from now on wear

uniforms,” he said. “We’d then have an

office-wear standard, but what would

be the point? Standardization has to be

seen in the context of something gained.

Do no harm, right?” But now the whole

strategy was up in the air. Max firmly

believed that Peachtree’s best long-

term bet – exemplified by his cautious

approach to standardization – was to

preserve at all costs the hospitals’ fl ex-

ibility to respond to constant change.

But Paul Lefl er and others saw his cau-

tion as timid. Their view was that only

by creating a thoroughly unified insti-

tution would Peachtree shed its legacy,

premerger shackles.

Besides Max, Candace, and Tom, the

team consisted of the COO, presidents

of two of Peachtree’s hospitals, and the

president of the Peachtree Healthcare

Foundation, the company’s nonprofit

research arm.

Candace moved quickly through her

formal briefing, careful not to dive too

deep, so there would be time for ques-

tions at the end. Tom asked who else

in the health care industry was aggres-

sively adopting an SOA strategy. “No

one that I’m aware of,” she said. “To be

honest, that’s one of the reasons key

vendors are eager to work with us. They

want to get some health care cred. On

the one hand, that motivates them to

be fl exible on pricing. On the other, it

makes us the guinea pigs.”

Max listened as Candace laid out

the risks and uncertainties. SOA was

new and had no industry track record,

she said. “So it’s very hard to estimate

with any reliability what a given unit of

progress will cost, how long it will take

to achieve it, and how close the result-

ing service will come to performing the

way we intended it to. The concept of

SOA suggests that it’s less expensive in

the long run than the monolithic sys-

tem, but we don’t have any data from

other health care institutions to prove

that. So you can’t rule out that it might

end up costing the same.”

Max found himself wanting Candace

to be just a little more upbeat on SOA.

She’d incited him to think about it, and

now he was beginning to wish he’d

never heard of it. “So, why would any-

one bother with it now?” he asked her.

She proceeded to share the Candace

Markovich Theory of the IT Future:

SOA was potentially the migration

path to a transformative way of creat-

ing technology capability. “I really do

believe that’s true,” she said. “So you can

imagine how it might not totally thrill

me to think about spending a bazillion

dollars on a brand-new, shiny dinosaur

that we’d be stuck with at a point in

history when the IT world is moving

someplace else. That isn’t a choice I’d

want to have to make. But I can see the

logic in making it, because SOA is still

kind of a crapshoot.”

How should Peachtree try to fi x its IT infrastructure problem? Four commentators offer expert advice beginning on page 36.

Max fi rmly believed that Peachtree’s best long-term bet – exemplifi ed by his cautious approach to standardization – was to preserve the hospitals’ fl exibility.

_ g _ / / / g g

1284 Glaser.indd 331284 Glaser.indd 33 6/7/07 9:05:52 AM6/7/07 9:05:52 AM

36 Harvard Business Review | July–August 2007 | hbr.org

W e

n d

y W

ra y

George C. Halvorson is the chairman and CEO of Kaiser Permanente, based in Oakland, California. Over the next three years, KP will spend more than $3 billion to convert all its medical and other administrative records to digital fi les, linking them to electronic tools for care and connectivity.

AJOR SYSTEMS PROJECTS are hard enough to support when your head of

information technology is fully and enthusiasti- cally on board. In Peachtree Healthcare’s situ- ation, a risky business case is being hesitantly recommended to senior management by an IT chief whose strongest positive feeling is that it might work. The proposed technology is untested in a health care environment, the cost load is undetermined, and the benefi ts are uncertain.

It’s pretty hard for a CEO to bet the farm on a major systems initiative that has no obvious upside or business case for implementation. The fact that the current systems environ- ment at Peachtree Healthcare is clunky and marginally functional should cause the sys- tems staff to look for a better approach. But building a plan that uses untested methodol- ogy in a pioneering rollout effort is not a good decision – particularly because the stakes in a health care work environment truly can be life or death as well as fi nancial.

So, what should happen next for Peachtree Healthcare? For starters, Max Berndt and the rest of the company’s senior managers need

to envision exactly what they want to accom- plish with their systems. They also need to be closely involved in developing and fi nalizing that vision. Clear intent is essential, coupled with an equally clear strategic pathway to achieve that intent. The Peachtree IT-planning process skipped that step and started with a tool rather than a desired outcome. The right approach for the organization’s leaders is not to implement something and then see if it works. It is to fi gure out exactly what they want their systems to do and then construct a plan for achieving those goals in a reason- able time frame and at an affordable cost.

In health care today, there are a few elements that must be included in any major IT plan. Ex-

tremely high levels of systems availability are an absolute necessity. Completely computer- ized clinical information will soon be essential, too, as will the ability to track care performance and patient outcomes. But standardizing care into a particular set of protocols is not a cur- rent necessity. Paul Lefl er, the nonmedical board chair at Peachtree Healthcare, is eager to standardize care – in part because standard- ization has created effi ciency, cost savings, and higher-quality products in settings outside the health care industry. In some operational areas, that kind of standards-based thinking can be transferred to health care delivery; in other ar- eas, however, it is entirely premature.

Why premature? Because the evidence needed to insist on standardization isn’t there yet for many areas of care. Some of the best thinkers in American health care are now work- ing on an initiative to have 90% of health care decisions based on best medical evidence by the year 2020. If that is the goal, the evidence now available is not suffi cient to use a com- puter to force standardized care on physicians. So the CEO of Peachtree is right in resisting rigid standardization. That said, the company’s

systems should include a database that will allow for tracking of care performance – both to identify which care delivery approaches work best and to ensure that those that don’t work are identifi ed and can be corrected.

Overall, the Peachtree team needs to go back to the drawing board. The company is defi nitely not ready to go down the service- oriented architecture path that the CIO has so tepidly recommended. It can do a lot better by starting with a broad vision for its systems results and then building a complete plan to achieve each objective within that vision. Sys- tems in a health care environment should be a tool that is used to improve performance in the context of a well-considered strategy.

A risky business case is being hesitantly recommended to senior management by an IT chief whose strongest positive feeling is that it might work.

M

MANAGING FOR THE LONG TERM | HBR CASE COMMENTARY | How Should Peachtree Try to Fix Its IT Infrastructure Problem?

1284 Glaser.indd 361284 Glaser.indd 36 6/7/07 9:06:11 AM6/7/07 9:06:11 AM

hbr.org | July–August 2007 | Harvard Business Review 37

HE FIRST THING I WOULD ASK IS, why is this Max Berndt’s decision? If the CEO

can override the technical recommendation of the CIO, and the CIO’s going to have to implement whatever the CEO decides, it’s very possible there will be problems. But let’s table that question for now.

One thing that’s not spelled out is Peach- tree Healthcare’s risk profi le. It would help to know how tolerant of risk the company is. But the fact that management is considering service-oriented architecture when others in the health care industry have steered clear suggests some willingness to get out ahead of the curve. It’s also obvious this is a time- bound situation. The company doesn’t have the luxury of waiting for a lot more certainty; its infrastructure needs a solution now.

A trap organizations can fall into is to see the choice as much more stark than it has to be. This shouldn’t be an either-or situation. Elements of both options may have value in combination.

What Peachtree could do – and, in fact, what we are doing at American Airlines – is to move gradually in the direction of SOA. The company doesn’t have to make a wholesale, knife-edge change from its legacy infrastruc- ture. Instead, it can (as Candace Markovich suggests) divide the transformation into cal- culated, well-prioritized chunks. Chip away at the edges of old systems and replace them over time with SOA-built services. An incre- mental approach not only minimizes risk but makes the project more fl exible and easier to control, and it allows IT to shift priorities at logical break points. The best SOA implemen- tations will take full advantage of the legacy system’s functionality but not just reinvent the older system in a newer SOA form.

Peachtree has traded in many of its old man- ual core business processes for IT-supported ones. Once that bridge has been crossed, there’s no going back. Peachtree’s clinical systems are, like American Airlines’ reserva- tion system, indispensable for carrying out the company’s mission. Doctors and patients depend on them, so reliability is crucial. What- ever approach Peachtree implements has to

be operationally sound. Obviously, part of the urgency the company faces is that its current technology keeps conking out.

I would reassure Max and Candace that SOA can be brought along in a way that man- ages down the risks and respects the need for reliability. In the end, the company must have systems that will work dependably. And an SOA-based environment that is not function- ally rich is a failure. In that case, Peachtree would be better off with a monolithic system. Because the stakes are so high, the company must err on the side of getting the job done, and only then bring along the fl exible systems and architecture. It doesn’t do any good to have a totally fl exible architecture that either doesn’t properly address business needs or takes so long to implement that the company misses opportunities in the meantime.

For an organization like Peachtree, I don’t think there’s a time penalty for either choice – it wouldn’t take any longer to get SOA up and running than it would the monolithic system. But it’s important to remember that people often start out thinking of SOA as a project. Done correctly, the “project” never ends – it just turns into the way you do business. It

becomes the way your IT capability is built, and that represents long-term value.

Candace should recommend that Peach- tree turn toward an incremental implementa- tion of SOA. And my strong advice to Max is to accept Candace’s recommendation. The question of how to replace which pieces of the infrastructure should come in at a distant second to the overall decision to adopt SOA. Peachtree should follow the commonsense approach of retaining what still works and adds value to the enterprise, as long as it will accommodate a modular SOA scheme.

Monte Ford ([email protected]) is a senior vice president and the chief information offi cer at American Airlines, based in Forth Worth, Texas. Since joining American in Decem- ber 2000, he has rebuilt the company’s IT function, consolidating more than 40 disparate groups and aligning all IT projects with the airline’s business objectives.

The company doesn’t have to make a wholesale, knife-edge change. It can chip away at the edges of old systems and replace them over time with SOA-built services.

T

_ g _ / / / g g

1284 Glaser.indd 371284 Glaser.indd 37 6/7/07 9:06:17 AM6/7/07 9:06:17 AM

38 Harvard Business Review | July–August 2007 | hbr.org

MANAGING FOR THE LONG TERM | HBR CASE COMMENTARY | How Should Peachtree Try to Fix Its IT Infrastructure Problem?

Randy Heffner (rheffner@ forrester.com) is a vice presi- dent at Forrester Research, where he covers technology architectures for computer- based business systems. Formerly, he was a chief architect at Sprint, where he led the development of compo- nent technologies that are forerunners of service-oriented architecture.

A X BERNDT HAS A CLEAR READ on Peachtree’s high-level choices – a well-

worn path of high-cost, rigid business stan- dardization versus a new path of incremental, fl exible business evolution. He senses that if service-oriented architecture can truly deliver on its promises of incremental change, it can provide the technological foundation for surgi- cal standardization. But his CIO, by “goofi ng around” with SOA as a vendor-driven product category instead of looking at it as a method- ology, has missed key perspectives on SOA’s maturity and its relationship to business dy- namics and change management.

To begin with, SOA’s industry penetration is deeper than Candace Markovich realizes. According to survey data from Forrester Re- search, about 60% of North American, Euro- pean, and Asian-Pacifi c enterprises say they are now using SOA or will be by the end of 2007, including 22 of 38 public-services orga- nizations surveyed.

More important for Peachtree’s consider- ation is that about 40% of current SOA users say it is helping them to achieve strategic busi- ness transformation. Why does SOA garner so much credit? Its design models, when done right, are the best yet at preparing a fi rm’s technology to change with the company. Each

major business task (like ordering a diagnostic test or entering clinical notes in a patient’s record) has a separate, simplifi ed software in- terface called a “business service.” With busi- ness services – the Lego-like blocks used to construct and change processes – alignment with the business is built in; the technology and products are secondary. Some fi rms have for 15 years or more built software as busi- ness services, but the label “SOA” has gained prominence only within the past fi ve years, with the rise of SOA as a product category.

Candace views SOA as a product category based on emerging industry standards for

connecting applications across a computer network – so-called Web services. Wide- spread support among technology vendors and users is creating a broad industry ecosys- tem of products, skills, and services. So far, only the core standards have achieved critical mass, and the market landscape is still rapidly changing. Even so, the trade publications are replete with positive user testimonials about Web services. SOA-based design does not require Web services, but their combined benefi ts provide strong potential for business integration and fl exibility.

Max’s greatest asset is his grasp of the business dynamics of health care. In the swing of the pendulum to the side of effi - ciency, the ruthless standardization option risks limiting doctors’ choices too much. By contrast, SOA’s modularity provides a range of standardization choices. For example, a sin- gle business service for clinical notes could accommodate physicians’ different note- fi ling preferences – whether doctors want to enter patient information directly on a com- puter or dictate it for later transcription.

Another big risk of ruthless standardization is that it requires an all-or-nothing approach to replacing Peachtree’s existing software. SOA would allow Peachtree to replace only the most broken parts of its existing technology base. Retrofi tting older systems with business- service interfaces is generally much cheaper than replacement. The benefi ts of broad stan- dardization depend largely on the success of one large, multiyear project. The best approach with SOA is a series of small but independent projects within an overall portfolio of improve- ment initiatives. This provides many opportuni- ties to assess, adjust, reprioritize, and redesign along the way. Furthermore, after SOA-based systems are implemented, the organization can continue to improve them.

SOA’s business design models are the best match for Peachtree. They will allow the company to manage the risks of business and technology change (including SOA’s own risks). Max should direct Candace to redo her decision analysis and strategy planning, look- ing at SOA through a business lens.

By “goofi ng around” with SOA as a product category instead of looking at it as a methodology, the CIO has missed key perspectives.

M

1284 Glaser.indd 381284 Glaser.indd 38 6/7/07 9:06:23 AM6/7/07 9:06:23 AM

hbr.org | July–August 2007 | Harvard Business Review 39

NE OF THE PROBLEMS facing Max Berndt is all too familiar to leaders of health care

systems: To what extent can or should the work of physicians in the various hospitals be stan- dardized? Max and his colleagues will probably be frustrated if they try to herd doctors into a corral made of the latest computer technology.

Many students bent on careers in medicine see a future in which they will work for them- selves and control their professional lives in a way unlike their friends in other careers. That vision was a reality generations ago, but today it is a seldom-realized fantasy. Very few doctors work in solo practice – most are either in private groups or employees of medi- cal schools or large networks like Peachtree.

Having lost the mom-and-pop character of practice administratively, doctors adamantly protect independence in their relationships with patients and in their other day-to-day activities. Most did not enter medicine inter- ested in, or equipped for, administrative re- sponsibilities. Unlike Max, many do not want

to run a company and will rebel against the regimentation that they see as a part of the corporate culture.

Within a health care system like Peachtree, consisting of community hospitals and major teaching institutions, the terms of employment take several forms. Many of the doctors in the teaching hospitals are probably members of a “practice plan,” a multispecialty group prac- tice controlled by either the medical school or the teaching hospital. These doctors – each of whom, we can assume, has an appointment in a clinical department of one of the medical schools (such as medicine, surgery, pediat- rics, or radiology) – are salaried, perhaps with a bonus based on clinical productivity. They have chosen this form of work because they want to participate in the teaching programs of the medical school, in some cases perform medical research, and care for their patients

in a well-known institution and with the col- laboration of talented colleagues.

Most of Peachtree’s facilities, however, are not teaching hospitals. They are community hospitals, established by citizens and doctors to provide health care for their communities, and are probably structured as not-for-profi t corporations. Most of the physicians who ad- mit patients to this kind of hospital are self- employed. Some – particularly in hospital-based specialties such as radiology, emergency medicine, and laboratory medicine – may be employed by the community hospitals directly or by contract with private group practices.

Given the differences in how Peachtree’s doctors are employed, and considering how they value their independence, one can un- derstand how diffi cult it would be to persuade them to follow regimented patterns in their work. The transition to a computerized sys- tem for charting clinical information presents a problem to those charged with establishing a workable IT strategy. Younger doctors who are

well versed in computer technology will have less diffi culty accepting such a system. Older doctors who are not particularly computer lit- erate will have a harder time adjusting.

Making the work of doctors more computer compatible is only one factor that management and the board should consider. They must ac- cept that many physicians will resist applying sophisticated technology to their day-to-day activities. Peachtree should not attempt to change the essential features of how doctors work in its community hospitals. That spark of independence still glows in the psyche of many doctors, and trying to regiment them will only increase its intensity.

Reprint R0707A

Reprint Case only R0707X

Reprint Commentary only R0707Z

To order, see page 195.

John A. Kastor (jkastor@ medicine.umaryland.edu) is a professor of medicine at the University of Maryland School of Medicine, in Baltimore. He is the author of Mergers of Teaching Hospitals in Boston, New York, and Northern Cali- fornia (University of Michigan Press, 2001).

The spark of independence glows in the psyche of many doctors, and trying to regiment them will only increase its intensity.

O

_ g _ / / / g g

1284 Glaser.indd 391284 Glaser.indd 39 6/7/07 9:06:29 AM6/7/07 9:06:29 AM