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.
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
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
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.
Nick, thanks for the interesting post. I agree with Roger, it is the complexity of the systems we deal with that greats the challenge in producing traceability models.
Hi Roger,
You are talking about app portfolio traceability. My post is talking about project portfolio traceability. Different animal. Be careful not to throw out the baby with the bathwater. Traceability is extraordinarily useful if alignment is the among your goals.
Simplicity is a highly valuable goal, but not the only one that executives care about. We wear many useful hats.
— N
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.
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
I have a completely different picture in my mind yet so similar to what you describe here.
I am very often asked by projects and solution architects to approve the design or grant an exception (as a part of architecture governance). You can bet that when they come, their solution usually exhibits the following attributes:
– it is very "creative" and project like the idea very much (kind of a toy or pet in the project, you know, finally a chance to invent something)
– much more complex then a simplest solution that comes up first in your mind
– cannot be really justified against business
requirements
– project can beat you up with tiny details why exactlty this solution is the only one possible
– has no documentation of how the solution actually originated (via discussions, of course)
– has no alternatives analysed (and when you ask, then people invent two most crazy extrem alternatives and look at you as if you had two hads and are completely nuts to be considering anything like that)
– project has no time to rethink or change anything
Eventually, I observed the following in most cases where I had to deal with the situation:
– Different people tell you different problems they believe the solution is solving
– Very often, people already tend to mistake causes and consequences (they design solutions for problems, which were not originally there and where brought in by a particular idea. They stick to this feature later on and nobody knows anymore why it is there).
– When you finally identified the original problem (with business, business analysts, designers), you have no clue, why the hell they need such a solution?
If I use an analogy, it’s like solving and nit picking in whther the better engine is 1.4 or 1.6 liter for the car, while you actually just need to get from a point A to a point B. There’s hardly any evidence on how far A can be from B, how often you will need to travel, how many passengers etc. and no analysis and decision that a car is the best option. It’s damned difficult to bring people to give up their solution for a while and try to think about the original requirement in a transparent way.
Anybody’s got any tips and tricks for this kind of situations???
@Ondrej,
First off, I want to thank you. It’s Friday afternoon as I read your contribution, and you gave me a great laugh. You described a problem that every architect in a governance position faces all too often… how to tell the passengers on the train that (a) the train is going to a bad place, (b) they have no need to take a train, and (c) the guy laying the track is a complete idiot.
What to do?
The answer is painfully easy and painfully difficult at the same time: don’t wait until the very end to review the project.
You hit the nail on the head when you said:
"- project has no time to rethink or change anything"
What is time? It is money, of course. If you rethink something, you spend money. No one has that money in their budget, so rethinking is simply not allowed.
So you have to get to a project BEFORE the project is placed onto a budget, BEFORE money is allocated to it, BEFORE some idiot picked the solution to a problem that no one actually has.
You have to get that problem in the funding process.
Saying that is simple. Doing that is difficult.
It is difficult because the REAL power in IT occurs in the funding process, and the really powerful people know it, and they will NOT let you into the room, no matter how smart or talented or intelligent you are. Why? Because you are logical, and they know it (after all, your title says "Architect.")
Logical people find themselves quickly confused by many funding processes, because those processes have nothing to do with logic. You can provide all the data you want, but no one will look at it unless some senior executive INSISTS that the results of the process must reflect the data. (And even then, they will manipulate the data to support the decisions that they wanted anyway).
Fixing this situation requires a level of openness and communication between you, the person who sees the problem, and the CIO, the person accountable for the money being spent. He has to personally know you and trust you and let you tell him why his organization keeps spending money on really stupid things.
On your part, you have to produce data that shows that the projects that are NOT YET FUNDED are aligned, or not aligned, to business goals. Then you have to stick a copy of that data in some immutable format (like PDF) and store it in a safe place. When the wrong projects are funded, you need to come to the CIO and show him your data, and show him his project portfolio, and ask HIM to tell YOU why his organization is not using the data that he wanted you to produce.
The worst thing that can happen is that he will tell you that your data is not useful. At least you will know that he doesn’t care.
On the other hand, if he expresses surprise, hide. Don’t let him put YOU on the stage to point at his senior staff and tell them that they are utter morons for funding stupid projects. He has to be the one to do it. (Good leaders would never pass the buck, but I’m not assuming that every CIO is a good leader. Your mileage may vary.)
I hope that provides you with some insight. Get data on the proposals being submitted for funding. Then get the profile of funded projects. Pull them together to show that some really stupid projects are being funded. Then ask him if he wants to change things. See what he says.
I did not say it would be easy. Good Luck!
— Nick
@Nick
I was really worried that this might be the only way:)))) And I must admit that – as usually – you are quite right. Especially with the fact which I could not understand for a very long time and that is: how come that despite everybody knows it and all methodologies and best practices highlight it only very few projects (in our companies) have clear scope and a solid business case (if at all). And if a project manager tries harder, then any project can be sliced to phases (you know, just not to be a "big bang" however small this bang might be) and produce a salami effect, where each slice is a great success, but at the end achieving nothing really.
When I read this after myself, I sound a bit like Marvin, I must admit, perhaps just because it’s Monday;) On a good note, even in that case I succeeded twice in stopping a huge train and moving it to the right track, but the effort put into it was gargantuous.
At last, tracking an evidence of enterprise architecture being right and the others being wrong didn’t help me very much in the past since managers have either tendency to come and go or "not to care about the past mistakes but rather to focus on the future":) (The later one really drives me crazy:)
cheers
O.