As advocates of agility, we could see this common definition of software architecture as potentially problematic.
In this article, we will be investigating how agile software development teams can handle and integrate the important aspect of software architecture. First of all let us define the term, starting with the more traditional (i.e. non-agile) definition that software architecture is a “Group of principles and constraints about how software solutions have to be built within a given boundary”.
As advocates of agility, we could see this common definition of software architecture as potentially problematic. Constraints and boundaries; these two words already entail a rigid structure, rigidly describing the functional and non-functional requirements of a software system. In traditionally managed software development projects, these requirements are practically engraved in stone, before any development starts, and are not changed until the development ends. As a rigid structure, such a software architecture is extremely sensitive to changes, due to the nature of its rigidity. But as agile software developers, we want to be able to move fast and embrace change.
A traditional linear software development process
There is no denying that certain constraints and boundaries are helpful in defining what we want to build. But for our agile purposes, we need to be able to remove their rigidity, so that we can adjust them during the course of our project. How can we transform traditional software architecture into agile software architecture? Remembering that, in agile, people are more important than processes (see the agile manifesto, at http://agilemanifesto.org), it becomes clear that to do this, we need to look at the role, the person, who creates the software architecture, namely the software architect.
The traditional software architect analyzes the software requirements of the planned system and makes technical decisions based on these requirements. He needs to be able to see the bigger picture, especially regarding the system’s future operation. He might need to know and heed compliance regulations and he also needs to be able to produce design documents. Usually, the traditional software architect is not very involved in the development, i.e. programming, itself. He might deliver the architecture and then move on, before the beginning of the actual development. A software architect who is not directly involved in a development project is unable to modify the respective software architecture if something in the project happens to change. Is this maybe one of the reasons why traditional software architectures have been so rigid?
In agile, the teams and their cohesion are important. If a traditional software architect is not involved in the actual development of the software, then how can he be integrated into an agile development team? Well, most software architects are experienced developers who have been promoted into the new role. This means that they possess the necessary skills to develop software, even if the new, traditional role of software architect does not really require this activity.
Looking at an agile team, we could embed an experienced developer into the team, name him “agile software architect”, ask him to design a software architecture with the team, while also asking him to stay in the team and develop the software with us. As he stays in the team and experiences development firsthand he will get a feel for the project and the software, will receive direct feedback, and will be able to adjust and modify the software architecture. Thus he is able to create living documents for an agile, sustainable software architecture.
This agile software architecture can then be applied and ported over into agile artifacts such as Scrum user stories, creating and updating them as required. As with the remainder of an agile project, this is an iterative process. The agile software architect continuously monitors the possibly changing requirements and helps the team align them with the possibly changing technological situation, all in discussion with other agile roles such as the product owner. The architect thus advises and mentors the team, enabling it to jointly determine its software architecture. He still needs to see the big picture, but he also needs to align it with what is happening during the ongoing, iterative development process.
We say this because it is important to consider that an agile development team is a self-managing team. An agile software architect is no team lead or team manager, even if he may be more experienced than the other developers in the team. What traditionally were technical decisions should be communicated as recommendations and discussed with the team. We need to remember that this is a collaborative effort that no one team member can dominate or do on his own. The agile principle of creating working increments, i.e. functional prototypes actually enables the software architect, and the team, to make more informed decisions by allowing them to see how they affect the system.
So when does an agile software architecture begin? As early as possible! As soon as the first user stories are made available the team should jointly see how these requirements translate into technical software requirements. This process could refine some user stories while putting into question the feasibility of others. Just don’t postpone your actual development because you don’t feel that your software architecture is not ready. Rather, see its design as an ongoing process. Some teams also have a basic reference architecture, which they adapt as the project runs its course. Keeping your agile software architecture as simple and lean as possible enables its easy application, communication and modification. These three points are immensely important when using agile principles in your software development process.
To conclude, we can agree that good software architecture is vital for software development, be it agile or traditional. However, in an agile software development process, this architecture is never really finished, while in a traditionally managed development project it is rigidly set in stone, at the beginning of the project. Moreover, we recommend that the role of software architect be adapted to the agile process by embedding him or her in the agile development team, allowing for first-hand experiences and team feedback to influence the ongoing software architecture design process. Lastly, we need to mention that a lean software architecture is vital to achieve a smooth agile development process.
Published on Java Code Geeks with permission by Daniel Hugelmann, partner at our JCG program. See the original article here: Software Architecture in Agile Development Projects Opinions expressed by Java Code Geeks contributors are their own. |
