Over the last few years we’ve seen a number of utilities implementing IBM Maximo for Enterprise Asset Management (EAM). IBM has been pitching Maximo Spatial for years with the ability to integrate the Maximo Location and Asset functionality directly to and Esri geodatabase. Many of these utilities have asked about SSP’s opinion and experience with Maximo Integration and/or Maximo Spatial which makes it a worthy topic for a quick blog post.
SSP worked extensively with an Esri/ArcFM™ GIS integration to Maximo between the years of 2007 and 2011. Our participation was twofold.
First, SSP won the contract to convert much of the asset data that had previously been managed only in the GIS into Maximo locations, assets, classifications, and work order history. This effort was completed at the database level with scripting and some custom GIS extraction applications.
For those of you not familiar with Maximo data structures, the model is based on a hierarchy of locations which can serve as collection points for asset records. The simple example I often give from our implementation looks something like this:
In the picture above, the green boxes are Maximo Location records and the pink box is a Maximo Asset record. The location hierarchy can be as simple or complex as you want.
The asset records can also get more complex when you start talking about parent and child assets. A quick example of this would be modeling a pole assembly asset record as a child asset of the pole record.
You can also have multiple assets assigned to the same location. For example you might have a pole, transformer, and multiple down guys all assigned to the same pole structure location.
Our challenge was to map all of the GIS records into the above hierarchy and then to populate the Maximo Oracle tables as required. In some cases a single GIS record like a pole would map to both a pole structure location AND a pole asset record.
As we migrated the data into Maximo, the Maximo system would assign several Maximo-specific ids to the records for both the locations and assets. We then took a reverse data load from Maximo with these ids and assigned them back onto the GIS records. This provided an attribute-level link between the GIS records and the Maximo records.
The savvy reader will now note that if a GIS pole was mapped to both a Maximo location and an asset record then we’d have two sets of Maximo IDs to track in GIS. And this is absolutely correct. Our GIS pole record ended up tracking a MXEAssetID/Number and a MXELocationID/Number to provide the two independent links.
Maximo has a fairly generic data model where they track a consistent set of fields for ALL locations and ALL assets, whether it’s a pole, a pad, or even a gas valve. These include common “header” values such as the asset number, the asset type, the install date, etc.
Then any “type”-specific attribution is modeled into the Maximo classification. The classification is a dynamic model that allows you to set up attribution for each asset type. For example, a pole would track class, height, and material, whereas a transformer would track rated KVA, serial number, and gallons of oil.
This is indeed a very flexible data model because you end up with one big table for all the classification attributes for all of the different asset types. The only issue we encountered is that because it uses one big table, it can get very slow. Tuning the Maximo Oracle database is absolutely critical!
The following screenshot shows the generic classification (specification) table columns. The AssetAttrId contains the id of the attribute for each “type” of asset whereas either the NumValue or ALNValue columns will contain the actual values for the attributes:
Once we got the GIS data converted over into Maximo and established the initial linkage between the two systems using the ID fields, we had to support the real-time integration between GIS and Maximo going forward. The real-time integration would be based on the linked attributes as mentioned above.
On the GIS side, the customer’s desire was to only pass data to Maximo when the GIS data was posted to SDE.Default (not just edited within a version). This pattern would prevent those ArcFM™ Sessions that were created, edited, and deleted without posting from prematurely synchronizing to Maximo.
To accomplish this, ArcFM™ AutoUpdaters were created and applied to all of the GIS classes that would write any creates, updates, or deletes to a designated Esri MaximoAssetTracking table. This tracking table was versioned so that the Maximo-related edits were tracked alongside the version. No data was sent to Maximo when the edits were applied in GIS.
When the Esri version was eventually approved and posted, a custom Process Framework (Session Manager) Subtask fired that collected the records from the MaximoAssetTracking table and pushed those records to Maximo via a web service and a queuing service. The integration pushed the asset type, the GISID, and any required attribute data for the Maximo header record AND the Maximo classification record.
Maximo would then respond with another message via a web service and queuing service that tied the GIS record to the new Maximo MXEAssetID and/or MXELocationID values as applicable. These values were then applied to the GIS record establishing the linkage between the systems. Correspondingly, a delete in GIS would retire the record in Maximo.
For ongoing attribute updates between the systems we had certain attributes that were owned by Maximo and other attributes that were owned by GIS. Whenever an update occurred in either system we would push that attribute to the other respective system via the integration web services and queuing services.
To manage which attributes were owned by each system, we created and utilized a Maximo Cross Reference table which tracked all of the attributes for each asset/location type along with the system ownership. The integration then used this table to send the attribute updates correctly.
With regard to Maximo Spatial, it was enabled in its most basic format where users could view the “map tab” for an asset or location within Maximo. This queried the GIS via ArcGIS Server to render the map display of the asset/location and its surrounding area.
Because the GIS data was ArcFM™ data, no editing was permitted directly via the Maximo Spatial product interface, although this is advertised by IBM as being part of the product.
This EAM-to-GIS integration was certainly complex, but it provided the customer with the workflows they needed to keep both systems in sync while performing related essential business activities in both GIS and Maximo.
It is also important to mention some of the other key players who worked on this project with us including Don Peaslee from Utility Data Contractors; Michael Bramwell, Michael Woodburn and Jim Saunders from IBM; and Ted Rakel from Schneider Electric.
This implementation has been in production for a couple of years now but the experience gained from integrating GIS to Maximo is definitely still applicable today. If you are a GIS dude (or dudette) who is new to the Maximo game I hope this provides some high level guidance.
If you have questions, feel free to give us a shout!
Prashant says:
Hi I also integrated maximo to ARC GIS and the approach adopted was all most similar to Yours. Yes You are correct GIS database is too completes for direct database updates using web services. The versioning and different layers for each Object also leads to different set of parameters and database schema for each table which is quite disimilar than maximo.
I wanted to know from you whether in your case asset creation was happening first in maximo or in GIS and How the data was syncing between these two apps.
Skye Perry says:
Hi Prashant – for most of the spatial assets we used the creation/posting event in GIS to trigger the asset/location creation in Maximo. Maximo would then send back the Maximo ids so they could be added to the GIS records. Both systems then owned specific attributes and the sync happened bidirectional. For example GIS might own the pole height and class attributes but Maximo would own the manufacturer.
However, we did have some assets that were created in Maximo first. These were mostly pre-capitalized/rotating assets like transformers, capacitors, and voltage regulators. These assets were capitalized at the time of purchase and not at the time of installation. Therefore they were entered into Maximo when they were purchased which created the Maximo record. Then later when they were installed (months or even years later), the asset record would be synched into GIS. In this case we basically maintained a lookup cache table in GIS of all the available Maximo assets so that GIS could easily build a relationship/link to the existing asset record.
Hope this helps! Thanks for your comment…
chandramouli says:
Hi friends, i am a GIS engineer, and i am new to MAXIMO..
please help me how to Integrate GIS data to MAXIMO.. or
If anyone have workflow ppt / pdf please mail me.
[email protected]
Thanks in advance
Ed Blair says:
My understanding these days is that IBM/Maximo offers an integration process that is run on a regular (i.e., nightly) basis to sync new and updated ArcGIS features with corresponding Maximo Asset records. If you were to implement an integration today would you still feel a need for things like the Asset Tracing Table and Web service messaging described in this post or would the IBM integration components accomplish the same thing?
Thx,
Ed
Skye Perry says:
My understanding is that it has gotten better but still doesn’t work out of the box or anything like that. It still needs to be implemented carefully with a fair bit of integration work to get it to work correctly in a bi-directional fashion.
Ingrid Tobar says:
Thanks for the post Skye, this is very helpful. Can anyone share insight on the timelines followed for your integration projects? I’m developing a timeline that broadly covers 4 major stages: 1. Requirements Gathering, 2. System of Record Determination, 3. Data Model Development, and 4. Implementation. I know the actual timeline depends on a number of factors, but it would be useful to know whether others have been able to reach an initial implementation stage in either days, weeks, or years… Thanks in advance.
SSP Innovations says:
Ingrid, that is indeed a tough question! Generally speaking a discovery & design phase for a large scale integration project might be in the range of 3 to 6 months depending on the complexity of the systems being integrated. The development phase inclusive of database, customization, and integration/interfaces can often be another 6-12 months. And then the deployment is usually 3 months after that. With all that said most of these big projects seem to take years as opposed to months based on other factors of a larger project (like the implementation of Maximo, GIS, or both). These external factors often complicate the integration timeline because they create a moving target which can cause constant change to the integration. Let us know how your project planning proceeds!
Adde says:
Hi friends, I am a MAXIMO engineer and new to Integration with GIS. We want to display the workorders, assets on map. Can someone please help me with how to proceed with it and how display of workorder on map works? Also help me with approach like to use web service or any other integration component. Thanks in advance
Skye Perry says:
Adde, this is certainly a more complicated question than I can answer in a paragraph but I’ll try to give some guidance. Based on this article you need to have a link built between GIS features and Maximo records first. If you don’t have that then nothing else will work. Then from the Maximo side there is a “map tab” within the Maximo application which can be configured via ArcGIS Server to show an interactive map where the asset is located. If work order polygons exist, it will also show the WO polygons on the map. This is a standard component of Maximo BUT does require installation and configuration of ArcGIS Server from Esri as well. ArcGIS Server uses geo-enabled web services to provide the mapping data back to Maximo.
Note that this is different than the integration I describe in this article which essentially establishes the link between Maximo and GIS. This is also handled via web services integration (SOA).
Skip Heise says:
There is a product called GeoWorx Sync from GeoNexus Technologies that removes the complexity of a custom integration. You will be up and running in minutes. Please check it out at http://www.geo-nexus.com
Skye Perry says:
Thanks Skip, we are definitely supporters of the GeoNexus out of the box integration for Maximo locations and assets and have worked with GeoNexus on several of our customer accounts. With that said, the GeoWorx Sync product wasn’t around back when this interface was originally implemented (2007) but has really come on strong since then!
Rich Dumont says:
I am currently, and have, implemented Maximo Spatial which offers a much offers an integration solution rather than the old days of batch Syncing. Maximo Spatial allows Maximo to use the GIS objects as MBOs (Maximo Business Objects). By using this method the GIS Feature Classes are queried in real time to obtain the attribute information. ESRI and IBM worked together on developing this product which allows a much tighter integration. At Maximo Spatial 7.6, which is due out soon, the use of Feature Services will be available which will make this integration even tighter and more seemless.
So if I was implementing a new GIS/Maximo project this would be the first item on my list to investigate.
With all that said, as with any implementation, it really depends on the and that should drive the best solution possible. To do that one must know of all the options available. This tool was built from a partnership of the two vendors involved, ESRI and Maximo and is still being Enhanced so even more functionality is coming.
Thanks
Skye Perry says:
Thanks for the comments Rich. We are also involved in more modern Maximo implementations using Maximo Spatial. The benefit is that it is a much tighter integration but it also involves having direct access to the GIS database from Maximo which defeats the intention of the SOA approach to integration which has significant impacts on upgrades because the systems are not truly decoupled.
I agree that the feature services implementation could be the solution to this issue if Maximo truly only interacts with the GIS data via the REST end points and is no longer hitting the database directly. This would then meet the SOA guidelines… we are looking forward to learning more about that release when it becomes available!
Thanks again for your comments… good stuff.