Sat Aug 30 13:02:58 PDT 2014

Control Architecture: Change management: How are changes to information technology managed?


Options:

Option 1: Just let change happen and hope you can handle it.
Option 2: Make backups before changes in case you have to revert.
Option 3: Use change control prior to changes but move forward and count on your expertise to make it work.
Option 4: Use sound change control with full reversion capabilities.
Option 5: Recertify systems in context whenever signficant changes are made.
Option 6: System-specific change controls should be used.

Basis:

Just let change happen and hope you can handle it.
Fast and loose is often the best approach for smaller businesses or for portions of businesses where risks are low. The cost of sound change control is often on the order of twice the cost of not having it, so low risk and low cost make sense together. But for medium and high risk systems, change control is absolutely required.

Make backups before changes in case you have to revert.
Backups are used to provide a modicum of recoverability, and changes are made with the knowledge that reversion is, at least theoretically, possible. It is prudent to also have a tested recovery procedure and to verify that thew backups are a workable solution for recovery in desired time frames.


Research and development separated from change control separated from production, testing at each step

Use change control prior to changes but move forward and count on your expertise to make it work.
In forward-only environments, such as financial transaction systems, many enterprises choose to never go back once a substantial change is made. This means that they accept the risk of failure and save the cost of full reversion. It places additional pressure on testing and process to get it right, and means that experts have to be available to deal with the issues if and when they arise, and in real time.

Use sound change control with full reversion capabilities.
Sound change control implies:

Recertify systems in context whenever signficant changes are made.
In high-consequence systems, particularly where process failures can cause harm that is not rapidly and automatically detected and readily mitigated, significant changes (i.e., anything other than well-tested variations in parameters) should result in a system recertificaiton in context. This includes both a thorough retest of the systems undergaing changes equivalent to the acceptance tests performed initially, regression testing of all known and resolved subsequent issues, and tests equivalent to acceptance and regression tests of interoperation to assure that changes don;t have adverse effects on related systems.

System-specific change controls should be used.
For systems that directly contact and control physical systems, changes are very closely related to the specifics of the physical system under control. As such, issues like stability and the ability to maintain control over the process are central to change management. As such, these are engineering decisions that rely on engineering calculations and analysis. Such changes cannot be made in bulk or based on a generic patch management approach, and cannot be tested with common system testing methods. Plant shutdown is often required for such changes, and simulations may also used to test some classes of changes.

Copyright(c) Fred Cohen, 1988-2012 - All Rights Reserved