I was sitting in a cramped room, surrounded by several software engineers who were passionately arguing among themselves about a data model and how we could integrate two systems seamlessly. I interjected, being the glutton for punishment that I am, what is the value this will deliver? They turned and looked at me with a look that beamed, "Who is this guy and why is he asking about value? Doesn't he understand that there can't be any value if the systems can't even talk?"
It happens every day I will sit down with folks who are so focused on the solution that they fail to look at the higher level questions. I have a confession to make, this didn't come naturally to me. I am an analytical technologist by nature and it took a lot of coaching to get me to think value first, than technology.
So, I got to thinking, with all the IoT and connected whatever buzzwords floating around is there anything I could take from my painful experiences and pass on to my readers as they consider "integration"? I came up with five key questions I believe anyone should ask themselves before they "integrate". The five things are:
- Have I identified a use case?
- Can I associate value with this use case?
- Does the use case provide more value then it costs?
- Can I support the use case after "xyz" company leaves my site?
- Does this use case provide a spring-board to greater use cases that will provide even greater value?
Have I identified a use case?
It would seem basic that the first thing you would want to know prior to purchasing technology is "How am I going to use this technology". The road to many a facility offices are paved with well intended integration proposals. It's not that these proposals are technically lacking. Rather it's that the use case is not defined.
Therefore, prior to doing any integration define your use case. In order to define a use case you must do three things:
- Identify your users and systems
- Identify what your users will do with or to those systems
- Identify what the systems will do in response
An example would be to say that when a tenant walks by the occupancy sensor the occupancy sensor will tell the HVAC system to occupy. The HVAC system in turn will tell the lighting system to increase brightness for 3 minutes.
Can I associate value with this use case?
Using the above example, what value could we get from an integration involving a tenant , HVAC system, and lighting system? First lets qualify value. Value comes in two forms qualitative and quantitative. Your CFO wants Quantitative value, this is value measured in dollars. Your Director of Tenant Engagement may want qualitative value, this is measured in perception.
Therefore, using our example we can identify two kinds of value.
The lights being lower and HVAC being off when the space is "unoccupied" reduces electrical consumption. This in turn saves dollars. This is a quantifiable benefit.
The fact that the lights and HVAC respond to the tenant automatically makes the tenant happy. A happy tenant ranks your environment higher on satisfaction scores. This feeling of happiness is a qualitative benefit.
Does the use case provide more value then it costs?
So far we have identified our use case and we have identified our qualitative and quantitative benefits. Now we must provide a dollar value to each of our benefits and subtract our cost from those benefits. If our system has an operational cost we must factor that in. I'm not going to bore you with a discussion on Return on Investment. Suffice to say, if our system's monetized "value" saves more than the system costs to maintain then we have a cash-flow positive system.
Can I support the use case after "xyz" company leaves my site?
One of the biggest areas of consternation is around supporting the use case after the company who installed it finishes their warranty period. I'll be real with you, anyone who tells you integrations are seamless is fooling you. Integrations require constant maintenance and attention. Whenever multiple systems are brought together to produce an outcome, complexity is not far away.
However, this does not have to be a bad thing. If you understand your systems from day one you can work with your provider and your system owners to ensure that a proper integration life cycle plan is in place. To create an integration life-cycle plan follow these four steps:
- List out all of the integrated systems and software
- Define the connection between these systems
- Define the process for checking the connections post-maintenance and/or upgrade
- Document the replacement process for each system
Does this use case provide a spring-board to greater use cases that will provide even greater value?
At the end of the day integrations are awesome, heck they keep me employed and give me a ton to write about. However, the real magic happens when you are able to use multiple integrations to build upon one another. This is a common strategy within the IT world but it is only recently being explored within the building automation space.
This concept in the IT world is called enterprise architecture (EA). EA, focuses on the as-is architecture and the to-be architecture. The architect will meet with the stakeholder and will define use cases and use these use cases to create work packages. These work packages will help to realize the to-be architecture.
In the case of integrations the architect will use a concept called chaining. Chaining is where a single task is supported by a chain of child tasks. An example of this would be:
I specify a BACnet controls system so,
I can connect a BACnet Lighting System which,
Interfaces with my occupancy sensor to control occupancy when,
My google calendar interface determines that I am not occupied.
While this example is not a perfect physical chain, logically the systems build upon one another to form a chain.
You can replicate this approach on your projects by building an integration chain. In order to build an integration chain you:
- List out all your systems
- Identify any functionality between the systems
- Identify any systems that this functionality is dependent on
- Begin to draw a line between these systems and number the "integrations"
- Identify any additional integrations that you can enable by "chaining" the systems
Conclusion
Man, that was fun, hopefully you had as much fun reading that as I had writing that. My hope is that after reading this article the cloud of fog surrounding integrations has been lifted a bit. As you apply the tools I taught you in this article please post the most interesting integration chain you have created.
I look forward to talking to you in the comments section below.
