The hype cycle vs legacy…

I am going to talk about a consequence of the hype cycle that seems to be missed by many. I will use an anecdote to illustrate the point…

Some years ago, I was engaged on a short assignment to review a new technology organization’s customer service programs. The company had grown rapidly in a new market that was now maturing. They had 3 customer service systems. They had 4 main customer groups served through 4 sales channels. Each channel used different business processes to execute the same activities and accessed all three systems. The IT solutions had grown organically with the business and were a mess! But now, with the market maturing, there were mainstream solutions from major suppliers that could replace these systems that were starting to constrain the business. However, the cost of resolving this, $15M, was seen as too expensive.

A few years later, the organization had lost its competitive position, had moved from number 1 to number 2 and was taken over by a foreign competitor entering the market. With a more complex product portfolio, more customer groups, a more complex sales model, the customer services systems were now seen as a major constraint to business growth. I happened to be engaged through another consultancy to look at the problem again. This time the cost of sorting it out had grown to $80M. Again the executive board decided that this was too expensive.

Recently, the organization merged with a major competitor. I heard that they had embarked yet again on a program to replace their legacy customer service systems. The market is now much more complex with many more products, it is also more competitive with tighter margins. The systems have grown in complexity since the last attempt to sort them out. I suspect the cost this time will be $150M or more. A ten times increase in cost in ten years. More importantly, the organization was the market leader 10 years ago but now it is in 3rd position with a likely drop to 4th.

The key point is that everything that you build before good practice emerges is likely to be poorly designed and poorly built. It should be thrown away and you should start over. If you don’t you will inevitably perpetuate bad practice. Future development will be compromised because time pressures to deliver tactical business change and the constraint of the legacy. And the cost of replacing it to deliver strategic business change will grow over time.

Sometimes I wonder why there is so much legacy. The answer is obvious if you overlay the adoption cycle with hype cycle…

So what are the lessons:

  • It is never too late to sort out your legacy
  • Don’t build on bad practice
  • The so called first mover advantage can be a handicap
  • Build knowledge before building solutions

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.