DETAILS / OPTIONS:

I have a long list of fairly simple requirements like this:
If the top level of the WO classification is FLEET, then set WORKORDER.FLOWCONTROLLED to 1.

Option #1:

1. Add a custom FLOWCONTROLLED YORN field to CLASSSTRUCTURE.
   • (Or alternatively, create a custom DIVISION table and add a FLOWCONTROLLED field. This table would also be useful for a number of other requirements. I'd need slightly different mechanisms for auto-population than what I have below.)
2. Batch update CLASSSTRUCTURE.FLOWCONTROLLED to 1 where the top level of the classification is FLEET.
   • I would do this using MxLoader.
3. Set up a crossover domain to auto-populate WO.FLOWCONTROLLED when the classification is modified in the WO.
   • In reality, we would use an automation script (existing) instead of a crossover domain, since we've found Maximo doesn't always honor crossover domains when creating WOs (buggy). For example, crossover domains aren't honored when a WO is created via a PM/JP/route.
4. Deploy and apply the changes to all environments (6).
   • The new FLOWCONTROLLED field in CLASSSTRUCTURE will require a db config outage.
   • I would apply db config changes myself to non-clustered environments (4).
   • We would need to plan/coordinate with the WebSphere team to get them to apply db config changes to the clustered environments (2). This involves after-hours work (after midnight; overtime) and of course, a system outage.

I'm under the impression that it's best to put logic in tables when we can, and use OOB functionality, instead of hardcoding the logic in code (i.e. automation scripts).

Benefits of putting logic in tables (like CLASSSTRUCTURE) include:

1. OOB functionality is easier to read/understand than code.
2. DRY - Don't repeat yourself. We only need to enter the logic into the table once.
   • It's easier to make bulk updates to tables, than it is to make bulk updates to code. 
   • It would be easy to refine the logic. For example, if the requirement changed and only some of the FLEET WO classifications required flow control, it would be easy to refine the data in CLASSSTRUCTURE by setting some of the FLOWCONTROLLED values to 0 instead of 1.
3. Database tables and OOB functionality can be easily upgraded. Code is much harder to upgrade.
4. My organization considers automation scripts to be customizations. And customizing systems is a violation of corporate policy. Ideally, I would put logic in tables, and use OOB functionality, to avoid violating corporate policy.

Tradeoffs:

To be honest, option #1 is way too much work -- since it involves db config changes (including clustered environments). It would require many hours of effort from admins and the WebSphere team. Not to mention an outage.

Option #2:
Hardcode the logic in code (automation scripts)

In contrast, I think I could implement the requirement quite easily by hardcoding the logic in an automation script. I don't actually work with automation scripts much yet, but I'm guessing a line or two of code would do it:

1. If WO.DIVISION is modified, and if the WO.DVISION = FLEET, then set WO.FLOWCONTROLLED to 1.

Benefits to hardcoding the logic in scripts:

1. Takes minutes, not several hours/days.
2. No db config outage required.
   • I could easily make the change myself, by pasting that script into all 6 environments.
3. All logic is in one place -- in the Automation Scripts application.
   • If we're wondering what mechanism is responsible for populating a custom field, we know where to look -- automation scripts. There isn't any hidden functionality in formulas or crossover domains that we forgot about.

Tradeoffs:​​​

1. We don't get any of the benefits from #1.
2. Code is difficult to maintain.
   1. I'm essentially saying, "screw you!" to the next guy who has to maintain the system and eventually upgrade it. That poor soul has no idea what's coming.
      
      

THOUGHTS:

To be honest, I'm a bit sad that I've come to this conclusion. I'm basically choosing to manage Maximo the wrong way...since the right way is turning out to be impractical. Goodbye data-driven/OOB best practices, hello unmaintainable code! :)

FOLLOW-UP QUESTION:

How does this compare with your experience? What do successful practitioners end up doing in the long run?

MAXVARS - Maximo Customisation

"When creating Maximo customisations either MaxVars variables or System Properties can be useful (with a preference to the latter) in order to avoid hard-coding values to provide reusability and flexibility. For example say you have a workflow that routes purchase orders over a particular value to the CEO for approval. Rather than hard-code the currency value in the workflow you could create a custom system property to store the threshold value amount and use a custom condition automation script to compare the PO total cost to the system property value and return a true or false accordingly. Therefore if the value threshold for CEO approval changes in future you only need modify the system property not the workflow."

DETAILS / OPTIONS:

I have a long list of fairly simple requirements like this:
If the top level of the WO classification is FLEET, then set WORKORDER.FLOWCONTROLLED to 1.

Option #1:

1. Add a custom FLOWCONTROLLED YORN field to CLASSSTRUCTURE.
   • (Or alternatively, create a custom DIVISION table and add a FLOWCONTROLLED field. This table would also be useful for a number of other requirements. I'd need slightly different mechanisms for auto-population than what I have below.)
2. Batch update CLASSSTRUCTURE.FLOWCONTROLLED to 1 where the top level of the classification is FLEET.
   • I would do this using MxLoader.
3. Set up a crossover domain to auto-populate WO.FLOWCONTROLLED when the classification is modified in the WO.
   • In reality, we would use an automation script (existing) instead of a crossover domain, since we've found Maximo doesn't always honor crossover domains when creating WOs (buggy). For example, crossover domains aren't honored when a WO is created via a PM/JP/route.
4. Deploy and apply the changes to all environments (6).
   • The new FLOWCONTROLLED field in CLASSSTRUCTURE will require a db config outage.
   • I would apply db config changes myself to non-clustered environments (4).
   • We would need to plan/coordinate with the WebSphere team to get them to apply db config changes to the clustered environments (2). This involves after-hours work (after midnight; overtime) and of course, a system outage.

I'm under the impression that it's best to put logic in tables when we can, and use OOB functionality, instead of hardcoding the logic in code (i.e. automation scripts).

Benefits of putting logic in tables (like CLASSSTRUCTURE) include:

1. OOB functionality is easier to read/understand than code.
2. DRY - Don't repeat yourself. We only need to enter the logic into the table once.
   • It's easier to make bulk updates to tables, than it is to make bulk updates to code. 
   • It would be easy to refine the logic. For example, if the requirement changed and only some of the FLEET WO classifications required flow control, it would be easy to refine the data in CLASSSTRUCTURE by setting some of the FLOWCONTROLLED values to 0 instead of 1.
3. Database tables and OOB functionality can be easily upgraded. Code is much harder to upgrade.
4. My organization considers automation scripts to be customizations. And customizing systems is a violation of corporate policy. Ideally, I would put logic in tables, and use OOB functionality, to avoid violating corporate policy.

Tradeoffs:

To be honest, option #1 is way too much work -- since it involves db config changes (including clustered environments). It would require many hours of effort from admins and the WebSphere team. Not to mention an outage.

Option #2:

Hardcode the logic in code (automation scripts)

In contrast, I think I could implement the requirement quite easily by hardcoding the logic in an automation script. I don't actually work with automation scripts much yet, but I'm guessing a line or two of code would do it:

1. If WO.DIVISION is modified, and if the WO.DVISION = FLEET, then set WO.FLOWCONTROLLED to 1.

Benefits to hardcoding the logic in scripts:

1. Takes minutes, not several hours/days.
2. No db config outage required.
   • I could easily make the change myself, by pasting that script into all 6 environments.
3. All logic is in one place -- in the Automation Scripts application.
   • If we're wondering what mechanism is responsible for populating a custom field, we know where to look -- automation scripts. There isn't any hidden functionality in formulas or crossover domains that we forgot about.

Tradeoffs:​​​

1. We don't get any of the benefits from #1.
2. Code is difficult to maintain.
   1. I'm essentially saying, "screw you!" to the next guy who has to maintain the system and eventually upgrade it. That poor soul has no idea what's coming.
      
      

THOUGHTS:

To be honest, I'm a bit sad that I've come to this conclusion. I'm basically choosing to manage Maximo the wrong way...since the right way is turning out to be impractical. Goodbye data-driven/OOB best practices, hello unmaintainable code! :)

FOLLOW-UP QUESTION:

How does this compare with your experience? What do successful practitioners end up doing in the long run?

DETAILS / OPTIONS:

I have a long list of fairly simple requirements like this:
If the top level of the WO classification is FLEET, then set WORKORDER.FLOWCONTROLLED to 1.

Option #1:

1. Add a custom FLOWCONTROLLED YORN field to CLASSSTRUCTURE.
   • (Or alternatively, create a custom DIVISION table and add a FLOWCONTROLLED field. This table would also be useful for a number of other requirements. I'd need slightly different mechanisms for auto-population than what I have below.)
2. Batch update CLASSSTRUCTURE.FLOWCONTROLLED to 1 where the top level of the classification is FLEET.
   • I would do this using MxLoader.
3. Set up a crossover domain to auto-populate WO.FLOWCONTROLLED when the classification is modified in the WO.
   • In reality, we would use an automation script (existing) instead of a crossover domain, since we've found Maximo doesn't always honor crossover domains when creating WOs (buggy). For example, crossover domains aren't honored when a WO is created via a PM/JP/route.
4. Deploy and apply the changes to all environments (6).
   • The new FLOWCONTROLLED field in CLASSSTRUCTURE will require a db config outage.
   • I would apply db config changes myself to non-clustered environments (4).
   • We would need to plan/coordinate with the WebSphere team to get them to apply db config changes to the clustered environments (2). This involves after-hours work (after midnight; overtime) and of course, a system outage.

I'm under the impression that it's best to put logic in tables when we can, and use OOB functionality, instead of hardcoding the logic in code (i.e. automation scripts).

Benefits of putting logic in tables (like CLASSSTRUCTURE) include:

1. OOB functionality is easier to read/understand than code.
2. DRY - Don't repeat yourself. We only need to enter the logic into the table once.
   • It's easier to make bulk updates to tables, than it is to make bulk updates to code. 
   • It would be easy to refine the logic. For example, if the requirement changed and only some of the FLEET WO classifications required flow control, it would be easy to refine the data in CLASSSTRUCTURE by setting some of the FLOWCONTROLLED values to 0 instead of 1.
3. Database tables and OOB functionality can be easily upgraded. Code is much harder to upgrade.
4. My organization considers automation scripts to be customizations. And customizing systems is a violation of corporate policy. Ideally, I would put logic in tables, and use OOB functionality, to avoid violating corporate policy.

Tradeoffs:

To be honest, option #1 is way too much work -- since it involves db config changes (including clustered environments). It would require many hours of effort from admins and the WebSphere team. Not to mention an outage.

Option #2:

Hardcode the logic in code (automation scripts)

In contrast, I think I could implement the requirement quite easily by hardcoding the logic in an automation script. I don't actually work with automation scripts much yet, but I'm guessing a line or two of code would do it:

1. If WO.DIVISION is modified, and if the WO.DVISION = FLEET, then set WO.FLOWCONTROLLED to 1.

Benefits to hardcoding the logic in scripts:

1. Takes minutes, not several hours/days.
2. No db config outage required.
   • I could easily make the change myself, by pasting that script into all 6 environments.
3. All logic is in one place -- in the Automation Scripts application.
   • If we're wondering what mechanism is responsible for populating a custom field, we know where to look -- automation scripts. There isn't any hidden functionality in formulas or crossover domains that we forgot about.

Tradeoffs:​​​

1. We don't get any of the benefits from #1.
2. Code is difficult to maintain.
   1. I'm essentially saying, "screw you!" to the next guy who has to maintain the system and eventually upgrade it. That poor soul has no idea what's coming.
      
      

THOUGHTS:

To be honest, I'm a bit sad that I've come to this conclusion. I'm basically choosing to manage Maximo the wrong way...since the right way is turning out to be impractical. Goodbye data-driven/OOB best practices, hello unmaintainable code! :)

FOLLOW-UP QUESTION:

How does this compare with your experience? What do successful practitioners end up doing in the long run?