What's one piece of advice you would give to cities or organizations looking to integrate different smart infrastructure systems seamlessly? What's the biggest integration challenge you've encountered?

Q1: My main recommendation for companies is to create a vendor-agnostic architecture instead of relying on individual hardware solutions. Many companies have implemented "smart" solutions that are not integrated into the company's overall data architecture, leading to a fragmented data ecosystem that makes it almost impossible to manage. Companies must have the ability to enforce open standards and API first in all contracts, so that all IPS and utility grids can communicate with each other and the end user. Q2: The greatest challenge we see on a repeated basis is the "proprietary lock-in" of legacy infrastructure. There have been numerous instances where we have seen critical public safety information being held hostage by a vendor in their walled-off environment, which resulted in the city's command center being unable to access that information without having to invest in extensive, custom-built middleware. This not only represents an unfortunate technical oversight; it represents a missed opportunity for capitalizing on the significant financial investments that we will continue to make on our smart environments. At the core of successful integration of data flows is not the number of devices and types of devices, but rather the governance over data flow for the infrastructure. We want to ensure that the infrastructure that we build for our users today does not have to be dismantled tomorrow.

I'll answer this from healthcare data infrastructure, which faces the same integration nightmares as smart cities--you're connecting systems that were never designed to talk to each other, often with competing commercial interests. **My one piece of advice: Don't try to centralize everything.** The biggest integration failures I've seen happen when organizations try to move all their data into one master system. We've powered federated analyses across 12+ children's hospitals where each kept their data in completely different formats--OMOP at some sites, FHIR at others, custom schemas elsewhere. Instead of forcing harmonization upfront, we brought standardized queries to where the data already lived. That pediatric research network completed rare disease research in weeks instead of the years it would've taken negotiating data transfers. **The killer integration challenge isn't technical--it's governance paralysis.** I've watched promising projects die because legal teams from different institutions couldn't agree on data sharing terms. We solved this by making governance granular: each site keeps full control, researchers get authenticated separately at each location, and only aggregated results cross organizational boundaries. Nobody has to surrender control to participate, which breaks the stalemate. The parallel to smart infrastructure is direct: your traffic system doesn't need to own your utility grid's data. They just need secure APIs to query what's relevant when it's relevant, with each system maintaining its own sovereignty and security posture.

I'm coming at this from a completely different angle than tech integration--I run a well drilling and septic company in Indianapolis. But here's what translates: the biggest mistake I see isn't about the systems themselves, it's about ignoring the people who actually maintain them after installation. We learned this the hard way when a commercial client wanted us to install a complex well system with automated monitoring. The property manager loved the dashboard, but their maintenance guy had been doing manual checks for 15 years and saw it as a threat to his job security. System worked perfectly for two months, then mysteriously started "malfunctioning." Turned out he was just ignoring the alerts because nobody trained him or showed him how this made his life easier, not obsolete. My advice: before you integrate anything, sit down with the people who'll be responding to 2 AM system alerts. In our business, that means showing the facility manager how our 24/7 monitoring means they're not getting emergency calls on Christmas morning. We now do a mandatory walkthrough with actual maintenance staff--not just decision-makers--within the first week. Those folks know where systems will actually fail in the real world. The integration challenge nobody talks about: different systems fail at different times, and finger-pointing between vendors kills you. When our well pump monitoring talks to a building's electrical system, and something goes wrong, you've got two companies blaming each other while water service is down. We now require a single point of contact in our contracts who has authority to troubleshoot across all connected systems--usually costs an extra $200/month but saves thousands in downtime.

Treat integration like a customer journey, not an IT checklist. Start by naming the three decisions you need faster, like signal timing, curb access, or fleet charging, then map which systems own the data behind each decision. Publish a simple data contract that defines identifiers, update frequency, and error handling, and require every vendor to pass a small interoperability test before procurement. Keep one shared incident playbook so operations, transportation, and utilities respond the same way when sensors or networks fail. The biggest challenge we see is identity and metadata drift. Different teams label assets differently, change firmware without notice, or export data in formats that look similar but behave differently. That creates silent failures where dashboards stay green while field performance degrades. The fix is disciplined governance, versioned schemas, and technical support that treats integration issues like service tickets, not one time projects.

I'm going to answer this from a completely different angle--from running passenger transport rather than tech infrastructure. But the lesson translates perfectly because we deal with the exact same integration headaches between booking systems, GPS tracking, compliance software, and vehicle maintenance schedules. **Biggest challenge I've hit:** Finding one supplier who actually picks up the phone when things break. We had three different systems that supposedly "integrated seamlessly"--booking platform, dispatch software, and our compliance tracker. None of them talked to each other properly, and when a school booking conflicted with a wedding charter at 6 AM on a Saturday, I got zero help from any vendor. Cost us a fortune in manual workarounds and nearly lost us both clients. **What actually solved it:** We ditched the "best-in-class everything" approach and went with suppliers we could grab coffee with locally. Our GPS provider is a Brisbane company--when their system glitched during a university tour, their tech was at our depot within 90 minutes. That relationship is worth more than any fancy feature list. Through COVID when we had 47 cancellations in one week, our local software partner rebuilt our cancellation workflow over a weekend call because he knew us personally. **My advice for cities:** Choose integration partners based on response time guarantees, not features. Build relationships before you need them. We maintain a short list of backup operators we actually drink beers with--when our bus broke down with 45 international students onboard, I had a replacement vehicle there in 22 minutes because I'd helped that operator out the month before. Infrastructure's only as smart as the humans maintaining it.

Pick one shared data standard and one integration layer early, then force every new system to plug into that instead of doing one off integrations forever. The biggest challenge I have run into is every vendor showing up with their own format, their own dashboard, and their own idea of what a "device" or an "event" even is. If you let that slide, you end up with five smart systems that all work fine on their own and a city that still cannot answer basic questions across them. The fix is boring but effective define your canonical data model, require open APIs, and make vendors prove they can integrate in a pilot before you sign a big contract.

One piece of advice is to start with the user journey and a shared data standard, not shiny tech, because "seamless" only happens when systems agree on identities, permissions, and handoffs. Japan's konbini culture is a great model: convenience stores act like distributed service hubs for payments, parcels, bill pay, and daily essentials, and the experience feels unified because the operational standards are consistent even across different providers. The biggest integration challenge is that every system has its own data formats and incentives, so without a clear governance layer and a few non-negotiable interfaces, you end up with disconnected services that look modern but behave like silos.

Start by establishing a single, secure identity and data standard that every system must use, and keep all approvals and changes inside the platform rather than over email. In our work unifying vendor onboarding, tax, and payments for events and productions, we built a closed loop where vendors self-onboard, identities and bank details are verified, and only verified data flows to the ERP with traceable in-platform approvals. The biggest integration challenge we encountered was stitching together fragmented, manual processes spread across spreadsheets, email, and separate tools, which created gaps in traceability and increased risk. The key lesson was to consolidate around one master record for counterparties and a single approvals workflow to reduce friction and make integrations resilient. Cities can apply the same approach to devices and services by choosing one data model, one identity layer, and one audit trail, then integrating systems to that backbone rather than point-to-point.

One piece of advice I would give to cities or organizations integrating smart infrastructure systems is to design for integration before deployment, not after. The biggest integration challenge I have encountered is fragmentation. Different systems are often implemented by different vendors, at different times, with limited coordination. When infrastructure is treated as separate parts instead of a connected ecosystem, even smart systems fail to deliver their full value. In my experience working with building upgrades and renovation projects, successful integration starts with clarity. When systems such as energy management, climate control, lighting, and approvals are planned together, decisions become simpler and outcomes more predictable. When they are introduced in isolation, complexity and cost increase quickly. What changed our approach was shifting toward transparency and upfront planning. By visualizing how systems interact before execution, stakeholders align earlier, conflicts reduce, and integration becomes smoother. The technology itself is rarely the problem. The lack of shared understanding usually is. The lesson applies at any scale. Smart infrastructure works best when organizations prioritize coordination, documentation, and transparency as much as the technology itself.

I spent years as Deputy Director of Baltimore County Economic Development and saw why most smart infrastructure projects fail--it's not the technology, it's that nobody asked the residents what actually bothers them daily. When we worked on economic development initiatives, the disconnect between what planners wanted and what small business owners needed was massive. My advice: start with basic city services that people complain about every single day. In Baltimore, we've seen situations where water bills take six months to fix and potholes stay unfilled for weeks. Those aren't sexy AI projects, but fixing trash pickup schedules or pothole reporting through better integrated systems builds trust that lets you tackle bigger infrastructure later. Get the fundamentals working first. The biggest integration challenge is that municipal departments protect their own systems like territorial dogs. When I served on community boards representing 17 different associations, trying to get any two groups to share data was nearly impossible--everyone wanted control of their own dashboard and budget. You need one executive sponsor with enough authority to force departments to use shared platforms, or you'll end up with five different apps that don't talk to each other and residents still calling the same broken phone line. Start small with something visible and annoying. Solve it completely. Then expand when you have proof and internal champions who are tired of the old broken way.

What's one piece of advice you would give to cities or organizations looking to integrate different smart infrastructure systems seamlessly? As a former state CIO, my biggest piece of advice is to design for integration first, not features. Most smart infrastructure projects fail quietly because each system is procured in isolation (traffic, utilities, public safety, building management) each optimized on its own. On paper, they're all "modern." In reality, they can't talk to each other without expensive glue code and manual workarounds. Start with shared standards, clean APIs, and a clear data ownership model before you buy anything. If the system can't integrate on day one, it will cost you forever. What's the biggest integration challenge you've encountered? Simply, technology is easy, but people and process are hard. The hardest challenge isn't technical it's organizational. Different departments protect their systems, budgets, and vendors like territory. As a former state CIO, I saw more integrations stall because of governance fights and unclear ownership than because of bad technology. When no one owns the end-to-end outcome, integration becomes everyone's "extra work" and no one's priority. The fix is strong central architecture authority paired with incentives that reward collaboration, not just local optimization. Without that, even the best technology stack turns into a fragmented mess.

I've spent 20+ years integrating complex systems across biotechnology, finance, and operations--from scaling Intelliflix's tech infrastructure to helping Sage Warfield clients access $50M+ in funding solutions. The biggest integration challenge isn't technical--it's human. You're dealing with different departments protecting their turf, legacy vendors who don't want to play nice, and procurement teams focused on initial cost rather than total system value. Here's what actually works: Start with one high-pain, high-visibility problem and solve it completely before expanding. When we launched GermPass in hospitals, we didn't try to replace their entire infection control system. We focused exclusively on the gap everyone acknowledged but couldn't solve--the 23+ hours between manual cleanings when high-touch surfaces stay contaminated. Once environmental services teams saw our system killing 99.999% of pathogens automatically after every touch, they became our biggest advocates for expanding to other units. My advice? Identify the "bleeding" problem where current systems fail spectacularly and existing staff are burnt out trying to patch it manually. That's your entry point. In our case, it was restroom stall locks and door handles in immunocompromised patient units--surfaces touched hundreds of times daily that EVS physically couldn't clean frequently enough. We proved ROI there first (one prevented HAI pays for years of GermPass operation), then had internal champions demanding we integrate into patient rooms, elevators, and staff areas. The integration challenge you'll hit hardest: data sharing between systems. Everyone wants to own the dashboard. Fight for open APIs from day one, even if it costs more upfront--proprietary systems that don't talk to each other will cost you 10x more in staff time and consultant fees within two years.

Advice: My one rule: Own the API layer. Never rent it from a vendor. The trap I see cities walk into constantly is signing onto a single "integrated solution" provider. Feels safe at first—one contract, one throat to choke. Fast-forward five years and you're a hostage. You can't swap out traffic management without also gutting parking sensors and street lights because they all speak a proprietary dialect only that vendor deciphers. The antidote is open middleware. Platforms like FIWARE exist for this exact reason. Standard APIs, common data models—any compliant system plugs in. You keep the power to swap parts without dismantling the whole nervous system. Challenge: The nastiest integration job I've faced was wiring a 1990s SCADA system to a modern IoT mesh. The old beast spoke a protocol that predates HTML. We ended up building a translation box—a physical gateway in the middle, converting ancient industrial commands into REST calls. Hard lesson: Legacy infrastructure is patient zero of integration nightmares. It does not bend. You wrap it, or you suffer.

I tell organizations to treat integration as a change project, not just a technical task. Systems connect easily, but people need time and clarity. I focus on clear communication, shared rules, and steady training from the start. Speed matters less than understanding. When teams see how data supports their daily work, integration feels useful and familiar. This approach builds trust and reduces confusion across departments. The biggest issue I face is legacy thinking. Old habits slow progress and create hesitation around new workflows. I address this by keeping early wins small and visible. I show teams faster decisions and fewer manual steps. Once results feel real, resistance drops. The system then grows with confidence, purpose and stronger adoption across the organization.

Prioritize phased integration: do not connect the next smart infrastructure system until the current one has clear processes, trained people, and proven stability. My biggest integration challenge came when I expanded our services too quickly; we ended up with unused product, a team not educated to my standards, and incomplete processes. That lack of structure led to poor patient education and confusion across the team. The lesson for cities is the same—pace rollout with discipline, sequence the work, and scale only after the foundation holds in day-to-day use.

One piece of advice I would give is to standardize data before you connect systems. Many cities rush to install sensors, cameras, and control panels without aligning formats or reporting rules. In my experience managing operations at PuroClean, integration fails when platforms speak different data languages. We once merged two job tracking systems and lost visibility on 15 percent of active projects for a week. The fix was building a single reporting structure first, then layering tools on top. The biggest challenge is not hardware, it is data governance and ownership. Someone must clearly own integration standards and accountability. Seamless systems start with clear structure, not just advanced technology.

I'll tackle this from the multifamily property tech stack angle--we deal with 15+ different platforms that need to talk to each other across 3,500 units, and the integration nightmare is real. **Biggest challenge:** When we rolled out UTM tracking and tried connecting it to our CRM, property management system, and Livly resident feedback platform simultaneously, nothing synced properly for three weeks. We lost granular lead attribution data worth thousands in wasted ad spend because our ILS feeds weren't tagging conversions correctly. The issue? Each vendor blamed the other, and we had zero documentation on who owned what data field. **What fixed it:** I created a simple shared spreadsheet mapping every single data point--where it originated, which system owned it, and who to call when it broke. Sounds stupid-simple, but when our video tour library (YouTube) stopped populating correctly on Engrain sitemaps during a lease-up, I knew exactly which vendor to call within 5 minutes instead of spending hours troubleshooting. That documentation cut our average integration issue resolution time from 8 days to under 24 hours. **My advice:** Document your data flows like you're handing them to someone who's never seen your systems before. When we launched geofencing through Digible, I made both their team and our website developer write down exactly what fires when someone converts--saved us when bounce rates spiked 12% and we traced it to a conflicting tracking pixel in under an hour instead of bleeding leads for weeks.

One piece of advice I would give is to agree on shared data standards and ownership rules before deploying any new smart infrastructure. Most integration problems do not come from sensors or hardware. They come from systems that cannot talk to each other cleanly because they were built in isolation by different vendors. The biggest challenge I have encountered is vendor lock in combined with incompatible data models. Traffic systems, energy management, public safety platforms, and building controls often collect similar data but store it in different formats with different access rules. When you try to integrate them later, you end up building fragile workarounds or expensive custom connectors. In one project, each system technically worked well on its own, but there was no agreed source of truth or common interface. Simple questions like who owns the data, how often it can be shared, and in what format slowed everything down. Integration became a governance problem, not a technical one. What worked was shifting the conversation upstream. We defined open APIs, standardized data schemas, and clear access policies before adding new systems. That made future integrations far easier and reduced dependency on any single vendor. The lesson is that seamless integration starts with coordination, not technology. Cities and organizations that treat data as shared infrastructure rather than a byproduct of individual systems avoid many of the hardest problems later on.

Start with data standards before you buy any hardware. Cities get excited about sensors and dashboards but skip the unglamorous prerequisite: getting water, transit and energy departments to agree on how their data should be structured. Without that agreement you end up with 5 systems that each work fine in isolation but can't talk to each other. The biggest integration challenge I've seen is organizational, not technical. One city we worked with had 3 different departments collecting traffic data in 3 incompatible formats. The actual sensor integration took weeks. Getting those departments to adopt a shared schema took 14 months. Nobody budgets for that. My advice: put a data governance lead in place before you issue your first RFP.

My one big recommendation: Before buying or hooking anything, settle on a simple, vendor-neutral city data contract, that every system would have to follow. Make the shared data model and rules be the product, every tool (new or old) has to use the same IDs, timestamps, APIs and owners for security and data quality. Then technology choices are details, not fights. The biggest challenge I've had is not tech, it's language and ownership. Various teams and vendors maintain inconsistent labels for the same things, time them differently and data appears linked but doesn't function in reality. We solved this by establishing one citywide dictionary for assets and events, standard IDs, and rules at the API layer gate plus a cross-agency group to make sure it all stayed honest. That made brittle one-offs into plug-ins and slashed the onboarding time from months to weeks.