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

Search ...

Powered by Squarespace

Enterprise Architecture Blog

Discussion focusing on how to manage an enterprise architecture function successfully.


Head over Heart

I was asked by a consultant from one of the major analysts whether a consultancy should have excellent sales capability and average delivery or average sales and excellent delivery. Many consultancies follow the advice of this analyst and strive for excellent sales capability at the expense of delivery...

Some years ago, I was evaluating a number of suppliers to deliver a $100M dollar transformation program. As part of the evaluation, we asked the candidate suppliers to make recommendations on the ERP modules that we would require to meet our business needs.

Unknown to the suppliers, we had pretty much already decided on the footprint but were open to change. Our process had included defining the new business operating model, training the architecture team, working with the ERP supplier to define the solution, and using independent third parties to review the solution.

Each delivery supplier was asked to present their recommendations to us. They were also asked to provide additional details where we had options or concerns in our solution.

Prior to the presentations, my team had read the supplier proposals in detail and had picked out the wooly thinking, weak arguments, poor clarity, and inconsistencies and had questions to get resolutions in these areas. The suppliers were instructed that their teams must be able to answer questions in all the key areas that we had notified them on.

The different suppliers produced broadly two types of team. Some consultancies produced teams of "sales" consultants who were very slick, well presented, had good graphics, delivered high impact presentations with a simple clear storyline. They took questions at the end. We also had presentations from other consultancies that were less well structured, presentational skills were weaker, and the suits were just that little bit less sharp. They allowed questions during the presentation. These presentations were from the people who would deliver the solution - the people we would work with.

The "sales" consultants despite their presentational skills were a singular failure. They lacked credibility with me and my team. We would not be working with them and we would not want to work with them. They were too slick, too "professional", they were not "people like us", they were alien. Worst of all, under questioning, they fell apart because they were sales consultants with weak delivery experience. They gave dishonest answers that toed the company line rather than genuine professional and balanced answers based on experience. We were being sold to.

The other consultants performed much better. Because they allowed questions as we went along, we were able to engage in a closer way. The storyline evolved to some extent and was shared, we were given a small taste of working together. The consultants were more adaptable and demonstrated their delivery experience which gave us confidence. We were collaborating.

It was interesting to observe the reaction of some of my senior management colleagues - confusion. They had been sold to and liked the pitch from the sales consultants but had seen what had been exposed was a lack of delivery experience. Should they go with the track record of the major name with slick PowerPoint or with clearly demonstrated delivery experience?

This is classic heart vs head decision driven by the different approaches of the consultancies. What was clear in the subsequent debate is that as a client we wanted delivery excellence not sales excellence and the head won out over the heart. But it was a close run thing.

The only reason that rational decision making prevailed was due to intensive and detailed preparation by the architecture team followed by assertive reasoning. If we hadn't done this then we and the business that paid us would have been lumbered with picking up the pieces of a poor solution delivered poorly.


The emperor's new clothes...

There are a number of clients that I have worked with several times over the years.  Some of these organizations have gone through major business transformations that were led by traditional tier 1 consultancies that cost hundreds of millions of dollars.  It is interesting to contrast the before and after states of a couple of these organizations.

Example 1

Before - two legacy IT estates with no integration between them.  Development tools and infrastructure were "burning" platforms.

What was intended - modernization of one legacy platform, migration of other to modernized platform, decommissioning of legacy.

After - two legacy IT estates with integration between them.  Development tools and infrastructure were "burning" platforms.

Timescale - 3 years

Hidden costs - loss of business and IT talent.  Business still constrained by the legacy.

Benefit - a single business operation.

Example 2

Before - legacy IT estate with spaghetti point to point integration between them.  Development tools and infrastructure were "burning" platforms.

What was intended - delivery of ERP, migration of legacy to ERP, decommissioning of legacy.

After - ERP package grafted on top of legacy IT estate with spaghetti point to point integration.   Development tools and infrastructure were "burning" platforms.

Timescale - 3 years

Hidden costs - loss of business and IT talent.  Business still constrained by the legacy.

Benefit - more efficient head office operations.

In public, they are trumpeted by the consultancies and their clients as great successes because they achieved the major business goal.  Privately, these transformations are considered failures since they increased IT costs and reduced future business flexibility.

In both these cases, the business vision and the IT vision were sound.  The plans to deliver them were unrealistic and unreasonable from both a delivery and solution perspective.  There were many dissenting voices inside the organizations.   These people typically moved on or were sidelined.

So what is the solution:

Make sure that executive level management understand change is delivered at the working level not in the board room.

Make sure you can work with the consultancy.   The most important relationships are those between the consultants who deliver and the staff and management who deliver.  These relationships must be built on trust and be mutually supportive.

Take responsibility for delivery, don't abdicate it to a consultancy - if their plans and solutions don't seem to make sense then they may not make sense.  Grill them, tear them apart if necessary, get them to refine their plans and solutions until they hold water.  This is being constructive, it is being a team player, it is being on message.  If the consultants don't like then that is their problem, they are grown ups, they will walk away to another assignment leaving you or your successor to pick up the pieces.

Take responsibility for change, don't abdicate it to a consultancy - make sure they deliver the plans and solutions as promised.  If there is a need for change then make sure you really understand any compromises.  Consultancies manage to margin, make sure you have a contingency fund to cover changes.  If you don't you will be forced to make compromises that incrementally destroy the integrity of the solution in order to meet the major business goal.


B to A or A to B

I read some where that if you want get somewhere there are four steps:

  1. decide where you want to go
  2. make sure you know where you are
  3. plot a route
  4. and go!

This formula encapsulates one thing that I think is critical - that you don't think about the As-Is until you know what the To-Be is. 

Why is this?  The first reason is efficiency, you only need to know enough about the current state to be able to get out of it.  Another reason is that if you understand too much about the present then it will constrain your thinking.  You will look for feasible routes from where you are and almost inevitably take the path of least resistance.  The third reason is that you will almost always repeat the mistakes of the past as you begin to understand the apparent reasonableness of folly.

Focusing on the To-Be first frees the mind to be creative and create a stretch ambition.  The collective mind is then motivated to develop a better future and is much more prepared to meet and beat the apparently insurmountable problems of the past.

There is a corollary to this this is not clear from the formula.  When plotting the route, start from the destination and work backwards, i.e. right to left planning is best practice for migration planning.


"Correct" is a contextual thing...

Nick Malik in his blog "Correct" is a point of view makes the critical point that when we state that enterprise architecture is about "doing the right thing" we must not gold plate the process, we must aim to do a good job rather than a perfect job.

Enterprise architects often complain about the business direction being unclear.  As I stated in my blog, The Absence of Strategy, this should never be an excuse.  You can always derive sufficient context for any architectural decision to to be good enough.

In hindsight, many decisions seem wrong and have created a legacy.  But at the time they may well have been right.  The alternative of delay or do nothing may have been much worse.  Failing to meet regulation, delaying product release or missing peak trading could have much greater costs than unpicking the legacy of hasty actions.

Enterprise architecture does not need to be what Nick Malik calls the "ultimate BDUF exercise".  There are a range of enterprise architecture management styles that suit different organizational contexts

Sometimes these decisions could have been made better.  Why weren't they?  Absence of information is usually the answer.  We need to be out there listening, learning and informing for our point of view to be heard.  Decision processes exist, we need to be part of them rather than create new ones, we need to be part of the context of business decision making.


Architecture as diagrams is an anti-pattern!

Every now and again I rediscover what I think of as Enterprise Architecture ways of working anti-patterns.  These are not typical technical anti-patterns but ways of working that seemingly add value but in practice store up problems for the future.  I highlighted one in previous blog on complex diagrams.  There is another related anti-pattern that I find particularly annoying because it voids a significant amount of effort.

It is the misguided belief that the creation of diagrams is architecture.  They are a representation of architecture.  For architecture to be useful it must be actionable.  A diagram is not actionable, it is a visualization.  The specification relating to the blob on the diagram is actionable - you can build it, deploy it, assess it, review it.  A colored blob on a diagram is next to useless.

What makes it actionable? It is understanding and attributes. 

Understanding comes from using the correct representation of the information in a particular context.  Sometimes this will be a hierarchical set of diagrams that gradually take the viewer into detail in focused areas.  Other times it will be vast maps for those who know the landscape to rapidly move one part to another.  Sometimes you needs lists and tables, other times you need raw data for comparison and aggregation.  You need a detailed set of attributes.  This is the key, architectures must be captured as data so that it can be re-presented in multiple forms and analyzed.

There is often an excuse - "we don't have the tools".  Some architects appear to hold the view that a high-end enterprise architecture tool or nothing is the choice.  There are low price or no price modeling tools that will do a good job of modeling and capturing attributes.  A spreadsheet will enable you to do the analysis.  They give you an 80% solution.  A high-end tool will give you another 10-15%, but the reality is that you will spend 3 months configuring it to do what you want.  It will take you less time to get going using an 80% approach and it will be much cheaper.

Sometimes architects are very focused on the ideas and the creative part of the role - this is good and positive.  They are sometimes less interested in the mundane data capture and specification of attributes and the detailed validation of the ideas.  Ultimately, design and implementation will be required.  These require that you record your idea in its entirety with no implicit assumption that thought transference over time will take place.  If you do not then the idea will be misinterpreted, may be rejected, it will be changed and the conceptual integrity of the architecture will be lost.  It is not the implementation team that screwed up, it is the architecture team that failed to communicate.

Page 1 ... 3 4 5 6 7 ... 13 Next 5 Entries »