Enterprise Impact Simulation - Making It Happen

  • Written By:
  • Published:

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.


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.

comments powered by Disqus