Architecture Governance: When you Disagree with Direction

Directions lead to a decision (selection). Decisions are implemented. Controls demonstrate that the direction was followed during selection and implementation.

Directions can endlessly cascade. Strategy decisions turn into Portfolio direction. Portfolio decisions turn into Solution Delivery direction.

One of the powerful features of good architecture is the ability to trace-back from an implementation decision to the original direction.

Architecture governance happens during architecture development, and during implementation.

Following & Enforcing Architecture Decision

Architecture decisions are embedded throughout your architecture. You will see them as Architecture Principles, a work package’s Implementation Strategy, or the Automation score on a Capability. Whenever you are developing more detailed architecture, you need to follow the directions and constraints embedded in your superior architecture.

When you transition from architecture to governing implementation, you need to enforce the decisions in the architecture. Using techniques like the Architecture Contract to provide clarity on the outcome expected and constraints on the implementers’ available choices.

You need to do this whether you were involved in the decision or not.

You need to do this whether you agree with the decision or not.

You need to own every decision in the architecture and treat it as if you made it.

It is simple to do all of that when you agree.

It is most important to do when you disagree. At those points you must defend the architecture decision. At those points you need to double-down on ensuring the architecture decision is followed.

The reason is simple – many architecture decisions and specifications exist to continually drive towards an outcome. Often that outcome is further down the line. Often realizing the outcome requires finishing every step. Making every change. We use the metaphor of building the complete bridge. Leaving the last 40cm (16”) out of a bridge’s road deck means every car will get stuck. 99.99999% of the work, at best 0.000001% of the benefit.

Many enterprise changes only become valuable at completion.

Steps to Help Do What You Need to Do

Start with recognition that you will not agree with every decision your stakeholders make. It isn’t a measure of your value as an architect.

You may need to deal with your emotions. You may need to process your own feelings.

It helps to explore the rational. What criteria did your stakeholders use? What alternatives were considered?

Then, own the decision. You can acknowledge alternatives, empathize compassionately with others who disagree—but own the decision. Providing clarity about the broader context and influences at play.

Anyone who has worked with me will have heard about Terry. There was a major decision in the scope of work pursued in the project that turned into our NA Construction Case study. There was a question whether part of NA Construction would be included. With a rapid transition from strategy to portfolio to implementation we had run ahead and included the division. I had acted as a stakeholder agent and spoken with Terry’s voice. When we met with the stakeholders to confirm the scope, Terry said no. He removed the department from scope.

With maximum irony, I was meeting with the stakeholders at the same time the implementation project was kicking off the work. We had brought people from across the country. I went from the meeting where I had passionately defended the inclusion to the kick-off meeting where I shut down the work. I spent time speaking with Terry’s voice. Listening to the exact same reasons I had used. Providing Terry’s answer and reasons. Then I monitored the project to make sure that Terry’s decision was followed.

I had the privilege of speaking with Terry's voice. It was easy when I agreed with him. The bargain of being a stakeholder agent required speaking with Terry's voice when I disagreed.

Yes, I had to regulate my emotions. I was coming from a meeting where I had passionately recommended inclusion. Passion to the point that Terry had told me I was on the line of going too far.

Yes, I had to use Terry’s criteria. I had to speak with Terry’s voice.

Learning from Disagreement

Whenever I have disagreed with Architecture Decisions, I recognize it is my fault. It comes down to two potential shortfalls:

• I used the wrong criteria to assess the choice
• I did not explain the facts effectively

Both are powerful learning and self-improvement opportunities. Terry, and my other stakeholders, have accountability in their organization.

I spend a lot of time reflecting on these points to work out where my assessment and communication fell short. When I disagree with my stakeholder most of the time, they are knowingly abandoning upside to avoid downside. They are de-risking. They are choosing more certainty. Terry was spending several years profits on the digital transformation. He was putting his job on the line. Potentially betting-the-company. He deliberately gave up a bigger benefit to ensure he got value.

One question for you this time. Do you reflect on the source of disagreement? Do you use these moments to improve the quality of your advice?

As always, simply reply with your thoughts.

Regards Dave

Dave Hornford
Conexiam