Vertical - Methods

IT, the architecture of success - Part 4

Data - The Intelligence

If the Process layer is the blueprint, then Data is the evidence that proves the structure works. After aligning the People (Part 2) and codifying the Process (Part 3), the Solution Architect must ensure the workflow produces data that is clean, structured, and accessible. That data becomes the “truth” that shows whether new processes are working, where bottlenecks exist, and where teams need support.

You cannot manage what you do not measure, and you cannot measure with inaccurate data. Ignoring the Data layer turns Service Management into a game of gut-feelings and assumption, rather than objective, continuous improvement.

The Architecture of Truth: Why Clean Data Matters

The quality of your service intelligence is directly proportional to the quality of your input data. In a service-led architecture, data must achieve three core objectives to be effective:

  • Be Structured: Data should be collected in a consistent format that enables powerful cross-functional analysis. This means moving away from open text fields and towards standardized choices, mandatory fields, and predefined classifications (e.g., a service request must have a mandatory Service, Category, and Configuration Item associated with it).

  • Be Accessible: Data must be centralised and easily available to all stakeholders—from the technician needing context for a ticket, to the executive analysing organisational efficiency. If data is trapped in separate spreadsheets or departmental tools, it cannot provide enterprise-wide visibility.

  • Be Actionable: The goal of collecting data is not merely reporting, but action. Data should clearly highlight the Non-Value-Added (NVA) steps identified in the process mapping phase, pointing directly to inefficiencies or compliance gaps that require immediate architectural intervention.

Data Integrity: The Foundation of Automated Governance

The transition from a manual process to an automated one demands perfect data integrity. Automation relies on data accuracy to make decisions (e.g., routing, escalation, and provisioning). If the data is faulty, the automation will be faulty, leading to disastrous outcomes like incorrect billing, security vulnerabilities, or misallocation of resources.

Example: Configuration Management Database (CMDB)

The Configuration Management Database (CMDB) is the central repository of asset and service data, and its health is entirely dependent on the Data layer architecture. For instance, if the process for managing servers (Part 3) is weak, the resulting CMDB data will be unreliable. If a technician incorrectly marks a server's Status as In Production when it was actually decommissioned, all subsequent reporting and decision-making is compromised:

  • Budgetary Failure: Licenses, maintenance contracts, and power consumption may be mistakenly allocated to a non-existent asset, resulting in budgetary waste.

  • Security Risk: The server is excluded from patching cycles because the process relies on the CMDB as the source of truth for assets In Production, leaving a potential vulnerability exposed.

The Solution Architect must ensure that data collection points are built directly into the mandated process, making it impossible to advance the workflow without capturing the necessary, clean data. When the data is correct, it tells the "truth" about the operational landscape.

Moving to Platform

Only once the organisation has committed to generating and maintaining clean, structured data is the system ready for the final layer. Data is the intelligence that validates the entire architecture. We now have the aligned People, the codified Process, and the measurable Data. This convergence brings us to the Platform, the tool designed to harness this intelligence and execute the vision.

Executive check: Ask what 5 fields must be accurate for automation to be safe and who owns each. If ownership is unclear, dashboards will mislead and automation will misfire.

Next week (Part 5): Platform - how to configure ServiceNow to enforce good process and data, drive adoption, and scale automation safely.

Mark Lowther

Mark Lowther is a Solution Architect and digital strategist, dedicated to helping large-scale organisations navigate the complexities of technical change. Currently a Principal Solution Architect at Methods, Mark leverages his extensive experience in systems design and digital delivery to solve some of the most pressing technological challenges facing organisations. From high-level architectural blueprints to the nuances of agile implementation, he is an expert at aligning business goals with robust technical frameworks based on over 30 years of delivery of highly robust and complex IT Services in across Central Government, Energy and Financial Services.

Back to top