This document discusses 10 aspects of software configuration and change management that organizations should consider when implementing solutions. It explores how the change process is universal and can be broken down into four steps: monitoring, requirements, development, and deployment. It emphasizes that bugs are most inexpensive to fix early in the lifecycle, and that everything in software is interrelated so even small changes can have large effects. Automated processes result in documentation, and maintaining multiple versions of software can resurrect bugs from older versions.

1.
10 Obvious Statements about
Software Configuration and Change
Management
(And What They Mean For Your Organization)
A Remain Software Whitepaper
By Wim Jongman, CTO
“Sometimes the first duty of intelligent men is the restatement of the obvious.”
~ George Orwell
Remain Software

2.
Background
This document will explore 10 important aspects that should be considered before proceeding with the
implementation of a specific solution. Most SCCM solutions address the common issues of source
control many do not address the entire SCCM process requirements. In this document we try and
highlight some of these additional needs.
Remain Software

3.
10 The Change Process is Universal
We don’t always think about Change Management as being a complex process. Given the diversity of
today’s international laws and regulations it is most of the time also a very complex process.
I was taught to break down complex matters to a level where they are no longer complex. After this
has been done, it is much easier to
go back and grasp the complexity of
the whole.
At Remain Software we work with a
slide that discusses how we address
SCCM issues at a high level.
When I start talking about the
different elements in the Software
Change process I often see my
audience’s eyes glaze over.
At that moment we like to break it
down. To do that, we only need to
use the four essential elements
from this slide. Here is why the change process is a universal four‐step
cycle:
1. In every change process there is already something in existence. I like to
call that state the monitoring state. It could also be called the
production state, but in the eyes of the change manager it is
monitoring.
2. The component has left the monitoring state because it is broken in
some way or no longer provides the required functionality. We now
enter the requirements state. What do I require to fix this?
3. After the requirements are defined and documented, we can fix the component. This is the
development state. It stays in this state until it is fixed.
4. After it is fixed, we need a transfer state. The component needs to be inserted back into the
production environment. This is the deployment state.
No matter what you change, software or anything else, this change process is always the same. When
these basic steps are clear, we can start adding the complexity.
Remain Software

4. 9: The Result of an Automated SCCM
Process is Documentation
What we do in an automated process in each of the change states is typically managed by electronic
documents. For example, if a user reports a bug this is logged as a problem. Based on this problem the
process will issue a change request. If we are advanced we will flag this in the problem document and
we will log the details such as the date and time when the change request was raised.
Now the change request will probably comply with several review stages before it is sufficiently
authorized so that we can actually start assigning the tasks to our developers. All this activity also
requires to be properly documented (logged).
Now when the developers have received their assignments, we need to see which software components
they will change as a result of the development task they have been given. Before allowing a change, a
copy is made of the previous version so that a roll back can occur, if required. This copy is also useful to
see the differences between this copy and future versions.
After the programmer has made the changes, the testers can perform their work. All of their work
including test results should be logged and documented. In addition formal signoff needs to be recorded
before the change is allowed the transition into production.
If you do this for a while, and if you are able to open up your database, then you can create all kinds of
documentation, whether it is aimed at the end‐user, the developer (see #2) or your SOX auditor (see
#4).
Here is an example of a drill down view on a program called PGM01. This view can exist because the
SCCM process provides automatic documentation.
Remain Software

5.
8: Bugs are the most inexpensive when
terminated early in the life cycle
Our opportunity to save some serious money is at the point of time when we really start believing that
this is true. Of course, we know that it’s true, but we don’t believe it.
There is a reason why most companies don’t feel this pain as much as they should. At Remain Software
we like to call this the “post‐bug cost calculation”. There is not even a well‐known expression for it
because most of the time we never calculate how much a bug has actually cost us.
What typically happens when a serious bug is reported in production is that everybody that can
contribute drops everything he or she was doing. Then we frantically search for the cause of the error,
assess the damage done and fix it as soon as possible.
The stress in the company rises exponentially with each minute the bug persists. But, the stress is
relieved almost instantaneously after the bug is solved, as if a balloon popped. Of course we have a
meeting and the guilty party (if we can find somebody, see #2) is spoken with, but ultimately we are
happy that the bug is solved and we continue with our day‐to‐day business.
What has this bug cost us? Usually we have
no idea.
Various studies have shown the effects
depicted in this diagram. If you fix a bug
during the testing phase it will cost you 17
(minutes, dollars, lines of code) whereas
fixing the same bug in production will cost
you 105 of the same.
So if you find a bug during testing and it
required one day to fix it, it would have taken
an equivalent of seven days if it were solved
in production. Of course, the time to fix it
would be the same (or even a bit faster) but
it would hit you seven times harder.
If you are reading this document electronically, try these links:
http://www.remainsoftware.com/en/news/index.php?page=prodnews&artid=soundfamiliar
http://www.origsoft.com/reading_room/nightmares.htm
Remain Software

6.
7. Multi‐Tier Software Development
requires synchronization of the watches
Many of us now develop for multiple tiers. This means that some code runs on a database backend
server like the System i and other code runs on another platform such as a Wintel application server or a
desktop.
The major issue with this approach is the opaque dependencies between the software components on
the various platforms and operating systems that make up your application (see #5).
If a database definition changes, how do we know which web application uses this table. Similarly, if we
change a module, which programs call this module? This needs careful investigation and documentation
which costs time and money (see #5).
But when it is time to go live, we must have assurance that all the tiers will go together. And if one
platform fails to install, we must be prepared to roll back all platforms.
Remain Software

7.
6 .Multiple Versions of the same
Application resurrect bugs
Creating another version of your application will result in the replication of the bugs that exist in your
original version. Most of us need to maintain multiple versions of the same application. And even if you
think you don’t, you really still do for a variety of reasons.
Suppose you have an application in production that you must maintain. One of your programmers is
working on a large project and this involves radical changes to an important number of your software
components.
In the mean time, your customers (this includes end‐users) may find a bug in the code running back in
production. If that bug is serious enough, it must be fixed before the official release of the big project.
After the quick production bug fix, your programmer still maintains a version of that same program but
with the bug still alive. If the release is installed, the bug
has “risen from the dead.”
Your company will have this problem all the time if you
must maintain multiple versions of one application. A good
illustration would be an independent software vendor.
Users report bugs on all versions and you must manage
every occurrence of each component.
If a software component was copied to the next version
before a bug was solved, then you have replicated the
same bug.
Remain Software

8.
5: Everything is related. A small change
can have big effects.
There is a theory which is called the butterfly effect. It states that the flapping of a butterfly’s wings in
Beijing can cause a hurricane in the US. This is also called the chaos theory and it describes the relation
of cause and effect in complex systems like the weather.
Now, I get a headache thinking about this so what I do is I try to break it down to a level that is no longer
complex. To understand this problem, I imagine the engine of a car. This is also a very complex system
(at least it is complex to me). Now I try to imagine what would happen if I randomly punch holes in some
engine pipes, or if I remove several fasteners.
Will something happen? Probably …. but exactly what will happen depends on the relationships
between the pipes or the fasteners with other parts of the engine. If the punctured pipe is in the supply
chain of my windshield wiper fluid, then I will probably survive. If the loosened fastener is attached to
an important part of the engine, then that gentle twist of my fingers can result in serious engine
damage.
Comparing complex dynamic systems like the weather to an engine is like comparing apples to oranges,
but I think it paints a good picture.
The key to this issue is the necessity to know how the parts of your engine are related … just as it is
necessary to know about how the pieces of your software application are related. If you change one
component, you need to know which other components are impacted by this change.
Given a solid software configuration database we can undertake a proper impact analysis like the one
shown in the diagrams. With such
concise information we can ensure
proper planning and execution of the
change no matter how complicated
the component relationships are.
For electronic document readers, here
is a link to a five‐minute video that
demonstrates the pleasures of owning
an SCCM system backed by a software
configuration database and an Impact Analysis module.
http://www.remainsoftware.com/en/products/index.php?page=modules&artid=iademo
Remain Software

9.
4 Auditors are expensive
And this is because auditors have a lot of responsibility and they are careful and thorough. Auditors,
especially SOX auditors, can charge your company anywhere from $150 to $500 per hour; they are
expensive in Euros too.
So, the trick is to get the auditors in and out of your office as quickly as possible.
The time required to undertake an audit can be significantly reduced if the information required by
Auditors can be made available to them quickly and efficiently. Since SCCM is a repeatable process,
confirmation of the validity of one process confirms the validity of this process on all applications which
utilize the process thus substantially reducing the time required for an audit.
The flexibility of the SCCM Reporting needs to allow a drill down and the generation of specific Ad‐hoc
reporting.
It helps to be prepared for the question: “Can you show me?”
Remain Software

10.
3: IT departments are in the eye of the
Hurricane
By this we do not mean that everything is peaceful and quiet. It will not take long before the storm hits
our IT Department and when we are battered enough, the hurricane changes direction and before long
we face the winds from another direction.
Business requirements generate a constant pressure on the development of our system. We need to
make better sales proposals, always be one step ahead of the competition and make sure we keep the
systems up and running for 24 hours a day.
The advancement of technology makes it possible to improve performance or reduce costs. However,
the switch to new technology is always a bumpy ride over a period of time during which we must
maintain two systems. An illustration of this is the switch from Terminal Screen to Graphical.
Regulatory demands keep your system under pressure because new laws and regulations must be
complied with and new tax rates configured. Internal company affairs keep you busy as well; your sales
people have different goals than your bookkeepers.
You already known this for some time, but that is what this document is about. SCCM can help keep
your software changes flowing. Our marketing artist has made a nice visualization of what he calls the IT
Challenge.
Remain Software

11.
2: Developers are not the only ones
responsible for software bugs
There, I’ve said it. We have the habit of pointing directly at our programmers when we find a new bug in
production. But are we really pointing at the problem? Why didn’t the organization’s users find that bug
before it got into earth orbit?
Eliminating bugs is a company‐wide effort, and although many employees are not directly involved,
anybody who is a stakeholder should at least be represented in the process.
The bug hunt starts back when the plans for a new system are first developed and it ends when senior
managers have the confidence to move a new/improved system forward into production.
Giving that everything is related (see #5) there is even a stronger need for testing. With the aid of a good
Impact Analysis tool we can also see the relationships of the fixed components which could lead to
testing seemingly unrelated modules.
Testing is the answer to fewer bugs. Remember the diagram from #8?
Remain Software

12.
Remain Software

13.
1: Your business rules live in a bed of
code
Your company has many, many business rules. Take the discount rule, for example. Your customers
probably earn discounts based on a variety of parameters: total revenue over a period of time, duration
of business, seasonal programs, special end‐of‐quarter incentives, and so on. The enforcement of these
rules is captured in software.
Some enterprises have complex rules about the product expiration date. Perhaps the sell date by lot is
based on the production date for a given product you are selling. The enforcement of this rule is
captured in software.
So if you change your software, you are changing the infrastructure in which your business rules must
perform their duties. One minor mistake can void your business rules.
Reliability of business rule application is the most compelling reason why your enterprise should
consider implementing an SCCM system. With an SCCM system, you can ensure that your rules are kept
…. and …. when something inevitably requires adjustment, you will be able to quickly track down an
emerging issue and resolve the problem.
Remain Software