EA Principles Series: Design for Composability
This is part 4 in our 7 part Architecture Principles series, and we’re going to discuss one of our core design principles for technology at Chick-fil-A which is “Composability.”
What is Composability in our context?
We know that that the word “composable” is used in a lot of different ways, and maybe most often it’s used to discuss a type of detailed technical design for a piece of software. For the sake of this article and our architecture principle, we are talking about something more at the macro-level. To us, a composable Enterprise is one whose key business objects (Think: Placing an order at a restaurant) are well-documented and readily available for use when building custom software or integrating with SaaS products. It’s like having a lego block for each thing we do as a business so we can build new, creative solutions with ease, or change blocks when the times change.
The next section dives into the details our our principle.
Why Composability is Important to Chick-fil-A
Anyone who has been in tech for long enough has likely realized the unpredictability of the future. We regularly deal with unexpected events (covid), threats, opportunities and industry disruptions. As we pursue a fully composable enterprise, this puts us into a much better situation to respond to our changing world without having to rethink (or rebuild) our entire tech portfolio. This enterprise agility has already served Chick-fil-A well over the last few years, and as we continue to evolve we know it will help us into the future.
Principle: Design for Composability
The text of our principle is as follows:
Composability is a strategy that enables an organization to respond to a dynamic, rapidly changing business environment with speed and agility by reassembling different business capabilities (like lego blocks) to create new experiences or support new business paradigms.
To do this, we proactively design a layer of standard, consumable interfaces (the Technical Interaction Layer) that represent the organization’s business capabilities. We employ an “API-First” strategy, but also establish other technical interfaces such as business events, libraries, or analytics extracts.
In preparation for composability, all teams that are partnering with a business domain should complete a business capability mapping exercise and develop a roadmap for the supporting Technical Interaction Layer.
Why? When teams provide standard technical interfaces to the business capabilities they own, it compounds the value of the work and increases overall organizational momentum by enabling all future product teams to leverage the interfaces whenever and however needed.
Commentary and Tradeoffs
While we do have an API-First mindset in all solution design in general, the composability principle is concerned primarily with the “Enterprise Business Objects.” These objects are those things that have broad, cross-team demand (e.g. Orders). For those objects, we then enable interfaces to execute the functions of those objects to do things (e.g. Place a new order)... As we consult with teams to build out these capabilities, we are creating the digital DNA of Chick-fil-A. Some of our services are even aptly named that way (Orders DNA).
This principle has probably been one that has driven the most broad-reaching positive impact within our company as it activates several benefits as detailed below:
Outcome 1: Drive domain ownership
Prior to adopting this principle we would have a sprawling number of similar APIs trying to solve the similar problems, and a tremendous amount of confusion over which one was “correct” or “trusted.” Committing to composable interfaces forces us to have conversations about who owns a business-object’s domain. Some business objects have pieces that are scattered in multiple places (not necessarily a bad thing), but having one product owner be responsible for the domain allows them to build subject-matter expertise and they can be responsible for understanding consumer needs and can drive trust and continual improvement which results in better quality services for the whole organization.
Outcome 2: Abstraction from the underlying technology
Abstracting the enterprise technical interfaces from the underlying proprietary application(s) has several benefits:
- No more point to point, direct integrations… which loosens system coupling (another principle that will come later!)
- No more asking other teams to understand the proprietary weirdness (tm) of a certain application (it’s APIs, it’s fields, it’s database structures, it’s authentication/authorization methods)
- Technical interfaces can use data structures and field names that make sense in the Chick-fil-A context. Perhaps an application has a field called “custom_field_1234” but in our data model we would call that “Order Number”.
Outcome 3: Overall increase in team momentum
This is the ultimate outcome supported by the previous two. A composable enterprise allows teams building custom or implementing standard software to inherit all the work that came before. It generally reduces the organizational drag that comes with everybody solving the same problem multiple times. It bootstraps new projects by giving them a grab-bag of existing functions to build from, so their team can focus on solving a unique problem, or building a unique experience.
Conclusion
We have experienced the benefits from the above outcomes in a very real way with Composable APIs, event streams and Data Sets in several key domains like Restaurant Locations, Corporate Staff, Restaurant Team Members and Restaurant Orders. As we educate our teams in this concept it has become contagious, we can see the lights go on as product owners, engineers, and even executives/business partners start to understand the benefit. The more time we in EA have spent on this topic, the more self-perpetuating it has become which is a very nice (and maybe unusual) experience for the members of our team.
