Wednesday, September 8, 2010

IEEE 1471 – What’s required for Software Architecture?

I recently read through the IEEE Std 1471-2000. In one of the last sections it gives an example of what is needed for an architectural description (an AD) to meet the standard’s requirements. A large group of industry representatives worked on this standard for several years and this standard was approved in 2000.

The first section is the basic information about the architecture. This includes the data of issue, the organization issuing the architecture, change history, a summary, the scope and context, a glossary and references. This is standard for the technical documents we write in my organization.

The second section must identify “architecturally relevant stakeholders”. This would include users, acquirers, developers, and maintainers (at a minimum). With this section, the concerns of the architecture are also included: the purpose, the appropriateness of the system in filling the purpose, the feasibility of constructing a system, the risks to all the stakeholders, and the general maintainability of the system. What concerns are most important to each of the stakeholders?

An example of this section would be a stakeholder that takes the software system being built and uses it in another system. This stakeholder is interested in the interfaces to the system and not much the internal design. But the developer /stakeholder is very interested in the internal design.

The third section describes viewpoints which are required. The specific views for an architecture are not specified but the standard says the views must be “selected, defined, and analyzed for coverage and that the rationale be given for their selection”. Each viewpoint must have a name, the stakeholder interested in that view, the concerns addressed, the modeling technique or method used to construct the view, the source information (like author, date, etc.).

The viewpoints should cover the stakeholders concerns. Note my blog entry where I lay out the minimum viewpoints I need to define an architecture.

The fourth section lays out more requirements about views. Each view will be only one viewpoint. Hmmm…this seems to favor Unified Modeling Language (UML). Check out Object Process Methodology which has one diagram with many views.

The next section requires that the views must be consistent with each other. This can be hard to do in practice if your tools don’t do this for you. Peer reviews can also help here.

Section six specifies that the architectural rationale must be included. This seems most important in evolving systems. See my blog post on recording architectural decisions – this is a practice we do in my organization on a daily basis.

Reading this specification reminded me of a time long ago when I was asked to come up with an architecture of a very large system. I came up with several views and assembled of team of cross functional designers from across the system. I spent months working on the diagrams trying to get agreement. I could not get convergence – even on what views to include. If I had this standard in hand at the time, it might have given me the framework to work on defining the views better in relation to the stakeholders.

I recommend reading the specification – it’s short.


  1. Is it time for a new paradigm in contract software engineering? We think so. Click on my name to go to our website to learn about our program that puts client and contractor satisfaction ahead of profits. We know that Good Pay + Low Rates = High Quality.

  2. There are a couple mis-conceptions in your otherwise good summary of the standard (which is now ISO/IEC 42010:2007, with an update in the works probably approved next year.)

    1. The 1-1 rule for view-viewpoint is best explained this way: First, the standard requires that a view should cover the entire system (from the set of concerns, modeling techniques, etc specified by the viewpoint.) So now a proof by contradiction: If you have -2- views for a single viewpoint, then either (a) neither view completely covers the system (which violates the 'whole system' rule) or (b) the views are redundant. The standard in particular allows the sharing of models between views; a view can just aggregate models. (Example: If you have a performance view, you might have 2 models in that view, one a network queuing model and the other a computational load model. The computational load model may also be used in a Kruchten "4+1" process view to document allocation of software to hardware.)

    Also the standard is explicitly not intended to be UML centric or UML focused. (In fact, I am no fan of UML, check out forthcoming "IEEE Software" Nov/Dec 2010 for my view of UML.)

    2. The standard does not require consistency across views. It requires that a single view be consistent, and that known inconsistencies between views be documented.

  3. The rule in IEEE 1471 about one view per viewpoint is not to give preference to certain notations such as UML. The standard is intentionally agnostic about notations, and encourages multiple notations to be used within a single view (this is why views may consist of multiple models: each model could use a different notation).

    The one-viewpoint-per-view rule is motivated by the idea: every map should have a legend: there should be one place the reader can look to see what are the (modeling) conventions in use for this view.

    IEEE 1471 was adopted by ISO as an international standard in 2006. Now ISO and IEEE are jointly updating it. New material builds on the foundations of the 2000 edition to address areas like architecture frameworks, architecture description languages and formalizes correspondences between views. Anyone interested in commenting on the on-going revision should visit:

  4. Good post and Smart Blog
    Thanks for your good information and i hope to subscribe and visit my blog Ancient Greece and more Ancient Greece for Kids thanks again admin

  5. Great design share. many designing software and paint para mac are available free tool on many website that's get help we design many image easily

  6. Thank u guys for Useful information. Really Nice post. The objective of this mini article is to introduce software engineering in terms of: why software needs engineering, how engineering can be applied to software development.

    Software engineering

  7. This is a very nice blog. I hope I can make a blog like you. I amazed with the blog yours

    Online marketing company in India

  8. Interesting story you have shared it is useful and getting a lot of new thing its really nice and making best thing.

    Total video downloader for Mac