IT assessment for SMEs: what decision should it help you make?

Use the investment question to define the investigation

Consider a hypothetical company planning to replace an established application. Changes take a long time, and an extension is planned for next year. The assumption is that rebuilding would cost less than continuing maintenance.

Before approving that budget, I would want to understand what causes the effort. Is the code difficult to change? Are suitable tests missing? Or does the team wait for an approval outside development whenever a change is made?

Those causes call for different actions. The assessment should test the assumption behind the investment. A technical action plan is useful when it supports the decision you need to make.

Write that question in one sentence before starting. Include the options being considered and the constraints already known. A delivery deadline or expiring contract can affect the decision without being a technical weakness in the system.

The system boundary determines who needs to be involved

An assessment of an existing application can examine architecture, source code, dependencies, tests, build and deployment. Assessing networks, identities, devices, cloud contracts or operational responsibilities requires appropriate expertise in those areas. The term IT assessment does not define that scope by itself.

I would draw the boundary around the business process concerned. Which applications, interfaces and manual handovers take part in it? Which will be investigated, and which will initially be treated as external constraints?

You do not need a complete architecture diagram to begin. Walking through the process with the people responsible can establish the first overview. Any visible gaps should remain explicit. An unknown data flow must not quietly become an accepted system boundary in the report.

My Forensic Code Assessment examines a defined software system using agreed questions and evidence. It does not automatically include an assessment of the company's entire IT landscape.

Findings need business context

A list of noteworthy files is rarely enough to support an investment decision. I want to see which business process a finding affects and how it creates a risk.

A frequently changed part of the system may deserve closer attention. The change pattern alone does not establish a problem. Frequent adaptation may be part of its business purpose. Responsibilities or suitable safeguards may also be missing. Those explanations need checking.

Quality characteristics can help organize the questions. The ISO/IEC 25010 product quality model provides a vocabulary for that purpose. The assignment still needs to define which characteristics matter to your decision. Using that model does not certify the software being examined.

A metric also needs context. A value without the examined revision, collection method and business relevance is difficult to use for a budget decision. I would therefore ask for an understandable explanation of each prioritized finding.

Start with a traceable evidence base

Before the investigation, establish which materials exist and who can provide them. These include the repositories concerned, architecture information, test reports, build configurations and known failure patterns. Technical and business contacts provide the context.

The documentation does not have to be perfect. Missing information can be a finding in its own right. It should then be clear which conclusion remains open and how a focused check could resolve it.

I would start by walking through one important process and connecting the available evidence to it. For example: which change affects this process, which tests check it, and how does the resulting version reach the intended environment?

Code coverage shows which code was executed during a test run. The business situations checked by those tests need separate examination. (Microsoft on code coverage)

Access and confidentiality must be agreed beforehand. My Forensic Code Assessment does not require production access. Investigating runtime behavior would need a separately defined scope; it cannot be silently inferred from a repository assessment.

The report should prepare decisions

After the assessment, you should be able to distinguish established findings, technical risks and explanations that remain hypotheses. An open question needs a next check. A recommendation needs its prerequisites and known limits.

For the hypothetical replacement project, one outcome might be to define a particular business area more precisely and examine its testability. That would be a reasoned follow-up investigation. It would not yet establish a decision to rebuild the whole application.

I prefer to agree on a traceable decision basis rather than an overall health grade. The published outcomes of my Forensic Code Assessment include a report, dynamic audit, short summary and roadmap. What they cover depends on the agreed questions and depth of analysis.

Implementation remains a separate step. The costs and benefits of possible changes also need to be assessed against their specific scope. An assessment can prepare that decision; it does not guarantee a particular financial result.

What I would establish before commissioning the work

• Which decision should the assessment help you make?
• Which systems and business processes are within its scope?
• Which data, access and contacts are available?
• How will findings, risks, hypotheses and open questions be distinguished?
• Which results will be handed over, and who will review them with the team?
• Which follow-up investigations and implementation work need separate agreement?

Once those points are clear, you can compare proposals by scope and usefulness. A focused code and architecture assessment may fit an established application. Other parts of the IT landscape need different expertise. Deciding which applies belongs at the start of the project.