When monolithic legacy systems jeopardize digital transformation

Many businesses have administrative and financial systems that fail to meet the needs of today, yet they can’t be easily replaced or modernized.

Take an example I recently encountered, when a client needed to update a home grown 40-year-old core banking system to support new digital requirements including:

  • New offerings based on customer segment needs
  • Cross-products pricing
  • New product configurator
  • Self-service

Because the legacy system was old and poorly documented, the client thought it was too dangerous to upgrade it…

Common challenges

In conversations with clients, I see common challenges come up:

  • Legacy systems that pose a growing source of operational risk due to knowledge loss (e.g., key IT people retiring) and aggravated by technology obsolescence.
  • Difficulty justifying a big bang “rip-and-replace” because it’s risky and the business case is not clear.
  • Difficulty adopting an incremental replacement strategy due to the complexity of legacy systems.
  • A two-speed IT strategy that does not address legacy systems’ complexity and often fails to meet key digital requirements.

Most clients have appointed enterprise architects who follow frameworks such as The Open Group Architecture Framework (TOGAF), but this has not prevented their information systems from becoming increasingly complex and monolithic.

When talking to software engineers, I gain additional insight. They tell me:

  • Enterprise architecture principles and rules end up being broken when they conflict with project schedule constraints.
  • The siloed nature of the IT organization tends to dilute responsibility to a point that encourages finger-pointing behaviour.
  • In case of failure, managers organize a “cover-up” which prevents honest discussion and limits the organization’s ability to learn.

Breaking down monoliths into smaller, loosely coupled parts

Traditional enterprise architecture frameworks that advocate the creation of enterprise-level data models do not help. Data sharing, which is a legitimate goal, is framed in a way that favours the creation of shared data stores. Yet shared data stores create coupling issues. For instance, adding a new column in a database had so many side effects at one large bank that I was told it required over 1,000 days of regression testing workload!

These “legacy-challenged” organizations increasingly must compete with enterprises that have reined in complexity. Breaking down monoliths into smaller, loosely coupled parts can be done. Large firms such as Amazon, Netflix, Capital One, The Guardian and ING have succeeded at this. They restored/created start-up-like agility capabilities while operating at scale.

How did they do it?

  • By decomposing software systems along domain lines (e.g. customer management, consumer credit origination, portfolio management, etc.) instead of layers (presentation, business logic, data access)
  • By recognizing that the total unification of the domain model for a large system was not feasible or cost effective.
  • By strictly enforcing context boundaries by authorizing communication only through service interface calls over the network.
  • By opening systems through API externalization, which eases the implementation of a platform strategy and facilitates aggregation of data and functionality into unforeseen agile solutions.

They use Domain Driven Design to guide software design. They combine continuous deployment, Microservices and containers to dramatically speed time to market. They break down the organization into smaller teams (reference Jeff Bezos’ famous “‘two-pizza” team rule) that have end-to-end responsibility and are loosely coupled with other teams.

A Wall Street Journal blog reports that a growing number of companies are moving in this direction: “The adopters we speak to today, like GE, Hewlett Packard Co., Equinix Inc., PayPal Holdings Inc., Capital One Financial Corp., Goldman Sachs Group Inc., Airbnb Inc., Medallia, Square Inc. and Xoom Corp. say it is well worth the tradeoff. The benefits far outweigh the costs. As more companies move to this model, better tools will emerge to help manage the growing complexity.”

In future blog posts, I will illustrate the value of Domain Driven Design (DDD), show how DDD combined with Microservices can help enterprises tackle their legacy systems’ challenges and, last but not least, suggest change strategies your business can implement to shift toward a cloud-native/fast-IT model.

Frédéric Lé: Directeur Associé & Technology Lead

EXPERTISE: Digital Strategy, Lean, Software Architecture, Financial Services

Frédéric works for the corporate technology office of CSC. He provides strategic guidance on new solution offerings. He also leads the “Loosely Coupled Integration” technology work stream which aims at modularizing CSC’s offerings and helping clients remove unnecessary complexity from their operations and systems.

Frédéric has more than 25 years of experience conducting consulting engagements and delivering innovative solutions to financial services clients. His domains of interest include Digital Business Models, Lean Startup, Domain Driven Design, Microservices, Business Analytics and Machine Learning.


  1. Nice blog….EAComposer is an EA tool for enterprise architecture using TOGAF that was built from scratch. Thanks for lovely post.

Leave a Reply to eacomposer1 Cancel reply


This site uses Akismet to reduce spam. Learn how your comment data is processed.