8 years, 3 months ago

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 6×6 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…