Last update 01/09/2022
How do a replatforming project? Bottom-up or top-down, inside-out or outside-in? This episode shows you how we did it.
Version 0.1 of our Business Domain Architecture
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:
- Are we working on the right topics?
- Are we working on the topics in the right way?
- Did we really understand the problem domain before jumping to solutions?
- Can we solve this more simplistic?
- Is this the right scope for a version 1?
- 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.’
