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.