Ask most finance leaders a simple question: what does this building actually own, what condition is it in, and what is it going to cost us next year? The honest answer is usually assembled after the fact, from several places that don't talk to each other. The design records live in one system. The capital project that installed the equipment lives in another. The maintenance history lives in a third. The insurance schedule, the depreciation ledger, the map of where everything physically sits — each one is its own island, built at a different time, by a different vendor, for a different department that had its own job to do.
None of those systems is wrong to exist. Each one does the job it was bought for. The problem is that a single physical asset — an air handler, a roof, an electrical panel — shows up differently in every one of them, if it shows up at all, and nothing connects those appearances back to one real object in the world.
The old answer
For decades, the standard fix has been to try to make everything live in one place: a single company-wide platform, usually a name like SAP or Oracle, meant to become the one source of truth for the whole organization. Anyone who has lived through one of those rollouts knows what it actually costs. Years of implementation. Years of internal disruption, training, and change management, spread across every department the new platform touches. And at the end of it, an air handler on the third floor still doesn't know it is also a line on a depreciation schedule, a name on a warranty, and a dot on a facilities map. The systems changed. The underlying problem didn't.
That is because the goal was never really one system. The goal is one identity.
One identity, many systems
Think about how a single person moves through the world. A bank, a hospital, and an airline each keep their own separate records, run their own separate software, and answer to their own separate regulators. None of them merge into one company, and none of them ever will. What lets all three recognize the same person is a shared, reliable way to confirm this is the same individual, checked at the door, every time. The institutions stay independent. The person carries one identity across all of them.
A building's assets can work the same way. The design software, the maintenance system, the accounting system, the insurance platform, the facilities map — they were built by different companies, for different jobs, and there is no real reason to think they will ever combine into one platform. In most organizations they shouldn't, and in mine, at least, I don't expect to see them merge in my lifetime. What can change is simpler, and more powerful. Give the physical asset itself one identity, a reference that follows it from the day it's designed to the day it's finally retired, and let every one of those separate systems recognize that same identity when they talk about it. The systems stay exactly as separate as they are today. The asset stops being five different half-known things and becomes one fully known thing.
Why now
This isn't a new idea in theory. It has been hard in practice, because reconciling records across systems that were never designed to compare notes used to take a large, dedicated technical effort and a long calendar. That has changed, and it has changed recently. The tools now available for reading, matching, and validating information across systems that speak entirely different languages have gotten dramatically more capable in a very short window. Work that used to require a standing team and a multi-year roadmap can genuinely happen in weeks now, because the connecting layer no longer has to be hand-built line by line. It can be assembled and pointed at the systems that already exist.
Trust, not just linking
Speed isn't the whole story. It wouldn't be worth much to connect these systems quickly if the result couldn't be trusted. Before any of this gets used to make a real decision — flagging an asset for replacement, capitalizing a project, writing up a liability — whoever is making that call needs more than a link between two databases. They need to know the information behind it can be traced back to where it came from, that it's still current, and that whoever is about to act on it actually has standing to do so. That's a genuinely higher bar than simply connecting two systems, and it's the one that turns a tidy dashboard into something an executive can stand behind in an audit, a capital committee, or a courtroom.
That bar is not hypothetical. It is the thing a live test against one real building was built to enforce: a physical event could not become a financial decision without the evidence to support it, and when the evidence was missing the process stopped and said so rather than guessing. The full case study collects that week from three different seats.
What doesn't change
None of this asks an organization to rip out what already works. Finance keeps its ledger. Facilities keeps its maintenance system. IT keeps whatever it has already built. What changes is that the physical assets underneath all of it finally get one identity, threading through every system that touches them, from the day they're designed to the day they're retired. That's the whole idea. It's also the reason I'm genuinely excited to be building it right now, at a moment when the technology has finally caught up to something this practical.
If the systems you already own are the ones that have to carry that identity, that is the conversation fixed asset software and implementation consulting starts with — what the environment should become, before anything gets connected to anything. See how that works →
