Sources of Truth & Yummy ALE: Use case of an ERP with Big Green Egg x Brightpearl
Rotate° has had the privilege of working with the iconic Big Green Egg BBQ for several years, during which we have successfully increased their conversion rate (CVR) and average order value (AOV).
While these achievements are exciting, this article aims to explore a less thrilling but equally fascinating topic - the concept of sources of truth within a composable architecture.
One of our key principles when designing a client's architecture is to create a highly decoupled system that fosters long-term agility. We understand that the challenges and opportunities a client faces today may not be the same tomorrow.
This principle lies at the core of a composable architecture.
An architecture that can adapt to your evolving business challenges and opportunities.
To achieve this, we strive to minimise vendor lock-in by enabling low-friction component swapping and additions within the architecture.
One effective way to achieve this is by establishing single sources of truth whenever possible.
As the number of data sources increases, so does the complexity of dependencies. Which sources hold the truth for customer data, orders, inventory, and product information?
The danger here is that the architecture may not be properly considered, and convenience and short-term costs may take precedence.
It is worth noting that composable architectures are often seen as expensive. However, one of our primary goals is to reduce the Total Cost of Ownership (TCO) over a span of a few years. But we'll come back to this later.
In a non-composable architecture or one that neglects long-term architectural health, pricing, stock, and tax codes may reside in the eCommerce platform, as well as several other places such as accounting software and warehouse systems. Customer data and orders may be spread across the eCommerce platform, CRM, and other unknown locations.
While everything may seem fine, occasional discrepancies may occur. But generally, things work.
However, when your business challenges change and you need to quickly modify your CRM, eCommerce platform, or another part of the system, your agency presents you with a six-figure migration cost and a timeline of months (which may even surpass their initial estimate, conveniently omitted from the proposal). They explain that running both the old and new systems in parallel to ensure data integrity is complex. Even at this cost, they strive to migrate as little data as possible. The challenges faced by the business are real, but when you weigh the cost/benefit, it simply doesn't justify the expense. As a result, you accept the situation and continue with an eCommerce platform or another infrastructure component that is suboptimal for your needs.
So, what's the alternative? Will we always have to deal with migration costs and headaches if we want the flexibility to swap out parts?
You're right, that's the end of the article... Okay, maybe not. You see, well-designed architecture anticipates these challenges. If we know that these changes and evolutions will inevitably happen, what can we do?
If we acknowledge the importance of change and evolution, the next question we should ask is: How can we reduce or mitigate the associated costs?
A simple but important concept: The life expectancy of different parts of your architecture is unlikely to be the same.
I like ALE - Architectural Life Expectancy.
As a rule of thumb, components that are closely tied to the customer experience tend to have shorter life expectancies.
Although this is not always true, it generally holds. I encourage you to review your own architecture and ask the same question.
From here we say the items that are unlikely to result in meaningful business change should be the sources of truth.
The less likely a component or vendor is to add value from change, the better an option they become for data sources of truth.
Storefronts, search, email automation platforms, eCommerce platforms, ESPs, DAMs (Digital Asset Management systems), and various other acronyms. If a new business challenge or opportunity arises, these may not be the best options in the short term. Therefore, they should not serve as sources of truth.
And this long and winding introduction brings us to our case study (Perhaps I should stick to architectural design and leave article writing to someone else)...
Case Study
Big Green Egg x Rotate°
For Big Green Egg, their primary source of truth is BrightPearl, an ERP system.
BrightPearl 
Stock, customers, orders, products, pricing, and tax codes - if it's important core information that doesn't directly impact the customer experience, it resides in BrightPearl.
This approach allows us to keep the eCommerce platform ‘dumb’ and transactional. It does not need to handle order management, stock management, product catalogs, or any other functionalities that monolithic eCommerceplatforms typically handle.
We complemented this setup with 
This may involve going headless and introducing an ERP system like BrightPearl at a minimum.
Ultimately, the decision depends on various factors. Composable architecture may not be the best choice at this stage in a brand's life. However, if all goes well, it should be considered in the future.
For Big Green Egg, being composable meant that changing the eCommerce platform required no data migration. The new platform could coexist with the old one, allowing for split testing and validation. Within three months, they were able to move their content management system, eCommerce platform, rebuild the storefront, and implement many microservices - all without any downtime or data migrations.
Read more here about the project here → Big Green Egg
