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.
