Easier Deployment

One of the biggest benefits of a water utility adopting the Local Government Information Model is that it makes deploying the ArcGIS for Water Utilities maps and apps easier, faster and cheaper.  The further you deviate from the Local Government Information Model, and in particular it’s geodatabase schema, the harder it will be for you to implement the maps and apps that are part of ArcGIS for Water Utilities. It will also be hard and time consuming to upgrade your ArcGIS for Water Utilities implementation when we release updates.

Changes you make to the Local Government Information Model schema may necessitate extensive modifications of the maps documents, and changes to apps (web apps, mobile apps, ArcGIS Desktop, etc.) that are part of ArcGIS for Water Utilities.  So the closer you stay to the core Local Government Information Model, the easier your initial deployment will be and the easier it will be to migrate your ArcGIS implementation to new releases or to deploy updates to the maps and apps.

It’s also important to note that when we say “adopt” the Local Government Information Model we don’t mean that you necessarily have to use it as is (or more appropriately – as downloaded).  You probably will need to configure the Local Government Information to meet the needs of your organization.   But the key thing to keep in mind is you should only be making changes to accommodate the true organizational needs of your utility. For example, instead of changing the field names to the field names you’d like to use in your organization, modify field and map layer aliases.   Bottom line, don’t reinvent the wheel, just make changes that are required to meet specific business needs in your organization.

At the very least you need to change the projection to the appropriate coordinate system and set up the domains to reflect the assets in use at your utility.  Small utilities or utilities that are new to GIS may choose to take the Local Government Information Model as is, while larger utilities, mature GIS implementations, or GIS implementations that are integrated with other enterprise system will undoubtedly need to make more significant configurations or extensions to the schema to reflect their organizational needs.  

Water, Sewer and Stormwater Data Modeling Best Practices

The Local Government Information Model incorporates many best practices for water utility GIS.  One of the most important best practices is how to represent a water, sewer or stormwater system in GIS.  

For years Esri had downloadable data models for water, wastewater and stormwater utility networks.  Those data models were the first freely available water utility GIS data models.  They were stewarded by Esri, but built by the user community and became the industry standard.  Globally thousands of water utilities have built their GIS around Esri’s free data models.  

The Local Government Informational Model is the next iteration of Esri’s water, sewer and stormwater data models.  In essence we’ve modernized the data models to reflect how water utilities have been deploying GIS over the past few years and we’ve also modified the schema to fit the requirements of the ArcGIS for Water Utilities maps and apps.  As water utility GIS continues to evolve Esri will regularly maintain the Local Government Information Model to keep introducing new best practices into the user community and functionality into our apps.

Comprehensive Data Model

There is no doubt Esri’s water, wastewater and stormwater data models were an incredibly valuable starting point for water utilities to get their utility networks into GIS.  Since the original data models focused primarily on a data structure for the assets that comprise utility networks, we received feedback that many utilities wanted more guidance on how to model operational data (workorders, service requests, customer complaints, main breaks, capital improvement projects, etc.) and base data (roads edge of pavement, road centerlines, elevation data, parcels, etc.) in their GIS.  The Local Government Data Model solves this problem because it includes a complete schema for typical water utility base data and operational data.  

Over the years, an observation we’ve made is that water utilities struggle with how to model and manage schemas for datasets that aren’t their utility networks or operational data – simply put managing base data can be a challenge for water utilities. For example we’ve seen a lot of utilities struggle with managing roads, parcel, buildings, etc. in their enterprise GIS, especially when these datasets are coming from other organizations or departments.

This is a particular issue for water utilities that serve multiple units of local government such as authorities, county wide utilities, state wide utilities and private companies.  A good example of this is a water authority whose service territory includes three counties.   The water authority needs parcel data that is maintained by the counties.  County A, County B and County C all use different schemas for their parcels.  So the water utility had two choices – leave the parcels in 3 different data layers and use them as is – which makes analysis, map creation and integration with other systems at the utility that need parcel data (such as a customer information system) difficult.  Or invest time to extract, transfer and load (ETL) the parcels into a common schema so they can be used as a single seamless layer across the service area.  The Local Government Information Model can now serve as the common schema in this example.
 
Easier Data Sharing

We describe the Local Government Information as a harmonized information model – meaning designed to accommodate typical GIS needs across local government.  If organizations that commonly share data all adopt the Local Government Information Model, it will greatly reduce the time and resources spent establishing a common schema and migrating data to these schemas – thus allowing water utilities to focus on the maintenance and management of their authoritative data.

For example a private water utility may serve two municipalities.  If the water utility and both municipalities all adopt the Local Government Information Model then they can all very easily exchange data.   When the water utility needs road centerline and edge of pavement layers from the municipalities than the utility can just import the new data without having to manipulate the schema and will have seamless layers for their service areas.  The same logic applies to the water utility sharing data with the municipalities – when the water utility updates the location of their upcoming capital projects, the utility can share that data back with the municipalities and the municipalities can use it without any schema manipulation.

Best Cartographic Practices for Water Utility Maps

As we’ve discussed in a previous blog, the Local Government Information Model includes geodatabase schema, map documents and specification for services necessary to deploy the ArcGIS for Water Utilities and ArcGIS for Local Government maps and apps.  

The map documents highlight best practices for displaying water, wastewater and stormwater data in the context that each map is designed to be used.  For example the map documents included with the Mobile Map Template have best practice cartography for displaying water utility GIS data in the field in both a day and night time use map.  The same goes for the map document included with the Infrastructure Editing Template – this is a best practice map document for editing water utility data with ArcGIS Desktop.

Looking to the Future

The specification for the services (map, feature, geoprocessing, etc) necessary for the ArcGIS Water Utilities maps and apps are also part of the Local Government Information Model.  So if other local government entities in the service area of water utility embrace the Local Government Information Model, ArcGIS for Local Government and start to publish services, then water utilities can consume those services for their maps and apps.  In this scenario the water utility may no longer have to import some data into their own geodatabase and can just consume the services right from the organization that is the steward of the data.

We hope you’ve found this exploration of some of the benefits water, wastewater and stormwater utilities will experience when adopting the Local Government Information Model helpful.  We encourage your feedback on the information in this blog, the Local Government Information Model or ArcGIS for Water Utilities.

IT departments may not always be familiar with GIS data and the workflows used to create, manage and distribute this information. Esri provides several online resources to assist you in building a secure, stable, scalable and high-performance enterprise GIS system. Here are some key resources:

• An Enterprise GIS Resource Center designed to help IT professionals implement a sustainable enterprise GIS by presenting best practices, patterns, and guidance in the areas of security, performance, and application architecture.
• A comprehensive System Design Strategies Wiki that describes in detail the Esri system architecture design methodology and the fundamental principles that contribute to system performance and scalability.

  

• A System Architecture Design Strategies instructor-led course that covers GIS infrastructure architecture alternatives and system architecture design strategies that support successful enterprise operations.

• A Building a GIS: System Architecture Design Strategies for Managers publication from Esri press, which includes a downloadable Capacity Planning Tool (CPT) and associated help videos that help you determine hardware and software needs by entering anticipated usage numbers for your implementation. The CPT is updated frequently to account for new hardware specifications.

  

• An Enterprise GIS Implementation Gallery featuring performance benchmarks on various enterprise GIS implementation scenarios. Refer to this guide for understanding and applying these benchmarks.

If you would like additional information or assistance in planning your enterprise GIS needs, please contact us.

• Virtualization / Cloud Computing


• Security


• Enterprise Integration


• Performance & Scalability


• EA Methodologies


• Application Development Patterns


• Enterprise Workflows – New for 2011


• Mobile – New for 2011

Been a while since we posted anything on updates to the templates, but that’s because we’ve been busy doing some updates.  A lot of good things are in the works.  We’ve heard from many users that migrated their production environment over to ArcGIS 10 in the last few months and as part of that migration are deploying the templates.  So their organizations are building new workflows and modifying old ones to take advantage of the templates.  We’ve gotten some very useful feedback from these users and the below are some of the results of that feedback.

New fields in the Dynamic Value Table

GENERATE_ID Table – You all have asked and we listened.  We are restructuring the Generate ID table to have two columns, Sequence Name and Sequence Value.  Each row will represent a sequence value. 

RUNORDER – This will allow to you specify the order the rules are processed.  The previous extension processed the rules in the order of the fields.  This caused issue when trying to chain together steps.  The runorder is more of a hierarchy, so numbers can be repeated.

ON_MANUAL – Users have asked for a way to only run certain rules when I click a button.  The on_change button is great, but does not allow for only manual rules.  There will be a button to fire on_manual rules.

Modified Rules – We have updated a few rules, below are the changes.

X_COORDINATE

Y_COORDINATE

LAT

LONG

These rules now have a value method that for lines you can choose to get the centroid, start or end coordinate.

C – Extract the coordinate value from the centroid

S – Extract the coordinate value from the Start

E – Extract the coordinate value from the End

JUNCTION_ROTATION – New option to list the diameter field.                              

New Rules –  To many details to mention, but we will have detail info in the doc.

MINIMUM_LENGTH

NEAREST_FEATURE_ATTRIBUTES

SPLIT_INTERSECTING_FEATURE

MULTI_FIELD_INTERSECT

INTERSECT_STATS

FEATURE_STATS

TO_EDGE_MULTI_FIELD_INTERSECT

FROM_EDGE_MULTI_FIELD_INTERSECT

TO_EDGE_STATS

FROM_EDGE_STATS

New Trace

We are working on redoing the trace to allow it to be exposed to web applications better, as part of this, we are adding a secondary isolation trace function.  This will temporary set all valves as inoperable, run the trace from the trace point and return the results.

Operational Viewer

We are anxiously awaiting the release of the Flex 2.3 viewer.  We this release, we will update the Operational dashboard to run on this release.

Citizen Engagement

Ne new version of the applications allow your customer to submit a service request as well as share information with them.  Coming Soon.

 

 

Update – You can find all beta releases on the Forum – http://forums.arcgis.com/threads/20000-Beta-Versions

Across the industry water utilities are expanding their GIS quality control procedures or implementing formalized quality control if they don’t have any in place.  Water utilities are also reviewing their existing GIS implementation and workflows for ways to increase quality assurance.  At some water utilities these changes are coming out the GIS department, driven by proactive GIS managers and staff.  At other utilities these changes are coming top down from utility management that recognize GIS data now runs throughout their utility like a steel thread or from the IT department as it assess the state of all utility digital data.

But haven’t we always been concerned about data quality?

Absolutely, as GIS professionals we are perpetually concerned about the quality of our data.  As GIS technology evolves, the way water utilities use GIS to support their needs changes and more people and applications rely on GIS.  This increases the pressure to be sure your data is right or at least you truly know the limitations of your data.  First, let’s take some time to understand how these changes drive the need for a better understanding of data quality at water utilities.

GIS Technology has evolved, making GIS easier to ubiquitously deploy across all departments at a utility, so GIS is driving broader and deeper into water utilities.  Now a single source of GIS data can be made available across the entire utility, including the office and the field and that single data source is accessed through a variety of applications that are tailored to the role of end-users or groups of end-users.  

Utility wide GIS access means that more people are interacting with your data.  From a data quality perspective this is good because it socializes your data.  Utility staff that have specialized expertise or firsthand knowledge of certain parts of your utility networks help you make your data better by pointing out issues. 

Of course utility wide access to GIS can turn ugly if you are sharing bad data or more appropriately don’t know how good your data is and haven’t clearly communicated the quality of your data (scale, currency, etc) to users.  2 of the big reasons why staff abandon using GIS applications (really any application) at a water utility is unexpectedly bad data and/or poor application design and interface.  We have seen utilities very successfully engage the entire utility staff in cleaning up bad data by clearly communicating that the current data isn’t up to par, than making it easy for staff to point out where data edits need to happen and having a workflow in place to swiftly make the edits. The same principles apply to ongoing data updates through redline submissions.

Utility wide GIS access also means that other enterprise business systems at water utilities are integrating with GIS and are reliant on GIS to be spatially enabled.  It’s typical of new workorder (asset management, CMMS, etc), customer information, LIMS, financial, billing, etc system implementations at water utilities to have GIS integration.  We’ve heard from a lot of GIS managers that as GIS is recognized as an equal participant in their utility’s enterprise, the bar is raised for both the quality and currency of their data.

The way water utilities use GIS is also driving the increased focus on quality assurance and quality control.  Years ago, utility staff were primarily exposed to GIS data through paper maps.  So as long as things looked good at the scale of the printed map, then everyone was happy with the quality of the data.  Also, utility staff were much more accepting of data currency issues with paper maps.

Now most water utility staff are exposed to GIS through web based and mobile GIS applications, which means they are free to interact with the data at different map scales and explore attributes.  So more people are drilling into data for detailed information and examining it closely. 

While GIS has been used historically at water utilities to perform spatial analysis for reporting purposes the amount and types of data being analyzed with GIS for reporting purposes is on the rise.  For example it’s now typical for water utilities to use GIS to report on many things like impervious surface calculation for stormwater billing, reporting to regulatory bodies about number and types of assets, as a tool to support asset valuation, and also for real-time or periodic generation of key performance indicators for utility management.  So increased usage of GIS for reporting, especially reporting related to regulatory approvals, customer billing and KPIs drives the need for better data.

So what can you do about it?

Let’s examine some of the ways you can increase GIS quality assurance and quality control. If you are unfamiliar with the differences between quality assurance and quality control, in a nutshell quality control is about testing to uncover data defects and quality assurance is about trying to avoid issues that lead to data defects.  So QA is focused on preventing future errors and QC is focused on identifying existing errors.

Quality Assurance

Here are some steps water utility GIS users are taking to ensure the quality of their data.

Use a geodatabase

We cannot stress how absolutely critical it is to store your water utility GIS data in a geodatabase. Shapefiles and coverages have their roles (mostly for data export and interchange now), they are not the appropriate GIS data repository for the needs of a water, wastewater or stormwater utility.

The geodatabase is a data storage structure for ArcGIS that enables water utilities to encapsulate your data as well as business rules.  What does this mean in plain language?  You put both your data and the rules about how your data is structured in one place.  Some of the rules that are in the geodatabase constrain users from making editing mistakes (such as not allowing improper attribute values) and some of the rules ensure that the connectivity and relationship between connected features is maintained.

Have a properly configured datamodel

A datamodel or schema is how you represent real world features in your geodatabase.  So the geodatabase is the storage structure and the schema configures the structure for your exact needs.  A properly configured datamodel minimizes the possibility of representing features in your GIS in a way they could not exist in the real world.   In other words you are preventing the creation of invalid data with a sound datamodel.  While it’s impossible to design a datamodel that prevents all editing errors, you can go a long way toward minimizing potential errors by doing a proper data modeling effort (or engage a consultant to assist you in this effort).  Of course you should always start with Esri’s water, wastewater or stormwater datamodels as we’ve already done much of the initial data modeling work for you, saving you time and money and utilizing industry best practices.  A properly configured data model utilizes domains, especially coded value domains where appropriate.  If your current datamodel no longer reflects the needs of your utility, you absolutely need to update your datamodel.

Use the Geometric Network for your utility network data sets

The geometric network is configurable specialized behavior in the geodatabase that mimics how individual real world things behave as a connected network – like how the individual assets of a water, sewer or stormwater network function together to move water or sewage.  The geometric network was designed for utilities and as a utility you should be using it.

More information on geometric networks here – http://blogs.esri.com/Dev/blogs/waterutilities/archive/2009/11/17/Geometric-networks-for-water-utilities.aspx

Take advantage of versioning

If you have multiple people editing data at your water utility, you should be using a versioned geodatabase.  Versioning will enable you to catch and resolve potential data issues like conflicting edits and perform quality control on recently edited data before all of the GIS users and integrated systems see the edits.  It will also give you an audit trail of edits.  If you aren’t familiar with versioning, it may seem daunting to start using it, but you find it to be a very beneficial tool to safeguard your data and well worth the time investment in learning how to properly utilize it.

http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/A_quick_tour_of_versioning/00270000000r000000

Formalize your workflows

The way to ensure you get the same result from multiple people performing the same task is to formalize workflows.  So, if you have multiple people editing GIS data at your utility than formalize those workflows to reduce the possibility of inconsistent individual processes yielding inconsistent data.  Formalization of workflows could be as simple as clearly written and documented standard operating procedures, could utilize ArcGIS Workflow Manager or customized tools.  

Utilize geoprocessing models and scripts

Remember, geoprocessing models aren’t just for analysis.  You can also turn data manipulation and some editing tasks easily into repeatable geoprocessing models.  So geoprocessing models are a way to formalize your workflows.

Quality Control

Remember, quality control is focused on identify and resolving existing errors.  So the key to quality control is to periodically check your data for errors.  Data checks can range from running queries (spatial, attribute or both), to random samples to visual exploration of data.  Data checks can be (and should be) formalized workflows that are automated where possible.  Examples of quality control automation include utilizing geoprocessing models or scripts, customized tools and the ArcGIS Data Reviewer extension.

The ArcGIS Data Review Blog is a great resource to learn more about GIS data quality control – http://blogs.esri.com/dev/blogs/datareviewer/Default.aspx

As always, if you’d like to share your experience with GIS data quality assurance or quality control please feel free to comment on this blog.

I’d like to start off by thanking each one of you who attended the Enterprise Architecture SIG at this year’s Esri User Conference and hope that you found the session valuable.  Many people approached us and commented on how they liked the new format.  Additionally, I believe everyone was happy with the full breakfast that was provided by IBM, as it got everyone energized for the day.  Thanks again to IBM for their sponsorship of the SIG.

• How to effectively collect user requirements in support of application development.


• Challenges in gaining acceptance and participation in the design for workflow centric applications.


• While UI prototypes risk influencing functional requirements, they were found beneficial overall in helping build better application requirements.


• Iterative approaches (waterfall, spiral, agile, etc) to application design were favored for many reasons and both economic (results can be demonstrated in a shorter period of time, securing funding), and regulatory (some organizations require 120 day milestone intervals).


• Adapting a design focused around specific workflows and business processes as opposed to a design that merely provides general tools.


•  Challenges in shifting from the “ArcIMS Kitchen Sink” style apps to workflow focused ArcGIS Server apps.

• Common definition for cloud computing –the simple “computing on demand” prevailed.


• Concerns/issues with SLAs (Service Level Agreements), costs and the economies of scale, security and privacy.


• Implementation approaches of private, public and hybrid cloud computing.




• Expect a brief whitepaper addressing geospatial cloud computing security over the next several months.

• Value of SOAP vs. REST and acknowledgement that most new, single organization projects are using a REST-based approach as opposed to SOAP-based approach.


• GIS community is just starting to realize the importance of OGC WFS-T for web editing. 


• Users were glad to see the new changes to ArcCatalog at version 10 for metadata.

• Numerous issues and challenges include:  data quality, data model determination and use, de-normalizing indexes to match workflow/transactions and data warehousing.


• Advanced planning (specifically around architecture) and education were keys to success.


• Organizations exchanged information about current relevant architectural guidance materials.

• Suggestions made for “How do you share data (securely) with the field?”


• Suggestions made for “How can you be secure while still being productive?”


• Esri was asked to provide list of security applications that their software was compatible with to assist in the execution of security certification process.




• We need additional input from users about how this would look.  A list of security products used successfully by other customers, but not guaranteeing compatibility?


• Esri was asked to provide deployment plans with attention paid to security issues / concerns / suggestions.




• We hope to expand on our security patterns with additional deployment guidance along with security and performance validation.

Performance 

• Large size implementations discussed how to best address uptime requirements




• We hope to add a Deployment patterns area to the ERC over the next several months that addresses availability requirements and scaling components.


• Moderate size implementations disussed lower-level details, such as “How does SQL Server work most efficiently with ArcGIS Server”


• How to properly scale servers when upgrading from ArcIMS to ArcGIS Server?  With the release of optimized map services based on the new .msd format, performance differences were not observed as frequently.


• How to best account for performance decreases when utilizing virtual machines?

• Should I run my Esri technology in a virtualized environment or not?


• A great case study was provided by one user, who discussed in detail their successes with running Esri technologies in virtualized environments.


• Choosing the right virtualized environment depends heavily on the organization’s broader IT strategy, perceived benefits, and the features included in the virtualization solutions.


• Business continuity, rapid application development, and simplified server provisioning are more important advantages of virtualization than performance.


• Esri supports and uses virtualization technologies for the development, quality assurance, and certification processes for many of its products.

We’ve added a cloud computing security section to the Enterprise Security presentation scheduled for Tuesday at 3:15pm in Room 32B.  The session will still cover security across the enterprise, but has been expanded to address this key subject. Please provide feedback on the presentation as it will be incorporated into a cloud security whitepaper we plan on releasing later this year!  Some cloud computing items to be addressed include:
  -  Understanding the security benefits and risks
  -  Secure deployment best practices
  -  Minimizing your cloud attack surface
  -  Single-sign-on integration
  -  ESRI product specific guidance and resources

See you there!

We are very excited about forming a stronger Enterprise User Community through the Enterprise Architecture Special Interest Group (SIG) at this year’s ESRI International User Conference.  In an effort to enhance effective communication of information and collaboration around topics of interest, we are changing the format of the SIG.  The first thing you will notice is that we have arranged tables in a “Birds of a Feather” format to facilitate communication amongst ArcGIS users, business partners and ESRI employees around key Enterprise topics such as:

  -  Virtualization
  -  Cloud Computing
  -  Security
  -  Enterprise Integration
  -  Performance & Scalability
  -  EA Methodologies
  -  Application Development Patterns
  –  Standards

As you enter the room, please seat yourself at a table whose topic interests you the most.  Once everyone is seated, we will kick things off with a set of “lightening talks” focused on key items relevant to enterprise-thinking customers such as new resources, technology deployment options, and key technology changes.  At the conclusion of the “lightening talks”, we will then open the floor to all of you, to discuss amongst yourselves at your respective tables, the following based upon your table’s topic (e.g. Virtualization, Cloud Computing, etc.):

  –  Lessons learned
  -  Areas ESRI may be able to provide additional guidance
  -  Biggest roadblocks/issues
  -  Where people are at in deployment/usage (Learning, implementing, fully integrated)

Table discussions will then be brought to close and Fred Collins from IBM will present information on Geospatial Cloud Computing.  After Fred’s presentation, key points from the table topic discussions will be shared with the room leading to additional discussions on the Enterprise Resource Center (ERC) and inviting feedback.  This is an exciting opportunity for all of us to learn from each other!

Last year’s breakfast SIG was a great success so the SIG will be bright and early again with the addition of a full breakfast including eggs, bacon, hash browns and much more – Yum!  Thanks again to IBM for sponsorship of this SIG.

Who
　Open to all UC Attendees

Date/Time
　Wed, Jul 14, 7:30AM – 8:15AM

Location (Same as last year)
　Room 16A

EA SIG coordinators (Feel free to contact us with questions/suggestions)
　Andrew Hendrickson – Solution Architect – AHendrickson@esri.com  
　Dave Wrazien – Solution Architect – DWrazien@esri.com  　　　　　　　　　　　　
　Michael Young – Sr. Enterprise Security Architect – MYoung@esri.com  

Breaking down silos of information

If you think about it, for years utilities have had pieces of information about their assets in multiple places.  For example paper as-builts (or perhaps even linens or mylars) describing what was constructed (or should have been constructed), maybe old project records with financial information that describe what it cost to put assets into operation, in other places paper work orders that described the level of effort to keep assets functioning.  You could rightfully call these silos of information – they all may be describing the same asset, with different primary pieces of information (and most likely some overlapping and contradictory information) and perhaps at different times in an asset’s life-cycle.  There was no interconnection between these information sources and often no senses of which was one was more correct or authoritative.

We’ve now moved into an era where most utilities have taken advantage of information technology (in some form) to store and maintain their information.  Instead of manual drafted paper maps utilities use GIS, instead of handwritten ledgers to track payments utilities use billing systems, etc.  Common IT systems used at water utilities are billing, financial, workorder (CMMS), GIS, SCADA, CIS, LIMS, etc.

Utilities still have pieces of information about their assets in multiple systems, but now they are computerized systems.  This means it’s still possible to have different descriptive information about an assets, costs associated with an asset, performance of an asset (perhaps describe by SCADA data or indicated by customer complaints) in multiple systems and that data may conflict.  So it continues to be a struggle for many utilities that still have to go to multiple systems to get a complete understand of their assets and it may also be a struggle to know what is authoritative information when data in multiple systems conflict. 

Some utilities are overcoming these challenges by specifying how their enterprise IT systems must work together.  This often takes the form of identifying where data is at a utility, how it’s maintained and then determining how systems should integrate with each other to share information and what systems are the “system of record” meaning they own the data.  It’s important to note that you may have multiple systems working together (properly integrated) that form your system of record.  So the “system of record” determination may happen on a field by field basis.

Enterprise Asset Management

The interesting thing about enterprise asset management is that it’s both a concept and now the name of a class of software commonly used at utilities and facilities.  A few years ago a trend started in the utility and facility industry where vendors of workorder and CMMS (computerized maintenance management systems) began to refer to themselves as “Enterprise Asset Management Systems”, reflecting that the systems that create workorders and manage maintenance tasks (both planned and unplanned) rightfully should participate in the enterprise IT environment.  But this has also added to a lot of confusion about how assets are really stored and managed in the enterprise IT environment at most utilities.  While now called EAM systems, workorders and maintenance tasks are only part of what a utility needs to truly manage their assets.

From our experience with large water and sewer utilizes, enterprise asset management is something that is only achievable with multiple systems at a utility that are properly integrated.  After speaking with many utilities big and small, it seems like what utilities want for enterprise asset management is the use of integrated information from multiple systems to enable a utility to best manage their assets.  It’s the best data from each system to describe what an asset is, how it affects others related things (customers, service levels, other assets in your network), what its condition is, maintenance history, cost to build, cost to maintain, criticality, etc.  That data should be maintained in a way that it’s created or maintained one time and then stored in the appropriate system in a way that’s transparent to users.  So enterprise asset management as a concept is really the ability to access and use the right pieces of information (and that information needs to be descriptively and temporally accurate and authoritative) from enterprise IT systems at a water utility.

GIS, Enterprise Asset Management and EAM Systems

So how does GIS play a role in enterprise asset management?  Spatial location is typically the one common aspect among all of the data at a water utility.  We can understand the relationship between customers and distribution or collection system assets by their spatial location and interconnection.   A map is often the easiest way for humans to aggregate many sources of data together to visualize them all and understand how they affect each other.   When we spatially enable our utility data we can then use the analytical power of GIS to gain a better understanding of how our assets are performing and how they affect our level of service and our customers.  From years of working with utilities, we’ve seen GIS consistently be the gateway where large amounts of asset data enter a utility and where its basic characteristics (location, size, installation date, material, etc) is maintained.  So maps from GIS are the place to visualize, analyze and explore many pieces of asset related data and also enable you to propose ways to manage your assets better (maintenance, rehabilitation or replacement) and understand the impact.

Interestingly, when you look at how modern EAM systems (workorder & CMMS) are implemented at water utilities, they almost always have a GIS integration component that includes a toolbar in desktop GIS to keep assets in sync between the GIS and the EAM and also uses server based GIS to give a spatial view of assets and workorders to utility staff that are dispatching and managing workorders.  So the way EAM systems are integrated with GIS underscores the concept that enterprise asset management is about utilizing the best information from each system that stores data about assets.

Want to share your experience or thoughts on this?  Feel free to post a comment.