It took awhile but I finally managed to complete describing all the activities of SAF at least at some level of detail.

What is SAF?

There is very little guidance on how one can go about designing/developing an architecture for a software project. The SPAMMED architecture framework (SAF) aims  to help fill this gap. 

SAF  is a set of activities that an architect can follow when she sets out to design an architecture. These activities helps the architect to keep abreast of the project's needs and the drivers that affect the architecture.

Overview posts:

Getting SPAMMED for architecture

SPAMMED State chart

SAF Activities

The Activities of SAF include

• Stakeholders -identify the 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.

• Stakeholders Everywhere
• Stakeholder Template

• Principles – list Principles, Goals and Constrains. These are the properties 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.)

• P is for Principles (and Guidelines and Constraints...) - Iteration I
• P is for Principles (and Guidelines and Constraints...) - Iteration II
• Principles Template
• Constraints Template

• Attributes –  discover quality attributes, the non-functional reqeirements, that (once prioritized) serve as the guide for the overall goodness of the system (Performace, Availability, scalability etc.)

• Quality Attributes - Introduction
• Utility Trees - Hatching quality attributes
• Architecture & Functional Requirements

• Model – model (and document if needed)  the architecture as seen from different viewpoints (list of viewpoints is stakeholder driven). Example for viewpoints include package diagrams, deployment diagrams, DB Schema etc. etc.

• Architectural Modeling - First Step
• Architectural Modeling - Choosing your Viewpoints
• Modeling - Architectural Styles
• Software Architecture Document Template

• Map – Technology mapping, buy vs. make decisions etc.

• SAF - Mapping -Don't forget the Technology

• Evaluate – 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

• SAF - Architecture Evaluation (Introduction)
• SAF - Architecture Evaluation - Evaluation in Code
• SAF - Evaluation part II - the "Formal Methods"

• Deploy – 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.

• SAF - Deployment - What to do when the architecture seems stable?

Feedback & Future

I would be very interested to hear any feedback on SAF - you can send  feedback to saf@rgoarchitects.com or just leave a comment

On the next SAF posts I am going to talk about SAF alignment with development methodologies (RUP, MSF 4, SCRUM etc.) as well as strategies for following or acting upon the activities.