OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Fwd: What Standards Does IEEE 1471 Describe?

This being circulated on an internal MITRE list.  If anyone has comments/corrections, please let me know if I can recirculate locally.


Begin forwarded message:

From: "Dabbaghchi, Eric" <iraj@mitre.org>
Date: August 20, 2008 1:55:18 PM EDT
To: "service-oriented-architecture-list Current SOA efforts and techn" <service-oriented-architecture-list@LISTS.MITRE.ORG>, "ese-enterprise-services-list ESE Enterprise Services" <ese-enterprise-services-list@LISTS.MITRE.ORG>
Subject: What Standards Does IEEE 1471 Describe?


From: Cutter Consortium [mailto:webmaster@cutter.com] 
Sent: Wednesday, August 20, 2008 7:20 AM
To: undisclosed-recipients
Subject: [EA Advisor] What Standards Does IEEE 1471 Describe?

20 August 2008

What Standards Does IEEE 1471 Describe?

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.

Mike Rosen, Director 
Enterprise Architecture Practice 
E-mail: mrosen@cutter.com

Welcome to the Enterprise Architecture E-Mail Advisor , a weekly electronic briefing from Cutter Consortium's Enterprise Architecture Advisory Service.

Recently published:

Get the EA Feed

Measuring Alignment in Agile Architecture

One of enterprise architecture's most important goals is to "align business and IT." However, this often proves elusive because it is too "fuzzy" or too difficult. This one-day seminar presented by Cutter Senior Consultant Jim Watson demystifies business-IT alignment by looking at how alignment can be practically measured in IT systems and the EA program. You'll learn how to consider your EA program as a business function and to measure and assess its success and value. For more information on bringing this workshop to your organization, call +1 781 648 8700, or send e-mail tosales@cutter.com.

Get a Sneak Peek at Upcoming Cutter Analysis

Participate in our surveys and you'll get a glimpse into upcoming topics and analysis -- and stimulate your own critical thinking about your organization's strategies with ...


Ken Laskey

MITRE Corporation, M/S H305     phone:  703-983-7934

7515 Colshire Drive                        fax:        703-983-1379

McLean VA 22102-7508


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]