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:

FRAMEWORK	MOTIVATION	COMPOSITION	REALIZATION	CONGLOMERATION
Zachman	WHY, WHO	WHAT, HOW, WHEN, and WHERE	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	Deciding Organizational	Designing Actor Cooperation Business Function Business Process Business Process Cooperation Product Application Behavior Application Cooperation Application Structure Application Usage Infrastructure Infrastructure Usage Information Structure Layered Viewpoint Landscape Map	Informing Implementation and Deployment Service Realization	Introductory Landscape Map
TOGAF Architecture Development Model ADM	Preliminary Requirements Management ADM A	ADM B-D ADM E	ADM E ADM F-H	ADM
TOGAF Content Metamodel	Preliminary Architecture Vision Architecture Requirements Business Architecture - Motivation	Business Architecture – Organization and Function Information Systems Architecture Technology Architecture	Architecture Realization	Content Model
DODAF	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

• Anonymous
  February 08, 2013
  Alan, I have certain doubts about the value of the contemporary EA frameworks. I have expressed some of them here www.strategicstructures.com 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)

• Anonymous
  February 08, 2013
  The comment has been removed

• Anonymous
  February 11, 2013
  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. Respectfully, Alan