Recently my company attended ASIS 2016, where the tag line was: “360 Vision – Security’s Full Spectrum of Solutions.” With anticipation we hoped to see many of the technology vendors on the exhibition floor begin to take part in a discussion of their role in constructing a 360-degree view of all hazards risk, resilience and security. As well, we wanted to see the tools by which the executives who managed these programs, measured their people, processes and technology over time.

Here are three things we heard:

• From a Director of IT: “This industry does not have a process or contract vehicle by which I can be assured of the viability and sustainability of the integrations (APIs, or application programming interfaces, which provide the building blocks of applications, programs and web-based systems, which can potentially be integrated into a comprehensive risk-mitigating technology platform) over time.”

• From an executive of a physical access control technology vendor: “We have to be careful who we give our API to. We do not want to make ourselves vulnerable to competition.”

• From another executive of a physical access control vendor: “We don’t make money on spending time and resources building connections to other company’s products.”

As a Security Risk Management Services (SRMS) provider, we are chartered to provide a 360-degree view of the business risk to our clients and help them mitigate that risk over time. We need technology that is able to be integrated to do this. And we need the commitment from those technology vendors to sustain those integrations over time.

Do you see the problem?

Let’s look at some reinforcing myths that sustain the prevailing culture of our industry:

Myth #1: We are open. We have an API.

The problem with this statement is it obscures the ‘‘rest of the story’’. You can have an API, but if you don’t have full open documentation and tools by which to support it, then no one but the vendor’s programmers can use it.

Myth #2: Integrators know how to build and sustain APIs. After all, they are integrators, right?

With Myth #1 in mind, the problem with this myth is that most integrators may know how to install systems, but they don’t have the business model to write or maintain an API. And the client may not have the program discipline to ensure it is sustained over time or develop a plan for version control and updates for all their integrations.

Myth #3: A closed, proprietary system provides product vendors and integrators a competitive advantage, since they are less prone to being replaced.

This could be true in the short term. But once the number crunching begins with inputs such as maintenance cost and opportunity cost of settling for below average applications, then the signs of disruption will begin. How do we change the DNA of the integrator that believes “It is easier to sell closed solutions even though open solutions are better for my clients”?

Is there a way to evaluate the openness of the technology vendor so you can achieve a 360-degree technology architecture? Here are some thoughts:

• Do they design integration extensions into every product preferably using industry standards?

• Do they provide documentation and tools to build and sustain integrations?

• Have they created a community portal for the integrations so that other users and integrators can provide insights into what works and what doesn’t?

• Do they provide certification of each solution before allowing it to enter their integration portal or store?