Agile has been here for some time, but confusion still floats around when we discuss Agile architecture. We hear, "Don't do up-front design" — which is often counteracted by the fact that if we don't do the design early, how can we proceed with the product visioning or the framework development? Confusing, isn't it? Agile does say not to do the "big design" up front, which may force one to a state of scrapping a major chunk of the hard work just when business decides to change its approach due to changed market requirements or, perhaps, to take a step ahead of the competition — who may have just come up with something similar. (Of course!) So, if that does happen, we'll need to get back to the drawing board and start afresh. And that begs the question: How much architecture is just right in Agile?
Honestly, there is no fixed answer. It's dependent on the project context. The team has to figure out the cutoff on this by using its collective wisdom. In general, the idea is not to spend a whole lot of time designing and implementing the different moving parts. Rather, we simply build the minimal amount of code needed to connect all of the basic pieces (some may still be in a conceptual state). Then we start building the actual functionality on top, providing an early end-to-end experience of the results. Yes, the focus is more on the API level of the infrastructure and not the actual implementation, which is usually mocked up for the first few sprints. As our iterations progress, the actual implementation is incrementally completed, guided by the need of the other functional parts of the application.
To put things in perspective, if we want to set guidelines on getting started with an Agile architecture, we can put down a few simple steps that will help us understand how we dive in:
- Identify business objectives. Focus on understanding why business wants to build this, rather than what business is planning to build.
- Establish architectural objectives. Identify technical challenges, understand/identify technology stack, define major hardware/software requirements, agree on design patterns, identify component/service reuse, create high-level diagrams, and define quality/security/performance attributes.
- Identify key scenarios/actors. Draw the key scenarios/use cases, which help in validating the approach.
- Draw an application overview. Use a simple wireframe/screen mocks/prototype. As a team, use the whiteboard to draw the application overview, communication behavior, dependencies, and layers/tiers.
- Identify design coupling points. While driving the design, we need to be careful to identify the couplings so that we keep enough room for future realignment.
- Create candidate architectural solutions. Come to an agreement as a team and pull out an architectural candidate solution. Let it be transparent, make it open for criticism, and tune it even further.
- Inspect and improve. Once your candidate is ready, start rolling the development and continue improving it as you progress.
We need to understand that Agile development starts to build even before the outcome is fully understood or envisioned. As development progresses, the design and development approach is adjusted and teams use empirical data and knowledge to make course corrections, aiming for an eventual state of stability. Architecture plays a crucial role is helping any team reach this state — but instead of being an individual effort, it evolves from the team. Also, instead of a specific approach, Agile architecture does offer flexible solutions, providing options to fall back on in case one approach fails to serve the altered need of business. And in this process, we don't "have to" design our architecture over a single iteration. Neither should we get lost in the details. We start by setting our focus on the big steps and building a framework on which we can base our architecture and design, and proceed by building the rest on top of it.