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

Drawing a line…

Early in my career, I was in a meeting where we were talking about a project. The lead architect drew a picture consisting of blobs and lines. The diagram was presented with certainty throughout and positioned the speaker as a key expert. Each blob and line was explained clearly except one…

I pointed at a part of the diagram and asked, “I think missed the explanation of one of the relationships, what does this line mean?” There was a disapproving glare and a sharp answer “there is a relationship!” The tone made it clear to me that the real answer was, “I was glossing over the fact that I don’t know and now you have embarrassed me!”

Perhaps I could have asked the question in a less challenging way. However, that aside, presenting certainty when there is none can cause serious issues as a project progresses and create and build on unacknowledged assumptions.

Sometimes, however experienced you are as an architect and however “strategic” you are in your work, sometimes it pays to get right back to basics. The issue often is how effective is our communication? In the communication of ideas through pictures and words are we being clear? If not then we fail, so it is right, sometimes, to go back and ask yourself whether you are getting the basics of communication right.

I read a book called “101 Things I Learned at Architecture School” by Matthew Frederick.  It is about the basics of “traditional” architecture rather than enterprise architecture but I was surprised how much I could get of the book and find relevant to what we do.

The first of the 101 “Things” is “How to draw a line”.  Just as in traditional architecture, pictures at various levels of formality are critical for communication.

You need to buy the book to get the specific advice however this page prompts a number of questions:

  • what does each line on your diagram mean?
  • do the differences between lines – thick, thin, colours, dashes, dots, arrowheads, etc. all have clear unambiguous meanings?
  • is the labelling meaningful and informative?
  • are you routing lines so they are easy to follow?
  • are they crossing?
  • are there too many blobs and lines?
  • do they take the audience from the “beginning” of the diagram to the “end”?
  • does the diagram tell a story?
  • when you sketch on a whiteboard, are your lines strong and bold showing certainty in your ideas?
  • are the lines weak indicating your lack of clarity?
  • do your diagrams leaving people nodding in confusion?
  • could your audience use your diagram and explain it to someone else accurately?

The most fundamental tool for an enterprise architect is the simple line. Are you using it right?