The company delivers digital learning and ops platforms to global enterprise clients in the hospitality industry. Their monolithic architecture and per-customer infrastructure limited growth to larger accounts. The trigger came when ambitions to launch a second product line demanded architectural and infrastructure cleanup, as well as domain clarity.

I created a short-term Domain-Driven Design program with a diverse group of stakeholders. From the program insights, it led to the domain and platform clarity, allowing the organization to distill the principles that guided the major product, architecture, and engineering decisions. It allowed them to untap other market segments that weren’t planned in the program’s initial stages.

The last session of the program ran 2 days before the COVID lockdown in the Netherlands. Their solutions are used by hospitality and food enterprises, which were the most affected by the pandemic. Given the new strategic direction from the program outcomes, allow the organization to make effective decisions to incorporate new features in their product, targeting the rules and regulations during the pandemic. That was only possible because of the new platforms and the domain orientation.

Create a Flow-Based Organization with Participative Design

The engagement was a mix of management consultancy advisory, workshop facilitation, and domain architecture. The sessions had the support of the executive team, and they were present throughout the program. It signaled to the organization the commitment to listen to the concerns from the different teams and, at the same time, provide clarity for the strategy for the next 3 to 5 years.

The initial question was clear: how do we start to reorganize ourselves and the code, so that we can have a new product in a different business line? I’ve got the same question from scale-ups in the same phase of growth. They have had initial success, and now they want to explore other business lines, but the past decisions for the product and architecture are limiting the options to execute the strategy.

We started the program in the most natural place: the status quo. By using EventStorming, the group was able to map how things work today, what the friction points and architectural bottlenecks are, and the ideas and opportunities to execute the strategy.

 

Director of Engineering: “The understanding and collective agreement are a lot more important than technology in the end”.​

 

We identified these main challenges:

• Onboarding new enterprise customers took 60 days due to manual processes and per-customer infrastructure.​ It was one of the early decisions to have this approach to the customer infrastructure, which allowed the start-up to grow to a scale-up. To continue the growth trajectory, the onboarding process needs to be redesigned to meet market demands.
• A growing staff in technology, almost linear headcount growth as the business grew, managed a Big Ball of Mud codebase. The software development lifecycle had numerous manual actions, such as testing and infrastructure, which complicated testing and operations scalability.​
• There was an inconsistent language across teams that caused misalignment. One of the examples was the names related to user accounts and paying customer (e.g., accounts vs. customers). It caused cognitive load when the teams needed to add new features or evolve the codebase.
• The cloud infrastructure costs hit 100k/month per large client, making it expensive for smaller customer segments.​ The management knew the potential of the products to target smaller customer segments, but they never tried to do it due to the product price tag.

The program sessions identified the initial boundaries and fracture planes for the new domains and common platforms. They were able to align the teams to the new design, increasing their effectiveness. 

The workshops had diverse participants from sales, marketing, finance, and engineering. These sessions helped them to build a shared language, start to decide about the boundaries, and create the conditions for the new product line to be built in the right way:

• The EventStorming sessions enabled the business folks to understand how the processes are implemented. As they digitize the boards, allowing them to leverage the digital version for compliance purposes.​
• Based on the insights, they restructured the teams and architecture around domains like Learn, Operations (as in the operations performed by the customers), platforms, with primitives for accounts, subscriptions, and ownership.​
• The sessions were held before COVID, which started to address some social debt. It was crucial for the company during COVID, since they were already aligned on how to execute the plan, and it had enough detail for the teams to get started. The organization matured to the point of using Domain-Driven Design techniques on its own.​
• As a result, the teams owned every aspect of their domains, from design to software operations, including customer support and security. The team’s orientation towards the domains enabled local decisions, accelerating the decision-making process.

From Chaos to Domain Clarity

One of the first actions was to isolate the Identity and Access Management in their domain. Although this is a concern that every SaaS company has, in their case it was to abstract the complexity of supporting multiple technologies, and provide a clear set of models for the consumers of that domain. It started to decompose the monolithic product, and serve to bootstrap the second product line. 

It freed up team, and reduced their cognitive load. And one of the actions that allowed us to streamline the business operations. They were able to build on top of this, and restructure the teams to align with the new domains.

Results

• By consistently applying DDD techniques and improving their platform, they were capable of tapping into the SME market. The onboarding time was slashed from 60 days to 20 minutes with a self-onboarding flow for small businesses.​
• The cloud infrastructure costs reduced by 80% (from 100k to 17k/month) through virtual multi-tenancy and a Kubernetes migration.​
• After the organization changed to a domain-oriented approach, it was able to grow without linear staff growth. Part of it was done through organization design and the re-architecture of their product; the other part was through the adoption of engineering practices, such as Test-Driven Development. It freed up teams’ time from manual repetitive tasks for value-added activities, such as domain exploration.
• After the new product launch, they continue to expand their product portfolio offering. They created an organizational awareness portal, where early adopters of AI could be used by their customers (namely, restaurants and tools) with compliance aspects.
• As the platform scaled, the new system design handled more than 4TB of educational video serving 800k worldwide users with role-based permissions tailored for the customers needs.​

Innovation Momentum

As the organization matured their approach, and continued their systems modernization, it continued to free up capacity for innovation. One of those innovations was in the initial launch of AI. They were able to build a copilot system, to support the customers with their compliance audits. The new tool was capable of detecting the gaps, and pulling the learning materials to help the frontline workers to learn and close the audit gap.

It created a faster feedback loop, and it is one of the clear examples of AI augmented work. By adopting DDD, they were able to remain flexible, and have innovation bets, without harming their current business. And because the domains are clear, they can compose the offers, rather than have a big ball of mud.