Join us at NexusCon 2024 - Apply to attend now
“This framework is incredible for understanding the difference between technologies.”
—Nexus Foundations student
In Module 4 of the Nexus Foundations course, we provide students a simple framework to use when researching new technology in our space. This framework is also a companion guide to the Nexus Vendor Landscape. Today, I’m sharing it with you Pro members and would love your feedback on how the framework and/or landscape could be improved upon.
Back to the course: At this point in the journey, the students have done the hard work required to understand key stakeholders, develop use cases grounded in human workflows, and assess the existing systems to understand the integration requirements.
In other words, they now have identified The Gap—that void between their existing systems and the use cases for new technology.
So how can new technology fill the gap?
Well, let’s first acknowledge that getting to this point is actually pretty rare. Most companies don’t do this work upfront. What I hear the most is that people jump straight to new technology because they don’t want to get left behind. Everybody is talking about AI, digital twin, analytics, etc, so we must need that too! Let’s do a pilot, they say…
That’s a reaction, not a decision, and certainly not a strategic decision. There are a lot of meetings in our industry that happen just like the meeting in this comic strip…
Making this problem worse is this phenomenon I’ve noticed where we often aren’t actually talking about the same things. I can’t tell you how many one-hour meetings I’ve been in where the first 55 minutes are spent getting on the same page…
What does the technology do? How does it relate to the technology we already have? How does it compare to the other technologies we’re evaluating?
This issue is further exacerbated when, even if we’re using the same terminology, we have differing definitions for the same words.
What do you mean when you say analytics? Energy management system? Energy management information system? Building management system? Building energy management system? Facility-related control system? IoT platform? Digital Twin?
It’s overwhelming.
Acronyms and names that can mean pretty much the same thing are getting lost in translation. Lots of time is being wasted because we’re talking in circles.
I’ve seen the consequences of this first hand: When building owners are confused, they slow down purchases, do nothing, or purchase a lousy product that doesn’t meet their needs and sets them back for years.
So today’s deep dive is centered around a framework I use to cut through that noise and confusion and answer the “What is it?” question.
It does this with three simple questions:
When I see a demo from a technology provider, I like to grab a notebook or a whiteboard and draw these three boxes and take notes into them. Questions one through three make up the product’s capabilities, stack, and scope.
And before we dive into each one of them, let me say that this is a non-technical framework. You can get as detailed as you want, but you don’t really need to get detailed to get a lot of understanding out of the mapping exercise.
And one thing I’ve noticed when talking to non-technical stakeholders about smart building products, it’s often best to start at the bottom of the framework. Start with the scope—that helps them begin by connecting the new tech to what they already have. So let’s do that.
The scope is simple: What does the product connect to? The scope could be any of the existing systems in the building, plus any third-party systems. And those connections could be native integrations at the very edge, through supervisory controllers on the IP network, or through the internet.
For example, the CMMS could be sitting on a local server or it could be accessed through a cloud connection. Further, the integration with each system could be a one-way transfer of data or it could be a two-way communication stream. So if you wanted to get more detailed, you could draw that 2-way connection with arrows.
On top of that sits the stack. A smart building product typically isn’t one singular thing or application. The stack is all of the devices, data services, and applications that provide capabilities to the user.
Depending on the implementation, the stack has many different components. Again, if you want to keep it non-technical, the four categories shown are probably all you need: Cloud software, mobile applications, local hardware, local software. And note that most products are quite flexible in their local architecture - they usually have the ability to put their software on a virtual server or a hardware device, so those bottom two categories could be more of an either/or.
The top layer of the framework is capabilities. Once you communicate with building systems or collect data, process it in the stack, what in the world are you actually doing with it? How does the product enable your use case?
And now you can see I’ve added a little cheat sheet in the form of 5 different types of capabilities: Centralize, Analyze, Control, Optimize, and Engage. Let’s walk through each one.
Centralizing is about bringing data from multiple silos together. We’re talking about digitizing it by getting rid of paper or getting it out of spreadsheets that aren’t central or connected. We’re talking about normalizing it and getting it into one database with a common data model to make it useful. We’re talking about connecting the data across traditional non-building silos like portfolios and departments. And often these types of tools provide tools to visualize the data in simple ways.
Example terms or products or buzzwords include:
Note that this capability often supports the other capabilities we’re about to cover, so some would argue that it’s actually part of the stack. But sometimes it’s sold as a stand-alone thing, which means there must be some stand-alone capability that it’s providing.
This is where the data gathered in the stack is transformed in some way to produce insight. So we’re talking cool math, advanced visualizations, historical models, fault or anomaly detection and diagnostics, models that predict the future, simulations, etc.
Note that in order for the insight to actually produce value, there often needs to be a human or humans in the loop. In other words, we need to go from insight to action. But the insight itself is valuable on its own of course. It helps us to use our data to improve our workflows.
Examples include:
First, let me say that my perception is that most of the products on the market today are in those first two categories - Centralize and Analyze. Control is not very well deployed, and neither are the following two below.
So whereas with analyze we talked about there being a human in the loop, control is when the product is designed to close the loop in some way, whether fully or partially, automatically or not. This requires a deeper, two-way integration process and a more sophisticated stack than simple collection and analysis.
These control sequences can be simple or super-advanced and since the product usually connects our siloed systems, it starts to allow cross-silo control and starts to get closer to a truly autonomous building.
Examples of controls capabilities include:
Whereas the previous types of capabilities were around using data and insights and commands to improve workflows, they didn’t really do much for the workflows themselves. So when I say optimize, I’m talking about taking human processes, digitizing them, and making them more efficient. Whether that be taking direct action from data or analytics or triggering the next steps based on some predefined action happening.
This is nuanced, so let’s talk through some examples:
And finally, our last category of capabilities. This is where the smart building platform takes that process optimization to the next level and connects stakeholders to one another. This is most commonly done through connecting with the occupant, but could also be connecting other stakeholders as well.
How does the product facilitate interactions and/or create that certain experience for stakeholders? Examples are:
Once you get comfortable with the framework you can start to use it to group companies into buckets based on similar capabilities. And you’ll also find that the framework can help you compare companies, imagine how they might improve, and analyze which companies might be great complements to each other.
Our first grouping is what is affectionately and sometimes non-affectionately called analytics. Probably 98% of the analytics implementations out there look something like this:
Your scope is HVAC, lighting, meter data, and pulling weather data from weather API somewhere. You have some sort of on-site gateway that handles the data collection and pushes data to the cloud. The cloud software has three roles: serve a user interface to the user, crunch the data, and store the data.
Capabilities provided are centralizing that data, which used to be scattered across three silos and allowing you to visualize it. Then analyzing it, perhaps through FDD or other means. And often you’re able to set energy baselines and calculate savings.
Now, once it’s mapped, the 5 categories of capabilities allow us to imagine ways the capabilities of the tool could be extended into the other categories.
As cool as FDD analytics to detect a leaking valve are, you could still imagine a better version, where it builds on that insight by adding:
The point of mapping it out is to see where to tool stops, which is where you’ll need to add onto it with another tool or interact with it in the workflow.
So here’s my challenge for you today: pick a technology and map it out. I would love to see you put this into action. In fact, here’s a template for you to fill out. Create a copy and send us the link on Connect!
I plan to use your feedback to take the Vendor Landscape to the next level.
Thanks for reading,
James
“This framework is incredible for understanding the difference between technologies.”
—Nexus Foundations student
In Module 4 of the Nexus Foundations course, we provide students a simple framework to use when researching new technology in our space. This framework is also a companion guide to the Nexus Vendor Landscape. Today, I’m sharing it with you Pro members and would love your feedback on how the framework and/or landscape could be improved upon.
Back to the course: At this point in the journey, the students have done the hard work required to understand key stakeholders, develop use cases grounded in human workflows, and assess the existing systems to understand the integration requirements.
In other words, they now have identified The Gap—that void between their existing systems and the use cases for new technology.
So how can new technology fill the gap?
Well, let’s first acknowledge that getting to this point is actually pretty rare. Most companies don’t do this work upfront. What I hear the most is that people jump straight to new technology because they don’t want to get left behind. Everybody is talking about AI, digital twin, analytics, etc, so we must need that too! Let’s do a pilot, they say…
That’s a reaction, not a decision, and certainly not a strategic decision. There are a lot of meetings in our industry that happen just like the meeting in this comic strip…
Making this problem worse is this phenomenon I’ve noticed where we often aren’t actually talking about the same things. I can’t tell you how many one-hour meetings I’ve been in where the first 55 minutes are spent getting on the same page…
What does the technology do? How does it relate to the technology we already have? How does it compare to the other technologies we’re evaluating?
This issue is further exacerbated when, even if we’re using the same terminology, we have differing definitions for the same words.
What do you mean when you say analytics? Energy management system? Energy management information system? Building management system? Building energy management system? Facility-related control system? IoT platform? Digital Twin?
It’s overwhelming.
Acronyms and names that can mean pretty much the same thing are getting lost in translation. Lots of time is being wasted because we’re talking in circles.
I’ve seen the consequences of this first hand: When building owners are confused, they slow down purchases, do nothing, or purchase a lousy product that doesn’t meet their needs and sets them back for years.
So today’s deep dive is centered around a framework I use to cut through that noise and confusion and answer the “What is it?” question.
It does this with three simple questions:
When I see a demo from a technology provider, I like to grab a notebook or a whiteboard and draw these three boxes and take notes into them. Questions one through three make up the product’s capabilities, stack, and scope.
And before we dive into each one of them, let me say that this is a non-technical framework. You can get as detailed as you want, but you don’t really need to get detailed to get a lot of understanding out of the mapping exercise.
And one thing I’ve noticed when talking to non-technical stakeholders about smart building products, it’s often best to start at the bottom of the framework. Start with the scope—that helps them begin by connecting the new tech to what they already have. So let’s do that.
The scope is simple: What does the product connect to? The scope could be any of the existing systems in the building, plus any third-party systems. And those connections could be native integrations at the very edge, through supervisory controllers on the IP network, or through the internet.
For example, the CMMS could be sitting on a local server or it could be accessed through a cloud connection. Further, the integration with each system could be a one-way transfer of data or it could be a two-way communication stream. So if you wanted to get more detailed, you could draw that 2-way connection with arrows.
On top of that sits the stack. A smart building product typically isn’t one singular thing or application. The stack is all of the devices, data services, and applications that provide capabilities to the user.
Depending on the implementation, the stack has many different components. Again, if you want to keep it non-technical, the four categories shown are probably all you need: Cloud software, mobile applications, local hardware, local software. And note that most products are quite flexible in their local architecture - they usually have the ability to put their software on a virtual server or a hardware device, so those bottom two categories could be more of an either/or.
The top layer of the framework is capabilities. Once you communicate with building systems or collect data, process it in the stack, what in the world are you actually doing with it? How does the product enable your use case?
And now you can see I’ve added a little cheat sheet in the form of 5 different types of capabilities: Centralize, Analyze, Control, Optimize, and Engage. Let’s walk through each one.
Centralizing is about bringing data from multiple silos together. We’re talking about digitizing it by getting rid of paper or getting it out of spreadsheets that aren’t central or connected. We’re talking about normalizing it and getting it into one database with a common data model to make it useful. We’re talking about connecting the data across traditional non-building silos like portfolios and departments. And often these types of tools provide tools to visualize the data in simple ways.
Example terms or products or buzzwords include:
Note that this capability often supports the other capabilities we’re about to cover, so some would argue that it’s actually part of the stack. But sometimes it’s sold as a stand-alone thing, which means there must be some stand-alone capability that it’s providing.
This is where the data gathered in the stack is transformed in some way to produce insight. So we’re talking cool math, advanced visualizations, historical models, fault or anomaly detection and diagnostics, models that predict the future, simulations, etc.
Note that in order for the insight to actually produce value, there often needs to be a human or humans in the loop. In other words, we need to go from insight to action. But the insight itself is valuable on its own of course. It helps us to use our data to improve our workflows.
Examples include:
First, let me say that my perception is that most of the products on the market today are in those first two categories - Centralize and Analyze. Control is not very well deployed, and neither are the following two below.
So whereas with analyze we talked about there being a human in the loop, control is when the product is designed to close the loop in some way, whether fully or partially, automatically or not. This requires a deeper, two-way integration process and a more sophisticated stack than simple collection and analysis.
These control sequences can be simple or super-advanced and since the product usually connects our siloed systems, it starts to allow cross-silo control and starts to get closer to a truly autonomous building.
Examples of controls capabilities include:
Whereas the previous types of capabilities were around using data and insights and commands to improve workflows, they didn’t really do much for the workflows themselves. So when I say optimize, I’m talking about taking human processes, digitizing them, and making them more efficient. Whether that be taking direct action from data or analytics or triggering the next steps based on some predefined action happening.
This is nuanced, so let’s talk through some examples:
And finally, our last category of capabilities. This is where the smart building platform takes that process optimization to the next level and connects stakeholders to one another. This is most commonly done through connecting with the occupant, but could also be connecting other stakeholders as well.
How does the product facilitate interactions and/or create that certain experience for stakeholders? Examples are:
Once you get comfortable with the framework you can start to use it to group companies into buckets based on similar capabilities. And you’ll also find that the framework can help you compare companies, imagine how they might improve, and analyze which companies might be great complements to each other.
Our first grouping is what is affectionately and sometimes non-affectionately called analytics. Probably 98% of the analytics implementations out there look something like this:
Your scope is HVAC, lighting, meter data, and pulling weather data from weather API somewhere. You have some sort of on-site gateway that handles the data collection and pushes data to the cloud. The cloud software has three roles: serve a user interface to the user, crunch the data, and store the data.
Capabilities provided are centralizing that data, which used to be scattered across three silos and allowing you to visualize it. Then analyzing it, perhaps through FDD or other means. And often you’re able to set energy baselines and calculate savings.
Now, once it’s mapped, the 5 categories of capabilities allow us to imagine ways the capabilities of the tool could be extended into the other categories.
As cool as FDD analytics to detect a leaking valve are, you could still imagine a better version, where it builds on that insight by adding:
The point of mapping it out is to see where to tool stops, which is where you’ll need to add onto it with another tool or interact with it in the workflow.
So here’s my challenge for you today: pick a technology and map it out. I would love to see you put this into action. In fact, here’s a template for you to fill out. Create a copy and send us the link on Connect!
I plan to use your feedback to take the Vendor Landscape to the next level.
Thanks for reading,
James
Head over to Nexus Connect and see what’s new in the community. Don’t forget to check out the latest member-only events.
Go to Nexus ConnectJoin Nexus Pro and get full access including invite-only member gatherings, access to the community chatroom Nexus Connect, networking opportunities, and deep dive essays.
Sign Up
Nexus Labs exists to move the smart buildings industry forward, without the fluff.
On Wednesday, we send out the renowned (and free) Nexus Newsletter.