Part 3: Building the new world — with Domain-Driven Design

So, what to do? Where to start? You could begin the journey bottom-up or top-down, inside-out or outside-in. There is a multitude of software solutions available for E-Commerce, some modernizing rather old-fashioned tech stacks and architectures but building on decades of experience, some embracing the cloud and applying cutting-edge web-paradigms from scratch. But which one best fits our needs and can run a business with triple-digit million (and possibly soon billions) euro revenues?

We decided to take the top-down plus outside-in approach, i.e., looking at WHAT it is our business needs (outside-in) and designing the architecture before jumping to solutions (top-down). This is more or less what is called ‘domain-driven design’ (DDD) in the tech industry and started off with a simple diagram of all high-level ‘business domains’ (at Gartner coined as PBC — ‘Packaged Business Capabilities’) of our E-Commerce business. We defined a business domain to represent functionality and data specific to the area of business, e.g., the digital storefront, the store management backbone, the order management, the warehouse management, the financial core, etc.

Coming from that, we set up a project team for re-platforming, comprised of our most senior internal engineers who have been running the business for years, external senior architects and engineers and product managers, to discover what we needed to build. Applying the primary virtue of our overall goals (enable to work concurrently), we set the project team up in multiple work streams, one per business domain plus one for ‘Developer Experience,’ i.e., reinventing the software development process, CI/CD, and infrastructure. This way we created the teams to be decoupled in development, thus minimizing dependencies, yet being closely aligned with each other.

As the timeline for the project would be mid- to long-term (roughly estimated at around 12–18 months), we defined a set of six high-level project steering hygiene questions we would ask ourselves periodically and sequentially every iteration:

1. Are we working on the right topics?
2. Are we working on the topics in the right way?
3. Did we really understand the problem domain before jumping to solutions?
4. Can we solve this more simplistic?
5. Is this the right scope for a version 1?
6. What will it take to make the version 1 replace the legacy system entirely?

It was an effort of almost 3 months to collect and map all the epics and user stories from our business stakeholders to reverse-engineer the business we actually were running on the higher levels, and to depict the outlook of what was coming ahead. However, with that deep understanding of the business we were finally able to evaluate technical solutions. We applied Gartner’s Pace-layered Application Strategy methodology, categorizing systems within the business domains into what are Systems of Record (SoR), System of Differentiation (SoD) and Systems of Innovation (SoI) and strategically decided what to BUY (or these days: RENT as Software-as-a-Service) and what to MAKE (develop ourselves because it yields intellectual value to Emma).

Gartner’s Pace Layered Application Strategy (source: https://cio-wiki.org)

This might sound easier than it is. The complete process of our solutions’ evaluation comprised of extensive market research, collecting dozens of solutions candidates in a longlist and filtering by strategic and architectural selection criteria into a shortlist. Finally, we designed a scoring model to condense down to three solutions per system context to be tested in technical proofs-of-concept (PoCs) — and ran the PoCs to find an ultimate winner.

Having chosen the winning solution, we start building a ‘Minimal Viable Product’ (MVP) for each business domain. This is the first iteration (of many) aimed to deliver business value earliest possible and at minimal effort and complexity. It is a standard approach in the Technology Product Management field nowadays, and I encourage everybody to read more about it, e.g. at the Silicon Valley Product Group as the terminology can be misleading and is often misinterpreted.

We’ll pick up how this plays along with our rollout strategy later in ‘Changing Business — One night at a time.’