Home Blog Software Development Scaling & modernizing monolithic apps

Scaling & modernizing monolithic apps

An out of date app is a dying app, doomed to decreasing users and ultimately being overtaken by the competition. If you have a successful app then updating it, modernizing it, and scaling it to keep pace with users’ growing needs is essential to maintaining that success. This article focuses on the key factors when modernizing monolithic apps, including the different scaling strategies and approaches, and how an agile perspective can help. As a development partner, Boldare has worked with numerous clients to update and even transform their existing monolithic apps or platforms.

Scaling & modernizing monolithic apps

Table of contents

Monolithic apps are self-contained – the user interface, the code, the database, all are contained in a single program, a single platform. Unlike apps created using a more modular design, which can be updated and maintained bit by bit, function by function, feature by feature, a monolithic app is – as the name suggests – a single block, a ‘whole-in-one’ and must be approached as such when considering updating or modernization. The work to scale a monolithic app is more all-encompassing, the app must be dealt with as a whole unit and as such, the approaches and strategies can be similar to those when creating a new app from scratch.

Why might you need to modernize a monolithic application?

There are a number of reasons why your app might need some attention:

  • New technology is available that will improve or transform your app.
  • The ‘old’ technology on which your app is currently based is either out of date or no longer sufficient to support the app’s functions and/or scale.
  • User needs and desires have changed.
  • Maintenance costs are growing as your tech stack becomes more divergent and complex.

Any of these reasons might apply to any app. However, with a monolithic app the need to modernize is often more acute – the process is rarely a ‘quick fix’ as due to the app’s integrated, monolithic nature there is usually a need to review the basic principles on which the app was originally built.

Boldare – a modernizing partner

Depending on your in-house talent and resources, it’s highly possible that you might benefit from an external partner when modernizing a monolithic app. At Boldare, we have 17 years’ experience of being just that kind of partner, having developed 300+ web and mobile applications for over 170 clients.

An example of a modernizing project that many of our clients might find familiar, is the transfer of a monolithic app’s infrastructure to the cloud. This is a classic scaling strategy which ensures the app’s future capacity while maintaining (and even improving) its functions, features and user appeal.

Always start with ‘Why?’…

Modernizing, updating, scaling… it all means innovation of some kind. A June 2021 article in The Economist magazine looked at the list of 100 biggest companies globally, finding that the number of European companies on that list had fallen by 63% in the last 20 years. The problem was seen as a failure to innovate. So, scale your apps, modernize or get left behind. But it isn’t just about refactoring an app, rewriting a bit of code, or even jumping on the microservices bandwagon. Successful innovation is focused on something concrete, in this case, solving the specific problem that’s facing your digital product. If you’re going to innovate, you need to know why you are innovating.

In our experience, the answer to finding that ‘why’ can be surfaced by working on your app’s system story. At Boldare, we kick off our projects with a workshop to agree a vision for the product and link it to specific business goals. The workshop aims to answer four questions:

  • What exactly are we building?
  • How are we going to achieve our goal?
  • Who exactly is it addressed to?
  • And… the tricky one: What for?

If you’re looking for an exercise or workshop that could help you with getting all these answers and more, think about using a system story. The system story is a simple answer to all four of those questions: a summary of the whole project in a single line. If that sounds difficult, it can be, but once you have it, the system story becomes a guiding light for the whole project. A signpost that always points you in the right direction.

(For more on system stories, check out our article, “System Story – the little sentence that builds big things”.)

…Then, think about your users

The users of any app have one fundamental question: Does it solve my problem? “Yes” is a good answer but not the best. A better response is: I can’t live without this app! Even better: I’m surprised when I hear someone isn’t using it!\ \ These last two answers mean your app has fans, dedicated fans who will recommend it to anyone who’ll listen. You’ll only get fans like this when your app is up to date and so, when you’re modernizing your app, you need to be focused (obsessed!?) on meeting your users’ needs.

This means not only finding out what users are asking for but – digging deeper – discovering what they really want. As startup and agile legend Eric Ries says, “If you don’t know who your customer is, you literally don’t know what the word “quality” means.”

How do you get to know the customer? Data and lots of it, preferably standardized so it is utilizable, and based on observation and interaction with actual users so as to fully understand their experience. One way to do this is to use a basic user story mapping process:

  • Define your key user personas (roles, lifestyles, responsibilities, etc.)
  • Interview and engage with real representatives of these personas (in pandemic times, this can be more complicated but remote tools enable the necessary engagement at a distance without losing the value of the user input – at Boldare, we are currently big fans of using Miro, Mural and Gathertown; your mileage may vary).
  • Starting with a one-line format - As a (type of user), I want (feature), so that (benefit to user) – break down each ‘story’ until you have a detailed picture of the steps in the user journey for each feature.
  • Use these details to build a backlog of tasks/items for development and prioritize

(For more on user story mapping, check out our article, “Build better digital products with user story mapping”.)

You now have a route map for your modernization and can move on to other planning decisions, including:

  • Choice of technology
  • Architecture
  • Platform support (e.g. the transfer from independent server to the cloud mentioned above, for which specific cloud expertise is needed.)
  • Browsers and devices support
  • Maintainability
  • Compliance requirements

You might be also interested in the article:

5-star Clutch.co review for digital prototyping services in the food industry

5-star Clutch.co review for digital prototyping services in the food industry

4 Monolithic app modernization strategies and approaches

From engaging with users to handling the actual technical changes, there are a number of useful strategies when modernizing your monolithic app:

  • Domain-driven design (DDD) – Monolithic apps are by nature complex, and DDD is an approach that involves subject matter experts (e.g. if you’re writing a banking app, you make sure you have people who understand banking are part of the process) to align the design of a product’s coding and architecture with the business goals and needs that the product is intended to address.
  • Lift and shift (AKA rehosting) – This is the strategy of moving a platform to the cloud. It involves making the change in infrastructure without making function or feature changes first. Afterwards, once the app is working seamlessly from its new cloud home, attention can be given to redesigning features so as to take full advantage of the newly-available cloud services. This approach means you’re not changing everything at once, instead adopting a more measured strategy, with the project broken down into more manageable stages.
  • Feature flagging – During the redesign process, feature flags (or toggles) can be used to effectively turn individual features on and off, or make them selectively available to certain user groups and not others. You can release a partly-completed product (with the unfinished features ‘switched off’) or activate features that are a work-in-progress to test them with specific users and gather essential feedback.
  • No more release cuts! – Big bang releases of new software versions are so 90s! Instead of treating each new development as an event, adopt an agile strategy of continuous delivery, allowing you (if you wish) to put out tweaked and improved iterations of your app regularly and often.

Why an agile approach is the right approach

As far as Boldare is concerned, the best way to avoid cutting releases is to work Agile.

Adopting an Agile framework for software and infrastructure development offers a number of benefits. Firstly, priorities from the backlog are tackled in short ‘sprints’ of one or two weeks, ensuring steady, coordinated progress. Each sprint aims to finish with something tangible and releasable (a part-product, a feature, etc.) And a system of regular planning and review/retrospective meetings keep everyone involved focused on specific objectives and, when necessary, tackling specific problems.

You might be also interested in the article:

Agile and skilled development teams for BlaBlaCar, a French unicorn

Agile and skilled development teams for BlaBlaCar, a French unicorn

Ensuring ROI

The final element that should underpin any scaling or modernization work on your app is the return on investment that you are aiming for. Measurable ROI is your indicator of successful modernization. That might be ‘hard ROI’ such as financial return, number of users, ratings compared to other apps, SLA performance, etc. or ‘soft ROI’ such as improved user experience, efficiency, teamwork and morale, or employee retention. Then there is ‘social ROI’ which is less tangible and measurable such as the impact on culture, or tackling an issue of wider social importance. Such impacts may seem one step removed from the project’s focus (modernizing your monolithic app!) but often tie in neatly to the ‘corporate social responsibility’ goals of many modern companies.

When faced with modernizing a monolithic app, whether it’s an overhaul and update of the features, scaling for a broader audience, improving the user experience, or making a transition of infrastructure, there are no short cuts but there are ways to do the work with maximum efficiency. User needs and wishes must be at the core of the process, with the goal of creating an essential app your fans won’t want to live without. Though there are numerous techniques (system stories, user story mapping, etc.) the underpinning framework to any modernization should be Agile, ensuring continuous delivery, and continuous learning and improvement along the way. Finally, without a strong focus on ROI, you risk creating something beautiful but unused – keeping in mind the balance of effort and resources invested with planned-for results will help ensure your improved app is a genuine improvement for both the users and your business.