Agile software development methodologies are now widely accepted and utilised within the software development industry. There is however a lot of debate on how to perform effective and efficient software architecture within an agile environment. In an non-Agile environment there is usually a lot of architectural discussions and decisions are made at the beginning of a project, practice which is discouraged in an agile environment.
So the question remains, how do you ensure that your architecture addresses the business requirements whilst keeping up with the agile practices. One of the 12 principles of the agile manifesto says that “the best architectures, requirements and designs emerge from self-organising teams”. I believe that this is the key to incorporating software architecture into the agile development approach, self-organising teams..
An Agile environment involves shared responsibility. The traditional role of the architect, as the one who defines the high-level solution, is diluted. The software architecture is performed by the entire team. This practice does not remove the need for a software architect, it just means that the architect contributes to the discussion with a broader and probably more experienced perspective, nevertheless all members of the team contribute towards the architecture of the software.The whole team participates in discussions and understands the consequences of design decision as they are made and, more importantly, these design decision are constantly evolved and evaluated.
Most of the architectural challenges are tackled by including them in iteration reviews, stand up meetings or any other development meeting. These discussions usually include lots of charts, diagrams, white boarding and other techniques. All of which helps to understand architectural challenges and to cement agreed solutions into everyone’s minds.
The Sashimi approach
There are several approaches to incorporate software architecture into an agile framework whilst keeping with the Agile principles of high customer involvement and feedback, continuous delivery of working software and attention to technical quality, amongst others.
One of these approaches is called Sashimi. In this approach the focus is on velocity. Instead of developing an architecture focused on tiers and layers you build the minimum amount of code that is necessary to connect all of the parts of the software and start building the actual functionality, which provides an early delivery of the software and enables the development team and customers to experience the software very early in the development process.
As the iterations progress the implementation is incrementally completed following the needs of the functional parts of the software, the business requirements. When performance and load tests are performed there is the opportunity to further tune the original design.
To be able to support this incremental approach to software architecture, the key is to implement well defined APIs over a “very” decoupled code, If the implementation details are moved outside the API, coupling with its consumers, then it becomes very difficult to refactor the architecture. Therefore it is key to have a well defined, decoupled API which will enable the Agile’s incremental approach. That is why API development is a key activity early in the lifecycle of the project.
Developers and architects that are not used to Agile development usually say that a detailed architecture design is necessary up-front because it is too hard and costly to change architectural building blocks once they are in place. The Sashimi approach deals with this argument and enables software architecture to be fully implemented into the Agile environment.
Reference: The Architecture Journal #23 pg. 13.
