Programming web applications and creating IT systems has long been a complex and slow job. Following the usual software engineering life cycles the development phase could not start before requirements were written, architecture was approved and a lot of Unified Modeling Language (UML) diagrams were drawn. So even before the project produced something of value tons of documentation was produced.
Due to the success of agile software development methods as e.g. scrum and devops often architects grown up with traditional development approaches, are experienced as a barrier for speeding up. So the role of traditional IT architects and architecture for creating solid design documentation has become under immense pressure.
One of the core ideas of many agile development methods is to start early and iterate often. Another core idea is also to release in short cycles to production (devops), so traditional operators are becoming more involved in the development of new products in an earlier stage.
Agile development methods are very popular, of course driven by good results such as shorter time to market and lower production cost. The traditional role of architecture was to deliver a solid design that matches the expectations and budget of the main stakeholders. Since everyone nowadays understands that agile development methods are no longer a buzz, but are here to stay due to the increasing pace of a changing business landscape. For a long time traditional architects had no good answer for the changes brought by agile development. Concerns are e.g.:
- Will maintenance not become too expensive in the near future (> 2year), due to the constant re-factoring of applications which will increase complexity?
- How can we ensure that security and privacy aspects are embedded properly in all iterations? Adding security later is expensive and complex.
- The risk of budget overruns is still present and most of the time increased. Mainly because all effort is put on the short time results and not on long term stability.
- How do we ensure that all crucial aspects of a new IT systems are properly documented? Having good documentation is crucial for interfacing, maintenance and future changes.
- Who will be responsible that new developments created by agile teams are in line with external and internal policies and constrains? E.g. external regulator rules and internal architecture principles?
These concerns are real and sooner or later every business will hit some of the predicted risks.
To minimize the risks and to better align agile development and architecture we propose a number of simple measurements:
- Focus on defining principles for new products, services or IT systems. Principles steer the development but give enough freedom to be handled in a creative way within agile development teams.
- Let your development team use tools that increase transparency in what they develop and how. Minimal design decisions should be captured. Many developer friendly documentation tools exist, e.g. wiki’s.
- Make sure architecture documentation is created with maintainability in mind. Good design documentation help developers and will invite developers and other stakeholders to optimize the documentation.
