Why Red Teamers Should Care About ISO 42010: 2007 (IEEE 1471)


Red teaming remains stuck in the Wild West phase of its maturity. One of the main culprits is the lack of shared terms—a lack that makes it difficult for red teamers to compare methods, communicate insights, and, ultimately, build a consistent and structured discipline. IEEE 1471 can help.1
      The full name of IEEE 1471 is “IEEE Standard 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems.” The standard is currently managed jointly by IEEE and the International Organization for Standardization (ISO) as ISO/IEC 42010:2007. As noted here, IEEE and ISO intend to broaden the standard’s scope to include both software and systems engineering.
      The first important concept to understand about IEEE 1471 is that it’s not an architecture framework but a standard for creating architectural descriptions. Any given architecture framework, for example, may conform to IEEE 1471 to a greater or lesser degree. As a system or enterprise architect, for example, you wouldn’t use IEEE 1471 to architect your system of interest, but you might use an architecture framework that conforms to IEEE 1471.
      The second important concept follows from the first: IEEE 1471 is notation independent. When generating an architectural description that conforms to the standard, you are free to use any appropriate modeling or diagramming approach to populate your architecture. The analyst, then, retains considerable methodological freedom, whether he or she is a software developer, a systems architect, or a red teamer.
      At this point, the skeptical red teamer will naturally ask, “If the standard isn’t a framework, and it doesn’t specify any modeling techniques, how can it benefit me?” It’s a fair question, but before I answer it, I need to define six key terms used in the standard.

  • Every system has an architecture; it is the inherent structure of the system. The architecture exists regardless of whether an analyst ever describes it.
  • An analyst or engineer creates an architectural description when he or she models the structure of the system. The architectural description characterizes or describes the whole system.
  • Systems have stakeholders. Stakeholders aren’t limited to the system’s users but include, for example, persons who sponsor, develop, implement, maintain, and depend on the system.
  • Stakeholders have concerns. A sponsor might be concerned that the system must be delivered on time, a developer might be concerned that a needed technology is delayed, and so on.
  • A view characterizes the whole system through the lens of a single concern or a set of related concerns.2 To describe a system, the analyst or engineer will typically need to build many views. Each view may in turn contain many models.
  • A viewpoint helps the architect structure the views. It should specify the stakeholders, their concerns, and the conventions used to construct the view models.3 In the domain of software engineering, for example, Rozanski and Woods apply six viewpoints: functional, information, concurrency, development, deployment, and operational.4

The following list summarizes the relationships among these six terms:

  • a system has an architecture,
  • an architecture is described by an architectural description,
  • a system has one or more stakeholders,
  • stakeholders have concerns,
  • a viewpoint addresses one or more concerns, and
  • a view conforms to a viewpoint.5

      So again, why is this useful to red teams?
      Most red teams “architect” target systems, even when they don’t use the term. Sometimes the process is informal and the resulting description is unsophisticated (and perhaps even undocumented). Sometimes the process is structured and the resulting description is much more complex. Rarely, however, do teams apply the same concepts or terms to their architectural descriptions.
      The real advantage of IEEE 1471 in this context is that teams can employ different tools and approaches and still use the same high-level concepts and terms. Remember that the IEEE standard recommends a common method of describing architectures, not of building them. The concepts and terms are abstract enough–yet also robust enough–to facilitate communication without constraining methods or imposing burdensome requirements.
      It is worth noting that I am not arguing that all red teams should adopt the same viewpoints and views. Most teams have different goals, customers, issues, and constraints, and these factors naturally yield different architectures, stakeholders, concerns, viewpoints, and views. I am, however, arguing that we should at least use the same terms and adhere to the same high-level structure in order to share ideas, concepts, and, yes, sometimes even viewpoints more efficiently.6
      Sandia’s IDART, for example, employs views, a concept another team might call viewpoints, a set of perspectives, a set of models, or something else entirely. If IDART and other teams were to use the term views consistently (along with the rest of the IEEE 1471 terms and concepts), they would be able to compare their methods and products more easily without surrendering their teams’ basic methodological independence.7
      Architecting–whether formal or informal–is just one of many functions red teams perform. While the lack of shared terms extends to most of these functions, we need to start somewhere. IEEE 1471 offers us a foundational set of concepts and terms on which we can begin to build a true discipline. And as we all know, Wild West gunslingers, card sharps, and cattle rustlers never were much inclined to discipline, but a clever sheriff could keep the assorted rowdies in line with a good set of shared terms.8

  1. To learn more about the standard, see, for example, Rich Hilliard’s presentation or this FAQ written by Mark Maier, Dave Emery, and Rich Hilliard. []
  2. As defined in one IEEE 1471 FAQ, “A view is a collection of models representing the architecture of the whole system relative to a set of architectural concerns.” []
  3. In the same FAQ cited above, a viewpoint is defined in these terms: “A viewpoint captures the conventions for constructing, interpreting and analyzing a particular kind of view. Viewpoint conventions include languages, notations, model types, modelling methods, analysis techniques, design rules or other operations on views.” []
  4. Rozanski and Woods, Software Systems Architecture, 2005. []
  5. For those who are interested, ISO defines the terms and illustrates their relationships diagrammatically here. []
  6. That said, we should always be careful to avoid tainting our analysis with an engineering bias. The answer, of course, isn’t to throw out any engineering-based approaches, but to be aware of the perspectives we adopt when we use them. []
  7. I continue to emphasize the latter point because some red teamers will assert that any standard, no matter how loose, will encroach upon their methodological independence. []
  8. And yes, I purposely used rowdies. Some of the red teamers I know would probably consider themselves modern guns for hire, and a few, I suspect, are decent card sharps. For all I know, a couple might even be cattle rustlers. []


  • Since I didn’t get around to commenting on the preview – I’ll do some now.

    The one problem I have with IEEE 1471 stems from the lack of scope. While architecture is the source of one set of views – System – it does not encompass the other views to which the IDART methodology subscribes. These other views (for those not familiar with IDART) include Functional/Logical, Physical, Temporal, Lifecycle, and Consequence. What’s more important is that views be created by red team members drawn from diverse skill-sets and expertise. Ideally, each member of the red team creates views of the target system according to the visualization standards of their area of expertise. An IEEE 1471 AD view would be a system view created by a software architect – not necessarily a systems engineer who would be more likely to use IDEF0. The diversity of views from different red team viewpoints helps the understanding of the target system as the team goes into the brainstorming process.

    Re Footnote #8 – I once practiced all of Scarne’s tricks and could second deal, nullify the cut, and generally cheat at cards with proficiency. I’ve never rustled cattle but I did help rustle an alligator, once.

  • Ray,

    I have to differ with you on this one. IEEE 1471 doesn’t constrain or prescribe scope; “system” in the standard’s parlance can be defined as broadly as necessary. Architectural frameworks consistent with IEEE 1471 implement a variety of viewpoints and views, some of which you’ll find in IDART, others of which you won’t.

    You note as well that “An IEEE 1471 AD view would be a system view created by a software architect – not necessarily a systems engineer who would be more likely to use IDEF0.” This is a very narrow view of IEEE 1471 and, more particularly, ISO/IEC 42010:2007, both of which are applied by both software and (increasingly) systems engineers to architect systems. Structural analysis and design modeling approaches (think IDEF0) are rapidly being overtaken by UML/SysML in the SE world.


  • Every diagramming method has its day and eventually is supplanted. I think prescribing any one expression of characterization would be too restrictive of red team ingenuity and creativity. My basic point is that each red team member should use whatever expression is consistent with their specialty and experience. My example might be flawed, but the idea is still valid.

  • Ray: I think we agree more than we disagree. We agree, for example, that one method will never work for every red team, and red teams need room to fly and be free. At the same time, I think you’d agree that red teaming as a whole lacks even the most minimal common structure. That’s why something like IEEE 1471 is useful; it is a minimal structure. It’s not a diagramming method or an architectural framework; it’s a standard for architectural descriptions. It doesn’t specify what viewpoints you use or how you construct your views. You could define a “humor” viewpoint and draw your views with crayon on paper, just as you could define a “functional” viewpoint and build a set of views using SysML, UML, IDEF0, entity relationship diagrams, all of the above, or none of the above. You could adopt DoDAF 1.5 products, DoDAF 2.0 viewpoints, MODAF viewpoints, another AF’s viewpoints, of build your own. IEEE 1471 doesn’t care, as long as you define viewpoints and build views.


Terms of Use

Please read.