In today’s dynamic technological landscape, the enterprise sector faces a fundamental dilemma: how to effectively modernize the legacy systems that drive the business but also limit its agility. The ‘Monolith vs. Microservices’ debate often resembles an ideological war, where technological trends take precedence over business pragmatism, leading to costly and often unsuccessful migrations. Today’s guest is Marcin Dąbrowski, a CEO and author of books on the challenges of digital transformation projects. Marcin will introduce us to the concept of the ‘Modernization Readiness Score’—a tool that shifts the architecture discussion from the level of subjective developer preferences to the realm of measurable KPIs and strategic corporate goals.
Marcin, welcome to our studio. Today, we're tackling a topic that has been sparking debate in the IT community for years: modernizing legacy systems. I get the impression that the industry views the choice between a monolith and microservices as a binary decision. Why is that? What makes us fall into this dichotomous trap?
Hi, Tomasz. That's an excellent question, and indeed, it's one of the biggest problems I observe in modernization projects. Surprisingly, despite its innovative nature, the IT industry often succumbs to fads and trends. Microservices were, and still are, a powerful trend. They promised flexibility, scalability, and team independence. And all of that is true, but only in an ideal scenario. The problem is that many IT leaders and teams treat it as a dogma, as the one true path, without a deeper analysis of the business and technical context. A false dichotomy is created: either the outdated, cumbersome monolith or modern, dynamic microservices. The truth is that architecture is a spectrum, not two opposing camps. Market hype and the desire to keep up with the latest technologies often overshadow common sense and pragmatism.
I see. So it's a bit like the latest shiny toy—everyone wants one because it's trendy. And it was in response to this problem that you created your proprietary 'Modernization Readiness Score' matrix. Tell us, what gaps in the decision-making process does it fill, and why did you feel it was necessary?
Exactly. I've seen too many projects where architectural decisions were based on the subjective preferences of developers eager to use new technologies, or under pressure because "the competition already has microservices." There was a lack of an objective tool to assess the actual technical debt in the context of business goals. It's not about whether a technology is "cool," but whether it supports the company's strategy. My matrix was born from the need to create a common language between management and the IT department. Management needs measurable indicators for ROI, risk reduction, and time-to-market. IT needs a framework that allows them to justify their technical decisions in business terms. The 'Modernization Readiness Score' fills this gap by providing a framework to assess an organization's readiness for modernization, considering technical, operational, financial, and even cultural aspects.
That sounds like something that could significantly improve dialogue within a company. Let's get down to specifics. What are the four key performance indicators (KPIs) that make up your matrix? How do you measure them, and why are they so crucial?
The core KPIs are the foundation of the matrix. The first is Change Velocity in the Context of Domain Cohesion. Here, we measure the speed of implementing changes, but we compare it with how well the system reflects business domain boundaries. Do changes in one module trigger a cascade of changes in other, unrelated domains? In a monolithic "big ball of mud" system, high change velocity often means that every modification is risky and expensive.
The second KPI is Operational Complexity, which is the organization's ability to effectively manage a distributed system. Microservices aren't just about code; they're also about infrastructure, monitoring, logging, deployment, and security. Studies show that the initial development costs for microservices can be 2-3 times higher than for a monolith, and observability costs can range from $500 to $3,000 per month per system. If mature DevOps processes and the right management skills are lacking, a distributed architecture will quickly turn into an operational nightmare.
The third is Data Consistency Requirements. Does your business need strict, real-time data consistency, or can it afford eventual consistency? In banking or telecommunications systems—like the ones Peoplemore often works with—immediate consistency is often critical. Distributed systems inherently make this difficult, introducing complex mechanisms like Saga Patterns.
The fourth, and incredibly important, KPI is ROI (Return on Investment) considering TCO (Total Cost of Ownership). We must look at the big picture: development, infrastructure, and maintenance costs, as well as risks and delays. Only then can we assess whether the investment in a particular architecture will actually deliver the expected business benefits.
That's a very comprehensive approach. Returning to the spectrum you mentioned—I often hear about a return to monoliths, but in a modular form. Why do you believe the modular monolith is currently the most rational choice for many companies?
This is that surprising yet true observation I mentioned. The modular monolith is not a return to the "big ball of mud." It's a strategic approach that combines the advantages of a monolith—simpler infrastructure, easier deployments, data consistency—with the benefits of microservices, namely clear domain boundaries and modularity. In a modular monolith, using techniques like Domain-Driven Design, we divide the application into autonomous, loosely coupled modules that communicate with each other through well-defined interfaces.
Its advantage is multidimensional. First, a lower barrier to entry and easier maintenance. You don't need a large DevOps team from the very beginning. Second, you maintain domain boundaries, which simplifies teamwork and reduces the risk of accumulating technical debt. Third, and this is key, a modular monolith gives you the option to smoothly evolve towards microservices in the future. You can extract individual modules as microservices when a real business need arises, rather than assuming from the outset that everything must be distributed. We call this a "deferred decision"—postponing a difficult choice until you have more data and a real justification. This approach is much more pragmatic and aligns with the idea of balancing Agility vs. Scale, which Peoplemore emphasizes, promoting flexibility while maintaining corporate stability.
So instead of jumping in at the deep end, you can build bridges gradually. And how should the pace of market change determine the choice of technology stack? When do microservices become a brake rather than an accelerator for growth?
That's a fundamental question. The architecture must be aligned with business dynamics and the product lifecycle. If you're a startup in a rapid growth phase, where you need to test many hypotheses and pivot quickly, a simpler monolith might be a better choice because it allows for faster iterations. Microservices introduce additional complexity that can slow down, not accelerate, development in the initial phase.
On the other hand, in mature markets, in sectors like telecommunications or finance where Peoplemore has been operating for over 20 years, systems must be stable, scalable, and fault-tolerant. Here, microservices, if implemented well, can bring benefits in terms of reliability and independent scaling. But even here, you have to be careful. Conway's Law states that organizations design systems that mirror their own communication structures. If your teams are not autonomous and cannot manage independent services, microservices will only deepen communication problems. Microservices become a brake when the cost of managing complexity outweighs the benefits of using them, when deployments become longer, and debugging becomes impossible. Surprisingly, despite their popularity, studies show that only 23% of companies actually derive significant benefits from microservices.
That's a very valuable insight. You talk about "war stories"—where do legacy modernization projects most often fail? What are the most common mistakes you observe in practice?
Oh, "Impossible Projects" are my specialty, and modernizing legacy systems often falls into that category. The biggest mistake is attempting a "Big Bang rewrite." This rarely succeeds. It's extremely costly, risky, and usually leads to years of delays, and often, failure. Instead, an evolutionary approach is better, gradually carving out functionality using the so-called Strangler Fig Pattern.
The second mistake is ignoring organizational culture and the DevOps team's skills. Transitioning to microservices is not just a technology change; it's primarily a change in the way of working. It requires maturity in Continuous Integration/Continuous Delivery, automation, monitoring, and incident management. Without the right management skills and investment in Team Augmentation, the team can be overwhelmed by complexity. Peoplemore often supports clients in this area, providing experts who help build these competencies.
The third mistake is the lack of defined, measurable business goals before starting the migration. If you don't know why you're modernizing, how will you measure success? Is it to shorten time-to-market, reduce operational costs, increase scalability, or improve security? Without clear goals, the modernization project becomes an end in itself, rather than a tool to achieve business objectives.
Those are very concrete and practical tips. Now that we know what to avoid, tell us, how can a large enterprise start using the 'Modernization Readiness Score' in practice? What are the first steps?
The process of implementing the matrix should be iterative and pragmatic.
Step 1: Inventory of current Pain Points. We start by gathering data from development, operations, and business teams. What is slowing things down, what generates the most errors, where are we losing the most money? Is it long deployments, scaling difficulties, high maintenance costs, or a block on innovation? This gives us context and justification for further action.
Step 2: Event Storming workshops to map domains. This is crucial to understand how the business works and what its key processes are. Event Storming allows you to visualize how business events flow through the system, revealing natural domain boundaries. This is the foundation for thinking about modularity, regardless of whether you end up with a modular monolith or microservices.
Step 3: Pilot the matrix on one critical module. Don't try to assess the entire system at once. Choose one important module—one that causes a lot of problems but isn't absolutely critical to the entire business. Apply the 'Modernization Readiness Score' to this module, evaluate the KPIs, and then develop a modernization strategy for that specific piece. This will allow the team to learn how to use the matrix, verify its effectiveness, and build trust in the process before expanding it to the entire organization. This is the Human-centric IT approach that Peoplemore promotes—we start with people and their experiences, and then we scale.
That sounds like a solid action plan. To finish, Marcin, I'd like to ask for your prediction. In your opinion, how will systems be built in 5 years, in the context of today's conclusions? In what direction is enterprise architecture heading?
I think that in 5 years, we will witness the decline of the 'Microservices First' era in favor of 'Pragmatic Architecture.' Companies, including those in sectors like Telco and Automotive that Peoplemore often works with, will focus on solutions tailored to specific business needs, not on trendy fads. We will see more modular monoliths, event-driven monoliths, and hybrid architectures.
A greater emphasis will be placed on Serverless and the automation of infrastructure management. Developers will be able to focus on business logic rather than managing servers or containers. This is the direction in which Intelligent Automation is changing the way we operate.
Event-Driven Architecture will become the standard for connecting different architectural styles. This will allow for better integration of legacy systems with new ones, and for building more resilient and scalable solutions that react to changes in real-time. We will build systems that are flexible yet stable and predictable—this is the essence of Agility vs. Scale. At Peoplemore, we believe the future is a combination of solid engineering and a deep understanding of business, not blindly following technology for technology's sake.
To sum up our conversation, the key takeaway is that legacy modernization is not just a technical challenge, but above all, an analytical process. Using the ‘Modernization Readiness Score’ allows you to remove emotions from the discussion about code and focus on what actually creates value for the customer and the organization. We thank Marcin Dąbrowski for sharing this pragmatic approach. For IT leaders, the lesson is simple: before you start breaking down your monolith into microservices, make sure you have a solid foundation in data, not just peer pressure.
Tomasz Michalik
