Blog Posts Enterprise Architecture (EA) Process Analysis Process Modeling

Structure in Threes: Revised Preface and start of Part One/Chapter One – An Architect’s View of Organizations

Blog: Brian's Blog - Enterprise Strategy, Architecture and Management

PREFACE

It has been close to thirty years since John Zachman coined the term Enterprise Architecture and introduced business to the Zachman Framework. Over the years, the metaphor has been used and abused, technical religions have grown around methodologies and still the term Enterprise Architecture is derisive.

Is it an activity that produces a plan for building various systems?
Is it the actual plan for an Enterprise?
Is it a methodology to produce standard compliant designs?
Is it a collection of diagrams that represent different types of information about the information systems used in an enterprise (the Zachman Framework Aka Ontology)
Or maybe a specific set of standard components organized in a specific structured way

When I started the initial concept for this book years ago, I had considered creating a text that would provide methods for designing an enterprise; this being the goal of Enterprise Architecture or at least my belief is the goal. However, over the years’ experience has taught me five things:

Nothing is simple when explaining yourself; a lesson taught to me by John Zachman
Words have different meanings depending upon the context and experience of others; a lesson taught by Michael Kutcher, John Sowa, Gil Laware, and Frank Kowalkowski
The difference between a methodologist and a terrorist is that you can negotiate with the terrorist; a lesson taught by IBM CIM Architecture Department and TC184/SC4 & SC5 working groups
Thinking in the abstract and in multiple dimensions while technically possible by most, is often avoided in most enterprises in the name of speed and comprehension; a lesson taught by most managers and mid-level executives I’ve had to deal with
Nothing is foolproof as fools are so dam cleaver and Nature always sides with the hidden flaw; Murphy you were an optimist

Those insights came to light over the years of associating and working with those I consider giants and mentors in the field. Included in this book are vignettes of how those insights were developed; if for no other reasons than to pay tribute to my mentors and colleagues and to establish part of the context for the content in the book.

That being the bedrock I started building this work upon, I realized I needed to answer several questions first before I introduced my approach to Enterprise Architecture. The book itself is meant to be a practical guide on “practicing” Enterprise Architecture, a theoretical text explaining my perspective on what Architecture or more specifically Enterprise Architecture is, and how these fundamentals are expressed in practice.

Why Structure in Threes

Structure in Threes praxis guide toward the design of enterprise based upon a fusion of several concepts:

A classic work from Henry Mintzberg, Structure in Fives, on strategy
My original research and training in dwelling architecture from works by Vitruvius, Soleri, and Christopher Alexander
Studies in Systems Theory from works from von Bertalanffy, Checkland, Forrester, Meadows, and Weinberg
Studies and learnings from John Zachman

The title is meant both to honor Mintzberg’s leap of using a spatial reference to describe an abstract subject as well Zachman’s ontology that defines a multi-dimensional problem space that is enterprise.

About this book

This book is both a stand-alone work as well as a companion text for an educational curriculum taught by the author. The sole purpose of both book and curriculum is to raise the knowledge and skill level of practicing architects and associated stakeholders. While it will reference a methodology for demonstration it should not be construed as THE sole approach towards developing a praxis.

Simply put I am not intending to form yet another priesthood in the field. There are many paths to this destination and fulfilling the goal of designing an effective enterprise.

Part One – Theory and Methodology

An Architect’s View of Organizations – creating a coordinate system for an abstract space

In 1997 I had published an article “What is Architecture” to lay out the context for the full problem space I believe enterprise architecture should cover. In this article, I recounted an earlier discussion with several IT provider executives that I worked with. Primarily the dispute was around the representations of architecture, but quickly moved past representations to what architecture is.

My opponent in this discussion strongly advocated documenting a set of components in a hierarchy. “Here the architecture is these six devices connected together by this specific network type. That’s the architecture” He’d laid out a hierarchy of computing systems that looked much like an organizational hierarchy; One master mainframe at the top with a descending hierarchy of smaller and smaller mainframes, and eventually workstations or personal computers.

I had asked what was the rationale behind using a hierarchy and the selection of each component type at each level. The response was a blank stare. It was though I was speaking Martian to him. Then suddenly a rather heated response back. “O.k. tell me YOUR definition of architecture”.

Without trying to escalate what had become a heated situation I fell back to my original training. “There is a difference between architecture and design. Many people use the term architecture when they really mean a design….an architecture are the rules for the selection and usage of components and/or elements to achieve a stated functional objective. These can be structural and non-structural such as light & shadow, space, stone, glass and wood. This how these components are selected, used to fulfill an objective is the architecture. The actual instance of using these are the design.”

Defining the problem-solution space

From that discussion and the Zachman Framework I came to the conclusion that to effectively design and construct an enterprise one really needed to visualize this conceptual entity, Enterprise” in an abstract multi-dimensional space. A similar concept to how architects use the dimensional metaphor to define dwellings. What is missing in those dwelling visualizations (designs) are the rules that were used to create those designs. That is the architecture that was developed inside the head of the architect during his/her education and practice.

However, in discussion of those components, elements, and rules has not been a topic of discussion in most Enterprise Architecture narratives or methodologies. Instead what has been taught and discussed has been documentation/representation practices. This is equivalent to teaching drafting standards. And when rules are discussed it typically has been around sizing of components, not selection and use. Occasionally one gets into discussions around implementations: Mainframe vs Network, Network vs Cloud, etc. These are typically religious wars from vendors attempting to justify why their products are better or inclusion in the latest technology theme.

Hoping to avoid such conflicts, the first part of this text is aimed at providing the theoretical foundations for the reader to move past such religious wars by establishing the coordinate space for discussions on why and in what context to select and use.

Strategy, Resource, and Structure – the three dimensions of Organizations

Keeping with the theme of threes I believe that Strategy, Resource, and Structure are the primary dimensions of this abstract space where enterprise can be defined. This may seem to go counter to the Zachman ontology, however, if one looks at the ontology in an architecture context, the various dimensions are actually views of an enterprise. Thus, each box in the framework is a projection of one or more of these primary dimensions.

Class Structures in Dimensions

One other aspect of these primary dimensions is that each is actually a family of instances based upon the context in which these are used. A simple example, there are corporate organizational structures, software structures, business structures, etc. Each describes the arrangement and relationship between components. These will be discussed further in each dimension section to follow.