Enterprise Architecture at Chick-fil-A
A few years ago, I participated in a fun panel about the relevance of Enterprise Architecture (EA) in a cloud-centric, product-focused, DevOps world.
We discussed some existential questions for EA such as: Does an Enterprise Architecture practice even make sense anymore? If it does, what value does it bring to the building of a software organization and to the business it serves?
At Chick-fil-A, we have maintained a conviction that EA is still critical — if not increasingly so — to effectively build and scale a technology portfolio while balancing speed of delivery and long-term organizational health.
Our Purpose and Mission
It may be cliché, but we’ve drafted purpose and mission statements, and while you’re probably rolling your eyes right now, allow me to share why we spent time developing each.
First, we see our purpose as our long-term (10+ year horizon) reason for existing as a team. Our mission is what we are attempting to achieve over the next several years considering our purpose as well as current realities, challenges, and opportunities in our business.
Our Purpose
Our purpose statement for our Enterprise Architecture practice is as follows:
“The Enterprise Architecture team exists to ensure Chick-fil-A employs a technology strategy that enables our most important business outcomes, focusing disproportionately on cross-audience initiatives and foundational technology capabilities. We continually monitor our business landscape and the broader technology landscape and craft vision for what the future could look like.”
Our Current Mission
To “Mirror healthy business growth with healthy technology growth and enable our <strategic business strategy> to thrive”.
How We Plan to Achieve this Mission
1. Maximize readiness to respond to business growth and sweeping business landscape changes. We enable rapid response to sweeping business-driven changes like Market Ecosystem, International, Entities, or environment-driven changes like a global pandemic or changing consumer expectations. We ensure critical business and technology capabilities are not developed in silos. We advocate for a technology portfolio that is ready to scale with business growth.
2. Bring awareness, context, and strategy to cross-audience technology opportunities. We bring a cross-audience and architectural best-practice perspective to our build and buy technology decisions. We develop and socialize “essential” architecture best practices while preserving audience team autonomy. We inject ourselves into business and technology solutions that are cross-audience in support of healthy growth and market. We bring a perspective on the big picture across the enterprise.
3. Define the future of our cross-enterprise technology landscape (the “technical what”). We marry our CFA context with the emerging technology landscape and explore new opportunities. We consider people change along with technology change. We equip and empower others to leverage our full technology portfolio. We own the technical what when cross-audience technology decisions are in play. We deploy in support of our DTT Transformation Priorities.
If these were simply written down on a page, eye-rolling might be appropriate. However, we have been very intentional in socializing our purpose, mission and engagement model across our product ownership and engineering leadership so that we are all working under the same assumptions. It also brings alignment to our team on what our role is in the organization. Given these benefits, we have found it an effective tool and would recommend it to others running Enterprise Architecture practices.
How Our Practice Works
Next, we’ll talk about our engagement model. Today, we divide our architecture practice into three pillars:
- Business Architecture — Part of our team is focused on consulting with our internal audience teams (e.g. Operator/Team Member system, Staff-facing systems) and large-scale initiatives like international expansion. While doing so, we help define business capabilities, map domains, and advocate for our core principles (more later) like composability.
- Customer Architecture — Part of our team is dedicated to our customer digital experience (e.g. CFA One app, API backend, Point-of-Sale, Food Delivery enablement) architecture.
- Core Technology Architecture — Part of our team focuses on our internal priorities (things like advanced analytics/ML, Automation) and on the emerging technology landscape, looking for ways to assist the business in reaching their goals by informing them of new things that technology might make possible for the business.
In all cases, our goal is to embed ourselves deeply within leadership teams, product teams and engineering teams so that we are all outcome-focused (not ivory tower). We operate mostly by influence as opposed to authority which is both rewarding and challenging for the team.
Our engagements can be either push or pull, but in either case, we prefer to establish expectations that we will play one of the following roles:
- Informed Party — Are made aware of initiatives and the approach but agree to leave decisions to the team, providing the original scope doesn’t change.
- Trusted Consultant — Weigh in on the initial direction and design and are brought in periodically as larger/directional decisions need to be made.
- Design Partner — Tightly connected to the team in a weekly (or sometimes daily) way, assisting in strategic as well as solution-level design decisions. This engagement type is limited to initiatives that have the broadest enterprise impact.
What we are not looking to do is dictate the exact future of technology, force compliance with architectural patterns, give a stamp of approval, and walk away for good. On the contrary, we want to always be learning about our business, its needs, and the ever-changing technology landscape. Enterprise Architecture represents about two percent of the staff in our IT department, so we will almost always end up in a better place by listening, learning, and partnering instead of thinking we know better and dictating the way forward. This is a tension we manage as we think about our engagement across the business.
Our Principles and Governance*
One of our cultural principles at Chick-fil-A is “freedom in a framework.” As Enterprise Architects, we seek to empower people close to the work to make as many choices — the freedom part — as possible. However, this exists inside a framework that ensures we do certain critical things in a particular and consistent manner for the long-term good of Chick-fil-A.
Architecture owns or contributes to a lot of the components of this framework, but most significantly in our Enterprise Architecture principles. These are the few non-negotiables that everyone must follow. They do not change very often. Today, our principles are:
- Maximize cloud first
- Steward our tech portfolio and minimize long-term technical debt
- Design for composability: Expose technical and business capabilities as consumable services
- Implement loosely-coupled systems and services
- Treat data as an enterprise asset
- Build vs. buy: Buy when possible, build when necessary
- Design and test systems for seven architectural pillars (Usability, Maintainability, Scalability, Availability, Security, Portability, Recoverability)
*Each principle has a short write-up explaining how it works and why it’s important. I have left those out for brevity, but please let us know if you are interested in seeing more by commenting below.
There are no real surprises here, and as you can see there is a lot of room for autonomy within these rails. We also have guidelines around approved build cloud environments, programming languages, etc. within our larger framework.
Influence vs. Authority
We could also frame this as a discussion of influence vs authority. Generally, we strive to influence outcomes across our department and business and strive to let the merit of the ideas we bring forth drive their adoption. However, with our architecture principles, we also have authority to enforce them. We “score” (simple red/yellow/green) our areas of engagement according to alignment with these principles so we know how well we are influencing as an Enterprise Architecture practice. We acknowledge that sometimes a principle violation could be a good business decision and we are perfectly okay with that idea. This is, in essence, a simple model for calculating and viewing risk of our technology systems and assets across a large organization.
Are these principles too general to be useful? No, and we have had a lot of very productive conversations with product teams and business areas based on these principles. We see occasional violations and we work hard with the owners and with leadership to figure out the best path forward. Sometimes we may decide to do nothing and take the risk, which is okay. Other times we may decide to pivot and make architectural changes.
Imagining Life Without Enterprise Architecture
What if we were not a team? What if there was less consistency across teams? What if nobody was intentionally advocating for our Enterprise Architecture principles? What if nobody was there to consult our audience teams?
After lots of honest assessment, we truly believe that there is unique value-add to an organization that deploys a team of individuals who are incentivized to look at the enterprise as a whole, even in a product-centric, DevOps, engineering-team-lead-as-product-solution-architect world.
Why? Let’s evaluate the different types of digital teams and their focus/incentives.
· Product teams are rewarded for great products and new features, so they focus on the product.
· Platform teams are rewarded for stable, capable, modern platforms, so they focus on their platforms.
· Audience teams (personas like Customers or Restaurant Team Members) are rewarded for great experiences in their audience, so they focus on their audience.
Each role above is working to optimize around their area of concern, and doing a great job! But, what happens when objectives are in conflict between teams? What happens when teams consistently choose micro-optimizations at the sacrifice of macro-principles? Over many years, lots of small deviations by many teams can slowly erode the health of the technology in an organization and lead to a world of drag, lost agility, brittle solutions, and big technical debt.
So…
We have an Enterprise Architecture team that is rewarded for enterprise-wide health and enterprise-wide technical capability, so we are focused on the enterprise.
As a bonus, we can also increase velocity of teams by solving the appropriate problems once and for all and drive efficiencies and re-use of services and patterns across products, platforms, audiences, and programs.
Conclusion
We believe Enterprise Architecture can be a unique driver of technology and business change and advocate for healthy technology growth in a rapidly growing business. Is your organization still practicing Enterprise Architecture? How do they do it? Do you find it empowering or burdensome? We’d love to hear your thoughts in the comments.
