A CMDB nobody trusts
Data goes stale, people keep their own spreadsheets and ask colleagues during incidents.
SolutionVersions and history for every change, data quality checks, discovery, import and sync with a primary CMDB.
Read the article →Solutions
How we solve it
We do not start with forms, we start with data. Every process sits on one CMDB and one rule for who the owner is. That is why incidents, changes and costs understand each other.
One truth about your infrastructure
A CMDB with 34 classes, from business services to OT devices. Every change has a version, an author and a source.
Impact before the outage
Before every change you know which services will be down. During an incident you know who is affected.
Accountability you can trace
Service owners, scoped roles, a RACI checked against permissions and a five-year audit trail.
Rollout step by step
A deployment profile, Excel import and a readiness check. You switch modules on when you need them.
Challenges
Challenges we solve
IT operations rarely fail on technology. They fail because nobody has the full picture: who the owner is, what depends on what, when production may be touched and what it costs.
Impact discovered after the outage
Whoever plans a change often does not know which services it will hit.
SolutionA layered dependency map, outage simulation and impact calculated before a change is submitted.
Read the article →Approvals lost in email
Outages, requests and prices are approved in different channels and nobody knows what is pending where.
SolutionOne approvals queue, one ownership rule, every rejection with a reason.
Read the article →Patching as a monthly negotiation
Every window is negotiated again and critical vulnerabilities wait.
SolutionA patch agreement with the service owner, a pre-approved window, wave plans and an expedited mode.
Read the article →Thousands of alerts, no situation
Monitoring reports symptoms, not causes. People stop reading.
SolutionDeduplication, suppression during changes and grouping into situations using CMDB topology.
Read the article →Costs not linked to services
Cloud and data centre invoices cannot be attributed to services or customers.
SolutionFOCUS cost import, costs by service and customer, a price list with an owner.
Read the article →Use cases
Use cases
Six everyday operational situations and how one shared dependency map helps.
01
Planned outage of a database cluster
The change manager creates a change. Stratum calculates the affected services, offers a slot inside the maintenance window and outside any freeze, and sends the outage to the service owners for approval. Alerts from affected servers are suppressed during the change.
02
A storage failure at night
Monitoring sends hundreds of events. Stratum groups them into one situation with a probable cause in storage, opens a major incident with the affected services and escalates to the vendor according to the service contract.
03
A critical vulnerability on a Friday
The scanner import flags an actively exploited flaw. Stratum shows the affected servers and services, sets a deadline by severity and creates a change in one step from the patch agreement’s expedited mode.
04
Monthly billing data
Costs from clouds, OpenShift and the data centre are loaded in FOCUS format, converted at the Czech National Bank rate and broken down by customer, project and service. Finance gets the data without spreadsheet work.
05
Shared services for many customers
A provider runs one platform for dozens of organisations. A customer’s users see only their own data, including costs; resolvers work across customers and the service owner approves the price list.
06
Alongside a primary CMDB
The enterprise keeps its CMDB in another tool. Stratum syncs with it via external IDs and adds the operational layer: impact maps, changes in windows, patching and costs.
Next step
Choose an edition →Start with a pilot in one area.
Pick a customer or a department and its key services. After the pilot we review SLAs, changes and costs together – and you decide on expansion with peace of mind.