When Traceability is a “Bridge to Nowhere”

One thing that many Enterprise Architects agree with: traceability matters.  If your job is to help the business to determine the strategic initiatives they should follow this year, the EA answer is to look to their goals and TRACE from their goals to their capabilities and, based on areas of weakness, TRACE to the initiatives that improve those capabilities.

The painful reality is that tracing from business goals may illuminate a decision that a business user is uncomfortable hearing.  For example, if a senior leader tells a general manager to “Solve Problem X”, and you are working with the team under that general manager, it is tough to tell that team that they are solving the wrong problem.  They really can’t handle that news, because they are not paid to question the directive.  They are paid to make it come to pass.

In this situation, traceability is a two-edged sword.  Traceability illustrates strengths, but it also illustrates weaknesses.  So if you ask the project team to tell you about the business goals, they will respond: the goal is to “Solve Problem X.” 

For the project team, there is no traceability above the directive.  No one can demonstrate traceability to anything that looks like business value or return on investment or business agility.  They are doing work because the big boss told them to.

The best that the project team can do is to try to find business value in “solving” problem X.  If there is far greater value in solving problem Y, and that simply makes problem X disappear, the project team will not be able to see their way there.  What’s an Enterprise Architect to do?

In those cases, you may be forced to do what I sometimes do: write down the assumptions that the team is taking, and NOT show your team how badly the assumptions trace to the business goals.  Just start with the assumptions and work from there. Your models will be wrong, but you will deliver output and build credibility.

Later, when you get a chance to present to the senior leader, don’t (just) talk about the (possibly wrong) results.  Talk about the assumptions.  See if he or she agrees.

To do this, you may need to produce many what-if models.  One that the project team has signed off on, and a couple that they have not.  When presenting to the senior leader, see if you can guide the conversation with the to consider alternatives, and then be ready to challenge the assumptions with real ideas.  You may not be able to convince everyone, but at least you will have had the conversation.  That is one of the most important things an EA can do. 

In this case, from the standpoint of the project team, traceability is not valuable.  If anything, it is counterproductive because it runs the risk of making them look like they are doing the wrong work.  But it is valuable in the end to make the enterprise successful.

Traceability matters to Enterprise Architects.  For some of our stakeholders, it is not valuable at all.  For a few, traceability is frightening.  For those stakeholders that won’t see value, don’t demonstrate traceability.  Traceability from goals to initiatives is a model that should not be shown to everyone. 

And that, unfortunately, is one tradeoff of being an Enterprise Architect.

Comments

• Anonymous
  January 23, 2010
  Splendid! It perfectly decribes the main task of an Enterprise Architect, and it works very simple although it sometimes takes months because of the size of an enterprise I disagree with your conclusion though; aren't we here to sometimes protect the customer from himself? The other day I proved a CIO to be wrong in assuming that SOAP would solve his interoperability issue. That was risky and took great care, but well worth it - as an EA I leave the trade-off decision to be made by the customer, not by myself

• Anonymous
  January 24, 2010
  Hello Martijn, I'm not sure what part of the conclusion you disagree with.  It sounds like we are in agreement about the majority of the post.  I think you DO tell the customer the truth... but it is important to know who the customer really is.  You may engage with a project team that is trying to develop a roadmap, while the customer is the senior executive.   You don't need to show every possible model to the project team... just the models that they are asking for.   But if there are additional models to show to the customer, ones that can help him or her to make better decisions, you would ALSO show those models. It's not a zero-sum-game.   --- Nick

• Anonymous
  January 26, 2010
  I agree that traceability is important. However the main reason it is so hard to achieve this goal in most systems is because of their complexity. Once a system exceeds a certain level of complexity, it is hard to see any relationships between the original goals and the technical features being planned. This is another reason why we must start with breaking down the complexity of the overall system. Then worry about the business goals and the traceability.

• Anonymous
  January 26, 2010
  The comment has been removed

• Anonymous
  January 28, 2010
  The comment has been removed

• Anonymous
  February 03, 2010
  While your post focuses on the topic of, and difficulties of Traceability, I think you actually raise the issues of Engagement and Alignment.  While you state that the job of the Enterprise Architect is to help the business determine the strategic initiatives to pursue, your scenario implies more of a reactive relationship.  Since a fundamental role of Enterprise Architecture is to align Business and IT objectives and initiatives, a relationship where the Architect is engaged early in the process makes it possible to limit or even avoid Traceability gaps.  To extend this to your illustrations, Panel 1:   Enterprise Architect:  X is a problem Big Boss: Tell me why. Panel 2: Big Boss: Solve Problem X Manager: I will do that. Panel 3: Manager: Solve Problem X Project Team: We will do that. I realize that Enterprise Architects may not always be engaged in the Project Ideation phase, but engaging them after project initiation seems to undermine their value and position them to be considered ‘idiots’, even by the Big Boss.

• Anonymous
  February 03, 2010
  Scott, You describe the correct, and ideal, scenario.  I was cautioning against those scenarios that do not fall within the ideal, but still often occur.   You are completely correct in stating that EA, in this situation, is far less effective.  But, alas, in many organizations, including ours, we sometimes stumble upon the train wreck in progress rather than before the fact.  In those cases, telling the conductor that his train has left the tracks is not effective.  That's my only point. Good response.  Thanks for pointing out this important distinction. --- Nick

• Anonymous
  March 04, 2010
  The comment has been removed

• Anonymous
  March 05, 2010
  The comment has been removed

• Anonymous
  March 07, 2010
  The comment has been removed