October 2005 Early Indications newsletter I: New technologies mean new business choices

Early Indications is published twice monthly by the eBusiness Research
Center at Penn State University. The author holds no direct financial
stake in any of the companies mentioned.


"In the Web 1.0 era, when a company raised $10 million, they spent $2
million on servers from Sun, another $2 million on software from BEA,
another $2 million on Oracle software, and then they'd have only $4
million left to actually build the thing."

-David Hornik, venture capitalist at August Capital, speaking
at the Web 2.0 meeting, quoted in the Boston Globe, October 10


"Here's what we're going to do. We're going to go out, and we're
either going to buy Oracle financials or SAP. That's a $5 million
plus or minus purchase. Plus consulting [fees]. . . . I said, 'Look -
I have been through so many general ledger conversions in my life . .
. I'm not going through another conversion [off of Great Plains] when
we get to be a $100 million company.'"

- Jim Barksdale, speaking in 1997 of his early days at Netscape,
in Michael Cusumano and David Yoffie, Competing on Internet Time


As Jared Diamond posited in his Seminal Guns, Germs, and Steel,
there's often a tight connection between resources and destiny. Less
important than the quantity of a resource, however, is its fit with
human or market need. Much like the Maginot line, corporate barriers
to entry (assemblages of resources) can turn out to be competitive
liabilities as speed, focus, and agility frequently trump mass. Right
now Ford and GM are jettisoning as much excess baggage as possible,
for example, perhaps noting that neither Honda nor Toyota run car
rental companies, own satellite factories, or build military armored
vehicles. By contrast, Netscape built infrastructure in anticipation
of rapid growth, correctly as it turned out.

Businesses can be built of many resources: material, human, financial.
More recently, economists including Paul Romer have contended that
innovativeness itself is a resource: the world might run out of oil,
in this line of argument, but it can't run out of creative people
motivated to solve energy problems. There's also the matter of
intangible assets like patent portfolios, branding, and capabilities
in employee selection and training. The factors of production have
expanded beyond the original land, labor, and capital.

Technology is of course a core business resource. In the developer
and IT management communities, the acronyms are running particularly
hot and heavy right now. Between AJAX (1), LAMP(2), two flavors of
OSS, RSS, and CSS, people who write code have a wide range of
lightweight, network-centric tools at their disposal. Many of these
standards are supported by free and/or open-source software, and many
expand the repertoire of the web browser to behave more like a thin
client of a "real" computer. (For examples, see Google Maps or Gmail,
Web Boggle (http://weboggle.shackworks.com/4x4/), backpackit.com,
Microsoft Outlook web access, Flickr, or even enterprise-grade
applications like NetSuite.)
(1) Asynchronous Javascript and XML
(2) Linux, Apache, MySQL, Perl/Python/PHP

These new kinds of software tools and materials are in the process of
changing not only the technology world, but the business and social
environment. Think about the history of building: when structural
steel and fast elevators became available, Louis Sullivan and his
successors built buildings that would have been inconceivable only
years earlier. What would major modern cities look and feel like if
buildings were only 10 to 15 stories tall? When powerful air
conditioning became sufficiently cheap and reliable, the American
South and Southwest underwent a development boom that persists to the
current time. Resources shape destiny, again and again.

The relationship between the nature of technology and business
potentialities reminded me of my colleague Dave Robertson's very pithy
explanation of the delicate business of getting information technology
and business decisions to reinforce each other. I'm paraphrasing:

"Let's compare a business to a vehicle. You could choose to be a dump
truck, or a hybrid, or a sports car. None of these are inherently
better than the others until we know whether the context is family
driving with $4 gas, or building highways, or racing. Once a business
decides what kind of business it needs to become, a gravel hauler or a
dragster, you look under the hood: IT is the vehicle's engine. A
cogenerating electric motor probably won't power the dump truck, while
dropping a Hemi into a hybrid would just be wrong. Each engine is
right for a certain kind of vehicle, but again, it all depends on
context."

Dave, who's a professor at IMD, goes on to say that this metaphor
provides a way into his research, soon to be published, into the
intricate but essential matter of getting business architectures and
technology architectures to reinforce each other. (His co-authors are
Jeanne Ross and Peter Weill of MIT's Center for Information Systems
Research.) If a retailer is positioned to deliver high-quality men's
wear at a premium price, for example, late shipments, sloppy customer
records, and slow network connections will undermine that strategy.
On the other hand,
plenty of successful service businesses, including banks and
universities, still run green-screen mainframe or minicomputer
applications, complete with batch processing and poor access to
analytical data streams.

Both business architectures and technology architectures are creations
of the organizations they inhabit: formal methodologies and
prescriptions, while they have a place, will not in and of themselves
build either a sturdy chassis or an engine that will fit both that
chassis and its real-world requirements. It's one thing to decree
data quality standards and quite another to understand how and where
conflicting or erroneous entries are introduced. If a business
intends to expand internationally, is it hiring employees who are
multilingual and can operate across cultures? Are computer systems
ready for multiple currencies, multiples time zones, and multiple
process maps? Similarly, it's one thing to say "our customer always
comes first" and something quite different to give employees the
training, managerial cover, and career incentive to act on the
rhetoric.

By noting the wider acceptance of Linux, Python, or
software-as-service applications, do I suggest that every IT shop
throw out its Rational methodologies, Microsoft developer suite, or
Oracle databases? By no means. Being aware of available resources
informs choices, including the decision to stand pat. A building
architect needs to be informed of the state of available materials so
he or she can choose to incorporate glass-and-steel curtain walls (as
at the United Nations building), curvilinear reinforced concrete (the
Guggenheim), or self-weathering Cor-Ten steel (the Chicago Civic
Center). But just as not every building is a landmark, most
technology environments will not rival WalMart's or Google's. Even
so, good IT architecture is no less important, whether the
environment's job is to run unobtrusively but reliably, or whether IT
_is_ the business, as at Amazon or Morgan Stanley.

Who's responsible for constraining and enabling the architects'
technology choices, of being the client as it were? In a recent
article in Harvard Business Review, longtime IT authorities Richard
Nolan and Warren McFarlan contend that IT governance begins with the
board. Following that logic, it's both appropriate and necessary that
business and technology executives learn what extreme programming
looks and feels like, or where PHP can work better than Java, or what
Linux actually costs and delivers relative to proprietary Microsoft and Unix.

Just as hybrids aren't inherently better than diesels and dump trucks
aren't superior to Priuses, so too for information technology: it's
not a matter of choosing the "best" technology, but the one that fits
(and perhaps reshapes) its context. In the quest for better, and
better-fitting, business and technology architectures, a working
knowledge of the rapidly evolving set of alternatives is too valuable
to be left to technologists alone.