Hey friends,

Today, we're continuing our series on Nexus Lore: the core concepts that come up again and again in this newsletter, on the Nexus podcast, in the Nexus Foundations course, in Nexus Pro gatherings, and in the community chatroom.

If you want to start at the beginning, check out our white paper with all 10 parts: Nexus Lore.

Lore is never written by one person, so send us your feedback for v2!

Let's jump into Part 5...

The Network Layer

Last week, we talked about all the devices that now need a network connection. In order to enable use cases for technology, we need to:

• allow remote access for administration;
• get data to the cloud;
• allow communication from the cloud to the devices; and
• allow communication from device to device.

Pretty simple, right?

Not so fast. As most of us have experienced on our projects over the years, if we don't treat the network layer seriously, things can blow up rather quickly. Network problems hold the industry back by making smart buildings look risky, delaying project success, increasing costs, and making stakeholders question whether the juice is worth the squeeze.

What problems are we talking about? Let's name a few...

🤫 When the IT folks close your hole in the firewall because they didn't know what it was.

😬  When you're scanning the network for the devices you know exist but are nowhere to be found.

🥴 When the power goes out and someone needs to reboot every device manually, but they forget the penthouse where all the air handling units are.

🫣 When you're on a new construction project and there's no budget for the full commissioning scope, and yet three different contractors are running redundant cabling.

😵‍💫  When that's where you're supposed to plug in your device.

😭 When the demand management project fails because the internet went down on the hottest day of the year and your software couldn't send the command to curtail the load.

😤 When your access control system is hacked and held for ransom.

You get the idea... All of those problems, and more, are solved at the network layer of the stack.

A dedicated layer with its own hardware, software, standard operating procedures, and key stakeholders who take responsibility for doing it right. It should be converged, monitored, maintained, and have redundancy.  

After all my interviews so far on the Nexus Podcast, I've learned that the key word is "responsibility". We have this IT network or networks, some of which has smart building function and importance. IT teams generally have no understanding of/experience with networked building system protocols and communication methods. And we have this OT network or networks, that’s in varying degrees of convergence onto a common internet protocol infrastructure. OT teams, meaning Engineering or FM or their vendors, have experience with BAS and related systems, but little understanding of/experience with enterprise networks and IoT.

Someone must take the responsibility to fill the IT/OT gap to enable the success we’re looking for, as a mutual understanding of both IT and OT systems is needed to manage the smart building network effectively.

The typical building has a hodgepodge of unmanaged siloed networks, “flat” networks running multiple building systems through one switch, building systems connected to the IT network, and building systems wide open on the internet.

So who should take responsibility? I think the best solution depends on what organization you're talking about. In some organizations, like Google, the IT folks take full responsibility. In other organizations, the IT team simply doesn't have the bandwidth or skill—they've found success leaning on dedicated service providers. Finally, I think most of the debate on this topic resides around whether OT vendors should take responsibility (a topic for another day).

What's not up for debate? The ways the current network hodgepodge causes dumb buildings. The enabling infrastructure that lets us fulfill our vision for smarter buildings.

Do you agree? What did I miss?

Let us know on LinkedIn,

—James Dice, Founder of Nexus Labs

P.S. Cohort 4 of our Foundations course (where we have a whole week dedicated to networks!) ended this month. Check out some lovely LinkedIn testimonials here, here, and here; then join the waitlist for Cohort 5!

✖ At the Nexus

Here’s everything worth sharing from Nexus HQ this week:

★ PODCAST: 🎧 #102: Unpacking 2022's major themes with Newcomb & Boyd—Episode 102 is a conversation with Paul Maximuk and Donny Walker of Newcomb & Boyd, a company focused on smart building consulting engineering.

We talked about some major themes for our industry in 2022, including hybrid office and decarbonization, and the major themes showing up on their active project list right now, including converged networks, the independent data layer, and building operating systems.

---

★ FROM THE ARCHIVE: Defining and exploring the Independent Data Layer

---

★ MEMBERS-ONLY EVENTS IN JUNE:

• Subject Matter Expert Workshop: CEO at BuiltSpace Technologies Corporation, Rick Rolston will present on Motor Monitoring
  and Analytics.
• Subject Matter Expert Workshop: Co-Founder and CTO at Senseware, Julien Stamatakis, will join us as the subject matter expert leading the conversation on how Real-Time IAQ Data Drives Modern Building Management.
• Member Gathering: James and Pro member Brian Vaughn of Cushman Wakefield will discuss the key ways technology is transforming building operations. James and Pro member Andrew Knueppel, also of Cushman Wakefield, will discuss the three categories of MSIs in the marketplace today. Plus, breakout rooms for networking!

​Join Nexus Pro now to get the invites and access to the recordings.

---

★ ON LINKEDIN: Digital twins have been continuously voted by the Nexus Labs community as the most overhyped technology in our industry.

---

★ LINK OF THE WEEK: PG&E's FDD Demo Series—Free 90 minute demos with some of the top FDD providers? Yes, please.

---

👋 That's all for this week. See you next Tuesday!