Why do specifiers struggle to implement a smart, integrated building during a plan-and-spec (and, in some cases, a design building) project?
In this month’s article, I’m going to begin a series of looking at how to build integrations into a specification.

INTEGRATION LIFE CYCLE

First things first, let’s define the integration life cycle. The big problem with smart buildings is that as more systems are added, the complexity exponentially increases. Yes, I know, this is an obvious statement. What is not so obvious is why this occurs. Contractors would have you believe that this complexity is due to the coordination of multiple contractors. This is partially true but definitely not the whole truth.

Stage One: Define the Business Outcome — When an integration is first created, it begins (or it should begin) as an idea that drives toward a business outcome. Reduce labor, increase efficiency, mitigate cost, and extend equipment life. All of these are business outcomes. 

How these business outcomes are achieved differs, but the outcomes remain the same. With a well-defined outcome, one can pick systems to achieve a use case. A use case quite simply is a set of actions that achieves a goal. In our case, a use case is how our systems will act with one another in order to achieve our business outcome(s).

Stage Two: Use Templated Plans — Once a business outcome has been defined, move onto stage two of the integration life cycle. This is when we start to think about how these systems will come together in order to achieve the use case. It is also at this point that things start to get expensive, contractual responsibility becomes a hot button issue, and the age-old question of who will pay for this becomes the top discussion point at planning meetings.

But it doesn’t have to be this way. Specifiers are great at having boilerplate templates. Integration should be no different. Engineers should have a template for each of their use cases that allows them to describe how the systems should interoperate. 

Should the lighting system be driven by the act of someone badging into the building or by the building’s occupancy schedule? These items can be defined once and used again and again.

Stage Three: Research Interoperability — This is the stage where engineers get stuck. It can feel absolutely overwhelming to think through protocols, application program interfaces (APIs), data models, etc. I get it. But, this is the world you chose to play in. I meet too many folks who just wash their hands of this and write in “contractors to coordinate in field.” This is an easy way to punt the ball until after the construction documents (CDs) are done. But, ultimately, this will cause more problems as an individual gets drawn into coordination meetings and your margin erodes. 

There is a better way.  Lighting, audio-visual, access control, power, etc., all speak protocols. Take the time, research the protocols, and have the vendors present to you. Have the vendors spend their time and marketing dollars teaching you how to integrate and consume data from their systems. It has been my experience that consulting engineers often do not take advantage of their power as the engineer of record. People will come to you if you ask.

Stage Four: Implement, Document, and Archive — The reality is, the first couple of integration projects will cost a firm more than it budgeted. But, if personnel documents the post-project design, they can create repeatable templates that will carry the firm through future projects. This is the most important stage of the life cycle. The firm has already absorbed the costs of a design; make sure the company captures the design’s deliverables for future projects.

CONCLUSION

In next month’s article, I’m going to begin a series of articles working through, in detail, the stages from this article. My hope is that by doing this, engineers can begin to grow a profitable division within their companies that is focused on smart integrated buildings.