Emerging architecture is a characteristic of agile software development. Instead of the Big Design Up-Front, software architecture emerges along with development activities. This becomes difficult for large projects, so enterprise agile approaches balance forward thinking with the rapid development of features that create business value. With a bit of planning, an architecture focus doesn’t have to slow us down.
What is architecture?
Software architecture is sometimes described as the implementation of the non-functional requirements. Performance, scalability, and so forth. This is a narrow view. In my mind, software architecture is about design patterns. Once defined for a particular solution, we use them again and again for features that are similar to ones we have already built. Another way to say that is:
A place for everything, and everything in its place.
Sure, the patterns include ways to ensure high performance, scaling, and robustness, but they also define the core design decisions. The kind you diagram on a whiteboard with boxes and arrows. Everything you need to know you learned in kindergarten… or maybe not. These patterns capture how the user interface functions, how data flows, how access is secured, how components interoperate, and so on. Once solidified and tested, we want to keep using them over and over.
The Never Beginning Story
Designing, building and testing these patterns is hard, but using them is easy. Therefore, the temptation in traditional projects is to dream up all conceivable patterns early on and implement them in an all-encompassing framework. The premise is that once the framework is established, productivity will kick into high gear and features will fly out of the machine.
The risk is that the framework may never complete. I have seen projects that spent many months, or even years, building out patterns without ever delivering any real business value. The project sponsor may pull the plug before the precious framework is ever put to productive use.
Emerging Architecture in Agile Projects
Conversely, in agile projects, the temptation is to do very little up-front overall design, and lump he architecture work in with the development work. The team only focuses on designing patterns when required to develop whatever feature they work on. This results in an emerging architecture that takes shape as the project unfolds. Like magic.
This works for small projects with highly skilled developers. It doesn’t scale well to large projects with a real-world mix of skills.
Enterprise architecture approaches, such as the Scaled Agile Framework (SAFe) introduce the concept of an architecture runway to drive the architecture work that supports upcoming features without having to redesign the solution (or end up with creative plumbing). It shifts the focus from emerging architecture to intentional architecture that is still delivered incrementally.
The challenge is that the runway is finite. If it’s not long enough, the developers who build the features that need the patterns will still have to wing it, often resulting in brittle architecture and rework.
I think there is a simpler approach.
Architecture in MoSCoW
A common way to prioritize features is to use MoSCoW:
- Must have
- Should have
- Could have
- Will not have – this time
Teams shoot for the must-haves/should-haves, which represents the business case for the project. This should take no more than 80% of the effort, with 20% left for contingency. The must-haves represent the Minimum Viable Product (MVP) and should take no more than 60% effort. Best case, there is room for could-haves. Worst case, only the MVP is shipped. Everyone is happy. Sort of.
We already know that it’s difficult to design and test architecture patterns, but easy to use them. It’s an 80/20 rule or worse. If we are not careful about designing and implementing patterns early enough, we may run into surprises at the tail-end of the project. Worst case, we can’t ship the MVP. Not a happy scenario.
A simple solution is to include an architecture perspective in MoSCoW:
By focusing on the features that are must-have or should-have and set patterns, in the top right quadrant, we ensure that the architecture emerges in a managed way. We avoid building architecture we don’t need. We also avoid surprises at the tail end of the project. The key is to balance the priority of features that set patterns (and thus require architecture work) versus those that just use patterns.
Takeaway
Architecture is core to building software solutions. It’s about sustainable patterns, not just non-functional requirements.
A little pragmatic planning goes a long way. By introducing an architecture perspective in the prioritization of features, we can shift from an emerging architecture to an intentional architecture.
Ernst Rampen ©2018
