GENYRA Let’s talk
☰
Genyra/Enterprise technology solutions/Software archaeology

SIGNATURE CAPABILITY / SOFTWARE ARCHAEOLOGY

Software
Archaeology.

Recover the understanding your systems were built on. From COBOL cores to ageing Java estates, we trace the code, data, rules and dependencies behind software that still works but can no longer be explained, so it can be maintained, converted or replaced with evidence rather than guesswork.

Explore the approach
Conceptual architectureNo customer data
01Interface02Business rules03Data04Dependencies Conceptual system layers Selected layer highlighted in gold
Inspect a layer

Four parts of the same system. Select one to examine.

Inspecting / Interface

Start with the behaviours people rely on. Trace an action into the components that make it work.

Inspecting / Business rules

Follow the logic that determines an outcome. Document the conditions and the exceptions that matter.

Inspecting / Data

Examine how information is stored, interpreted and moved. Establish which relationships a change must preserve.

Inspecting / Dependencies

Identify the services and systems beyond this component. A change has to account for their contracts and failure behaviour.

01 / ESTABLISH THE SYSTEM

Look beneath the interface.

A working application reveals only part of the story. Begin with the code, interfaces, data and operational context that can be examined with authorisation.

  • System boundaries
  • Available evidence
  • Operational context

02 / MAKE RELATIONSHIPS VISIBLE

Follow the logic. Find the dependencies.

Separate the layers to understand how components depend on each other, where information moves and which behaviours need to be preserved.

  • Dependency mapping
  • Business-logic discovery
  • Behavioural documentation

03 / CREATE AN INFORMED NEXT STEP

Recover understanding. Engineer what comes next.

Bring the evidence into a coherent architecture. Use the findings to consider preservation, incremental change or a carefully scoped modernisation.

  • Architecture reconstruction
  • Technical findings
  • Migration considerations
Discuss an assessment
WHY IT MATTERS

The system still runs.
Nobody can say exactly why.

Every established organisation has one, whatever its sector: a COBOL core that still settles the books, or the Java application-server estate that was built to replace it and has become legacy in its own right. Built by people who have moved on, documented in fragments if at all. It is not broken. That is the problem. Because it works, nobody has had to understand it, until the day it has to move.

Software archaeology turns that uncertainty into evidence: what the system does, what depends on it, and which parts carry the rules the organisation cannot afford to lose.

  1. The COBOL core, and the Java built to replace it.

    Core banking, insurance and payments logic still runs in COBOL: native, compiled code that few people can read but that has never needed a runtime patched at two in the morning. The Java EE estates others built to replace it in the 2000s were heavy on arrival and are outdated now. Both have to be understood before either can move, and the destination should be native again.

  2. The people who built it have gone.

    The design lived in their heads, in messages nobody kept and in a wiki last edited years ago. What remains is the code, and the code does not say why.

  3. A migration fails on a rule nobody wrote down.

    A conversion or replacement goes live, and an unexplained validation, a date convention, a rounding rule or an overnight batch turns out to be load-bearing. The fault is found in production, by the people it affects.

  4. An auditor asks a question nobody can answer.

    Regulators, auditors and counterparties expect an organisation to explain how its systems make decisions and handle data. “It has always done that” does not satisfy them.

WHAT ARCHAEOLOGY RECOVERS / LAYER BY LAYER

Take the system apart
without touching it.

A working system is read as layers, from the screens people use to the jobs that run at night. Each layer is examined for what it does, what depends on it and what would break if it changed. Follow the dig.

One application drawn as five layers: interface, business rules, data, dependencies and operation.05 OperationSchedules, access, backups, who runs it04 DependenciesBatch jobs, services, files, other systems03 DataTables, copybooks, identifiers, meaning02 Business rulesValidation, rounding, approvals, exceptions01 InterfaceScreens, forms, the paths people take

One application drawn as five layers. Conceptual, not a customer system.

  1. INTERFACE

    The actions people rely on.

    Screens, forms, reports and the paths through them. We record what users actually do, including the workarounds, because that is the behaviour any change must keep.

  2. BUSINESS RULES

    Validation, approvals and exceptions.

    Calculations, limits, approval steps and special cases accumulated over years of decisions. We separate the rules the organisation depends on from accidental implementation detail, and confirm the reading with the people who use them.

  3. DATA

    Stored meaning, and where it is silently reinterpreted.

    Schemas, codes, flags and date conventions that mean something only to the code that reads them. We trace where a value is written, who reads it and where its meaning changes on the way.

  4. DEPENDENCIES

    Jobs, services and files it cannot run without.

    Scheduled jobs, external services, shared databases and files on a disk somewhere. We inventory each one, what it is for and what happens when it is late or absent.

  5. OPERATION

    Who runs it, and how it recovers.

    Deployment, monitoring, backups, manual interventions and the people who know the rituals. We document how the system is kept alive today so that any successor can be held to the same standard.

WHAT THE EVIDENCE LOOKS LIKE / A NIGHTLY COBOL JOB

Read the program.
Recover the rule.

This is the work at its most concrete. A loan-interest program and the job that runs it, read line by line, with each business rule, rounding decision, dependency and exception recorded against the lines that prove it. The same reading applies to a Java EE service and its deployment descriptors.

Illustrative COBOL program and job · not a customer system
LNINT01.cblPROD.LN.SRCLIB · 1998 → today
001       IDENTIFICATION DIVISION.
002       PROGRAM-ID. LNINT01.
003      * NIGHTLY LOAN INTEREST POSTING        REV 1998-11
004       DATA DIVISION.
005       WORKING-STORAGE SECTION.
006       COPY LNACCT.
007       01  WS-INT-RATE        PIC 9(3)V9(4).
008       01  WS-DAYS            PIC 9(3).
009       01  WS-INTEREST        PIC S9(11)V99 COMP-3.
010       PROCEDURE DIVISION.
011       1000-MAIN.
012           PERFORM 2100-CALC-INTEREST
013           PERFORM 3000-POST-LEDGER
014           STOP RUN.
015       2100-CALC-INTEREST.
016           IF WS-DAYS > 360
017              MOVE 360 TO WS-DAYS
018           END-IF
019           COMPUTE WS-INTEREST ROUNDED =
020              LN-BALANCE * WS-INT-RATE * WS-DAYS / 360.
021       3000-POST-LEDGER.
022           IF LN-STATUS = 'F' OR 'W'
023              GO TO 3900-SKIP
024           END-IF
025           WRITE LEDGER-REC.
LNNIGHT.jclNightly window 02:10
01//LNNIGHT  JOB (ACCT),'LOAN INTEREST',CLASS=A
02//STEP010  EXEC PGM=LNEXTR01
03//STEP020  EXEC PGM=LNINT01
04//LNACCT   DD DSN=PROD.LN.ACCT.MASTER,DISP=SHR
05//LEDGER   DD DSN=PROD.GL.POST.DAILY,DISP=MOD
06//STEP030  EXEC PGM=GLPOST02,COND=(0,NE)
Read the program, trace the job, record the rule with the lines that prove it. That is the evidence a migration is built on.

01 / SOFTWARE ARCHAEOLOGY

What software archaeology is.

Software archaeology is the disciplined investigation of an existing system to recover the understanding it was built on: what it does, how it is structured, what it depends on and which of its behaviours carry decisions the organisation still relies on. It treats the code, data, configuration and operating history as evidence, and it produces documentation that did not exist before.

Systems become difficult for ordinary reasons. The people who designed them move on. Years of urgent changes accumulate beside the original design. Documentation describes the first version, not the fifteenth. Vendors disappear, source is partly lost, and a scheduled job somebody wrote one evening becomes permanent. None of this means the system is bad. It means the knowledge has drifted away from the thing that runs.

02 / SOFTWARE ARCHAEOLOGY

Recover dependencies and boundaries.

The first product of an investigation is an honest map of what the system is. We inventory components, databases, scheduled jobs, interfaces to other systems, shared files, credentials and the infrastructure underneath them, and we record which of these the system cannot run without.

The historical architecture matters as much as the current one. Knowing which parts were designed, which were bolted on and which were retired but never removed explains why the system behaves as it does and shows where a boundary can safely be drawn for a change.

Illustrative enterprise estate · 8 systems · 10 dependencies · not a customer system
Core ledgerCOBOL · CICSS01SELECTEDNightly batchJCL · 02:10 windowS02DOWNSTREAMCustomer web channelJava EES03DOWNSTREAMPayments gatewayJava EES04DOWNSTREAMReporting warehouseSQL · nightly loadS05DOWNSTREAMDocument storeStatements · filesS06DOWNSTREAMRegulatory reportingReturns · month-endS07DOWNSTREAMIdentity & accessDirectory · SSOS08Core ledgerCOBOL · CICSS01SELECTEDNightly batchJCL · 02:10 windowS02DOWNSTREAMCustomer web channelJava EES03DOWNSTREAMPayments gatewayJava EES04DOWNSTREAMReporting warehouseSQL · nightly loadS05DOWNSTREAMDocument storeStatements · filesS06DOWNSTREAMRegulatory reportingReturns · month-endS07DOWNSTREAMIdentity & accessDirectory · SSOS08
If it changes

Change the Core ledger and six systems need re-testing: the nightly batch, both channels, the document store, the warehouse and regulatory reporting.

A dependency inventory is the first product of an archaeology engagement. Each line here is a question to answer before anything moves.

The map an inventory produces. Select a system to see what its change would reach.

03 / SOFTWARE ARCHAEOLOGY

Discover the business logic.

Validation, calculations, limits, approval steps and special cases often exist only in code. Some are policy. Some are the fossil of a problem solved in a particular year. We trace each rule to where it is enforced, work out what it protects and check the interpretation with the people who use the system. The result separates rules that must be preserved from implementation detail that can be let go.

  • Calculations and rounding conventions
  • Validation and eligibility rules
  • Approval paths and exception handling
  • Rules that live in data, not code

04 / SOFTWARE ARCHAEOLOGY

Investigate interfaces and data flows.

A task rarely stays inside one program. We follow it from the screen or message where it starts, through application logic and stored data, out to the services, files and reports it touches, recording where information is transformed and where its meaning quietly changes. Interfaces that other teams or organisations depend on are documented as contracts, because they are the first thing a migration breaks.

05 / SOFTWARE ARCHAEOLOGY

Analyse only what you are authorised to analyse.

Investigation is agreed before it starts. We work from the repositories, builds, binaries, documentation and environments you authorise us to examine, on terms that respect licences, contracts and data obligations. Where source is missing, authorised analysis of binaries, configurations and runtime behaviour can recover what the application does. Representative or redacted data is preferred; production access and any change to a system are separate decisions, never a by-product of looking at it.

  • Written scope of systems, artefacts and environments
  • Legal and licensing review before binary analysis
  • Data handling agreed with your security function
  • Read-only by default; changes are a separate authorisation

06 / SOFTWARE ARCHAEOLOGY

Document what was never documented.

Everything recovered is written down in a form the organisation can keep and maintain: architecture views, dependency records, traced workflows and a register of business rules, each tied to the evidence it came from. We distinguish clearly between what was observed, what is a well-supported explanation and what remains open, so that nobody later mistakes an assumption for a fact.

  • Observed: behaviour demonstrated in code, data or operation
  • Explained: a reading supported by evidence and confirmed with users
  • Open: a question that still needs an owner and an answer
THE ENGAGEMENT

Understanding
becomes direction.

07 / SOFTWARE ARCHAEOLOGY

How an engagement is scoped.

An archaeology engagement is sized around a question: what do we need to understand before we can safely change, integrate, migrate or retire this system? From that question we agree the systems in scope, the evidence available and the depth of recovery required. Work proceeds in four stages, and each stage produces something you can keep even if the engagement stops there.

  1. Authorised evidence

    Agree the systems, artefacts, environments and data-handling terms, and confirm what we may examine.

  2. Inventory

    Catalogue components, stores, jobs, interfaces and infrastructure, and establish the system boundary.

  3. Traced workflows

    Follow the tasks that matter through the layers, recovering rules, data meaning and dependencies as we go.

  4. Findings and options

    Report what was found with its evidence, and set out the preservation, migration or reconstruction options it supports.

08 / SOFTWARE ARCHAEOLOGY

What you receive.

Deliverables are agreed against the scope and the evidence available. A typical engagement produces some or all of the following, written for the engineers who will maintain the system and the people who have to make decisions about it.

  • What depends on what?Architecture assessment and dependency inventory
  • Which decisions must survive?Behavioural documentation
  • What could change safely?Migration considerations and roadmap

  1. Architecture assessment

    Current and historical structure of the system, its boundary and the condition of each part.

  2. Dependency inventory

    Every component, store, job, service, file and interface the system relies on, with owners where known.

  3. Technical findings report

    Risks, defects, unsupported components and fragile areas, each tied to evidence and ranked by consequence.

  4. Behavioural documentation

    Traced workflows and a register of business rules, separating observed behaviour from assumptions.

  5. Migration considerations

    What must stay compatible, which interfaces are contracts, and how a change would be tested and proven.

  6. Modernisation roadmap

    Sequenced options for preserving, migrating or reconstructing parts of the system, with the trade-offs made explicit.

Service models to design an engagement around, not a record of completed client work.

09 / SOFTWARE ARCHAEOLOGY

Preserve, migrate or reconstruct.

The findings decide the path, not the other way round. Sometimes the right outcome is to keep a working component and protect it properly. Sometimes it is to move it. Occasionally it is to rebuild it from the recovered rules. Most real systems need a mixture, decided part by part.

Preserve

Keep the component as it is, document it, put it under test and contain its dependencies.

WHEN IT FITS

It works, the rules are sound and the cost of change outweighs the benefit.

Migrate

Move the behaviour to a supported platform while keeping the interfaces and data meaning intact.

WHEN IT FITS

The logic is worth keeping but the technology underneath is not.

Reconstruct

Re-implement from the recovered rules and workflows, dropping accidental complexity.

WHEN IT FITS

The original can no longer be safely changed and its purpose is now understood well enough to rebuild.

Whichever path is chosen, the recovered documentation becomes the acceptance standard for it: the behaviours that must survive, the data that must keep its meaning and the interfaces that must not change.

Before an enquiry

Questions we are asked.

Short answers in the same terms as the page. Anything specific to your systems is agreed by enquiry.

What is software archaeology?
The disciplined investigation of an existing system to recover what it does, how it is structured, what it depends on and which of its behaviours carry business decisions, so it can be maintained, integrated or replaced on evidence rather than guesswork.
Do you need the source code?
Source is the best evidence, but an investigation can start from builds, binaries, databases, job schedules and operating documentation you are authorised to share. Every finding states the evidence it rests on.
Does an investigation mean the system has to be replaced?
No. The findings decide the path. Often the right outcome is to keep a working component and protect it properly, or to change one boundary rather than rewrite the whole application.
How is an engagement sized?
Around a question: what must be understood before this system can safely change, integrate, migrate or retire. The systems in scope, the evidence available and the timing are agreed before work starts.
What is legacy code?
Code that still works, that something important depends on, and that nobody can change with confidence. Age is incidental; the missing understanding is the problem, and an investigation recovers it.
Static or dynamic code analysis?
Both, plus the data. Static analysis recovers structure and dependencies from the source; dynamic analysis shows which paths actually run under representative inputs; data analysis finds the identifiers and relationships that give the code its meaning.
CONTINUE THE EXPLORATION
Legacy system modernisationSystems integrationEnterprise engineering
A CLEARER NEXT STEP

Discuss an archaeology assessment

From an unanswered question
to an engineered possibility.

Discuss an archaeology assessment
Chat on WhatsApp