EA Frameworks or Ontologies?

Or why not both?

Frameworks, ontologies, taxonomies, schema... each of these is important and very useful in Enterprise Architecture. But the terms are frequently used in a confusing way.

I've written this post to explain the differences and briefly describe why and how frameworks and ontologies are both useful.

Pre-defined frameworks

It is impossible to read about enterprise architecture without coming across the notion of frameworks. John Zachman was probably the first person to describe an architecture framework in detail, with his Framework for Information Systems Architecture, while the most popular architecture frameworks is probably The Open Group Architecture Framework (TOGAF®). But are these truly architecture frameworks?

• On the John Zachman's website his "framework" is more accurately described as an enterprise ontology, a classification and a schema.
• While TOGAF® is really a Body of Knowledge (BoK), which then includes several different frameworks (content, capability, skills, etc.).

Furthermore, any pre-defined framework - such as Zachman or TOGAF® - must be customized to meet the exact needs of a specific enterprise, because every EA initiative is different. So it makes sense to distinguish between pre-defined "frameworks" that are used as a starting or reference point, and frameworks that are tailored to address a specific, practical task.

To make this distinction clear, I refer to pre-defined frameworks as source or reference frameworks; while the practical frameworks created to support a specific task are given names that show their use, such as a Content Framework, or a Governance Framework.

So! These two popular frameworks are not strictly frameworks in the customized, practical, this-will-really-help-me-day-to-day sense (one is a schema, the other is a Body of Knowledge).

Source or reference frameworks

All pre-defined frameworks are useful inasmuch as they provide source or reference material to help us create practical and useful frameworks that we can then use in our day-to-day EA roles.

But here we face another problem with pre-defined frameworks: they may have some things in common, but they are often very different in what they include and how they present it! Which is a challenge when architects want to use material from several source frameworks to create their own tailored ones.

The solution is simple! It's summarized in the following diagram:

We can deconstruct any source or reference material into an EA metaframework and an EA ontology.

Note that source or reference material is not limited to architecture frameworks: it might include other EA metamodels, reference architectures, or even domain models from business or management. In fact, given the wide scope of enterprise architecture, we can radically improve the way that we architect by leveraging the huge number of readily-available domain-specific frameworks and models.

A metaframework

An EA meta-framework is simply a framework that sits above any pre-defined frameworks. It also sits above any tailored and customized frameworks that you might produce for your specific enterprise needs.

Now an important characteristic of EA is that it is quite a complex, multi-dimensional discipline. And it is always difficult to visualize a large number of dimensions in a single diagram or graphic. From my experience and research, EA requires eight fundamental factors or dimensions. [These are described in more detail in Enterprise Architecture - the Eight Fundamental Factors.]

Some of the pre-defined EA frameworks make the mistake of trying to graphically show several of these dimensions in a single diagram, or framework. It is easy to present one or two of the factors in a single framework. Even three factors in a single matrix or table can work - if you choose the right factors. But trying to show more than three dimensions or factors is well-nigh impossible. It is frequently confusing and it certainly doesn't result in a framework that is immediately practical or useful.

In fact, EA frameworks have a bad press precisely because they attempt to show too many dimensions or factors in one framework diagram. It makes them overly complicated, difficult to understand, and useless as tool to think about or manage architectures.

The EA Metaframework is therefore a mechanism for extracting all of the good and useful material from any pre-defined or pre-used framework to create more useful ingredients that can be used to create practical and useful frameworks.

As I mentioned earlier - my experience and research suggests that there are eight fundamental factors, and I use these as the basis for an EA Metaframework. These are shown in the diagram below. [I wrote at length about the Levels of Understanding - which is one of the eight fundamental factors - in an earlier post.]

I should emphasize that I don't see this as a prescriptive or definitive list: I simply offer it as a suggestion for a comprehensive EA Metaframework:

The lines in the diagram indicate that each of the factors can be used on their own, or in combination with any of the other factors. This is a really important point. It gives a metaframework for creating practical and useful frameworks that you can use to help you think architecturally and manage architectural change. There are many possible combinations, but each of them is based on a common metaframework - which makes it easy to create individual frameworks that are consistent and integrated.

An ontology

It is also possible to populate each of the factors with a checklist of values, and again this can be harvested from any pre-defined source. For example, the most important factor is the one that I call Domains or Categories, that covers the subject areas covered by EA. The most common high-level domains are Business, Data, Application and Technology. But there are a whole host of other domains and sub-domains, including Product, Process, Information, Security, Capability, Security, and Service. 

By extracting these names from our source frameworks we can produce a useful checklist of domains. This forms part of our EA ontology - the kind of things that form the basis for enterprise architecture. And we can produce similar checklists for each of the eight fundamental factors.

Better still, we can arrange our list of domains into a faceted classification to make it easier to structure and use our checklist. A classification also makes it easy to extend these checklists. Over time, using such checklists, you will build up a definitive, comprehensive list of the ingredients that are used across all of your EA projects.

EA techniques are used to ensure that the metaframework and the ontology are well-structured, and that they can be easily extended and adapted over time.

Roger Evernden