Establishing an Architecture Council
The organization had just attempted the third rewrite of an existing system. This rewrite was once again not successful even with the amount of work, clear priority and desire of the organization to get the product delivered. Looking back at the trail of decisions that had been made to deliver the project it was clear that there was a gap between what the team was trying to accomplish with the technology and the quality of the decisions that had been made along the way.
One of the ways to significantly improve the quality of technical decision making is to create a forum for more formally talking about high level technical decision making. In this writeup I’ll be discussing building an architecture council to systematically improve the quality of technical decision making within your organization.
An Architecture Council is a forum to discuss in detail a high level technical approach. It can be instrumental in getting feedback on projects if it is structured properly as well as get quality input and alignment on technical direction. Membership in an architecture council should be clear and transparent to the organization. I recommend centralizing membership decision making here to the VPE or CTO to make sure there is good coverage of the overall organization. Any changes to membership should also be communicated in a timely manner and very clearly. Membership should be treated as a responsibility and time should be carved out for members to be able to prepare and fully participate. This is some of the highest leverage work that can be done in the organization and needs to be prioritized over work that may feel more urgent but less critical long term. Make the time allocation explicit to members of the council. I’ve found it helpful to have the group have less than 10 members. Larger than that and it becomes difficult to have efficient and effective conversations on topics.
One of the patterns which I strongly suggest avoiding is having the AC (Architecture Council) be composed of non-contributing architects. I find it critical for active contributors on projects to be the vast majority of membership. This ensures that there is a very grounded perspective on what challenges people are facing as well as connects back the discussion with the software delivery that is underway. If the group is not connected to the needs of the organization and doesn’t have credibility with working with the delivery teams, then it will be difficult for the feedback to be properly integrated into the development process.
There are two main ways to structure the AC group. This can either be advisory or as a decision making body. As an advisory group the team is providing a perspective and is giving feedback to teams. They are not making the decision, but depend on building credibility with the organization and influence to be able to get things done. As a decision making body, the council can and will make binding decisions for teams. This allows for quick decision making and a more holistic approach to architecture.
Typically I recommend going the advisory approach. This creates a set of incentives that keeps AC relevant to the concerns of the teams. It also allows the teams to own their architecture and the decisions. It can weaken the council if they lose faith from the organization but I find this to be better than decisions being made and handed out to teams without proper ownership of the projects. I’ve found a few ways to strengthen the connection via the advisory route.
The impact from AC comes from having a series of discussions. I typically have two types of meetings when I form AC. One series is the bi-weekly recurring discussions. The second is for technical reviews of projects early in the project lifecycle. The recurring discussion is for talking about relevant topics to the organization. This may be about what tooling the teams are using with Node, threat modeling, patching and upgrading, API design etc… The goal is to have open conversations to build perspective and alignment on how engineering is done within the organization. These discussions tend to provide benefits over the long term and are less relevant to the immediate needs of teams. The technical reviews provide a space for project level feedback for teams. A team can request these and get feedback on how they are approaching a project from an engineering perspective. Have the team submit materials in advance of the meeting so the team can have an informed discussion. It is also helpful if the team submitting has a few areas that they want to request extra attention to help focus the conversation to the needs of the team.
As a first practice I strongly suggest doing something like a technology radar exercise. The goal from a team perspective is to build the muscle for having a respectful and curious discussion around how technology is currently used in the organization. I’ve found technology radar to be fantastic for that as well as understanding how different teams think about and use various technologies.
This should set you up for a great start with the architecture council. Let me know it goes for you or if you have questions at brad@henricksonleadership.com.