Outage Management Architecture Decisions at Niagara Mohawk
Decisions to Support a Centralized Architecture
Detailed Analvsis
In early 1998 detailed discussions with different groups from IT began to review the technical requirements. Individuals from the outage project team, enterprise technology assessment group, distributed computing, network services, database administration and mid-range technical services were represented. Previously, discussions took place with these areas on feasibility issues but now were the formal discussions to determine a supportable architecture.
The project team approached these discussions with a bias toward a distributed architecture that at the time would be implemented at four regional control centers. Each site would consist of two UNIX servers each managing different database engines and an NT server to run background trouble call retrieval and prediction processes. Database replication services would be used to synchronize the data between the four sites, so each site would have access to updates from other sites. This provided the benefit of making each site capable of stand-alone operation in the event of a failure such as losing a WAN link.
Additionally, the possibility of at least one center being available in a catastrophic event would be near 100 percent. If a remote site required access to the system, that could be accomplished by running products such as Citrix WinFrame or Terminal Server with the remote site being served from the closet control center. This architecture seemed it would satis~ the requirements, particularly the flexibility in having centers take over dispatching operations for other centers and mitigate the risk of not having an operating center available in the event of a catastrophe.
As the group mapped the components to support the distributed environment it became clear this approach did not fit with the NMPC enterprisewide technical architecture. We did not have a support staff to administer the UNIX servers in the regional control centers. UNIX is our mid-range standard and although we are looking at NT servers for particular applications, we didn’t feel it would be appropriate for this mission critical system. The DBA group had not worked with database replication and from their research weren’t comfortable with its reliability and resilience for this application in our environment.
Another major consideration is that our Customer Information System is centralized running on mainframe databases. This system is the primary point for the entry of trouble calls by customer representatives or through voice response units and without this the use of the Outage Management System is limited. So, this identified a weak link where, although each control center could operate stand-alone, it may not be able to get trouble calls and communicate with the CIS.
At this time we were getting information from re-engineering that the system would be required in 10 to 12 district offices for certain storm situations, but that the regional control centers would move toward consolidation over the next two years. In evaluating this we would need to buy UNIX servers for each site and administer them or try and run an emulation product such as Citrix. We felt an emulation product was not the direction we’d want to take at this time. Therefore, for each additional site we would incur the cost of buying servers, replication licenses and support services. For each site we calculated the server hardware and database software including replication would be around $75,000. We didn’t try very hard to calculate a support cost because we knew we had to investigate a centralized option which could still meet the requirements.
|
