Trends in enterprise solutions
Thomas M. Myers
Andersen Consulting
100 N. Tryon Street, Suite 3900
Charlotte, North Carolina 28202
The lines separating GIS, SCADA, and traditional corporate information systems are fading
rapidly. The trend is clearly towards common architectures which draw from multiple sources
and disseminate information enterprise-wide - systems referred to as an enterprise solution. This
paper will examine past and current trends for enterprise solutions by describing six phases of
evolution, and discussing the challenges and opportunities of implementing an enterprise
solution.
First Phase - Custom Systems
In the beginning, there were custom systems. These systems were individually built from
scratch. A company was responsible for the design, implementation, and ongoing maintenance
and support of the system applications. As a result, each system was unique to the company that
built it, and was a perfect functional fit with the business processes it supported. Integration was
built-in on the computer platform that was used. The platform provided rudimentary tools, such
as operating systems and databases (e.g., IBM CICWIMS). Integration across platforms, such as
between IBM and DEC, was non-existent. The systems tended to be expensive to develop and
maintain, although technical upgrades were relatively infrequent. Companies needed to have
large IT departments to build and operate the systems.
Second Phase - Custom System Tools
Due to the high cost of developing custom systems, and the fact that each company was
"reinventing the wheel," tools started to appear on the market. The initial tools were often
design guides that would help a company through the design aspects of a custom system
development effort. For example, IBM developed the DCIS and GFIS design guides to help
with the development of work management and gee-facilities systems. These design guides
provided a jump start to a system development project, provided starter templates, and avoided
the "reinventing the wheel" syndrome.
The next item to appear on the market was "transferrable software," which was custom code
already developed at another company. Examples of transferable software include the IBM
GFIS code offered by Wisconsin Public Service and San Diego Gas& Electric, and the
WORK/1 software offered by Andersen Consulting. This software provided an even greater
jump start to a custom development project by providing functioning code that was already
designed and tested. The software greatly reduced the cost and risk associated with a custom
development effort, and often provided best practices in the industry by continually adding
functionality with each successive transfer. However, the software was specific to a company's
technical environment and business practices, and often needed considerable modification to fit
the environment of a new company. Although tools were developed to facilitate these transfers,
the final product was still a custom solution that the company would need to support and
maintain.
Third Phase - Software Packages
As the transferable software products evolved, software vendors began to build software to
support multiple companies. This software was sold as a package that the vendor would
maintain and enhance. The company was no longer responsible for the development, testing and
support of the software, and didn't have to worry as much about the increasing speed of technical
changes. Since the software was built for multiple customers, the fictional fit to a specific
company was not as complete as a custom system, and changes were often required to a
company's business processes.
Due to divergent technical platforms, software packages initially had to pick a strategic platform
upon which to build their product. Products became tied to hardware and software
configurations. As technical architectures opened and became more compatible, packages were
able to be supported across multiple platforms.
Fourth Phase - Business Process Reengineering
Concurrent with the introduction of software packages was the first wave of business process
reengineering efforts, driven by Michael Hammer and James Champy's book Reen~ineerin~ the
Co~oration. Companies began to look closely at their business processes, and realized that
many systems were built within the isolated functional "silos," and that integration was needed
to break down the walls. As companies reengineered their business processes to be more
efficient and integrated, they realized that integrated processes required integrated systems.
Systems integration became an area with high demand.
Many "out of the box" reengineering efforts did not take technology into consideration, and
came up with solutions that would require functionality that was not yet available in packaged
software. Implementing the reengineered processes would require a complete new set of custom
systems. The costs associated with these implementations often exceeded the benefits of the
reengineering.
