Who Drives an Enterprise Architecture Initiative?

Who drives an enterprise architecture initiative? Does it come from an enterprise architect? Maybe it’s a request from IT? Or perhaps it comes from a business unit looking to solve a serious and specific problem… Of course the answer really depends on the problem you are trying to solve. The reality is that any of […]

Related posts:

  1. The Road Ahead for Enterprise & Business Architecture With a new year upon us it’s always exciting to…
  2. Enterprise Architecture still delivers in recessionary times Enterprise Architecture (EA) increasingly covers a broader role in an…
  3. Invest in Enterprise Architecture now A recent video from analyst firm Gartner highlights the importance…

Related posts brought to you by Yet Another Related Posts Plugin.

Week 22 Enterprise Architecture Summer Camp (Day 2)

This blog post deals with the second and final day of the summer school dealing with Enterprise Architecture. The tagline for the summer school is “Scandinavian Design and Oblique Angles”. The day was characterized as a setup that was dominated … Continue reading

Week 22 Enterprise Architecture Summer Camp

This blog post deals with first day at the summer camp for Enterprise Architecture in Week 22 that was held in Denmark at the IT University of Copenhagen. The participants were mostly students. The tagline for this event is “Scandinavian … Continue reading

A week in Tweets: 15-21 May 2011

And it’s catch-up time again… not too delayed this time, though. A rather larger collection of Tweets and links this week – not sure why. Usual categories, usual comments or tags in italics, usual ‘Read more…’ link. As usual.

Enterprise-architecture, business-architecture, business-strategy, innovation and the usual stuff that goes around business big-picture:

bartleeten: Agile Architecture […]

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…

About 10 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.

SAM_0149a

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…

SAM_0156

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

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…

About 10 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.

SAM_0149a

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…

SAM_0156

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