In Agile development we want to implement features fast as we want to minimize time to market. For that reason, we think there is no space for architecture work. We think architecture is a waste because it's time consuming and does not fit the sprint style of development. We need to recognize that the way we think of architecture has to change when we talk about agile development. We can not make a state of the art architecture of a big software product ready and then start developing. First, we need to design the building block of the software and define the interfaces of various components. The architecture should be done such that we can divide the whole software into small pieces of modules. Then, we can focus on the modules which provide the core features and functionality. We need to keep in mind that the architecture can be extendable. This way we can be ready with the minimal architecture within a short time and start developing the modules for which we have finished the design. While some modules are being developed we can design other modules.
As an architect we need to ask ourselves what could be a waste in the architecture so that the time and effort we put in designing the system is worth it.
We can think of what is the right way to approach architecture for agile development. It can be a list of Do’s and Don'ts. Here I have put together a few of the points that make architecture work as waste for agile development. A lot of them are even true whether or not we are doing agile development.
Architecture is waste:
When No one follows it, you make the design but the development team and other architects and internal stakeholders do not follow or use it when they discuss the product. Remember architecture diagrams are also something to point at during discussion and explanation. Especially when doing agile development you need to focus on a part of your big plan. You need to have a blue print, otherwise your development can not be easily extendable. Proper architecture will make us focus on those modules we would like to develop now we can easily abstract the other modules.
When the technology that will be used or the environment where it will be deployed is not clear. In that case you can not make architecture decisions that will hold true for the future too. Even in agile you need to have a futuristic view. If some decisions are not well thought off, then that can prevent your software from extending. This is the task of the architecture, software has to be designed such that it can be changed or extended in future.
When the cost of deployment and ownership of the product is higher than the expected revenue. For example, you choose a costly Database or Infrastructure as a service (IaaS). Later, you may find that new features or applications can not be supported by the existing setup.
When it reiterates what is well known to everyone working in the organization or your area of work. Then, we can just straightaway focus on development.
When we accept too many tradeoffs in the beginning without being unclear about the consequences. A tradeoff made today can be a blocker for development tomorrow.
When the prototype only addresses a small part of the functionality and is tested with a small group of stakeholders. Again this can hinder future development of the product because the prototype did not address a problem that we would like to build in future.
When you fail to understand the main requirements. This is true in general not only for agile development. In Agile it means we need to take many steps backward and correct your mistakes. That means we lose time.
When the architecture does not take boundary conditions into account. Boundary conditions are important to narrow down the scope for the current sprint. At the same time keeping the possibility for future extension.
When the architecture of an existing system is not updated according to the changes that happened afterwards. It makes the architecture outdated. At a certain point of time it becomes difficult to make an informed decision by looking at the current state of the product because the design differs largely from the living system. We can no longer have a blueprint of the living product that can be referred to and examined.
When the documents of the architecture are difficult for the stakeholder to understand. This is true for agile and non agile development. An architecture that is difficult to understand makes room for misunderstanding and errors.
When the design is very generic and high level that you can't follow it when you want to develop. In Agile development we need to develop fast for that we need the exact architecture without guesswork that can be implemented right away.
In the second part we will see what are the Do’s or what should be done for software architecture for agile development.
Comentarios