There is a misconception that Architecture has no place in Agile methodology or Agilists don’t do Architecture. In my view there is no conflict between Agile and Architecture. In fact contrary to common perception, majority of agile teams perform architecture modeling in their projects. Architecture is an important aspect of agile software development, just like traditional development practices, and is critical for scaling agile approaches to meet the real-world needs of modern systems.
Architecture provides the foundation from which systems are built. It is the set of design decisions that must be made early in a project. It includes core technology choices, the overall high-level structure and solution for complex problems. Big up front design (bufd) typically addresses critical concerns but goes overboard. Having countless diagrams of classes and interactions before writing the code may not serve the intended purpose. A good architecture should be pragmatic, designed for test, modular, no unintentional redundancy and addresses performance, usability aspects.
In traditional development projects, we used to have ivory tower architectures developed by an architect or architectural team in relative isolation to the day-to-day development activities of project team(s). The isolated architects develop one or more models describing the architecture. These are very beautiful things, well-documented with lots of fancy diagrams. In theory, these architectures work perfectly. However, in practice they suffer from significant problems.
- The poor developers are unlikely to be convinced with the architecture because they had no say in its development.
- The architectures are often unproven. One big reason being the architects rarely dirty their hands writing code, and as a result are little cut off from the ground reality. They do not have the benefit of concrete feedback provided by a technical prototype.
- Overbuilding of software is promoted as the architecture reflects every feature ever required by any system that the architect(s) was involved with and not just the features actually required.
- Does every customer need all the magnificent features? The answer is no.
The ivory tower architecture approach however is not going to work in Agile projects.
Agile does not mandates the development tools/practices to be followed. I have seen that project teams take this as a blank cheque to avoid things like writing test plans, code reviews, etc. Another casualty is Architecture. While Agile is certainly a tool for a faster cycle time of products, but one should differentiate between Agile and impulsiveness. In a hurry to ship features, project teams avoid addressing the question of Architectural vision. Agile has always challenged people with the age old question – how much to design upfront?
Agile stresses on the Design Values of Simplicity, Continuous improvement, Teamwork, Communication, Trust and Satisfying stakeholder needs
Architecture is an important part of any project, regardless of its methodology; every delivery team needs to address solution architecture in some manner. So when and how do we work on Architecture in an Agile project. The project should start by defining an appropriate technical strategy. With discipline, the Agile teams should continue to evolve architecture throughout a project in an incremental fashion.
When an agile project starts, there is a pre-gaming phase. This is the Inception phase where you need to get the project organized and going in the right direction. Part of that is the initial requirements envisioning and architecture envisioning so that the critical aspects of project like the scope, cost, schedule, and technical strategy are taken care of. From an architectural point of view, the goal is to identify a potential technical direction for the team as well as any technical risks. At this point a detailed technical specification is not required. In fact creating such a specification at the very beginning can be a fruitless exercise. The initial architectural vision should be evangelized with sub-teams for feedback and subsequent evolution.
Agile teams work on features defined in a product backlog. In every sprint planning, a subset of features (user stories) is extracted to work upon. This becomes the sprint backlog. There should be pre-sprint story review or grooming meeting. This meeting should occur one week prior to the start of a sprint. The product owner calls this meeting and invites “senior chickens” (architects, user experience leads, development and test leads).
In this one week prior to sprint planning, the senior folks, working with the product owner, can groom the stories further. Improvements can be done by refining description and acceptance criteria, breaking stories into smaller child stories, adding constraints. The architects play a key role in this process. There can be Architecture spikes in sprints which can help in further refining of architectural vision. Radical changes may be first tried out in spikes before including in the system.
So, the key to a successful architecture is to work with development teams and update the architecture in an evolutionary manner. Take care that the final architecture document or artifact is not too bulky to act as a deterrent for anyone wishing to read it. In summary, don’t overdesign, don’t under architect. Architecture should aid in continuous development of features delivering customer value.
| Reference: | Agile vs. Architecture from our JCG partner Gurpreet Sachdeva at the gssachdeva blog. |
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design