Understand
Technical Discovery & System Understanding
Know the system before you change it.
Bring scattered software knowledge into a validated view of the business functions, dependencies and constraints that matter to your next decision.
What you receive
The result of this engagement.
A validated account of the scoped business functions, system relationships and knowledge gaps needed for handover or change.
- System and dependency maps with evidence references and confidence limits.
- Recovered business rules, critical flows and change constraints within the agreed boundary.
- A prioritised knowledge-gap register and decision or handover report; a requirements brief where included in the agreed scope.
Example handoff
A critical flow, ready for handover.
An incoming supplier needs to understand order dispatch before changing the warehouse integration. The example connects a business rule, the implemented flow, dependencies and an unresolved verification question.
What must the supplier preserve, and what must it verify before changing dispatch?
- Order APIAccept an authorised order request.
- Order recordStore the order identifier and dispatch state.
- Dispatch adapterSend the request using the stored order key.
- Warehouse APIAccept the request and return a dispatch reference.
Evidence and confidence
- EX-D1 · selected trace
- The trace follows one order through the record and dispatch adapter. It supports this path, not every order type or failure condition.
- EX-D2 · implementation
- The illustrated handler and schema retain the order key for retries. Warehouse-side duplicate suppression is outside the inspected boundary.
- EX-D3 · owner statement
- The owner reports the business rule: one order must not create duplicate dispatches. Record its source and distinguish the requirement from verified system behaviour.
- Open evidence
- The warehouse duplicate-handling contract and a repeated-request test are unavailable. Duplicate suppression remains unverified.
Recovered rule and decision consequence
- Rule to preserve
- Keep a stable order identity across dispatch attempts. A changed identifier could defeat any downstream duplicate check.
- Scoped finding
- The selected adapter path reuses the stored key (EX-D1, EX-D2). That observation alone cannot establish end-to-end duplicate prevention.
- Recommended next action
- Confirm the warehouse contract and test repeated requests before the supplier changes the integration. Preserve the identifier and dispatch-state relationship in the transition.
What the incoming team receives
- Handoff package
- The selected flow and dependency view, source register, recovered rule, confidence annotations and a named verification action.
- Responsibility
- Our lead architect owns the scoped interpretation. The client validates business intent; the incoming supplier plans and executes the integration verification.
- Boundary
- Other order types, cancellation paths and the warehouse implementation remain outside this example. Extend the map only when evidence supports them.
When this helps
Recognise the situation.
- You have inherited a system whose documentation and actual behaviour have drifted apart.
- A key person is leaving, a supplier is changing, or an implementation partner needs a reliable technical brief.
- A modernisation or investment decision depends on understanding business rules, integrations and change constraints.
How it works
Evidence appropriate to the question.
Set the boundary
Agree the business question, systems, critical flows and the depth of understanding required.
Reconstruct and validate
Investigate relevant code, documentation, configuration, integrations, tests and owner knowledge. AI-assisted analysis lets us read and connect far more of it than a manual review can. Validate the interpretations that matter with the people and evidence available.
Create a usable shared view
Connect system structure to business functions, dependencies, unresolved questions and the intended handoff.
Scope & responsibility
Agree the scope and depth. Keep the boundaries clear.
Scope of the engagement
A partner-ready discovery report and a deep existing-system reconstruction have different evidence needs and effort. We agree the system boundary and validation depth before committing to timing or price.
Limits of reliance
Understanding work does not automatically include a complete target architecture, every business rule in an estate, or implementation. Missing sources and unverified behaviour remain explicit.
The agreed scope of the engagement sets the coverage, deliverables, responsibilities, timing and fixed fee. Any change to the scope is agreed in writing.
Relevant experience
Read the work in its actual context.
Questions
Before you book.
Do you need source code?
Not for every scope. Documentation and owner interviews may support an initial report. Deeper reconstruction normally needs the relevant source, configuration and operational context.
Is this only for legacy software?
No. Newly built products can also be poorly understood. The same question arises in inherited applications, supplier handovers and AI-assisted development.
How long does it take?
It depends on the number and size of the systems. One small system usually takes about a week. Several systems take two to three weeks or more. We agree the timing and a fixed fee before work starts.
Related work
Related services
Each is available as a standalone service when the evidence and scope support it.
What's the decision in front of you?
Tell us the situation and what you intend to commit to. 25 minutes on Teams, no preparation needed. If this scope is not the right fit, we will say so.