This mini-series outlines some risky practices that I have seen from Maximo and non-Maximo installations or heard about when talking to system administrators.

Maximo is often used to help manage risks for work on highly valuable assets but ironically installations can have risky practices that put the Maximo installation at risk and this mini-series will highlight some of them.

Using obscure code rather than the best practices

Maximo has a very large code base (over 20 million lines of code) and inevitably that means that there are often multiple ways to do things. IBM provide functions to automate a lot of the key things that developers will want to do but at times IBM may also replicate some functionality in more obscure areas to make certain tasks easier.

It can be tempting to use the more obscure functionality but the dangers need to be considered carefully.

A non-Vetasi Maximo developer posted that they had found an obscure piece of code that made it easier for them to perform a potentially dangerous operation. IBM provides an official a set of functions to do the operation and it takes a little more work to get it working.

The obscure code was buried in a crontask provided as an ancillary function to a component that may not be used in all installations.

It wasn’t long before someone responded by highlighting that the crontask had been removed in a future Maximo release and thus that the code would actually break in the future.

This leads to an interesting situation.

The client now has a piece of code that will fail to compile when the installation is upgraded beyond the release where the crontask was removed.

Software is typically supplied under a warranty that won’t have provisions for ensuring that the software will work with a future upgrade – so any remedial work may have to be paid for separately as an unexpected cost.

My Advice

• Always ask if customisations are doing things that are non-standard e.g. using an unrelated crontask to provide functionality
• Upgrades will always contain an inherent risk that external customisations could break and organisations should expect that.
• Understand the long term risk of using solutions
• Provide a guide for incoming developers setting out what is/isn’t acceptable. If your organisation is not happy taking risks like this then clearly state that management approval may be required
• If specific functionality is required then raise a RFE to ensure that it is provided in the main product as a long term feature.

This blog series

This article is one of a series of articles to help system administrators understand the Maximo logs and the underlying architecture.

This series is written by Mark Robbins who has been recognised by IBM as an expert in his field via the IBM Champion programme. Mark has supported/developed Maximo systems and trained system administrators for over 8 years and actively promotes good support practices via his blog and webexes.

Articles are normally posted on a Tuesday.

If you like this article then please share or like it.

Whilst I support the wider Maximo community and encourage the spread of knowledge, when republishing content from this blog please include the originating author along with the article or parts of.

If people do find parts of this blog coming up in blogs/newsletters/communications then please contact me directly.