Don't ask only whether it integrates. Ask what actually happens across the boundary.

An integration can exist technically without supporting the operational behavior the buyer needs. What information crosses the boundary, which system is authoritative, which direction the information moves, what triggers the exchange, how frequently it occurs and how exceptions are handled can materially change what the integration actually does.

Evidence breadth

Multi-Case + Structural Synthesis

Where this applies

ERP, finance, GIS, procurement, customer/service-request, building-automation, IoT, document, analytics and other systems expected to exchange operational information with the CMMS.

Last evidence review

September 22, 2026

What happened

In Hawaii's CMMS procurement, vendor questions exposed how much operational detail can remain unresolved inside a requirement to “integrate.” Clarifications addressed matters including system ownership, implementation phase, data flows, information objects, directionality, protocols, volumes, documentation and API requirements, access or licensing restrictions, and cybersecurity requirements. The procurement also documented that exchange frequency could vary by dataset, including real-time, hourly, daily, weekly or monthly exchanges.

Why it matters

Two products can both claim to integrate with the same system while supporting materially different operational behavior. What moves, in which direction, when it moves, how it moves and what happens across the boundary can determine whether the connection actually supports the buyer's workflow. Unclear integration boundaries can also make implementation scope and pricing harder to compare.

What a buyer should do

For every consequential integration, trace the required behavior across the system boundary: source → information → authority → direction → trigger → frequency → destination → expected result → failure behavior → reconciliation. Then require evidence that the proposed integration performs that behavior under the conditions that matter.

Specify the behavior the system boundary must support rather than merely naming the systems that must connect. Then require evidence that the proposed integration performs that behavior under the conditions that matter.

What this evidence does and does not establish

This evidence does not establish that complex integrations are preferable, that every interface requires real-time exchange, that an advertised integration will fail operationally, or that Hawaii's eventual implementation succeeded or failed. The appropriate integration behavior depends on the workflow, information, timing, authority and consequences the buyer needs the system boundary to support.

Documented evidence

State of Hawaii, Department of Accounting and General Services — Central Services Division

Questions Received and Responses Provided from Previous Solicitation

P26003149 / RFP CSDR-26-036-SW — Attachment No. 2 · May 29, 2026

Primary integration-definition and pricing evidence

View source →View document →