The benefit of excluding Inactive objects in an application.

-

Should a UI allow or block the use of an object that has been disabled?


We recently had to make that decision in our MES project and chose a consistent policy of excluding inactive objects in all the end user pages. Only the administrative tools and forms designed to edit (and reenable) those objects will allow them to be interacted with.

Your decision could go either way, but here's why we made that specific choice:

 Any good application is going to last for a while.

(Based on experience, bad applications last even longer; because no one wants to get involved in rewriting something that couldn't be done right the first time.)

With a long-lasting application that has customizable "objects" you're going to eventually wind up with some that have legacy properties and mystery values. In an MES these will be things like Work Cells, Equipment, Materials, Routes, etc. 

You know which ones you don't want to touch. You've given the users new maintenance utilities that do proper validation and enforce current business rules... but these old objects have been around since long before then. They rely on deprecated tables and hardcoded conditions that were built in the bad old days. Time is what made them dangerous, and only time will kill them.


Our choice was to treat any object that has been marked as inactive as if it could have been created using outdated methods and have all kinds of inappropriate values. We only allow the end users to interact with it by re-enabling it, and we only allow them to enable it by going through the modern tools that perform validation. 

So, the act of enabling something becomes a checkpoint for consistency and compliance.

The goal is to shift the responsibility to the hands-on administrators of those objects, forcing them to deal with the "Oh, we're going to have to update Work Center X if we're going to use it again." realization, rather than allowing them to proceed straight into an "MES is broken!" situation.


Circumstances will vary, but don't forget that administrative tools for maintaining application objects are also opportunities to validate and enforce consistency of old objects. Approaching that opportunity strategically can increase success, ignore that opportunity and increase risk.

Comments

Post a Comment

Popular posts from this blog

Default Browser - set url association with PowerShell

-
 Something that is helpful to know for complicated environments. Background: We have a legacy software that is in the process of being rewritten as a Blazor application, as we begin integrating these things together one need is to make sure that invoked urls do not open in Internet Explorer.  Policy and OU based controls are not available within the timeline we're looking at. However we have an advantage in the fact that we're already using a .ps1 script that prepares some environment needs before  the software executes. Other alternatives: A popular recommendation for handling this is to work within the DefaultAssociationsConfiguration structure. This is a good option, and is well covered in articles like this:  set-default-browser-to-microsoft-edge-using-powershell/ Why this solution: This solution fits a need where anything that may cause IE to be reset as default is handled promptly without requiring a logoff or restart to take effect.  Components: Registry ...
Read more

LINQ within a foreach()

-
  An example of how LINQ where clauses save steps. The where can occur right within the declaration of the foreach LAMBDA syntax: foreach (var person in people.Where(n => n.sex == "male")) { ... } Query Syntax: foreach (var person in from person in people where person.sex == "male" select person) { ... } Both syntaxes compile to the same code (Credit to  @YuvalItzchakov   https://stackoverflow.com/a/25412168 )
Read more

Rules of Automation

-
  Automation has several concrete rules: ·           Automation requires a system o      You can't automate an action, you can automate a process.   ·           The process has to be well defined o      All actions have to be expressible with valid conditional logic      ("If this, … and this, …but not this"). o      Ultimately this means you can't use the word "sometimes" in the process description. o      All needed condition values must be in a ready and readable state before the trigger is given for an automation step.   ·           Automation projects fail because of weak processes, not because of weak technology.
Read more