Can a systems architecture assessment work without source code?

The short answer

A systems architecture assessment does not require source code in every engagement. It requires enough traceable evidence to test the specific cost or schedule decision in scope. When source is unavailable, the assessment states which conclusions remain supported and which cannot be made with confidence.

Source code is one evidence source. It can reveal dependency patterns, implementation relationships, and change concentration that documents do not show cleanly. But many executive decisions concern system boundaries, interface ownership, verification obligations, change propagation, and program commitments. Evidence for those questions often exists outside the repository.

Begin with the decision, not the data request

A useful scope starts with the decision that must be made. A board may need to decide whether to fund structural work. A program director may need to decide whether another schedule is credible. An acquiring organization may need to decide which roadmap commitments can be accepted.

Each decision creates a different evidence boundary. Asking for every repository before defining that boundary increases handling work without ensuring a better answer.

Evidence that can support the assessment

Depending on the decision, the assessment can use:

• systems architecture records and design decisions;
• system, software, and interface requirements;
• interface-control documents and ownership records;
• change requests, issue histories, and release records;
• integration and verification evidence;
• existing static-analysis or scanner output;
• interviews with engineers responsible for the boundaries.

The evidence is not assumed to be complete. The assessment records whether a relationship is documented, inferred from several sources, disputed, or known only through practitioner testimony.

What changes when source is unavailable?

The method does not pretend that all evidence sources are interchangeable. Without source access, some implementation-level dependencies may remain unobserved. The correct response is to narrow the claim and expose the uncertainty.

For each material finding, the decision record should show:

• which evidence supports the relationship;
• what was not available;
• which assumptions bridge the gap;
• how sensitive the cost or schedule exposure is to those assumptions;
• what additional evidence would change the decision.

The methodology brief describes this separation between evidence, assumption, and conclusion.

When is non-source evidence enough?

It may be enough when the decision concerns cross-team interfaces, ownership boundaries, evidence coverage, or the credibility of a program commitment and those relationships are visible in controlled records and corroborated interviews.

It is less likely to be enough when the decision depends on implementation relationships that are absent from every other evidence source. In that case the assessment should recommend targeted source access, a bounded scanner extract, or further measurement—not a stronger conclusion.

Restricted and inherited systems

Source may be unavailable because ownership is transferring, a supplier controls access, or handling rules make movement impractical. Those are scoping constraints, not reasons to invent certainty.

The assessment boundary, transfer method, access, retention, and deletion are agreed before material moves. If the handling required for the evidence cannot be supported, the engagement does not start with that evidence.

For regulated programs, the regulated systems architecture evidence guide explains how this boundary remains separate from certification or safety judgments.

What the buyer receives

The output is not a source-code quality report. It is an evidence-backed record of the systems architecture relationships relevant to the decision, the resulting cost and schedule exposure, the assumptions that matter, and the bounded options available.

The constructed sample assessment shows how evidence coverage and uncertainty are presented without describing a client engagement.