GISdevelopment.net ---> GITA 1999 ---> Enterprise Integration

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.

Fifth Phase - Market Chaos
As business process reengineering efforts gathered steam, software vendors moved aggressively to increase the breadth and depth of their functionality. Additional vendors entered the market, resulting in a proliferation of software packages and platforms. As the vendors increased the scope of their packages, overlaps in functionality and data became more severe. Mobile computing packages overlapped with work management packages, who overlapped with GIS packages, who overlapped with outage management packages, who overlapped with SCADA systems, and so on.

The integration efforts to tie all these disparate packages together became increasingly complex and costly. The promised "silver bullet" of middleware never materialized, since no single piece of software could keep up with all the changes and combinations of the different packages, and the addition of another layer of software compounded the overlap problem.

Internal information flows became disjointed. Although each package knew best how to collect, organize and exchange information for its own purposes, it often did not match up when brought together with another package. So even though a "best of breed" package can deliver a key strategic advantage at a departmental level, inefficiencies may result at a company level. The complexity of integration, coupled with the high rate of change of each of the components, has made the "best of breed" packaged software model unworkable as an enterprise solution for the long run.

Sixth Phase - Enterprise Solutions
Feeding off the issues associated with the integration of multiple software packages, "reintegrated" software solutions entered the market. Examples include SAP, People Soft, Oracle, and BAAN. These vendors promote a lower total cost of ownership compared with maintaining and integrating multiple individual software packages.

These solutions also represent a powerful new concept: the ability to tie together information from every corner of the enterprise. Once business functions are integrated under a single information regime, a company gains a new view of itself. Managers can see what's happening in their own and neighboring departments. Executives can identify operational bottlenecks and observe how changes in one area affect others.

In order to bring these functions together, enterprise solutions impose a coherent structure from the top down. Although the systems allow for some degree of customization to permit companies to configure aspects of the system to reflect how they do business, the flexibility is limited by their nature as generic packaged solutions. To varying degrees, enterprise solutions require companies to change how they do business in order to realize the benefits of integration.

The Challenge of Enterprise Solutions
Since an enterprise solution covers the gamut of business functions - from accounting to engineering - implementation brings cost, complexity and organizational challenges. The solutions are costly and complex due to their scope and nature. A large company can spend between $50 million and $500 million implementing an enterprise solution. Perhaps the biggest challenge, however, is the impact an enterprise solution can have on a company's organization and culture.

Because an enterprise solution unifies information under one system, adopting the technology can pull a company's organization and culture in different directions. Enterprise solutions embody their own version of best practices, which challenges the existing practices of a company, forcing the company to question almost everything they do. The unified system also forces the integration of business functions within a company and the sharing of data between departments, something that has typically never been done before.

Enterprise solutions also present strategic challenges. As enterprise solutions are adopted across entire industries, individual companies risk losing what makes them unique. If all of your competitors are rushing to implement an enterprise solution, should you? If everyone is gaining the exact same advantages in the exact same way, has anyone gained any strategic ground? In some cases, such as in the petrochemicals industry, enterprise solutions have so revolutionized the industry that not adopting the technology would be foolhardy. In other cases, if the cost of implementing an enterprise solution is forcing your competitors to raise prices, and your current systems are adequate, not immediately implementing the technology might be the best move. Only careful analysis of your strategy and the competitive landscape will tell.

The Promise of Enterprise Solutions
Enterprise solutions provide an opportunity for a company to rethink their business. If an industry is undergoing fundamental change, as the utilities industry is today, enterprise solutions can provide the vehicle for driving organizational and cultural changes. Enterprise solutions can enable the transfer of power from the center of a hierarchical organization to the periphery, encouraging a flatter, more empowered structure. On the other hand, enterprise solutions can be used to impose structure and discipline, breaking down autonomous fiefdoms. Enterprise solutions can also support geographically dispersed operations, or support an acquisition strategy to build a global company.

Business process reengineering efforts, when conducted in conjunction with an enterprise solution, have a much greater probability of delivering the benefits they identify. Example benefit areas include integrated supply chain logistics, integrated financial management, and integrated customer service. Integrated business processes, supported by integrated technology, can drive out redundancies and inefficiencies that in many cases have been caused by system overlaps and isolation.

In many ways, enterprise solutions embody the promise of the electronic enterprise. In an age of electronic communications, it's a truism that companies perform better when information is unified under a central system. But specific benefits will come only when an enterprise solution functions within the context of the business' strategic, organizational and cultural objectives.
© GISdevelopment.net. All rights reserved.