The life Cycle of OSP-FM
The Early OSP-FM releases
The early OSP-FM releases were the first releases of OSP-FM to gain broader user at U S
WEST. OSP-FM in this phase used an extract-merge back model for editing data. There
was a master database for each wire center that was in the OSP-FM system. The design
engineers would decide which area they needed to work on and they would initiate an
extract of that data from the master database. A local database was created on the
engineer's workstation for each work package (job) that the engineer was working on.
The user would then edit the local data, and merge the changes back into the master
database.
Figure 1: Early OSP-FM Architecture
U S WEST found a lot of value in the data that was put into OSP-FM. With this data
engineers could do network traces online, count make-ups, ripple changes downstream
automatically, research facilities online, and at the same time, keep the source of record
up to date without having to post changes to paper records. U S WEST was one of the
first companies to harness this type of power from GIS systems.
U S WEST encountered some problems with this model. First, the extraction process
could be lengthy. Once the data was extracted to the workstation, the engineers could
encounter problems if they did not extract the right data, or not enough data. When the
engineer had extracted all the necessary data to do the required work, putting the data
back (merge back) could cause even more problems. For example, if an engineer
changed the administrative cable name for a cable, that change needed to ripple though
all of the affected cables. If the engineer only extracted the first three sections of a cable
that has ten sections, the ripple needed to continue on to the next seven sections when the
data was merged back. Detecting that the ripple needed to continue was one hurdle, plus
another engineer may have already done a ripple that makes our engineer's data invalid.
Issue on top of issue arose from the merge back model.
U S WEST realized that the early OSP-FM releases were not a scalable enterprise
solution. The business recognized the potential of a system like OSP-FM and they did not
want to give that up. The decision was made to suspend the development of this
architecture and do a review of how to make a successful architecture. The business
evaluated GIS vendors, alternate architectures, and created some of their own criteria
about how the system should look going forward. The re-architecture effort took about a
year, and rewrote many key architectural elements.
