EIS-enabled
IT
The demand for Enterprise Impact Simulation (EIS) is driven by collaborative
commerce, enabled by IT. Businesses engaged in c-commerce run on Internet
time. Change-readiness is the watchword. The predictive capabilities of
EIS deliver change-readiness. Two specific predictions are particularly
relevant to the demands of c-commerce. The first is the accurate prediction
of effort and duration for IT projects. The second is the accurate prediction
of impact to business functions, organizations, and other IT systems as
a result of those projects. These predictive capabilities require accurate,
coherent, comprehensive knowledge of the components used in the simulation;
IT blueprints.
EIS
enables c-commerce alliances to move quickly and in lock step to introduce
new functionality to their collaborative capabilities. EIS enables alliance
members to produce accurate predications of the effort and duration of
their individual IT projects. This is key to producing an accurate schedule
at the alliance level for the introduction of that new functionality.
Schedule overruns in the efforts of any one member can have a delaying
affect on the alliance as a whole. The ability to produce accurate estimates
depends on accurate knowledge of the thing being changed. The main source
of problems with IT software estimates was long ago identified as relating
to those things that were missed, not those things that were known but
misestimated. The knowledge contained in the IT blueprints forms the basis
for the solution to this problem.
EIS
enables c-commerce alliance members to introduce new functionality to
their own businesses without unintended impact to the alliance's collaborative
capabilities, and vice versa. The members of the alliance compete with
other businesses to maintain their membership in the alliance. The alliance
as a whole competes with other alliances. Thus, businesses that participate
in c-commerce compete on two levels. Both require ongoing change to the
business' IT systems. Yet these changes must be kept separate so that
unintended impacts do not cause disruptions to either alliance-level functionality
or to business-specific functionality. Either can jeopardize a business'
membership in an alliance. The primary cause of unintended impacts in
IT projects is a lack of knowledge: of the behavior of the IT components,
of the usage of the system, or both. The knowledge contained in the IT
blueprints forms the basis for the solution to this problem.
The
development and maintenance of the blueprints that enable EIS capabilities
requires a material change to the IT operating model. It must move from
today's craftsman-oriented model to one with a manufacturing orientation.
In
a manufacturing model, the mindset is that the product will be refined
and redefined over time. As a result, information about the thing being
produced, blueprints and bills-of-material, are key components of the
final deliverable under a manufacturing model. These information deliverables
allow those refinements and re-definitions to occur with much more predictability,
typically in much less time and for much less cost, than the original
development. The absolute requirement for the production and maintenance
of IT blueprints is the fundamental difference between today's IT operating
model and the one that enables successful participation in c-commerce
alliances.
This
article is the last of three in a series. The first
introduced EIS, identified the technology breakthrough in software test
automation that makes it possible, and identified the c-commerce alliance
model as the key demand driver for EIS' predictive capabilities. The second
explored the c-commerce alliance model, the challenges it poses for the
IT organization, and the value it promises for the consumer and for alliance
members in more detail. The intent of this article is to develop the operating
model that delivers EIS' predictive capabilities to businesses planning
to compete for membership in a successful c-commerce alliance
The
Operating Model - Tools, Processes and Framework
Software test automation tools now make it possible to have 100% accurate
descriptions of the behavior of our IT systems. System behavior, however,
is not the only information we need to produce the predictions required
for successful participation in a c-commerce alliance. The acquisition
and maintenance of the information base we need requires the effective
use of our full suite of tools. An operating framework is also needed
to guide the use of those tools to a common goal: change-readiness. There
is no need to invent a new framework. The one in use by manufacturers
of computer hardware serves very well.
All
designers work from requirements, but the tailor-made nature of IT software
demands requirements management of a slightly different nature from that
for either computer hardware or packaged software. IT software designers
need accurate information about how the business, its customers, and trading
partners use the systems. This information is key to avoiding unintended
impact to the business or to the alliance as a result of change to the
systems.
It
is not unusual to have many individuals belonging to several business
groups using the same IT system. They often use some of the same system
functionality to accomplish different business tasks. Requirement Management
tools and processes enable IT organizations to record and maintain information
about who uses which pieces of system functionality, why they use the
functionality they use, and how they use that functionality. Coupled with
information about the system components that deliver this functionality,
information acquired and maintained with Requirements Management tools
and processes enables us to accurately predict impact to the system's
users as a result of change to the system, and vice-versa.
IT
software designers need accurate information about how the IT systems
work, and work together. They also need information about the components
that make up the system, especially components shared by other systems.
The deliverables that come out of the design and development phase in
the manufacture of computing hardware include a set of blueprints and
associated bills of materials. Many of the tools used in the design of
computing hardware have sophisticated simulation capabilities. Engineers
produce a design and then simulate its behavior until it works per the
requirements. The tools then produce blueprints and bills of material
for the design. In software development, we currently lack this design
simulation capability.
In
the manufacture of software, we must proceed past design through development
and utilize Software Test Automation tools to get an accurate description
of the system's behavior. It is this lack of simulation capability that
drives us to utilize the Test Automation tools, rather than the Design
tools, to produce the IT blueprints we need for EIS. The bill of materials
capabilities for software development are provided by Configuration and
Content Management tools. Together, Software Test Automation and Configuration
and Content Management tools and processes allow us to acquire and manage
two more types of information EIS needs to produce accurate predictions
of effort and impact.
Successful
hardware manufacturers use off-the-shelf components whenever possible.
This makes cost estimates easy to produce. As competing designs are produced
the bills of material are fed to groups responsible for acquiring the
specified parts. These groups obtain prices for the parts listed in the
bill of materials and produce refinements of the initial product cost
estimates based on models driven off direct-materials costs. Businesses
engaged in c-commerce should, whenever possible, follow suit with their
IT development efforts. Depending on the platform and target environment,
there are an increasing number of software components available off-the-shelf.
For the foreseeable future, however, the development of custom components
will remain a fundamental part of most IT software projects.
As
long as custom development is a major component of IT projects, IT organizations
must continue to use Project Management tools and processes as their primary
means of producing effort estimates. Businesses engaged in c-commerce,
however, must develop the ability to produce these estimates much more
quickly than they do today.
An
automated approach is possible, but requires information we do not typically
get from the Project Management process today. The focus of Project Management
today is on the control of projects. The high-level structure of the IT
project schedule typically focuses on project phases: analysis, design,
code, and test. Information about effort per component is spread across
phases and is often difficult, if not impossible, to extract. Simulations
to produce predictions of effort require historical information at the
component level. Project Management tools can support the acquisition
of this information, but the scope of Project Management processes must
expand to include this objective. With minor modifications in their usage,
Project Management tools and processes can provide the information EIS
requires to automate the estimation process.
While
the assembly line isn't relevant to software, other production and post-production
activities in the hardware lifecycle are important to note. In particular,
a hardware product may be produced in dozens of different versions during
its lifetime. Testing during production, customer complaints fielded at
the help desk, or warranty service records all provide feedback on the
product.
When
a problem with parts from a particular vendor, or with a particular type
of part is identified, new parts are chosen for use and a new version
of the product with a new bill of materials results. The same is true
when parts shortages occur, or when new parts with superior cost or performance
characteristics become available. Every time a new version is authorized
for production new blueprints and/or bills of material are produced. This
requirement is absolute. Businesses participating in c-commerce alliances
should move to ensure their IT organizations adopt this operating model.
Introducing
the Model - A Process for Change
Successful introduction of the new IT operating model can be ensured through
the use of three tools: relentless communication from management, a measurement
process, and the use of change agents.
Change
of this magnitude requires relentless communication to ensure that everyone
knows why the change is necessary, what is going to change, how it's going
to change, who will be impacted by the change, and when the change needs
to take place. Everyone needs to understand that this change is about
the survival of the business in a world with new rules. Everyone needs
to understand that while software is a key deliverable, the rules of collaborative
commerce make information about that software as valuable as the software
itself. Everyone needs to understand that the change to the IT operating
model will effect everyone in the IT organization, and everyone that interacts
with that organization on IT projects. And everyone needs to understand
when the changes will begin, when to expect full implementation, and when
each component of the implementation will be rolled-out.
Key
to achieving our goals is the implementation of a measurement process.
We need to know who's meeting or exceeding their goals so we can hold
them out as positive examples of success and how it's rewarded. We need
to know who's having difficulty so we can remove the obstacles impeding
their success. A process should be put in place that measures success,
both in the production of the information deliverables and in their use
by other organizations and other projects in achieving change readiness.
The
project manager who develops the schedule that gives us the component-level
information we need, and the project manager who develops another schedule
more quickly due to the reuse of that information both need to be rewarded.
The programmer who uses information produced by the test group about how
the system interfaces with other systems to avoid impact to those other
systems needs to be rewarded just as vigorously as the test group that
produced it. If we have evidence that an individual or group has utilized
the new information deliverables, we must reward their successes as though
they resulted from that use, even if we have no direct evidence of it.
The
change we seek will happen more quickly and more surely if we bring in
Change Agents, people who already know how to use the tools and how to
organize the effort to deliver the results we need. We should use these
people to lead the first efforts, to mentor our own people to take over
when they leave, and to lay the infrastructure we need to make the new
model self sustaining. The use of outsiders will signal our seriousness
and will avoid mistakes that could slow or even derail our efforts. Anthropologists
teach us the introduction of new tools will inevitably change a culture
when the tools and their usage impact status. The use of outside consultants
signals and cements that change in status much more quickly than can be
achieved otherwise.
Summary
Before c-commerce bad estimates and unintended impacts were issues businesses
managed. Cost and schedule overruns and disruptions to the business caused
by IT projects were an internal affair. Not any more. Not when the business
participates in a c-commerce alliance. These issues suddenly become problems
that have to be solved. IT blueprints and the list of components that
accompanies them, known in manufacturing as the bill of materials, form
the foundation for the solution to these problems: Enterprise Impact Simulation.
The
process framework for the development and manufacturing of computer hardware
has three characteristics that make it an especially good reference. First,
computing hardware is the closest cousin of the computing software we're
concerned with here. Second, the computing hardware industry has made
very effective use of simulation tools as part of its history of ongoing
cost reductions and improvements in functionality and performance. Third,
we are searching for the software analogy to the successes that have characterized
the history of computing hardware.
The
transformation of the IT industry will share many similarities with the
transformation introduced by Henry Ford to the manufacturing industry
almost a century ago. The work will change in many ways. In particular,
the definition of success for engineers will change much as it did for
engineers in Ford's operation. IT management will be faced with some of
the same issues and challenges faced by Henry Ford's management team.
The role of formal processes and controls will change, much as it did
then. As a result, IT productivity and predictability will improve. Businesses
employing the new operating model will, like the automobile manufacturers
in Ford's day, succeed while their competitors who do not will fade from
the scene.
About
The Author
Bill Walton has 15 years of IT experience including development, QA/Testing,
and management positions with IBM, Compaq Computer, and Sabre, Inc. His
background includes support of Engineering and Manufacturing as well as
back office functions. His breadth of experience gives him unique insight
into the problems facing IT today. His views on the most pressing of these
problems and their solution can be found on his web site at http://www.jstats.com.