IT architecture is a complex and important component of any organization and requires the collaboration of different teams and departments. “IT Architecture is Team Work” is a principle that emphasizes that planning and implementing an effective IT architecture requires a joint effort of different teams.
An important aspect of “IT Architecture is team work” is the need for extensive collaboration and coordination between teams. This means that teams must work closely together to understand the requirements of various stakeholders and ensure that the IT architecture meets all necessary requirements.
What are the IT architecture approaches for organizations?
What can IT architecture teams look like in increasingly agile structures? These definitions are based on descriptions on the topic by Stefan Toth. For further deepening I can recommend this article by him.
Classical Architect
In this classical approach the enterprise architects or the enterprise architecture board make the “important” decisions about the architecture issues. The role of the developers is limited to feedback and implementation of the corresponding architecture specifications.
Supporting architects
In this approach the focus of the architects is on support and mentoring. Architecture is a role which is often not fulfilled full time.
Architectural agents
One speaks of architecture agents when certain topics (SQL, .Net, data models, …) are accompanied or controlled by developers with special knowledge from an architectural point of view.
No named architect
Here (hopefully) the developers involved make and communicate decisions independently.
The Communication Components
Another important component of “IT Architecture is Team Work” is the need for clear communication between teams. It is important that teams communicate regularly to ensure that all stakeholders are aware of IT Architecture progress and challenges.
It is also important to ensure that the teams involved have the necessary knowledge and skills to effectively plan and implement the IT architecture. This may mean providing training and education to ensure that all team members have the necessary skills and knowledge.
We should document decisions in a traceable manner via so-called Architectural Decision Records. This topic of documentation in the context of digitalization is very complex. There are few approaches that are always valid, but the context is important here. For example, in a consulting and development company, it may make sense for these decisions to be stored in the repository, e.g. Github.
Architectural Decision Records (ADR)
An Architectural Decision Record (ADR) is a document that records an important architectural decision. These decisions are made by a team, including its context and consequences. ADRs have a lifecycle and will be used to document any decision related to the architecture of an application. We use ADRs to capture both functional and non-functional requirements that have a measurable impact on the architecture and quality of a software system. The collection of ADRs in a project form the decision log.
For those interested in the topic of ADRs, check out this resource on Github and Eltjo Poort‘s article on the topic.
It often helps to present ADRs as a story and not to be too technical, so that all stakeholders can understand the results. It is also advisable to include the drawbacks and the solutions not chosen.
Summary of IT architecture as teamwork
In summary, “IT Architecture is Team Work” is an important principle that emphasizes that planning and implementing an effective IT architecture requires the collaboration of different teams. It is important to ensure that these teams work closely together, communicate clearly, and have the necessary skills and knowledge to plan and implement a secure and effective IT architecture.
Recommended reading
For those who want to delve into the sources, I recommend the book “Procedure patterns for software architecture: combinable practices in times of Agile and Lean” by Stefan Toth.
Here is the link to Amazon with a reading sample and also a sample drawing. Please use this affiliate (sponsored) link. You don’t have to use it, but you can get directly to the book here.
“Process patterns for software architecture: combinable practices in times of Agile and Lean” by Stefan Toth.
For the communication component, I recommend the book “The Software Architect Elevator” by @Gregor Hohpe.
A german version of this article is here. I highly recommend reading the topic related to this, which is around the 5 Why’s.
