Abstraction, in which general rules and concepts are derived from the usage and classification of specific examples, is a fundamental skill for enterprise architects.  Here, I begin with an analysis of EA responsibilities and thought processes, and then show the importance of abstraction in all of them.  Finally, I end with a recommendation that I hope will make you more effective as an enterprise architect.

There are many definitions of enterprise architecture.  This one, from Gartner Group, is my favorite: 

Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve targeted business outcomes that capitalize on relevant business disruptions.

I like this definition because it focuses on leadership, action, and value.  It positions enterprise architects as skilled navigators of business and technology change.  EA leadership requires thorough analysis and planning to formulate constructive responses to disruptive forces or to build and maintain repositories and processes that make enterprises more agile, and requires communication in many forms, from relationship-building and requirements elicitation to documents and presentations.

To analyze, plan, and communicate, EAs begin with computational thinking, which is concisely described by the BBC as having “four cornerstones”:

• decomposition – breaking down a complex problem or system into smaller, more manageable parts
• pattern recognition – looking for similarities among and within problems
• abstraction – focusing on the important information only, ignoring irrelevant detail
• algorithms – developing a step-by-step solution to the problem, or the rules to follow to solve the problem

To adequately define EA thought processes, however, computational thinking must be enlarged to include business problem-solving, and its fourth cornerstone must encompass architectures, which, per the ISO/IEC/IEEE 42010 standard, can be described with

• An identification and overview of the system-of-interest. These systems may involve any or all of people, processes, information, and technology.  A system-of-interest may therefore be an entire enterprise or any part of it.
• An enumeration of the stakeholders and their concerns that are relevant to the system-of-interest.
• A set of viewpoints. Each viewpoint is a template that specifies an audience of stakeholders, a set of their concerns to be addressed, and the kinds of models used in the viewpoint.
• A conforming view for each viewpoint.

Enterprise architecture begins with the identification of a disruptive change or persistent problem, or with managerial recognition of the need for a new or improved ability to respond to change.  An enterprise architect is typically given a business or technology problem or responsibility for guiding a particular part of their enterprise.  Alternatively, an enterprise architect may proactively identify a disruptive change, and gain support for focusing their effort on addressing that change. In each case, they must, often very rapidly, gain relevant expertise.   Abstraction is required to select what must be learned across complex disciplines and functions as well as what is not known and must be discovered.

Once the enterprise architect has a clear sense of the problem, they must depict the baseline situation through (per ISO/IEC/IEEE 42010) a description of the system-of-interest, an enumeration of stakeholders and their concerns, and a set of views, each governed by a viewpoint, that address stakeholder concerns.   Each viewpoint corresponds to a manageable (understandable) part of the problem or domain, and each view abstracts the information necessary to address the targeted set of stakeholder concerns. 

To establish the baseline architecture, develop a corresponding target architecture, and develop a roadmap with a sequence of transition architectures between the baseline and target, the enterprise architect usually collaborates with specialists.  The enterprise architect therefore often develops a glossary that abstracts the most important concepts and establishes a common definition that applies to all relevant processes and systems.

Target architectures are typically based on combinations of existing industry and enterprise patterns as well as architectural innovation, which is the creation of a new pattern, or solution to a class of problems, for an enterprise.  Pattern reuse and architectural innovation both involve recognizing and abstracting the most important aspects of a problem, comparing them to available solutions, and communicating them in views for different stakeholders.  A marketing executive, for example, generally appreciates different abstractions than a software engineer.  

Abstraction is critical whether an enterprise architect is decomposing a problem or domain into manageable parts; recognizing patterns or creating new ones; developing architecture descriptions; or communicating with stakeholders.   Proper choices of abstraction can make or break an architecture effort.

Furthermore, new enterprise architects may not be prepared to abstract appropriately.  Enterprise architects generally begin their careers in detail-oriented engineering or analysis roles.  In these roles, deliverables are typically consumed by peers or by managers trained in the same discipline as the individual that produced them.  As a new architect transitioning from an engineering role, I remember being asked by my manager to translate my solution presentation into business terms, going back to my desk and laboring over a new version for several hours, and then presenting it again to my manager, only to be told that I had merely used different technical terms. Even today, with decades of architecture experience, I find my first instinct is to include details that were important to me in coming up with a solution, rather than those that are important to the stakeholders to whom I must communicate.  Sometimes, I correct these errors myself, and sometimes they are caught by others’ reviews.

Therefore, I recommend that you, in your role as an enterprise architect, pay close attention to the choices you make when abstracting information in your deliverables and informal communications. Are you including the information that is important to your system-of-interest, problem, and audience? Are you omitting the information that isn’t?

Authored by Iver Band, EA Principals Senior Instructor and ArchiMate Expert