Approach to team discussion among architects

The article turned out to be long, so I split it into 2 parts. In the first part, the focus is on the importance of abstraction from specifics at the beginning of problem analysis. How to turn the discussion into a constructive channel and get the most out of decision-making. In the next part, I will try to describe what to do when the requirements are agreed internally and the discussion returns to the decision, and what to do if there are several equivalent solutions.

Part 1

I think many of you have worked in a team and have faced heated discussions when making a decision. Usually, there is a person in the team who has the final say, for example, the tech lead. But sometimes there are disagreements that are quite difficult because the team consists of senior people, each of whom has many arguments why their opinion should be heard.

If there is only one architect on the project, then this problem is less pronounced in their work because there is an option, in case of equivalent solutions, to keep the last word to themselves. Not always their option, but it is important that there is an opportunity to stop the argument if it exists.

However, if there is a team of architects on the project, then an interesting game begins here. Even if there is a lead or a CTO among them, the decision is still an exhausting activity. Everyone understands that architects are specialists who know their job, and it is necessary to try to listen to everyone, but since everyone has a bunch of arguments for their options and in opposition to the opponent, a lot of energy is spent.

Once, I was in such a situation for a very long time and at one point, I got tired of it and started thinking about how to get out of it.

Let's start by looking at some situations.

Example 1. Which cloud is better to choose.

Architect 1: "Let's use AWS, the market leader (not anymore), we already have a dozen services there, we can continue to use them further."

Architect 2: "Let's use Azure, there are many interesting things that will help us, plus we have a lot of dotnet, and there are dotnet-oriented services. Or let's use Google Cloud, there is a native Kubernetes and GPU instances that we will need for machine learning. Plus, Google Cloud has convenient separation by projects, our company is not small, this will help organize the cloud correctly and conveniently."

Architect 3: "Why do we need the cloud, we have our own data centers, there is hardware, a bunch of services are already deployed and used in production."

Then a heated discussion begins, where everyone will bring 100500 arguments in favor of their options. And all options seem valid, right?

Example 2. Should we keep DTOs between layers within one microservice or refactor to only use external contracts and models?

Architect 1 - let's keep DTOs between layers.

Architect 2 - let's remove them, they don't add value.

Architect 3 - let's assess the situation, there's no need to make a decision now.

It's clear that these examples are too extreme, but I think everyone can imagine similar discussions on any topic, even outside an architecture team.

What's the problem?

The first thing that started to strike me systematically during these debates is that they are mainly centered around specific solutions or technologies. Each member of the team has gone through a thought process and has conclusions on the topic before the conversation even starts. However, each person's conclusions may be based on different inputs.

But why are the inputs different?

Because an architect usually works in partial uncertainty, and part of the requirements are set by the architect themselves. The same situation applies to the development team when they need to make an independent decision and have to create the requirements themselves. Examples:

• should we use Redux or MobX?
• where should we implement business logic, in models or service layers?

You can argue with passion for one solution or another, but the result will always be the same: the winner will be the one who either shouts the loudest or is better at selling their idea.

What to do when you can't stand it anymore?

My proposal is to introduce a specific format for decision making. This format should involve conflicts around requirements, not around specific technologies or approaches.

A conflict around requirements is what is primary and where truth is born. At the same time, any specific solution at this stage should be vetoed. It can be expressed, but first converted into a requirement.

For example, there is a proposal to use validation with annotations instead of a fluent interface. Let's try to express it as a requirement: let's do validation in such a way that it is strongly tied to the model. It is assumed that this is where the main and important discussion will arise, which should end with a common understanding of what needs to be achieved.

After the general agreement is reached, magic happens: any solution will approach if it meets the requirements (the requirements have already been agreed upon collectively, which means that the solution will also satisfy the collective).

Returning to examples.

In the first example, about choosing a cloud provider, in the new reality the conversation might go like this:

Architect 1:

"Let's use AWS, the market leader (not anymore), we already have a dozen services there, we can continue to use it further."

"We should make it so that after choosing a cloud provider, we have the minimum number of new entities, and we don't have to learn something new, because many of our developers have not worked with cloud providers, and if we exchange experience within the company, it will greatly accelerate us. Also, we can reuse solutions built on AWS by several teams."

There are 2 requirements here that can be directly recorded and discussed.

1. Limiting the number of entities to some level X. It would be good to derive this X.
2. Reusing solutions for the cloud provider within the organization.

As can be seen, having these requirements, other cloud providers can be pulled under them, for example by switching teams that use AWS to hypothetical Azure.

Architect 2:

"Let's use Azure, there are many interesting things that will help us, plus we have a lot of .NET, and there are .NET-oriented services there. Or let's use Google Cloud, there is native Kubernetes and GPU instances that we will need for machine learning. Plus, Google Cloud has convenient separation by projects, our company is not small, this will help us organize the cloud provider correctly and conveniently."

We need a quick start for .NET because it is our main development stack where there are many teams. We also need to take into account the availability of GPU machines to deploy machine learning. It is also important for us that the cloud provider provides convenient organization tools for teams, since our organization is not small, and it would be convenient for us to share and reuse resources between teams.

In this example, the requirements that should be discussed would be:

1. Convenience for .NET. It would be desirable to discuss what specifically distinguishes .NET, if, for example, docker images are already being used.
2. The ability to purchase GPU instances.
3. Convenience of organizing work in the cloud provider. Of course, with general agreement with the requirement, it would be correct to clarify this requirement by answering the question, what does "convenience" mean in the current context.

Architect 3:

Why do we need cloud, we already have our own data centers with hardware and a lot of services that are already deployed and used in production. We invested in our servers, and we have unused capacity. It looks like cloud will bring additional costs and we will not utilize the money already spent on hardware.

The requirement suggested by this architect is the prioritization of utilizing the existing free capacity, which in turn leads to cost optimization. This requirement is controversial and needs to be discussed, but if you look closely, all requirements are controversial depending on the context of the organization or project. Therefore, they should be considered in a specific context where their own truth will be born.

I hope the idea is clear from the description and examples.

The discussion needs to be shifted from the level of technology specificity to the level of requirements. All requirements from the participants' minds need to be made explicit. For someone, a requirement may be obvious, for others, it may be controversial, and for the third, it may be incorrect altogether.

I'll leave the second example to your interpretation of how it would be better to change the dialogue to come to a common understanding more quickly.