Architectural work in cross-functional, agile teams Do we still need software architects?
Every day and every hour in which software is developed, architecture is created-whether it was intended that way or not. But if architecture is created simply like that, then you don’t need software architects-or maybe you do?
Companies on the topic
Architecture inevitably arises in software projects, even in agile projects.
Today, most software development projects operate in an agile approach. Agility is described by the agile principles:
- Individuals and interactions are more important than processes and tools.
- Working software is more important than comprehensive documentation.
- Cooperation with the customer is more important than contract negotiation.
- Responding to change is more important than following a plan.
Cross-functional teams develop the software. Cross-functional means here that the software is designed, developed, tested and put into production. And of course design means that architectural work is done. And since agile software development means developing increment for increment, it also means that the architecture is created increment for increment.
What is architecture?
When independent teams develop software, architecture emerges. But usually several teams are working on a software project. How can you ensure that these teams can work as independently as possible? It must be guaranteed that the software works as a whole – that is, that working software is created.
At the same time, however, this also means that comprehensive interface documentation is needed so that other teams can use these interfaces. Software architecture arises during development, but many teams need to be synchronized during development. Where does the architecture come from and what is it actually?
Different levels of architecture.
(Photo: Dr. Annegret Junker)
According to ISO/IEC / IEEE 42010 2011, software architecture encompasses the functional concepts or properties of a system embodied in its environment in its elements, relationships, and in the principles of its design and development. The system can be a simple application, a complex enterprise application or even a whole landscape of enterprise applications. Architecture “happens” on different levels.
Enterprise architecture or Enterprise architecture is an architecture that is driven by the business. Business capabilities are broken down into functions and these in turn are assigned to applications.
Normally, the system architecture is seen as the architecture of the different infrastructure components such as loadbalancer, proxy server or event and trade fair brokers. Each of these components plays a role in the respective applications. But from the point of view of a function, they are not visible. Therefore, a system architect must integrate these components into the applications in such a way that the non-functional requirements can be secured.
Normally, the system components are distributed components. So they don’t belong to a team. But they have a direct impact on the functionality of an application. Therefore, there must be someone who accepts the requirements of all teams and implements them within the scope of possibilities.
Since the solution architecture – as its name suggests-has a direct influence on the solution, it must safeguard the functionality of the application. Usually several teams work on one application. You have to ensure the independence of the individual teams on the one hand, but also the end-to-end functionality of the overall application on the other.
The solution architecture of a team will change over time. However, it must be ensured that other teams are not negatively affected by these changes.
Architecture – solution of contradictions
Working software also means that teams are set up in the same way as the software we want to get. Conway’s Law tells us that the emerging software structure corresponds to the organization that develops it. But this also means that if the teams have to be cut like the software that is to be preserved, the architecture has to be predetermined to a certain extent.
This contradiction can be countered by the difference between tactical and strategic design as defined by Eric Evens with the domain-driven design (“Domain-Driven Design: Tackling Complexity in the Heart of Software” by Evans, Eric J., ISBN: 8601300201665). Tactical Design takes place within a team. The team develops its own specific question to describe its object of development. Strategic design takes place across teams and defines the domains-and thus the team boundaries.
The once defined team boundaries also change and require regular review and possible correction. But you have to realize that team changes are change processes that require close support and reduce the overall speed of development. But not bringing about these changes would mean that the software does not meet the requirements in the end.
Levels of architectural work
Architectural work takes place on different levels. These levels take very different perspectives on business functions and technical infrastructure.
Types of architectural work: Corporate architecture, Strategic Design, Tactical Design and System architecture.
(Photo: Dr. Annegret Junker)
The preceding figure shows the different types of architectural work that focus on the different levels of architecture. At company level, business capabilities are assigned to applications, using overarching models. On the other hand, the system architecture assigns infrastructure components such as loadbalancers and servers to business functions represented by applications.
System architecture focuses on the Basis of the Software Ecosystem and the associated infrastructure components. The tactical design focuses on the design of a solution and is usually handled by a team. The design – that is, the architecture-is created with the work within the team. The strategic design focuses on the definition of domain boundaries and the assignment of domains to applications and solution architectures. As already mentioned, the business architecture focuses on the assignment of business capabilities to applications.
Do we still need architects?
This question can be answered with a clear yes. Even though architectural work is spread over many shoulders, individual teams cannot answer the overarching questions that arise from both the system architecture as well as the strategic design and the corporate architecture. These questions must be answered comprehensively.
Dr. Annegret Junker (Picture: Thomas Wieland)
From a certain size, this can no longer be done by architects in the teams, but there must be overarching architects who perform overarching architectural tasks. However, these overarching architects do not prescribe the solution, but rather enable the teams to work independently and independently in their space.
* Dr. Anngret Junker is Principal Software Architect at adesso. She has been working in software development for more than 25 years in different roles and different domains such as automotive and FinTech.