Many IT systems have tightly coupled, monolithic architectures, rather than a more modern modular architecture—and that limits the speed of change.

In monolithic architectures, business logic may be scattered across many components so that changing one component means you have to change others, too. That may be acceptable in smaller systems, especially if the original developers (who know where logic is scattered) are still around to help manage it.

But as systems grow and development teams get bigger, this becomes harder to manage. Teams implementing new features have to modify multiple components, and they wind up bumping into each other’s work. Because components are dependent on one another, changing one part of the system often requires full regression testing, further slowing delivery speed.

Some organizations address this problem through large, expensive programs that seek a wholesale replacement of a group of legacy systems. These programs, which typically involve an all-at-once cutover to a new system after several years of design, construction and testing, have a failure rate as high as 90%, according to recent research by the Standish Group.

A better approach to modernizing a monolithic architecture is based on Agile principles of stepwise change guided by business value. An increasingly popular and successful method that embodies these principles is to move incrementally to microservices, which are self-contained components, loosely coupled and capable of being modified, tested and deployed independently of the systems that use them.

The first step in migrating from monolithic to modular is to identify where business value can be unlocked by separating a component from the monolith. These are usually areas in which teams collide the most, or areas that change most often, or areas that are fragile or unstable. The next step is to figure out which components are easiest to separate based on the number of dependencies on other components and the degree of difficulty in separating the business logic from the monolith to put it into the microservice. Then, the work is conducted in small increments, prioritized based on these two steps. Software intelligence tools can help with these decisions, providing hard data about dependencies and connections.

Microservices are usually organized by customer experience or business capability, rather than by stack layer. So they require cross-functional skills, since a business capability might cross several silos. For example, opening an account might involve the user interface, workflows, databases and business logic, requiring support from a broad cross-functional team. Since a microservice is accessed through an application programming interface, other teams don’t need to understand its inner workings.

Over time, organizations progressively migrate functionality from the monolith to microservices, based on business value and technical difficulty. Several factors determine how much of an application should be restructured as microservices. Some parts of an application may be problem-free and require changes only rarely, so they may not be worth migrating. In other situations, the business case will justify the investment in moving to an architecture fully based on microservices, enabling consistency in team structure and skills, ease of change and maintenance, and reuse of capabilities in other applications.