Kick The Stovepipe Systems Habit

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.

However, unless

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

after deployment.






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

is appropriate.



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.






Twelve-step program


* 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

problems.






* 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

amends.






* 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

practices.



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

of tomorrow.






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

systems.






DR THOMAS J MOWBRAY,


Chairman, Component Management Group.

Back To Home

| Back

To Content

Copyright Cyber Media India Ltd.



You must read the terms and conditions before
using this service