#53-Changing Change, Part 3

Part three of this series on changing our relationship to change deals with the concept of encapsulating variation in business automation.  This is expressed in non-technical language and should be useful to those that lead product development initiatives.

Transcript

Changing change, Part 3.

One important aspect of dealing with change effectively is to find ways to hide changeable things in one part of the system from as many other parts of the system as possible.

One example of this: the way critical information is structured needs to appear to be the same, no matter the details. If we fail to do this, then we run into the risk of encountering problems like the Y2K bug.

Y2K remediation cost billions and billions of dollars, provided no business value, and sidelined innovation for many organizations for years. But this bug was not complex: two-digits versus four-digits is not rocket science. The problem is that it was propagated everywhere, and because it was in millions of places, it had to be changed in millions of places. And, because we knew we could miss some of them, we had to go slowly and methodically.

In systems where date calculations were done in a single place, that change was trivial to make. Unfortunately most systems were not created that way.

Another example: Imagine that you have a need to issue notifications when an event takes place. But you have a business rule. If the event happens during business hours it will be done in one particular way, whereas if the event occurs after business hours it will be done in a different way. 

This is a variation in behavior and if we force various parts of the system to examine the system clock whenever such an event takes place, and thus determine for themselves which way to issue the notification, then if that business rule changes we will have to make changes all throughout the system. On the other hand if the notification behavior appeared to be the same under all circumstances, then when the rule changed we would only change it once, in the notification system itself. That would be because the variation was hidden in the first place.

This could be even worse if the change to the business rule indicated that under certain circumstances more than one notification would need to be issued. The difference between a single action and multiple actions would be a variation in the cardinality of the behavior. Once again if every part of the system that is responsible for issuing these notifications had to make that distinction for itself, and then later we have yet another rule that applies to, say, evenings and weekends, then we will have massive, sweeping maintenance work to be done. But if notification appears the same whether it be a single call two calls or 100 calls, then we need only maintain one place when the rule changes.

These are all examples of encapsulating variation. The more of this we do the easier it will be to make changes to systems when market forces, business innovation, technological breakthroughs, alterations to the regulatory laws that govern our business, or any kind of change is required to remain competitive.

How can we do this? This is a matter of technical training, namely that the developers who create the systems to automate our business processes understand the techniques that are needed to be able to hide all these variations and dozens of others that I could name. It is a question of analysis and design, and the skills that our technical teams possess.

Those who manage those teams must understand and support the notion that they need this knowledge so that they can serve the business in an environment of increasingly constant change. 

Also: best practices and strong policies must govern the way in which we manage change. I'll talk about that next week.