What Standards Does IEEE 1471 Describe?
by Mike Rosen, Director, Cutter Consortium Enterprise Architecture Practice
I recently participated in a discussion about architecture frameworks and standards. While there are many frameworks -- such as Zachman, FEAF, and DoDAF -- only TOGAF qualifies as an official standard. By "official," I mean that it is created, published, and maintained by an accredited standards organization. Note that this does not make it any better or worse than the others; all have their strengths and weaknesses. It is just one characteristic that could be considered when applying architecture at your organization.
During the discussion, the question came up, "What about IEEE 1471?" While it is a standard, it is not a framework, though it could be applied to any of the different frameworks. In fact, TOGAF is in the process of aligning its descriptions with IEEE 1471. However, while many had heard of it, almost none actually knew what it was, making it a good topic for an Advisor.
IEEE1471:2000 was adopted in August 2007 by the International Organization for Standardization as "ISO/IEC 42010:2007, Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-intensive Systems." Currently, IEEE and ISO are working on a joint revision of the specification. In the parlance of IEEE, a recommended practice is the least normative type of standard they publish. The specification provides the following:
A normative set of definitions for terms (see below).
A separation of the concepts of "architecture" and "architectural description" to facilitate separating standards for how architectures are described from standards on how systems should be constructed.
A set of normative requirements on the elements of an architectural description and the relationships among those elements, including conformance for well-formed architectural descriptions.
In other words, it is a standard for how to describe architecture, not for what architecture should describe. Like all good architectures, it describes the major concept of the solution. The major concepts of IEEE 1471 include:
A system is "a collection of components organized to accomplish a specific function or set of functions."
A system exists within an environment (or context), where "the environment determines the boundaries of the system relative to other systems."
A system has one or more stakeholders.
A stakeholder has one or more concerns relative to the system. Concerns are "those interests which pertains to the system's development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders."
A system has an architecture, which can be described in anarchitectural description.
The architectural description can be divided into views, which are "a representation of a whole system from the perspective of a related set of concerns." Each view addresses one or more stakeholder concerns.
A view may consist of one or more models and a model may participate in one or more views.
To summarize, the main concepts are the idea that architecture needs to be described in several different but related views (or presentations or perspectives), where each view is designed specifically to address a particular stakeholder. For example, most EA approaches define views such as business, information, application, and technology. Each view is targeted at specific organizations or roles and is described by a different set of models, such as a business process model, ERD, and so on, which are familiar to those stakeholders.
Finally, IEEE 1471 formally defines conformance, including: identifying the key stakeholders for the architecture, separating the description into views, defining techniques for documenting each of these views, and insuring consistency between views.
One of the important goals of architecture is to have commonality between similar things -- whether it is security, how errors are logged, semantics or, in this case, how architecture itself is described. By adopting a standard, it makes it easier to understand different aspects of the same architecture or to compare different architectures. One organization adopted the use of IEEE 1471 to assist in merging two different systems together after an acquisition. It reported improved results after adopting it because all of the different alternatives were described in similar descriptions, allowing for comparison that is more direct. In addition, discussions about the alternatives were more focused and relevant because each view was addressing the same set of concerns. Finally, the organization had greater confidence in its analysis and decision because of the clarity of more direct comparisons.
IEEE 1471 formalizes a best practice of architecture: the use of architectural views to improve clarity, consistency, and communication. Like most standards, it needs to be applied and adapted to your own needs. While the general concepts are well known, adoption of the particular standard is much more limited. I suspect that if the standard were freely available, its adoption would be significantly greater. Currently, it is only available through ISO for 102CHF, or about US $100.
I welcome your comments on this Advisor and encourage you to send your insights on enterprise architecture to me at mrosen@cutter.com.
Sincerely,
Mike Rosen, Director
Enterprise Architecture Practice
E-mail: mrosen@cutter.com