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.