Business Architecture, Enterprise Architecture, and Human Communication

Realization has occurred that there is not one, but at a minimum, three sets of interpersonal communications that exist in an organization – (1) Business people talking to business people, (2) Technology people talking to technology people, and (3) Business people talking to technology people, and Technology people talking to business people.

In order for these communications to actually successfully occur and an exchange of understandings to take place, there is “implicitly” a set of prerequisites that are in place. We hope a very brief analogy will help understand what is needed in our enterprises to make these communications productive and successful.

You and I have implicitly agreed to communicate with a common “frame of reference” – the English alphabet of 26 mutually exclusive and collectively exhaustive letters (at least in the United States!). Out of the common frame of reference, come numerous words that have been developed and generated from these 26 letters – Oxford Dictionaries suggests somewhere around 750,000 words exist, all with single or multiple definitions. Most of these words have multiple definitions, and we, therefore, need a context for each of these words, to completely understand each word. This context is usually a sentence developed from the English language grammar – a methodology – how to construct sentences, paragraphs, etc. This methodology is usually a pattern for a simple sentence, which is subject – predicate, or subject – verb – complement.

In order for you and I to communicate within any of three sets of communications, we need a similar set of understandings – a frame of reference, definitions, context, and methodology. With this frame of reference, we can then state our understandings explicitly. Our “frame of reference” is The Enterprise Framework TM (www.EACOE.org), an elaboration of John Zachman’s work. This frame of reference has 30 mutually exclusive and collectively exhaustive “letters” – artifacts.

Using the Enterprise Framework, we define Enterprise Architecture as explicitly describing an organization through a set of independent, non-redundant artifacts, defining how these artifacts interrelate with each other, and developing a set of prioritized, aligned initiatives and roadmaps to understand the organization, communicate this understanding to stakeholders, and move the organization forward to its desired state. This is the basis of communication and understanding between Business people and Technology people.
We define Business Architecture as explicitly representing an organization’s desired state and as-is state, through a set of independent, non-redundant artifacts, defining how these artifacts relate with each other, and developing a set of prioritized, aligned capabilities needed to meet the organization’s goals, communicating this understanding to stakeholders, and advancing the organization from its as-is state to its desired state. This is the basis of communication and understanding between Business people.

Each of these architectures is explicitly defined, symbolized, and represented uniquely (we do not have numerous definitions for our “words”, is what we are trying to suggest – a bit purer than dictionaries). Once we have this frame of reference, and explicit set of definitions, we can now go on and precisely develop sentences – in our case, what any given “XXX Architecture” is. We have represented and defined twelve architectures and architect roles in an enterprise that collectively define Architecture Models in an enterprise. These architect roles and architectures are: Enterprise, Business, Policy/Rule, Rule Assertion, Process, Data, Roles, Workflow, Logistics, Technology, Event/Sequence, and Event State. Each of these architectures is defined by scope, granularity, responsibility, interactions, naming, graphical notation, templates, and deliverables (these are in our Enterprise Framework Practitioner’s Guide).

A second set of architectures in an enterprise also exists – we refer to them as Implementation Architectures.

We have to date defined 138 of these Implementation Architectures, of which Information Architecture, Information Technology (IT) Architecture, Service Oriented Architecture, and Application Architecture, are examples of these types of architectures. Based on the Enterprise Framework, there are 684 possible Implementation Architectures (without vendor specific “architecture” titles). It is unknown how many Implementation Architectures individuals or organizations will “invent”, as this “creativity” seems to be endless without a frame of reference – “only one more XXX Architecture will solve all needs!” seems to be the mantra! Implementation Architectures are combinations of Architecture Models in an enterprise. Every time someone comes up with an “XXX” Architecture phrase (especially without defining their frame of reference), we see it generally falling within this class of architectures – Implementation Architectures. One example and elaboration of this class of Architectures is our definition of Information Architecture as the artifacts contained when combining Process Architecture and Data Architecture into one Architecture representation.

With one frame of reference, we can improve and articulate the communications between Business people and Technology people, enabling communications that are explicit, precise, and human consumable.