About one third
of all information system projects fail. The other two thirds deliver
less than half of the desired features (on average). These projects
expend 2-3 times as much budget and time as planned. Once systems are
delivered, organizations are afraid to change them because changes are
expensive and very likely to break the systems. Overall, the likely
outcome of virtually all IS development projects are so-called stovepipe
systems those hard-to-modify, legacy ones.
The first generation of OO did not change these expectations. More recent
OO (object oriented) concepts-like design patterns, frameworks and distributed
objects-are too new to assess.
there are fundamental changes in thinking at the architecture level
of information systems, I seriously doubt if the results will be any
different for the majority of developers.
Stovepipe system development is analogous to a drug or alcohol addiction.
We really do not want to admit it, but our systems do not provide the
expected features; we cannot effectively manage system development;
we are afraid to change the systems; and we continue to make the same
mistakes, generation after generation, that lead to more stovepipe systems.
There appear to be no alternatives.
Software architecture is a key technical source of these problems. Poor
software structure leads to brittle systems that are hard to understand
and cannot adapt to change. Approximately half of software cost is used
for system discovery, ie programmers trying to understand how the system
works. In addition, change is a primary cost driver in IS, with approximately
30% of development cost due to changes in requirements during system
construction, and 70% of operational costs are due to system extension
Good architectural structure makes the system much easier to understand
and change. An effective architecture provides system adaptability throughout
the life-cycle. Good architecture begins to provide manageability from
the initial prototype through the full-scale system, with benefits increasing
with the scale of development.
One particularly difficult challenge has been architecture migration,
i.e. moving legacy software to an improved software architecture. Experience
in systems integration using distributed objects has shown that OO architecture
migration can be relatively quick and inexpensive. OO architecture migration
results in an interoperable set of legacy subsystems and a stable architectural
structure supporting system extension. Once the architecture is migrated,
the legacy subsystems can be migrated independently, at whatever pace
Even so, the technical benefits alone may not be sufficient to eliminate
an addiction to stovepipe systems. What may be needed is a 12-step intervention
process to kick the stovepipe systems habit. Based on ideas from the
AA Big Book3 (ie an intervention process that has helped numerous people),
here is a sequence of steps that your organization may undertake to
reform your IS systems towards improved OO software architectures.
* Admit that we are powerless over our old stovepipe systems.
* Come to believe that better architecture (OO architecture) can restore
our systems to manageability, including management of complexity, management
of change, and management of performance.
* Make a decision to migrate our legacy systems to improved OO architectures.
* Perform an in-depth analysis of the architecture-level interfaces
of existing legacy systems and relevant commercial technologies; this
understanding is crucial for the design of successful target OO architecture.
* Design and document the exact nature of the target OO architecture.
For example, use OMG IDL to specify your OO architecture interfaces.
Review the design with employees, management, and at least one outside
consultant. Tutor the design knowledge and make it a required part of
training of all architects, developers, and operations staff.
* Make an organizational commitment to the target OO architecture, to
have the target OO architecture eliminate all past system problems,
even though this commitment entails costs, risks, and inconveniences.
* Initiate migration. Migrate your legacy software to an OO architecture
first. Then, use an incremental approach for migration of subsystem
functionality and data.
* Identify past lessons learned; make a list of all business processes
and organizations that have been negatively impacted by past system
* Prioritize the list of lessons learned. Determine how the target OO
architecture will resolve such issues. As target system capabilities
become available, demonstrate and train the impacted organizations on
the improved system functionality.
* Continue to take inventory of lessons learned. Add target system shortcomings.
When there is a problem, promptly admit it and determine how to make
* Through careful analysis and decision making, seek to maintain and
improve the quality of your OO architecture; reuse the designs across
multiple system applications; this will lead to organization-wide interoperability
and software reuse.
* Having experienced the benefits of improved information systems using
these steps, carry this message to other IS system developers and users,
and to continue to follow these principles in all your information systems
Many seasoned technologists believe that there is no way to avoid the
next generation of stovepipe systems. In this cynical view, even the
best OO projects of today will produce the brittle stovepipe systems
Given the technologies and practices of the past, I tend to agree. In
the past, there was no feasible way for the majority of developers to
be successful in business and "do it right," ie create good
architectures. Now, with OO architectures and distributed object technology,
there is much greater potential to create viable alternatives to stovepipe
DR THOMAS J MOWBRAY,
Chairman, Component Management Group.