mimicry transforms legacy systems using observation of behavior - the same approach engineers naturally use to understand software, automated at scale, refined to be accurate and comprehensive.
How Engineers Actually Understand Software
Ask your developers: When you need to understand an unfamiliar system, what do you do first?
You probably won’t hear “I read all the source code.” Instead, they’ll describe something like this:
They run the system - enter data, see what happens, try different scenarios
They observe and experiment - test edge cases, trace through workflows, watch how data flows
They build a mental model - forming hypotheses about what the system does and how it works
Along the way - they might review documentation (if it exists and is current), talk to subject matter experts, or search through code for specific pieces they need to understand
They verify and refine - find relevant code sections, read just those parts, make targeted changes, test thoroughly
They don’t try to understand everything. They understand what’s needed to accomplish their task.
mimicry Automates the Core Approach - At Scale
mimicry takes this natural and proven approach and scales it through technology that makes what was once manual and limited now automatic and comprehensive:
Observes thousands of transactions instead of one or a few
Captures every edge case not just whatever scenario is currently in focus
Analyzes all interfaces - databases, APIs, files - not just the UI
Generates targeted test cases to clarify ambiguities and narrow down decision boundaries
Builds a complete model validated against reality through continuous testing
Tests exhaustively - millions of parallel observations provide strong confidence in equivalence
The difference? Speed, completeness, and validated equivalence.
The approach? Inspired by what engineers do naturally, powered by advanced technology that makes it automatic, accurate, and comprehensive.
If you want to understand how this works under the hood, here’s the detailed process:
1. Collect Observations
We instrument your system to capture complete input/output traces from the application processes:
All file system operations
All database queries and results
All network operations
All API calls and responses
All input/output device activities
Scale: Millions of observations across representative workloads - normal operations, edge cases, error conditions.
2. Mine Application
Discover overall structures and all observed behavioral patterns.
3. Extract Mental Model
Build a model of what the application does through discovery of:
Interfaces
Workflows
Data types and data models
Data flows
Functions and conditions
4. Visualize the Mental Model
Enable analysts and engineers to explore the mental model - as overview, drilling down into individual patterns, or filtering certain types of cases.
5. Create Executable Specification
Use the extracted mental model to create an application that mimics the behavior of the original application, built in a modern architecture, consistent with the mental model.
6. Validate Functional Equivalence
Run the executable specification in parallel with the original system, using existing and newly generated test cases or new production cases. Validate that for same inputs, the same outputs are generated. Where deviations show up, refine mental model and executable specification.
Human-in-the-Loop
While mimicry performs its activities, humans guide the analysis and mining process, the build-up of the mental model, and the creation of the executable specification. Humans also fill in gaps in mimicry’s knowledge, such as domain knowledge about data types or functions.
How mimicry Compares to Other Approaches
Understanding legacy systems requires different tools for different goals. Here’s how the main approaches compare:
Interviewing Subject Matter Experts
The most human way to understand a system. Yields valuable information about business context, technical rationale, and design intent.
Best for: Understanding business context, design rationale, organizational history
Limitations: SME availability constraints, memory gaps after many years, and the sheer complexity of detailed mental models typically lead to incomplete understanding that deviates from actual implementation.
Reading Documentation
The simplest approach when documentation describes what you need clearly and accurately reflects what the application actually does.
Best for: Quick reference, understanding intended behavior, architectural overview
Limitations: Documentation often suffers from incompleteness, inconsistencies, and outdated information - providing needed clarity in only a few cases.
Analyzing Source Code
Determining a mental model from source code is an intellectual challenge of extraordinary complexity.
To understand how a specific transaction is processed, you must study many sections of code and their interactions. Each section doesn’t just handle your transaction type - it handles a multitude of different ones, forcing you to constantly filter what’s relevant to your case.
Simultaneously, you’re disentangling business logic from architectural and technical design choices at every level - language idioms, framework patterns, decades of accumulated technical decisions.
The constant context switching between files, the mental filtering of irrelevant code, the cognitive load of separating “what” from “how” - this overwhelms even the most capable engineers. Traditional and AI-based static analysis tools face the same fundamental challenge.
Best for: Understanding internal architecture, debugging specific issues, working within the existing codebase
Limitations: Extremely high cognitive load, time-consuming, requires expert knowledge of technologies used
mimicry
mimicry observes what the system actually does and derives a mental model of its business logic from behavior - interfaces, workflows, data flows, data types and models, functions and conditions.
This approach sidesteps the entanglement problem entirely. You get the business logic without needing to disentangle it from decades of architectural choices. mimicry derives both common patterns and edge cases from large observation sets, then creates an executable specification validated for functional equivalence through extensive testing or parallel runs.
Best for: Understanding business logic, replacing or transforming legacy systems, creating modern equivalents
Limitations: Does not provide information about the internal architecture of the original system or links between the model and source code
A New Tool in Your Toolbox
Understanding software systems requires different approaches - each with their strengths and limitations. mimicry adds a powerful new capability to this toolbox - one that’s often the most direct path when the goal is understanding what the system does rather than how it’s currently built.
The approach builds on decades of research in program comprehension, software analysis, process mining, data mining, and machine learning.
mimicry has been applied to:
Payment processing, securities processing, batch systems, stock exchange order book processing, file decoding and transformation, complex business rule engines, tax calculators, web applications, Linux command line tools, master data design and maintenance tools, process monitoring tools, end-user computing solutions.
Each application has contributed valuable insights to refining our approach, informed by our deep experience with enterprise legacy challenges.
Common questions are addressed in our FAQ, covering topics like target architecture, completeness and precision of the mental model, and project approach, efforts, and timelines. Our blog explores the technical foundations and practical insights from our work in greater depth.
Ready to Understand and Transform Your Software Systems?
Let’s discuss the legacy challenges you are facing, the options you may have, and whether mimicry is right for you.
