Utility and public works managers today are faced with the predicament of aging infrastructure (such as water, sewer, roads, bridges, etc.), budgets and staffing that are stretched to capacity, and increased regulatory requirements. Over the past few years, a new paradigm has arisen to manage these issues: asset management. However, asset management is often no more than a concept. Even those organizations that commit to this concept often struggle with implementation. Any such implementation must also focus on practical data and systems management strategies to provide the foundation for success in implementing asset management.
Before defining a solution, it’s helpful to understand where we are with respect to asset data and how we got here. In many organizations, infrastructure data is scattered in multiple datasets, and there is no single, authoritative version of reality. How did this happen? With the best of intentions, individual departments selected applications or built databases to manage the information they needed. This grew over time, so that a typical organization had separate financial, customer information (billing), permitting, maintenance, and geographic information systems, along with separate databases for as-built drawings, construction photographs, inspection records, and so on.
The problem isn’t a lack of data – it’s an overabundance of data about the same features. So when we ask simple questions, like how many valves do we have in each district, how many feet of cast-iron water main are in service, or how many signals did we install last year, we get different answers depending on which source we use. More importantly, there is a tremendous duplication of effort as the same data is entered and maintained (inconsistently) in multiple places. And because these applications do not easily share information, handoffs between them are typically cumbersome, slow, and manual.
Successful data management isn’t automatic – it requires planning, standardization, and updating or replacing existing solutions that don’t fit. Along the way, change will be needed. Although change is often painful and difficult, the rewards of an environment in which information can be easily shared between all users is more than ample payback for the investment.
Strategy 1: GIS-Centric Asset Data Management
Many of the readers of this article have already adopted the first strategy – use GIS to centralize the management of all the data about the physical assets themselves. The Esri GIS product family is the most popular GIS product in today’s market. The power lies in the Esri geodatabase, which provides the means to develop an abstraction of the real-world infrastructure, including connectivity, relationships, and rule-based behaviors in the software. It’s important to create data structures in your GIS that mimic your real-world assets to the extent that is practical. GIS can be extended beyond the typical uses in utilities and public works to incorporate features within facilities, including pump stations and treatment plants, at a high degree of detail. This means that GIS can be used as the repository for all of the core data that describes any real-world asset.
Because it can become the unifying core to which all other asset-related data elements (digital photographs, record drawings, permit forms, etc.) are attached, a GIS-centric data structure provides the foundational element for any asset management system. But GIS-centric data only addresses static asset data, not activities. Additional solutions must be added to address the activities an organization performs to maintain its assets.
Strategy 2: GIS-Centric Software Products
The second asset management strategy is to adopt GIS-centric software products. To be GIS-centric, a product has to use the geodatabase as the repository for its asset data. This means the investment in the geodatabase discussed earlier is leveraged by the tools used to manage the assets. The value of this concept is well understood by Cityworks users. Because they have only one authoritative source in which their asset data is stored, they can put all their energy into keeping it current and accurate.
Contrast that with users of other, non-GIS-centric asset management products. They, of course, are using GIS and have all their assets stored in the GIS. But each of those assets is also stored again in their asset management product’s own database. No matter how hard they try to keep these systems synchronized, they still have two sources of reality, leading to complex data maintenance processes and inconsistencies.
There are other GIS-centric solutions that address other asset-management-related needs, including hydraulic modeling, call-before-you-dig compliance, vehicle routing, as well as others. A number of GIS-centric software vendors (including Azteca) have banded together to create an organization called the National Association of GIS-Centric Software (NAGCS). More information about NAGCS can be found at www.nagcs.com.
When possible, selecting products that use a GIS-centric approach can leverage the investment in the geodatabase and provide a ready-made environment for integration. But this only addresses a portion of the problem.
Strategy 3: Service-Oriented Architecture
Many of the solutions an organization requires – such as customer service, permitting, finance, HR, project management, and SCADA, to name a few –are not available as GIS-centric solutions. Therefore another strategy must be employed to integrate these applications. Many such strategies have been employed over time, starting with file transfers and progressing to point-to-point automated data transfer-style interfaces. Eventually, the number of connections and the complexity of managing change becomes overwhelming. Figure 1 shows an example of an organization with numerous point-to-point application interfaces that became unmanageable.
But because these solutions are based on importing files or directly updating databases, they are fraught with challenges. Such solutions can break down for no apparent reason, and if any of the integrating applications changes due to an upgrade, these point-to-point connections often have to be reconstructed.
A better approach is available – based on the Service-Oriented Architecture (SOA) concept. With SOA, services talk directly to other services and exchange data based on a loosely coupled concept. A set of orchestration tools connect the services and monitor the data exchanges. There are many advantages to the SOA approach. The use of standards maximizes the ease of integrating off-the-shelf products, and orchestration services allow for easy monitoring and recovery if problems occur. Because the services are typically built into newer applications, they shield the data exchanges from changes in the underlying data structures or changes due to upgrades. And once the framework is built, incremental applications can be easily added. Figure 2 illustrates an example of SOA framework.
This framework shows how the multiple tiers work together. The end-user applications are on the top tier. They call orchestration services that in turn call upon specific spatial services, which are the only ones directly interacting with the data repositories. So, if an application change is made at the lowest level, the only required changes are in the spatial service or services that interface with that application. Likewise, an end-user application can be updated (possibly from Web ADF to Silverlight interface) without having to rebuild any of the underlying logic.
Using the SOA approach, Woolpert has developed a middleware “product” to standardize communication between Cityworks and external applications using a lightweight Enterprise Service Bus (ESB) as shown in Figure 3.
This framework greatly simplifies the effort needed to build interfaces to customer information systems, financial systems, public access portals, etc. The result of the SOA-middleware approach is application integration that is affordable, adaptable, robust, and secure.
A Template for Success
To summarize, the data and systems management strategies that make asset management successful include the following steps:
1. Determine an integration architecture appropriate for your organization.
2. Develop a GIS-centric asset database structure.
3. Select GIS-centric applications where available.
4. Select non-GIS-centric applications with open architecture and web services.
5. Use Service-Oriented Architecture (SOA) to integrate using loosely coupled concepts.
By John M. Przybyla, PE, GISP, Senior Vice President, Woolpert
Comments (0)