Managing updates to protect your data investment

Managing updates to protect your data investment

Michael Carr, Jennifer Fischer
Programmer Analysts, Ohio Edison Company, 253 White Pond Drive, Akron, Ohio 44320

Abstract
Ohio Edison’s implemented work request application controls the data updates to the production database while managing a construction project through its life cycle of planning, design, construction and as-built. Versioning rules permit multiple engineers to concurrently work on a common asset base while managing a particular project through the process stages. The tradeoffs of optimistic versus pessimistic control and central versus copied project databases are also described.

Introduction
Ohio Edison is an electricity provider for more than one million customers over 9000 square miles of Ohio and Pennsylvania. To streamline operations and improve customer service, Ohio Edison has been investing in information technologies. A key area was managing the network infrastructure using an AM/FM system. The initial emphasis has been on creating and maintaining an accurate database.

The creation phase is being done by outside conversion vendors. As an operating area is finished, it is loaded into the main database. From that point on, any changes-reflecting either new construction or backlogged changes that occurred during conversion—are made by a team of drafters. Management of this concurrent activity becomes paramount. Because of Ohio Edison’s sizable investment, the data is ‘golden.’

Requirements
Managing concurrent activity presents a number of challenges that must be addressed.

Conflict Management-A controlled method is needed for dealing with users working on common data.
Communication—A method is required for users to see what other users are doing.
Performance and Scalability—Performance must not be degraded when adding concurrent users.
Process Control—A well-defined method is required to ensure the quality of changes made to the database.
Enterprise Database-The database must always be current, all on-going activities in the database have to be ‘viewable,’ and a seamless view of the network is essential.

Solution Architecture
Essentially, the challenge focused on a change management process. The first component of the solution was to define the unit of change. This became the Work Request. A Work Request represents a complete, self-contained set of changes related to an activity. The activity could be something that occurred in the field (e.g., addition of a new pole) or the correction of errors found in the existing data. Work Requests are identified by type, user, and related system work request number.

Recmirement On-Conflict Mana~ement
Ohio Edison’s primary focus is electric distribution (as opposed to transmission). This means that changes to the infrastructure tend to be small and localized, but occur with great frequency. The Work Request process typically takes less than one week—usually one day. A user may process several Work Requests at once.

Because the Work Request process is short in duration and very localized, it was decided that apessimistic conflict management approach would be best. In this approach, User A is notified of a conflict at the start* of a Work Request (i.e., another Work Request is already underway that is using some or all of the data that User A may need to use). The notification identifies the conflicting Work Request and its owner. The resolution is simple. User A contacts the owner and negotiates a resolution. Either the owner finishes the conflicting Work Request, incorporates User A’s changes, or removes the Work Request.

Requirement Two-Communication
All Work Requests in the system are defined and viewable in the central database. In this way, any user can see pending work. This is especially important for engineers who have supervisory responsibilities. This simplifies task scheduling while providing an overview of the areas undergoing change.

*In an optimistic approach, the user makes the changes and hopes that when the changes are committed, no conflict problems occur. If conflicts occur, the entire Work Request maybe abandoned or significantly altered.

Ultimately, the Customer Call Representatives will benefit by being able to tell customers if proj ects are underway in their areas as well as the nature of the projects.

Requirement Three-Performance and Scalability
The technical architecture must be properly designed or the impact on performance of having one database serving many users of different types will be unacceptable. The key is to minimize traffic to the central database—the technique used is display caching. This technique recognizes that most spatial data requests are for the display of background information to be used as context. Display caches are pre-built from common views of the database. For example, content varies by primary and secondary electric distribution networks. Consequently, two sets of display caches are created for these cases. The display caches are updated when changes are made to the data. Because the ratio of volatile to static data is small, this happens quickly.

One of the arguments for having separate project databases for each Work Request is the independence of users of a central database. The perceived impact on performance occurs only at the start (extract) or end (mergeback) of the project. The reality is that from a system administration stand-point, there is more work-everything from back-ups to synchronization. This impact on administration resources ultimately degrades the ability to handle large numbers of concurrent users effectively. Therefore, the scalability requirement is missed. Unfortunately, with this project-based approach, all other requirements are also missed. With separate project databases:

Communication is difficult.
There is no single view of all the activity in the enterprise.
Conflict management takes more effort (one user cannot see what the other is doing).
Process management is more complex.

Requirement Four—Process Control
The Work Request is controlled through a workflow process to help ensure the quality of the data. The workflow process is defined as a set of stages. Currently, only one process definition (Work Request Type) is being used—Map Maintenance (Table 1). The stages in use are

Creation
Completion of Data Changes
Verification Sign-off
Permanent Commit

The Work Request moves through these stages when users perform certain tasks. Once a task is complete, the user promotes the Work Request to the next stage. Security privileges control what type of user can promote a Work Request. A user has the option of rolling back a stage to a previous stage.

Table 1- WorMow for Map Maintenance

Stage	Task	Owner	Description
	Data creation/maintenance	Drafter
Ready form Approval		Drafter	Drafter promotes Wrok Request
	Validation	Suppervisor	Often involves trace testing to ensure proper connectivity either the Supervisor or Drafter will fix the problem
Commit Changes		Supervisor	Promotes the data into a permanent status; the Work Request is completed

Within a task, the user cart define check-points. These allow the grouping of sub-tasks that can then be rolled back to a previous check-point. This capability is typically used in the Data Creation and Maintenance task. Often, the user adds some structures, completes a logical group (e.g., pole and associated transformers and switches), and then moves to the next logical group.

Requirement Five-Enterrmise Database
This requirement can be met only if there is a single database that contains the actual energized network infrastructure and any on-going modifications and additions. The system must allow for different versions of the data to be held, viewed, and manipulated within a single database by multiple users.

With all data (reposed, underway, and current) contained in a single database, the system must support multiple views. In this way, depending on task and/or privilege, a user may only want to see the ‘energized’ database. A supervisor may want to see all the Work Requests underway.

The converse approach would be a database of record and a set of project databases (extracting data, making changes, and then committing) for handling individual Work Requests. This approach would negate the enterprise benefits. It would also make the performance of tracing tasks that require data beyond the Work Request area problematic.

“ The Drafter would have access privileges only for this type of Work Request. For other types, the Supervisor would likely roll-back the stage and advise the user to fix the problem and then re-promote.

Solution Implementation
The solution was implemented using the versioning and locking capabilities of VISION**. Together, these provide the foundation ofrepresenting, accessing, and manipulating multiple views ofthe same database. VISION* ‘s display caching capability isusedto minimize traffic tothe database server. This enhances scalability and performance.

These base capabilities were used in a layered product called the Version Update Control System** (VUCS). Written in VISION*’s fourth generation language, VUCS enabled the creation of specific Work Request types as well as the tools for managing the workflow process. Ohio Edison then customized VUCS to meet its specific needs. For simplicity of implementation, Work Requests are defined by a geographic area. All features in the area are locked as part of the Work Request, regardless of whether they will be changed.

Future Plans
The workflow currently being used is quite simple and reflects basic map-maintenance tasks. Ohio Edison will be adding engineering design tasks that will require a more complex set of stages. In addition, these stages are being integrated with a Work Management System that will enable the engineer to take a holistic view of the design challenge. Tradeoffs on material usage, crew scheduling, and loading will be able to be collectively analyzed and then committed to. The integration with Work Management is facilitated by the use of art open, commercial database (ORACLE***) in the AM/FM solution.

Although a minority, long-term Work Requests will need to be handled. These tend to focus on large-scale proposed changes to the electrical network and may take up to a year to complete. This will require two major enhancements:

Only those features that have changed during the life of the Work Request will be locked (as opposed to the area-based locking where all features are locked). This minimizes potential conflicts.
Incremental commits will be allowed. This enables the owner of the Work Request to commit data that has been completed.

From the experience of the simple Map Maintenance task, it is clear that up-front investment in controlling how changes are made to data pays large dividends in terms of quality and efficiency. Any fiture applications will need to be analyzed and designed with this change management challenge in mind.

* VISION*, a spatial information management product from MCI Systemhouse, is used by Ohio Edison as the AM/FM solution.
**VUCS is a product of Geographic Information Technologies (GIT).
***ORACLE is a database management product from Oracle Corporation.

Conclusions
As a provider in a de-regulated industry where there is a need to be more competitive in both cost and service, Ohio Edison is investing heavily in improving their network facility. Because of its critical nature, the data must be managed in a predictable manner through its life cycle of change. For this to happen, a workflow system was designed that addresses conflict resolution, process control, performance, and communication while preserving the benefits of a true enterprise database. This was made possible by an underlying technology that supports concurrent update, versioning of data as well as providing tools for ensuring scalability.