Scaling Architecture, Requirements and Design – The Mystery of the 11th Principle
Agile software development is an approach that uses self-organizing, cross-functional teams to develop requirements and solutions by collaborating with customers and end users. It advocates a rapid, flexible response to change, along with the early delivery and continual improvement of software. Agile development uses a broad range of specific frameworks such as Scrum and Kanban.
A group of software developers published the Manifesto for Agile Software Development in 2001 based on their combined experience. This manifesto contains twelve principles that describe agile development and distinguish it from the traditional model, commonly known as waterfall development. For example, Principle 11 says that self-organizing teams create the best architectures, requirements and designs, which creates challenges when an organization scales up its development efforts by deploying multiple agile teams. This principle implies that each team should create its own architecture, but they still need to integrate these architectures to obtain a common platform that provides consistent performance across the enterprise. Agile teams must therefore adopt a series of best practices that allow them to scale up while adhering to Principle 11 of the Agile Manifesto.
Scaled Agile Framework
The Scaled Agile FrameworkTM (SAFe) is a set of workflows that help guide enterprises in scaling agile practices beyond a single team. It promotes the alignment, collaboration and delivery of software across a large number of teams by leveraging agile software development as well as systems thinking and lean product development. The problem of being truly agile at scale has caused some developers to advocate simply discarding Principle 11 by centralizing their architecture. This option becomes even more attractive when you consider the complexity of the modern software environment on a cloud platform.
Multiple Architects
The use of multiple architects is one of the best methods for scaling agile development, which generally involves deploying architects at various levels within the framework. Enterprises that use the SAFe methodology for large development projects often appoint architects with different roles such as enterprise architects, system architects and solution architects. These projects may also use multiple release trains that collaborate to create architecture.
Agile frameworks like Scrum don’t specifically identify the role of an architect on a team, but neither do they prohibit it. Multiple architect roles in SAFe help decentralize architecture so its development doesn’t depend on a single architect. For example, a solution architect ensures these trains work well together, while the system architect for a release ensures that it’s technically sound.
Collaboration
Collaboration is another key practice for scaling architecture, which requires striking a balance between intentional architecture and emergent design. Adhering to Principle 11 at scale requires teams to implement safeguards to ensure their architectures remain aligned with each other without becoming centralized. Teams must retain the flexibility needed for designs to emerge within architectural constraints, allowing them to decide the best way to move their development efforts forward.
The balance between intentional architecture and emergent design in SAFe also manifests in the use of an architect runway. This analogy describes the flow of continuous releases down the same track. However, those tracks must be laid down first before the train can move across them.
Value Streams
Architecture needs enough of a runway to allow teams to operate effectively and independently without the need to explicitly make every decision. For example, an enterprise architect can ensure architectures remain aligned across value streams by working with other architects in different portfolios. The key requirement for this process is to define technical initiatives but only standardize what is necessary to achieve flow across the entire architectural set without creating a single centralized architecture.
Each value stream can contain multiple systems, so it’s critical for the system architects to conform to the enterprise architect’s guidelines while still allowing the design of each architecture to emerge. Each system architect is responsible for ensuring their concerns are met regarding their own architecture. It’s not uncommon for each system to have a team of architects, since no single person may have the necessary depth of knowledge across all of these technical domains.
Summary
Principle 11 doesn’t need to go, although following it is more of a challenge at the enterprise scale. However, the original intent of empowering teams to make as many technical decisions as much as possible still applies. The key takeaway is that you can’t grant your teams complete autonomy to make architectural decisions at scale because you need to create the proper balance between a centralized architecture and one that allows designs to emerge.
Watch the webinar to learn more:
Learn More
