If you’re like most of our customers running IBM Maximo, you’ve probably run into a performance issue or two recently — maybe it was something obvious, maybe it took a long time to debug, maybe you bought some more consulting services to fix it or maybe you are the consultant who’s trying to fix it. Regardless of the circumstance, I’ve found that most IBM Maximo implementations, regardless of industry and implementation, have a few things in common:
- They’re Big — Implementations span thousands of users, managing large portfolios of assets
- They’re Mission Critical — Business can’t function without them. Service calls can’t be scheduled, work can’t be done and it’s hard to know what’s going on.
- They’re Complex — Typically deployed across farms of servers, integrating with backend ERP, database, inventory, scheduling and a variety of homegrown applications. Usually deployed and managed by a team of folks, patches and updates can go through a long validation cycle before ever seeing production
- They’re Opaque — From an operations perspective, you may understand the general data flow through your system, but it’s difficult to know when something is down or slow and what the root cause is. It’s easy to get into a finger pointing scenario because no one’s sure what’s really going on.
Sounds like a perfect candidate for Application Performance Monitoring.
The nice thing about Maximo is that it’s written on an IBM WebSphere Java application framework, which makes it a good candidate for instrumentation and performance monitoring. A small modification to the WebSphere JVM arguments to include the AppDynamics Application Agent and you’re off to the races.
Once you have the agent installed for your IBM Maximo WebSphere server, you should immediately start seeing performance data and flow map for any requests you’ve made to IBM Maximo.
Business Transaction Configuration
IBM Maximo operates on a relatively straightforward URI scheme, which makes Business Transaction detection easy. Since traffic is initiating from the IBM Maximo tier, all BT detection happens there. Most of the action happens within a few main URLs:
/maximo/ui/
/maximo/ui/login
/maximo/report
/maximo/ui/XXXX
From there, the request is broken down further based on the URL parameter “value”. Ok, easy enough — modifying default BT naming to include 3 segments and creating a custom match rule to split the transactions based on value leaves us exactly what we’re looking for.
Backend Applications
Backend applications for Maximo come in a variety of different flavors. From a performance monitoring perspective, they can be categorized into:
- Off The Shelf such as BO, SAP, etc
- Custom Built
- 3rd Party (web-based)
In addition, these apps can be built in either native or managed languages. AppDynamics can view performance for each of these, but the approach varies depending on the architecture of the application and how much instrumentation you want for that application.
For most IBM Maximo implementations, the deployment typically includes a mixture of both fully instrumented applications and applications instrumented as exit points.
Typically your custom built application backends would be the primary candidates for full instrumentation. I won’t go into full detail here on how to set these up, but with basic configuration, you should be able to see full data flow throughout your IBM Maximo deployment.
So… Now What?
With this newfound visibility into IBM Maximo, now you can start realizing core benefits of APM, alerting, root cause analysis and best of all: performance metrics! If you’d like to try this out for yourself, you can get an environment here.
