Implement Loosely Coupled Systems and Services
EA Principles Series Part 5
Our next principle in this series is about how we promote an old but good idea: the loose coupling of systems. As a reminder, these are principles that we share across Chick-fil-A with people that are making decisions about building or buying softwares. They may range from software engineers to business leaders. Our principles are written as simply as possible to support sharing them with minimal translation.
The Dangers of Tight Coupling
To flip the question: Why are tightly coupled systems bad?
- Components get intertwined and become difficult to update, maintain and reason about
- Software teams end up having to have discussions about how another team’s system works behind the scenes. The collective velocity will slow to that of the slowest team involved (or perhaps slower if they have to understand something very different from their own system). That is wasted time that could be used for productive activities like features or reliability engineering. Ideally a team only needs to understand its peer team’s interfaces. Not their inner-workings.
- When systems blur, data domains can also blur together.
- When data domains blur, systems can also blur together.
- When one thing breaks, a lot of things break.
- Making changes is hard to reason about and requires too much context to promote regular releasing to production, which we know is critical for happy and productive product teams.
- More direct dependencies means testing is harder to achieve and maintain, and therefore releases get less frequent or less reliable which are both bad outcomes.
In short, tying things together seems easy (and it is), but its difficult in the long-term and it creates risk.
Principle: Implement Loosely Coupled Systems and Services
Here is the verbatim of our principle.
Systems and Services at Chick-fil-A should be built in a loosely coupled manner. This means that the system is built in a manner that keeps its components from being intertwined and dependent on each other.
Each product team should maintain ownership and control of their core business logic and domain object models and share them openly with the rest of the organization through standard interfaces (such as APIs or business events).
Why? Loose coupling keeps business processes transparent and configurable, allows work to scale across multiple teams, allows for more frequent deployment of components, and supports an open integration methodology (API-First) between components. It also allows for easier component replacement in the future should we want to replace something off-the-shelf with something custom, or vice versa.
Outcomes and Tradeoffs
What are the goals behind this principle?
Outcome 1: Avoid system spaghetti
We all know that an unintentional approach to systems building and enterprise architecture can result in a big mess. If we aren’t intentional about how products interact with each other, about the functionality and data they own, and how tightly they are intertwined… there is a good chance things will get messy eventually. Getting to that mess of spaghetti is quite easy to achieve, and everything thereafter is very hard.
If we can draw good domain boundaries, get clear about what functionality lives with each product, and promote interactions through clean and well-defined interfaces, we can avoid much of this messy future and maintain wonderful things like organizational agility, ease of updating / maintaining / replacing components… and we can promote practices that lead to frequent releases, iterative delivery and feedback (agile), and fewer silos.
Outcome 2: Define your domain boundary explicitly, and maintain control over the data and capabilities within
We mentioned this above, but we want to be very clear about the boundaries of each of our domains. In simple terms, this means we want each team to know what they are providing to the business and what data and business functionality falls within. We do not want to confusion between groups about who owns what or multiple teams owning the same domain unless absolutely critical.
Our one exception has been our “location” data, which is data about restaurants. This one has long been messy, but we started to have more successes when we got clear about what a location actually is and what data is involved, and then what other things had relationships to locations but were really separate domains (or sub-domains owned by some other product team).
As we undertake business capability modeling via our business architecture practice, I expect this to get easier and more mature with time. Hopefully we will be able to associate a team to a capability or set of capabilities, and associate the data and business functionality in that area to it. On top of that we can layer in our systems support and interfaces (APIs, enterprise messages, etc).
Outcome 3: Build and share a purpose built set of interfaces so that you don’t become a silo
To avoid silos, we need interfaces. We don’t want teams sharing database access, application code (though libraries are fine), etc.
To be a nimble, composable enterprise we need to invest in having technical interfaces that match each of our core business capabilities. Think about things like getting the info about a restaurant, placing an order via Chick-fil-A One, opening a support ticket, logging a batch of chicken that is being cooked (IoT Edge use case), or placing said chicken in hot holding. These are places where we want to be able to share data cleanly and consistently, or let others talk to an area of functionality through an API.
As we mentioned “composable” here, you may recall our last post about building a composable enterprise. These points of overlap are intentional: considering principles together can help to start to create a better picture of what we want our larger technology ecosystem to look like.
If we break silos, we’ll all be able to work together more easily and with less meetings to dig into the details that ideally should be abstracted away. We have been pushing this idea of covering our business capabilities with technical interfaces for numerous years. It takes time, change management, storytelling, and patience… but it does yield great results.
Conclusion
If we tightly couple things, we end up with technical debt or enterprise debt. We do our best to help call these places out and help teams see the consequences, and instead promote loose coupling, API-First thinking.
