Does IEEE-1471 Define Enterprise Architecture?

Michael Poulin recently blogged on EBizQ some of his challenges with applying IEEE-1471 to enterprise architecture.  For those not familiar with IEEE-1471, it is an ISO standard definition of “software architecture” that defines key concepts such as View, Viewpoint, Stakeholder, Model, and Architecture. 

For folks who would like a refresher on 1471, and how it connects to UML notions like element, artifact, and profile, see my prior post on the extended 1471 model that we use in Microsoft.

Using the concepts of Viewpoints and Views, Michael finds challenges in the notion that an Enterprise Architecture can be defined by the various views.  He correctly points out that the contents of the view can only illustrate the particular elements that are actually in the model itself, and if we don’t define the scope of the architectural model, then the views will not contain the necessary information.

Michael’s conclusion is “the viewpoints and views, so loved by the IEEE 1471 standard, do DESCRIBE but NOT DEFINE the architecture and the Enterprise Architecture, in particular.” 

With all due respect, I believe that Michael missed the point.  IEEE-1471 does not define the concrete enterprise architecture, nor the abstract enterprise architectural metamodel.  It defines the concept of architecture itself.  There are a few steps in the middle that need to be understood in order to bring all of these concepts together.  Saying that IEEE-1471 does not define EA is like saying “the concept of a Mammal does not define my cat Fluffy.”

IEEE-1471: a conceptual model for any architecture

First off, I don’t believe that Michael is challenging the core notion of IEEE-1471 itself.  The standard mostly defines terms and a semantic model, so that we can use those terms well.  It does not define how an architecture is developed, when, or who does the work.  It is purely a domain model for architecture.

Applying IEEE-1471 to “Enterprise Architecture” means that we will include, in the architectural model, all of the elements that are important to understanding the concerns of “Enterprise Stakeholders.” 

This is where we must re-apply IEEE-1471 beyond it’s humble application architecture roots.  The standard describes concepts that can be applied to any level of concerns, but only discusses those concepts within the context of software.  It is up to us to discuss those concepts within the context of the enterprise.  In Microsoft, we do exactly that, and we have no problem with using IEEE-1471 to define the notion of Enterprise Architecture.  The key is to use IEEE-1471 in the right context.

The diagram below illustrates the relationship that I will talk about in the rest of this article.

Applying IEEE-1471 to Enterprise Architecture

Applying IEEE-1471 to EA requires that we start with a single question: “Who are the stakeholders for an enterprise and what are their concerns?”  If we start there, we can capture those concerns, and create an “abstract viewpoint” that would be useful for creating the necessary views; views that describe and clarify those concerns. 

This process of “abstract-to-concrete” is useful, because it indicates the elements that we need to include in the architectural model itself.  Once we identify those elements, we know what information we need to collect from the enterprise itself.  We can actually scope our efforts, and justify the efforts to collect specific information, only when we understand the stakeholder’s concerns and the views we want to provide to meet them.

Note that the existing standard set of abstract viewpoints, defined in RM-ODP, does a very poor job of capturing the enterprise stakeholders and their concerns.  It is immature and in dire need of an update.

This is the clarification I would make on top of Michael’s post.  It is not about “defining EA by defining the views” (an approach that he calls “out-in”).  It is about defining the contents of an enterprise architectural model by first understanding the stakeholders of the EA model, and the concerns that they want to see addressed, and then creating an abstract viewpoint that you believe meets those concerns. 

This is not “outside in” or “inside out".  I argue that we should define the scope of your Enterprise Architecture efforts by the outcome you need to produce.  

How does IEEE-1471 relate to an Enterprise Metamodel?

Every model has a metamodel: a description of the elements within the model and how they relate.  A metamodel is, itself, a model, and thus has it’s own metamodel.  This hierarchy of models is well recognized, and the UML folks spend a considerable amount of energy and effort to describe the different levels, all the way back to a root level.  (Leave it to architects to want to understand the nature of any “thing".  It’s philosophy at that point). 

IEEE-1471 is a model that describes how you collect any kind of architecture.  In itself, IEEE-1471 is a metamodel.  Looking at it this way, you can create any model you want, as long as it works for your stakeholders.  It can be a model of an application, a business process, and yes, an enterprise. 

The abstract model, or ideal model, of an enterprise is called the “enterprise metamodel.”  This describes the elements of architecture useful for describing an enterprise.  I published part of an enterprise metamodel last spring in the Architecture Journal.   

Using views to decide what to capture in the EA model

Many medium and large organizations are sufficiently complex that it makes sense to hire an Enterprise Architect.  Any such “complex organization” can be viewed from many different angles.  Your “ideal enterprise architectural model” (or metamodel) can include hundreds of entities, some could contain thousands of rows.  Collecting that data in a consistent manner could take a very long time, but you will never collect all that data. 

You cannot, and should not, do the “ideal” thing.  You need to do the sensible thing… figure out what concerns your organization has, and which views on the ideal model will meet those concerns, and then collect only the information that you need. You only need to collect a chunk of information if you intend to create a view to meet the concerns of named stakeholders.  Limit your efforts to meeting the needs of specific people, not “abstract notions”  and, just their concerns; nothing more.

Inside Microsoft IT, we have a description of an ideal enterprise architecture metamodel.  It took Microsoft a considerable amount of energy, and money, to create it.  But I have no mysterious delusions that we will EVER populate that ideal model with actual data in every defined entity.  The ideal model is useful, because it helps our EA team to be consistent, growing our understanding in consistent ways, so that the data collection effort we do at one time supports the reports we need later.  But the ideal model does not define our work.  The concerns of the stakeholders define our work.

Closing Advice

My advice is this: don’t define the conceptual Enterprise Architecture as a set of views, but do define the concrete EA model as a set of views on an ideal metamodel… because those views have a purpose.  Know the purpose: to meet the concerns of EA stakeholders.  Those views are useful for selecting the entities you need to have, and the data you therefore need to collect.

Once you collect the data, you can produce the views that the stakeholders need, and answer the questions that the stakeholders need answered. 

That is the job of Enterprise Architecture, as expressed using the concepts of IEEE-1471.