How To Define Open Architecture In An RFP?

A member has asked us what is the best way to prevent a user getting stuck with a closed or proprietary system when issuing an RFP. It's a good question because typically RFPs just require a system to be 'open architecture' without any further qualification, while most systems are sufficiently complex that they can claim to be 'open' even if they are mostly closed.

To properly specify openness, I believe one needs to (1) carefully define what elements need to be and (2) how they are opened.

What Elements Need to Be Opened

A VMS, for instance, can (hypothetically) be integrated with lots of third party devices (from cameras to recorders to analytics to PoS to PSIM to access control, etc.). First, and foremost, any and all systems one would like to have the option to integrate with 'openly' should be defined in the RFP (e.g., "The VMS must have an open architecture facilitating integration with A, B, C, D, etc.").

How They Are Opened

The typical way vendors confirm they are open is by waving their API / SDK, saying that with it, one can integrate anything. You should be more specific, require that a specific set of APIs be available to integrate with what whatever other systems you desire (e.g., cameras, recorders, analytics, PoS, etc.).

Also, beware and specify the availability of the API / SDK, for instance that the API will be available at no additional charge to whatever third party device you request it to be provided to (Note: this is critical for the end user but something the manufacturer may fight over as they often want to control who has access to their API)

Alternatively, you might specify openness via a 'standard' like ONVIF. While including ONVIF specifically is better than a generic 'open architecture' requirement, you should even be more specific:

  • Weak: Must support ONVIF
  • Better: Must support ONVIF Profile S
  • Best: Must demonstrate ONVIF Profile S support on the ONVIF official conformance list

As you define it in more detail, you close loopholes (like older versions of ONVIF, claims of ONVIF support, etc.).

Finally, the true test of open architecture is what third party devices a product already supports. Do not be fooled by 'sure we can integrate with other stuff in a few weeks'. To that end, require a list of (5) or (10) third party offerings that the product currently integrates with in production for each category you care about (list 10 IP camera manufacturers or 5 access control platforms, etc.).

What Do You Think?

Agree/disagree. Add more?

I think that you have made a number of excellent suggestions. I could write a book on failed systems integrations I have experienced over the years. A few of the major issues that I have come across include:

  • The two manufacturers that you wish to integrate each offer an API/SDK but neither commits to write the code necessary to make the interface actually happen; both parties expect the other one to do it. End result: systems are "capable" of being integrated, but never are.
  • The level of functionality is seriously degraded when using third-party products. An elaborate spec is written described the features and functions wanted, and then the words "system shall be capable of interfacing with Product A, Product B and Product C". However, when operating with these systems, functionality is often reduced to the level provide by the least capable of all of the systems. This was a common problem with some of the "middleware" (now sometimes called PSIM) solutions that claimed to be able to integrate multiple access control systems under a single platform.
  • Manufacturer issues a long list of systems that they can interface with, but don't specify that if you interface with Product A, you can't interface with Product B or Product C on the same system. This is often found out very late in the project when there is little you can do about it.
  • The interface works at the time the systems are installed, but stops working when software updates for one or more of the underlying systems are issued. Sometimes this is just a short term problem until one manufacturer catches up with the other, other times the interface goes away and never comes back. This can sometime be a result of a deliberate marketing strategy on the part of a manufacturer - they want to sell more of their own products so decide to no longer support products produced by competitors.

Michael, great list!

That goes to show there are a lot of gotchas involved.

On your point about neither manufacturer committing to do the integration work. As an end user, the best way to do deal with this is to either understand this limitation and accept the additional cost (now or later) or specifically require that an integration between product A and B be included in the deliverable. At that point, you have moved beyond simple open architecture into an actual integration.

Good one Michael

Excellent. I can use that immediately. This language will work for access control as well?

Great list Michael. One thing I would add...the interface "works" but is not fully functional. For example, a VMS may claim it works with a particular PTZ but it may only allow viewing and no controls, or the controls may require the use of the arrows on a keyboard instead of a joystick. Latency can also be an issue! We have encountered this and it makes for a very sketchy situation with your customer!

Mitchell, one added point for PTZ, depending on how many users use the PTZ on a given camera, there could be a conflict which would add to the latency of PTZ due to the confusion and neither user may get the FOV they were looking for. So for PTZ specific features, one would be PTZ lock based on role priority or a timeout period.

Dear All,

I think everybody articulated well on this. Few more points from my end

a)Openness to integrate with other OSS/BSS where in it is offered as SaaS

b)Well defined APIs to integrate with standard Cloud platforms- Amazon/Openstack etc.

c)SDK Openness: The most trickiest thing I faced is when we buy we do not need it most of the time immediately but probably after 5-8 years, then comes the issue of support and clarifications. My recommendation, is better has an exclusive tech session with them in the very beginning and ensure it is really OPEN, say for every DLL/functional calls, APIs are well defined and the code is integrated with 3rd party systems.

I've seen a lot of RPFs lately that require specific 'open' protocols such as BACnet etc. If you can get your hands on a public university RFP over the last year or so, pretty much all of them I've seen lately seem to have had a lot of time put into defining open.

Nick, but how much detail do they go in specifying 'open' protocols? We are reviewing a few right now (UK, comes to mind) and they are quite vague about what openness means.

Usually when I've seen it specified, they basically have an 'umbrella' system for commissioning and monitoring all the various building systems. This system will communicate with BACNet, LonTalk, and some other less common ones. I was looking for the specific language but am running out of time before I need to run to a job site, but the spec usually says something to the effect of 'Access control system will be capable and sending and receiving information using at least one of the following protocols: BACnet, LonTalk. System will be required to communicate with (brand name) commissioning and monitoring system, and will both take commands from the system as well as provide information to the system on a constant basis."

The security industry is still a lot like what we'd have if IP addresses weren't regulating. You'd have some systems operating on IPV4/6, and some operating on the system used in China, others on the Indian system, and so on, and things wouldn't talk very well together (if at all). What we don't really have now coming from the security is a global standard, but at least there are common protocols available for use.

Also, while I don't think this is a good option I'll mention it anyhow, but pretty much anything (anything to my knowledge) in terms of access control that runs off a mercury board can be taken over by other software.

With that said, that really isn't a forward-leaning way to go if you're specifying the best options available now in terms of openness.