How to decide on architecture for your company, with no fear — part 4

So I published the document, now what?

In the previous articles, I wrote about the process of researching, building, and publishing architecture in the organization. I explained the considerations before even thinking about the technologies, who are the people in the organization who should be partners in the process, and the correct execution process, in my opinion.
In part 3 we covered the architecture document's writing, the project's structure, and publishing it in the organization.
Although it seems that at this point the work is finished, there are a few more things that I think are important to do and take into account after the architecture document is published.

Should an architecture team be formed, and what are its responsibilities?

Although we have determined and defined everything that is needed for the organization at the current point in time, it is important that we also think about the long term. For all our work not to go down the drain, it is important to build a technological support mechanism that will enable the execution of the architecture decisions.
The most correct way to produce such a mechanism is to establish an architecture team, which will be fully responsible for implementing, informing, and supporting the architecture in the organization.

Building an architecture team starts with choosing the right people.
In part 1, I wrote about the cycle of thinking that is important to produce before making decisions about the architecture. Among the members of this circle of thinking you can find technologists in the organization who are already familiar with your decision-making process from the beginning, and it is recommended to examine which members of this circle are available, able, and interested in joining the architecture team and accepting responsibility for it in the long term.
At the same time, as an architect in the organization, there is direct and continuous contact with the development managers in the organization, and it is worth consulting with them about who they think is suitable for such a task.
Senior developers can give great value in accepting responsibility and leading the architecture for the long term, and at the same time, young developers can develop and grow within the team, which will give them a sense of belonging and a very great responsibility towards the project and the architecture.

Once the team members have been selected, it is very important to define and explain to them the area of responsibility of the team.
Development managers sometimes tend to think that the architecture team is responsible for everything that is not the responsibility of the development teams, and it is very important to clarify the point that the team handles only issues related to the implementation and stability of the architecture. It is important to have a dialogue on issues that are in dispute, as a team responsible for the architecture, the responsibility also includes understanding who develops which part of the product, and being available to provide development support so that things are implemented correctly and according to the established standards.

It is very important to clarify that the team is engaged in the framework of the architecture, in the development of architecture-supporting services (design system library, build processes, tests infrastructure, etc.), and not in the development of the product itself.
Once there is an understanding with the other development entities in the organization about what is in the team’s area of responsibility, it is easier to manage the communication between the team and the rest of the organization.

Conclusion!

If we summarize the series of articles:

• In part 1 we talked about the considerations and preparations that are important to make before even starting to research technologies. Who are the people in the organization who are important to be involved in the process, and how to recruit them for the process?
• Part 2 detailed the process of choosing the right technologies, emphasizing what it means “right technologies”.
• In the article part 3, we detailed the process of writing the architecture document, the document sections, and the structure of the project, and I shared an example document.
• In the current part we summarized the process, and what is important to do to preserve and maintain the architecture in the long term.

After reading the article series on writing architecture for an organization, the bottom line you should take is that there is no such thing as one correct architecture or a correct way to determine it. Every organization has its needs, its people, different nature of work. All of these must be taken into account to adapt the right architecture to the organization, and it is important to do it in an orderly manner from the beginning, according to predetermined stages, to meet the goal and determine a clear and agreed architecture, which will survive and develop over time.

That’s all for this subject, let me know what you think. Happy coding! 🤓