November 11, 2002
Case Study: General Electric Co.

GE's Drive to Real-Time Measurement
By Dave Lindorff

CIO Insight

What Is a Real-Time Company?

A company that competes by using up-to-date information to progressively remove delays to
the management and execution of its critical business processes.

The business goal: To save time and money by responding faster to events and by reacting
more flexibly to rapid shifts in the marketplace.

The technology risk: Business activity monitoring can reap more information than
managers know how to manage or harness into meaningful responses.

The management risk: A tendency to micromanage at the expense of stifling innovation and
creativity—and a danger of focusing less on longer-term strategic goals.

Results so far at GE: Some cost cutting achieved; no influence yet on revenues but some
change in purchasing and sales strategies.

The Real-Time Enterprise: Powering Profits with Process Automation , By Joe Bellini and
Peter Fingar, Meghan-Kiffer Press, January 2003

Gary Reiner, CIO of General Electric Co., leads a visitor over to the far side of his spacious
office at GE's Fairfield, Conn., headquarters and takes a seat at a large table, on which the
only objects are an unusually large keyboard and what looks like a PlayStation game
controller. Before him, a huge, elongated flat-screen display panel is mounted on the wall.
Like a kid at a game console, Reiner, in shirt-sleeves and open collar, punches a few keys.
Suddenly at his fingertips and on display on the screen is an array of green, yellow and red
which, on closer inspection, resolves itself into diagrams that signal the status of software
applications critical to GE's day-to-day operations.

Reiner calls up the main screen for GE's plastics operation, which flashes a series of green
lines (green is good) and a few yellow lines (which mean a certain operation is not running
as efficiently as it could). At the moment, there are no red bars on the screen. Otherwise,
Reiner says, he'd be pounding away at his own keyboard, sending an e-mail to the
appropriate division manager asking for an immediate explanation.

Reiner's goal: to monitor, once every 15 minutes, GE's mission-critical operations—which,
on his priority list, are sales, daily order rates, inventory levels and even savings from
automation across the company's 13 different businesses around the globe. These "digital
cockpits," graphical depictions of up-to-the-minute business performance across GE's
landscape, are checked regularly by electronic robots that send test transactions through the
system—tests that should take four seconds to complete, and which likewise trigger an
automatic e-mail warning, or inquiry, when yellow or red becomes the color of the moment.
"The idea is to respond faster to change, reduce cycle times and improve risk
management," Reiner says. "We are not waiting for end-of-the-month or end-of-the-quarter
or even end-of-the-week results anymore before we act. We now respond continuously."

Welcome to the frontlines of the real-time revolution, where response time means money.
Since the dawn of machine automation, managers have sought to build processes that
speed their ability to respond to change, but the real-time revolution promises to transform
companies into complex sensing organizations that use everything from radio frequency
sensors to global positioning satellites and worker-monitoring software to run everything
from their in-house payroll departments to remote factories across the globe—and at
speeds and split-second reaction times that, in some operations, will far exceed humans'
ability to gather, process, analyze and respond on their own.

Driven by increasing pressure to cut costs and become faster and more responsive to
increasing volatility in the marketplace, GE is one of a handful of giant corporations, from
computer chipmaker Intel Corp. to Iberian fashion dynamo Inditex Group, that is fast
becoming a digitized enterprise where every process, down to the activities of every
production worker and the details of each minute financial transaction, is at least
theoretically accessible to successive layers of plant managers and ultimately to top
corporate managers.

It's a brave new world, and cockpits are just part of the equation: When GE started to digitize
its business two years ago, it also began to buy and sell online and, more important, started
creating a digital nervous system that connects anything and everything involved in the
company's business—IT systems, factories and employees as well as suppliers,
customers and products. GE's aim, says Reiner, "is to monitor everything in real time,"
whether by using sensors to gauge performance of jet engine machinery operated by GE's
customers or tracking which customers paid on time and what it would take to get them to
make their payments faster.

Reiner, who is leading GE's digitization drive and was the first GE executive to use the
cockpit, calls GE's digitization strategy "e-buy, e-make and e-sell." E-make, using digital
cockpits, is all about GE's effort to interact faster within its own operations. E-sell, on the
other hand, aims to hasten interaction with customers: GE's Polymerland Web site, which
helps customers research GE's resin products and prices, has been cutting phone calls to
service reps by up to 300,000 calls per year, boosting the speed at which GE responds to
customers while at the same time shrinking the unit's costs by 35 percent over five years,
with more savings under way. By digitizing sales, says analyst Nick Heymann, who tracks
GE for Prudential Financial, GE has also speeded up service—and has cut 60 percent from
the costs out of selling GE's vast array of products, from dishwashers to polymers.

E-buy is also about interacting better and faster—but with suppliers. In 2001, says Reiner,
GE saved more than $680 million through Web-based auctions. And there were time
savings as well: "Before," says Reiner, "sometimes a buyer didn't quite know what was
expected of him or her in terms of what they should buy for a particular commodity, and
they'd go out and cut their own deal." Now, he says, such deals are no longer acceptable.
The result? "The new system forces people to buy off prenegotiated contracts," Reiner says.
"This saves time, saves money and keeps us from wasting effort on transactions that will
ultimately have no value."

Speed gains also show up in billing. Steven DeLarge, manager for global financial planning
at GE Power Systems, says that simply by collecting more data on customers who were late
in paying their bills, GE was able to be more effective in getting them to pay on time, for a
savings of $6 million in interest. "With this system, you can get the payment information to
the front end faster, and then have the salesperson do the collection call instead of having to
use a collector," DeLarge says.

But GE isn't the only company keen on getting faster. In years to come, many experts say,
many more companies will use information technology to become a "real-time
enterprise"—a company that can react within seconds to changes in its business. And as
more and more firms wire themselves up and connect to their business partners, they make
the entire economy faster. "What businesses like GE are creating is an explosive cocktail of
time-based change that will rip out inefficiencies in our organizations based on our ability to
gather, use and disseminate information," says Gartner research vice president Andy Kyte.
"Wasting time will seem as stupid as wasting money itself."

To be sure, in the current lackluster economic climate, it's little wonder that vendor hype has
sprung up around the concept of the real-time enterprise: Gartner's annual schmooze-fest in
Orlando in early October was all about real time, as are nearly a dozen conferences in the
coming year, from Chicago to Berlin. But while experts acknowledge that getting to real time
will require, in many cases, significant new levels of technology investments, the push for
real time isn't all hype, either. Indeed, in a cost-cutting climate, real time can mean real
savings. For its part, GE estimates that its digitization efforts saved the company $1.6 billion
last year. "We said we'd cut $10 billion in costs in five years, and we're already a third of the
way there," Reiner says.

According to Gartner vice president and research fellow Roy Schulte, the elapsed time of
individual processes at e-businesses around the globe is already beginning to accelerate.
Responses to call-center inquiries, for example, have gone from eight hours as of a few
years ago down to 10 seconds today; refreshing a data warehouse has accelerated from
one month to one hour; and the time it takes to build a custom-made PC has gone from six
weeks to 24 hours, to name a few examples. Schulte predicts this acceleration has just
begun and that process times will speed up even more, triggering a huge impact on the
inner workings of companies large and small. For the strategic CIO, he says, the movement
to real time will mean "increasing the velocity of business processes, and to get this kind of
speed the CIO is going to have to rethink how he or she designs computer systems."

Shots in the Dark

Yet as GE's cockpit shows, the real-time movement is also about strategic advantage: being
able to monitor business continuously and react when conditions change. "Today,
businesses mostly shoot in the dark," says Michael Maoz, a research director at Gartner and
one of the pioneers of this concept.

In addition, real time means the ability to use newly available information to offer new
products and services—or, simply, to have a window into operations that wasn't available
previously. In 2000, GE's consumer appliance business installed online kiosks in selected
branches of The Home Depot. Today, customers can order an appliance, select a delivery
date and time, and be told instantly whether their request can be met.

Internally, says GE Power Systems' DeLarge, the use of cockpits has eliminated the need
for weekly operations reports. "In the past, some operating numbers weren't available until
the Saturday of each week," he says. Now, information is loaded continuously into GE's
cockpits and, he says, "in the case of past-due invoices, for example, salespeople know
how much leverage they have over price in the field and can act on operations figures right
away."

To be sure, it takes money to make or save money: Gearing up to real time will require
companies to make massive new investments in software, sensors and other technologies.
According to Reiner, GE so far has spent about $1.5 billion in employee time, hardware and
software and other expenses, which works out to a roughly 33 percent return on investment
per year over the five years of the project.

Advocates and experts on the subject of real-time operations say a 50 percent to 100
percent return on revenues should be possible. "Basically, every 1 percent of revenue you
spend on real time should give you a 1.5 percent to 2 percent revenue increase as payback,"
says Vinod Khosla, a partner at the venture capital firm of Kleiner Perkins Caufield & Byers,
and one of several experts widely credited with coining the term "real time." Says Khosla, "If
you're not getting that kind of return, either you've already spent so much on IT that you have
wrung out a lot of costs already, or you have a poor IT strategy."

But while this new digitization process carries much promise, it also poses some significant
management and operational challenges—at GE and elsewhere. In the view of Eric
Clemons, professor of information management at the University of Pennsylvania's Wharton
School, what businesses need to do is follow the model of the U.S. Marines. "Current Marine
war-fighting doctrine says you cannot have micromanagement. You have to permit local
decision-making with distributed responsibilities and trust without monitoring"—precisely,
he says, the opposite of the command-and-control digitized model being developed at GE.

And real time will cause labor dislocations, experts caution. Real-time initiatives, as they
spread through the economy, could lead to an increase in unemployment of 2 percent to 2.5
percent because of labor-saving improvements in technology, says John Parkinson, chief
technologist at Cap Gemini Ernst & Young. Adds Ann Bartel, a professor of human resource
management at Columbia University's Graduate School of Business: "Just the shift toward a
more monitored workplace will affect the quality of workers' lives and change the way
workers are used to working, creating significant management challenges."

Indeed, taking a glimpse at GE's experiences so far on the road to real time, such
predictions don't sound entirely hollow. John Seral, vice president and CIO of GE's IT and
e-business, says that as GE's plastics division moved from a traditional business model to
real time, with digital cockpits in managers' offices, "the company was able to eliminate all
the people who were producing data and spreadsheets on a regular basis"—for a savings
of $3 million in payroll costs last year alone. During Gartner's conference on the real-time
enterprise, research vice president Carl Claunch told assembled executives that "in
businesses being transformed by e-business and real-time strategies, there will be 10
percent fewer workers on the payrolls by 2005."

Larrie McNary, president of International Union of Electrical Workers Local 701 at GE's
aircraft engine plant in Madisonville, Ky., says workers there have mixed feelings about the
company's real-time initiative. "It's a way for the corporation to analyze whether or not a plant
is getting the most work effort and productivity, and I've seen how the whole environmental,
health and safety information is now on the digital system," McNary says. "Of course, GE has
always tried to see which of its operations is going to be profitable, and this is now a means
by which GE can continuously keep track of each division via real time. From a business
point of view, it's good. But for us, it's quite the opposite. It gives management a
minute-by-minute comparison of the cost factors for each of its sites and each part being
produced."

McNary says digital cockpits let GE "slop back and forth as to whether Madisonville should
be making 70 percent of a part or whether the Evendale, Ohio, or Lynn, Mass., plants should
be making it instead." In this way, McNary says, GE managers can play one plant against the
other. "It's really a work speedup, a way to get people to run more parts in less time—and at
no extra pay. Those who can do it the fastest get to keep their jobs." McNary says workers
and managers at the plant have already "had some skirmishes about it. All the monitoring
has been quite an issue at our site, and it's going to be a growing problem in
labor-management relations. It's something we'll be addressing at our next contract
negotiations."

And there's another potential speed-bump on the road to real time: While geared to make
firms better and faster at responding to change, real time also threatens to make firms far
more vulnerable to change—and far more difficult to control and manage well.

The financial markets have already shown that putting even parts of the economy on
autopilot can lead to accidents. A stock market crash in 1987 was caused in large part by
automated program trading. Further, even the best technology can offer no protection
against bad management decisions: Cisco Systems Inc., for its part, got hit a year ago by a
classic "bullwhip effect" and had to write off $2.5 billion in inventories because its order
books failed to reflect real demand. Cisco managers refused to believe the dramatic
changes in the numbers that their automated systems were showing them, and got stuck
with components already ordered from suppliers. "The idea of corporate cockpits at GE is
good, but the key is how good is the information in that cockpit—and how ready are we to
believe the machines we set up to monitor this stuff?" says Fred Meyer, chief strategy officer
with Tibco Software Inc., a business integration company that has constructed digital trading
floors for Wall Street investment banks. "This is a great place for the concept of garbage in,
garbage out," he says. "It's a great place for a powerful person to make decisions based on
yesterday's news."

Management Challenge

Reiner acknowledges the need to manage things differently under real time, saying the
company's management structure and approach have changed enormously over the past
four years to accommodate some of the new challenges being brought on by the real-time
movement. Yet he says that "real time" is also a bit of a misnomer. "Right time" might be a
better way of looking at it, he says: Few operations at GE outside of finance need to be
monitored on a minute-by-minute, much less a real-time, second-by-second basis. "Most of
our monitoring is daily or weekly," he says, "or at eight-hour intervals." While it might be
technically possible to monitor much more rapidly, there is little or no advantage to be
gained from such an increase in data, experts agree.

Still, according to Lynn Boyd, manager of information development at GE, there are cultural
speed bumps that must be negotiated. Even within IT at GE, she says, the digitization drive
has led to a "significant restructuring" of the company's information management training
program, "especially the two-year, entry-level program for IT people." Specifically, it has
become much faster paced, and a lot less site specific. "The business problems they're
dealing with now, which used to involve business planning, now increasingly revolve around
digitization," explains Boyd. "You could find yourself working on a project with maybe two
people here in our Fairfield office, and another 30 working on coding in Bangalore, India."
Clearly, holding a meeting under such circumstances will continue to involve, among many
things, whole new levels of uncertainty and collaboration.

Analysts credit GE with having the management discipline built into the culture so that the
movement toward more automation might be easier than at other companies. For his part,
Reiner says he sees the real-time movement as an extension of GE's already relentless Six
Sigma quality drive, which he helped spread through the company when he was promoted
to CIO in 1996. Like vigilant quality controllers, he says, GE will continuously monitor time
savings as passionately as it does quality improvements. "The technology is going to keep
getting better and will keep wringing out costs," he asserts. So when will GE be fully
operating on real time? "It's going to take forever," he says. "Like quality, it's something you
are always looking to push further."

But can GE and other organizations change fast enough without risking greater, hidden
costs down the road? The experiment so far at GE is unquestionably benefiting the
company's push to cut costs, even as the initiative is still being put in place. But it's also
flashing some early red and yellow warning lines of its own about the risks of moving toward
real-time enterprises. Says CGE&Y's John Parkinson: "Technically what they've done is very
impressive, but it may well be a house of cards." Adds Gus Stuart, a professor of game
theory and business strategy at Columbia University's Graduate School of Business: "GE
and other companies should be very excited about the potential of real time, but there will
need to be a whole new cultural adjustment to make it happen.…My guess is that there will
be a huge growth in the IT consulting business, because some managers are going to
botch this, big time."

Dave Lindorff has written for such publications as The Atlantic Monthly and BusinessWeek

The Power of Now at GE

$1.6 billion saved last year from digitization, roughly 16% of the $10 billion GE expects to
save annually by 2006

$3 million saved by GE's plastics division on payroll costs so far from switching to digital
cockpits

$100 million freed up by digitizing inventory, accounts payable and receivables

$6 million saved in interest payments last year by knowing which customers paid bills late

5% improvement in GE Power Systems' inventory turns, and 10% hike in receivables
turnover

$680 million cut from total purchasing costs last year by using online auctions

2 Times as many customers per salesperson can be handled, thanks to cockpits that guide
price and sales

Case Study: General Electric Co.

Creating the Real-Time Manager

CIO INSIGHT: You've put so-called "digital cockpits" in the hands of managers throughout
GE. What are they and how do they work?

The goal of the cockpits is to get information to individuals as quickly as possible with as
little cost to the back office as possible. The cockpits are for management decision-making
and to better enable managers' reactions. Every business in GE has its own type of digital
cockpit. Most businesses will have 10 to 20. For example, the sales leader will have one.
The manufacturing leader will have one. The engineering leader will have one. That's per
business unit, around different sets of metrics. Engineering will have cockpits around the
status of projects under his or her purview. They'll be able to know the status of projects all
the time. Manufacturing will have cockpits on yields, by machine. Sales and marketing will
have orders per day, per customer. And for our short-cycle businesses, if something is off,
the metric will turn red and typically the sales leader will get an e-mail automatically, saying
we're off on this particular customer in this particular region on this particular day. Machines
are sending automatic e-mails to a particular manager in charge of a process that's running
into questionable operation.

Okay. I get an e-mail. What then?

It depends on each manager's personal style. Most people will forward that e-mail to the
relevant person who has to fix it and tell them to fix it. Within IT, every business has its own
digital cockpit. We're now organized around 13 businesses, but even within those
businesses, there are sub-businesses that will have their own digital cockpits as well. So
we're talking roughly 50 in all.

These cockpits track the performance of all our mission-critical applications. When they fall
below a certain yield, then the CIO of that business and I get automatic e-mails
simultaneously, and then my job is to take action on those signals. Also, on a daily basis, I'll
look at an overall cockpit, which is the aggregation of all of these individual business
cockpits, to see which applications are having trouble. These are all cockpits built by IT with
input from the business side. Take the sales cockpit as simple example. Sales and IT in
collaboration designed it, IT built it, sales uses it and IT maintains it, and we stay in
alignment that way. Marketing also has its own cockpit, built in cooperation with us.

Speeding Procurement

You're also using IT to speed procurement.

This year we will do about $18 billion in e-auctions. Suppliers bid for our business over our
Web-based application. It saves us incrementally over $1 billion a year. What we try to do in
every way possible is to ensure there's competition in our supply base, just like our
customers do with us.

We also do purchase orders digitally. Say somebody wants to buy a computer. They go into
our database of prenegotiated contracts, select the computer available to them, and then a
message gets sent to that person's approver, saying: "Do you approve of this person buying
a PC?" If the answer is yes, then an EDI signal takes that order and puts it directly in the
order-entry system of the supplier. This ensures that the people who do buy are buying off
prenegotiated contracts. Before, you had a number of situations where a buyer would go and
cut his or her own deal. For doing that, GE would pay a higher price, and there wouldn't be
the same kind of controls over whether they could buy a particular item in the first place.

How is IT being used to boost sales?

Take, for example, one of our businesses in the financial services area. When a
salesperson would cut a deal with a customer in the past, it would require approval from GE
headquarters. Oftentimes, the customer would get upset because they'd get an agreement
with the salesperson and then headquarters would sometimes reject the deal. So we put in
place a Web-based wizard that allows the salesperson to put into the application the
specifics of the deal and create a map in the red, yellow and green metrics format. Green in
this case means the likelihood that the deal would be accepted. It's all based on artificial
intelligence, where you put rules into the application, so the salesperson knows if the
proposal they're considering is green, yellow or red—red means it will get rejected, yellow
means "call—we have to discuss," and green means approved. The payoff? Approval times
are faster, people are not working on bad deals anymore, and, you get much happier
customers because they can get feedback right away. We've doubled the capacity of
salespeople.

What's next?

Being able to make decisions even faster, and being able to have your processes operate
even faster. Our management team has changed enormously in the last four years in terms
of its comfort level with this stuff. The big change will be when wireless really works. Then
you free up sales and service people to really do their jobs remotely. That's the next great
leap. Linux is also going to be a big technology changer as well, because it's going to allow
you to do a lot more on cheaper platforms. We are using a lot of Linux, and we are rolling out
more and more of it.

How does the move to real time tie in with GE's famous Six Sigma quality push?

Six Sigma is a five-step process: Define the scope of the process you're focusing on,
measure its current performance, measure how good it is and how defective it is. Then you
analyze it, so as to understand why defects are occurring. Then you improve it and control it
so it stays defect-free. Digitization is the improve-and-control phase of Six Sigma. It gives you
the tools you need to keep improving.

Case Study: General Electric Co.

Creating a Real-Time Work Force
Online exclusive: Columbia University management professor Ann Bartel on the impact of real-time
strategies on the workplace.

Ann Bartel, professor of human resource management at Columbia Business School,
recently chatted with CIO Insight about the bumps in the road to creating a real-time work
force.

CIO Insight: Some say that the push by businesses to real time could lead to job losses
and also to increased labor-management difficulties, due to increased electronic
monitoring.

This new approach to monitoring will make it easier for management to document
substandard performance, and then make it easier for managers to make the case for
discharging and laying off people for not living up to performance standards. Any increase in
monitoring also will increase concerns among labor.

Given today's labor market, though, the unions are so weak that unionized workers probably
won't be able to do much about monitoring. Technology has its advantages, certainly, but will
it affect the quality of workers' lives to have Big Brother watching over you? It will certainly
change the way workers are used to working.

Is this likely to affect all types of workers, or just certain classes of them?

It will have to be the type of job where you will, in fact, be able to monitor tasks, so clearly,
factory workers will be affected. So will customer service reps and telemarketers. In the
telecom industry, they've been monitoring with technology for quite some time, and
managers have been monitoring how customer service reps handle service calls, such as
how long they take per call, or whether they spend too much time talking to customers who
don't intend to place an order.

This has become a major labor issue at places like Verizon and MCI. Monitoring is clearly
going to affect the quality of a person's work experience. It's going to be hard to know that you
have someone basically looking over your shoulder, someone who is able to track what
you're doing every minute of the day. I think, certainly, that this would make it more
unpleasant for workers. It will certainly make them feel their autonomy is being limited and
that their privacy is being invaded.

Labor Backlash?

Do you think workers might challenge this increased monitoring?

It probably hinges on the state of the economy. To the extent that workers are easily
replaceable, it's going to be much more difficult for labor to successfully negotiate these new
issues. If we're dealing with a tighter labor market, where it's more difficult to replace
dissatisfied workers, then it would be easier for them. But I think in today's job climate, it's
very, very difficult for workers to be successful on bargaining over these new issues.

Do you see increased use of information technology in the workplace as a net gain or
loss for society? You certainly increase the efficiency of the firm on one level, but on the
other, moving to a more monitored environment may lead to a loss of creativity and job
satisfaction.

Well, it's the question of how you want to quantify that. We can certainly quantify the gain in
efficiency, the gain in productivity. How we're going to quantify the loss of job satisfaction,
that's a very difficult thing to do, to compare apples with oranges. It's not at all clear whether
it's a gain to society.

On the one hand, efficiency will go up, but on the other you could have a lot of dissatisfied
workers, you can imagine people opting to be self-employed as a way to gain some
autonomy back, to move away from a Big Brother, 1984 scenario of the manager being able
to monitor every breath you take. People might want to become self-employed under those
circumstances, to be their own boss.

However, down the road, increased monitoring could become an accepted way of working.
Think about someone who works on an assembly line where his or her productivity is
measured. From the business point of view, the manager will know exactly how much that
worker produces each hour, each day—and that's considered a normal way of operating,
and no one gets upset about it because it comes with the territory. And those who do a good
job will be credited for their work. In a monitored system, nobody can hide.

So maybe, if you're a worker, you adapt to it over time, you know the terms, and you have to
accept it. To the extent that everyone in society views this as an abhorrent way of being
managed, you might predict that over time, companies are going to have to pay higher
wages to compensate workers for the disutility of being monitored. Maybe a job that had
less monitoring would have lower wages.

This suggests that unions are going to be fairly adamant in opposing this development.

Absolutely. Unions don't want differences among their membership; they want everyone to
be the same because that's what gives the union power. Once you have differences, you no
longer have the unity of the union members. I think there also are issues raised in the end
about workers with disabilities, and how you are able to use this type of monitoring system
fairly and not run into conflicts.

Case Study: General Electric Co.

Designing IT Architectures for Real Time
Online exclusive: As information technology accelerates the pace of business and the economy, CIOs
will need to rebuild their companies' computer backbones to keep up, says Gartner Research Vice
President W. Roy Schulte.

The information backbone of your company is hardly as efficient as it could be. W. Roy
Schulte, Gartner Research vice president and research fellow, Application Integration and
Emerging Technologies, tells CIO Insight how to design enterprise architectures around
events as they happen, for savings in time and money.

CIO Insight: What is your definition of a real-time enterprise?

Schulte: It's not something that's a slogan, it's not something that you can do just by telling
people to work fast. If you want a real-time enterprise, change your business systems,
change your organization chart, change your business processes and also implement a
computer system that's driven by events.

All enterprises are partially event-driven, but there's no such thing as an enterprise that
should be 100 percent event-driven. Every enterprise should be a proper mix. What you want
to do is make sure that you're using the mix that's optimum to get the business results you
want.

You're saying that most businesses need to be rewired to keep pace with the
accelerating speed of business today?

The pace of business is accelerating. It's a plain fact of life. Something that might take 20
minutes to trickle across the company in the past is now done in a matter of seconds.
Consider building a PC, which used to take an average of six weeks. At Dell Computer, they
now take the PC order, they build it, they ship it, and they deduct the money from your
credit-card account—all in 24 hours. All of this has to do with increasing the velocity of the
business processes.

Now, to get this kind of speed, we have to rethink how we design computer systems. One of
the most powerful ways that we can do this is to apply a so-called "concept of events."
Concept of events goes back to understanding what data looks like in general.

We would say that there are three kinds of data in the world—reference data, state data and
event data. Reference data is stuff that doesn't change very much, such as my name, my
address, how many kids I have, the number of seats on an airplane.

State data is different. It changes in the course of business. My name doesn't change every
day, but I go through many states. I go through sleeping, the state of sleep and the state of
being awake, the state of being hungry, the state of being full. A lot of different states. The
location of an airplane, the balance of my bank account, all of these things change, and what
you're doing if you're in the information systems business, you're in the business of
maintaining reference data for some purposes, but mostly what your systems are doing is
changing the state data.

Event data influence the big changes. An event means that something has happened. A
business event is a meaningful change in the state of a business. Although events can
change the nature of state data and can change reference data, it's usually state data that
gets most influenced by events. Examples of business events include opening a new
account, submitting an order, changing an address, making a payment, delivering a
shipment to a loading dock and so forth. Those are all business events.

Now, for those of you who are programmers, you know that within a program you also use
the concept of events. If you click a mouse on an icon, an event goes to a programming side,
and then the program will react to it and do something. These are not business events.
These are technical events. Technical events in software help you implement business
events. So there's a strategy side of events and there's a technology side of events.

The business events that I'm talking about—such as submitting an order, changing an
address, making a payment and so forth—these business events are handled by every
business everywhere, even if they don't have computers.

However, when you say an enterprise is event-driven, you mean something else. You mean
that the systems internally are also built on an event basis. So the business event, like
submitting an order, is going to be handled technically on a design basis and maybe even
on a software basis as an event, as something that is captured by an action that is coming
in from the outside.

Think business strategy. Traditional business strategy is all about building to a plan. In an
event-driven enterprise, you build to order. So if you have a traditional enterprise, you're
building to plan. You're saying, "I'm going to build 50 cars today, and the cars are going to be
the following." If you're building to order, you're saying, "I'm not going to build anything today
unless an order comes in, and if the order comes in, then I'm going to build that specific
car." So you're not building ahead. Now, build-to-order takes a lot more agility. Your
computer systems have to be running differently than if you're building to plan.

Another example would be just-in-time inventory. Traditional inventory systems a long time
ago would have not been just-in-time, they would have been planned. You'd know, for
example, that every day you've got to order 100 tons of steel to be delivered, and that it's all
supposed to come here. Just-in-time says, "I'm going to change the orders and probably am
not going to order until I get down to a very low amount. I'm going to have very small
inventories, and have them in various locations, and maybe very small inventory carrying
costs. But I can only do that if I'm monitoring what's happening on a real-time basis or close
to a real-time basis, and I've got very good information collection and very good information
dissemination."

Another example of event-driven business at the business level is to fix-as-it-fails instead of
doing preventative maintenance. Common sense says you do preventative maintenance.
You send a person in to change the light bulbs at a given time period because you know that
statistically you can predict that light bulbs are going to start to burn out after X number of
hours. You think that by doing this, you're saving money because you're saving people's
time, and the people's time you're saving outweighs the cost of the extra light bulbs. So
you're throwing away working light bulbs, but it's worth it to you because that way you don't
have to reschedule the people and you don't have to send people in on demand.

Well, we're changing that today. Many businesses now are switching over to a fix-it-as-it-fails
mode. If you have something that's big enough and worth it, now you monitor the device,
whether it's a piece of equipment or a financial system, for example. You're monitoring it for
signs of failure. If you have sensors on something, you can tell when something is starting
to fail.

Now, you don't have to do preventative maintenance. You can get every ounce of economic
life out of something, and if you see it start to fail, if you have a good enough information
collection system, you can go in and fix it—but not before you have to. So here's a case
where you're changing the entire way you organize maintenance activities, just like you
changed the way you build-to-order instead of building-to-plan. Why can you change the way
you do things? Now you have information correlated in ways you didn't have in the past. You
can be smarter now about things because you know more.

Future businesses will be doing a little less planning and forecasting and a lot more acting
based on actually knowing when events will occur. Now, we can measure it and track it, we
can see what's happening and respond to what's actually there instead of what we think
statistically might be there.

Design Requirements

What implications does this have for the CIO and system designers?

To design this into an IT architecture, you have to do some additional things to your
computer systems. One of the attributes of a process that's event-driven is that you have to
have the recipient ready and available to go when that new information comes in.

So if I'm event-driven, it does not help me to get information if I'm not going to react to it. So in
an event-driven process, the person or the computer system that's supposed to do that work
has to be available or they have to be working on something that can be interrupted so when
the event data comes in, your company can start responding immediately.

This is all part of what it takes on a business level to get things to go fast. You omit
unnecessary steps by redesigning the business process, and reduce the start-up time to
start each task. You try to shorten each step as much as you can. You combine multiple
steps into one step, you do steps in parallel instead of serially, and the final thing you do is
you try to offload as much work as you can onto the person or thing that's sending the stuff to
you or the person or thing you're sending stuff to.

And if you do all the steps, then you speed up that business process. Systems, computer
systems and business systems that are designed to be event-driven have to be designed
with a specific focus on events. So this is a different design philosophy than what you're
doing today, or at least what most CIOs are doing today.

Traditional computer systems keep the idea of an event within that application
system—capturing the event like an order entry system would. There is an event there that
any order entry system is going to say, "Aha! I recognize that an event has occurred, that
order has occurred, and I know about it. And within that system, I've defined what an event is
and I do something to it—I put it in a database, I process something. Maybe I'll throw
something to a transaction file, and at the end of the day I'm going to send those
transactions to somebody else."

In an event-driven system, you're thinking of events across the enterprise, or at least across
a wider scope. You're agreeing with different business units and different application
systems and different systems analysts on what the definition of that business event is.
What are the attributes of the business event? If you agree on it, you're surfacing the idea of
an event to a much more prominent place in the application design process.

There's a generation of software that's emerged on the marketplace whose job it is to notify
and alert people or systems about derived facts and events and alert people and other
machines. These alerts are being made, and they're based on thresholds. For example, I
don't want to know if the airplane is going to be 15 minutes late—but I do want to know if it's
going to be 20 minutes late. Or, I don't care if the stock price is going to hit such and such,
but I do care when it hits another level. So you set thresholds to have this alerting take place
in a way that's most useful and desired.

Notification isn't simple anymore. Now it can be done to a person through their browser if it's
between 9 a.m. and 5 p.m. If it's during the evening, maybe you want the system to call them
on the phone or maybe you want to send a message to their mobile device, or maybe you
want to page them.

So there are systems that handle the automatic escalation of alerts. So you don't write that
software, you buy software that handles the alert notification, and you buy the software so it'll
escalate properly. It'll go look at a directory as to who's supposed to be notified about what
facts. It'll also escalate in cases where you have a problem. The system can be told to look
for an acknowledgement.

So if you don't get an answer back from the person saying "I got the message," then the
system has got to be smart enough to say, "Okay, well, who's the backup destination here,
who else should I send that notification to?" These systems can be very sophisticated, very
powerful, so if you have something that really, really matters for that small part of your
business, you want this kind of a system to be able to make sure that an event gets
delivered to people so the proper corrective action can be taken. And, again, this can be
done to people. It doesn't just have to be to systems.

Event-based systems have an implication for software. The software that's good at pushing
information is different than the software that's used for pulling information.

To have event-driven systems, we're going to start using message-oriented middleware on
a much broader basis than we're using today. There's a lot of different kinds of message
oriented middleware, but to work best for real time, it has to be software that's designed with
the following characteristics: First, you have to have scalability because you may have
dozens or hundreds or thousands of senders, and you may have dozens of hundreds or
thousands of receivers for that one particular fact or event. So in some cases we're talking
about transmitting events the same way radio and television works, broadcasting the
information to a large base.

In many cases, you want exactly one delivery. If I buy 100 shares of stock, I want that
transaction delivered once, not twice because I don't want to buy 200 shares. So you have to
have software where the quality of service is built into the system. Again, that's not
something that most communication mechanisms have today on a technical level. You have
to add it in the application or you have to buy message-oriented middleware.

This dynamic reconfiguration—the ability to add, delete or move senders or receivers—is not
a property of most systems, and the fundamental reason why it's not part of most technical
systems is because most systems are connection-oriented. In most computer
communication, the sender and receiver know who each other is. They know down to the
TC/PIP address, they know down to the process base, and so forth. There are direct links
between the systems, and you need some sort of intermediary to be able to allow these
things like dynamic configuration to take place.

You'd also like a system that can change the sender or receiver's view of the data without
having to change the side. So what you'd like is a translation capability, so something that is
sent here arrives in a form that's different when it arrives, such as a different format.

Then, of course, you want store and forward capabilities because you can't guarantee that
System A and System B are up at the same time. With traditional computer systems, most of
the traffic that happens inside a computer is very tightly coupled. This side and this side
better be alive and running at the same time or else the transfer is not going to take place.
And if I try to send a message or ask a question, if the system isn't running, I'm out of luck.
The bits fall on the floor, and the communication has stopped. With store-and-forward, it
doesn't happen. With store-and-forward, something in the middle holds it in a queue, in a
temporary database so that it can get there.

Additionally, what I call publish-and-subscribe is also very helpful for event-driven systems.
Publish-and-subscribe says that the subscribers define what kind of information they can
get, and they notify a central authority—for example, message-oriented middleware or some
other mechanism. What kind of information am I interested in? Where are the criteria for stuff
I want to hear about?

The publishers, on the other hand, don't have to know anything about the receivers. They
don't have to know who they are, they don't have to know how many there are, they don't even
have to know if they're there. The publisher creates information and throws it over the
transom, and the middleware in the center is the one that reconciles this, it takes the
messages, it figures out the subscription criteria and rules, and sends it where it's
supposed to go. So it's kind of like a magazine subscription but not exactly. In a magazine
subscription, the writers write the stuff, they put it in a magazine, the magazine distributor
has the distribution list for that information.

Further, publish-and-subscribe is many-to-many. You can have many different people
sending that kind of message, many different people receiving that kind of message, and
that can change dynamically during the day. Every second, you can add more senders and
add more receivers. It's a very powerful communication mechanism. If you don't have it,
some kinds of event-driven processing are not possible. So you'll be doing more
publish-and-subscribe, again both on a business level and on a technical level to make the
event driven enterprise actually work.

Picking Products

Are there products that help drive some of this?

Traditionally, there were I would say three fairly distinct kinds of personalities to these
products. There were some products that were meant for the very extreme situations, lots of
senders, lots of receivers—we're talking tens of thousands of messages a second in some
cases, and many hundreds or more of senders and many thousands of destinations.

We also have general-purpose, information system-type message queuing systems of
which the most widely known is IBM's MQ Series, now called WebSphere MQ. You also have
products that are of the same general genre, like Microsoft's SMSQ. There were a dozen
others. This was a whole set of vendors that came out in the late '80s and early '90s. Most of
those systems have disappeared. There's been a lot of market consolidation here, a lot of it
due to IBM strength in terms of being able to promote its product across many different
platforms.

Last but not least, we have the newer generation of middleware, which is the JMS-type
messaging systems. New messaging systems that are based on the Java standard can be
implemented a lot of different ways, and they're implemented by a lot of different vendors.
They're also implemented as a layer sitting on top of other products. Java message service
is not a specification about how you do messaging internally, but it is a standard that
describes the behavior of a particular type of messaging system.

These different kinds of products have actually come together a lot in the last several years.
In the past, most of them did not do publish-and-subscribe. Now they all do, or almost all do.

So if you looked on paper and just did a check list of features, they'd all have a check, but if
you actually then asked how well they worked, you'll still see some fairly significant
differences in the personality of these products in terms of their scalability, their security,
how good they are at being easily managed and how hard they are to manage.

A lot has been said about the next level of automation at companies and how it will
create, in effect, an "enterprise nervous system."

The enterprise nervous system is the idea of the intelligent network. It says, "We've got these
smart application systems, there's logic and there's data in those application systems, but
now we're going to put some logic and data outside of the applications,"—you can say "in
the network"—"and that makes us an enterprise nervous system."

So we're doing transformation that the network has some process smarts, and it has some
semantic smarts because it can do the transformation. Well, the backbone of this in many
cases is going to be some sort of message-oriented middleware. More of the traffic is going
to flow over that than anything else.

So we're going to see message-oriented middleware being used within the enterprise, and
by extension we're going to see it across enterprises in this worldwide grid. If you have every
enterprise building its own enterprise nervous system, and every business is tied in inside
of itself plus through its business partners, through a smarter network that can do these
things, you'll step back and you'll say, "Wow, they're all connected to each other."

And what we essentially have is one network for the entire planet, and every network you see
is just a sub-net of this worldwide network. And then the sub-networks are smart, and
essentially what you're going to get is a network grid across the entire world that's a smart
grid.

The products that have the kind of qualities that we were talking about here, this
message-oriented middleware, are changing. In fact, we would say in some cases they're
going to be fading because they're morphing into something much different. Plain
message-oriented middleware came out as a commercial product in the late 1980s. They
spread because they were imbedded into application systems and they were hidden under
things like your network and system management tools.

Around 1996, when we started using them for integration purposes, we started making them
a little bit more visible. When they were added to the JAVA application servers in about 2000,
they became ubiquitous. Suddenly, anybody who was just buying an AP server was getting a
messaging system.

They may not be using it in every case, but they were getting it. So you can buy it in an
application server or you can buy a specialist product that's dedicated just to doing
messaging exceptionally well.

In the future, these systems are changing their nature. The name of the game is messaging
systems and the Web servicing systems coming together to creating what we're calling
these enterprise service buses. So companies like Cape Clear, Sonic Software, SpiritSoft,
these companies are coming up with products that are meant to talk Web services so you
can be a client or a server of a Web service and talk to these communication mechanisms.

But the quality of service they had is much beyond plain soap. In addition to playing request
reply activities, these products are also capable of store-and-forward, they're capable of
publish-and-subscribe, they're capable of the kind of communication patterns you need on a
technical level to implement those business strategies you wanted. So we expect to see
these services spread across many companies to help enable the event-driven enterprise.

At the moment, enterprise services are coming from some very small vendors, but we expect
over the next 12 to 15 months that major vendors will start coming out with these products.
So it's going to be a Web services system, it's going to be a messaging system, it's also
going to have some of the basics that you need for application integration. As these products
come out, they will compete against some of the traditional integration middleware.