Channels ▼


The SPAMMED Architecture Framework


Architectural decisions are made early, and once made, they're hard to change. This means that it is extremely important for you to ensure that architectural decisions are right. To me, the premise of "test early/test often" is also applicable to architecture. Thus, once you have made some decisions (while modeling and mapping), you want to evaluate your decisions and validate your assumptions. An artifact that can help you in evaluating architectures is the quality attributes scenario. In fact, this is the way it was originally used in evaluation methodologies, such as ATAM.

It is preferable to evaluate the architecture in code; after all, this is how it will eventually be used. There are several possibilities for evaluating architecture in code—simulations, proof-of-concept (just enough code to validate a single decision), prototyping (making several architectural components work together), and building a skeleton (similar to prototyping, except the end result is the basis for further development). When you test the architecture in code, you can also use additional techniques such as Test-Driven Design (TDD) to further refine the design.

If you are still looking at the system in a higher level of abstraction (compared to code), it can be harder to dive to code, so you can draw on formal evaluation methods. The Software Engineering Institute (www.sei offers several evaluation techniques (ATAM, ARID, and the like). Microsoft introduced one (LAAAM) as part of MSF 4 for CMMI improvement , CERT has Survivable Network Analysis, and there are others. Evaluation on paper can take between a couple of hours to several days, depending on the method used. Formal evaluation requires the participation of various stakeholders to be successful. Both evaluation approaches (evaluation in code and on paper) complement each other to help you make the right decisions.


Once you are satisfied with the current state of the architecture, deploying it is the next activity. Deployment means that development teams utilize it for developing system functionality (this can be early in the process if you are part of an Agile team). If you are a responsible architect, this doesn't mean it is time to disengage—far from it.

There are two motivations for you to continue working with the teams:

  • Governance. It is your responsibility to ensure that the architecture is followed. Developers have all the reasons in the world not to follow the architecture—ranging from prosaic (you communicated the architecture poorly and no one really understood you) to deadlines imposed by management that lead to cut corners for on-time delivery. You need to make sure (assuming you believe in the architecture you drafted) that the architecture will not be circumvented. Architects are usually not the direct manager of developers, so you'd have to lead rather than command (which is better anyway). You can choose techniques such as pair programming, mentoring, meetings, and presentations.
  • Verification. It is your responsibility to ensure that the architecture fits the actual needs of the software. I don't know about you, but when I code, I have bugs. The same is true for architecture modeling—mistakes will happen, and because architectural decisions affect the entire system, an error can result in adverse results. Working with the team on the design of various modules (participating in design and code reviews and/or coding), you can (and should) pay attention to the implications of the architectural decisions and make sure that the decisions are both valid and easy to use. Should the architect spot problems, she should repeat one or more of the previous activities (modeling, evaluation, and so on).

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.