Following the initial implementation and after several years of usage and maintenance, your Maximo^® software is likely to be fully optimised to support your business processes. Most of the bugs will have been eradicated and the users will be well versed in operating it. However, the precise 'recipe' of how the system was tailored to work for a specific company is not always easy to reconstruct.

We often encounter cases where fragments of this 'recipe' have been lost, and the organisation struggles to replicate the desired level of performance after an upgrade, technology update, change in the organisational structure etc. To help such companies, we have developed the following range of services:

• Documentation Audit
  Where documentation is incomplete, out-of-date or its condition is unknown, we will analyse it, compare it with your system and database, and help you to complete and update it.
• Configuration Audit
  Verify the state and integrity of all items that have been configured on your Maximo^® system, so they can be replicated in the event of an upgrade or when you need to configure a new 'out-of-the-box' Maximo^® installation.
• Code Audit
  A critical, independent evaluation of any custom code enhancements which have been added to your Maximo^® system. Often used to provide an impact assessment on any system updates or upgrades being considered.

Besides the natural need for an up-to-date documentation of the system, the issue of incomplete or inaccurate documentation is critical whenever a new change needs to be implemented or the system needs to be upgraded to a new version. Not knowing what's inside the black box and how it works can result in months of what we call 'chasing ghosts' around the system, when a change in one area directly causes a problem in a different area of the system.

There is almost always a strong business case to be made for investing in good documentation:

1. Breakdown recovery time. If a malfunction happens in the system, the time it takes to fix the problem will be longer without documentation. The question that we need to answer is what the potential cost to the business is when specific functionality is not available. Once we have calculated these figures (e.g. Application 'XYZ' produces costs of £10,000 per hour while it is down), then we start estimating how fast we can remove the fault if we were to have documentation. The end result is a matrix of functionality and associated business costs, and based on the findings, you decide whether or not we need to invest in new system documentation.
2. System maintenance. How effectively can you maintain the system without proper documentation? When thinking about this we must consider both the current situation where there may be a team that has been maintaining the system, and the potential future, when the current team is replaced. Similar to above, we assess the cost to the business of system downtime. In this case, the downtime would be due to incorrect maintenance procedures (e.g. a new employee makes a backup of the system but is not aware that there are some custom files that need to be backed up too. Later, a problem happens that requires a restore of that backup but because the backup is faulty, we cannot bring the system up).

The documentation audit incorporates the following three stages:

• Identify
  • Install 'vanilla' Maximo^® and compare
  • Use Code Development's own MaxCC software to record configuration and compare with vanilla system
  • Use file comparison tools
  • Use directory comparison tools
  • Database Inspection
  • Software walkthrough with users
• Explain
  • Explain purpose of identified Changes
  • Ask users
  • Ask system support
  • Consult existing documentation
  • Reverse engineer Java and WorkFlows where needed
• Document
  • Catalogue, unify and organise existing documentation
  • Set up document/knowledge management system and procedures
  • Update existing and write missing documents
  • Verify completed documentation against production system
  • Train staff to maintain documentation in the future

Configuration of a typical Maximo^® system consists of many different items:

• Application screens (including customised screens)
• Database schema (including custom changes)
• Metadata (including client-specific values)
• Cloned applications
• Custom applications
• WorkFlows (including custom elements such as actions, roles and escalations)
• Java classes
• Security settings (security groups and access levels)
• Actuate reports
• PS solutions, industry-specific solutions and add-ons
• Integration parameters, MEA, configuration and processing classes (Java)
• Maximo^® messages (new messages) and language localisation files
• Other custom items

In order to fully define a Maximo^® system and make it cloneable, all above items have to be catalogued, described in documentation and easily installable on a clone system. Code Development consultants will document all configuration items, back them up and store them in their native format (XML structures, SQL scripts, Java packages etc) as well as develop procedures for re-installing them on any other Maximo^® system in the organisation.

The purpose of this effort is to be able to verify the integrity of configuration items at any point, as well as to have a bullet-proof way of replicating the current system starting from a vanilla Maximo^® setup.

Our in-house developed database configuration tool, MaxCC has a key role in archiving and validating entire ranges of Maximo^® settings, configuration items and metadata.

Even the best of custom code can cause unexpected issues and problems if not properly documented and maintained. With new versions of Maximo^®, service packs and patches, IBM often introduces changes in core Maximo^® classes which represent the basis for development of all custom code. In such cases, any change or upgrade without prior impact assessment may prove to be destructive for the daily operation of the company, especially if the code had not been developed as future-proof and in strict accordance with Maximo^® architecture. The purpose of the code audit exercise is to establish whether the custom Java code:

• contains any changes in relation to what is described in the documentation
• meets the necessary code guidelines and best practices set by IBM
• still performs the same function adequately after a change (patch or upgrade)
• is sufficiently optimised to meet present system demands
• is managed in a way which allows for easy integrity verification and change control (code versioning systems)
• is future-proof in terms of upcoming upgrades of Maximo^® versions, installation of add-ons or industry solutions, or planned further Java customisations

This process usually starts with the documentation audit, which is followed by an expert analysis of the code itself and the procedures for its maintenance. The end result is a detailed report on the differences between the actual and assumed state of the system, and recommendations for resolving any conflicts or procedural faults.

Code Development can also help with the auditing and updating of SQL trigger code on legacy Maximo^® systems.