Smart building integration
Smart Building Integration: How to Avoid Vendor Lock-In Without Buying Everything Twice
For IT architecture, FM, OT, CRE, property asset managers and procurement.
Evidence checked · Guide updated
An integration claim matters only when it works with your actual assets, policies, data and future exit requirements.
Independent educational decision guidance, not an assessment of an individual supplier or a certification, compliance determination or guarantee of outcomes. Check current sources and organisation-specific constraints.
Start with operational outcomes
Describe the workflows that need to operate across systems: fault-to-work-order, location-to-asset, room-booking-to-service, building events to analysis or energy reporting. A list of supported protocols is not an implementation requirement.
Map the existing estate
Document the actual systems, interfaces, versions, ownership, integrations, control boundaries and data sets. Include retained legacy systems and site-level differences. Do not design the architecture using only the vendor’s reference environment.
Separate protocols from interoperability
BACnet, IFC, APIs and other standards may provide a common vocabulary or exchange mechanism. They do not by themselves guarantee complete semantics, usable mappings, consistent permissions, real-time performance or working end-to-end workflows. Validate the configured implementation.
Examine data rights and portability
Clarify who can access asset inventories, histories, documents, metadata, identifiers and change logs. Verify export formats, completeness, access controls, API limits, fees and contractual rights. An API demonstration does not establish usable exit rights.
Protect building control systems
Do not conflate enterprise software integration with authority to control physical systems. Review OT network zones, account permissions, safe fallbacks, latency, operational continuity and cyber risk separately from analytical data flows.
Test semantic alignment
Matching a device ID is not enough if spaces, equipment classes, asset hierarchies, locations or units mean different things in different systems. Use representative data from existing sites and test exceptions, not only perfect examples.
Price the whole integration
Account for software subscriptions, connectors, middleware, implementation, data cleansing, customisation, security assurance, ongoing maintenance and eventual exit. “Native integration” may still require significant configuration.
Plan migration and parallel running
Identify record ownership, deduplication, histories, interfaces and audit requirements. Use staged acceptance, rollback points and business continuity criteria. Test the ability to recover from a failed migration without guessing what data was lost.
Define change ownership
Interfaces deteriorate when a vendor changes an API, equipment is replaced or a site is acquired. Contracts and operational plans should assign responsibility for monitoring integrations, updating mappings and resolving incidents.
Keep the option to do less
Where the current system can be reconfigured or linked through an existing governed interface, replacement may not be justified. Conversely, a higher initial integration cost may be warranted if it preserves data quality and future options. Record the rationale for each route.
Questions buyers ask
Practical questions, bounded answers.
What exact cross-system workflow must work?
Which systems and versions exist in each building?
What data model and identifiers are used on both sides?
Which interfaces are genuinely available in our subscribed edition?
What standards or protocol claims have been tested in our configuration?
What happens when one connected system is offline?
Can users export complete data and histories in useful formats?
What restrictions, charges or rate limits apply to API access?
Who owns ongoing integration monitoring and remediation?
How are IT-to-OT permissions separated and approved?
What would migration, parallel running and rollback cost?
How can we change suppliers without losing operational continuity?
Evidence and standards context
Sources, status and scope.
Source status describes the cited material, not a vendor or product certification. Confirm the applicable version, jurisdiction and implementation context for each decision.
buildingSMART · Published; verify latest version · See publisher
Interoperability standard context, not a verified interface.
OpenAPI Initiative · Published; verify latest version · See publisher
Specification, not proof of functioning API.
NIST · Published; verify latest version · See publisher
Guidance on OT interfaces and security.
Need to apply this to a real decision?
Move from general guidance to a governed decision context.
PROVE TDI structures the requirements, evidence, alternatives, uncertainty and accountable conclusion for a specific enterprise technology decision.