EA Principles Addendum: Is Composability a good idea?
I’ll be the first to admit that “composability” is a buzzword. Does that mean it can’t be a good buzzword? I believe there is value in the underlying concept, particularly if we frame it the right way.
A friend shared this comment in response to our post about Composability as an Enterprise Architecture principle:
I go back and forth on “composability” as a goal. Sometimes it leads us to over-engineer or prematurely optimize the software.”
This is a great comment. As an aside, one of the great values of sharing things with the tech community is getting challenged or getting feedback that helps you further refine and communicate your ideas. Being misunderstood is good too; if it can happen online it could happen at work.
So how composable should we be? Are we allowing buzzwords to overcomplicate an application’s architecture? Are we taking this too far?
Let’s discuss applying composability in two different ways: an application’s architecture and in context of an enterprise architecture.
The Application View
The application view of composability that makes the most sense to focus on is microservices, though an application is made of many more components (storage, database technologies, libraries, infrastructure, etc).
At Chick-fil-A, we caution teams against getting carried away with decomposition into too many microservices in their applications. There is a cost to managing tens, hundreds, or thousands of small pieces, both technically and in the form of cognitive load when building, operating, and coordinating changes in this type of system.
We do see a lot of value in crafting services into reasonably-sized components that enable them to scale independently with load or be deployed at different cadences. A great example of where we apply this pattern is in our backend API-tier for Chick-fil-A One, where we have 30+ teams building 1+ discreet services that compose our overall customer digital experience. Teams are building independently, deploying frequently and scaling differently under load.
The Enterprise View
Our principle is less about the application view and more about the enterprise view of covering the core capabilities of our organization with standard interfaces (akin to Jeff Bezos API mandate). At Chick-fil-A, we consider “standard interfaces” to mean web services (haven’t seen that term in a while), enterprise messages (SNS/SQS, Kafka), or even shared libraries that do “a thing” in code.
Using the lego block metaphor, this enables us to…
- Build lego blocks: Create pieces that can be shared.
- Share the lego blocks: Easily assemble solutions that require sharing functionality or data across different business domains.
- Tear down/reassemble the lego blocks: Respond to new and unexpected business opportunities or challenges with agility by re-using pieces we have.
- Use the things we built to build better things: Do less “start over work.” Build on top of what we already built.
For us, composability = make interfaces for the important stuff.
Keys to Failure and Victory
What can happen if you don’t do this well?
- Teams have to veer out of their lanes to build something outside of their domain that they need to successfully build the things inside their domain. We want to teams to be outside aware but inside focused.
- Duplication of efforts — not the end of the world but has a cost paid in confusion over time.
- Delivery slows down.
- Missed opportunities. Some opportunities have a timeline attached, and a non-composable enterprise means you may miss the opportunity while you try to throw together the pieces you need.
- Ugly point-to-point integrations, single-use services, spaghetti architectures, and general messes.
- It’s harder to integrate with outside partners quickly and / or you end up creating partner-specific integrations.
To do this well…
- Tie interfaces to business capabilities and make sure the important ones — the ones that have velocity and focus today — are covered.
- Treat shared interfaces as products.
- Make sure interfaces have SLA’s and that they are tracked / met. When an interface is unreliable, internal teams are going to 1) not use it or 2) build their own proxy to accommodate for the lack of reliability.
- Catalog interfaces, document them, and make them easily discoverable. Backstage or similar.
- Make the process to build shared interfaces as easy as possible for your organization.
- Run all of your enterprise interfaces through some sort of front door for monitoring, metrics collection, security, etc etc etc.
How we are doing this
At Chick-fil-A, our strategy is to leverage our Business Architecture practice to work with our business partners to define all of our business capabilities. That work is active. When we are finished, we will work to ensure that we have interfaces (APIs, events, etc) to cover the capabilities that are associated with our big organization areas of focus and strategic initiatives. Over time, we’ll work to build out that coverage across more areas to ensure that we have our technical “lego blocks” for every area.
We’re building out Spotify Backstage to catalog our APIs and shared enterprise messages.
We are actively working on a new front door for all of our Enterprise APIs which we’ll share about in the future.
