Enterprise Architecture Discipline Classification

Like the discipline of Physics which has multiple branches of practice, so too Enterprise Architecture should distinguish branches of practices such as Theoretical and Applied Enterprise Architecture.

In Physics: Applied physics is a general term for physics research which is intended for a particular use. An applied physics curriculum usually contains a few classes in an applied discipline, like geology or electrical engineering. While

Theoretical physics is a branch of physics which employs mathematical models and abstractions of physics to rationalize, explain and predict natural phenomena. The importance of mathematics in theoretical physics is sometimes emphasized by expression “mathematical physics“.[note 1]

The advancement of science depends in general on the interplay between experimental studies and theory. In some cases, theoretical physics adheres to standards of mathematical rigor while giving little weight to experiments and observations.

Again like Physics, the partitioning of the discipline into categories will likely require a richer taxonomy that the current hierarchy in use today which has its basis from the Zachman Framework.   This does not mean that the Zachman Framework and derivatives from it are invalid views.  However, looking at the Framework from a broader perspective may yield a more comprehensive ontology that could fill in the gaps between business theory and I.T. design and executional elements.

Today, as I continue my research in the arena I was watching various Black Hole and Physics programs on the Science Channel.  As I listened to some of the arguments and history regarding Black Holes and the physics behind these discussions it sounded much like some of the discussions I’ve heard over the years and more recently in the Google Group Enterprise Architecture Forum.   All of these ranged around what should be or not be in Enterprise Architecture verses Information Technology or Infrastructure Architecture.  The various sides all wish to include or exclude various areas such as BPR or I.T. and its subdivisions or business models or finance.  Add to that the difference between theoretical and applied ad EA is a mélange of sub-disciplines that are still to be related together into a cogent body of knowledge.

While initiatives such as TOGAF are attempting to amass a body on knowledge what I’ve seen is an orientation that still approaches the topic from a strictly I.T. perspective, projecting into the business domain from that orientation.  This has the effect to limit the non-I.T. contributions that are, in my opinion, just has valuable.  Business Models and Strategy, Organizational Design and other areas all have a contribution to the “Architecture” of an enterprise and therefore should be included in such a discipline.

As initiatives such collaboration and social networks gain importance so too shall these other soft sciences and sub-disciplines increase in priority and influence in how an enterprise is structured and operates.  That suggests that these are architecture components for enterprise, like light and space are architecture components in dwelling architecture.

The Meta-Framework for discipline definition I proposed prior a approximately decade ago at ZIFA was Jon Lang’s used in the field of Dwelling architecture. This does not replace the Zachman Framework but places a context for it to operate in to help distinguish between theoretical and applied, prescriptive and descriptive.


Translating Business to Enterprise Architecture: Methodology Activity #1

Converting Business definition to an enabling Enterprise Architecture is not a direct mapping.  Business definitions do not neatly fit into a structural taxonomy that most Enterprise Architects use.  Business definitions do not fare well in process oriented ontologies either.  The nature of business definitions is, as social constructs, these entities are multi-dimensional.  Thus any attempt to document has often met with gaps in perception that appear based upon the orientation of the modeler.  If you’re a structural focused, dynamics are missed.  If you’re process focused you might miss structures or goals.   The Zachman Framework, givens insight to this issue.  However, the establish linkage between on cell to another with the same robustness as in mechanical design has eluded the field for two decades.  While there have been attempts as creating production rules to project from one cell to another, the linkage and visualization has still to be accomplished.  This is not a failure of the framework, but of the representation systems we have at present.  The situation only gets worse as we move down the hierarchy from owner to builder the framework.

 Added to this lack of dimensional integrity between representations systems are the differences in language constructs at each level.  The structures and dynamics at each layer and within each dimension are substantially different due to context.   This until a unified representation system can be developed translation and design will always require human intervention to interpret and unify.  This inconsistency acknowledged a team can still overcome the effects of this situation.  This first activity addresses some of the intermediate forms to translate between the hierarchy levels previously identified in the framework. 

 At the Owner level, the common business model representations used have typically been based on those developed by Michael Porter or Adrian Slywotzky.  These models represent business activities on a broad scale and despite the author’s clear definitions, have merged activities and the organizational structures that accomplish these as a single construct. The Michael Porter models define how an enterprise competes in the world.

Adrian Slywotzky’s model describes how an enterprise creates and captures value within the business world.

Converting these constructs into I.T. Infrastructure Designs is rather significant challenges as the gap between these concepts are not direct translations.  Therefore Enterprise Architects should focus on intermediate forms that bridge these gaps.  One intermediate form that bridges this gap is defining capabilities.  During the late 1990s and early 2000s a method call Strategic Capabilities Network was introduced.  This technique has staff define and relate capabilities to the activities and functions used the business models most corporations use.  These capabilities are closer in concepts to the processes and applications that I.T. Architects use.  Thus mapping between functions and applications through a capabilities network provides a semantically rich association that can be discussed with business owners enabling them to understand how the I.T. Architecture will enable the functions needed to fulfill strategy.