CTO · VP Engineering · Director of Engineering
Make critical engineering decisions with fewer unknowns.
The systems your roadmap depends on are expensive to change and understood by too few people. Engineers keep re-investigating the same questions instead of shipping. You have to decide what to change, replace or leave alone, and the decision has to hold.
The questions you need answered.
- How much engineering time goes into rediscovering how our own systems behave?
- What exactly are we risking if we change this system?
- Can we modernize incrementally, or does this have to be a rewrite?
- How do we stop depending on the two people who still remember how it works?
- Which parts of this could we safely automate or hand to an agent?
Worth knowing first.
Knowledge debt
Behavior that exists only in running code and in a few heads. It costs nothing until someone has to change it. Then it costs every time.
Evidence states
A finding is verified, observed, inferred or open. A decision built on inferred behavior carries a risk that one built on verified behavior does not.
Reusable system knowledge
An investigation that ends in a document nobody maintains is a one-off. One that ends in specifications and tests is an asset the team keeps using.
Before you commit the quarter.
Name the decision
Rewrite, replace, integrate, extend or leave alone. The analysis should serve that decision, not describe the system in general.
List what has to survive
The behaviors customers and other systems rely on, whether or not anyone intended them.
Separate known from assumed
For each item: verified, observed, inferred or open. Fund the work to close the open ones that matter.
Decide with the evidence in hand
Commit engineering time once the risk is visible, not after it has materialized.
Where Foundry fits.
Every finding carries its evidence state: verified, observed, inferred or open. How we work.
Map undocumented systems
A behavior report and dependency map your team can hand to anyone, so the knowledge stops living in individuals.
Assess change impact
What a change, migration or replacement will affect, and which behavior has to survive it, before you staff the project.
Watch for change
Re-analysis when the system or its dependencies change, so the knowledge stays current instead of decaying.
Reading for your situation.
Discovery, verification and security assurance are three different things
What behavioral discovery establishes, what verification adds, and why neither is a security audit or a compliance result.
How to build an inventory of undocumented dependencies
A method for finding what a system calls, reads, writes and waits on, when nobody wrote it down, and for recording how sure you are about each item.
How to define an effective software intelligence engagement
What to pin down before anyone analyzes a system for you: the decision, the authorized target, data handling, success criteria, deliverables and limits.
How to investigate an undocumented system without confusing inference with fact
A working method for learning what an undocumented system does, and for keeping what you saw separate from what you assumed.
Next step.
Bring the system and the decision it blocks. We scope a defined engagement around it.