Enterprise Architecture Matrix

How Enterprise Architecture Works at Chick-fil-A

by Brian Chambers & Eric Fisher

A few weeks ago we wrote about our Enterprise Architecture mission, purpose, and principles and shared how our practice currently works. Today, we will share more about how we view what “Enterprise Architecture” actually is and about the framework we developed to explain what it is and how it works in a large and growing organization.

EA in a Rapidly Growing Business

As Chick-fil-A has grown to become a fairly large organization, this growth has highlighted the need to bring together business context and technology expertise together in a way that crosses departmental boundaries or other potential organizational “walls.”

For many years it was possible for engineers, product owners, architects and business subject-matter-experts to have a shared context due to the smaller scope and scale. When we did have a context gap, it was practical to physically walk to a persons office to fill that gap with a brief conversation.

There were fewer systems, fewer people, and fewer processes. There was less organizational complexity. There was no COVID and work from home. Today, that is no longer possible in an organization our size.

Something like this is what I believe to be happening — as the business grows in size, complexity, and number of people, the ability to retain a shared context across the organization decreases and silos become more probable. This is not a statement about cultural / values alignment, but instead about functional work.

As we thought about this challenge of declining shared context, we also recognized a declining understanding across the enterprise of what our team's purpose is. As the business evolved, so did Enterprise Architecture; from a primarily technology-focused function to one that has and needs deep understanding of both the business and the technology.

This is especially true for our team, which is a group that has its roots in a Technology Architecture practice which may not be typically thought of as having a real understanding of the business.

We realized that we need to get really clear on what we do as an Enterprise Architecture team and help people understand how we add value to the organization, and get that message out into the business. We also needed to be able to clearly explain what Enterprise Architecture is in a way that is easy to understand across the company. It really is unfair to assume the organization sees things the way we do or understands our point-of-view unless we have done the difficult work of 1) crafting a clean and understandable story and 2) telling it to our stakeholders. Our team decided we needed a model to explain how Enterprise Architecture functions in our organization.

Enterprise Architecture — what is it?

We recently found two definitions of Enterprise Architecture that we really like, so I will share them both:

Enterprise Architecture (EA) is a discipline that manages conflicting approaches to success within large-scale organizations. It is devoted equally to the worlds of IT and Business. It introduces practical standards across departmental units and teams in order to streamline efforts with an intelligent sharing of resources (capabilities, data, etc). — LeanIX w/ some small additions by us

An Enterprise Architecture is a defined approach, selected from competing options, that determines how an organization’s functional domains and supporting technologies will interact with each other. It consists of disciplines around DATA, FUNCTIONAL PROCESSES, and STRATEGIC CONNECTIONS.

There are many paths to success (or failure). There are many technologies we can use. There is no “right” option. What will we choose to leverage? How will all of our functional areas work together? That is what we are here to help the business navigate.

EA Matrix

The EA Matrix is our answer to explaining what an Enterprise Architecture is and how the Enterprise Architecture team engages in different components of it. We would like to give a nod here to the Zachman Framework, which influenced us tremendously.

The rest of this post will unpack our Enterprise Architecture Matrix and explain what it means and how we use it. It may get a bit tedious going through each row / column, but if you think this may be useful to you, hang in there and keep reaching. If you already get it at first glance, feel free to skip to the very end.

Columns

The columns represent the collection of activities that take place across our Enterprise Architecture in the domains of Data (how data is thought about and managed), Function / Process (how our business capabilities and processes are supported by technology systems), and Strategic Connection (how all the things in the ecosystem relate to each other).

Rows

Lets unpack each of the rows…

Enterprise View

The enterprise view represents what the business cares about as it relates to data, functions/processes (systems), and strategic connections. These are things the C-Suite or other Senior Business Leaders care about.

• Enterprise Data Entities — what data domains are important to our business? That might be things like our restaurant locations, menu items, and sales transactions.
• Enterprise Business Capabilities— what business capabilities do we have (what does our business do)?
• Business Model and Strategic Goals — how does our business operate and what are the strategic goals we are pursuing?

Business Architecture View

The Business Architecture View is like a landscape design view. When we look at the Enterprise View, how do we start to support that with architecture and technology? The audience here is usually domain leadership, both in the IT function and in the business.

• Domain Data Architecture — How does data move across the enterprise to ensure decision-making-ready data is available, and data can be shared across silos / departments / domains to enable enterprise outcomes? How do data objects that have pieces scattered across domain boundaries get appropriately assembled into a composite view that the business understands?
• Capability Fulfillment Design — How do our business capabilities translate into a system portfolio that enables those capabilities to be executed successfully?
• Contextual Interplay of Systems, People and Partners — Explains how systems, people and partners come together to support CFA’s business model, operational model, and strategic outcomes.

Designer View

The Designer View is essentially a solution architecture view which could be taking place at a domain level (supply chain) or product level (CFA One App or Point of Sale). The audience here is generally our DevOps Product Teams.

• Enterprise Data Object —How do we view our data objects in context of a business capability rather than a functional view inside a system. This is the data payload that would be shared in APIs / Business Events across the enterprise (and with partners) and be the starting point for transformations for analytics purposes.
• System Solution Architecture — The technical solution (infrastructure, programming languages, monitoring tools) for a product or set of products that enable business capabilities to be executed. In short, the design of the system to meet the functional and technical needs of the business.
• Integration Architecture — How a particular product integrates into the larger Chick-fil-A ecosystem via external interactions and supports the overall contextual interplay of systems, people and partners.

Implementation View

The Implementation View is the hands on the keyboard executing the Solution Design from above (with lower level design tasks such as database schemas, pipelines, code, AuthN/AuthZ models, etc.). The audience here is our DevOps Product Teams.

• Functional Data Model — Design and implementation of a data model that enables a technical product to function and perform. Table designs, schemas, etc. are designed to meet functional and technical requirements, but also contemplate how data can be shared externally.
• Technical Product Implementation — Implementation of a product by a DevOps Product team including functional code, deployment pipelines, operational telemetry, etc.
• Product fit-for-purpose — Does the product or feature meet the requirements of the business?

Enterprise Technology View

The Enterprise Technology View is the platform view. What foundational technology enables all of the building above?

• Data Storage and Movement Technologies — Foundational technology capabilities related to data movement and storage.
• Technology Platforms and Capabilities — Establishment of baseline technology investments for platforms and technical business capabilities that serve our software building community (including business technologists) or business community respectively.
• Enterprise Technology Frameworks and Standards — Enterprise standards and guardrails that drive successful execution in a highly distributed and autonomous delivery organization. These ensure products are fit for purpose, that integrations are consistent and loosely coupled, and that organizational components interplay well to support Chick-fil-A’s Business Model.

Box Relationships

As you will begin to see, each of these boxes in the matrix builds on each other.

Top-to-bottom in the function/process column, we establish our key business capabilities that are important to the business (Enterprise View). Then we design a portfolio of systems to enable them to be achieved and track their fit and maturity (Biz Arch View). We design each of those systems in a way that meets our organizational needs (Design View) and then build the solution we designed (Implementation View). We build it on top of our Technology Platforms and Capabilities such as our Cloud Strategy or Kubernetes-based App Platform (Technology View).

Right to left in the Enterprise View, we have an established business model at Chick-fil-A and a series of strategic goals. We identify business capabilities that enable these outcomes, and we identify the data entities that are involved in those capabilities and ensure we understand them, master them as appropriate, make them discoverable, etc.

One more…

Top-to-bottom in the Strategic Connection space, we have our Business Model and Strategic Goals. The Contextual interplay of Systems, People and Partners is really our ecosystem that is built and orchestrated to support these goals. That is enabled by all of the systems thoughtfully integrating with each other using EA strategies such as “API First.” For each of these systems, we ensure we build or buy something that is fit-for-purpose for our business’ needs, whether they are industry standard (and therefore buy) or unique and differentiating to us (and therefore build). And all of this work happens within the guardrails of our enterprise standards and frameworks, such as Architecture Principles or our Digital Framework that includes security, identity, and other standards and best practices.

Together, all of these components make up Chick-fil-A’s Enterprise Architecture: the way our technology enables our business to achieve its goals and ultimately serve our Operators, Team Members, and Customers. As you can see, these relationships exist throughout the entire matrix, which is a beautiful thing when explaining what EA is and how it serves the business.

At Chick-fil-A, Enterprise Architecture is responsible for the technology health of the enterprise. We have responsibility in each box, but we manage the outcomes differently as we move around to each.

How We Use It

The Enterprise Architecture Team does not own and execute every one of these boxes. A true enterprise architecture has many different participants working in coordination to achieve the top line “Enterprise View” outcomes — successful delivery of enterprise data, business capabilities supported by technology, a successful operating model, and achievement of strategic goals.

Our EA team is part of the solution. We own some parts, collaborate on some, or give input to others.

We generally believe in starting at the top of the matrix in the Enterprise View (with the things the business cares about) and working down. When you start at the bottom (focused on technology platforms and capabilities or solution building and architecture and work up) it is easy to be the proverbial “hammer looking for a nail” and to seem “too technically minded” or “out of touch with the needs of the business.”

How the tool has helped us

Since creating this matrix, we’ve seen a few benefits worth sharing:

1. We have a clear definition of what EA is and how it works to help achieve business goals. We can use this to develop a shared understanding of our team and how we work (internal marketing).
2. In discussions about Enterprise Architecture (with Engineers, product owners, business people) we can identify what “box” we’re currently discussing and talk about what activities and deliverables are in the box, and how that box relates to the bigger enterprise picture. This drives clarity and helps people understand why we show up the way we do.
3. We can talk about the roles people are playing and how they show up differently depending on what part of the enterprise architecture they are engaging on. This has helped other internal teams understand our engagement model better and understand who they should work with and when.
4. We can point to “boxes” and say “lets partner together to make this happen.” This makes creating shared challenges way easier than it was before, both inside our department and with the business.

This approach to defining Enterprise Architecture behaviors and their relationships has proven very useful to us, and I hope you find it useful as well. If you have any questions about the EA Matrix, drop us a comment below.