| GISdevelopment.net ---> GITA 2003 ---> User Presentations |
Migration - Exchanging engine during the flight
Rodrigo Mendonca Queiroga
GIS Division Senior Analyst
ESCELSA – Espírito Santo Centrais Elétricas S/A
BR 101 Norte, Km 9,5 – Carapina – Serra – E.S.
ZIP Code: 29.161-500 – Brazil
Rodrigo Mendonca Queiroga
GIS Division Senior Analyst
ESCELSA – Espírito Santo Centrais Elétricas S/A
BR 101 Norte, Km 9,5 – Carapina – Serra – E.S.
ZIP Code: 29.161-500 – Brazil
Abstract
Our enterprise GIS enables us to provide efficient power distribution, cable TV, and internet services, while minimizing costs in keeping these networks operational. Through our enterprise GIS we are able to manage distribution outage with minimum cable TV signal interruption. Escelsa is a multi-utility company located in Southeast Brazil that was privatized in 1995. Since then we are dedicated to improving the quality of our services and reducing operation costs. Therefore, one of the first decisions taken was to acquire an enterprise GIS that could serve the multiple goals of the company. Now we are facing the new challenge to move forward in terms of technology. Our 7 year-old GIS became a legacy system and we need to upgrade. What technology migration strategy should be adopted in order to move on and also keep up with all the company requirements? What are the issues we are addressing? Check the internal and external facts that influence the path that is to be adopted. What are the possible consequences of the migration?
Introduction - A little bit of our history
Our IT division provides solutions for two companies, Escelsa and Enersul. Escelsa was the first Power Distribution Company to be privatized in Brazil, back in 1995. It has about 1 (one) million customers in Espírito Santo State. Enersul is also a Power Distribution Company and was bought by the Escelsa stakeholders in 1999. It attends to half a million customer at the Mato Grosso do Sul State. The main business line is Power Distribution, but there are some businesses, like Cable TV and Internet Service Provider, that showed some synergy. Therefore these other lines of business were than started. Obviously, all three lines of business somehow depend on geographic location of its resources and can easily take advantage of GIS.
The selection of the GIS technology we use today was based on some very meaningful criteria for us. It should: attend to the entire corporation, be open and easy to integrate, reduce operation costs, have applications ready to use to minimize effort of deployment, have good performance, be able to present the same information in various different shapes according to the user group, and certainly be at a reasonable total cost.
Background
In 1996 we have selected and acquired the applications for Power Distribution Network Management implemented over VISION*. GIS Platform. It had all the main features we required and the project was a complete success by 1998 with 75% of the data acquisition done and 80% of the customers already geo referenced.
The first step was to deploy the data entry and maintenance module. This was a big operation once we had in place a Natural/Adabas legacy system running for about 18 years. The good thing about it was that, since the beginning, there were people concerned about locating poles and network devices with its UTM coordinates. This means 13 digit coordinates were typed in a green old screen. That was of great help to moving into the GIS. The deployment caused a huge work order backlog and the users had a very tough time to finish it. Scrubbing the data was also a very big effort and ended up with some aerial photos to help data accuracy. In some areas we were required to contract for field surveys using GPS to review the information. The result is a database with approximately 99% of customers’ geo referenced and knowledge of the location of all devices in the field, with very accurate information. The maintenance module is not only able to maintain the Power Network but also the entire land base.
Following that, as we had planned, we deployed tools for load flow. The load flow also was based on the parameters from a mainframe legacy system and was developed to finish its use. It enabled the connection of new customers to be based on electrical evaluation of the circuit “on the fly”.
At the same time we have deployed a brand new module for data maintenance of the optical and coaxial networks. The Optical network attends the automation project of the companies as well as the cable TV company. The coaxial network attends the cable TV company. The synergy of the two business lines started taking advantage of the same database in order to minimize power interruption for their customers.
The GIS support for Outage Management System was also acquired and deployed after some customization. It deactivated a 20 year-old mimic panel and gave to operators of the distribution network tools for locating and managing devices in all the Escelsa/Enersul areas. It allows operators to open/close switches and due to the connection to our Customer Information System it is able to alert in case this operation is about to happen with any special customer like a Hospital or someone who’s life depended on an electrical device.
The next step was to deploy tools for substation planning. This tool was also acquired and had its performance enhanced “in-house” from a 14 hour calculation of the projections based on a very rough distance measurement to a 5 to 7 minute calculation of the projections based on more accurate distance measurement.
By the year 2000, we started tests on the acquired Network Design Module, which was deployed only in 2002 due to a big effort to stabilize and customize it. The module allows the versioning of the elements and after construction the data is automatically updated reducing a lot of effort on data maintenance. The module is also integrated to our ERP and provides a very powerful control on budgets for new design orders.
At that point, we also developed a tool for querying and retrieving spatial information of our distribution network which enabled us to access our GIS database with zero cost. That tool and the web site were responsible for spreading GIS to the whole company and beyond. Some contractors were able to locate customers for new connections, re-connections and disconnection with the guidance of the GIS web site.
Our GIS solution was based on some architecture definitions. These definitions are presented on the next section.
Architecture
The main requirement for the selected GIS was to be able to extend it to the whole corporation. In order to minimize costs of operational support, we should also have a solution that could be managed centrally by a small but competent group of technicians.
We defined our operational support as having three levels: 1st – Basic Support, which includes, Operational System, RDBMS (in our case ORACLE.) and LAN; 2nd – Application Support, which means all the modules deployed and the development team that knows it and is able to maintain or repair it; 3rd – Local Support, which means support to the users workstation, its peripherals and local connections.
For that to become more efficient, we decided to have what is commonly called a “thin client”. Everything should be concentrated on a single server; the “thinner” the better. The mainstream of our applications uses UNIX servers. These servers (there is one for each company) have ORACLE. as our RDBMS. The users responsible for massive data entry/maintenance and network analyses have an application that is developed based on an UNIX environment provided by the GIS software. The user was only required to install an X emulator at his/her workstation. This class of application requires mainly intense CPU resources. We currently have approximately 38 users using massive data maintenance functions simultaneously at Escelsa and around 20 at Enersul.
Our database is completely open, with all graphic and attributes data available to any other application of the companies to use.
Along with software evolution, we decided to follow the Object Orientation paradigm and deliver a three-tier application. That was through the Outage Management System, which was based on Delphi and ORACLE.; therefore the client is quite “fat”.
The environment for the Outage Management System is based on a different UNIX server with high availability and in an isolated LAN due to security reasons. Its architecture is quite different once it is based on a Delphi application accessing the ORACLE. so the user must have in his/her workstation ORACLE., BDE, VISION*. Client, plus the executable itself. This solution is three tier based.
This application allowed us to deploy a module, known as Viewer, which was license independent and significantly reduced our cost to provide GIS information to our companies. But it is still a “fat client”.
We also had a movement to deploy a web-based application as the strength of the Internet has invaded every business. Our web-based application was on top of Microsoft IIS., ColdFusion. Server and MapGuide. Server. This web application was and still is used strongly by our Call Center. This application required from the user the installation of a Plug In or Active X (depending on the user’s browser). Therefore, a “thin client” as we thought would be better for query only.
Where we are and why are we migrating now?
We have a set of applications now that extend almost all the sectors of the power companies on their major processes involving the Distribution Network. Most of the information is up to date and we are developing new projects to: integrate our SCADA system to our Outage Management System, upgrade our Outage Management System by adding Dispatch and Call Center capabilities, improving our modules for work orders and contractors information exchange, deploy a new environmental control module for our Power Generation users, continue to acquire data (specially for Enersul in the rural area), and always developing the new functions requested by all the users.
Our version of VISION*. GIS is currently 5.3.0.3.4. Our current version runs on top of SOLARIS. 2.6 Operating System and ORACLE. 8.1.7.2 RDBMS. This means that by the end of 2003 we will enter on a back level support for both, O.S. and RDBMS. There is a weak perspective that we should move on to the next version (5.4 which is based on SOLARIS. 2.8 and ORACLE. 9i) once there is no intention for VISION*. to be continued by its manufacturer. Its manufacturer has deployed a new product that uses some of the enterprise concepts and architecture of VISION*. called Autodesk GIS Design Server. that requires the client workstation to have either Autocad. or Onsite. installed. This requirement induces on the need of better client workstations and the acquisition of additional client software. We also have to rewrite a lot of our applications that are already running.
Our GIS solution that once had proved very responsive to the challenges now appears to be very inflexible and slow to attend to our customers needs.
The business strategy has changed throughout the last 2 years and has become more third party dependent for some of the internal processes. This has caused the need to exchange information and redesign our software.
Some of our mistakes and why we did it that way
Our mainstream application is closely tight to the VISION*. technology, which means that it is not a layered architecture. The solution is so coupled that most of the application will have to be rebuilt from scratch. The exception is the Delphi application that was designed in a way that, in theory, is not a big job to uncouple the old GIS layer and couple a new one.
During the last 2 years we were able to observe all the previously mentioned changes, but, in order to deliver quickly some of the requests of the users, we kept developing in our mainstream application environment. This made the running application jump from a 550 function to an almost 700 function application. Therefore, the amount of functions that need to be converted to a new technology is very high.
Big And Small Issues
There are some issues that we will need to address in order to accomplish a future migration of what we have so far.
1) Full Conversion - pros and cons: if we decide for a full conversion of the application and data, we will not deliver new functionality to our users. Moreover, we will not be able to extend some process of the companies that we could. For example, the expert location of teams in the field, Mobile information exchange between the field teams, and the Operation Center and Services Centers.
2) Lack of support - what happened to us: the lack of support for migration from the older product to the new one allowed us to choose a new technology. But the new technologies available can easily do the same (meaning that we could be “abandoned” as well) and we would have to face, in the near future, a new migration, which would be very expensive.
3) Open GIS Technology - is it safe? Choosing a totally open and free GIS platform drives us to two additional costs: the lack of warranty for mission critical systems like Outage Management System, and the need to develop and maintain all the applications, once there is no similar application free in the market. This means a lot of training and development and again very expensive.
4) Stakeholders - will they agree? The investment on GIS is recent and it is quite a task to make the stakeholders understand that it is necessary to investment again on the same subject.
5) Managing Team Expectations: if we decide for an incremental conversion, we will have in our environment two different platforms to take care of, two teams, one for each platform. There is also the side effect caused that a team would jealously receive new training and move on in terms of technology and other team will still be in charge of maintaining the older version.
6) New Strategy and the hardware in place: depending on the new technology to be chosen, it might be necessary to upgrade hardware on the client workstations, which increases the cost.
7) New dependency - how to manage that? Depending on the new technology to be chosen, there might be a new technology dependency in terms of geographic data as well, which we do not have now.
8) New design of applications - a must: the new technologies on the market implies always in a big coupling between the application and the technology. We would like to avoid that in order to minimize future migration costs. By that we have to design the new applications so that it would be easy to unplug a GIS technology and plug in another.
9) Legal requirements to be fulfilled: there are some legal requirements from the Regulation Agencies that must be attended, and therefore, there is no way to stop completely the maintenance of the running applications or the generation of special reports when a big amount of new indexes.
What Should Be The Strategy? Is It Positive Or Negative?
We have considered until now two possible strategies: incremental and full conversion of the applications.
Incremental: Meaning the development of new modules based on a selected technology and maintaining the running applications at the same time, the incremental strategy allows a gradual review of the applications and investments and also gives the chance to achieve knowledge gradually. Following we show some positive and negative points about it.
- Training and Learning – positive, because we could absorb the new technology and evolve in time. The knowledge could then be used during the reengineering of the already running applications. The knowledge of the running application is crucial for migration and the new technology needs to address some particular issues. There will be more time to gather new knowledge and think about them.
- No backlog – positive. Once we could deliver new applications to divisions of the company that were not using GIT at that point, we are attending unattended users, meaning we are moving on, improving the processes and results of the company.
- Attending legal requests – positive, because we could keep the efforts to attend legal requests without stopping evolution of the team or applications. In fact, we have to address those requests anyway, but the incremental strategy keeps the pressure over the development team stable.
- Costs – positive. There would be a new cycle of investment without the requirement of massive expenses and could fit any annual budget with no difficulty. There would be a gradual expense with less risk.
- Keep two systems alive – negative. There is a need to maintain the old system, which is done by the same development team. Either part of them would not be taking part on new developments, or all of them would have to share time attending any requirements on the old modules. Depending on the architecture of the old and new technologies the differences could show some incompatibility or force some extra effort in terms of infrastructure.
- Keep synchronized two databases – negative. An extra effort will be required to keep synchronized the databases of different GIT. There is also an effort to integrate to other systems in order to keep the solution enterprise wide.
- Team motivation - maybe negative. Depending on the path to be chosen, the team can be highly motivated by taking part on developments using the new technology. The other possibility is to create two groups and give one of them the task to gather information about the food.
- Training and Learning – positive, because there will be an opportunity to move the team forward. They will be trained and soon will be able to practice what they have learned.
- Team motivation – positive. Developers always have an appetite for new technologies and trends. The motivation will be very high and the opportunity to use the new technology will be immediate once the team takes part on migration efforts.
- Backlog – negative. There will be a constraint of resources in order to accomplish the migration as soon as possible. Therefore, some backlog will grow and needs to be addressed after migration.
- Costs – negative, because the investment requirements for a full conversion are very high.
- Attending legal requests – negative, because there will be a lack of resources to attend them. The team would be all assigned to migration. It would be necessary to plan to accommodate the legal requirements (which are unpredictable).
- Training and Learning – negative, because the developer in house would be kept aside from the new technology. There will be an increasing dependency on the technology partner.
- Team motivation – negative. Developers always have appetite for new technologies and trends. The motivation will be destroyed by the fact they will not take part on migration efforts.
- No Backlog – positive, because the development team would be available for all the needs.
- Costs – negative. There would be a very high cost for this approach. The costs of a full conversion plus the internal development team costs would be happening together.
- Attending legal requests - positive, because the development team would be available for all the needs.
With all that issues in mind, we will have to decide what platform we should adopt. There are platforms considered a commercial success and are supported by big companies around the world with thousands of users. There are also, new technologies, more like market tendencies and promising research. Most of the technologies seem to give a fair return on investment and the decision is more likely to be either paying a huge amount for a commercial success or selecting an open architecture and paying for the whole development and customization. We have a list of meaningful questions to guide us on choosing it. The key about them is to figure out whether we are moving towards a reasonable predictable future. The future is uncertain but changing some points of it into known risks will help us make the right choice. Commercial success
- Support - How does it work?
- Who uses it?
- Are they happy?
- What do they think about it?
- Who owns it?
- What do they plan for the future?
- Support - How does it exist?
- Who uses it?
- Are they happy?
- What do they think about it?
- Is it really open?
- What are the plans for the future?
- Is it possible to do everything you need?
What seems to us very clear is that we cannot afford to do a full migration without attending the daily requests of the users or stop delivering any new functionality. This is a technical point of view which does not reflect a cost x benefit analyses from the business point of view. The reasonable path to take would be to provide the companies with the new technology to extend the processes we do not extend today.
If we take that path, we can start training and learning processes of the new technology. The new users would have a GIS solution and we would add more functionality to the enterprise GIS as a whole. In the meantime, we could keep alive what is already in place, gain expertise in the new technology, and satisfy some requirements through the forth-coming years. After that, we could easily proceed with a more massive migration, because we then would gain much more productivity and response from the development team. This team would be proficient in both the running legacy application and the new technology and its particularities.
We know that along with a partial migration we will have to migrate the entire database and keep alive mechanisms for synchronization of the two databases (old one and the new to extend the new platform). We believe that this could be done with minimum effort because we have a totally open and fully accessible database, which is well known by the development team.
Our Numbers (Just Out Of Curiosity)
Notes:
ORACLE. - This is a registered trademark and belongs to ORACLE Corp.
VISION*. - This is a registered trademark and belongs to Autodesk Inc.
Autodesk GIS Design Server. - This is a registered trademark and belongs to Autodesk Inc.
Autocad. - This is a registered trademark and belongs to Autodesk Inc.
Onsite. - This is a registered trademark and belongs to Autodesk Inc.
MapGuide. - This is a registered trademark and belongs to Autodesk Inc.
ColdFusion. - This is a registered trademark and belongs to Macromedia Inc.
IIS. - This is a registered trademark and belongs to Microsoft Corp.
SOLARIS. - This is a registered trademark and belongs to SUN Microsystems Inc.