The weekly operations meeting is discussing a planned storage array replacement. Someone asks: “Which services will this actually affect?” Silence. The storage administrator knows which servers are attached. The virtualisation team has a good idea which virtual machines run on them. But who knows exactly which applications and business services sit on top, and who needs to be told? The answer is pieced together from several people and several spreadsheets, and it is often incomplete.
The same question comes up at a worse moment. Monitoring reports a failed hypervisor, and the service desk cannot tell whether it is a forgotten test system or a service thousands of people rely on every morning. Prioritisation stalls, and the people who could fix the problem spend their time working out what has actually broken.
Why impact is rarely known in time
Organisations do have dependency knowledge. It is just scattered. Each team sees its own layer and understands it well. What is missing is a view that connects the layers.
- Architecture documentation goes stale with every change, and few people keep it current.
- A CMDB without relationships is just a list of items. Without links, it cannot say what depends on what.
- Monitoring sees technical components but not the business services that rely on them.
- Change impact analysis is done by hand and depends on the experience of whoever writes it.
The result is that impact is discovered at the moment of failure, when it is too late to plan or communicate.
A better way to think about impact
The key is to model dependencies once and use them everywhere. If the CMDB knows how layers relate, from the business service through the application, database and server down to the hypervisor, storage and network, the same question can be asked in different situations:
- Before a change: what will be down or degraded during the work?
- During an incident: which service is affected, and who is responsible for it?
- When processing monitoring events: which alerts belong together, and what is the probable cause?
- When planning: what happens if a given component fails, and will the service survive?
One dependency map then serves change management, incident responders and the monitoring team alike.
How Eywo Stratum handles it
Eywo Stratum shows a layered dependency map: business services, applications, databases, servers, hypervisors, storage and network. For every item you can see what runs on it and what it runs on.
On top of the map you can run an outage simulation. Pick a component, and Stratum shows which services and applications would be hit and whether any of them are protected by redundancy. Other parts of the product build on the same foundation:
- Incidents: when an incident is raised from a CMDB item, Stratum suggests the affected service, the impact and the resolver team. Priority is then derived from impact and urgency.
- Changes: before a change is submitted, its impact is calculated, showing which services and applications will be unavailable or degraded. The owner of the affected service then approves an outage they actually understand.
- Monitoring: in event management, alerts are grouped into situations based on CMDB topology, so you see a probable cause instead of dozens of separate notifications.
The question “what breaks if this goes down?” is then answered from data the team understands, not from guesswork in a meeting.
Conclusion
You can know the impact of an outage before it happens. It takes a CMDB that knows relationships, not just items, and a tool that puts that knowledge to work in changes, incidents and event handling. For operations teams, that means less guesswork in critical moments and more confidence when planning.
The dependency map, outage simulation and impact calculation for incidents and changes are part of the Standard edition; topology-based alert grouping comes with the Business edition.
Eywo Stratum Standard
For organisations that want a reliable CMDB and managed ITSM processes.