Software architecture is the design and specification of the rules by which software will be built and by which components of the system will behave and interact. It could be as high-level as “We will build out the solution using REST services” or as detailed as naming the particular services to be developed and what data we expect to pass in and out of each.

Architecture also includes establishing design considerations for the development team, such as “no returning null values” and “all code must be peer reviewed before release,” as well as producing and maintaining a list of third-party libraries that are approved for use when building code.

When adopting agile, enterprises often ask, “When do we create our software architecture? How much of my architecture do I create up front?” My instinctive response is, “Approach architecture just as we approach everything else—by using agile.”

When I look at the Agile Manifesto, several principles stand out that guide the development of an agile software architecture.

Designing Architecture Based on Agile Principles

Working software is the primary measure of progress.

Architecture specifications, design documents, approval processes, etc., may be important, but only when they bring us closer to our goal of working software. These artifacts are only a means to an end, not a goal themselves, so they must never be prioritized over delivering working code.

This principle is closely tied to the Agile Manifesto value of working software over comprehensive documentation. If we spend too much time documenting our architecture instead of building working code, we are moving away from agile principles.

The best architectures, requirements, and designs emerge from self-organizing teams.

"Ivory tower architectures" developed by architects that are not involved in the day-to-day development of the software may not fit the immediate needs of the software and the team. The team has the best vantage point to figure out what they actually need to build and how that aligns with architectural guidelines. 

If you consider that the customer for the architecture is the development team, this principle and the related Agile Manifesto value of customer collaboration over contract negotiation suggests that a big, up-front architecture created by an architectural team will not be as effective as embedding an architect into the team working with the developers throughout the project. A creative collaboration involving someone who will actually be using the finished product will lead to an architecture that fits the team needs as well as the requirements of the enterprise. An architectural contract handed down from on high will often not.

Simplicity—the art of maximizing the amount of work not done—is essential.

Up-front architectural designs often try to accommodate anticipated future needs that may never actually be realized. That causes more work for a payoff that never arrives. Building and designing based on perceived future need is not agile and wastes effort. Try using team-based design, where your design is incrementally built along with the code, refactoring it as you go.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Architecture is there to guide the team to a solution that fits the needs of the software and the enterprise. If the team members aren't involved with the development of the architecture, they may not understand the objectives and values, so they are more likely to be prone to following the letter of the law without understanding the spirit. Give them the environment and support they need, and trust them to get the job done.

Continuous attention to technical excellence and good design enhances agility.

Agile doesn't mean "no design" or "no architecture." Best practices still apply and will help the team develop more effectively. A well thought-out architecture makes it easier to change directions as customer needs change or become better understood.

Too much architecture can make it more difficult to adapt. Agile architecture must strike the right balance for the team, the software, the environment, and the enterprise.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

What was expected in the early stages of a project almost never matches with reality as the project matures. This holds true for design and architecture just as it does for requirements. By designing iteratively and reflecting on what is providing value and what is hindering the team, the team can adjust the architecture as it is tested and proven through actual use, and they can reevaluate and adapt it as the project changes.

Fitting Architecture into the Agile Process

In order to be agile, we must develop the architecture in an iterative manner, beginning with enough definition for the team to start development. The architecture has to guide the team in a direction that will give them the best chance for success, without specifying so much that they don't have the flexibility to build the software in an agile manner.

There is a trade-off between allowing a team to choose what makes sense for their project while ensuring they don’t pick technologies that are incompatible with the rest of the enterprise. This trade-off is making sure the team builds software that aligns to the overall enterprise architecture without forcing the team to use an architecture that won't be effective for their project.

Like any mature agile process, an agile approach to architecture relies on doing just enough definition up front to get started, gathering feedback as we go, adjusting as needed, and iterating frequently to keep architecture and design in sync with the emerging application.

Prior to the first sprint, a high-level enterprise or system architecture should be created (if it doesn’t already exist) and discussed. As part of each sprint kickoff, team-based design is used to update the as-is design from the last sprint to account for feature additions and enhancements that will be made in the current sprint. As stories are tasked out for development and testing, the team will use this new “to be” design to help determine what will need to be implemented in order to satisfy the expected design.

Sprint review meetings should present how each story fits into the bigger picture of the whole application and the enterprise. Sprint retrospectives should include architecture and design in the discussions of what is working and what isn’t.

In all facets, architecture should be treated like any other part of the agile process:

• By starting with experienced architects and industry best practices, we can integrate the project requirements with the enterprise requirements and standards to be confident in a good foundation
• By incorporating retrospection and review in the process, we can make minor adjustments to both the architecture and the software being developed to ensure that we meet the enterprise's needs
• By driving that feedback using quality tools, security tools, testing, and other objective metrics, we ensure that we aren't reacting to guesses and anecdotal evidence
• By reflecting and evaluating continuously, the course corrections remain minor and incremental and can adjust to changing architecture requirements throughout the life of the project and as needs evolve
• By collaborating with the development teams, we can be sure the architecture reflects real-world needs and isn’t just an “ivory tower” architectural approach that makes sense on paper but fails in actual use.

For an organization transitioning to agile development, creating software architecture isn’t incompatible with your new processes. Consider the principles in the Agile Manifesto, involve team members who will be using the architecture in its development, and reflect and adapt often, and you will end up with an architecture that meets the needs of your team and your enterprise.