Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

December, 2009

Posts
  • Inside Architecture

    Why the Zachman Framework is not an ontology

    • 8 Comments

    John Zachman has been making an interesting claim in the last few years… he is claiming that the Zachman Framework for Enterprise Architecture, a creation of his that, through many revisions across the years, has formed a cornerstone of Enterprise Architectural practice in many parts of the world, is an ontology.

    It is not.

    Let’s be clear, first off, about the definition of an ontology.  There are two commonly used definitions.  In philosophy, an ontology deals with the nature of being.  An ontology in philosophy is a statement of “what is real”,  a conceptual understanding of something that helps to answer key questions, like “what things exist,” and “how does a thing relate to other things.”  Philosophical ontology attempts to answer questions like “does truth exist?” or “does energy exist?” 

    Not long ago, the term ‘ontology’ took on a new meaning in the context of computer science.  In the late 1980s and early 90s, Artificial intelligence was attempting to create large maps of human understanding, and the term “ontology” started to creep into general use in AI circles. 

    Tom Gruber is widely credited with bringing the term into focus in computer science.  In 1993, he wrote a paper titled "Toward Principles for the Design of Ontologies Used for Knowledge Sharing," later published in the International Journal of Human-Computer Studies.  The paper can be found here.  A more general discussion can be found here.

    Gruber’s use of Ontology is fairly clear.  In the discussion cited above, he stated:

    “In the context of knowledge sharing, I use the term ontology to mean a specification of a conceptualization. That is, an ontology is a description (like a formal specification of a program) of the concepts and relationships that can exist for an agent or a community of agents. This definition is consistent with the usage of ontology as set-of-concept-definitions, but more general. And it is certainly a different sense of the word than its use in philosophy.” (emphasis added).

    The goal of ontologies in Gruber’s research was focused on Artificial Intelligence.  His challenge was complex: How could he get intelligent agents to converse with one another in a consistent fashion?  Ontologies provided that ability, far better than simple definitions would.  A concept in an ontology is defined rigorously, and the relationships between terms are specific and declared.

    It is important to note that there are no implicit relationships between terms in an ontology.  Relationships, where they exist, are explicitly declared, and in many cases, constrained.  Relationships are not implied.  There is no notion that two terms may be related to one another, or not, as needed.

    And here is where we come back around to Zachman.  While the Zachman Framework (ZF) defines, in a 6x6 grid. a self-contained set of terms, the ZF does not declare the existence of any relationships between them.  In fact, he implies that anything can be related to anything, without constraint.  While practitioners can reasonably discuss the composition of primitives into composite objects, the Zachman framework does not describe any composite objects at all. 

    In defining a “type system” for “things related to enterprise organizations,” the Zachman framework provides a simple set of data types, and little else.  It is useful, but insufficient. 

    Using ZF, I can look at a thing and figure out “where in my taxonomy does this thing belong?”  But the type system is too broad to imply many constraints.  The Zachman framework is full of generalities.  Specific types are not described.  This means you can understand a “thing” but not really talk about it at a conceptual level because it is too vaguely defined.  Specificity and clarity are required to draw conclusions.  That requires a great many more objects, and specific, constrained, declared relationships between them.

    Without concrete objects and specified relationships, ZF cannot solve many EA-specific problems.  You cannot, using Zachman alone, have two people draw the same conclusions from the data that you collect, because your data is unstructured.  Conclusions come from structure and relationships, not definitional types.   You need a model that includes relationships to infer a conclusion drawn from the data.  EA needs ontologies (metamodels).

    An ontology allows inference.  The Zachman Framework does not.

    The Zachman framework is not an ontology.

  • Inside Architecture

    Does IEEE-1471 Define Enterprise Architecture?

    • 3 Comments

    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. 

Page 1 of 1 (2 items)