In last month’s article, I covered two of the three categories of open. Just to recap, those categories are open protocols and open procurement.

In this article, I’m going to look at the third category of openness and examine specific language that can be used in specifications to achieve “openness.”

What are open systems?

Honestly, the definition of open systems is the most confusing of the three types. Open protocols are pretty straight forward — they’re protocols that communicate with one another. Open procurement means that materials are able to be procured. But open systems, what exactly does that mean?

To better understand this, let’s look at the issue with non-open systems. A non-open system may prevent a contractor from accessing a specific manufacturer’s programming software, accessing a specific database due to that database being tied to a specific system’s integrator, or accessing software updates, unless you are part of that manufacturer’s organization. These are all issues that are resolved when utilizing an open system.

In an open system, the components of the system are open to the end user or additional contractors. Components of an open system are most often hardware and software but can also be tools and support. These are all factors that should be considered in today’s day and age by a specifying engineer.

So, what can engineers do with this information? As a specifying engineer, you can understand what your customer’s expectations are regarding openness. Do they prefer to self-execute work, maybe buying parts and smarts? Or do they prefer to self-support? Are they looking to have a diverse group of contractors to support them both during the installation and/or service periods of their projects?

[Author’s note: It is at this point you are going to notice a shift to focus on integration. The reason behind this is that integration is inherently difficult to specify, therefore if we address the most difficult topic first, everything else will be easier.

Once you understand this information, you can begin to build out a specification that helps your customers achieve their goals. Now, there are two ways to address this.

The first is through a standard RFI/RFQ/RFP process. I’m not going to assume that you understand what these are, so here is a quick overview of the RFI/RFQ/RFP process.

When an owner is trying to find a solution to a problem, he or she requests information from experts, hence an RFI. Once the information is gathered, the owner will formulate a solution, often with the help of an engineer. Contractors then “qualify” to work on this solution through a formal request for qualification (RFQ). Finally, once the owner/engineer has a list of qualified contractors, the contractors will submit proposals for the project. From this process, known as a request for proposal or RFP, a contract will be awarded to a contractor for the project.

But how does this fit into the specification process? That is where things get tricky, and it is where engineers will be spending a fair amount of time. The reason you do not see a lot of integrated buildings in the plan and specification environment is because “integrated buildings” are inherently iterative by nature. In other words, it takes multiple tries to get an “integrated” building right.

That is why it’s difficult to provide prescriptive specification language for an integrated building. The methodology I will be teaching you in this article and greatly expanding upon in future articles is based on over a decade of experience integrating systems. I have done what I talk about, I know what works and what doesn’t.

The four-step methodology

Step 1. Define what the use case is. It is in this step that an engineer defines what it is he or she wants to do. This will include the use case along with a business case for the use case.

Step 2. Seek solutions to the use case. This is where engineers will utilize the RFI process to define the actual solution for the use case.

Step 3. Build out work packages. In this step, engineers will build out work packages that contractors will qualify for to perform.

Step 4. Secure contractors. In this final step, engineers will select contractors utilizing the formal request for proposal process.

For some of you, this may seem unfamiliar and a little intense. But to truly build integrated buildings, this is the process you must use. Simply specifying that contractors will “coordinate” integration may have worked in the past, when systems were simple, but today’s systems, data models, and use cases cannot be “field engineered.” In the next several articles, I will look at case studies that illustrate how to use this four-step process.