IBM Maximo Build EAR Process Slowing You Down? Here’s One Way to Fix It
The IBM Maximo EAR (Enterprise Application Archive) file is an enterprise archive that can be...
CATEGORY:
Tutorials
August 03, 2022
IBM Maximo is a complicated and immensely powerful tool. It can take years to develop expertise to use it effectively and efficiently. But for many of us, Maximo is just one of the many tools we have to learn and work in, and with other concerns and accountabilities weighing on us, knowing and following best practices often takes a back seat.
So, for all you power users out there, listen up! That is, if you want my two cents. After give-or-take 14 years of working with Maximo, these are my top three implementation rules:
1. DO NOT CHANGE THE CODE. Do Not Implement Weird Customizations To Meet Your Business Cases
Make sure that your business case is accurate. In my 14 years of Maximo experience, I have never changed the out-of-the-box code to meet a business requirement. I have configured Maximo with the front-end tools to meet the business requirements but have never updated or changed the Java code.
To quote author and former IBM executive Catherine DeVrye, “Remember that the six most expensive words in business are: “We’ve always done it that way.”
“We’ve always done it this way,” is not a strong enough reason to justify customization of your Maximo code. When you don’t have access to tools for Maximo CMMS configurations or automation scripting, evaluate your business processes to make sure they are correct. Because the Maximo application is built to meet industry best practices and standards.
Here’s a few great examples of the consequences of too many customizations. Less than 10 years ago, I worked with an organization that could not upgrade from Maximo 4 because nobody knew:
- What had been done to the system?
- Why those changes had been made?
- What requirements they were trying to meet?
At another place I’ve worked, they required a full reimplementation because too much customization de-standardized the system across the organization. In this case, there were multiple physical sites and what was on one screen in Maximo at one site, was not there at another site. And it wasn’t on purpose. 😉
And I can’t tell you how many times I’ve seen customizations limiting one’s ability to work with any third-party tools. Maximo is an amazing tool, but it sometimes you need a third-party application created by experts in a specific niche to reap the full benefits. Third-party tools can provide huge advantages to streamline the processes, overcome limitations, and simplify using the system. Being unable to take advantage of these tools can be huge opportunity cost.
2. Document Everything, Literally Everything
Document your requirements. Document your development. Document your results. And see Rule #1! It is impossible for me to overstate this. I can’t tell you how many times the root of the problem is that nobody has documented anything. This is another example of know-how: a few people know what has been changed in Maximo, and this information only exists in their heads. When they leave, that information is gone and we’re back to reinventing the wheel.
When I consider documentation, I think about the expression, “Punctuation saves lives”. This is like that. Documentation saves lives.
If it’s not documented, how can you do anything?
I have one guideline regarding documentation: if you think you have too much detail, you’re probably missing some!
3. Have Multiple Environments and Build a Playground So That the Mess Isn’t Made in Production
If you ever think having multiple environments is too much work or adds cost, think about how hard it will be to troubleshoot something in your single production environment without affecting your live users. (Hint: they will be affected! 😉)
Many years ago, I was faced with the ruling given by management that only one environment would be stood up. We were lucky that it was a small site with a small quantity of users, but this created many problems with patching and performing maintenance on the server. Needless to say, they’re still on the same version of Maximo that they went live with many years ago. Why? Because they are a 24/7 operation and they can’t take it down for an upgrade and they refuse to have multiple environments.
So, when I had the opportunity to provide feedback to the team lead of how many environments would be ideal, I said four.
Four Environments That You Could Create in IBM Maximo
1. Out-of-the-Box Demo Environment
This is your playground. Let people go crazy in there. Put Maximo out-of-the-box data in there and restore it any time you need. If something looks broken in production, go and test it there. You’ll know. You’ll know really quickly.
2. Development Environment
This contains a duplicate of the production data but it’s only used by developers.
3. Test Environment
This contains a current duplicate of the production data and the implementation should be a mirror image of production. Anything – I mean anything – that exists in production should exist and be functional in here.
4. Production Environment
I’m pretty sure I don’t need to explain this one.
Now that I’m much older (maybe not wiser), I would add a fifth environment to that list:
5. Staging Environment
This is a mirror image of your test environment, but here you practice your deployment processes, so that on Go-Live Day, everything is perfect.
These are my three golden rules for a successful Maximo implementation. Don’t change the code. Document everything. Have multiple environments. It’s not rocket science. Of course, these are just my opinions, but you could say they’ve been formed based on the dogs that have bitten me over the years.