Custom DCIM Software Development: Why Your Rack Spreadsheet Is Always Slightly Wrong

Why the rack spreadsheet is always slightly wrong

Open the file. It is called RACK_ELEVATIONS_MASTER, it has one tab per room, and there is a merged cell in row 60 that breaks every filter. It says cabinet C-07 has 14 rack units free. Physically it has nine, because a technician racked two switches at 3am during a window and never went back to the sheet, one unit holds a blanking panel nobody recorded, and two are taken by a customer's own gear that arrived in a taxi.

You survive that with one room. It stops being survivable the moment someone asks whether C-07 can take another 4 kW, because the honest answer depends on five records in five places: the cabinet's design load, the rack PDU it plugs into, the branch circuit feeding that PDU, the panelboard above it, and the UPS module above that. Four of those sit on a line drawing that was accurate at commissioning and has been amended by hand since. The fifth is in someone's memory.

The failure is specific and you have probably seen it. A deployment lands on a branch circuit already close to its limit and the breaker opens at 2am. Single corded gear goes dark and you are in a service level conversation before breakfast. Dual corded gear survives, until the failover moves the whole load onto the B side panel that was planned from the same stale sheet, and you learn that your redundancy was an assumption. Nobody was careless. The record was not true and nothing in the workflow required it to be.

Problem 1: power capacity is a chain and your record tracks one link

Most teams track kilowatts at the cabinet. That number cannot answer the question people actually ask. Capacity runs from the outlet on the rack PDU up through the branch circuit, the panelboard, the UPS module, the generator and the utility service, and a proposal has to clear every link before it is safe. A cabinet with headroom on a panel without headroom is not a cabinet with headroom.

Two things make this harder than it looks. Nameplate ratings and real draw diverge badly, and both matter: nameplate is what you reserve against, measured draw is what you plan against, and holding only one means you are either stranding capacity or overloading it. And the National Electrical Code treats a continuous load at 80 percent of breaker rating, so a circuit described internally as 30 amps carries 24 amps continuous. Teams plan against the label rather than the derated figure, then wonder why a room that should have room does not.

A custom build models the electrical topology as a graph and evaluates every proposed deployment against each upstream node, in the normal state and in the failed state where one side carries everything. That evaluation takes a fraction of a second. Operationally it is the difference between a capacity team that commits a number in the meeting and one that raises a ticket to engineering while the customer talks to someone else. This capability alone tends to justify the project.

Problem 2: the connectivity record dies during the maintenance window

The other half of the estate is ports. Structured cabling, patch panel positions, fiber counts and connector types, cross connects into the meet me room, customer to customer connections carrying a monthly charge. All of it is inventory, and in colocation the cross connects are inventory you bill for.

Two errors compound quietly. You keep billing a cross connect a technician pulled six months ago, which becomes an awkward credit when the customer notices. And you never start billing one that was patched in an emergency and not recorded, which is revenue nobody will ever find. Meanwhile meet me room ports get sold twice because the record shows availability that is not there.

The cause is workflow design, not laziness. The change happens at 2am in a cold aisle, by someone in gloves with a torch in their teeth. Any system expecting that person to walk back to a desk, open a laptop and complete a form will not be updated, and after three months of not being updated it is worse than useless because people still half trust it. Capture has to happen on a phone, at the cabinet, by scanning a label, in under thirty seconds. That requirement decides whether the whole system tells the truth, and it is what packaged products most consistently get wrong.

Problem 3: cooling gets modelled at the building, decisions get made at the cabinet

Facility level cooling numbers hide the problem you have. A room averaging 8 kW a cabinet with one 25 kW high density deployment in it is not an 8 kW room, and putting that deployment at the end of a row near a door behaves nothing like putting it inside contained aisles. Average based planning worked when density was flat. It does not now that a single machine learning cabinet carries several times the load of its neighbours.

Placement needs cooling context at the row and the cabinet, plus inlet temperature history from sensors most facilities already have installed and unread. The ASHRAE thermal guidelines give you the envelope you are meant to hold at the inlet. Whether you are holding it in aisle 4 at 3pm on a hot Thursday is a data question, and answering it turns placement from a judgement call into a check.

Problem 4: sold, drawn and billed capacity are three different numbers

A colocation customer contracts a 10 kW cabinet and draws 4.2. You bill the commitment, so revenue looks fine. But if you also reserved the full 10 kW on the panel and the UPS, you stranded 5.8 kW twice, once contractually and once physically. Repeat across 300 cabinets and you have a room sold out at 40 percent utilisation while you quote a new build to a board because you appear to be full.

Applying a diversity factor is how the industry actually operates and it is defensible, but only if you measure. Branch circuit monitoring gives you per circuit reality and sits installed and unread in a great many facilities. Joining measured draw at a high percentile against contracted commitment and against reserved capacity in the topology turns that hardware into decisions: which cabinets to reclaim, which customer to open a right sizing conversation with, and how much of a new request you can accept against real headroom. No packaged product makes that join, because one side of it is your commercial terms.

What Nlyte, Sunbird, Device42, Hyperview, FNT and EcoStruxure IT actually do

These are real products and several are good. Sunbird dcTrack is strong on rack elevations, port level connectivity and change workflow, and for a conventional enterprise facility it is a sensible purchase. Device42 leads with discovery and dependency mapping and is excellent at telling you what is on the network, which is a different problem from facility power capacity. Nlyte and FNT Command are enterprise weight, with deep asset and process models and deployment projects to match. Hyperview is a lighter cloud option suited to smaller estates. Schneider EcoStruxure IT is strongest where the power estate is largely Schneider, and if that describes you it is hard to beat on integration economics.

They stop at the same place, which is your building. Your electrical topology, the metering points you actually installed rather than the ones the design intended, the naming convention that survived two expansions and an acquisition, your containment layout, and how your method of procedure approval really runs. Each product asks you to express your facility inside its model, and the distance between that model and your building gets filled by conventions people forget and fields people quietly stop populating. That gap is where the spreadsheet crawls back in.

What a custom DCIM build has to include

• The electrical topology as a graph from outlet to utility service, evaluated in both the normal and the failed state, not a kilowatt field on a cabinet record.
• Rack elevations with front and rear depth, unit position, blanking and weight, because floor loading in older buildings is a constraint people rediscover the hard way.
• Port level connectivity for copper and fiber, including cross connects linked to billing so a disconnected circuit stops charging and a new one starts.
• Change capture built for a phone in a cold aisle: scan the asset label, confirm, done.
• Ingestion from branch circuit monitoring and building management, normalised across the protocols you actually have, typically a mix of SNMP, Modbus and BACnet.
• A method of procedure workflow where approval is blocked unless the upstream capacity check passes, so the check cannot be skipped under time pressure.
• An append only audit trail, because a record that can be edited silently is a record nobody trusts in an incident review.
• A capacity API your quoting or provisioning tooling can call, so the answer in the sales meeting comes from the same source as the answer on the floor.

What this costs and how long it takes

A first release covering the asset and elevation model, the full power chain with capacity evaluation, and mobile change capture for a single facility runs $70,000 to $150,000 and ships in 14 to 18 weeks. That is a system your critical facilities team uses during a live install, not a pilot. The full platform, adding connectivity and cross connect billing linkage, monitoring ingestion, cooling aware placement, multi site rollout, a customer portal and the capacity API, runs $180,000 to $450,000 phased over 6 to 14 months.

What moves the number in data centers specifically: the count of facilities and how little their naming conventions have in common, since normalising three sites is more work than building the first. The condition of your existing data, because importing a wrong spreadsheet buys you a fast wrong system, and a physical audit of 300 cabinets is genuine weeks of genuine people. Your metering protocol mix, since a Modbus gateway per PDU vendor is separate work from an SNMP walk and both differ from a BACnet interface into the building system. Whether customers get a portal. And whether 2N has to be modelled as well as N plus 1, because evaluating failure states across a mirrored topology roughly doubles that part of the work.

What keeps the number down: one facility, the power chain only, and an explicit decision that connectivity waits for phase two. That covers the risk that actually trips breakers.

When buying is the right call

Buy if you run a single enterprise room under roughly 2 MW with fewer than about 200 cabinets and low churn, because Sunbird or Hyperview fits that shape and a build is a vanity project. Buy if your power estate is overwhelmingly one manufacturer's equipment, since you should not pay to rebuild the native integration that vendor's own platform already gives you. Buy if the real problem is IT asset discovery and dependency mapping rather than facility capacity, because Device42 does that job well and a facility model will not help you.

Build when two or more of these are true. You run multiple facilities whose conventions disagree. You sell or chargeback on committed kilowatts and suspect you are stranding capacity. High density deployments have broken your average based planning. Your capacity team needs an answer inside the meeting rather than in two days. A tripped breaker, failed cutover or redundancy surprise in the last eighteen months traced back to a stale record. Or you have branch circuit monitoring installed and unused, which is extremely common, and nobody has joined that data to what you contracted.

How to choose a developer for a DCIM build

Make them draw the power chain on a whiteboard before you sign. A team that has done this sketches cabinet, rack PDU, outlet, branch circuit, panelboard and UPS, and asks about A and B feeds without prompting. A team that draws assets and locations is building an inventory application and will discover the failed state problem in month four, on your budget.

Ask how a change gets recorded at 2am. If the answer involves opening a desktop application, they have never stood in a cold aisle and their system will be stale within a quarter. Ask which branch circuit monitoring vendors and building systems they have integrated by name and protocol, and what they did when measured values contradicted the design record, because they always do and the resolution rule is a design decision rather than a bug.

Ask whether history can be edited silently, and reject any answer that is not append only. Ask who owns the repository and the cloud accounts, and put it in the contract before kickoff rather than discovering it at handover. At Digital Heroes the client owns the code from the first commit, and we would tell you to walk away from any developer who wants to hold either. Then do one thing this week: pick your three most heavily loaded panelboards, write down what the design load says, and pull what the meter says. The distance between those two numbers is the scope of your project.