What is Enterprise Architecture Debt and how to manage it? (Part 2: Pathology)

Previous part: The Concept

Where does EAD come from?

Why and when is the EAD made? Although virtually no organization is founded and managed to deliberately work in chaos and inefficiency, dealing with complexity and inefficiency is quite common in the world of business. So, where does EAD come from?

To answer this question, it is useful to consider the organization as a system comprising different interrelated building blocks. The various types of these building blocks are architecture elements (org units, processes, services, applications, etc.). Different architecture elements and relationships are usually described by a conceptual data model called an architecture meta-model. The following figure shows a simplified (and by no means, universally applicable) meta-model for organizations, modeled in ArchiMate:

(See my article “CBEA Basic Metamodel” for a more precise general metamodel.)

Any shortcoming in keeping the elements and relationships in the described ideal state (as shown in the meta-model) potentially results in the creation of an EAD item.

Here are some common types of EAD items:

1. Poor strategy support by capabilities

Business capabilities are essential building blocks of an organization that enable the execution of strategy. Business capabilities encapsulate all related organization’s resources, i.e. people, processes, and technology, required to make one or more strategies (course of actions) realized. (See my article “Capability-based Planning in 7 Moves! (1/7)”)

When there is not a sufficient set of enabling capabilities to support all strategic goals and courses of action, there is an EAD there. This kind of EAD could be easily figured out by an examination of the Course of Actions-Business Capabilities cross matrix or standard Strategy View of ArchiMate.

2. Capability immaturity

Not all business capabilities have the same level of maturity, at any given time. The more mature a business capability, the more it can deliver its services and support the business (See my article “Capability-based Planning in 7 moves! (2/7)”). Unassigned business capabilities to organization units or actors, undefined or poorly documented processes, or insufficient IT support for business capabilities make them immature, and hence incapable of supporting related strategies. These conditions typify another kind of common EAD.

3. Business services inadequacy

Business capabilities are expected to provide adequate business services to business actors (including external stakeholders) or other business capabilities, to enable the whole enterprise to do its functions. When there is a shortcoming to providing required services by any of business capabilities, then there is an EAD in place. Possible causes are immaturity of business capabilities (especially newly established ones) or incomplete definition of a business capability scope.

4. Inadequate processes

Any business service should be realized with the corresponding process(es). In some organizations, especially the ones with poor process culture, there are not adequate realizing processes for some (or all) business services, that result in a common form of EAD. Too rapid change pace of organizations involved with digital transformation, which forces the business to provide new services before the complete design of supporting processes, is another common cause of this type of EAD.

5. Lack of IT support

In general, business processes should be supported by appropriate application services. Any process with no or insufficient supporting application service indicates an EAD item. This EAD type results from insufficient IT support of the business.

6. Improper data access

Business processes must have access to the right data, to properly and efficiently working. The required data are represented by business objects and data objects in the enterprise architecture meta-model. If any process does not have access to the required data, architecturally and systematically, then there is an EAD item in place.

7. Messy application landscape

A broad range of EADs are related to the enterprise application landscape. Applications not providing required application services, overlapping or redundant application services from many applications, and applications with obsolete, hard-to-maintain technologies are common symptoms of this kind of EAD.

The above list of EAD types could be extended by analyzing other relationships between all architecture elements. Cross-reference models (usually, matrices or layered diagrams) extracted from the architecture repository can be used to diagnose and detect EAD items in any architecture state.

Next part: Dynamics of EA Debts.