In “Think big, act small” – what does it mean in architecture?, Viktor Grgic says, "Let’s simplify things by talking about concrete things we actually do in software projects." Inspired by this, here's a summary of what I consider to be a minimal set of software architecture practices. Or to put it another way, here's what I do to get to a software architecture quickly.

The discussion about what I consider to be "just enough up front design" can be found in the sample of my "Software Architecture for Developers" book, but it's about...

• Structure: I look to understand the significant structural elements and how they fit together, based upon the architectural drivers (e.g. a product backlog plus the important non-functional requirements and constraints). I achieve this by doing design and decomposition down to containers and components. There are other ways to decompose software systems, but I like thinking in terms of components/services. I'll often sketch out a domain model too, particularly if I'm dealing with a domain that is new to me or non-trivial. Oh, and yes, this does include choosing technology. Often a single technology will be identified, and at other times there may be some options that we would like to evaluate. And this latter point leads us to...
• Risks: I like to identify and mitigate the highest priority risks - the things with a higher than normal risk of consequences if I don’t get them right. Good examples include not adequately catering for non-functional requirements or putting too much faith in an untried technology. Risk identification can be done with techniques like risk-storming and mitigated by prototypes, walking skeletons, etc.
• Vision: I create and communicate a vision so that we, as a team, understand what is being built and how *we* are going to build it. Note the emphasis on *we* ... I typically write code too. I use a collection of simple software architecture sketches to illustrate this. You can transcribe them into an electronic tool if you need to, but even a bunch of sketches on the wall can help tremendously to provide some focus.

Just to be clear, this isn't about gathering all of the requirements in any detail and it's not about big design up front either. A few short workshops to gather requirements and do some collaborative design is all it takes to get to a decent starting point. Since I'm a visual person, I'll even start to draft up a context diagram during workshops with non-techie people when we're gathering requirements.

That's basically it to be honest. I may do more if needed, but I don't generally do less than this. This isn't specifically an "agile" thing either, as I've followed this same basic approach for software projects of all shapes and sizes. The whole point of this is to introduce some direction and put some foundations in place that we can build upon. I have no problem with the architecture changing once we start writing code, but it should be done for a reason and in a structured way. Structure, risks and vision ... it's all about having a starting point for the rest of the delivery process, however you slice it up.

Add a comment

Posted by Simon Brown on 13 March 2014 17:02:56 GMT #