Get in touch

Loading...
We use HubSpot CRM to process and manage contact and information requests. Please accept the "Functional Cookies" and reload the page to load the contact form.
Insights / Technology

How to architect technology to support starting small and scaling fast

March 09, 2021
About the author Kacper PotegaKacper Potega
Chief Product Officer, Omnevo

Build architecture like Lego bricks

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:

  • Expensive to scale: In order to scale these applications by running multiple copies of them in parallel (horizontal scaling), you always have to scale the complete beast – even if the heavy load on the system might only be on a small piece of the software. In E-Commerce this tends to be requests for inventory information, product searches, content. Ultimately, scaling everything just to support the heavy loading on one element seems like a huge waste of resource.
  • Poor performance and UX: Since the complete application has to be run even if requests might only require a tiny piece of data (e.g. stock information), response times become typically poor. To solve the slow response, integrators tend to try workarounds, for example by reducing the number of calls to the backend and implementing heavy caching, which adds (yet) another layer of complexity (cache invalidation issues) consequently negatively impacting customer experience anyway. A monolith with a workaround is still a monolith. 
  • Over-payment: Developers building all of these features want their salaries paid - and that is eventually on the customer. So if you buy software, where you really only need 80% of the features, that is 20% extra spent on development and maintenance that could could have been saved. And this is not even including the potential future costs of scaling, or the cost of poor performance and UX yet.

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 start-small-alternative

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?

Modular Architecture: Have your cake and eat it too

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.

Why redundancy is a good thing (sometimes)

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.”