Channels ▼


The SPAMMED Architecture Framework

List Principles, Goals, and Constraints

Designing architectures is a tough and complicated job, and the solution space is virtually endless. To help you focus and limit the solution space, you can use three tools:

  • Principles
  • Goals
  • Constraints

Stakeholders don't just sit there with their concerns and agendas—they can also introduce constraints related to: business (time constraints); technology (the company standard is to use WebSphere, for instance); or architecture. For example, on one of my recent projects, the customer required that the solution incorporate a parallel processing engine (grid) and that a single engine would be used in all subsystems that required parallel processing.

It's important to remember the constraints when you model solutions. I usually document each constraint, explaining what it is, its rationale, which stakeholder introduced it, and the scope of its effect.

Goals are similar to constraints in that stakeholders originate them. The difference is that while constraints are demands, goals are more on the "nice to have" side and tend to be more amorphous; for instance, you want the architecture to be open and based on standards.

Principles draw on our past experiences. Using principles from other similar projects can increase the chances you will be able to reuse assets from those projects. For example, a principle might be "we think that a federated database can work for this solution because it proved to be the best option in three other similar projects." You can document principles in a more formal manner by describing what they are, the rationale behind them, the benefits they bring, their liabilities and implications, the alternatives, and the scope of their effect. It is usually more worthwhile to manage principles in larger projects. Regardless of project size, and whether you carefully document principles or just spend some time thinking about them, you should be ready to forgo any of them if/when the actual requirements of the system at hand show they do not fit.

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.