With Maximo, the Maximo Integration Framework (MIF) provides a very powerful and flexible integration tool, allowing any data held or used by Maximo to be interfaced using a variety of methods, from flat files to database tables and REST API calls. While this flexibility provides a number of integration options and methods, it is still important to plan your integration with third-party applications thoroughly. Below are BPD Zeniths 9 Recommendations For A Successful SAP & IBM Maximo EAM Interface – we highlight some of the key items to consider when developing interfaces. This is followed by common challenges, as well as risks and mitigations that often arise. It is also worth noting that this is based on our experience and is by no means an exhaustive list, however, does contain the items we come across most regularly and how best to resolve them.
Often referred to as KISS (Keep it Simple, Stupid), this principle is key when designing interfaces, especially when developing interfaces between complex systems. It is very easy to start defining a highly complex interface process with data expecting to flow constantly between systems. Bear in mind that complex interfaces typically require more effort to support on an ongoing basis and mean future developments around the interface require more thought.
While not always possible, defining a ‘Master of Data’ for each data set enables clear segregation of data and processes. Maintaining data in a single system, with other systems receiving a copy of this data (or a subset of the data if not all is required) is usually easier to maintain than trying to maintain data in two or more different systems.
In addition, it is also worth making the master depending on where data will be used most. For example, having company/vendor data is most used in procurement, therefore having the Company Master of Data in the same system as your Procurement (Purchase Requisitions, Purchase Orders etc.) is a good starting point to review.
While there can be a tendency to consider interfacing all data shared between systems, it is always worth taking a step back and considering what the benefits are of developing an interface for each specific data object or element. The benefits are often linked to the frequency in which the data is changed or updated. For example, both ERP and EAM/CMMS solutions may reference data such as currency codes, units of measure etc. However, how often is a new currency released, let alone the new currencies used? Same with Units of Measure. Rather than spend time and effort developing and supporting an interface that has little traffic, it may be easier to load the data to align them initially, then define a semi-automated or manual process to ensure they are maintained.
Once you’ve reviewed what data needs to be interfaced, the next stage is to think about how often data needs to be interfaced, and at what time in the day. Real-time or frequent interfaces provide data instantly (or within a few minutes), however, if you have all of your interfaces running in real-time and have a high number of records and processes needed as part of the interfaces, you can start to increase the load on your environment. Often (like with Maximo), interfaces are processed separately from the user interface, however, there are common elements such as the database which, if overworked, has an effect on all users and processes.
Consider which interfaces can run less frequently, data required for visibility or that changes less frequently are often interfaces that may be considered. However, depending on the data, it is also worth having a way to override and run the interface sooner if needed. Previously I’ve seen Vendor master data being interfaced daily on an evening due to the infrequency in which the data changes. However, when an urgent record is required for a new Vendor which has to be raised on the same day as the vendor, a daily interface quickly becomes a problem. As these examples are usually infrequent, having a manual override is usually a better option than increasing the standard interface frequency.
When interfacing data with less frequency, it is also worth considering exactly when the interface runs. Often these are running at night when the systems are used less by end-users. This means that more system resources are available and fewer users are affected by any common elements being over-worked.
When looking at the individual fields that are being interfaced, it is key to ensure that the data type and size for each field are aligned. Having the master data description field hold 150 characters and the secondary hold 120 may be sufficient to work most of the time and potentially get through basic testing, however, it will fail once live. Due to this, it is always worth checking the field type, validation performed on the data, and the length for each field during the design and build.
Once live, it is also worth keeping an up-to-date document in place which highlights what fields are interfaced where and what the agreed field size, type and validation is. This then provides a reference point when changes are made in future, which also needs to be considered to ensure data continues to flow correctly between systems. It is very easy to make a change to a system and interfaced systems are not considered. While some changes can be made without additional changes, frequently these changes can cause sporadic issues (as some validation still passes, while others fail) or even a complete failure of the interface.
Through testing of any change is critical to identifying and resolving issues prior to moving the change into a Production environment. This is equally true for interfacing. When designing test cases, it is often a good idea to spend additional time testing boundaries (data that is on the limit of what is allowed), negative testing (aiming to break the interface using available functionality) and testing each type or route the record can take. While this takes additional time to complete, resolving any issues found is significantly easier to complete before the interface is deployed into your Production environment. Not just in terms of effort, but also user experience and attitude towards the system.
As mentioned in Point 5 above, it is always worth keeping up to date and accurate documentation on your interface points as a reference point, which is used when designing future developments and changes. Ideally, it is worth keeping this documentation clear, concise, known to all related developers and easy to review and reference. This will help ensure that the documentation is reviewed and utilised.
It is also worth ensuring that the updating of this documentation is added to the close-out steps of the work process. While good documentation is important to ensure systems and processes remain aligned after changes are made, out of date or inaccurate documentation can cause significant additional effort and work while both developing, testing and fault finding. Not to mention how frustrating it is as a developer! Having clear concise documentation and ensuring it is maintained as part of the work process helps ensure the documentation is up to date and aligned with actual interfaces at all times.
When interfaces are being built, there are usually multiple parties involved, this includes third party and client technical specialists for each interfacing system, third party and client consultants/Business Analysts for each interfacing system, Business Subject Matter Experts for the specific data objects, Project Managers, stakeholders etc. As with any development/project work, ensuring there is an open honest atmosphere at all times is key to the work being completed successfully. As with any project, interface work can sometimes go different to what was initially planned, items don’t work as expected, expectations aren’t as aligned as thought… the list goes on. What is key is to ensure that there is an open atmosphere where issues can be raised, discussed and acted upon in an appropriate way, by working together as a single team, issues are resolved quickly and the chance of overall success is increased. Due to the number of different parties involved, this is even more critical with interface work.
Once the interface is live, there is often a tendency to focus on resolving the individual record, rather than the underlying cause. This is especially true just after the interface has gone into Production and there are a high number of issues being raised. While resolving the individual issue ensures that the specific record in question is processed and work can continue, it does not stop the issue from occurring again and again.
Instead, it is key for analysis to be performed on the issues raised. Reviewing not only the object where the issue is occurring but also why the record failed. By understanding and resolving the underlying issue, you can help ensure that the same issue does not occur again in the future.
When resolving underlying issues for one data object/attribute, it can also be worth checking if the same issue is applicable to other similar data objects. This can help resolve unresolved issues faster and make the most of the time spent analysing the initial underlying issue.
It is also worth considering documenting the root causes and resolutions in a knowledge base. This can help speed up resolution time and enable learnings to be brought forward onto future interface work.
With these 9 Recommendations For A Successful SAP & IBM Maximo EAM Interface in mind, there can be further challenges to face when developing interfaces that can vary depending on a variety of factors. There are a number of common challenges we have come across in our experience of interfaces at BPD, these are listed below, together with comments and suggestions on how to overcome them.
There is often a fairly lengthy initial discussion around which system should be the master for each data set. Ultimately there is no perfect right and wrong answer for many of the data objects, with multiple systems being more than capable of handling being the master data holder. Due to this, we often recommend reviewing the following points:
Once required interfaces and objects are defined, together with master and secondary data sets, the next challenge is often around what transportation method will be used to interface the data. Most enterprise solutions support a range of transportation methods including flat files, XML, database tables, REST/APIs, Web Services etc. As many of the options could be used successfully, it is often challenging to decide which will be used. While decisions can vary, we would often consider the following points:
While multiple systems can handle the same types of data objects (Purchase Requisitions, Purchase Orders, Inventory etc.) the required data to process each record can vary based on system and business processes. Due to this, it is always worth carrying out a GAP analysis on the required data from each system and not make the assumption that the required fields for one system will be the same as another. It is also worth taking into account any validation requirements and data translation requirements when interfacing data between systems. While this can usually be handled with interface configuration, complex conversions can often require heavy customisation, which will then require ongoing support. Your integration will transfer the data between systems, there may be other steps that are required before that data can be used within the system, consider automating these steps wherever possible to make the integration more seamless.
While Risks for an interface vary from project to project below provides a table of the common risks associated with developing an interface, together with methods of mitigating the risk:
Risk |
Mitigation |
| Defined Interface is overly complex | Review what is actually required in order to satisfy business requirements and focus on core requirements, not optional elements |
| Multiple options for Master of Data | Focus on where the data will be most used and is most required to be up to date |
| Existing interfaces use out of date/unsupported methods | Consider using a new transportation method with a plan to migrate the existing interfaces at a later date |
| Expected interface development costs are higher than expected | Consider reusing existing interfaces or simplifying requirements |
| A high number of issues after go-live | Through testing prior to go-live using a range of testing types (negative, load, all-path etc.) Also focus on underlying issues rather than ‘firefighting’ individual records |
| The interface method could be shortly out of date or unsupported | Ideally ensure interface data is separate from transportation protocol, meaning that the transportation method can be changed while still using existing interface structure, this allows the transportation to be updated without a full interface redevelopment |
| Changes made by multiple teams for different systems can cause the interfaces to be out of alignment | Maintain a clear interface document which notes all interfaces and rules included, ensure this document is used and understood by all teams and ideally held in a central repository to ensure the correct version is used. |
| Slave system data | Unless your interface is bidirectional you may need to restrict access to data in the ‘Slave’ system to prevent data misalignment. |
| Change of Master system | If the integration is due to a change in the ‘Master’ system, do not forget to disable or remove previous automations that may continue to function, such as approvals of PR to PO. |