This is a Flickr badge showing public photos and videos from Chief Architect. Make your own badge here.

Search ...

Powered by Squarespace
« How to become an enterprise architect? – some observations… | Main | The Enterprise Architecture Network »

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 organization 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 organization’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.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (1)

A short postscript...

I have just participated in a program planning exercise. The sponsor's expectation for the first release delivery from the first project was 5 months. The raw effort based schedule showed 5 months. By working through the business calendar for the business units affected we delayed the start of the first project by a month, increased the timeline by 2 months and added a month congtingency. This was achieved with 100% buy in from the sponsor.

Result: a "safe" schedule that shouldn't be forced to make architectural and quality compromises to meet unrealistic dates. Given that it is the first project, it is foundational from an architecture perspective and it sets a precedent for the planning approach.

July 25, 2008 | Registered CommenterAlan Inglis

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>