The uncomfortable truth about most enterprise IT landscapes is that no single person, and often no single document, holds an accurate account of what exists, how it connects, and why it behaves as it does. Systems accumulate over decades through acquisitions, reorganisations, urgent tactical fixes, and the departure of the engineers who understood the original intent. The map, if there is one, drifts steadily from the territory. What remains is a set of partial views: a configuration management database that was accurate three years ago, architecture diagrams drawn to win project approval rather than to describe operation, and a great deal of undocumented knowledge held informally by a handful of long-serving staff.

This matters now for reasons that have sharpened considerably. IT landscapes are more interdependent than they have ever been, with cloud services, on-premise legacy, software as a service, and integration middleware woven into flows that cross organisational and vendor boundaries. Regulatory expectations around data, resilience, and supply chain have hardened, so the ability to demonstrate what you run and how it is controlled is no longer optional. And the pace of change means transformation programmes are launched continuously, each one making decisions that depend on an accurate baseline. When the baseline is wrong, the programme inherits the error and amplifies it. Establishing ground truth is therefore not preliminary housekeeping. It is the single most consequential input to every decision that follows.

The terms assessment and audit are used interchangeably in casual conversation, and treating them as synonyms is the first mistake. They answer different questions, obey different standards of proof, and produce different kinds of confidence. An assessment is diagnostic and forward-looking. It asks what the true state of the IT landscape is, where the risk and the technical debt sit, and what should change. It is comfortable with informed judgement, with reading between the lines of imperfect evidence, and with expressing findings as a considered professional opinion. Its output is understanding and a direction of travel.

An audit is evaluative and evidential. It measures the IT landscape against a defined standard, a control framework, a policy, a licence agreement, or a regulatory obligation, and it asks whether conformance can be demonstrated. Its currency is evidence that would withstand challenge: the configuration as it actually is, the log that proves the control fired, the record that shows who approved the change. An audit is far less interested in what ought to happen next and far more interested in what can be proven about what is. The two disciplines are complementary and often run together, but conflating them produces weak work. An assessment dressed as an audit makes claims it cannot substantiate. An audit dressed as an assessment mistakes conformance for health, ticking every box while the IT landscape quietly fails around the edges of the checklist. Knowing which question you are answering, and holding yourself to that question's standard of proof, is the foundation of the craft.

Everything described so far is technical analysis: the disciplined reading of a system as it has actually been built and now behaves. It answers the question what is true of what we have. It is indispensable, and it is only half of the work. The other half is business analysis, which answers a different question, what does the organisation actually need the system to do, and it draws on a separate body of skill. The two are complementary, and the frequent mistake is to fund one and assume the other happens on its own. A change scoped from technical analysis alone rebuilds what exists with more modern parts and never asks whether it should exist at all. A change scoped from business analysis alone specifies a need in a vacuum, blind to the constraints and the debt that will govern what is feasible. Serious analysis holds both lenses at once.

Requirements are the core of business analysis, and they come in kinds that must not be blurred. Functional requirements describe what the system must do, the behaviour a user or another system can observe. Non-functional requirements describe how well it must do it, the qualities that decide whether that behaviour is actually usable in practice: performance and response under load, availability and resilience, security and privacy, scalability, accessibility, and the regulatory obligations the system must satisfy. Technical requirements and constraints describe the ground the solution must stand on, the platforms it must run on, the systems it must integrate with, and the standards it must honour. Projects fail far more often on neglected non-functional and technical requirements than on missed features, because the feature is visible and demanded while the quality is assumed and silent until it breaks in production.

Separating the need from the stated want is the analyst's real craft. Stakeholders arrive with solutions already in mind, described as requirements, and the untrained response is simply to write them down. The disciplined response is to recover the underlying need, the outcome the proposed solution was meant to achieve, because it is at the level of need that better and cheaper options usually appear. This is not obstruction. It is the difference between building what was asked for and building what was wanted, which are distinct far more often than anyone is comfortable admitting.

Requirements do not float free. They rest on two things that reward analysis in their own right, and a third that returns us to the IT landscape.

Process and workflow analysis asks how work actually flows, step by step, across the people and systems that carry it, and where it waits, doubles back, or quietly depends on a spreadsheet nobody will admit to. Most requirements are really statements about a process, and a requirement gathered without the process behind it tends to automate an accident of history rather than a considered design. Mapping the real workflow, as it is rather than as the procedure claims, is often where the most valuable findings and the largest simplifications are discovered.

Data and information analysis asks a different set of questions: what information the organisation holds, what it truly means, where it originates and how it flows, and whether it can be trusted. It is the work of conceptual and logical data models, of definitions agreed across departments that each thought they already knew what a customer or a product was, and of honest assessment of quality and lineage. Systems are, in the end, machines for moving and transforming information, and an analysis that treats data as an afterthought inherits every ambiguity and every duplication the information already carries.

Technical and system analysis completes the set, and here we return to the IT landscape assessment and audit described earlier: feasibility, integration, the constraints of the existing architecture, and the debt that will shape any solution. The point of naming these forms separately is not to sell four engagements where one would do. It is that each uses a different skill and answers a different question, and the worth of an analysis practice lies precisely in knowing which one a given problem actually needs, and in sequencing them so that requirements, process, information and the system inform one another rather than being gathered in isolation and stitched together too late.

These forms are all part of what we offer under analysis, from the strategic and business end through to the deeply technical. An engagement might need only one of them, or all of them in concert, and the first act of good analysis is deciding which.

The governing principle of good diagnosis is that evidence outranks assertion, including the confident assertion of people who genuinely believe they know their own systems. This is not cynicism about colleagues. It is a recognition that human accounts of technical landscapes are systematically unreliable, not through dishonesty but through the ordinary decay of knowledge. People describe the system as it was designed, or as they last understood it, or as they wish it were. They report the intended data flow and omit the emergency workaround that has quietly carried production traffic for two years. Diagnosis that rests on interviews alone inherits every one of these distortions.

Evidence-based analysis therefore triangulates. It gathers what people say, then tests it against what the artefacts declare and what the running system actually does. Configuration files, infrastructure-as-code definitions, deployment manifests, network rules, database schemas, and access policies are the IT landscape's own written record of itself, and while they can be stale, they are harder to misremember than a conversation. Behaviour is more truthful still. Telemetry, traffic captures, dependency traces, log volumes, and resource consumption reveal what is genuinely in use, what talks to what, and where the real load and the real fragility lie. When these three sources agree, confidence is high. When they disagree, the disagreement is itself a finding, usually the most valuable one in the engagement, because divergence between belief, declaration, and behaviour is exactly where hidden risk and undocumented dependency live. The practitioner's task is not to collect evidence for its own sake but to resolve these contradictions into a defensible account of reality.

An architecture is rarely handed to you cleanly. More often it must be reconstructed, inferred from the traces it leaves, in the way a field geologist reads a landscape from exposed strata rather than from a designer's blueprint. The artefacts are the first stratum. Source repositories reveal structure, coupling, and the shape of the codebase, and their commit history reveals which components change constantly, which have been frozen for years, and where change concentrates. Build and deployment pipelines expose the real topology of what ships together and therefore what is coupled in practice, regardless of what the logical diagram claims. Infrastructure definitions show the intended runtime; the actual runtime, discovered through inventory and scanning, shows the drift between intention and operation, and that gap is often where the interesting problems sit.

Behaviour is the deeper stratum, and it is where inferred architecture is confirmed or overturned. Dependency mapping built from observed traffic and distributed traces shows the true call graph, including the surprising edges: the reporting job that reaches directly into a transactional database, the deprecated service that still receives requests, the third-party endpoint that a critical flow silently depends upon. Data flow analysis follows information across boundaries and frequently uncovers duplication, undocumented copies, and lineage that no governance record captured. The discipline in all of this is to distinguish the accidental from the essential. Not every dependency is deliberate, not every coupling is necessary, and part of reading an architecture well is recognising which structures express genuine design intent and which are scar tissue from expedient decisions made under pressure. The reconstructed picture must always be held as a hypothesis, tested against fresh evidence, and revised without attachment when the behaviour contradicts the story.

The most expensive failures in analysis are failures of causal reasoning, and they cluster around a small number of recognisable patterns. Symptom fixation is the most common: a diagnosis that catalogues everything that hurts without asking why it hurts. Slow response times, recurring incidents, and rising cost are symptoms, and treating them directly, by adding capacity or tightening a timeout, can relieve the pain while leaving the underlying pathology, a structural bottleneck or a design that scales poorly, entirely intact to resurface elsewhere. Good diagnosis keeps asking why until it reaches a cause that, if addressed, would dissolve a whole family of symptoms at once.

Tool worship is the belief that a scanning product's output is a diagnosis. Automated discovery, vulnerability scanners, and dependency analysers are indispensable for gathering evidence at scale, but they generate findings, not understanding. A list of two thousand vulnerabilities ranked by a generic severity score is data awaiting interpretation, not a conclusion, and treating the tool's ranking as the priority order ignores the context that determines what actually matters in this IT landscape. Confirmation scoping is the quieter danger: framing the analysis to validate a decision that has already been taken, so the assessment becomes a justification exercise and the evidence that would complicate the preferred answer is never gathered. Precision theatre is the seductive final trap, in which enormous rigour is applied to the measurable and the trivial while the genuinely consequential structural risk, harder to quantify, goes unexamined because it does not fit neatly into the spreadsheet. Every one of these failures shares a root cause of its own: prescription arriving before diagnosis is complete, and the analysis being quietly bent to fit the remedy someone already wanted to sell.

Nashua treats analysis and auditing as a deliberate, evidence-led practice rather than a preamble to selling a change. An engagement begins by fixing the question with precision, because assessment and audit demand different work, and being clear about which one is being asked prevents the whole exercise from drifting into weak generality. From there the approach is systematically triangulated. What stakeholders describe is captured and respected as a source of intent and history, then held against what the artefacts declare and, wherever it can be gathered safely, against what the running landscape actually does. Configuration, code structure, infrastructure definitions, telemetry, and dependency behaviour are read together, and the contradictions between them are pursued rather than smoothed over, because those contradictions are where the load-bearing surprises hide.

The discipline that Nashua brings is causal, not merely cataloguing. Findings are not delivered as an undifferentiated list of two thousand issues ordered by a generic severity number. They are organised by cause, so that the IT landscape's structural pathologies are named and separated from the symptoms they produce, and technical debt is characterised by the risk it carries and the leverage that addressing it would create, not by its raw count. Nashua is also candid about confidence. Where evidence is strong, the finding is stated plainly. Where the picture rests on inference or on records that could not be fully verified, that uncertainty is made explicit rather than hidden behind false precision, because an honest account of what is not yet known is more useful to a decision maker than a confident account that later proves wrong. The deliverable is a defensible diagnosis: a true state of the IT landscape that a transformation, a consolidation, or a remediation programme can be built upon without inheriting a hidden error.

The difference Nashua makes is the discipline to keep diagnosis and prescription in their proper order, and the independence to hold that line even when it is inconvenient. Many analyses are conducted by parties whose recommendation is decided before the evidence is gathered, so the diagnosis is shaped, consciously or not, to justify the change that was always going to be proposed. Nashua's value is that its account of the IT landscape is built to be true rather than to be convenient, which is precisely what makes it a sound foundation for the decisions that follow. When the baseline is honest, every downstream choice, what to migrate, what to retire, what to leave alone, and what to remediate first, rests on solid ground rather than on an assumption that will fail in production.

There is also a practical corollary that changes what the work is permitted to assume. When an engagement calls for a capability that does not yet exist, it need not wait on a procurement cycle or a vendor's roadmap. The Nashua 360 Enterprise Platform is built to accommodate almost any feature at pace, through extreme vibe coding: what is needed is described in plain language and generated quickly, but always within firm architecture principles and under stringent quality assurance, so that speed never comes at the cost of coherence, security or control. The effect is strategic rather than merely convenient. It moves the make-or-buy line, keeps optionality cheap, and lets the architecture follow the strategy rather than the strategy bending to whatever happened to be on a shelf.

What holds this together is continuity between the diagnosis and everything that comes after it. An assessment that is filed and forgotten decays as quickly as the documentation it replaced. Nashua's practice is to treat the established true state as a living reference that informs architecture, security, and operational decisions over time, and to keep the evidence, the reasoning, and the confidence levels transparent so that others can challenge, extend, and rely on the work. That combination of rigorous diagnosis, causal honesty, and durable follow-through is where the analysis stops being a report and becomes a genuine advantage: the organisation finally knows the IT landscape it actually has, and can change it with confidence rather than hope.