Software architecture is a lot of different things to different people, however most definitions agree that it deals with the major components or structures, their relationships and interactions. It encompasses the major (read hard to change) decisions and their rationale and every system has an architecture (even if it is a default one)
While agreeing on what software architecture is – is one thing. Getting there (i.e. building one) is another thing altogether. There is very little guidance on how one can go about building/developing an architecture for a software project. The SPAMMED framework (dare I say methodology? J) was developed to help fill this gap. SPAMMED is not a new thing invented out of thin-air, but rather a synthesis of several existing approaches and methods combined and integrated into something, I believe, is greater than the sum of its parts.
A note on real-world uses of this process – I have employed major parts of this process in previous projects I architected and this is the prime process I use on project I architect these days.
OK, so what is SPAMMED already… well:
- S – Stakeholders – Anyone with vested interest in the project (end users, clients, project manager, developers etc.) These are the people you will have to explain you architecture to. These are the people that have concerns that the architecture will have to satisfy (or most likely balance). Thus, the fist step is to identify and rank them.
- P – Principles – Principles, Goals and Constrains. These are the things you wish your architecture to have (or lack) based on your previous experience. Constrains can also come from your stakeholders (e.g. management decided that all project should be .NET, a deadline etc.)
- A – Attributes – or rather Quality attributes which (once prioritized) serve as the guide for the overall goodness of the system (Performace, Availability, scalability etc.)
- M – Modeling – model and document the architecture as seen from different viewpoints (list of viewpoints is stakeholder driven) this can include package diagrams, deployment diagrams, DB Schema etc. etc.
- M – Mapping – Technology mapping, buy vs. make decisions etc.
- E – Evaluation – Since architecture is the set of decision that are hardest to change it is worthwhile to spend some time trying to evaluate if they are indeed correct before commencing on
- D – Deployment – Software architectures are not a fire and forget thing. As an architect you still have to make sure that the guidelines set are indeed followed and even more importantly that the architecture chosen indeed match the project’s needs and doesn’t have to be reworked.
On the next few posts(among other things) I’ll try to delve in more detail to each of the steps that make the SPAMMED process I will then follow this with guidance on integrating the process with the rest of the (waterfall/iterative/agile/plan based) development life cycle
