Real words or buzzwords?: Enterprise Class - Part 2

May 30, 2017
How the physical security industry's definition of an enterprise grade system compares to the IT world

Editor’s note: This is the ninth article in the "Real Words or Buzzwords?" series from contributor Ray Bernard about how real words can become empty words and stifle technology progress.

The scope of the term "Enterprise Class" is of sufficient breadth and depth that it requires three articles to cover it. The first article looked at the technology trends having the greatest impact on what Enterprise Class means today. The term Enterprise Class (a.k.a. Enterprise Grade) appeared first in the IT domain, and was used to label just about any information technology that had requirements beyond the scope of single-user and small-user-group application. It is a marketing term that asserts a product or system is reliable enough and capable enough to handle the needs of organizations of any size and geographic distribution.

For example, a small group of users manually encrypting documents one-at-a-time to exchange with each other is one thing, and can have its own complications. Providing policy-based document encryption/decryption across a wide spectrum of a large corporation’s critical documents is quite another challenge, requiring secure document management systems that can keep pace as technology evolves, support a variety of encryption requirements, be easily used by people with little to no technology familiarity beyond a word processor or spreadsheet, and include many other features beyond encryption capabilities.

Sometimes the word "Enterprise" is the top label among several given to sets of product features and capabilities, such as Basic, Professional, Team, and Corporate. Often these labels are retrofit onto existing product capabilities in the hopes of attracting more customers in each category. It doesn’t necessarily mean that the top-of-line product was designed to support all or even most of the needs a large enterprise may have.

Industry Technology Adoption

Historically, when the physical security industry has adopted information technologies, that adoption is incomplete. Often the technology understanding is shallow rather than deep, narrow rather than wide, and very often technology is adopted without accompanying technology practices. For example, the industry began putting systems onto networks in the 1990s, but didn’t develop and publish an industry standard for MIBs until 2015. Only IT companies with physical security products, such as Axis Communications, provided MIBs for their products until recently. MIB stands for Management Information Base, and it refers to the documentation for the information available from a networked device using queries and alerts per the Simple Network Management Protocol (SNMP).

This is an example of why IT terminology adopted by the physical security industry often does not carry forward the full meaning that is has in the IT domain. So let’s first take a look at the common scope of enterprise class requirements in the IT world, and then see what occurred in our industry. 

Enterprise Class Requirements

In enterprise class systems, organizational requirements must be considered in addition to individual user-task requirements. For a technology to be feasible for deployment at a large scale, the dynamics of system size and function combine with organizational needs to create a very large set of requirements. Requirements vary across different types of technologies, but the basic enterprise-class information systems requirements include:

  • Availability. This means more than just 24/7 product or system use. Enterprise-wide availability can require multiple languages, 24/7 tech support, and integration with a variety of regional systems whose product versions may vary significantly. It can require Application Programming Interfaces (APIs), as more and more, users are not just people but also other systems, and some users need custom and advanced capabilities that can only be obtained via custom software development (in-house or outsourced) enabled by an API. For example, for real-time and near-real-time systems, it means taking time zones into account. Enterprise systems that have workflows that involve review and approval, may need workflow routing options that include alternate recipients, to account for people on vacation, sick leave, business travel, unavailable on special assignment, or even just taking personal time off. Availability in context may require accounting for such real-world conditions. In general, availability being available at all the times and in all the ways required not just for the application to perform, but to allow users to keep performing as well within their enterprise context.
  • Business Alignment. How well does the application fit into the company culture and operational context? If it is a highly collaborative organization, does the application support the required collaboration, or are third-party tools needed or out-of-system workflows required? Parks and recreation operations are different from hospitals and manufacturing companies. Does the system act as a force multiplier, allowing fewer people to get more work done more reliably, quicker, and to a higher quality? If not all those factors, which force-multiplier effects are provided?
  • Compatibility. The word compatibility covers a very large landscape, two key categories of which are: System – referring to operating platforms and interoperability with various devices and systems, and Data –data formats, database integration capabilities, data exchange capabilities (including speed and volume of transaction processing). Legacy compatibility is another perspective. Standards play a large role in system, device and data compatibility.
  • Manageability. How manageable is the deployed technology? How easily can it be upgraded? How much training is required and what does a typical learning curve involve?
  • Performance. Does it meet the speed and capacity needs required for its users and operational results stakeholders to be satisfied? How current do dashboards need to be: daily, hourly or up-to-the-minute? How fast can data distribution occur?
  • Reliability. Can the system be counted on to perform exactly as it is supposed to when being fully utilized? Are there audit trails and logs to verify? What are the options or alternatives in case of any type of failure?
  • Security. From one end of the system to another, are the integrity and privacy of data maintained at all points throughout the system?  Can the system be sufficiently protected given the risk profile, both technical and organizational, of the enterprise?
  • Scalability. The scalability issue involves maintaining all the above attributes at large scale, which includes high user count, high data processing loads, and high communication levels. To what scale has the system been proven to maintain high performance for the key customer categories and the ways in which their system usage typically varies?

Enterprise in the Security Industry

In the physical security industry, the original objective for Enterprise Class for physical security systems started with a focus on these capabilities:

  • Company-wide networking. All site security systems could be networked via the customer’s enterprise network.
  • Central administration and operations. The main security administration functions and security operations functions, such as monitoring, could be performed centrally.
  • High Availability. Local and central systems will stay online and communicating with extremely low downtime.
  • Multi-Language. Limited multi-language support was provided on a per-operator basis, with the capability for language expansion, including user-provided localization.   

Many companies did achieve those objectives, but unfortunately progress seemed to stop there, mainly because the required IT practices were not adopted, leaving systems integrators to the impossible task of trying to make up for the lack of proper technological support. The built-in features required to support troubleshooting and management of enterprise size systems are still generally lacking.

For example, how do most customers with hundreds or thousands of security cameras get their firmware updated? Can they use an automation approach like IT does with large computer deployments? No, and the result is that updates are infrequent and sometimes non-existent. Is cybersecurity protection common for internet-connected cameras? Also a No. Thus, the latest, and to date the largest, botnet attack was enabled by malware-infected cameras.

Why, in many large corporations, do security investigators report that 10 to 20% of the time they can’t find video that should have been recorded? Can you call it an enterprise class system if the customer assigns operators to manually check cameras and report those found to be offline?

A True Enterprise Perspective

Enterprise requirements should be viewed from the perspective of high task and workflow support for users, strong business alignment, and full support for the “IT way of doing things.” It must include fully understanding and utilizing product design, development and deployment practices. It should not be a case of deciding what’s the minimum that must be done to use the enterprise class label, but what’s the maximum that can be done to support security operations and technology infrastructure maintenance in enterprise-scale deployments.

The Full Scope of Enterprise Class

Space does not permit an in-depth evaluation of all the requirements that makes security technology solutions enterprise-ready. However, the next article in this series does contain a checklist that integrators, specifiers and end-users can use to evaluate and compare offerings that are labeled "Enterprise Class," and take enterprise-class thinking to a level where it should be.

About the Author:

Ray Bernard, PSP CHS-III, is the principal consultant for Ray Bernard Consulting Services (RBCS), a firm that provides security consulting services for public and private facilities ( He is the author of the Elsevier book Security Technology Convergence Insights available on Amazon. Mr. Bernard is a Subject Matter Expert Faculty of the Security Executive Council (SEC) and an active member of the ASIS International member councils for Physical Security and IT Security.

About the Author

Ray Bernard, PSP, CHS-III

Ray Bernard, PSP CHS-III, is the principal consultant for Ray Bernard Consulting Services (, a firm that provides security consulting services for public and private facilities. He has been a frequent contributor to Security Business, SecurityInfoWatch and STE magazine for decades. He is the author of the Elsevier book Security Technology Convergence Insights, available on Amazon. Mr. Bernard is an active member of the ASIS member councils for Physical Security and IT Security, and is a member of the Subject Matter Expert Faculty of the Security Executive Council (

Follow him on LinkedIn:

Follow him on Twitter: @RayBernardRBCS.

(Photo courtesy
Several security industry companies have asserted that network-friendly meant 'works well over a network,' but their concept of 'works well' was too shortsighted. It is one thing to work well when three devices are talking on a benchtop network. It’s completely another to work well in a corporate network environment with hundreds or thousands of active devices connected.
(Image courtesy
Manufacturers and their product development teams need to take a very close look at how the term 'open' should be applied not only in the design and development of products and systems, but in the explanations that they provide to sales people, channel partners and customers.