We started this series of posts with a discussion of the fact that continuous refactoring of emerging-only architectures in enterprise-class software systems becomes problematic as the size of the system grows. In addition, to improving usability, extensibility, performance and maintenance, it seems evident that we might wish to build systems out of components that work in a like manner. Thus there are some practical motivations to apply some “architectural guidance” to the software development practice, the benefits of which include:
Avoiding large-scale and unnecessary rework ‒ Even apparently minor system-level refactors can cause substantive rework for large numbers of teams, some of whom would otherwise NOT have to refactor their module. (It is one thing for a team to refactor their code based on lessons they have learned, it’s another to require multiple teams to refactor code based on other teams lessons learned).
Managing the risk of Impact on deployed systems/users ‒ Even the best possible BVT (Build Verification Tests) systems are imperfect, so the threat of a regressive bug in a deployed system is always there; the cost, risk and impact of which increases with scale. Minimizing unnecessary refactoring is a primary risk mitigation technique.
Improve usability, extensibility, performance and maintenance ‒ Some common, imposed architectural constructs can ease usability, extensibility, performance and maintenance. For example, something as simple as imposing a common presentation design can result in higher end user satisfaction, and ultimately, revenue!
The need for this guidance brings us to the role of intentional architecture, (described further in Chapter 16 of SSA) an enterprise practice designed to produce and evolve robust system architectures in an agile fashion. Intentional Architecture has three primary objectives:
- Leveraging common architectural patterns, design constraints and implementation technologies – These decisions that can simplify development, extensibility and usability. Some can be defined up-front (examples: use the existing user activity logging component; do all web GUIs for the new subsystem in PHP). Others emerge during the course of development and can be leveraged by other teams if we only take the care to do so.
- Building and maintaining architectural runway – architectural runway exists when there is sufficient system infrastructure to allow incorporation of nearer-term product backlog without potentially destabilizing refactoring. In most agile practices, it is sufficient to have six months or so of runway, so that there is a high probability that the highest priority backlog items can be reliability committed to the nearest, upcoming releases.
- Sponsoring Innovation – In many ways, agile natively fosters innovation by more quickly driving solutions to better meet real user needs. Alternatively, however, agile can also be hostage to the “tyranny of the urgent”, as our rapid iteration cycles and continuous commitment to value delivery may drive us to avoid risky or innovative experiments. When everyone is committed and accountable to a near term deliverable, who is scouting the next curve in the road?
In my experience, as an agile enterprise matures, the role of architecture resumes a place of prime importance in assuring overall efficiency of the development process and helping to assure the systems that are built provide world-class scalability, performance and extensibility. By judiciously applying some Intentional Architecture, teams can build better systems without any need to abandon the paradigms that have delivered the outstanding benefits in productivity, quality and morale that agility provides.