<div style="display:inline;"> <img height="1" width="1" style="border-style:none;" alt="" src="//googleads.g.doubleclick.net/pagead/viewthroughconversion/1066880148/?value=0&amp;label=4oTQCMyJzwQQlJnd_AM&amp;guid=ON&amp;script=0">
Reginald Oake

By: Reginald Oake on January 10th, 2023

Print/Save as PDF

How do I Know My Integrations are Working?

 So, you’ve just finished implementing a series of integrations so Maximo can play its part in a set of enterprise-wide business processes. Work orders, assets, POs, GL accounts, labor and inventory transactions, and so forth are flowing back and forth with few, if any, errors when the following conversation occurs…. 

Client: So, how are my integrations working? 

You: Messages are flying back and forth like nobody’s business and there are no errors to speak of so, pretty well, I think. 

Client: Okay, but how do I know that all of the information that is supposed to be getting into Maximo actually makes it to the right spots in Maximo and how do I know that all of the information that should be coming out of Maximo makes it to the right spots in other systems? 

Put another way, how can we know if integrations are working correctly and reliably? 

Why Should I Care? 

Outside of just being able to answer the client’s question, integrations support important business processes from ordering needed parts and getting important work done to getting people paid for the work they are doing. We definitely want to be able to demonstrate that an interface that tells the payroll system how big a paycheck someone gets is pretty much flawless. 

A Good Start 

A lack of errors is a good start. Better still is having good error handling practices (notifications, remediation, and rationalization) but that’s a topic for a different article. 

Just as important, and often overlooked or just assumed, is establishing that each system has the right records, records that match the state of the system-of-record, and records that can be progressed through the business process. 

In a word (or two), to demonstrate that integrations are correct and reliable there needs to be a reconciliation process between the system-of-record and other integrated systems for each integration point. 

Reconciling Integration Records 

A reconciliation process is meant either to demonstrate that integrations are correct and reliable or to expose flaws in the integrations. Reconciliation should be part of testing during development and parts of the reconciliation process can be continued as regular checks to demonstrate that the integrations continue to function correctly. 

Reconciliation should cover three criteria (having all and only the right records, having correct information in the correct places, and having records that work correctly throughout their lifecycle). 

System and user testing should cover all three criteria while, in production, testing the functionality of integrated records is typically dropped as this can more easily be demonstrated by the presence or absence of integration related support requests. 

The other two criteria should be easy to demonstrate and should be demonstrated on a regular basis. 

A final note here. Reconciliation is meant to establish confidence that the integrations are working correctly, not to verify every single record (mainly because verifying every record would be onerous and costly and would probably be the first thing skipped when people are busy). 

Making Sure a System has the Right Records 

Since these records are in the database, a query (better yet, a report) should be able to reveal information about the records that are shared between systems. For a start, querying records from a particular integration in different systems can give a raw count of integrated records for each system. If these raw counts match, you have an initial indication of correctness. 

To strengthen confidence, you can add breakdown counts for domain-controlled fields and totals of other fields. The more different counts and totals match the higher the level of confidence. 

Thinking of POs, for example, if you compare systems monthly and total counts match, breakdowns by status and vendor match and total costs match month after month, it is extremely unlikely (very extremely unlikely) that you have missing or extra records. 

For example, if the system of record says that Maximo should have 872 POs in a given month and Maximo has 872 POs, we could guess that we have a 90% confidence level that we have the right records. If a breakdown by status matches, we could guess at another 90% confidence. If total cost also matches, we could have another 90%. 

Just these three factors give us a 99.9% probability that we have the right records. If we get this same match monthly for a year, we go up to 99.99%. 

Making Sure the Information on a Record is Correct 

You could also, along with the counts, include a random-ish set of integrated records along with key fields for each record. Such a report could be run in the system of record and another system with the results compared for discrepancies. If the reports are set up correctly, the comparison could be as simple as using a text compare utility. 

The Reconciliation Report 

For both criteria above (having the right records with the correct information), the report run in the system-of-record establishes the standard of correctness for the other system.  

If the two reports are created so that matching data is identical (e.g., Maximo statuses are converted to appropriate values for the other system in the report) and the reports are sorted using the same criteria, differences should be easy to detect. 

An alternate type of report (more sophisticated but also easier to interpret) would be to create a report that has access to both systems being compared. Such a report could have the aggregate numbers (the counts and totals mentioned earlier) and could be set up to only display records that don’t match (either missing, extra or having different information) between the two systems. 

Finally, What’s the Point? 

Simply put, this gives us the ability to demonstrate to the business, with a high degree of confidence, that integrations are doing what we want them to do or demonstrate flaws in the integrations that can be investigated and remediated. 

About Reginald Oake

Reg Oake is a senior Maximo technical consultant with over 30 years of experience in software development and system support with Maximo being his main focus since 2007. Reg has worked with Interloc Solutions since 2013 for clients in aviation, health care, utilities, manufacturing and so on. At Interloc Solutions, Reg works as a technical lead with teams of up to 10 developers and likes to focus on delivering stable, scalable, high-value solutions to the clients he works with.