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.

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

Cutter Report - How to Measure Success: Use EA to Define Architecture

I have just read the Cutter Report by Michael Rosen on the success or otherwise of enterprise architecture. 

Here are some points that struck me as interesting:

"77% report that they have architectural models representing their current state. Somewhat fewer, 56% report that they have models representing their future state. This could indicate that many organizations have more of a focus on managing complexity, which requires a good understanding of the current state and less focus on alignment/strategy."

"organizations with a disdain for agile (no integration) report the highest percentage of overall EA effectiveness"

"37% of EA organizations have no way to measure EA success"

"6%, have a mature and well-established program"

There are many more interesting insights into the current state of EA but I think I would get in trouble if I relayed more of them...

The over-reaction architecture governance anti-pattern

There are a couple of avoidable behaviors that architects sometimes adopt that generally annoy project teams. 

The first is “nick picking” – identifying an apparent issue and then drilling down into it to minute detail.  It appears to be an exercise in demonstrating how clever the architect is and how dumb the project team is.  The effect often is the reverse.  It tends to destroy the credibility of the architect as a business steward that is safeguarding the interests of the enterprise.

Architects do develop a set of useful instincts that allow them to “sniff out” issues embedded in designs.  But unfortunately, some architects act like the dog in the park that gets a whiff of food and very shortly afterwards is seen tucking into a stranger’s picnic hamper. 

The second behavior is "panicking about nothing” – hearing a rumor of non-compliance and initiating large scale projects reviews, post-mortems and escalations.  Often the scale of the intervention is excessive leaving the architect having to justify why it was so important to “cry wolf”. 

This behavior is a symptom of architects being disconnected from delivery.   The solution architecture will be wrong because it is based on limited information, the project will discover awkward facts that change the original solution.  Formal and informal feedback are necessary.

A disciplined approach is necessary to avoid these anti-patterns…

The first rule is focus on what is important – architectural governance must begin with a triage process that identifies high risk activities.  Restrict governance to those activities.  Yes, you will miss stuff but it is the less important stuff.

The second rule is advise.  You have seen the issue coming through the triage process, so give the project the right advice up front so they don’t make the mistake.

The third rule is support.  When the project team gets to the critical activity, be there!  Make sure they understand your advice and, equally important, that your advice is still fit for purpose.  From a process perspective, there needs to be a mechanism for projects to provide feedback on their decisions.

The fourth rule is communicate.  Write it down - an architect’s instinct should be captured as a principle, a policy, a guideline or  a standard.  The triage process should be documented.  You must get the knowledge out there, continually – do you have an ongoing communications plan?

The fifth rule is be humble!  There is never a need for arrogance.  The project team are the people that give architecture worth because they are the ones that deliver.  You have succeeded when you have helped them deliver business value.  You need their goodwill.

Eduardo Jezierski: Architecture, Mobiles, and Health: 10 Pitfalls

There is a good summary of Eduardo Jezierski's blog "Architecture, Mobiles, and Health: 10 Pitfalls" J.D. Meier's Blog.  The summary is excellent and stands alone if you don't have more than a few seconds to spare.  If you have a few minutes and want to think things through then the full blog entry is well worth a read.

Picking up the pieces...

Thank you to Karen Lopez for finding and praising a blog post by Anith Sen.  He writes about database design errors, Karen disagrees with some of Anith's conclusions in her blog which goes to illustrate that design is a mix of art and science and that even experienced practitioners will disagree over details.  

Anith observes that "an application can trespass on the field of data management" and that developers sometimes "treat the database as being a mere component of the ‘application domain’".  Particular skills and experience are required to manage data and to create and maintain databases.  Data management differs on at least two levels:

1. At the programming level, being able to write an SQL statement is not the same being able to design a database.  The set based thinking required to develop design a database effectively is very different to the procedural thinking required by most programming languages.
2. Databases have a different life-cycle to applications and they are often shared between applications.

In my previous blog, Vive la différence, I stated that we do not train people in design.  I think this is a illustration of this point.  We often don't teach an understanding of data management and its approaches.  This results in designers and architects having a poor understanding of the role of databases in the application landscape and people like Anith having to pick up the pieces.