The Architecture Implementation Gap

Congratulations: your idea is agreed by senior leaders. Now comes the hardest part for the Entarch or Bizarch. Enterprise Architects are not responsible for the enterprise, the IT ecosystem, or even the IT staff who actually implement the architecture. Business architects similarly don't "own" the architecture of the business, the org chart, the process hierarchy, or the outcome of funding cycles.

The architects create designs, and they we try to get our clients / customers to agree to them, but we don't manage the project to build them (unlike a building architect). We are not the arbiter of what can or should be done in an enterprise... our clients are. We are not trusted enough to do that.

And there's the rub. That's what I call the "implementation gap". It's the distance between getting executive buy in for a direction, no matter how detailed, and actually delivering that vision in capabilities, processes, teams, software, data, and security.

Many years ago, I was a leader in the Enterprise Architecture team deep inside the bowels of Microsoft. Ballmer was in charge and his words carried weight. So at an IT all-hands, I stood up and posed a questions about complexity and overlapping systems, to which he responded as we thought he would: we should minimize complexity, reduce redundancy, and create consistent and clear data sources. I fed him the question, he fed me the answer. Dance complete.

I printed out his response and posted it on my door. I sent it to my stakeholders in management, all of whom either agreed with the sentiment or left the message unread. Did it make any change? no. It was nice to be able to say "even the CEO agrees with me" but saying that would not make any real difference when making detailed decisions under the umbrella of simplifying the infrastructure, to combine (or separate) processes, or to improve the collection and cleanliness of data. Lesson learned.

So what does work? We've seen interesting tools like Benefit Dependency Network diagrams that show strategy mapped to programs to projects to changes. That helps a little. But what really matters is something I mentioned up above: trust.

Trust is the point of all those EA artifacts. Trust is the currency that you cannot put a price on. If we are to "build a bridge between strategy and execution", as so many proclaim for Enterprise Architecture, then trust is not the mortar in that bridge... it is the stone itself. If you have the trust of business leaders, you can direct improvements. If you have the trust of IT leaders, you can direct implementations. You need both and you need that trust at multiple levels. The leaders have to trust you, but so do the junior execs, department managers, program managers and the project managers and the software managers and the software engineers and the operations team and the security team and the data team... and... and... and...

I find that some people are more willing to trust than others. This is a perpetual and ongoing concern in Enterprise Architecture. You have to answer this question over and over. How do you develop trust? Who do you earn the trust of, and how do you maintain that trust?

What do you say? Do you stakeholders trust you? How do they show it?