Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Security

The SPAMMED Architecture Framework


Model

Modeling is the most obvious activity. It can be done on whiteboards, with case tools, or even with a word processor. The level of detail depends on the requirements (sometimes a customer demands a detailed document as part of the contract), the team level (experienced developers require less detail than inexperienced ones), and the development process (Agile processes require less documentation).

Another point to remember is that design should be conveyed from multiple viewpoints (see IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems, ISBN 0738125180). Each stakeholder has different concerns and different viewpoints that help demonstrate how the architecture addresses these concerns. For example, a deployment or physical view helps communication with operations and/or system engineers by demonstrating what software runs on what hardware, the hardware needed, the network topology, and the like.

Map to Technology

Granted, mapping technologies is not an architectural activity per se. Choosing one technology over another usually will not change the quality attributes of the system. However, the architectural implications become evident when the wrong technology is used. For instance, using Microsoft Access where Oracle RAC 10g should be used will greatly affect performance and availability. Another problem that can occur is misalignment of the technology (to the architecture). The result is hard work for the development team, which can, in turn, result in rejecting the architecture all together. For example, if you decided to build a rich-web client (AJAX, for instance), servlets are probably not the way to go about developing it.

Another aspect of mapping to technology is to make decisions involving buy versus make versus reuse versus customize.

  • Make will get you the best alignment with the architecture, but will cost you time and money to develop (and the component may well be one that is not in your organization's core business).
  • Reuse is taking some existing asset from another project and using it as-is.
  • Customize is similar to reuse (you take an existing asset), but you clone and own it instead of using it as-is.
  • Buy is taking a third-party solution to fill a particular block in the architecture. Buying a ready-made solution can be cost effective. However, usually the match is not 100 percent and the architecture sometimes has to be adjusted to fit the product.

All of these decisions are similar to architectural decisions in that they tend to have ripple effects solution-wide. Also, technology decisions affect the detail design. For example, if the project needs some way to move messages around, it is always possible to start at the socket level and develop some proprietary solution. Or maybe you can buy a JMS solution. However, if you are using SQL Server 2005, why not utilize a service broker? Or maybe web services interoperability would be better.


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.