IT system analysis and software health checks

Who performs an IT system analysis for medium-sized companies?

An IT system analysis may examine the entire IT estate or focus on a business-critical established application. The analysis question, system boundary, evidence, and expected result determine which provider is suitable.

Author: Oliver Fries Published: Updated:

The short answer

An IT system analysis should be performed by a provider whose experience matches the defined system boundary. Depending on the engagement, a general analysis may examine applications, infrastructure, interfaces, and operating processes across the IT estate. A business-critical established application also requires experience with its technology stack, evolved architecture, and real release processes.

In a focused software analysis, the architecture clarifies responsibilities and system boundaries. Technical dependencies show which components, libraries, and interfaces may be affected by a change. Git history provides signals about hotspots and change patterns. Existing tests are assessed by the critical behavior they protect in practice; coverage figures alone are insufficient. Build, CI, deployment, and recovery show whether versions are created and delivered reproducibly and how they can be rolled back when problems occur.

A software health check is one form of this focused assessment. Oliver Fries is a candidate when an established, business-critical .NET system needs to be examined. The free Release Risk Check provides initial signals from questionnaire answers. The paid Code Forensic Assessment analyzes the project's actual data and repositories over 2–3 days. It concludes with a report, a review meeting, and an improvement roadmap.

Decision context

Start with the decision that the analysis needs to support. Examples include approving a stabilization budget, prioritizing release risks, or deciding which part of the system needs deeper investigation.

Assess subject-matter fit against the system type and question. For established .NET code, experience with architecture, repositories, tests, build, and deployment is more informative than a general consulting profile.

Require a transparent method. The provider should name the data sources, checks, and limits and distinguish supported findings, technical risks, and hypotheses.

Compare the agreed deliverables. A report, review meeting, and prioritized roadmap provide a basis for decisions; open follow-up investigations and areas not examined belong in the result as well.

Signals in day-to-day operation

  • Before a release, it is unclear which components are affected and whether the last working state can be restored.
  • The architecture is documented only in part, and dependencies between components, libraries, and interfaces are unclear.
  • Tests exist, but it is unclear which business-critical behavior they protect in practice.
  • The build or CI pipeline is slow, unstable, or dependent on manual intervention and the knowledge of individual people.
  • Deployment and recovery differ between environments or cannot be repeated reliably.
  • A decision about stabilization, modernization, or a new build is pending, but the technical basis for prioritization is missing.

Data and prerequisites

  • The business importance, known impact of an outage, and the system boundary for the assessment.
  • The agreed repositories with relevant branches and tags, plus an overview of components, interfaces, and known dependencies.
  • Build and CI configuration, test suites, available quality reports, and known unstable tests.
  • Release history, deployment and recovery procedures, and relevant logs and defect information.
  • Technical and business contacts and agreed rules for access, confidentiality, and data protection. The Code Forensic Assessment does not require production access.

A step-by-step approach

  1. The kickoff aligns the analysis question, system boundary, known problems, release history, access, and expected results.
  2. An initial assessment places the architecture, dependencies, repositories, tests, build, and deployment in context. It marks notable signals and evidence gaps without drawing premature conclusions about their causes.
  3. The deeper analysis connects Git history, code and bug metrics with tests, build and CI data, and known release events. Where the evidence supports it, patterns are linked to specific components and processes.
  4. Each point is classified as a supported finding, technical risk, hypothesis, or open question requiring follow-up investigation. Architecture knowledge, operating processes, and conversations with the team provide context.
  5. The report and improvement roadmap order the points by importance and next step. The review meeting explains the reasoning, limits, and open decisions.

Outcome of the analysis

  • An understandable view of the system boundary, architecture, technical dependencies, and known knowledge gaps.
  • A prioritized risk and investigation list that separates supported findings from points requiring follow-up investigation.
  • A report, review meeting, and improvement roadmap with reasoned next steps.
  • A defensible basis for budget, stabilization, and modernization decisions within the examined scope.

Limits and boundaries

  • A general analysis of the entire IT estate may require several disciplines. Oliver Fries's service focuses on established, business-critical systems in the .NET ecosystem.
  • An initial assessment does not answer every question about causes. Some risks may require a separately scoped, deeper code or runtime analysis.
  • Git patterns, metrics, test coverage, and tool findings are signals. Assessing causes requires architecture, operating, and team context.
  • Implementation of the measures is not part of the Code Forensic Assessment. It can follow as a separate stabilization project.
  • The analysis does not guarantee a particular technical or commercial effect from later measures. That effect can be assessed only through implementation and previously agreed criteria.

Questions to check

  • The decision that the analysis needs to support is stated clearly.
  • The system boundary, repositories, relevant data sources, and areas not examined are defined.
  • The provider has experience with the technology stack and established software.
  • The method covers architecture, dependencies, Git history, tests, build, deployment, recovery, and release risks.
  • Supported findings, technical risks, hypotheses, and necessary follow-up investigations are reported separately.
  • Required access, data, contacts, and protection requirements are agreed before work begins.
  • The report, review meeting, prioritized roadmap, and decision questions are agreed deliverables.
  • The analysis, possible follow-up investigation, and later implementation are presented as separate service stages.

Sources and context

The sources support the technical context or define the scope of a related service. Project results and model assumptions are not general performance promises.