Patterns in Implementing Enterprise Architecture - A Framework

Implementing a successful enterprise architecture is not easy. There are good reasons for failure I will talk about them in a separate article, but in this article, I want to discuss some behavioral patterns of implementing the EA practices in an organization, not necessarily all of them are a recipe for success.

The Framework

In this article, the EA practice is divided into 3 pillars.

• EA Governance
• EA Data/Repository
• EA Deliverables and Values

This classification defines a practical framework for an EA practice, given that the other pillars such as Analytics, Perspectives, Integration/Automation, etc. are streamlined to simplify the discussion.

Pillar 1: EA Governance

A practical EA Governance covers key domains such as selecting a framework and customizing it for “my” organization (metamodel), principles, defining the EA processes, enhancing the EA capabilities, cooperation and collaboration approaches, data currency mechanisms, etc.

Please note that there are references such as OpenGroup that provide a comprehensive definition of EA Governance, yet too much focus on this pillar turns the EA into an abstract practice. ?

Pillar 2: EA Data/Repository/Basic Views (e.g. Catalogs)

In a successful EA, the modeled baseline is an essential source on which all the analysis, road mapping, rationalization, future state planning, alignment studies, etc. will be applied.

The baseline could be implemented for a limited domain (e.g. just applications) or could be enhanced by covering multiple domains (e.g. Capabilities, Applications, Servers, Databases, People, Processes, etc.)

Not having a proper baseline for the organization causes a fragmented approach with parallel sources of the data, which ends up in huge discrepancies and potentially keeps everyone busy to deliver a simple catalog.

Bad practices in this pillar make the EA a middleman who keeps working on non-structural data such as Excel and Visio files.

Pillar 3: EA Deliverables and Values

In many cases, it happens that the EA practice is considered non-tangible! I.e. it doesn’t have enough deliverable, and the values of the practice are not clear enough.

A practical and systematic approach to implementing an EA practice could help to address this issue, while there are pre-requisites to it, such as understanding what the business’s concerns/needs are, and what is defined as a value (Cost, Efficiency, Innovation, Investment, Time to market, Customer Experience, etc.).

In an ideal scenario, EA should focus enough on making deliverables by understanding business needs, analyzing and designing them, and making proper views/artifacts/visualizations to help the business make the right decisions and turn the EA team into a trusted advisor.

EA Practice Implementation - Focus Patterns

Let’s assume that each of the 3 pillars has 3 focus levels. Low, Medium, and High. The focus level indicates the level of the EA team's focus on the pillar. I.e. how much time, effort, and resources the EA spends on the pillar.

To simplify the discussion, let’s put “M” (Medium effort for the pillar) aside, as it could imply the transition period between the patterns. In this simplified version here are some common patterns:

Pattern 1: LLL: Governance Low, Data Low, Deliverable Low

An LLL pattern illustrates the organizations with no practical implementation of EA.

Pattern 2: HLL: Governance High, Data Low, Deliverable Low

An HLL pattern illustrates the organizations with strong theoretical approaches (not necessarily practical) in the EA that focus too much on the books and references.

Pattern 3: LHL: Governance Low, Data High, Deliverable Low

An LHL pattern as one of the most common patterns, illustrates the organizations that spend lots of time maintaining inconsistent data and probably don’t have an actual central repository with a framework to organize their data/portfolios

Pattern 4: LLH: Governance Low, Data Low, Deliverable High

An LLH pattern is an ideal pattern that illustrates organizations with a sustained governance and data repository that serve the stakeholders to address their business needs and concerns.

Conclusion

Staying “High” in the Deliverable pillar to cope with the changes and business needs is essential, however, due to the phases of development the other pillars could go Low after a while. In a mature organization, an ideal scenario is that the main focus is on Deliverables (H) because the change in the business is constant, and the focus on the other pillars is low (L) because they are already stabilized/automated/collaborated.

Understanding the pattern your EA practice is following, helps strategize the practice accordingly.