In part 1 I have discussed the essence of software architecture for agile development. Then I listed a few points that we should not do when we work on architecture for agile development. Here in part 2 of the series I am going to write about a few points that make architecture worthy for agile development. Architecture pays off for agile development
When the main concept of the software being developed is made clear to everyone including the architects. As we work for a future goal with small steps at a time, the bigger goal and context have to be clear, otherwise the implementation that we will do in the current or next spring may not align with the final goal.
When the architecture addresses precisely the problem and the viable solution and depicts the solution in the design diagrams. The architecture should modularize the problem and solution. The problems and solutions should be identified, modularized and prioritized and the diagrams precisely depicts the solution. This helps implement the solution fast and without any ambiguity. It also keeps the architecture relevant for agile development.
When the architecture finds answers to the open questions that arise during requirement analysis then the architecture is relevant enough that everyone gives importance to it. This is applicable for all types of development strategy. For agile development, as the development progresses we focus on the modules that have not been looked into in detail earlier. As a consequence we discover new problems. Architecture remains relevant when it has solution(s) of problem(s)
When architecture provides good guidance to the developers on what to build but not too specific to instruct how to build. In that way developers get a quick start that helps faster development. At the same time keeps an open end for the expert developer how best he/she can realize the solution in terms of code.
When a new product is built from scratch, we need the basic structure of the building blocks. How different components and modules will be connected to each other need to be decided. It's the job of architects to provide the building blocks as a guideline so that development can start with more focus and less ambiguity. At the same time we need to keep in mind that we should not take much time to come up with a structure and should not focus on detailing each module in the beginning, that will take much time which is not suitable for agile development. We need to have an idea on what can be done and what can’t be done though. There should be a balance between the both that will determine how much effort we should put in the beginning for architecture work.
When the architecture itself is used for work estimation, defining work packages. If the software architecture is modularized in such a way that work packages can be created according to the modules and different teams can work on the modules independently with less dependency it's a win-win situation. It helps development managers to organize their work. That makes architecture relevant for them.
When the architecture can correctly identify interdependencies amogh the work packages and modules This goes with the same line of thought as the previous point. It helps in planning and organizing the development work.
When architecture provides a common vocabulary that helps people describe and discuss the problem and the solution. Even for agile development people start recognizing its relevance in day to day work.
When the architecture itself can be reviewed by other architects and can be adapted when needed. Adaptation and change is core into agile development. The architects should also have the same mindset. The architecture should be extendable and adoptable depending on the current situation. As it changes frequently it also needs constant review.
When the architecture is futuristic enough so that it can be relevant and extendable in future. Agile development rapidly brings features to customers and it is also designed to act fast based on market and customer needs of the near future. The capabilities and functionalities of a product can change a lot in future. The architecture today should be done in a way that it can withstand the change of requirement and it can cater the future need to new technology available.
When architecture covers all required business goals. Generally for all kinds of development, agile or not, this requirement for architecture always exists. Otherwise, there is no point in coming up with an architecture.
When architecture addresses the quality topics. For agile development as there is not much time to think while developing. The development needs more guidance and a predefined and well thought framework that automatically ensures the quality requirements are needed. The guidelines need to be strictly followed while doing the development.
When the architecture solution or part of it can be reused for another software product. It helps agile development because we already have an architectural solution in hand which does not need much rework.
When the architectural solution is specific enough to address the main problem but not too specific that it can not be extended. This makes sure that the same architecture can be reusable for similar problems in other products and also can refine itself according to the future requirements.
When the architecture includes the industry best practices of product development and architecture guidelines. This is a generic requirement that is applicable even for non agile scenarios.
When the architecture of the product takes away the complexity of the system or makes it relatively easier to understand. Everyone who does not have much knowledge about architecture and know-how about the diagram notations also can understand and can draw a common understanding and overview of the software that they are going to build. Every team involved in development, management, operation, productization gets the bigger picture. It helps them to visualize and do their part of the job.
When an architecture of a product or part of a product is used for discussions and knowledge sharing. Lastly this applies for all architectures and all kinds of development methodologies. People can learn how a software product or parts of it works internally. People can use the architecture to discuss the development and refer to it or its parts in the picture.
I have put down my thoughts on what we should keep in mind when architecture needs to be created in agile development scenarios. In the two part blog post I have written what we should do and what we should not do while working on architecture of a product that follows agile development.