Addressing the Multi-Dimensionality Challenge on Thinking of The Enterprise as a System

Last week I had the pleasure of attending and presenting at the Open Group conference in Newport Beach, California.  I find these conferences enlightening as I enjoyed the dialog with fellow professions who share similar point of views on the discipline of Enterprise Architecture.   I have made the following observations:

  • We have a huge challenge in language and grammar in describing the architecture of the enterprise system.
  • We all seem to believe that one two-dimensional expression may not be fully sufficient in describing enterprise architecture of a complex system.
  • There are two classes of architects.   There are hedgehogs and foxes.    The hedgehogs stick to their credentials, methods and frameworks.   The foxes are comfortable darting around from one technique.  (Check out the LinkedIn groups on Enterprise Architecture and this will be painfully obvious.)

In an attempt to spark some discussion, I presented the following presentation at the conference.   After the presentation two distinguished colleagues pointed out to me, who I respect greatly, indicated to me that my thinking is a bit ahead of the curve.   I take that as complement in some ways, but in other ways I take it as a challenge.   There was clearly an agreement that framework on its own will clearly not make an architect successful.    Our enterprise architecture frameworks appear to stifle thinking in solving a problem.   Just examining how to link two frameworks together is not easy.  For example, take TOGAF and ArchiMate and although the have similar language their intent in addressing a problem may not be the same.

In my early days as a practicing architect the only architectural layers I thought of was contextual, conceptual, logical, and physical.   A variation of Krutchen's well known "4+1 model" perhaps.    I struggled with these being labeled as “architectural” layers, because, I thought of them as vertical walls that were based on time on where one was in the development lifecycle.   But was it?   Can you use some science to determine what layer you were in?   So that was one dimension, but something was missing.  Then John Zachman introduced us to the Zachman Framework which took these traditional layers and added another dimension on the nature of questioning and inquiry using the classic six interrogatives.   Alas, we had a 6x6 matrix of 36 cells that had an all compassing view of the enterprise.  

I credit Mr. Zachman a great deal for generating his framework using classic engineering and hard manufacturing methods of reductionism.   I personally found the framework of thinking restrictive and limiting, and difficult to comprehend as architects debated on what was which cell we were working on at any given moment.  In addition it had its roots in the development of a HARD system, one that is perhaps fragile because it is static and rigid.   SOFT systems are more complex, they are dynamic.  John Zachman is one of the best architecture and engineering minds of our time as he thought of the enterprise as something that you transacted with, but the thinking around  enterprise and technology has reach a level of enlightenment:   it is an experience which evolves through emergence.  Can you imagine flying an airplane when the passengers are all interacting and reshaping the plane itself?   As an engineer I understand reductionism, but there is more to a system than its parts.     As one of my colleagues said to me, can you understand the ocean by just examining at all the drops of water individually?  (Thanks Kumaran Anandan)

So I looked to examples of art to figure out a way how to express multiple problem domains in a two dimensional format.    The concept of viewpoints was an interesting one to me, but there was a tendency of architects to create too many viewpoints to describe the system in question.   There were process viewpoints, data viewpoints, enterprise viewpoints, system viewpoints, security viewpoints, operational viewpoints, logical viewpoints… but then what was a viewpoint versus a view, etc.    Then enterprise architects wrestled with the enterprise architecture domains….. is each domain a viewpoint, or is it a separate architecture?   These endless debates around grammar and language became mind-numbing. There was too little effort by Enterprise Architects dedicated to solving the enterprise "mess" and wicked problems, as most of the effort was around the language and grammar of expressing the problem and is associated solution.    So I began to research philosophy, then system theory, then complexity theory, and now set theory to better understand and describe how to think about complex or “wicked” problems.   

Systems thinking is around the concept of describing mental models.   Mental models at least for me, are never two dimensions in my mind.   Modeling a complex system is not easy when one is limited to a two dimensional piece of paper.  As we develop mental models, we think in multiple dimensions. 

Peter Checkland, a thought leader and pioneer in soft systems methods, brought the Soft Systems Methodology (SSM) and the PQR formula.  Simply stated:  Do P by Q by achieving R.   The links between P-Q, Q-R, and R back to P become worthy of exploring.   (For more on PQR and SSM, see previous blog entries).


 Again credit to Zachman for introducing us to the notion of knowing the type of question you are answering.  Putting the best of hard and soft system thinking together, it lead me to create this mental representation below.    When examining a system, its subsystem, or its elements, there were always four dimensions to consider at any given moment.   




Then l added the ISO 42010 (formerly IEEE 1471) concepts of viewpoints, describing motivation, composition, realization, and conglomeration.   (Yes I do not like that last word either, I am working on it.)  Each of these viewpoints have different considerations that one has to think of, but there are also interconnected by different aspects.



Each of these viewpoints carry with its own way from moving from course to finer grained descriptions of the system.    


 I am not suggesting or implying any framework or indicating that one has to use all or any of the views that I have described above, as well all need to develop our own fit for purpose views based on the system in question they are trying to address.    What is encouraging is that there is momentum in many of the more modern architecture frameworks that aligns closely (although by no mean perfect) with this representation.   

(Note:  Some of you may be asking why am I doing this.  I have worked with many large organizations both in the public and private sector as an architecture consultant and I typically have to align outcome oriented techniques, in which consultants hopefully are compensated by, with existing frameworks.  Another topic for a blog.)

 The following table is a guide that I use when working with my clients:









Does not describe

Does not describe

ArchiMate Metamodels

Motivation Metamodel Extension

Business Metamodel

Application Metamodel

Technology Metamodel

Implementation and Migration Extension

Does not describe

ArchiMate Viewpoints




Actor Cooperation

Business Function

Business Process

Business Process Cooperation


Application Behavior

Application Cooperation

Application Structure

Application Usage


Infrastructure Usage

Information Structure

Layered Viewpoint

Landscape Map



Implementation and Deployment

Service Realization


Landscape Map

TOGAF Architecture Development Model ADM


Requirements Management







TOGAF Content Metamodel


Architecture Vision

Architecture Requirements

Business Architecture - Motivation

Business Architecture – Organization and Function

Information Systems Architecture

Technology Architecture

Architecture Realization

Content Model


Standards Viewpoint

Capability Viewpoint

Data and Information Viewpoint

Services Viewpoint

Systems Viewpoint

Operational Viewpoint

Project Viewpoint

All Viewpoint

 Note:  Zachmans interrogatives do not align to the interrogatives to what I am suggesting.  

I know there is paradox that some of you may be thinking.   And asking:  “Hey you are introducing a framework right?”  My answer to that is perhaps, but it is framework for thinking about complex systems, not about the specification of the system itself.    As one of my colleagues suggested, perhaps a metaframework for architectural thinking?   Again perhaps….   It is my hope that we can bring a level of understanding to enterprise architecture in order to make it more consumable not only for fellow architects, but constituencies outside of our profession.    As I understand this looks complicated, and perhaps it can further simplified.   I will continue to publish these thoughts and as always I welcome your feedback.  

Happy architecting…


Comments (3)
  1. Alan,

    I have certain doubts about the value of the contemporary EA frameworks. I have expressed some of them here along with other observations on EA fallacies. Basically frameworks are used  as a tool to reduce the variety of the enterprise to just a few things that share the same properties, according to some classification theory. All EA framework tend to have a lot of abstract layers, tiers, cells or whatever word their authors fancy to indicate some division. That gives them the freedom to solve whatever is not fitting when mapped from reality by adjusting abstractions or modifying rules.

    What this all leads to. First a huge amount a frameworks. I call this "an increased variety of variety reduction failures". Let's compare this with another framework in another domain: Mendeleev's periodic table of elements. It's only one and is in use for over 140 years. It's not easy to argue about it. You can take an element, make a test (reality check), and you'll see it's properties will prove it's place on the periodic table as originally found. I can't do that with EA frameworks. Further, the periodic table predicted new, yet to be discovered or synthesized, elements. And that's what a good ontology should do. Not just tell you back what you tell it, but help you discover new knowledge. I'll come back to this in a minute.

    Apart from creating taxonomies and meta-models, some frameworks also feature a methodology for EA, notably TOGAF. What is the value of prescribed processes in a complex adaptive systems and in using best practices is something discussed enough, or at least it seems so to me, so that I could add anything more. Let's just say, it's minimal if any. Basically it's a attempt to reduce the things you can possibly do to just a few but well defined and in a specific order, with well prescribed inputs and outputs, because that was common for so many organisations that did well so that it became a best practice, and the chances are, if you do it, you will succeed as well.

    I believe the job of an Enterprise Architect comprises mainly sense-making, decision-making and design. And I'm not sure frameworks, at least those that are in currency today, help or could help much.

    (..continued in the next comment)

  2. "So I began to research philosophy, then system theory, then complexity theory, and now set theory to better understand and describe how to think about complex or “wicked” problems." My path was roughly the same. I would add "cybernetics" somewhere in that line and evolutionary theories. What I've been learning from systems theory and cybernetics is how to diagnose systems especially social ones, which are my main interest. And complex sciences help me a bit better understand the behaviour of systems that live and evolve without central control. But I'd like to point out the importance of set theory in the context of frameworks. If we try to test some of the meta-models of the EA frameworks using set theory, they prove inconsistent.  Luckily, it's quite easy to do this now, having powerful languages like OWL-DL.

    EA frameworks also contribute to isolate Enterprise Architects in communication (they use terms that are foreign to the business) and reduce their influence at strategic level. And then putting a strategic discipline act on operational level, makes it marginal at best.

    Having said all that, I have to admit that all this proliferation of frameworks, the certification and the tooling around them, is all but natural. Luckily, there are balancing mechanism in the viable organisations that wouldn't allow EA do much harm being so poorly equipped. The real EA is done anyway (not under this name) and companies can't survive for long if it is not. I just wished to see the real EA and the labelled EA work in synergy or being indistinguishable.

    That might come one day. Blogs like this one give me hope.

  3. AlanHakimi says:

    Ivo, thank you for your kind comments.

    I have seen your work as well and I take great comfort in the fact that there are others in this Enterprise Architecture profession that are like-minded.   Enterprise Architects need to know how to think.  I think you and I would agree that frameworks are not necessarily evil, but over reliance on them in the absence of critical thought is.

    We are doing some research on the topic of architecture of architecture and meta-architecture, and there is some amazing thought leadership that is spread throughout the globe.  Our challenge is we need to build a global community to help drive this forward.

    I would welcome your thoughts on that.



Comments are closed.

Skip to main content