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.