Introduction
Architecture can suffer in agile environments, particularly with small teams, but there are steps that can be taken to guard against pitfalls. During a sprint, developers are working with very small increments of functionality, such as individual feature requests or granular functional improvements. They do not have a clear vision of the product as a whole or the larger business objectives behind it. An architectural team can help bridge that gap and ensure that all activities are working in concert with agreed upon business goals.
Why is Architecture Important?
Although architecture is a technical exercise, the primary purpose of developing and following an architecture is to ensure that systems meet strategic business objectives. Typically, these business objectives are agreed between senior management and senior technical leadership. They may include:
- Extensibility and Reusability. It may be important that the systems be scalable to large numbers of users, or be able to be reused for other applications. Or it may be that the systems are intended to stay small and single-purpose.
- Product Lifespan. The question of how long a system should be able to be operated and supported is a key determinant in many design choices. Interoperability. The system may be called upon at a future date to interoperate with other systems. If so, then structured interfaces will be a requirement.
- Durability and Reliability. It may be that the system is intended for short term internal use, in which case durability and reliability should not be a focus. On the other hand, the system may require multiple redundancy and reliability layers in order to ensure robustness.
- Maintenance Plan. Sometimes a system is maintained and enhanced by the original development team. However, there may be a requirement that maintenance of the product be handed off to other teams and new hires (with potentially different skill sets) in the future. This will affect tool choices, complexity, and documentation.
- Modifiability. Are there components of the system that are likely to require modification in response to changing business needs? If so, then those components should be structured for replacement/upgrade with minimal impact to the rest of the system.
All of these business objectives have critical impacts on the choices made to implement a system. Developers could easily spend large amounts of time on unnecessary features or, conversely, fail to give adequate attention to key business requirements if they do not have guidance on how the overall system should be structured.
Forces Allied Against Architecture
Agile approaches to software development, including scrum, produce terrific results quickly and flexibly, and keep development teams happy by bounding their time commitments. However, these same agile approaches have forces that are naturally in tension with good architecture.
- Sprints Are Tightly Focused. Sprints typically occur in two-week segments that are focused on delivering small increments of functionality. When viewing the small, moving parts that are developed in a sprint it is very difficult to see the overall system.
- Technical Developer View. Software developers are expert in writing computer programs, not developing business goals. Take a look at the business objectives listed above. These are not the strengths of programmers at all. However, given these parameters and a clear architecture, programmers can do a good job implementing a system that meets those objectives.
- Pressured Product Owner. Looking at the business objectives one would think that the product owner would be best positioned to represent these requirements to the team. And in an ideal world, she might. However in the real world product owners often face several impediments to this larger view. Product owners may not be senior staff with an expansive view of business objectives. Rather, they are often lower-level “implementers” charged with getting a product released. They may not be technical in nature and thus not equipped to evaluate the consequences of specific technical choices. Finally, they are almost always under pressure to deliver functionality quickly, and this makes them highly susceptible to sacrificing the organization’s strategic objectives for short term tactical wins.
- DevOps, CI/CD. Agile methodologies are often used in DevOps and continuous integration environments. This work by definition is responding to conditions on the ground and making changes on production systems, thus placing them at the opposite end of the activity spectrum from thoughtful architectural development.
- Culture. Some agile enthusiasts may be critical of placing too much emphasis on architecture, portraying architecture as another name for waterfall project management, but this is untrue and misses the point. Architecture tells you what to build; it does not tell you how to build it. Agile teams are free to implement system components in a myriad of ways, as long as those components function in conformance with the overall system requirements.
Scrum and the Architecture Team
Businesses with a mature agile infrastructure may have instituted organizational-level agile approaches such as Scaled Agile Framework which have built-in architectural oversight mechanisms. But often, organizations getting started with agile do so at the implementation team level and thus have no over-arching support structures to ensure architectural success. In this case an architecture team can be created to perform a vital role in ensuring that agile development activities stay aligned with business needs. The architecture team should first identify the key business goals and then create a system architecture to address them. This activity should happen before the beginning of any system implementation, when discussions can happen in a relaxed, expansive, and considered environment. Once the architecture is established and documented, the architecture team should reconvene on an infrequent schedule, perhaps quarterly or annually, to received updates from the implementation team about realities on the ground, and also to determine if any of the key business objectives have changed. If so, then the architecture can be updated.
Architecture Team Composition
The architecture team should be composed of the following individuals:
- Execute Leadership. To represent the key business objectives and expectations.
- Technical Architects. This should be one or two senior individuals with strong architectural backgrounds charged with taking a leadership role in developing the system technical architecture.
- Product Owner. The product owner will be guiding the implementation and so clearly needs to participate. Participation will help her see the product in a larger context and provide input that leads to an appropriate architecture.
- Scrum Team Representative. An individual from the scrum team should participate. She has a dual role of advocating for architectural features that match technical realities on the ground, and also of representing the architectural and business objectives to the scrum team when they are facing implementation choices. This helps to ensure that there is buy-in to the architecture from the scrum team. During technical work sessions for architecture development, the technical architects should consider including the scrum team more broadly to further build support and collaboration.
- The Scrum Master. The scrum master can play a key role in promoting the benefits of an architectural approach and ensuring buy-in and participation of all stakeholders. Also, the scrum master may identify an issue during implementation and call an ad-hoc meeting of the architecture team to address it.
Architecture Team Scope
The architecture team is charged with identifying the key business objectives and ensuring that those are reflected in a system architecture. Toward that end, the architecture can establish:
- Components and Interfaces. The architecture should specify the system’s primary functional components and the interfaces between functional components. This especially includes APIs. The architecture can specify that an API of a certain type be developed, or the architecture could actually fully specify the API and leave the implementation to the scrum team.
- Technical Standards. The architecture should provide guidance about the level of robustness required for code, where and how errors should be trapped and logged, and the primary protocols to implement.
- Languages, Platforms, and Tools. If specific tools need to be utilized to meet a business objective, then those should be specified in the architecture. These choices could be for technical resources, but also have to do with budgeting, licensing, and even human resource concerns.
- Testing Workflow. Unit testing and other testing criteria should be specified. If the project is to utilize test-driven development, then the architecture team can specify that a separate testing group develop acceptance tests in advance of development.
- Documentation. Documentation standards and requirements should be specified in the architecture to meet both customer needs, and the business objectives of long term product support.
In general, the architecture should provide minimum specifications and guidance and leave the implementation to the scrum team. However, a product owner may desire to have an architecture that is more completely developed. She may desire this because it will ensure a more performant outcome and also because she can use the identified architectural components to guide her efforts in prioritizing the agile backlog, which is her primary responsibility and challenge.
Conclusion
Having an architecture team can be of tremendous benefit for agile projects. It protects the organization’s business interests and provides a roadmap for the product owner. Rather than being anti-agile, an architecture can give confidence to a scrum team to know precisely how to calibrate their technical activities and ensure interworking with existing or future components of the system. Finally, it gives the product owner a clear roadmap for the entire product and allows her to adjust development priorities without compromising either business goals or system integrity.