Inoculation Pattern in Change Management
Gautam Hegde/Koushik H
gautam@backend.co.in/koushik@backend.co.in
Backend Bangalore Pvt. Ltd. #587, KPC Layout, Bangalore - 560035

Abstract
The management of change becomes very challenging for the implementers and users in the live
environment of a software implementation. The change necessitated due to increased visibility into theuser requirements or due to underlying technology changes have to be brought about in real time
without bringing down the system. The inoculation pattern suggests bringing about the essential changein a gradual and staged manner keeping the quantum of change well below the user’s rejection
threshold. The process comprises of –1. Identifying, Ordering and Selecting functional modules in terms of importance and usage from auser perspective
2. Injecting the change in selected modules;
3. Allowing sufficient familiarity in these modules before the changes are introduced to the rest,
until all of the modules are covered and the whole change is implemented.

ThumbnailIf

Changes are required due to additions/alteration in user requirements;
Due to change in underlying technology

Then

Identify modules in terms of importance to user and usage
Injecting change in selected modules
Allow for incubation of familiarity with the introduced change, before inoculating rest of themodules

Problem
Changes are inevitable in software process and happen due to alteration and additions to userrequirement. Changes can also happen due to change in underlying technology. Incorporating thesechanges in live environment can be extremely challenging. Implementers do not have luxury ofdowntime or long drawn user training schedule. The implementation of changes and user training has to1|Page

Version 1.3

5 Feb 2014Inoculation Pattern in Change Management
be done on the fly. User resistances to changes have to be overcome smoothly so that their rejection
threshold is not breached. Business continuity is of paramount importance since discontinued services
mean risking loss of business. So the change management program has to evolve a method for
introducing the changes without risking business continuity.

Forces

Scope creep: documented scope in software development process is usually like a tip of ice-bergwith a large portion of work hidden at the requirement capture stage.
Increase in visibility of additional requirements during the course of implementation.

Solutions
Software Architecture has to cater to inevitable future changes. While the visibilities to the changes arelimited, an n-tier approach may help by separating the functionalities in different layers.
Software architecture could be visualized at the logical level as abstract layers comprising of specific setof functional components interacting with each other to deliver specific business functions.

2 | Page

Version 1.3

5 Feb 2014

Inoculation Pattern in Change Management

Functional modules may be grouped logically into following layers or logical block: Database/Storage (DB):This is the layer the persistent data is stored as tables or files.
 Data Access Layer (DAL):In this layer the methods for accessing Database is defined. As methods of accessing different DBs aredifferent, this layer hides/abstracts the details from top layers.

 Business Logic Layer (BLL):In this layer addresses the functions of business where business logic decides the data to be collected anddirected into DB through DAL. This layer also provides interfaces to top layers as well as feature interaction
among layers.

 Transport Service Layer (TSL):
This layer comprises of communication and security protocols defining means of transportation of
information functioning as an interface between Business Logic Layer and User Interface Layer.

 User Interface (UI):This is the layer visible to user through which they make use of the business logic to achieve the objective ofsoftware application. The users interact with application server side software through this layer using clientside software like web browser or forms.

Each layer interacts with its adjacent layer [LayerX] [upper (LayerX+1) or lower (LayerX-1)]

3 | Page

Version 1.3

5 Feb 2014

Inoculation Pattern in Change Management
To implement a change in a software system, multiple layers may be affected, which may break existingfunctionalities. Change may be in
A. UI layer or
B. Underlying layers in that module with corresponding UI change or
C. Only in specific layer(s) but impacting user experience without affecting UI
Changes in the UI and/or changes in the user experiences increase the chance of user discomfort.
One approach is to surgically replace the whole functional module with a new enhanced module. In suchcases probability of user discomfort could be high resulting in larger outlays of time and resources for
re-training. To avoid this, an approach can be taken which gradually changes the system instead of doinga drastic change. This could be particularly effective where there are eye-visible changes.
The gradual change approach helps to maintain the continuity of the services. Same approach may be
applied to each functional module and its dependant module.
Example: Injecting a change in Business Logic Layer
Stage 1: Create change as new entity
Changes as new Module X.1

Services (Reference)

Deprecated Module X

Module 1

Module 2

Module nBusiness Logic Layer
Stage 2: New block (Changed) and existing block co-exist so that if there is a problem there can be easyroll back.
Test Services (Reference)
Module 1

New Module X.1

Services (Reference)
Deprecated Module X

Module 2

Module nBusiness Logic Layer

4 | Page

Version 1.3

5 Feb 2014

Inoculation Pattern in Change Management

Stage 3: Deprecated block removed after successful testing of new block. All references to thedeprecated block from rest of the software also removed.
Services (Reference)
Deprecated Module X
Module 1

New Module X.1Module 2

Module nBusiness Logic Layers
In case of any necessity of Rollback the Deprecated Block and it references can be brought to its originalpositions.
Services (Reference)
Module 1

Deprecated Module X

Business Logic Layer

New Module X.1

Module 2

Module ns

Stage 4: Change completed. Deprecated block is archived.
Deprecated Module X
Module 1

Business Logic Layer

5 | Page

Services (Reference)
New Module X.1

Module 2

Module ns

Version 1.3

5 Feb 2014

Inoculation Pattern in Change Management
Example: If change affects a single functional blockOriginal

State 1

State 2

State 3UIUIUIUIUIUIServices

Services

Services

Services

Services

Services

Stage 4UI

UIServices
Services

BLL

BLL

BLL

BLL

BLL

BLL
BLL

BLL
DAL

DAL

DAL

DAL

DAL

DB

DB

DB

DB

DB

Archive

Existing Block
Block to be updated
Updated BlockUIServices

Merged Block

Archived Block

BLL

In this case all the dependant layers are duplicated and merged at each stage with consequent changes
in dependant interfaces. Co-existing old block and new block helps to keep backward compatibility androllback if there is any necessity. After each dependant block is merged, old block’s content can beremoved/archived.

Resulting Context
Enhanced functionalities achieved without disruption of any business services and user re-trained withminimal time and effort.

Conclusion
Inoculation pattern is most effective in cases of eye-visible change management. There could be some
limitations to this pattern in cases where changes impact user experience without consequent changes
to the UI.

Acknowledgement
We would like to acknowledge Prof. K V Dinesha of International Institute of Information Technology –Bangalore for enlightening us on PLoP and shepherding us in the preparation of this paper by holdingthe preparatory workshop. We also like to thank Mr. Éric Platon for shepherding this paper.
6 | Page

Version 1.3

5 Feb 2014