Monday, November 21, 2005

November 2005 Early Indications I: The word salad relating to "services"

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.

If one ventures into the enterprise software world, the sheer volume of verbiage devoted to variations on the words "service" and "services" is bewildering, especially because a server, which confusingly can be either hardware or software, is unrelated to services. Web services are related to but not synonymous with service oriented architectures (SOAs), some of which can be implemented using an enterprise services bus (ESB). Public examples of SOA-like behavior can be found in the much-better named category called mashups, examples of which can be found below.

At the macroeconomic level, meanwhile, the services sector (which is really several sectors, as UCLA's Uday Karmarkar has noted) is crowding out products companies as the dominant force in gross domestic product. In the middle between code and Alan Greenspan, marketers worry about satisfaction ratings for customer service (including self-service) in the transaction process, while aftermarket repair and maintenance is yet another kind of service. Finally, there are transactions in which activities are performed in conjunction with a product purchase: software implementation is one such service.

According to the Oxford English Dictionary, "service" has at least five different meanings that could apply to the current confusion:

-the action or process of performing duties for
-an act of assistance
-the process of attending to a customer in a shop
-a system supplying a public need such as transport, or utilities such as electricity and water
-a periodic routine inspection and maintenance of a vehicle or other machine

(The root word, servus, means "slave.")

IBM has launched a research initiative into what is now being called Services Science, Management, and Engineering (SSME). According to the initiative's website, "A service is a provider/client interaction that creates and captures value." Elsewhere, an IBM Software page answers the question "What is an SOA?" this way:

"SOA is the blueprint for IT infrastructure of the future. SOA extends the Web services value proposition by providing guidance on how enterprise IT infrastructure should be architected using services."

But it's clear that the software folks do not intend that such architectures should use "provider/client interactions that create and capture value." Given this wide semantic variation, it will not come as a surprise that measuring services is problematic. At the economic level, what is the productivity of a teacher or programmer? The input-output metric used for mechanical efficiency breaks down, but no model readily presents itself as an alternative. There is substantial promise in the area of supply chain research however, insofar as networks of people in various roles perform tasks to accomplish a process. At a sufficient level of abstraction, treating some kinds of medical patients, building software, and delivering fresh strawberries do share metrics, constructs, and success factors.

Measurement of services is important for many areas, particularly where money is concerned. Thus a network provider might have a service level agreement (SLA) with a customer, that throughput will never fall below a given threshold and downtime is expected to be 30 minutes a month, never falling between 8 am and 6 pm, etc. Confusingly, because a services-oriented architecture runs across a network or set of networks, it requires a service level agreement from the provider of the network. The "S" is SOA has nothing to do with the one in SLA.

One further thought. Does customer satisfaction measure what was delivered by the provider, or what was experienced by the customer? For this discussion, "service" can be understood as retail or hospitality, professional services like law or consulting, and possibly more. Major corporate effort is expended in the area of increasing customer satisfaction, usually in operational improvements. It may not be the best place to apply effort, however. If satisfaction is understood as the congruence between expectation and experience, some of that spending on operations could be redirected into negotiation, getting customers to reset expectations rather than trying to meet unrealistic ones.

A cab ride is a service. Going from midtown Manhattan to LaGuardia at 1 pm on a weekday can take 25-45 minutes, while doing so at 5:15 is a very different proposition. Weather makes matters worse. If, however, a driver takes an hour in the middle of a sunny day because of inexperience or other driver-related factors, the rider is right to be irritated. The point here is that much effort is expended in trying to define service levels for a wide range of contingencies. Alternatively, it may make more sense to educate customers into the factors, both in and out of the provider's control, that influence service performance.

The broader issue of confusion over service, service levels, and service economics will get worse before things improve. That the language is insufficient probably relates to the relative newness of the swings from products to services, and from applications that run on processors to services that run over networks. I can only hope that just as "horseless carriage," a lame extension of a soon-to-be outdated name, gave rise to a rich vocabulary of automobile language, so too can we get more words like "mashup" and fewer bureaucratic three-letter acronyms that usually define reality neither vividly nor accurately.

Mashup examples:

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 (,,
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

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

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.