How to architect technology to support starting small and scaling fast
March 09, 2021
We have all heard the advice – “Think big. Start small. Scale fast!”
Unfortunately, many organizations driven by their enterprise IT departments seem to focus only on the “think big”. This is the best explanation I could come up with, having seen most enterprise software bloated with features packed into a single system – a so-called monolithic architecture.
Taking E-Commerce platforms as an example, many typically look something like this:
Definitely no lack of thinking big here! But starting small and more importantly, scaling fast? Not likely.
This architecture has some heavy downsides technologically and also for the business:
The last item especially hurts if you do not have a validated business model yet and are working on achieving precisely this with a Minimum Viable Product (MVP) first.
The gold rush on innovation in digital created the opportunity for the “Software as a Service” (SaaS) model. There’s nothing easier than signing up for an off-the-shelf software solution provided to multiple tenants who will share the development, hosting, and maintenance cost. In many cases, this can provide great opportunities to create new business models out of thin air (yes, this is a terrible “cloud software” pun). A great example of this is the now-trending audio-social-network Clubhouse, which supposedly relies heavily on Agora’s audio SaaS platform.
However, many innovators quickly hit a wall with this approach when it comes to successfully creating a moat between them and competitors trying to copy their success – and it is obvious why: If your business model heavily relies on a standard solution offering standard options, then by default it becomes easy for anyone else to copy. Or put differently: innovation is not a configuration option you simply turn on.
Let’s say you want to start a business selling lemonade online. You have 2 options: Buy an off-the-shelf solution, find someone to help you customize and implement it just as you need it (and as the business develops over time), and after 6-12 months, go live with your lemonade online store. Or you can be up and running in 15 minutes with a SaaS solution.
BUT: With the SaaS solution, you are limited to the standard options that the platform offers. Suppose you want to offer a lemonade subscription as your business model matures; suddenly you reach the limits of what the SaaS platform you chose can do. So that is actually the dilemma: to quickly validate your business model you need the speed of a SaaS solution, but to keep innovating and differentiating, you need the customizability of a flexible product.
When developing our Omnevo product suite we are continuously facing up to that exact challenge: How do we provide our customers with a comprehensive set of capabilities while at the same time keeping a lean enough product proposition to allow businesses in the validation phase to start using it without a major investment in capital?
This is why we developed the modular architecture, that we follow with our product suite – and approach most of us are still familiar from our Lego sets at home:
The approach combines the best of all worlds. It covers a broad set of features matching that of any enterprise solution out there. Because one size rarely fits all, it allows for a customized set of features to be cherry-picked for implementation according to the specific local needs of each customer. Finally, at the same time, it is agile enough to be rolled out swiftly to customers who may be in the early stages of validating and developing their business opportunities.
But how exactly do we do this? By applying a philosophy that would not have gotten me my MBA back in University: introducing redundant implementations.
Taking a closer look at the architecture of our E-Commerce Suite you will notice that some functionality is available in multiple components; we have a search feature in Flamingo (our E-Commerce framework developed in Golang) but we also provide a full-fledged Search & Recommendation Engine. Flamingo has cart and promotions capabilities, but there is an additional Cart and Promotions module as well.
How does this make any sense?
Well, it enables customers to run a fully-functional E-Commerce store with only our Flamingo component, with a very basic set of features that we curated based on our experience in helping dozens of customers validate their commercial hypotheses. The Flamingo framework is super lightweight, can be deployed to the cloud-super easily and it’s actually open source!
When the business starts growing and our customer wants to add more capabilities, we can do this by simply deploying a module replacing Flamingo’s internal feature. This was our (now not so-)secret sauce in rolling out many customer projects without requiring big investments in resources, IT re-design, and capital expenditure.
This does come at a price, of course. Some features, that we already have in a dedicated component might need to be duplicated within our Flamingo framework – and consequently, we have to maintain both of them. Naturally, this would not impress the “clean-architecture evangelists” preaching clean-cut bounded contexts and don’t-repeat-yourself (DRY) code style, but as long as it helps us solve actual customer and real-world problems, we are quite content with this strategy.
After all, technology architecture should be about building the right solution for the market and not about technologists being able to build their ideal tech toys, disconnected from the reality of doing business. This is perhaps the true meaning of “think big, start small, scale fast.”
