Chloe Maraina lives at the intersection of aesthetic precision and raw data power. As a Business Intelligence expert with a deep-seated aptitude for data science, she has spent her career transforming cold, monolithic legacy systems into agile, visual narratives that drive enterprise strategy. Her vision for the future of data management isn’t just about moving bits and bytes; it is about a holistic integration that respects the history of an organization while ruthlessly pruning away the technical debt that stifles innovation. Today, she joins us to discuss a resurging architectural strategy that mimics the patient, relentless growth of nature to solve one of the most stubborn problems in modern IT: the modernization of legacy applications.
The conversation explores the revival of the Strangler Fig pattern, a concept that originated in the rainforests of Australia and has recently made a significant comeback in enterprise circles with several high-profile sightings in just the last two months. We delve into the mechanics of traditional technology-focused migrations versus the more modern, data-centric approach that utilizes knowledge graphs and triple stores to bypass the rigid constraints of old APIs. Chloe breaks down the delicate sequencing required to move use cases from old systems to new ones, the hidden dangers of business rules “marbled” into millions of lines of code, and why the era of the high-risk “Big Bang” migration is finally coming to an end in favor of incremental, data-driven evolution.
The concept of the Strangler Fig is a striking biological analogy for software engineering. How does the behavior of this rainforest plant provide a blueprint for handling the monolithic legacy systems that many enterprises are struggling to retire today?
The analogy is quite beautiful when you visualize the rainforests outside of Brisbane where Martin Fowler first observed this. A strangler fig begins its life high up in the canopy of a host tree, and rather than attacking it directly, it slowly grows roots downward and shoots upward to capture its own sunlight for photosynthesis. In our world of enterprise architecture, we treat the legacy system as that host tree, building a new structure around it that eventually supports the entire “weight” of the business operations. By inserting an intermediary that satisfies the exact same APIs, signatures, and protocols as the original program, we allow the new system to set its roots without causing the old one to collapse prematurely. Over time, the fig displaces the original host entirely, but because it grew around the host’s frame, the overall structure of the ecosystem remains intact and stable.
In the traditional application of this pattern, the focus is often on swapping out technology or platforms. Why is the “Data-Centric” version of this pattern considered a more potent evolution for modern businesses?
The traditional approach is essentially a technology swap where you try to keep the exact same functionality and merely change the underlying platform, which is often incredibly difficult because you are forced to maintain backward compatibility with every single legacy API. With the Data-Centric Strangler Fig, we’ve been practicing a variation for years that shifts the focus from the code to the data itself by extracting copies into a knowledge graph, or what we call a Triple Store. This is a game-changer because the new use cases operating against that Triple Store don’t need to be form-compatible or even API-compatible with the old system. We can drastically reduce the complexity of the data model right from the start, avoiding the trap of reintroducing the very mess we are trying to escape just for the sake of legacy compatibility. It allows us to build brand-new capabilities, like unified revenue and margin predictions that were impossible when task assignment and labor costing systems were trapped in separate, distinct silos.
You mentioned that the first step involves building a pipeline to a Triple Store. What are the specific tactical advantages of using a knowledge graph as the foundation for this migration rather than just another relational database?
When we move data into a Triple Store, we are essentially creating a live, evolving map of the enterprise’s information that can be kept up to date through a vertical pipeline. This allows the first few “native” use cases to be either read-only visualizations or dashboards that provide immediate value without the risk of pushing data back into the legacy systems. By unifying the data in this graph-native environment, we can see connections that were previously invisible, such as how labor costs directly impact specific project tasks across different departments. This architectural intervention is much less invasive than the traditional Strangler Fig because we aren’t necessarily touching the legacy server or client code in the early stages; the whole process can be mediated by the equivalent of ETL scripts or streaming architectures like Kafka. It provides a “safe zone” where we can improve data structures and functions while the legacy system continues to chug along in the background.
There is a specific “trick” to sequencing when you start replacing legacy use cases with these new graph-native ones. Could you explain the importance of documenting dependencies, specifically using the relationship between CRMs and order systems as an example?
Sequencing is perhaps the most critical part of the migration because you want the transition to be as gentle as possible for the business users. The rule of thumb is to implement use cases from the “dependent” to the “depended upon,” which might feel counterintuitive at first glance. For instance, if you have a CRM system where users are setting up customers and then placing orders, the orders are dependent on the customers; therefore, you should migrate the order-taking use case to the new system first. Once that is done, you can simply stop entering orders into the old CRM, and you’ll see the volume of traffic flowing through that legacy pipeline start to dwindle. As you recreate more of these use cases in the graph-native environment, the flow of data through the old system becomes a mere trickle until the day you can finally decommission the legacy database and server entirely.
One of the biggest fears for any architect is the “marbled” business rules hidden within millions of lines of legacy code. How do you navigate the anxiety of uncovering these rules without letting them stall the entire project?
This is a valid anxiety because legacy systems, including many SaaS implementations that have reached legacy status, often contain millions of lines of code where business logic is scattered like veins in marble. It would be a dream if every rule were encapsulated in a neat, readable module, but the reality is that one piece of code might set a flag that triggers a distant procedure, which then creates a side effect picked up even further downstream. We are starting to see Large Language Models, or LLMs, help us identify candidate rules from the code, but we have to be careful because these models generate many false positives. Many of these “rules” are actually just simplistic validation checks or implementation-specific batch processing steps that shouldn’t even be reproduced in a modern environment. Our observation is that while there might be hundreds of legitimate, essential business rules, a large portion of what people fear losing is actually just technical noise that can be safely discarded during the transition.
Why do you believe the industry is moving away from the “Big Bang” modernization approach, and how does the Strangler Fig pattern fit into this shift toward incrementalism?
History has shown us that most “Big Bang” legacy modernization projects are doomed to fail because there are simply too many moving parts to migrate all at once without breaking something critical. Practitioners have largely concluded that the secret to success is incrementalism—moving the needle one use case at a time so that the enterprise can gain confidence in the new approach. The Data-Centric Strangler Fig is the ultimate tool for this because it allows for the improvement of data structures and functionality while the transition is still in progress, rather than waiting for a “go-live” date that may never come. By avoiding a deep architectural intervention and using the knowledge graph as a bridge, we can retire the legacy front end, the server, and the database gracefully. It turns what used to be a high-stakes gamble into a predictable, manageable evolution of the enterprise’s digital core.
What is your forecast for the future of enterprise data architecture as these “Strangler” patterns become more mainstream?
I believe we are entering an era where the concept of a “permanent” application will disappear, replaced by a fluid environment where the data remains the constant while the applications that sit on top of it are constantly being “strangled” and replaced by better versions. As LLMs become more mature and provide better coverage for extracting business rules from legacy code, the speed at which we can deploy these Data-Centric Strangler Figs will increase exponentially. We will see enterprises finally breaking free from the “packaged application” trap, where they no longer have to live with a million lines of someone else’s code just to perform a few hundred unique business functions. The future belongs to those who treat their data as the sun and their applications as the foliage—always growing, always changing, but always rooted in a unified, high-integrity knowledge graph.
