다음을 통해 공유

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.

image

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.

Comments

  • Anonymous
    December 14, 2009
    An excellent article on IEEE-1471, now I understand what it is and what role it plays in EA.

  • Anonymous
    December 14, 2009
    Hi Nick We've disagreed over some points in the past, but this is one where I strongly agree with you. IEEE-1471 defines the concepts and the terminology, but not the architecture itself. (This means that it's also valid beyond IT, such as for whole-of-business or whole-of-enterprise architecture, or for other forms of architecture entirely.) The relationship between views/viewpoints and the architecture-repository is somewhat hen-and-egg. We need views/viewpoints to find the information to populate the repository, and we then read the content of the repository into subsequent views. But like you, I would argue that we must define a repository-structure for an idealised architecture first, so as to provide a meaningful context for the viewpoints and their views. (We've disagreed in the past on the scope of that idealised architecture - I argue that it must be much broader than indicated in your Motivation metamodel - but we agree on the principle at least.) Crucially, the metamodel for the repository must not be defined by its views, and the views must not be determined solely by the structure of the metamodel. This is where Zachman is so frequently misused: it's somehow assumed that each row is the only viewpoint required in that space, that each cell represents a distinct separate view, and that the sum of those cell-views represents the entire of the architecture. In reality, views frequently straddle metamodel cells and will occasionally also straddle rows - a point emphasised in the design of the Archimate language, which deals primarily with connections between cells. Zachman himself does warn of this mistake, emphasising that his cells are 'primitives', whereas the real world is usually make up of composites of different types of primitives - but tool-vendors still insist on pigeonholing their views into Zachman cells, perpetuating the problem. In my own work I use an extended and modified variant of Zachman (see http://tetradianbooks.com/2008/12/silos-frame-ref/ ), much as you suggest, as a skeleton for an architecture that is not only idealised but inherently abstract. In fact it's not an architecture as such, but a descriptive framework for 'all possible architectures' - a kind of meta-metamodel from which architecture-specific metamodels can be built. In that sense, it's much closer to IEEE-1471 than, say, Zachman or the TOGAF metamodel, which are both metamodels for IT-oriented architectures, rather than the much more complex whole-of-enterprise architectures that my clients are usually dealing with. I do agree with the principles behind Michael Poulin's critique; they're valid concerns. But like you, I think he's missing the point: IEEE-1471 remains one of the best tools we have for designing architectures-of-architectures for the systems-of-systems that we deal with today.

  • Anonymous
    January 19, 2010
    Thanks for the great explanation, I read about "Levels of Abstraction" and After reading your blog I wrote the graph in http://infchg.appspot.com/usr?at=1263994762 feel free to correct me,    (I hope to have understood the subject  and meta-model model relationships). Best. J.