Behaviour is unclear
Business rules and exception paths are buried across code, data and interfaces.
Legacy application discovery
Understand the application before you decide how to change it.
Discovery should establish what the application does, not simply inventory what is in the repository.
Harten reconstructs behaviour, dependencies, data relationships and interfaces from the evidence available, then makes the gaps explicit for technical and domain review.
When discovery is needed
Start when the system is important but the knowledge is fragmented.
Legacy application discovery is useful when the next decision depends on facts that are spread across code, documentation, configuration and people.
Dependencies are uncertain
Teams cannot confidently explain what will be affected by a proposed change.
What Harten establishes
A reviewable account of the current application.
The output is designed to be challenged. It separates source-supported findings from interpretation and unresolved questions.
Application behaviour
Capabilities, rules, state changes and exception paths within the agreed boundary.
Relationships
Data, interfaces, dependencies and the technical paths that connect them.
Uncertainty
Questions that require more source evidence, runtime evidence or human judgement.
Evidence boundary
Discovery is not a claim that the whole system is understood.
- Source support: material findings retain inspectable evidence.
- Human review: domain and operational context is used where source alone is insufficient.
- Open questions: uncertainty is carried forward rather than hidden.
- Next decision: the result should make scope, architecture or investment easier to challenge.
Inspect the work
See what application discovery looks like in practice.
CardDemo and PRSD-IWS show selected source-checked findings and the decisions they create. They are public worked examples, not customer case studies.