Before we talk about the what/how let’s do a quick recap on why we’re here:
- Architecture is important to software projects
- Architecture and agile have some conflicting forces that need to be reconciled (e.g., up-front work, hard to change vs. delivering business value quickly and embracing change)
- design can be emergent, but architectures can’t and must be grown instead
Another important point to remember is that sometimes you can get away with it. By “get away with it,” I mean you can make one day or less design session; opt for an off-the-shelf architecture (usually that also means choosing a product like Rails or Django) – and it would be good enough for your project. This is usually true for small projects or for projects that are very familiar (and thus rather predictive and, for the most part, can be handled by waterfall processes).
Let’s move on, assuming your project does not fall under the above category. Here is a list of “Do”s and “Don’t” which is based on my experience
- Do start with “iteration 0.” – Iteration 0 means an iteration (though it may take more than one) that is focused on building architecture and infrastructure. It may seem like a waste at first since you’re not delivering business value (at least apparent one) – However, I find that it pays off, especially if you are working with multiple teams and need to allow them to continue in parallel.
- Do Elicit architectural requirements as scenarios (which makes them similar to user stories). Describing architectural requirements as scenarios helps in making sure that the requirements are tied to things important to the system (not just we need 99.999% uptime but also the business scenario where it really matters). Another benefit is that you can align the implementation of the architectural requirement with the delivery of the business value it delivers. You can look for scenarios based on the deliverables in your release plan.
- Don’t think you get them [architectural requirements] all – requirements change, and architectural requirements change as well (hopefully at a slower rate). Try to find the minimal set that can take you forward.
- Do Spike risky stuff – it is worth exploring and evaluating your architectural decisions (see also evaluating architecture in code). When the risks are around stuff you’d need too far in the future (the definition of “too far” can vary, but, say, six months in the future is probably too far), it is probably safe to disregard them – but if you make such a decision add this into the technical debt and risk list to make sure it isn’t forgotten.
- Do try to build the minimal architectural skeleton – Even though we’re spending some effort up-front, we still want to deliver business value as fast as possible. Maybe some of the identified architectural components can be stubbed or partially implemented. For example, in a xsights, the communications infrastructure only handled optimistic scenarios (e.g., assuming resources will always be there) for several months.
- Do try to separate business logic from architectural and infrastructure constructs – If we embrace the idea that change will come, it is wise to get ready for it. Separation of business logic from the rest means it will be easier to move that around when/if we need to (it doesn’t guarantee we will be able to do it, but it would be easier). Another way to look is this is to try to build flexibility in. Yes, I know it is easier said than done, but some things work better than others. An example is event vs. procedure calls (both local or over the network). With events, you don’t know in advance what will handle the call; with a procedure call, you do. Choices like that can have a lot of impact on the ability to shuffle things around later on.
- Don’t fall in love with the architecture you have – Probably the most important thing, it is going to change. Fred Brooks said it long ago in the Mythical man-month: “Plan to throw one away, you will anyway.”
That’s it for now. The next installments will cover strategies to deal with the changes and evolve the architecture.
