Organizational Governance — The Three Branches of Governance

Welcome back to my musings about organzational governance. Last week we took a look at the players (roles) involved and the implications on the technology. What I like to call the “narrower org governance.”

In this article we are exploring the “wider org governance” — what is the bigger picture of governance in your organization and how will that apply to your program?

We have defined the roles and have them assigned to the tool features as well as to the governance processes, we need to think about how we structure the org design for your program.

I will talk about “Content — Governance — Adoption” in a “Capabilities” article a bit later, but those three areas make or break the success of your implementation, and you need to establish governance functions so that the roles in your program (mentioned as Architecture Community in figure 3 below) can do what they are supposed to do.

Being fully aware that I might sound like an old Middle School teacher, but we will adapt an old concept to the organizational governance of the program.

• The main idea of an architecture program is to create content, and you will need to give direction and support — your Executive Branch function. This is mostly done by the Enabler role group above and might be structured as a Center of Excellence or as a “Guild” if you follow the Spotify model of organization.^ It doesn’t matter how you call it, as long as this group consists of people “who really care.”

• The second function is to define and maintain the shared rules (the Legislative Branch). This part-time group should be filled with architecture people who are a bit “nerdy” and will be able to analyze standards, reference content, framework, etc. and apply this to your program. This reflects the fifth major architecture capability “EA Methodology” and will have a direct impact on the configuration of your tool. But, as always in life, my recommendation is to do this in moderation so that you don’t kill the creativity of the Users or overload them with too much formality.

• The last governance function is the Judicial Branch, the “referees” when it comes to the application of the rules. Typically, you see Architecture Review Boards in larger programs, and unfortunately, I have seen too many of those who became roadblocks for innovation by insisting on following the defined rules and standards “to a T”. They have become the “Committee of No” and since no one wants to play with unpleasant people, people vote with their feet and bring a big risk to an architecture program.

As figure 3 above shows, the three functions work together, and you will have to find the right balance between them and the actual community that they are serving (just with the three areas of successful architecture implementations). Unfortunately, there is no “one size fits all” approach, and you should define the players in these groups, as well as the names of the groups, according to your organization’s culture. Do not be “too esoteric” because that will reduce the adaptability of your program — nobody wants to be associated with the perennial loser in your favorite sport.

However, you can make the best out of this situation and be as transparent as possible in the design of these org units (map out their processes and define their overall objectives), and the communication about and from them. And just like any other program team, there should be KPIs that measure the performance of the three branches shown in dashboards, and if something doesn’t work out, then change things.

The last step in the org governance section now is to set up the org units that you have defined. This can be done in two ways:

• The onboarding of regular user groups with a standardized process and training, or

• The specific implementation of a “general”/“shared” governance or unit, such as a COE or an ARB.

I will cover the first scenario in a future article, when we discuss what to do to create a training/enablement program. I recommend adding the topic of standardized onboarding of new users or user groups to the program to your governance processes. This allows you to rationalize the roles that you might need, specify what you expect them to do, and how you can support these activities with systems, automation, and visibility (dashboards and reports). Remember that they are most likely in the contributor role category from above and do not understand completely how the show is run, but rather just perform their part of the bigger picture.

For the second scenario, I cover an example of our favorite governance entity — an Architecture Review Board.

A few years ago, I worked on a large transformation project with a global organization and helped them define an architecture capability and implement it following this approach(-ish). However, when it came to defining the organizational governance they were not happy about having an ARB, since they already tried this a few years back, and it was the “Committee of No” and everyone involved hated it.

I was able to convince them to establish the three types of governance orgs that we just discussed, and they decided to give an ARB another shot, but wanted to have a low-touch approach to it. Based on this, we developed a four-step approach to the maturity of this org unit and also established clear rules on how to run the ARB.

The four stages of the ARB evolution were:

1. Communication — providing a forum where the different parts of the organization that were tasked with implementing the transformation could meet regularly and exchange information about what the individual projects do, what their objectives were, and what they were implementing from a technical perspective. We defined a core group of ARB members and developed a schedule for individual projects to present. Everyone in the transformation program was allowed to attend, and we also streamed the meetings via Teams, so that remote workers could collaborate. This allowed, after a period of curiosity where people checked if the new ARB was not just like the old but rather a true new approach. This enabled to exchange information and, over time, lively discussions about the right way forward and what to use from a tech perspective.

2. Standardization — the first step of my engagement with that client was to do an EA Maturity Assessment, and it became clear fairly quickly that they did not have any standards in place and groups just saved whatever they needed wherever they saw fit. They also used different notations (or none) and did not have a shared understanding of which artifacts should be included in a Solution Design. As part of this phase, we defined standards (just a few) and prepared for the purchase of an architecture tool, which would then come with a whole set of technical governance and would further standardize artifacts in one repository for enterprise-wide analysis.

3. Decision-Making. The phase that everyone was fearing to bring out the worst out of Board members, and everyone was afraid that it would evolve into the “Committee of No” again. But you know what? We never reached this stage. One premise of the ARB set up was to stop at a level where everyone would be comfortable to move on. And the client was happy with the collaboration that they had so far, and decided to deal with exceptions, changes, and roadmaps in the collaborative format that they had established. Decisions were made by all involved (even the “non-core” members in attendance) and that worked out very well.

4. Quality Improvement — In this stage, the ARB characteristic changes from the place where you have to do your “sing and dance” to a true helping organization. The ARB helps new projects to get off to a good start by sharing content knowledge and help them through “the process”. It transforms into the “Committee of Know”.

Evolving the participants and the committee was a very delicate dance that required a lot of communication and clear guidelines to build the trust needed to proceed. And at any point the committee was allowed to disband itself if the outcomes would not meet the expectations.

For the first phase, we established these “rules”:

• Architecture review board will have regularly scheduled bi-weekly meetings.

• Project teams will request to be included in the agenda in advance.

• Project teams will provide the appropriate materials for each checkpoint.

• The architecture review board will determine if a project is exempt from the review process.

• Architecture review board may require project teams to follow up on questions or comments after meetings.

• No approvals/rejections will be incorporated in stage 1.

• The scope of the architecture review will evolve to meet the IT and business needs.

• The Architecture review board will not be responsible for managing the project portfolio.

As you can see, we defined steps in the development process when projects should check in with the ARB (visualized in figure 5 below).

Having those clear defined rules for the ARB operations and following up with them transparently allowed the ARB to evolve to a level that “felt right” for the organization. This created the trust needed to bring all projects into the fold without having to set up organizational “orders” that let the first attempt fail.

When implementing governance organizations in general, you want to ensure that you understand where the people are, what their motives and expectations of joining such a group are. Then tailor an approach similar to the ARB example above that allows building trust while keeping as far out of the project’s businesses as possible, and have them have the responsibility (and authority) for their implementations.