Digital Athena
  • Blog
  • Essays and Book Reviews
  • Contact Us
  • About Digital Athena
  • Index of Essays and Reviews

CONT R A R I A

Technology has alwa

y s b e en a b out

hope. Since the beginning

of the industrial

revolution, businesses

have embraced new

technologies enthusiastically,

and their

optimism has been

rewarded with improved

proce s s e s ,

lower costs and reduced

workforces. As the pace of technological

innovation has intensified over the past two decades,

businesses have come to expect that the next

new thing will inevitably bring them larger market

opportunities and bigger profits. Software, a technology

so invisible and obscure to most of us that it

appears to work like magic, especially lends itself to

this kind of open-ended hope.

Software promises evolutions, revolutions and

even transformations in how companies do business.

The triumphant vision many buy into is that

enterprise software in large organizations is fully

integrated and intelligently controls infinitely complex

business processes while remaining flexible

enough to adapt to changing business needs. This

vision of software lies at the core of what Thomas

Friedman in The World Is Flat calls “the Wal-Mart

Symphony in multiple movements — with no finale.

It just plays over and over 24/7/365.”
1 Whole

systems march in lock step, providing synchronized,

fully coordinated supply chains, production

lines and services, just like a world class orchestra.

From online web orders through fulfillment, delivery,

billing and customer service — the entire

enterprise, organized end to end — that has been

the promise. The age of smart machines would

seem to be upon us.

Or is it? While a few companies like Wal-Mart

Stores Inc. have achieved something close to that

ideal, the way most large organizations actually

process information belies that glorious vision and

reveals a looking-glass world, where everything is

in fact the opposite of what one might expect. Back

office systems — including both software applications

and the data they process — are a variegated

patchwork of systems, containing 50 or more databases

and hundreds of separate software programs

installed over decades and interconnected by idiosyncratic,

Byzantine and poorly documented

customized processes. To manage this growing

complexity, IT departments have grown substantially:

As a percentage of total investment, IT rose

from 2.6% to 3.5% between 1970 and 1980.
2 By

1990 IT consumed 9%, and by 1999 a whopping

22% of total investment went to IT. Growth in IT

spending has fallen off, but it is nonetheless surprising

to hear that today’s IT departments spend

70% to 80% of their budgets just trying to keep existing

systems running.

According to a multiyear study of over 400 companies

by MIT researchers Jeanne Ross, Peter Weill

and David Robertson,
3 IT departments tend not to

be innovative leaders within organizations, but

rather conservative forces, viewed by business executives

as cost sinks and liabilities. In many

companies, it takes the IT department one to two

years to implement a new strategic initiative --

hardly the agility companies are striving for. The

research shows the typical IT structure is so dense

and extensive that it’s often a miracle that it works

at all. The researchers observe: “Legacy systems

cobbled together to respond to each new business

initiative create rigidity and excessive costs. Every

change becomes a risky, expensive venture.”

The Proliferation of Complexity

How did this happen? James Cordata, who has

written extensively about the information economy,

points out that as work became more complex

and specialized over the 20th century, the use of

data — numbers and facts — as fodder for more

and more analysis and fact-based decision making

intensified. And digital technology “was perfect for

this kind of world.”
4 Of course, digital technology

The Trouble With Enterprise Software

Has enterprise

software become

too complex to

be effective?

Cynth ia Rett ig

Illustration: TK/theispot.com FALL 2007 MIT SLOAN MANAGEMENT REVIEW 21

This article, originally

published on the

MIT Sloan Management

Review website,

stirred up a good deal

of discussion in the

blogosphere, a sampling

of which is included in

the following pages.

22 MIT SLOAN MANAGEMENT REVIEW FALL 2007 sloanreview .mit .edu

not only supported that complexity but also played

a large part in actually creating it, weaving a continuous

web of unending data. “More computers

are better than fewer” remains a key belief of American

business, Cordata says. “There are no limits to

how much is good.” Management became accustomed

to the idea that buying more computers and

more software would continue to cut costs and improve

operations.

But there are limits, some of which are inherent

in the nature of software itself. Software is code,

lines and lines of code that runs sequentially. Building

software programs entails accumulating more

and more code. Much of the seemingly boundless

complexity of enterprise software is founded on

conditional branching (if-then statements) and a

hierarchy of interacting objects, all of which manipulate

information in a logical succession of

small steps. Each step contains explicit instructions.

To build software, programmers routinely

break down processes into discrete steps, effectively

systematizing and standardizing how work is done.

An entire sequence of such instructions works

more like a calculator than a “thinking machine.”

Thus the so-called intelligence of digital technology

arises not through magic, nor, in more

contemporary terms, through some emergent or

self-organizing principle, as some would believe.

The result is not greater than the sum of the parts.

Rather, it’s more akin to Adam Smith’s division of

labor and Frederick Taylor’s scientific management,

a process dependent on relentless analysis

and rationalization of the work to be done.

General software programming used in enterprise

systems may contain intricate branching and

handle a huge number of conditions, all of which

allows it to control a certain amount of complexity.

It does not, however, tolerate ambiguity,

inconsistencies or illogical conclusions. To be sure,

there are fuzzy logic programs, dynamic simulations,

genetic algorithms and neural nets with

subtler powers, but a vast amount of software

working in today’s large organizations is not of

these more advanced types. In fact, enterprise software

systems are more likely to succeed at relatively

straightforward tasks such as procurement and

order processing. As the problems get more complex,

so does the software that solves them. It is

estimated that for every 25% increase in complexity

in the tasks to be automated, the complexity of

the software solution itself rises by 100%.
5

Business users and management inevitably want

changes in their automated processes as their needs

and markets evolve. And they expect to be able to

customize their software to fit their own needs.

“Software is infinitely malleable,” says computer

historian Martin Campbell-Kelly.
6 This is in theory

true; however, as enterprise software becomes increasingly

comprehensive and complex, the costs

and risks involved in changing it increase as well.

No single person within an organization could

possibly know how a change in one part of the software

will affect its functioning elsewhere.

Software’s supposed flexibility and unending

ability to manage complexity contributed to the

discrepancies between the great expectations and

mediocre reality that plagued the first round of

implementations of enterprise resource planning

systems. In the middle to late 1990s, U.S. corporations

rushed to purchase and install such systems.

These systems — Germany-based SAP Aktiengesellschaft’s

is the most common — promised to

eliminate the complexity of multiple operating systems

and applications by replacing them with a

single set of interconnected modules to run the financial,

manufacturing, human resources and

other major functions of a typical multinational

corporation. Theoretically, a single monolithic system

would seamlessly connect various distinct and

geographically separate locations through private

CoNT R A R I A

From The Wall Street Journal

Business Technology Blog

http://blogs.wsj.com/biztech/

“Technology is supposed to simplify business. This has been true from

the Industrial Revolution to the Internet age. But did the large software

applications that were supposed to streamline large companies instead

irrevocably slow them down?

There’s a compelling argument to be made that they have. The average

company spends $15 million on Enterprise Resource Planning

software, the monolithic systems of record from vendors like SAP and

Oracle, and many large companies have spent tens and even hundreds

of times that, according to [Ms. Rettig’s article].

Some of this resonates. Certainly, companies that have tried to customize

these systems to reflect their own customized processes have

spent a lot of time and money to do so. And ERP systems do introduce a

certain amount of rigidity. On the flip side, having a system of record is a

benefit in and of itself that shouldn’t be discounted.” — Ben Worthen

sloanreview .mit .edu FALL 2007 MIT SLOAN MANAGEMENT REVIEW 23

networks. Companies understood that they could

customize these systems as needed to suit their

unique business processes.

That was the hope. But these massive programs,

with millions of lines of code, thousands of installation

options and countless interrelated pieces,

introduced new levels of complexity, often without

eliminating the older systems (known as

“legacy” systems) they were designed to replace. In

addition, concurrent technological and business

changes made closed ERP systems organized

around products less than a perfect solution: Just

as companies were undertaking multiyear ERP

implementations, the Internet was evolving into a

major new force, changing the way companies

transacted business with their customers, suppliers

and partners. At the same time, businesses were

realizing that organizing their information around

customers and services — and using newly available

customer relationship management systems

— was critical to their success.

The concept of a single monolithic system failed

for many companies. Different divisions or facilities

often made independent purchases, and other

systems were inherited through mergers and acquisitions.

Thus, many companies ended up having

several instances of the same ERP systems or a variety

of different ERP systems altogether, further

complicating their IT landscape. In the end, ERP

systems became just another subset of the legacy

systems they were supposed to replace.

The Costs of Implementation

ERP systems were expensive, too, costing companies

more than they had ever paid for software

when costs had been based on per-workstation

usage. But that price tag was dwarfed by the installation

charges, because companies had to

hire brigades of outside consultants, often for a

number of years, to actually get the software up

and running. While the average installation cost

$15 million, large organizations ended up spending

hundreds of millions of dollars. Even such

large expenditures did not guarantee success,

however. In fact, 75% of ERP implementations

were considered failures.
7

Try as they might to measure the productivity

gains of ERP implementations or IT in general, researchers

have yet to arrive at any coherent or

consistent conclusions. One problem is that there

is little statistical evidence, especially about

whether the benefits of ERP implementations outweigh

the costs and risks. Researchers have even

suggested that ERP implementations are so difficult

that those companies that actually complete

them with relative success gain a competitive advantage

in the marketplace.
8 It seems that ERPs,

which had looked like the true path to revolutionary

business process reengineering, introduced so

many complex, difficult technical and business issues

that just making it to the finish line with one’s

shirt on was considered a win.

All that complexity and all those options created

another conundrum. As Nicholas Carr famously

pointed out in his book, Does IT Matter? Information

Technology and the Corrosion of Competitive

Advantage,
9 simply implementing the plain-vanilla

business processes that your competitors have does

not provide any competitive advantage. On the

other hand, as many companies learned the hard

way, customizing the already complex ERP software

created yet more complexity and even larger risks.

From Rough Type: Nicholas Carr’s Blog

http://www.roughtype.com/

“Over the last two decades, companies have plowed many billions of

dollars into enterprise resource planning (ERP) systems and the hardware

required to run them. But what, in the long run, will be the legacy

of ERP? Will it be viewed as it has been promoted by its marketers: as a

milestone in business automation that allowed companies to integrate

their previously fragmented information systems and simplify their data

flows? Or will it be viewed as a stopgap that largely backfired by tangling

companies in even more systems complexity and even higher IT costs?

In ‘The Trouble with Enterprise Software,’ Cynthia Rettig deftly lays out

the case for the latter view. Enterprise systems, argues Rettig, not only

failed to deliver on their grand promise, but often simply aggravated the

problems they were supposed to solve. Different divisions or facilities

often made independent purchases, and other systems were inherited

through mergers and acquisitions. In the end, ERP systems became just

another subset of the legacy systems they were supposed to replace.

So what’s the solution? Rettig doesn’t offer one, beyond suggesting

that top executives do more to educate themselves about the

problem and to work more closely with their CIOs. That may be good

advice, but it hardly addresses the underlying technical challenge. But

Rettig nevertheless has provided a valuable service with her article.

While some will argue that her indictment is at times overstated, she

makes a compelling case that the traditional approach to corporate

computing has become a dead end. We need to set a new course.”

— Nicholas Carr

24 MIT SLOAN MANAGEMENT REVIEW FALL 2007

CoNT R A R I A

sloanreview .mit .edu

Without intimate knowledge of how the integrated

pieces of these modular software packages actually

worked, customizing could lead to in-house bugs

and glitches that were hard to foresee and expensive

to fix. Perhaps even worse, customization made

changing the software later — or upgrading to a

newer version — far more difficult, and in some

cases prohibitively expensive. Christopher Koch,

executive editor of CIO, tells the story of one head

of a corporate SAP installation group who bragged

that he had his installation time down to a mere

three months for various facilities around the world:

“It didn’t matter that he was honing his skills on a

10-year-old version of the software because the

costs of upgrading are so huge — tens, even hundreds

of millions of dollars, or as much as it cost to

install the stuff in the first place — that he keeps installing

old versions of the software so that it will

line up with the old software they already have.”
10

Unexpected bugs present another type of difficulty

that increases with complexity. Robert

Pool, technology journalist and author of Beyond

Engineering, explains it this way: “It’s possible to

go through a program line by line and make sure

that each individual instruction makes sense but

it is not possible to guarantee that the program as

a whole has no flaws.”
11 The average professional

coder makes 100 to 150 errors for every 1,000 lines

of code, according to a Carnegie Mellon study

conducted by Watts Humphrey.
12 That means for

every million lines of code there would be 500,000

mistakes. Software developers do extensive testing

on the paths users seem likely to take and correct

many of these errors. Nevertheless, they cannot

test or even anticipate every possible usage path,

so released software inevitably contains unknown

defects. “Civilization depends on software. So although

much software code is poorly written, you

can’t just stop the world to fix it,” says Bjarne

Stroustrup, the Danish-born computer scientist

who designed the popular C++ programming

language. On the other hand, Stroustrup does

concede that “muddling along is expensive, dangerous,

and depressing.”
13

The Vagaries of Data

The data that software processes and generates is

another constant and growing problem. Estimates

of errors are astoundingly high. Single systems can

have error rates of 50% or more from myriad

sources — everything from mistyped data to stale

information to data placed in the wrong fields

within the database structure. But the really nasty,

intractable data problems erupt when companies

integrate multiple data sources, as was necessary

for ERP implementations, so that they could have

all their product, inventory and production records

stored in one place. Because of differing

formats, conventions, abbreviations and so on,

such integrations can result in a 100 or more records

that actually point to a single product or

customer. In the case of enterprise system implementations,

data problems alone precipitate many

of the failures perceived by business users and

much of the added expense as well. Overwhelmed

by the sheer difficulty and complexity of the new

software itself, companies literally “forgot about

the data,” as executive John Nicoli of Trillium Software

in Billerica, Massachusetts, describes it, until

the tail end of the project, thereby necessitating

enormous reworking to properly clean up and integrate

the data.
14 And with corporate data stores

From Andrew McAfee’s Blog

http://blog.hbs.edu/faculty/amcafee/

“It is certainly true that enterprise systems have failed in many companies,

and it’s also true that, as [Ms. Rettig] points out, many others have not

been able to shut off legacy systems to the extent they expected after ERP

went live. But it is simply not the case that researchers have been unable

to draw any coherent conclusions about these technologies.

Rettig’s argument falls into a long line of pessimistic writing about the

value of corporate IT. Much of this writing takes the implicit, and at times

explicit, view that the executives who make technology decisions are

dupes, perennially falling for a ‘triumphant vision’ of software. The only

way I can see for the IT pessimists to be right is if the delusion about IT’s

benefits is both persistent and virtually universal. And I don’t buy that.

‘ERP doesn’t help’ is a testable hypothesis, and some colleagues

of mine have tested it. NYU’s Sinan Aral, Georgia Tech’s D.J. Wu, and

my friend and coauthor Erik Brynjolfsson at MIT recently published a

wonderful paper, “Which Came First, IT or Productivity? Virtuous Cycle

of Investment and Use in Enterprise Systems” (http://papers.ssrn.com/

sol3/papers.cfm?abstract_id=942291). [This paper] contains a vital insight:

If IT were not delivering value, rational decision makers would not

keep investing in it.

I agree that it’s important not to naively accept anyone’s triumphant

vision of corporate IT. But it’s also important not to make claims in the

other direction that are too sweeping. Perhaps most fundamentally, it’s

critical at some point to stop floating hypotheses about IT’s impact (or

lack thereof), and to start testing them.” — Andrew McAfee

sloanreview .mit .edu FALL 2007 MIT SLOAN MANAGEMENT REVIEW 25

doubling every three years, such data issues are

only compounding.

Is enterprise software just too complex to deliver

on its promises? After all, enterprise systems

were supposed to streamline and simplify business

processes. Instead, they have brought high

risks, uncertainty and a deeply worrying level of

complexity. Rather than agility they have produced

rigidity and unexpected barriers to change,

a veritable glut of information containing myriad

hidden errors, and a cloud of questions regarding

their overall benefits. Leaders in computer science

are clearly worried. “Complexity is death,” says

Chuck Thacker, one of 16 technical fellows at Microsoft

Corp. “We are hanging on with our

fingertips right now.”
15

Business executives, however, simply want to

continue to believe that technology will lower

costs, improve processes and reduce the size of the

workforce. They don’t want to understand IT issues.

In part, this is because technology requires

special skills and intellectual talents that are quite

distinct from those needed to understand and

manage business organizations, markets and

strategy. But it is also because executives do not

like to hear about the downside of technology.

Observes Jim Shepherd, senior vice-president of

Boston-based AMR Research Inc., “Senior managers

often don’t particularly want to be told that

there’s a high risk and that there’s a great deal of

expenditure involved in minimizing it.”
16 Yet the

only sure thing about new technologies and the

changes they introduce is their uncertainty. In

summarizing decades of research into technological

change, MIT Sloan School of Management’s

Wanda Orlikowski and the National Science

Foundation’s Suzanne Iacono conclude that

changes involving technology are both “profoundly

complex and uncertain.”
17

For their part, CIOs and their managers rate aligning

IT with business strategy as their number one

priority. They struggle year after year to prove the

value of IT to the business side of the organization.

Yet the cost overruns, delays and outright failures of

enterprise systems have if anything widened the digital

divide between IT and the executive suite.

The Next New Thing

The proposed fix for these problems — the next

new thing — is service-oriented architecture. Basically,

SOA proposes to overcome the problems

involved with updating and changing legacy systems

by building modular cross-system business

processes. These processes would connect the relevant

pieces of functionality from various IT

systems, thereby making it easier to change processes

to adapt to new business goals. But technical

realists point out that many difficult technical

problems must be solved before SOA can become

the backbone for a new strategic architecture, including

robust protocols for accessing the

applications, high quality integrated data stores

and a sound methodology for managing the overall

process. Researchers Ross, Weill and Robertson

admit that most companies are in the early stages

of a four-part transformation to SOA that may

take many years — even decades — to realize.
18

The estimates of how long this will take reflect a

growing acknowledgment of just how deep and

From the ZDNet.com Blog

http://blogs.zdnet.com/service-oriented/?p=938

This article, originally published on the MIT Sloan Management Review website, stirred up

a good deal of discussion in the blogosphere. A sampling of that crosstalk is included here.

“There’s really nothing new in [Ms. Rettig’s] analysis. But Rettig goes a

step further and says there’s no hope for the future. In fact, while she

doesn’t offer any remedies for her gloomy prognosis, she does quash

one — service-oriented architecture (SOA).

Rettig doesn’t offer any encouraging words about SOA as an ERP

workaround. SOA may take years to come to full fruition, not in enough

time to help beleaguered companies, she says. And SOA may simply be

too slow to keep up the dynamic business environments of today. Not to

mention technical challenges. Rettig says that SOA increases complexity,

as it becomes “additional layers of code superimposed on the

existing layers,” and she doesn’t buy the Lego-block concept that underpins

much of the thinking about SOA.

Let’s put it this way: aside from SOA, what is the alternative? No one

is willing, or can afford to, to stay with the rigid, stovepiped systems in

their current form. One solution is just throw the entire mess out, and

buy a huge, well-integrated, modular application. But no one has the

time or budgets. The only workable approach, then, is gradual integration

between systems, and gradual, greater agility — if not through SOA,

then how? SOA, pure and simple, is the first step to software industrialization

— creating massive, adaptable systems in an automated and

modular fashion through greater economies of scale. ERP was a step in

this direction, since it modularized, and brought many vital pieces of

the business together into a single standardized system. SOA takes it to

the next level, beyond the domain offered by a single vendor. That’s the

core value proposition of SOA. — Joe McKendrick

26 MIT SLOAN MANAGEMENT REVIEW FALL 2007

CoNT R A R I A

sloanreview .mit .edu

radical are the organizational changes these technological

innovations mandate. It is a process of

adoption and adaptation that by definition cannot

occur overnight. Nor, conclude the researchers,

can companies skip a step. Given that only 6% of

companies have made it into the later stages, this

model would suggest that companies are in for a

long haul if they are to escape the tangle of technological

complexity inherent in large organizations

today, and it will be a journey fraught with cultural

as well as technical problems.

The timeline itself for this kind of transformation

may just be too long to be realistically

sustainable and successful. The dynamic business

environments of today, where whole industries and

markets can undergo radical changes in a matter of

a few years and the horizon for corporate strategies

has shrunk from 10 years to three to five, makes it

questionable whether companies can actually

maintain a focused strategy long enough to align

their core business processes with IT.

Technical problems raise additional questions

about the feasibility of such an undertaking. The

hallmark of service-oriented architecture — one

might reasonably argue its entire raison d’etre — is

the fundamental modularity of its software business

processes. A self-contained business process adopts

parts of the functionality from multiple enterprise

applications to automatically complete a set of tasks.

For example, a single business process might begin

with an order from a customer on the Internet in a

web services system and send it to manufacturing in

an ERP system. The same business process would set

up delivery in a logistics system and then send all the

relevant information to billing in an accounting system

as well as a customer relationship management

system. Companies would build (or purchase) business

modules for their core processes. They would

then be able to easily change these processes, snapping

out and in functional pieces of code from

enterprise systems in Lego-like fashion.

The Lego dream has been a persistent favorite

among a generation or more of programmers who

grew up with those construction toys. Unfortunately,

however, software does not work as Legos do.

For one thing, a unit of software code is not similar

to other software code in terms of scale or functionality,

as Legos are.
19 On the contrary, code is widely

various and heterogeneous. It contains different

numbers and types of connections to other code,

more like fractals, as Victoria University of Wellington

researchers James Noble and Robert Biddle

describe it, than Legos, with their uniform connections.

Software engineering expert Robert Glass sees

another problem with the Legos idea: The notion of

reusable software works on a small scale. Programmers

have successfully built and reused subroutines

of standard functions. But as software grows more

complex, reusability becomes a difficult or impossible

task. “It is simply a problem too hard to be

solved, a problem rooted in software’s diversity.”
20

“Complexity is a deadly software killer,” says Yale

computer scientist David Gelernter, and he argues that

managing complexity is more of an art than a science,

and a difficult one at that, especially given the monumental

real-world systems today’s software attempts

to automate.
21 And to the extent that these service-oriented

architectures use subsets of code from within

ERP and other enterprise systems, they do not escape

the mire of complexity built over the past 15 years or

so. Rather, they carry it along with them, incorporating

code from existing applications into a fancy new

remix. SOAs become additional layers of code superimposed

on the existing layers. That means it is possible

that a process will fail at some point due to some fault

in the layers below, and in order to understand and fix

that problem, software engineers will need to deal with

the layers of enterprise applications below the modular

business processes.

From the Deal Architect Blog

http://www.dealarchitect.typepad.com/

“The good news is [Ms. Rettig’s] article will get executive attention. Not

that they do not know. I recently met an executive at a client about to

start an ERP implementation. He sounded like a man headed to the gallows.

Nervous, not excited about the project. (That afternoon, I felt

really embarrassed for our industry that after 100K+ ERP projects, we still

cannot make it a no-brainer.)

But it is way past talking about messes. Companies are in various stages

of ERP hangover management, not always looking at software as a service

(SaaS), as those vendors would have you believe — it’s not that easy to rip

and replace a backbone ERP solution — but software as a customized service

(SaCS). [Those companies are in] aggressive re-negotiation of ERP

maintenance contracts or moving to third party maintenance.

The only ones who do not seem to realize the party is over are the

vendors, who are using service-oriented architecture (SOA), compliance

and more low payback justifiers to extend the run.

— Vinnie Mirchandani

sloanreview .mit .edu FALL 2007 MIT SLOAN MANAGEMENT REVIEW 27

Culturally, this long-term plan calls for closer and

closer communication and collaboration between

the IT and business sides of the organization. While

much to be desired, this has proved difficult in the

past, and with increasing complexity in software systems,

it is unlikely to improve by itself in the future.

Differing backgrounds and perspectives, goals, even

vocabularies — all hamper efforts to improve communication

across this internal digital divide. Biases

intrude: A recent study by Forrester Research Inc. of

Cambridge, Massachusetts, found that only 28% of

CEOs thought their CIOs were proactive or creative

in terms of business process improvement.
22 Forrester’s

advice to CIOs is to get more deeply involved

in the business issues and educate executives on what

IT is and what it actually does.

Sound advice, no doubt, but it may be time for

business executives themselves to become more

proactive. Executives could educate themselves

more about technology. They could send promising

younger executives to executive programs

designed to teach business people how to better

understand, communicate with and capitalize on

their IT. And business schools, too, could do better

at teaching the interdependence of business and IT.

At present, however, corporations see in software’s

seductive invisibility and seemingly open-ended

flexibility a never-ending frontier of promise,

where hope triumphs over reality and the search

for the next new thing trumps addressing difficult

existing problems. And hope, unfortunately, has

never been a very effective strategy.

Cynthia Rettig was director of knowledge management

for B2B consulting company Canopy International of

Newton, Massachusetts. She has consulted to software

companies for over 20 years. She can be reached at

cynthia.rettig@rettigtech.com.

REFERENCES

1.
T. Friedman, “The World Is Flat: A Brief History of the

Twenty-First Century” (New York: Farrar, Straus and Giroux,

2005), 128.

2. J. Dedrick, V. Gurbaxani, and K.L. Kraemer, “Information

Technology and Economic Performance: A Critical

Review of the Empirical Evidence,” ACM Computing

Surveys 35, no. 1 (March 2003): 18.

3. J.W. Ross, P. Weill, and D.C. Robertson, “Enterprise

Architecture As Strategy: Creating a Foundation for

Business Execution” (Boston: Harvard Business School

Press, 2006), 11.

4. J.W. Cordata, “Progenitors of the Information Age:

The Development of Chips and Computers,” in “A Nation

Transformed By Information,” eds. A.D. Chandler and

J.W. Cordata (New York: Oxford University Press, 2000),

206-208.

5. R.L. Glass, “Facts and Fallacies of Software Engineering”

(Boston: Pearson Education, 2003), 58.

6. M. Campbell-Kelly, “From Airline Reservations to

Sonic the Hedgehog: A History of the Software Industry”

(Cambridge: MIT Press, 2004), 198.

7. K-K Hong, Y-G Kim, “The Critical Success Factors for

ERP Implementation: An Organizational Fit Perspective,”

Information & Management 40, no. 1 (October

2002): 25.

8. L.M. Hitt, D.J. Wu and X. Zhou, “Investment in Enterprise

Resource Planning: Business Impact and

Productivity Measures,” Journal of Management Information

Systems 19, no. 1 (summer 2002): 71-98.

9. N. Carr, “Does IT Matter? Information Technology and

the Corrosion of Competitive Advantage,” (Boston: Harvard

Business School Press, 2004).

10. C. Koch, “The Monopoly That Matters More Than

Microsoft,” blog in CIO Magazine, Nov. 13, 2006, http://

advice.cio.com/the-monopoly-that-matters-more-thanmicrosoft.

11. R. Pool, “Beyond Engineering: How Society Shapes

Technology” (New York: Oxford University Press, 1997),

137.

12. C. Mann, “Why Software Is So Bad,” Technology

Review (July/August 2002).

13. J. Pontin, “Bjarne Stroustrup: The Problem With Programming,”

Technology Review (January-February

2007): 22.

14. J. Nicoli, interview with author at Trillium Software

(Billerica, Massachusetts), August 8, 2005.

15. S. Rosenberg, “Anything You Can Do, I Can Do

Meta,” Technology Review (January-February 2007): 45.

16. M. Wheatley, “ERP Training Stinks,” CIO Magazine

(June 1, 2000).

17. W. Orlikowski and C.S. Iacono, “The Truth Is Not Out

There: An Enacted View of the ‘Digital Economy,’” in

“Understanding the Digital Economy: Data, Tools and

Research,” eds. E. Brynjolfsson and B. Kahin, (Cambridge:

MIT Press, 2000), 355.

18. Ross, “Enterprise Architecture As Strategy.”

19. S. Rosenberg, “Dreaming in Code: Two Dozen Programmers,

Three Years, 4,732 Bugs, and One Quest for

Transcendent Software” (New York: Crown Publishers,

2007), 94-95.

20. Glass, “Facts and Fallacies of Software Engineering.”

21. D. Gelernter, “Mirror Worlds: Or the Day Software

Puts the Universe in a Shoebox … How It Will Happen

and What It Will Mean” (New York: Oxford University

Press, 1992), 51.

22. S. Shay, “CEOs Rate IT: Steady But Uncreative,”

CIO Magazine (April 1, 2007): 20.

Reprint 49101. For ordering information, see page 1.

Copyright © Massachusetts Institute of Technology, 2007.

All rights reserved.