Finding the signal in the infrastructure

Mapping complexity with a complex product

Tideway Foundation gave large organisations an automated way to map the technology spread across their data centres. From a dedicated appliance, it scanned authorised systems and collected evidence about their hardware, software and running processes, and could reveal how the estate changed over time.

This mattered because years of growth and acquisition had left many enterprises dependent on duplicated, poorly understood or orphaned technology. Foundation could identify the technical components, while application modelling added the business context: which servers, software and processes worked together to support a named application.

But the product used to make this complexity intelligible was itself difficult to install, navigate and interpret. Retrieving data and troubleshooting models could be laborious, while the volume of information could overwhelm the people using it. I joined Tideway as its principal usability specialist to research those difficulties and design a web-based interface to replace the existing command-based one.

Technical evidence needed organisational knowledge

Foundation could inspect systems, but it could not infer all the business knowledge held by people across an organisation. Producing an application model meant finding its owners, establishing which hosts and software they believed supported it, gaining permission and credentials to scan those hosts, then reconciling that account with what Foundation found.

At one customer, a small team was expected to create lightweight models of roughly 800 applications at a rate of 50 each week. Credentials could take days or weeks to obtain, while a single host might contain hundreds of unmatched processes that had to be interpreted and tested. The team relied on spreadsheets, scripts, shared storage and manual reporting to coordinate work around the software.

Application modelling was therefore not simply a feature within Foundation. Its success depended on cooperation, information and decisions distributed across the customer organisation.

From the interface to the signal in the noise

The original brief framed the problem as making a technically powerful product easier to navigate. The application-modelling work showed why that was too narrow. A cleaner interface could reduce friction, but it could not repair missing ownership, unreliable source information or context lost between teams. Nor could showing every observed change tell a customer which change deserved attention.

This changed the starting question:

From

How do we make all this information easier to display?

To

How do we help each participant see what matters, understand how far it can be trusted and move the work forward?

The interface project had become an investigation into how technical evidence travelled through an organisation and became a decision.

Seeing the service around the software

This was service design: understanding how the software's value depended on the people, information, processes and decisions surrounding it. I interviewed customers, prospective buyers and Tideway specialists across the product lifecycle, tracing how a discovered fact became, or failed to become, a decision.

I represented those perspectives through more than 15 role-based personas and end-to-end scenarios. The main synthesis was an Application Modelling blueprint that connected interview evidence to pain points and user needs, then to proposed features, wireframes, technical architecture and business strategy.

This gave senior stakeholders a shared model they could inspect. They could follow a proposed interface decision back to its evidence, question the interpretation and understand how changing one part affected the wider service.

Making the signal visible

The key product insight was that collecting more infrastructure data could create more noise unless Foundation helped people judge its significance. Customers needed to define the policies their infrastructure should follow and the conditions they considered normal. Foundation could then compare its live model with those expectations and draw attention to meaningful deviations rather than present every change as equally important.

This principle shaped the requirements, wireframes and prototypes I produced. The answer to a complex product was not another layer of interface complexity, but a clearer way for people to see what mattered and decide what needed investigation.

A principle that still endures

I returned to contracting after completing the work, so I do not know which proposals were adopted or shipped. Foundation later evolved into BMC Helix Discovery, whose customers can use rules-based blueprints to define the composition of a service or application. The product maintains those models from observed infrastructure data and calls for human review when new evidence would change a model substantially.

This does not establish a direct line from my designs to the current product. It does show the continuing value of combining customer-defined meaning with live technical evidence and drawing attention to consequential change rather than every change.