Enterprise Architecture Migration Planning – Timing is Everything

Architects will often think of their work as having 4 major phases:

  1. Develop the As-Is model
  2. Develop a To-Be model
  3. Develop a migration plan
  4. Govern the plan delivery

I am interested here in the third phase, migration planning. Let’s define a migration plan…

There are two primary types of migration plan:

  • A formal transformation program – this will typically be a major replacement or upgrade of the IT landscape that underpins major business change
  • A set of policies that steers IT change

There will always be business and IT changes that fall outside formal change programs. These will require governance to ensure that they do not derail the program. A light touch approach to smaller changes avoids diverting scarce resources unnecessarily. The light touch is a set of policies managed into projects supportively (I have covered this approach elsewhere). I want to focus on transformation programs.

The original Zachman framework had columns for data, function and network – the traditional IT domains. It was later extended to include people, motivation and time. The importance of time dimension is often overlooked, particularly the top two rows which cover business cycles and business events.

It may seem obvious that the time dimension is critical when planning large scale change but I have seen on several occasions that no attempt is made to understand this. The result is that an otherwise well formed plan is rejected and the authors condemned as having no business knowledge. A devastating loss of credibility for an enterprise architect.

First, business cycles…

Pretty much all organizations have an annual financial cycle. This will include start and end of year, budgeting, budget revisions, internal and external reporting. There will be periods within this cycle in which the finance department and potentially some managers throughout the business will be no go areas for business or IT change.

Running alongside the financial cycle and closely related to it will be the business planning cycle. Again this puts load on certain managers and creates management stretch which reduces the capability of a business to adsorb business change.

Many organizations have seasonal sales cycles. Retailers, for example, will have peak sales in the run up to Christmas – changing retail systems or making business change during this period will not normally be allowed. To be fair, this is usually picked up, what isn’t always understood is the upstream effect of the peak period. The supply chain is full before the peak period as product is stockpiled ready for the trading rush. Therefore, the supply chain change freeze will start earlier than the retail change freeze.

Other industries will have their own cycles which need to be understood in order to create sensible migration plans. And there are other cycles such as recruitment cycles e.g. organizations that take on large numbers of graduates or schools leavers will have business cycles driven by school and university term times.

Next business events. Many businesses will have schedules of events such as price changes and marketing campaigns that cause localised stress on particular business areas and their supporting systems. These create what are effectively informal mini-change freezes throughout the year.

The next mistake that is often made is scheduling delivery too close to the change freeze. Changes must have time to bed down in the organization and systems often need to be stabilised. This should occur when processes are not under stress. Any fixes should not be severely time constrained.

The net result of considering business cycles and events is that the time periods when major changes can be released into the organisation can be very constrained. In addition, bringing in change before a peak in the business cycle can result in major benefits over bringing it in after. This means that we need to design releases carefully into the organisation’s calendar in order to drive maximum benefits. In turn, this means that we may need to compromise the solution from the technically ideal in order to ensure timely delivery. This compromise is best done in a planned way rather than as a reaction to schedule drift – i.e. rational compromise is far preferable to emergency surgery.