| GISdevelopment.net ---> GITA 2000 ---> System Architecture |
“Managing value through an Architecture Approach”
Pierre Vorster
Project Director, Operations Support Project Management Office
BC Gas Utility Ltd.
1111 West Georgia Street
Vancouver, BC, V6E 4M4
Pierre Vorster
Project Director, Operations Support Project Management Office
BC Gas Utility Ltd.
1111 West Georgia Street
Vancouver, BC, V6E 4M4
Abstract
This discussion will present the value of using an architecture to plan and manage the implementation of a corporate AM/FM/GIS project. It will explore some of the techniques employed at BC Gas. BC Gas initiated its AM/FM project in December 1997. In addition to AM/FM, a number of separate projects that form the basis of an integrated ERP and SRP strategy have been initiated. These initiatives included an SAP implementation to replace all Financial, Materials Management and H/R systems. Additional projects will replace the existing WMS, introduce a new Preventative Maintenance strategy and integrate scheduling and dispatching across the company. Finally, a new CIS Project is underway to replace the existing customer systems.
Across these projects there is significant risk of creating duplicate and conflicting business processes and developing separate silos of technology. To ensure business value, BC Gas has employed an architecture approach to both plan and manage the implementation of corporate solutions. The presentation will focus on: major components of the enterprise AM/FM system; scope and integration issues highlighted by the architecture; techniques used to manage the project; and, the benefits the AM/FM project realized by following an architecture approach to project management.
Background
BC Gas Utility Ltd. is the largest distributor of natural gas in the province of British Columbia, Canada. It was formed in 1988 when Inland Gas acquired the gas division of BC Hydro. With 750,000 customers, it has one of the largest territories amongst gas utilities in North America. BC Gas Utility Ltd is a wholly owned subsidiary of BC Gas Inc. Like many utilities across North America, BC Gas is moving into new business paradigms. Deregulation, competition and unbundling are challenging the organization to achieve operational excellence through numerous high priority initiatives. Amongst these is the AM/FM Implementation Project.
A strategic study was commissioned during 1996 to evaluate and present the business case for implementing a corporate GIS. The study identified approximately eighteen applications and three major interfaces and included a significant data conversion component. A phased implementation plan was presented which was subsequently shortened to three and a half years to drive out early business benefits. The project approval progressed through executive, Board of Directors and finally, Utilities Commission approval before officially starting in December 1997.
The AM/FM Implementation Project was initiated in a changing business environment. The organization was in the midst of a major reorganization and had initiated two major technology projects:
Projects such as this face a number of challenges.
During start up delays, the organization undergoes significant change and the basis of the value proposition is challenged. Along with organizational change, requirements change.
A three and a half year project presents significant uncertainty which is manifested in a number of business and market drivers:
Through this myriad of uncertainty and opportunity the project has a value proposition to deliver on.
Two approaches helped minimize risks and ensure project success:
Planning
The AM/FM architecture at BC Gas consists of four major components.
Figure 1 Components of the Architecture
The value of the architecture is in the relationships drawn between the elements in each of these components. Relating organizational elements to both data and application functionality requires an understanding of who in the organization will use what functionality to derive information from stored data. This requires the development of many matrices including relating organizational lists to each other. In order to effectively deploy technology the location of user groups within departments needs to be defined and an understanding of their usage developed so that both data storage and network demands can be designed.
The four components and the relationship between elements within the major components make up the architecture. The result is four detailed binders, one for each major component. Two summary documents summarize the architectures from two different perspectives with two different audiences:
Managing costs and benefits
Understanding the impact of one element of the plan on another through an architecture, allows the project to manage the cost / benefit model at every stage. By including and starting the planning phase with a definition of the Organizational Model a business perspective to the project is induced. It creates a focus on the value proposition that is subsequently maintained throughout the project.
If for example, the organization reorganizes during the project, resulting in changes within a department, this could impact the number of PC’s, the number of licenses and even the functional requirements. The architecture and associated model of costs and benefits, provides a framework against which to evaluate these and other changes. Since the costs and benefit realization plan were derived from the architecture, the impact of change can be readily assessed. The value proposition can be protected by balancing the changes in cost with associated benefits.
The architecture also provides a framework to evaluate new off-the-shelf solutions. New products often bundle functionality differently to that of the original plan. The evaluation of a new product requires that a functional fit be performed and an assessment of the cost to customize for these gaps. Since the architecture links each major application functional component to costs and benefits, the value to the organization of the new product can be determined. Cost of customization should be balanced with associated benefits. From an overall perspective, the off-the-shelf alternate solution should deliver the same value proposition, or better, than that originally planned.
The architecture helps manage the major components of the project at BC Gas, including Scope Management, Risk Management, Procurement Management, Resource Management, Planning and Budget Management.
Building the Applications
Projects of longer duration typically face the challenge of managing scope but at the same time not delivering, to the business, a dinosaur that was needed two years ago. To keep pace with business change, functional scope needs to be flexible. Using an object oriented GIS is key for the delivery of value at BC Gas. The application architecture needed to embrace the concepts of object oriented design such as inheritance and re-use.
The application architecture at BC Gas was designed to firstly, align with business processes and secondly, allow for a delivery plan that built modules upon previously delivered functionality. Four major phases of delivery based on key business processes were identified :
Alignment with the Corporate Architecture
During the AMFM Project at BC Gas a number of other large initiatives were started. This included the replacement of WMS and introduction of Preventative Maintenance strategy. At the same time the CIS replacement project pilot ended and the full implementation started. Finally, Device Management as well as automated Scheduling and Dispatch projects were being planned.
The associated business processes can be supported by application functionality in a few ways:
Building the corporate architecture after the AM/FM architecture was completed, required the project teams to verify the two architectures. Through the application of architecture principles, inconsistencies in the architected solution were highlighted. An example of this is that of the ‘Valve Maintenance System’ that the AM/FM Strategic Study specified.
BC Gas’ architecture principles require that applications are architected to conform to logical business boundaries and that applications be designed to support business processes that run across business units and pass data transparently.
Building a ‘Valve Maintenance System’ violates these principles in that it supports a vertical slice out of a number of horizontal business processes, instead of supporting a full business process or sub-process. In other words, building a tool that supports a part of the maintenance processes for all and any facility is better than building a tool that performs most of the maintenance functions, but for valves only.
The AM/FM Project redesigned the ‘Valve Maintenance System’ functionality to leverage the strengths of a spatial analysis tool rather than build preventative maintenance functionality that most ERP tools do so well. The result is that AM/FM will provide ‘Survey Tracking and Planning’ tools which will integrate with ERP’s preventative maintenance modules. The maintenance of valves will be supported by both AM/FM and ERP tools. The major advantage is that the maintenance of all facilities can be supported by the same set of tools. In addition, new facilities (or multi-utility facilities) can be added without any modifications to any of the applications.
The added advantage of subscribing to and participating in the corporate architecture, is that the GIS technology finally attains corporate recognition. It is designed into the corporate architecture as an integrated ERP and SRP (Spatial Resource Planning) solution.
Lessons learnt from building an Architecture
Building an architecture does not come without cost. The return on investment is maximized when the right level of detail is achieved. The pressure to deliver early in the project can limit the investment in up front planning with subsequent risks downstream. The team falls into the trap of starting the project before properly planning the project. On the flip side, too much time and money can be spent planning by succumbing to analysis paralysis. The following lessons can be drawn:
Building an architecture is an investment in a structured and formalized approach to driving out a comprehensive project plan for larger and longer duration projects. It provides a framework against which all project decisions can be made.
In conclusion, the following summarizes the major benefits of building and using an architecture to plan and manage the implementation of enterprise GIS:
This discussion will present the value of using an architecture to plan and manage the implementation of a corporate AM/FM/GIS project. It will explore some of the techniques employed at BC Gas. BC Gas initiated its AM/FM project in December 1997. In addition to AM/FM, a number of separate projects that form the basis of an integrated ERP and SRP strategy have been initiated. These initiatives included an SAP implementation to replace all Financial, Materials Management and H/R systems. Additional projects will replace the existing WMS, introduce a new Preventative Maintenance strategy and integrate scheduling and dispatching across the company. Finally, a new CIS Project is underway to replace the existing customer systems.
Across these projects there is significant risk of creating duplicate and conflicting business processes and developing separate silos of technology. To ensure business value, BC Gas has employed an architecture approach to both plan and manage the implementation of corporate solutions. The presentation will focus on: major components of the enterprise AM/FM system; scope and integration issues highlighted by the architecture; techniques used to manage the project; and, the benefits the AM/FM project realized by following an architecture approach to project management.
Background
BC Gas Utility Ltd. is the largest distributor of natural gas in the province of British Columbia, Canada. It was formed in 1988 when Inland Gas acquired the gas division of BC Hydro. With 750,000 customers, it has one of the largest territories amongst gas utilities in North America. BC Gas Utility Ltd is a wholly owned subsidiary of BC Gas Inc. Like many utilities across North America, BC Gas is moving into new business paradigms. Deregulation, competition and unbundling are challenging the organization to achieve operational excellence through numerous high priority initiatives. Amongst these is the AM/FM Implementation Project.
A strategic study was commissioned during 1996 to evaluate and present the business case for implementing a corporate GIS. The study identified approximately eighteen applications and three major interfaces and included a significant data conversion component. A phased implementation plan was presented which was subsequently shortened to three and a half years to drive out early business benefits. The project approval progressed through executive, Board of Directors and finally, Utilities Commission approval before officially starting in December 1997.
The AM/FM Implementation Project was initiated in a changing business environment. The organization was in the midst of a major reorganization and had initiated two major technology projects:
- a replacement of the CIS systems; and,
- an SAP implementation of Financials, HR and MM modules.
- integrated scheduling and dispatch; and,
- replacement of WMS and Preventative Maintenance system.
Projects such as this face a number of challenges.
During start up delays, the organization undergoes significant change and the basis of the value proposition is challenged. Along with organizational change, requirements change.
A three and a half year project presents significant uncertainty which is manifested in a number of business and market drivers:
- competition and deregulation drives continual organizational change
- during the project, new off-the-shelf application solutions enter the market, with functionality bundled differently to that designed in the project plan. There are benefits to adopting these new solutions
- the base GIS product (Smallworld) continues to be enhanced, reducing the requirement to buy or build add-on functionality
- new projects typically start up, taking advantage of other off the shelf products that in many cases overlap to some degree with the functionality being delivered by AM/FM.
Through this myriad of uncertainty and opportunity the project has a value proposition to deliver on.
Two approaches helped minimize risks and ensure project success:
- To provide maximum flexibility in the design and delivery of the applications and to make best use of the Smallworld technology the project team identified an object oriented approach to delivering applications, leveraging inheritance and re-use wherever possible.
- To mitigate the risks and capitalize on opportunities, these and other factors resulted in the development of an AM/FM architecture to help plan and manage the project.
Planning
The AM/FM architecture at BC Gas consists of four major components.
-
Organizational Model: A view of the organization as it pertains to AM/FM. This
includes a high level definition of business processes and many spreadsheets
listing departments, user groups, locations and job types. It defines the to-be
organizational model at a high level.
Application Architecture: Defines and groups functionality required to support the organizational processes and functions. Interfaces are identified and conceptually designed.
Data Model: Defines the data entities and attributes required by the applications to deliver the functionality and information required by the business.
Infrastructure Architecture: Defines the hardware and software required to support the system and includes network (WAN and LAN) requirements, servers, desktops workstations, software licenses, printers and plotters.
Figure 1 Components of the Architecture
The value of the architecture is in the relationships drawn between the elements in each of these components. Relating organizational elements to both data and application functionality requires an understanding of who in the organization will use what functionality to derive information from stored data. This requires the development of many matrices including relating organizational lists to each other. In order to effectively deploy technology the location of user groups within departments needs to be defined and an understanding of their usage developed so that both data storage and network demands can be designed.
The four components and the relationship between elements within the major components make up the architecture. The result is four detailed binders, one for each major component. Two summary documents summarize the architectures from two different perspectives with two different audiences:
- Summary Architecture - The Technical Perspective (technical audience)
- Summary Architecture - The Business Perspective (business stakeholders) The architecture planning effort drives out plans for the three components of the project :
- Development and Implementation Plans (including application development plan and IT deployment plans)
- Data Conversion Plans (paper and digital)
- Change Management Plans (including business process redefinition plan, training plan and communication strategy)
Managing costs and benefits
Understanding the impact of one element of the plan on another through an architecture, allows the project to manage the cost / benefit model at every stage. By including and starting the planning phase with a definition of the Organizational Model a business perspective to the project is induced. It creates a focus on the value proposition that is subsequently maintained throughout the project.
If for example, the organization reorganizes during the project, resulting in changes within a department, this could impact the number of PC’s, the number of licenses and even the functional requirements. The architecture and associated model of costs and benefits, provides a framework against which to evaluate these and other changes. Since the costs and benefit realization plan were derived from the architecture, the impact of change can be readily assessed. The value proposition can be protected by balancing the changes in cost with associated benefits.
The architecture also provides a framework to evaluate new off-the-shelf solutions. New products often bundle functionality differently to that of the original plan. The evaluation of a new product requires that a functional fit be performed and an assessment of the cost to customize for these gaps. Since the architecture links each major application functional component to costs and benefits, the value to the organization of the new product can be determined. Cost of customization should be balanced with associated benefits. From an overall perspective, the off-the-shelf alternate solution should deliver the same value proposition, or better, than that originally planned.
The architecture helps manage the major components of the project at BC Gas, including Scope Management, Risk Management, Procurement Management, Resource Management, Planning and Budget Management.
Building the Applications
Projects of longer duration typically face the challenge of managing scope but at the same time not delivering, to the business, a dinosaur that was needed two years ago. To keep pace with business change, functional scope needs to be flexible. Using an object oriented GIS is key for the delivery of value at BC Gas. The application architecture needed to embrace the concepts of object oriented design such as inheritance and re-use.
The application architecture at BC Gas was designed to firstly, align with business processes and secondly, allow for a delivery plan that built modules upon previously delivered functionality. Four major phases of delivery based on key business processes were identified :
- Create and Maintain Facilities Information (Map and Facilities) : This included drafting functionality, interfaces to document management systems, enhanced editors and query tools.
- Maintenance Planning : This includes Corrosion & Cathodic Protection as well as Survey Planning & Tracking functionality. Enhanced Thematic Mapping completes this delivery.
- System Planning and Outage Analysis : This includes an interface to Stoner’s SynerGEE and Emergency response analysis functionality.
- Facilities Design and Planning : This includes enhanced design tools and interfaces to WMS.
- Core GIS software (out-of-the-box functionality) : Smallworld version 3.0, currently installed at BC Gas, offers significant out of the box functionality and an object oriented design. This allows for an object oriented approach to developing and deploying functionality.
- Data Maintenance and Integrity Tools : This category includes enhancements to basic GIS functionality required by most utilities and business applications. Generally it includes enhancements to drawing functions and object editors.
- Application Utilities : Architecture planning and development forces the project to decompose functional requirements and facilitates the identification of common modules required to support business functionality. Identifying these modules early in the project allows these functions to be designed and built once. This category of application also includes reporting engines and the QA/QC tools required for both data conversion and ongoing data integrity.
- Business Modules : These modules deliver business functionality and can include Corrosion & Cathodic Protection, Outage Analysis, Facilities Maintenance and Facilities Design
Alignment with the Corporate Architecture
During the AMFM Project at BC Gas a number of other large initiatives were started. This included the replacement of WMS and introduction of Preventative Maintenance strategy. At the same time the CIS replacement project pilot ended and the full implementation started. Finally, Device Management as well as automated Scheduling and Dispatch projects were being planned.
The associated business processes can be supported by application functionality in a few ways:
- Best of Breed packages : generally have functional strength but are specific to certain business functionality.
- Broadly integrated packages such as Enterprise Resource Planning (ERP) products that are well integrated but lack functional strength in some key modules.
- In-house development : provides the best functional fit but generally require a larger capital and ongoing maintenance investment.
Building the corporate architecture after the AM/FM architecture was completed, required the project teams to verify the two architectures. Through the application of architecture principles, inconsistencies in the architected solution were highlighted. An example of this is that of the ‘Valve Maintenance System’ that the AM/FM Strategic Study specified.
BC Gas’ architecture principles require that applications are architected to conform to logical business boundaries and that applications be designed to support business processes that run across business units and pass data transparently.
Building a ‘Valve Maintenance System’ violates these principles in that it supports a vertical slice out of a number of horizontal business processes, instead of supporting a full business process or sub-process. In other words, building a tool that supports a part of the maintenance processes for all and any facility is better than building a tool that performs most of the maintenance functions, but for valves only.
The AM/FM Project redesigned the ‘Valve Maintenance System’ functionality to leverage the strengths of a spatial analysis tool rather than build preventative maintenance functionality that most ERP tools do so well. The result is that AM/FM will provide ‘Survey Tracking and Planning’ tools which will integrate with ERP’s preventative maintenance modules. The maintenance of valves will be supported by both AM/FM and ERP tools. The major advantage is that the maintenance of all facilities can be supported by the same set of tools. In addition, new facilities (or multi-utility facilities) can be added without any modifications to any of the applications.
The added advantage of subscribing to and participating in the corporate architecture, is that the GIS technology finally attains corporate recognition. It is designed into the corporate architecture as an integrated ERP and SRP (Spatial Resource Planning) solution.
Lessons learnt from building an Architecture
Building an architecture does not come without cost. The return on investment is maximized when the right level of detail is achieved. The pressure to deliver early in the project can limit the investment in up front planning with subsequent risks downstream. The team falls into the trap of starting the project before properly planning the project. On the flip side, too much time and money can be spent planning by succumbing to analysis paralysis. The following lessons can be drawn:
- take a business focus : start the planning phase by identifying the key business processes impacted and align the functional development and implementation plan along these processes. This will ensure that the business objectives and the value proposition is front and foremost.
- the devil’s in the details : planning at the high level leaves too much to risk while diving into too much detail at the planning stage delivers diminishing returns on investment. To what level of detail should business processes be defined? How detailed should preliminary requirements definition be? Should all the object attributes be defined?
- it’s a guide not the gospel : on longer duration projects it is crucial to use the architecture to manage scope, not contain it. The business has no use for functionality planned three years ago if the business model and requirements have subsequently changed. Use the architecture to make business decisions. The architecture is equally as effective at containing scope creep by providing a framework to measuring the impacts and associated costs of scope changes.
- publish or perish : commit publicly to your plan. Publish the architecture documents.
- don’t become a slave to the architecture : keeping the architecture details up to date on every small project development can erode the initial investment. The architecture is as much a structured process for understanding the dynamics of the project as it is a final deliverable. Verifying the architecture at the start of each major phase or for critical decisions is enough to retain the value of the initial effort.
Building an architecture is an investment in a structured and formalized approach to driving out a comprehensive project plan for larger and longer duration projects. It provides a framework against which all project decisions can be made.
In conclusion, the following summarizes the major benefits of building and using an architecture to plan and manage the implementation of enterprise GIS:
- it provides a structured approach to planning
- it provides a framework against which to make decisions
- it forces a business focus to planning and delivery
- it links cost and associated benefits realization to every aspect of the project and commits project action to the value proposition
- it facilitates enterprise recognition of the GIS. An integrated ERP and SRP solution.