Show Notes
When a Building Is Loud Instead of Smart
Modern commercial buildings can contain impressive technology: HVAC controls, access systems, cameras, elevators, lighting, fire alarms, and tenant-facing amenities. But installing intelligent systems is not the same as operating an intelligent building. This episode examines the integration gap that appears when those systems sit side by side but cannot share useful information.
The opening scenario is familiar to many facility teams: at 2 a.m., a manager is watching a rising temperature alert on one screen, a door sensor alert on another, and a camera feed on a third. The real problem is not simply dashboard fatigue. It is incomplete context. A door left open may explain why a specific area is heating up, but when access control, video, and HVAC are isolated, the person responding has to make that connection manually.
That is the “hidden handshake” between building systems: the ability to exchange the right information at the right time so operations can respond intelligently.
Why Building Integration Is Still Difficult
Building automation has existed for decades, yet many properties remain collections of separate systems. One major reason is legacy equipment. A chiller installed in the 1990s may still perform well, but it may use a proprietary protocol designed for its manufacturer’s ecosystem. A newer access control platform may communicate in an entirely different way.
Making those systems communicate often requires gateways, custom integrations, specialized configuration, and documentation that may be outdated or missing. What seems simple at a high level can become expensive and operationally difficult once a property team tries to connect real equipment from multiple eras and vendors.
- Older equipment may use protocols that were never intended to connect broadly.
- Integration often requires a translator, gateway, or custom project that was not included in the original budget.
- System documentation may be incomplete, outdated, or unavailable.
- Different contractors and integrators may be unwilling to take responsibility for systems outside their specialty.
The result is a building made up of separate kingdoms. HVAC, security, elevators, fire systems, and other platforms may all be essential, but no one has clear ownership of the connections between them.
The Cost Is Operational and Business-Focused
The cost of disconnected systems is not limited to inconvenience. Facility teams make decisions with partial information, potentially extending outages, missing root causes, or responding too slowly to issues that affect occupants. A temperature alert can appear to be an HVAC problem until access data and camera footage reveal an open loading dock door on the same floor.
Integration failures can also create direct tenant consequences. The episode discusses an access-control and fire-alarm connection intended to unlock doors during an alarm. After a software update, the connection was not tested. During a false alarm, a door remained locked. The lesson is not that integration should be avoided. It is that critical integrations must be designed, maintained, and tested as operational systems rather than treated as a one-time installation.
Tenant expectations further raise the stakes. Occupants notice when elevators, access control, lighting, and HVAC do not work together. Waiting in a lobby because elevator access is disconnected from entry credentials, or working in offices that are too hot or too cold because HVAC lacks occupancy information, becomes a business problem for the property.
Do Not Integrate Everything
A central theme of the conversation is that more integration does not automatically create a smarter building. Connecting systems without a clear operational reason can introduce unnecessary dependencies and new points of failure. The goal is not to make every device communicate with every other device. The goal is to solve a real problem.
Before connecting systems, teams should begin with the operational outcome they need. That could be improving energy efficiency, strengthening security response, reducing manual work for facility staff, or delivering a better tenant experience. The intended outcome should determine which systems need to exchange data and how much risk the property can accept.
- Start with a specific operational problem, not a technology wish list.
- Identify which systems need shared context to solve that problem.
- Determine whether each connected system can continue operating safely if the integration fails.
- Avoid creating dependencies that provide little operational value.
A practical design question is: what happens if the integration goes down? If lighting and HVAC are connected but each can fall back to standalone operation, the failure may be manageable. If a failed connection could create a severe safety or operational issue, redundancy and testing need to be part of the design.
Open Protocols Versus Proprietary Ecosystems
The episode also addresses the tradeoff between open protocols and proprietary systems. Open approaches can offer flexibility and make it easier to work with multiple vendors over time. However, open does not necessarily mean simple. The building owner may assume more responsibility for coordination, configuration, and long-term support.
Proprietary ecosystems can be more polished and easier to deploy within a single vendor’s environment. The downside is vendor lock-in. If a manufacturer is acquired, discontinues a product line, or cannot provide future support and parts, the property may face an unplanned replacement project. One example discussed involved a proprietary building automation system that continued running after the product line was discontinued, but could no longer receive parts or support. The facility team ultimately had to replace it.
There is no universal answer. The appropriate choice depends on the property’s operational goals, risk tolerance, internal capabilities, and long-term flexibility requirements.
A Framework for Owners and Facility Teams
For older buildings, the first step is not necessarily a large retrofit. It is a thorough audit. Many properties contain undocumented systems, partial integrations, and equipment installed at different times by different parties. Understanding what exists is the foundation for making a practical plan.
- What systems are installed in the building?
- What protocols do those systems use?
- Which integrations already exist and are actually working?
- What operational problem would a new integration solve?
- What is the cost of continuing without that capability?
- Who will own, maintain, and test the integration after installation?
- What happens if the integration fails?
Integration is not a purchase that ends at commissioning. It is an ongoing capability. The best integrations are often invisible because the building simply responds as expected. Reaching that outcome requires documented architecture, clear accountability, maintenance, testing after changes, and a technology partner that can support the environment over time.
Key Takeaway
A modern building is not defined by how many intelligent systems it contains. It is defined by whether the right systems can share the right information safely, reliably, and for a clear operational purpose. Start with an audit, define the business problem, evaluate long-term ownership, and ask the most important resilience question: what breaks if this goes down?
The Hidden Handshake Behind a Modern Building
A building can have intelligent HVAC controls, access control, cameras, elevators, lighting, fire alarms, and occupancy systems and still fail to operate intelligently. The issue is often not a lack of technology. It is the absence of integration between the systems already in place.
Consider a facility manager responding to alerts in the middle of the night. One dashboard shows that temperatures are rising in an east wing. A separate access-control dashboard shows a door sensor alert. A third screen shows a loading dock left open. Each alert matters, but the systems do not exchange context. The manager must recognize that an open door may be driving the temperature issue and then manually coordinate a response.
That situation illustrates the hidden handshake in commercial real estate technology: the connection between building systems that allows information to become operationally useful. Without it, a building may be full of data but still force its people to work with incomplete information.
Disconnected Systems Create More Than Dashboard Fatigue
Switching between multiple applications is frustrating, but the larger problem is decision-making. A facility team that sees only a temperature alert may dispatch HVAC resources without knowing that the root cause is a propped-open door. A security team may see the door event without recognizing its effect on a tenant space. Video may provide confirmation, but only after someone knows where to look.
These gaps slow response and make operations more dependent on the experience of individual team members. When the right context is not available in one place, people become the integration layer. They compare timestamps, interpret alerts, make calls, and try to reconstruct what happened across separate systems.
That manual process becomes especially costly when events affect occupants. Tenants do not experience a disconnected architecture diagram. They experience a lobby delay, a locked door, an uncomfortable office, or a building that feels unreliable. For owners and property managers, those experiences can affect satisfaction, retention, and the property’s overall perception.
Why Integration Remains a Challenge
Many commercial properties are technology timelines. A chiller may have been installed decades ago and remain mechanically reliable. Access control may have been upgraded more recently. Cameras, lighting controls, elevator systems, and tenant technology may have been added through separate projects. Each platform may work well independently while using different protocols, software, documentation, and support models.
Legacy equipment is a significant obstacle. Older systems may rely on proprietary communications methods that were never intended to connect with a broader building ecosystem. Connecting them to a newer platform can require a gateway or custom translation layer. That work may be expensive, and it is frequently outside the original scope and budget of a replacement project.
Documentation creates another challenge. Properties often have records that are incomplete, out of date, or scattered among contractors, vendors, and previous management teams. A building may already have integrations that no one can fully describe, maintain, or validate. That uncertainty becomes a major risk when a software update, hardware replacement, or emergency event tests an undocumented dependency.
Responsibility can also become fragmented. The HVAC contractor may not want to own security-system behavior. The security integrator may not want responsibility for elevators. Each party may protect its own scope, while the building owner is left responsible for the gaps between systems. Those gaps are where integration failures frequently live.
Integration Must Be Designed for Failure, Not Only for Success
Connecting systems can deliver important benefits, but any connection also creates a dependency. A fire alarm and access-control integration may be designed to unlock doors during an alarm. That is useful only if it continues to work after configuration changes and software updates. If the integration is never re-tested, a failure may not become visible until the building needs it most.
This is why a building integration strategy needs to include failure behavior. Before systems are connected, owners and facility teams should ask what each system does if the integration becomes unavailable. Can it continue in a safe standalone mode? Does it fail in a way that creates a serious security, safety, or operational problem? Does the design need redundancy?
Not every integration carries the same risk. A failed connection between lighting and a scheduling platform may be inconvenient if lights retain local control. A failed connection involving access, life safety, or other critical operations may require a more deliberate resilience strategy. The correct level of design, testing, and support should match the consequence of failure.
More Connections Do Not Always Mean a Smarter Building
It is easy to assume that every intelligent device should be connected. In practice, over-integration can create needless complexity and new points of failure. A connection that does not solve a meaningful operational problem may become another system that someone must support, troubleshoot, and maintain.
The better starting point is the business or operational question. Is the property trying to reduce energy waste? Improve security awareness? Speed up incident response? Make access and elevator movement smoother for tenants? Improve comfort using occupancy information? The answer should determine which systems need to communicate.
A focused approach avoids the trap of connecting technology simply because it can be connected. It also produces a clearer support model, because the purpose of each integration is documented and tied to an expected outcome.
Open and Proprietary Systems Require Deliberate Tradeoffs
Owners also need to decide how much flexibility they need over the life of the property. Open protocols can make it easier to work across multiple vendors and avoid dependence on a single ecosystem. They can support flexibility, but they may also require more coordination and technical management from the owner or a long-term technology partner.
Proprietary ecosystems can be polished and easier to operate within a single manufacturer’s design. The tradeoff is lock-in. If a vendor is acquired, discontinues a product line, or no longer provides parts and support, a building can inherit an expensive replacement problem. A system may still function, but the owner may no longer be able to repair, expand, or reliably support it.
Neither option is automatically right or wrong. The decision should reflect the property’s goals, risk tolerance, budget, technical resources, and expected holding period. What matters is making the tradeoff intentionally rather than discovering it after a critical system becomes unsupported.
Start With an Audit
For an older property, a major retrofit is not always the first move. The first move is understanding the environment. A thorough audit can identify the systems installed, the protocols they use, the integrations that already exist, and the dependencies that have never been documented.
That audit should establish a practical baseline:
- List every significant building system and identify its vendor, age, support status, and protocol.
- Document existing connections, including their purpose and the party responsible for maintaining them.
- Identify operational gaps where separate systems prevent teams from responding effectively.
- Determine which integrations have tenant, security, safety, or revenue impact.
- Review failure modes and confirm how each connected system behaves during an outage.
- Assign long-term ownership for maintenance, testing, and change management.
Even when no immediate retrofit is planned, this work provides value. When something breaks, the facility team has a clearer picture of what it is working with. When a future improvement is proposed, the owner can evaluate it against actual architecture and operational needs rather than assumptions.
Integration Is an Ongoing Capability
The strongest building integrations are often invisible. When access, elevators, HVAC, lighting, and other systems respond as expected, occupants rarely think about the technology behind them. But that invisibility is the result of ongoing work: documentation, monitoring, ownership, maintenance, testing, and disciplined changes.
Integration should therefore be treated as a long-term capability, not a one-time project deliverable. The right technology partner can help a property team audit its current environment, define the operational outcomes that matter, assess vendor and protocol tradeoffs, and build a support plan for the systems that need to work together.
Before adding the next connection, ask four direct questions: What problem are we solving? What does doing nothing cost us? Who will own this long-term? What happens if it fails? Those questions can prevent a costly integration project from becoming another disconnected system.
To hear the full conversation on building interoperability, legacy equipment, vendor lock-in, and strategic integration planning, listen to this episode of Built, Wired & Secured.