Last update 17/01/2023
How do a replatforming project? Bottom-up or top-down, inside-out or outside-in? This episode shows you how we did it.
‘[…] premature optimization is the root of all evil (or at least most of it) in programming.’
— Donald Knuth, Computer Programming as an Art (1974).
However, if your business remains successful, eventually you reach the next phase and become a ‘scale-up’. And now, all the decisions that made sense early as a startup come haunt you as legacy and technical or organizational debt you’ve deliberately built up. When I joined Emma late 2020, we were exactly at that stage: Business was thriving, yet software development was merely reacting, drowning in tickets, and becoming a bottleneck to business development. There were many reasons for that, organizational and processes are part of it but also the technical architecture and infrastructure were big factors.
Remember: Emma is just 6 years old but experienced hypergrowth since its infancy. As the business grew almost exponentially, the organization scaled with it — fortunately linearly. However, what didn’t scale was the technology.
Hypergrowth requires scalability in Business, Organization and Technology
Although running on the (Amazon) cloud, the E-Commerce system used was the legacy version 1 of Magento with many, many customized extensions developed over the years that were implementing ERP-like functionalities, servicing the business as it grew. This, inevitably, accumulated a lot of functionality that doesn’t really provide distinguishing intellectual value to the company, but that, nonetheless, needed to be maintained and operated. At the same time, Emma started to implement a 3rd party ERP-system (Microsoft Dynamics 365 Business Central) to professionalize its operational and financial processes from an end-to-end perspective. I’ll cover the special aspects of repackaging an ERP-system integration in a separate blog post (see here).
Looking at it from one level up and depicting the situation like in the illustration below (i.e., categorizing 4 sectors of visible or invisible and positive or negative value contribution), the areas consuming the most capacity were of negative value (‘bug’ and ‘technical debt’) with some also allocated to ‘feature’ work. Obviously, the goal is to focus on both positive value areas and explicitly invest enough in the invisible area of ‘architecture’ to avoid accumulating invisible technical debt in the future.
We are feature+bug+technical debt, but need to be architecture+feature+bug (source: Kruchten, P. 2009)
Reviewing the status quo and anticipating Emma’s highly ambitious business goals, it became apparent that the current technical landscape would not suffice and simple, incremental improvement would not be enough to transform. We needed a radical step ahead — a leap to the next level of technical productivity, enabling global business in 30, 40, 50 or more countries, becoming proactive about business innovation, living on the cloud, and scaling not only technically but even more importantly, organizationally. We needed to enable concurrent business development driven by our country teams — we needed to become Business Agile, thus deprecating the old platform and designing a new, modern one.
