Show Notes
The Hidden Handshake Between Building Systems
A building can have intelligent HVAC controls, access control, cameras, elevator systems, lighting, and fire alarms while still creating more work for the people responsible for operating it. This episode opens with a familiar late-night facilities scenario: a temperature problem, a door alarm, and an open loading dock appear on three separate screens. Each system is reporting something important, but none of them is sharing context with the others.
That is the central issue explored in this conversation: a building is not truly responsive simply because it has many connected devices. Without purposeful integration, it can become noisy rather than smart. Facility teams are left moving among separate dashboards, interpreting disconnected alerts, and making operational decisions with incomplete information.
Why Disconnected Systems Create Business Problems
The cost of disconnected building technology goes beyond the inconvenience of switching screens. When systems do not exchange the right information, operations teams can miss the relationship between events. A rising temperature in one area may be connected to a door that has been left open on the same floor, but that connection is easy to miss when HVAC and access control data live in separate systems.
- Teams may respond to symptoms rather than underlying causes.
- Operators can spend time moving between dashboards instead of resolving the issue.
- Building decisions are made with incomplete operational context.
- Tenant comfort, security, and confidence can suffer when systems do not respond as expected.
The episode frames these outcomes as business problems, not merely technical inconveniences. If access control does not inform elevator behavior, people may be left waiting in a lobby. If HVAC does not reflect occupancy, offices can be too hot or too cold. Tenants experience the result directly, whether or not they understand the technology behind it.
Legacy Equipment and Vendor Silos
Integration is difficult partly because commercial buildings accumulate technology over long periods. A chiller from the 1990s may still be running reliably, but it may use a proprietary protocol designed to stay inside the manufacturer’s ecosystem. A newer access control platform may use an entirely different approach. Connecting the two can require a translator, an expensive gateway, or a custom integration project that was never included in the budget.
Documentation is another recurring obstacle. Building teams may inherit outdated records, missing records, or a patchwork of existing integrations that nobody fully understands. Even when a technical path exists, responsibility can remain fragmented. The HVAC contractor may avoid responsibility for security technology, while the security integrator may not want to own an elevator-related outcome. Separate parties protect their own areas, while the property owner inherits the gaps between them.
Integration Must Be Tested and Maintained
One example in the discussion highlights why an integration cannot be treated as a one-time install. A fire alarm system had been integrated with access control so doors would unlock during an alarm. The concept was sound, but the behavior was not tested after a software update. During a false alarm, a door stayed locked, creating an immediate tenant impact.
The lesson is not that integration should be avoided. It is that connected systems require clear ownership, maintenance, testing, and an understanding of failure modes. A capability that works at commissioning can become a risk if changes are made without verifying how the connected systems still behave.
Avoid Over-Integrating
More connections do not automatically create a smarter building. The conversation warns against connecting systems simply because it is technically possible. An example of linking a coffee machine to a lighting schedule illustrates how unnecessary integrations can introduce extra points of failure without solving a meaningful operational problem.
The better starting point is an operational question: what problem is the building trying to solve? The answer may involve energy efficiency, security, tenant experience, or another specific outcome. That objective should determine which systems need to communicate and which systems are better left independent.
- Define the operational outcome before selecting an integration.
- Identify what information or action must move between systems.
- Determine whether the benefit justifies the added maintenance burden.
- Document how each system behaves if the integration is unavailable.
Open Protocols Versus Proprietary Ecosystems
The episode also examines the tradeoff between open and proprietary approaches. Open protocols can provide flexibility and reduce dependence on a single vendor, but they may require the owner or its partners to manage more complexity. Proprietary ecosystems can be more polished and simpler to deploy within one vendor’s environment, but they can create lock-in.
A proprietary building automation system can become a major capital problem if the manufacturer is acquired, discontinues the product line, or can no longer provide parts and support. In that situation, a system may continue running but become difficult or impossible to maintain, leaving the property team facing an unplanned replacement project.
A Practical Retrofit Starting Point
For older buildings, the discussion recommends beginning with a thorough audit rather than rushing into a retrofit. Property owners need an accurate view of the systems already installed, the protocols those systems use, and the integrations that are already operating. Many buildings contain undocumented patches and connections that become visible only when someone investigates carefully.
An audit is valuable even when a major project is not planned. It gives the owner a baseline for future troubleshooting, changes, budgeting, and risk management. Knowing what is in the building is a necessary first step toward deciding what should work together.
Questions to Ask Before Connecting Systems
- What problem are we actually trying to solve?
- Are we trying to improve energy efficiency, security, or tenant experience?
- What is the cost of doing nothing?
- Who will own and maintain the integration over the long term?
- What happens if the integration fails?
- Do connected systems fall back to standalone operation?
- Would a failure be minor, or would it create a catastrophic outcome?
Where the consequence of failure is serious, redundancy matters. Where the consequence is minor, an integration may not be necessary at all. The goal is not to connect everything to everything else. The goal is to make deliberate choices that improve building operations without creating avoidable fragility.
Start With the Building You Have
The conversation closes with a simple action: walk the building, list the systems, and ask, “What breaks if this goes down?” That question helps reveal dependencies, hidden risk, and opportunities where a purposeful integration could create a better operational and tenant outcome. When integration works well, it is nearly invisible. The building simply responds.
If your systems are only coexisting rather than working together, start the conversation with a technology partner who can help evaluate the operational need, long-term ownership, and risk before a project begins.
A Modern Building Is Not Smart If Its Systems Cannot Work Together
Commercial buildings are filled with technology that promises efficiency, safety, comfort, and a better tenant experience. HVAC controls regulate temperatures. Access control manages doors and credentials. Cameras provide visibility. Lighting systems follow schedules. Elevators move people through the building. Fire alarms support life safety.
But a building can have all of those systems and still operate as a collection of disconnected islands.
Consider a facilities manager working at 2 a.m. One dashboard shows temperatures climbing in the east wing. Another shows a door sensor flashing red. A third shows a loading dock left open. Each screen reports a legitimate problem, yet the systems provide no shared context. The facility manager has to connect the dots manually.
That is the hidden handshake: the purposeful integration between systems that lets a building respond to conditions instead of merely reporting them. Without it, a building may not be smart. It may simply be loud.
The Cost of Separate Dashboards
Disconnected systems create more than an annoying user experience for facilities teams. They create an operational blind spot. When HVAC, access control, cameras, and other systems do not share the information needed for a specific outcome, teams make decisions with incomplete information.
For example, a temperature issue may appear to be an HVAC problem. But an access control event showing a door propped open on the same floor could provide the missing explanation. If those systems are isolated, the team may spend time investigating equipment while the real cause remains visible only on a different screen.
That lost context affects response time, staff efficiency, and the quality of decisions. More importantly, it affects the people in the building. A hot office, a cold workspace, an unexpected delay in the lobby, or a door that does not behave as expected is not experienced as a technology issue. It is experienced as a building that does not work well.
For owners and property managers, this is why integration belongs in business conversations. It influences tenant experience, operational consistency, and the ability to manage a property confidently.
Why Building Systems Still Do Not Talk
It may seem surprising that integration remains difficult after decades of building automation. The reality is that most properties have technology from different eras, manufacturers, contractors, and project scopes.
A chiller installed in the 1990s may still be dependable, but it may use a proprietary protocol that was never intended to communicate outside the manufacturer’s ecosystem. A newer access control platform may use a different language entirely. Making those systems exchange useful information may require a gateway, a translator, custom programming, or a project budget that did not exist when the systems were purchased.
Documentation often makes the problem worse. Records may be out of date, incomplete, or missing. A building may contain existing connections that work but were never properly documented. When a problem occurs or an upgrade is planned, the facility team may not have a reliable map of what is installed, what is connected, or who owns responsibility for each part.
Vendor silos add another layer. The HVAC contractor may not want responsibility for the security platform. The security integrator may not want to be accountable for elevator behavior. Each party may reasonably limit its scope, but the property owner is still left with the outcome when the systems fail to work together.
Integration Is a Capability, Not a One-Time Project
There is a tendency to view integration as a project with a start date, an installation phase, and a completion date. That view creates risk.
Connected systems must be maintained and tested as changes occur. A software update in one system can alter behavior in another. In the episode, a fire alarm and access control integration was intended to unlock doors during an alarm. The design made sense, but the integration was not tested after a software update. During a false alarm, a door remained locked. The result was immediately visible to tenants.
The lesson is not that systems should remain separate. The lesson is that the owner needs a long-term operational model for every integration. Someone must understand what the connection is designed to do, who maintains it, how it is tested, and what the building does when it is unavailable.
This matters because the best integrations are usually invisible. When systems respond correctly, nobody needs to think about them. When they fail, they become the center of attention.
Do Not Connect Systems Just Because You Can
Integration has real value, but more integration is not always better. Connecting a coffee machine to a lighting schedule may be technically possible, but it can create extra failure points without producing a meaningful operational benefit.
The right question is not, “What can we connect?” It is, “What problem are we solving?”
That operational question should lead every integration decision. A property may need connected systems to improve energy efficiency by aligning HVAC with occupancy. It may need an access control and elevator relationship to reduce lobby friction. It may need security-related information to give operators clearer situational awareness. Each of those use cases starts with a defined business or operational outcome.
When the desired outcome is unclear, the integration is more likely to become expensive complexity. When the outcome is clear, the owner can evaluate whether the connection is necessary, how it should operate, and how success will be measured.
Open Protocols and Proprietary Platforms: A Real Tradeoff
There is no universal answer to the open-versus-proprietary question. Open protocols can support flexibility and make it easier to connect products from different vendors. However, open does not automatically mean simple. It can require more expertise and more active management from the owner and its technology partners.
Proprietary ecosystems can be polished and easier to use within a single vendor’s environment. The tradeoff is lock-in. If the vendor changes direction, is acquired, discontinues a product line, or cannot provide support and parts, the building can be left with a system that still runs but cannot be sustained.
That situation can force an unplanned capital project. A building automation system might need to be removed and replaced not because it stopped functioning overnight, but because the owner can no longer obtain support or equipment needed to keep it viable.
Owners should view this decision through the lens of long-term flexibility, not only initial installation cost. The appropriate choice depends on the property’s needs, internal capabilities, risk tolerance, and the partner responsible for maintaining the environment.
Start a Retrofit With an Audit
For an older building, the most practical first step is a thorough audit. Before selecting a platform or approving custom integration work, identify what the property actually has.
- What systems are installed?
- What protocols do those systems use?
- Which integrations already exist?
- Which connections are documented and which are not?
- Who supports each system today?
- What operational dependencies already exist?
This work is useful even if a major retrofit is not planned. A current inventory helps a property team troubleshoot faster, prepare for future upgrades, and understand where hidden risk may exist. It also creates a more realistic basis for budgeting. You cannot develop a durable integration strategy if the starting environment is unknown.
Four Questions Before You Integrate
A practical framework from the episode can help owners and facility teams decide where to begin.
First, ask what problem you are actually trying to solve. Is the goal better energy efficiency, stronger security, a better tenant experience, or improved operational visibility?
Second, ask what doing nothing costs. In some cases, the inefficiency caused by disconnected systems costs more over time than the integration itself. In other cases, the inconvenience may not justify the added complexity.
Third, determine who owns the integration long term. A capable installer is not enough. The property needs a committed partner who will maintain the connection, understand the dependencies, and support it as systems change.
Fourth, ask what happens if the integration fails. If the answer is catastrophic, design for redundancy and clear fallback behavior. If the answer is minor, the building may not need that integration at all.
Build for Deliberate Operations
The goal of building technology is not to create the largest possible web of connected devices. It is to create a dependable environment where the right systems share the right information for a clear operational purpose.
Start by walking the building and listing the systems that matter. Identify the points where teams are manually switching among dashboards or making decisions without the full picture. Then ask a straightforward question: what breaks if this goes down?
That question reveals both opportunities and risk. It can help a property owner identify which connections are worth making, which systems need stronger documentation, and where a long-term technology partner can help turn isolated tools into a more responsive building environment.
To hear the full conversation on building-system interoperability, listen to this episode of Built, Wired & Secured.