Change Happens – It’s All About How to Handle It

Change Happens – It’s All About How to Handle It

AreYouReady

Those of you studying for the TOGAF certification may see that “change management” is mentioned in a few places throughout the specification, with slightly different contexts.

Requirements Management is the center of the ADM hub, and has managing changes to requirements as it’s primary task. Phase G talks about handling change requests during development and implementation of the solution. And Phase H has to do with monitoring for changes in the business landscape, and handling those changes.

So what’s the difference? Or is there a difference?

The center of the hub is easiest to deal with. The ADM Requirements Management phase (which is not really a phase since it’s always operating) is a process for ensuring that any requirements that change while the ADM cycle is in progress get captured and handled. We cannot expect that, once the business requirements have been identified and signed off on, that for the next several months (during the rest of the requirements phases, into planning and implementation) that the business requirements cannot change. We all know that companies NEED to react to changes in a more dynamic (yet controlled) fashion, and this phase allows you to deal with each change as it happens, and make decisions as to how it impacts the process you are currently undertaking.

For example, you might be past the business requirements phase (phase B), and working on the technical requirements (phase D). And a change request comes in that says that the business owner now expects there to be 50 new retail stores added this year, instead of 20. The solution you are designing and developing needs to be able to handle quicker growth.

Now it may be that this information has no impact for you. The solution that you are proposing and in the process of designing can handle growth the same whether it`s 20 new stores or 50. There may be no impact at all. And so you update the business requirements document, ensure the application and data requirements are not impacted, and resume work on the technical requirements. You might be able to do all that in a single day.

But perhaps your solution cannot be rolled out that quickly. Given the date you expect the solution to be complete, and the amount of time it takes to upgrade existing stores, handling 50 new stores this year might be a very difficult or impossible task. So this could very well push you to stop Phase D, go back into Phase B, and re-imagine a better solution that allows for quicker completion and rollout. This is just a hypothetical example, but the nature of the change does alter the way you react to it.

Within Phase G, the solution is already designed and the development team has the task. Your role in Phase G is compliance, and so what do you do if the solution cannot be compliant to your designs? For example, you were counting on the ordering system to be able to update the customer relationship management (CRM) in almost real time. Within minutes of an order coming in, the customer record is updated to reflect that. This allows customer service agents to be able to talk to recent orders placed without having to go into the order system specifically. But during the development or deployment, it is realized that for performance reasons, there will be a 4-8 hour delay in getting orders updated inside the CRM. This is not compliant with your requirements, and in violation of the architecture contract.

So what do you do then? Most likely, you do NOT stop what is happening and go back to Phase C (Data Requirements). You most likely have to either accept that the solution will initially be non-compliant (a dispensation), or come up with some temporary solution (a new system that will pull the orders in near real time and update the CRM) and deal with it properly the next time through the ADM. Again, it’s a hypothetical example. But how you handle change in this phase is specific to the context of this phase.

Finally, in Phase H, the solution is deployed and you are monitoring the architecture landscape for change. You are actively looking for it. You are looking for a degradation in performance of certain systems (slowly falling out of compliance with the performance requirements), looking for new technologies or changes to the industry. And of course changes can come from within as businesses wish to make small tweaks here and there without needing to kick off a full ADM round again. If you are in Phase H, you do not need to “go back to Phase B” because there is no active ADM cycle going on at this point. You either handle the change (of course, this includes keeping the baseline requirements up to date) or defer it to the next cycle.

Change is constant in business. And the TOGAF ADM has several ways to handle it.