Business Architecture, Enterprise Architecture, and Human Communication

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.

A B L ™ – Architected Business Language

A B L ™ – Architected Business Language

The Architected Business Language A B L ™ was developed to address the eight key elements to successful business understanding and communication. These eight elements provide the underpinning of the three “sets” of communications that exist in an enterprise or organization – (1) Business people communicating with business people, (2) Technology people communicating with technology people, and finally (3) Business people communicating with technology people, and technology people communicating with business people. The overarching objective of A B L is to provide a communication mechanism that allows business expression of a problem or opportunity, that could potentially be transformed by technologists into mechanized or manual solutions. In understanding these objectives, the underlying design philosophy is to “keep it simple” –  avoid unnecessary complexity.

The eight essential elements to successful business communication are:

The Five Minute RuleA StructureThe 7±2 RuleClarity in ExpressionConsistency in ExpressionA Medium that is easily graspableExpressive Relevancy - ConciseTimeliness
In the internet driven, multitasking, interrupt driven world we live in, we have learned that imposing extensive new requirements of any kind on our business partners, subject matter experts, and customers just does not work – and frankly, correctly so. Teaching our business partners a modeling language or symbology with dozens of constraints, elements, arrows, “crow’s feet”, and accompanied by a 400 page manual will not cut it! A good question directed toward ourselves as architects or technologists, is why should we impose “anything” on our customers – after all, they are customers (partners?), not “users”! The Five Minute rule recognizes that we must, and we can communicate with only five minutes of explanation or learning, on something that may be new to our business partner. A B L was designed with this in mind – human consumable and understandable with five minutes or less of introduction, and yet robust enough for transformation and translation by technologists. A B L has three essential design elements – (1) a consistent naming convention, (2) a graphical notation, and (3) a template-assisted definition for each artifact necessary to understand and communicate.
How the interactions between business personnel and technologists are structured will determine the clarity of the understanding that results. Structure comes from the three essential design elements discussed previously – naming convention, graphical notation, and template-assisted definition, and the ability of humans to absorb and understand anything of complexity – the 7±2 Rule – discussed next. The structure should allow for both summarization and granularity – depending on the audience in the dialogue.Furthermore, structure comes from a defined “frame of reference” – a framework. A B L is based on The Enterprise Framework TM. The Enterprise Framework provides a set of collectively exhaustive and mutually exclusive artifacts that can be used to describe business representations to business people, and transformations from these business representations to technology personnel. Without a “clean” Framework, technologists and business personnel tend to keep coming up with “new” representations, because they are looking for the “one” representation to serve all needs. We suggest that this search is fruitless. If you have had the pleasure, privilege, or frustration of building a house, as an example, you know that to represent something as simple as a house (as in comparison, describing or representing a business strategy or business) takes multiple drawings. Elegant structures based one the Framework are simple to understand.
We as humans have a finite capacity to hold information in our short-term memory – we are not computers! Our brains retain information in “clusters” or “groups”. Numerous studies have determined that these clusters or groups are best understood if they are “limited” to seven plus or minus two items within a group or cluster. This extremely important fact requires us to “represent” our thoughts to business people within these constraints to allow maximum understanding. Human communication requires this structure in long documents, graphical representations, or general communications. So, for the most impactful communications and understanding, the structure would “cascade” to whatever level of depth is required: • 7±2 sections (or elements in an overall diagram) • 7±2 sub-sections in each section, etc. (or elements detailing each higher-level element) If you end up with a dozen sub-sections in a section, either consolidate two or three sub-sections in to one, or create a new section to maintain this structure.
Clarity is simply being on point. A B L has no elements that are not fully traceable from the business descriptors to potential end solutions. Providing a confused message to your business or technology personnel only confuses them and your message will be ignored, or worse, misinterpreted.If you are communicating about a marketing event – stay on point. First describe the marketing event. Then describe the relations of this marketing event to others that may be an influencer on this event. Given the right frame of reference, this is all that is required to sufficiently describe the marketing event from a business perspective. Three additional, more technology focused descriptors are needed to fully describe a solution (not the focus of this article), and these are focused on a technologist understanding: a technology neutral description which transforms the business understanding into “technology neutral” representation; a technology specific representation; and a solution specific understanding. It is better and clearer to create separate representations for separate stakeholders.
Nothing upsets people more than inconsistency of your representations. A B L defines a consistent vocabulary that is clear and unambiguous by defining each term used, providing extensive examples, templates, and with The Enterprise Framework, a mutually exclusive and collectively exhaustive set of artifacts that are each human consumable. As an example, endless and fruitless discussions whether something is a strategy, or an objective, or a tactic, or a performance indicator, or etc. are removed by fully defining each artifact and its relationships. Without a frame of reference, one person’s strategy is another person’s objective. Definition of terms is just not enough.
The message and the medium are both important. Specialized “tooling” and/or software actually get in the way of business personnel understanding the message. Frankly, why should business people learn a special tool to understand themselves?! The sequence of events should not be “find a tool or software, and then fit the problem to the tool”, but to start with a frame of reference that this complete, and deliver an architected understanding in a medium that takes less than five minutes to understand. Too often, technologists confuse their need for or use of a tool or software, with presenting understanding to business personnel. Additionally, if the only tool you have in your tool bag is a hammer, everything starts to look like a nail. That is why someone invented a toolbox. The medium that should be used for human understanding of a business opportunity or issue is one that provides the greatest likelihood of comprehension, the greatest accuracy, the least possible ambiguity, at the lowest cost, shortest learning curve, and shortest time to delivery. There is little value from a business perspective other than these criteria.
Without a frame of reference – a Framework that is complete and clean – the inventive juices of technologists will continue to look for or “invent” the one representation that will solve all needs. Realization is occurring that there are six fundamental and exhaustive set of understandings that describe simple or complex opportunities or issues. Years of history have proven this to be the case. With the five minute rule and the 7±2 rule, to date, these six “abstractions” can describe anything in an enterprise. We know that some may see this is quite a bold statement, and some reading this paper will, of course, be skeptical, but four decades of practice, with the main objective of the practice addressing business understandings and opportunities, have proven this to be the case. These six abstractions, very briefly (very briefly, and without detailed elaboration in this paper), are Strategies and Goals, Processes and Activities, Materials and Things, Roles and Responsibilities, Locations and Geography, and Events and Triggers. As a further example, our practice has found that the key element for increasing an organization’s agility, is the understanding and representation of Events and Triggers. Suggesting that an organization’s agility can be significantly enhanced by “handcrafting software solutions smaller and faster”, does not make much sense as an organization’s strategy for growth and competitiveness.
Psychologists call remembering the first few items presented as a “Primacy Effect”, and remembering of the last few items presented as a “Recency Effect”. A B L design, with the other accompanying characteristics described in this paper, provides the underpinnings to timely communications. Business personnel (along with all of us!) differ to the degree of how dominant each effect is on their understanding of an opportunity or issue.Additionally, each time interactions between business and technology personnel occur, anchoring on the previous status and understanding, and providing a continuous and traceable path to the most timely information is imperative. Continuing to remember the limits that “humans” have to remember context and content with all of the “information” that is thrown at them on a daily basis, providing current and timely information, within the context of previous interactions, will maintain and grow understanding, trust, and partnerships.

In summary, the Architected Business Language (A B L) provides a unique, quick, simplified, relevant, and precise language to facilitate business and technology communications. Only the essentials, without needless complexity.

Measuring an Organization’s Capability Ability⧉

Measuring an Organization’s Capability Ability

Capability Defined:

A capability is an integrated composite of goals, processes, data, roles, locations, and events that are organized to drive a company’s strategies to a specific desired outcome. Examples of names of capabilities includes development of products, management of vendors, protection of intellectual capital, development of web sites, management of logistics, buying of merchandise, management of customer relationships, innovation of technologies, marketing to international locations, management of brands, extensions of brands, innovation in manufacturing techniques, etc. The list of names of capabilities is endless! Of course, to completely and definitely understand a capability, an explicit definition of each capability is required. At a minimum, the definition of a capability must include the names and definitions of the goals, processes, data, roles, locations, and events that represent that capability.

An example of capability is shown below:

Capability Ability:

We often see an organization’s capability ability measured by only one number or measure. Since a capability contains a number of attributes or artifacts that the organization has various competencies within, a measure such as this is quite misleading. This is like telling someone that the average height of building in New York City is seven stories – quite limited in usefulness!
To accurately gauge an organization’s ability/competency of a capability, a truer picture of each “artifact’s” competency is required. As an example, an organization may be good at doing the process “Outfit Sailboats”, but has difficulties with the process “Prepare Charters”. Or, an organization may be good at achieving the goal “Achieve Zero Sailboat Complaints” but the organization’s “Charter Operations” roles are poorly defined and executed.

In order to accurately provide organizational guidance for increasing a specific competency, we have developed the Competency Radar TM – an easy to understand visual that precisely provides an organization with this guidance. An example of a Competency Radar is shown below:

If 100% of the Preparation of Boat Charters competency was being achieved, the six measures would all indicate “100”. This Competency Radar map would indicate that the organization was meeting approximately 50% of its Goals objective, 30% of its Process objective, 80% of its Data objective, 10% of its Roles objective, 70% of its Locations objective, and 60% of its Events objective. Further details can be displayed for each of these attributes, as shown below:

This Competency Radar, related just to the Data objective, shows 50% of the Sailboats data objective, 30% of the Suppliers data objective, 80% of the Maintenance data objective, 20% of the Customers data objective, 70% of the Preferences data objective, 60% of the Charter Data objective, and 40% of the Sales data objective being achieved, from a desired score of 100 from the Preparation of Boat Charters competency. An organization can quickly, and precisely, determine the path to capability competency by addressing areas of improvement identified by these Competency Radar maps.

If you are using analyzing capabilities in your organization, Competency Radar maps are essential!

Business Enterprise Human Communication

Business Enterprise 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.

Webinar: Addressing Coding -Your Highest Security Concern

Every day we hear about new breaches into our computer network and systems.  And who knows what we are not hearing about!

The reactions are always the same:  it’s the opposition political party, it’s foreign governments, it’s “professional hackers”, it’s our competitors, it’s, it’s, it’s them!!

Perhaps instead of looking outside for the culprit and at the symptom, it is time to look in the mirror, and at the cause.

Cloud Sales Are Booming: So Why Are Adoption Rates Down?

via the Wall Street Journal

Comparing Two Leading Enterprise Architecture Methodologies and Frameworks

This article describes eight criteria used to compare and contrast the two most practiced approaches to Enterprise Architecture; from The Open Group (TOGAF) and
The Enterprise Architecture Center Of Excellence (EACOE).

Eight comparison criteria are described and used in the comparison: (1) the development of Business Initiatives (projects), (2) the provision of Directed Guidance, (3) Consistency and Simplicity in its approaches, (4) Structured, Precise Definitions for Human Communication and Understanding, that Lead to Technology Enablement, (5) Clarity and Reason in Modeling, (6) providing Value in the Transformations from Model to Model, (7) Skills Acquisition, and (8) understanding Business’ Multiple Architect Roles.

The author of the Comparison is a Certified Architect by both TOGAF and EACOE.

BOOK RELEASE: Reaching the Pinnacle: A Methodology for Implementing and Managing Enterprise Architecture

“Reaching the Pinnacle: A Methodology of Business Understanding, Technology Planning, and Change (Implementing and Managing Enterprise Architecture)” by Samuel B. Holcman explains the detailed process of building an enterprise architecture.

Kent State University Students Earn Enterprise Architect Certification as part of Coursework in the School of Digital Sciences

Through a unique arrangement between Kent State University and the Enterprise Architecture Center Of Excellence (EACOE), undergraduate students at Kent State University can now earn Certification as Enterprise Architects. The first group of students earned the Enterprise Architect Certification in December 2012.

Pinnacle Business Group, Inc. donates $3.2 million to Penn State Center for Enterprise Architecture

Through a gift-in-kind to Penn State’s College of Information Sciences and Technology, the Pinnacle Business Group, Inc. and its subsidiary, the Enterprise Architecture Center Of Excellence (EACOE), an enterprise architecture (EA) service provider and certification body, is contributing software and content to support research and educational initiatives in the college’s Center for Enterprise Architecture. The commitment is valued at $3.2 million.

WordPress Video Lightbox