You need:

  • A unique value that will not change on the source system.
  • The ability to create and/or update GIS data via a REST call.

Be aware of:

  • Database indexing/health is critical to GIS performance.
  • Versioning is supported but an automated process is recommended.

The unique value is what allows you to establish a link between both systems. If you’re a database person, this is specifically a primary/foreign key relationship where the unique value represents our primary key. The ability to update GIS via a REST call is important, both when GIS is the source system and when it’s not. When GIS is the source system driving the creation of MBOs, Maximo needs to be able to mark records in GIS as processed, then return any data such as the newly created Location or Asset numbers. When Maximo is the source system driving the creation of features in GIS, we need the ability to create the necessary records in GIS. So how do we figure out the system that owns the source data? Finding the approach your organization needs lies in your current or future business processes. Don’t worry – we’re going to share scenarios when GIS and Maximo drive the creation of records and expand on GIS database health and versioning as well.

We run into a lot of organizations that use GIS as their design tool and this can be a key indicator for what records start with GIS as the source system. Often times these records are Assets, Locations or Service Address in Maximo. Activity based features, like Work Orders and Service Requests, tend to start with the Maximo system. In the case of activity-based features, it makes sense to keep users in the current system and allow the creation of GIS features from Maximo.

Database indexing and overall health is very important to a GIS system in general, and especially important when you’re integrating your GIS system. Tasks like rebuilding indexes and statistics can greatly affect your overall system performance. (Look for a future blog that covers suggestions for your database platform’s best practices.)  Starboard does advise you to invest time in understanding your system’s vendor-recommended best practices for database health or find a resource with expertise in your platform.

Finally, most organizations have some form of versioning in place and want to know if Maximo Spatial will support versioning. The answer is yes, Maximo Spatial does support versioning, but we do recommend that some form of automated practice be put in place to manage your geodatabase versioning. The logic behind automating your versioning process is two-fold. First, versioning does add to database management overhead but a geodatabase with a well-managed versioning process will make little if any impact to system performance. The second reason is that most versioning strategies do not intend for Maximo to update the default version and instead use a version dedicated to Maximo. A dedicated Maximo version is a sound approach but without reconciling and posting your Maximo edits, GIS users may never see the fruits of your GIS integration.

When it comes to Maximo Spatial 7.6, there are two things you need and two things you should be aware of. For Maximo Spatial 7.6 you need a unique value that will not change on the source system and the ability to create and/or update GIS data via a REST call. You should also be aware that database indexing/health is critical to GIS performance and versioning is supported but an automated process is recommended. Stay tuned for our next post where we will discuss some tips and tricks around Maximo Spatial 7.6.

Contact at Starboard Consulting to maximize your asset management technology.

Written by: The Starboard Consulting Team