This article originally appeared on SecurityInformed.com.
BY DAVID FLEMING
It’s not hard to see why more and more locations are requesting security solutions that operate on an open system. Selecting products and platforms that utilize open standards—Session Initiation Protocol (SIP), HTTP, IEEE, RESTful APIs, etc.—provide additional levels of interoperability, scalability and versatility that give organizations the flexibility they want to be proactive with safety and security.
Unfortunately, creating the right solution today isn’t quite as simple as reading a product sheet or specification. In the past, end users frequently were forced to pick hardware and software products that were proprietary to each individual manufacturer, meaning pieces of technology often didn’t have the ability to talk and interact with products that didn’t also carry its brand name.
In the future, all systems likely will be open in some form and will provide a litany of connectivity options with little-to-no additional development time and resources.
But until that day is here, it is important to manage the expectations for stakeholders involved with the project appropriately, knowing that the current security landscape has not yet evolved to the point that all systems are truly open.
Consumer Technology Expectations
To be fair, the end user’s expectations are often set by what they see happening with consumer technology and not by what is currently available in the security marketplace. There, technological advancements can seem to happen overnight. The apps on your smartphone, for instance, perform almost instantaneous updates, even while you are not actively using it.
As convenient as that may be with social media or gaming apps, this also can signal a system that regularly requires fixes and patches, a scenario that would not provide stakeholders with the advanced level of reliability that is demanded for adequate safety with commercial security products, in large part because it will expose locations to numerous liability issues. As a result, the current security space can resemble its past almost as much as its future.
Decreased Potential For Compatibility
Make no mistake, there are certainly many products available today that can easily integrate into open platforms, only in a more limited capacity. An IP desk phone, for example, could easily connect to another IP PBX system that can then place basic calls.
But as the customer’s demand for additional sophisticated options increases—diagnostics, event triggers, location identification, etc.—the potential for compatibility decreases. When it comes to security, this is due to the fact that two products or systems rarely expose similar functionality using the same technology or language.
Take this example, for instance: Manufacturer A sells a product that contains Features X and Y; Manufacturer B offers one with Y and Z. The customer therefore assumes – or may even be sold – a solution where X, Y and Z can all be configured.
Pairing the two may give you interoperability with Feature Y fairly easily (if they are implemented the same way), but X and Z will not happen without an additional investment that may be difficult to procure.
Meeting End User Expectations
The devil, however, is in the details, a message that isn’t always effectively communicated to end users. Excusing it all off with the old idiom ‘It’s all Greek to me’ only sets up the project for potentially expensive revisions later on – costs that the integrator often has to eat. Therefore, it benefits all parties to have a common understanding of the project from the very beginning.
Given the current state of the consumer marketplace, it is vital for integrators to understand the reality of the products they are considering before seeking out potential solutions.
Many manufacturers offer a list of ‘integration partners’ they are compatible with, but these scenarios will carry a predefined scope that may not match the end user’s expectations.
Assessing Compatibility
To understand the full options available, a copy of a manufacturer’s Software Development Kit (SDK) needs to be requested, which should include detailed information about the possibilities for integrations with their products.
From there, you can compare the devices being considered to see how compatible they are with one another. Finally, it is important to consider the practical implications of financing. If the end user is seeking features that are not currently possible, then additional development will need to be contracted in order to make it happen.
Some manufacturers offer design services with developers who are acclimated to their platforms that can help expedite the learning curve.
However, with the right SDK and a background in the platforms being used, a third-party development firm or contractor is fully capable of providing the same level of work as the manufacturer.
Considerations For Security System Integration
To reiterate, any integration, no matter the scope, requires you to consider the following three questions:
- What does the end user want?
- What can the products do today?
- How can you bridge the gap?
It is imperative that both integrators and end users take the time to do the homework required with those three key questions to ensure they are selecting a solution that will not only work tomorrow, but also provides an appropriate layer of protection for people and assets today.
This also should help mitigate any confusion or frustration that may be experienced by the customer. As much as we all would like to believe that each and every feature available is a viable option that simply isn’t feasible given the realities we face today.
There will come a day when the technological advancements enjoyed by consumers around the world provide the type of experience that can be applied to security.
Until that time arrives, though, each party involved in the project needs to understand what exactly is currently available from a hardware and software standpoint. The safety of everyone at that location depends on it.
David Fleming is the Chief Design Officer for Code Blue Corporation.