This is the fifth article in the award-winning “Real Words or Buzzwords?” series about how real words become empty words and stifle technology progress, also published on SecurityInfoWatch.com.
By Ray Bernard, PSP, CHS-III
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.
★ ★ ★ GET NOTIFIED! ★ ★ ★
SIGN UP to be notified by email the day a new Real Words or Buzzwords? article is posted!
Real Words or Buzzwords?
The Award-Winning Article Series
#1 Proof of the buzzword that killed tech advances in the security industry—but not other industries.
#2 Next Generation (NextGen): A sure way to tell hype from reality.
#3 Customer Centric: Why all security industry companies aren't customer centric.
#4 Best of Breed: What it should mean to companies and their customers.
#5 Open: An openness scale to rate platforms and systems
#6 Network-friendly: It's much more than network connectivity.
#7 Mobile first: Not what it sounds like.
#8 Enterprise Class (Part One): To qualify as Enterprise Class system today is world's beyond what it was yesterday.
#9 Enterprise Class (Part Two): Enterprise Class must be more than just a top-level label.
#10 Enterprise Class (Part Three): Enterprise Class must be 21st century technology.
#11 Intuitive: It’s about time that we had a real-world testable definition for “intuitive”.
#12 State of the Art: A perspective for right-setting our own thinking about technologies.
#13 True Cloud (Part One): Fully evaluating cloud product offerings.
#14 True Cloud (Part Two): Examining the characteristics of 'native-cloud' applications.
#15 True Cloud (Part Three): Due diligence in testing cloud systems.
#16 IP-based, IP-enabled, IP-capable, or IP-connectable?: A perspective for right-setting our own thinking about technologies.
#17 Five Nines: Many people equate high availability with good user experience, yet many more factors are critically important.
#18 Robust: Words like “robust” must be followed by design specifics to be meaningful.
#19 Serverless Computing – Part 1: Why "serverless computing" is critical for some cloud offerings.
#20 Serverless Computing – Part 2: Why full virtualization is the future of cloud computing.
#21 Situational Awareness – Part 1: What products provide situational awareness?
#22 Situational Awareness – Part 2: Why system designs are incomplete without situational awareness?
#23 Situational Awareness – Part 3: How mobile devices change the situational awareness landscape?
#24 Situational Awareness – Part 4: Why situational awareness is a must for security system maintenance and acceptable uptime.
#25 Situational Awareness – Part 5: We are now entering the era of smart buildings and facilities. We must design integrated security systems that are much smarter than those we have designed in the past.
#26 Situational Awareness – Part 6: Developing modern day situational awareness solutions requires moving beyond 20th century thinking.
#27 Situational Awareness – Part 7: Modern day incident response deserves the help that modern technology can provide but doesn’t yet. Filling this void is one of the great security industry opportunities of our time.
#28 Unicity: Security solutions providers can spur innovation by envisioning how the Unicity concept can extend and strengthen physical access into real-time presence management.
#29 The API Economy: Why The API Economy will have a significant impact on the physical security industry moving forward.
#31 The Built Environment: In the 21st century, “the built environment” means so much more than it did just two decades ago.
#32 Hyper-Converged Infrastructure: Hyper-Converged Infrastructure has been a hot phrase in IT for several years, but do its promises hold true for the physical security industry?
#33 Software-Defined: Cloud-computing technology, with its many software-defined elements, is bringing self-scaling real-time performance capabilities to physical security system technology.
#34 High-Performance: How the right use of "high-performance" can accelerate the adoption of truly high-performing emerging technologies.
#35 Erasure Coding: Why RAID drive arrays don’t work anymore for video storage, and why Erasure Coding does.
#36 Presence Control: Anyone responsible for access control management or smart building experience must understand and apply presence control.
#37 Internet+: The Internet has evolved into much more than the information superhighway it was originally conceived to be.
#38 Digital Twin: Though few in physical security are familiar with the concept, it holds enormous potential for the industry.
#39 Fog Computing: Though commonly misunderstood, the concept of fog computing has become critically important to physical security systems.
#40 Scale - Part 1: Although many security-industry thought leaders have advocated that we should be “learning from IT,” there is still insufficient emphasis on learning about IT practices, especially for large-scale deployments.
#41 Scale - Part 2: Why the industry has yet to fully grasp what the ‘Internet of Things’ means for scaling physical security devices and systems.
#42 Cyberspace - Part 1: Thought to be an outdated term by some, understanding ‘Cyberspace’ and how it differs from ‘Cyber’ is paramount for security practitioners.
#43 Cyber-Physical Systems - Part 1: We must understand what it means that electronic physical security systems are cyber-physical systems.
#44 Cyberspace - Part 2: Thought to be an outdated term by some, understanding ‘Cyberspace’ and how it differs from ‘Cyber’ is paramount for security practitioners.
#45 Artificial Intelligence, Machine Learning and Deep Learning: Examining the differences in these technologies and their respective benefits for the security industry.
#46 VDI – Virtual Desktop Infrastructure: At first glance, VDI doesn’t seem to have much application to a SOC deployment. But a closer look reveals why it is actually of critical importance.
#47 Hybrid Cloud: The definition of hybrid cloud has evolved, and it’s important to understand the implications for physical security system deployments.
#48 Legacy: How you define ‘legacy technology’ may determine whether you get to update or replace critical systems.
#49 H.264 - Part 1: Examining the terms involved in camera stream configuration settings and why they are important.
#50 H.264 - Part 2: A look at the different H.264 video frame types and how they relate to intended uses of video.
#51 H.264 - Part 3: Once seen as just a marketing term, ‘smart codecs’ have revolutionized video compression.
#52 Presence Technologies: The proliferation of IoT sensors and devices, plus the current impacts of the COVID-19 pandemic, have elevated the capabilities and the importance of presence technologies.
#53 Anonymization, Encryption and Governance: The exponential advance of information technologies requires an exponential advance in the application of data protection.
#54 Computer Vision: Why a good understanding of the computer vision concept is important for evaluating today’s security video analytics products.
#55 55 Exponential Technology Advancement: The next 10 years of security technology will bring more change than in the entire history of the industry to now.
More to come about every other week.
The word Open is usually used in conjunction with other words, most commonly Open Architecture and Open Platform in the physical security industry. They appear in product promotional materials, manufacturer Architect and Engineer (A&E) product specifications, as well as in the system performance specifications of design-build projects.These terms are commonly used in IT and many other fields, and in each field their definitions are adjusted as people apply the concept of “open” to their technology designs and strategies. This is why internet searches on these terms don’t lead to clarity for integrators, consultants, and end user customers of the security industry. There are many valid variations on what these terms mean, but none of them help us if we don’t know and apply the right ones.
At this writing, a Google search for “open system architecture” (including the quotes) provided about 193,000 results—yielding a much wider range of definitions that I had expected. Yet the answers we need are there, buried in a hundred thousand articles and book references. Some of them are pure gold, including the IT definition of Open System provided later in this article.
Clarity for Manufacturers
In the IT world, the degree and nature of “openness” are treated as strategic product considerations, as they do have a significant impact on a product’s position in the marketplace and its value to end customers as well as industry partners. Amazing results have come from ensuring that development teams achieving crystal clarity on these terms, and all getting on the same page. These terms are critically important from the perspective of product business strategy, and there are profit-and-loss case study examples available on the Internet that are very revealing.
But more pertinent to this article, is this tip to manufacturers: you should realize that if your customers can’t explain what these terms mean—as they appear in your literature—then your use of them is meaningless. And if your sales people can’t give meaningful answers, whatever open features you are proud of will work against you.
Therefore, manufacturers and their product development teams need to take a very close at how those terms 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.
System Purchasers, Designers and Providers
Do all manufacturers mean the same thing when they say their product or system is “open”? Definitely not. Can consultants and end users tell you exactly what they mean when they say “open platform” in their specifications? Not when I’ve asked the question. And I have yet to find a product or A&E specification that includes a definition of Open Platform, Open Architecture or Open System in a specification’s PART 1 list of definitions.
As we begin developing and deploying security systems as evolvable intelligent infrastructure, there are several concepts of open system architecture that apply. I have extracted applicable concepts from two definitions are provided to us by Federal Standard 1037C, the Glossary of Telecommunication Terms.
Open Systems Architecture
Definition #1 below is a common telecommunications model describing the important concept of system layer independence – whereby, in this case, the means of implementing each communications layer can be altered without affecting any other layer. an important concept considering the availability of global networking, the advent of truly intelligent buildings, and the pervasive IoT device network that is rapidly evolving.
Definition: Open Systems Architecture
- The layered hierarchical structure, configuration, or model of a communications or distributed data processing system that:
- enables system description, design, development, installation, operation, improvement, and maintenance to be performed at a given layer or layers in the hierarchical structure,
- allows each layer to provide a set of accessible functions that can be controlled and used by the functions in the layer above it,
- enables each layer to be implemented without affecting the implementation of other layers, and
- allows the alteration of system performance by the modification of one or more layers without altering the existing equipment, procedures, and protocols at the remaining layers.
Note 1: Examples of independent layer alterations include (a) converting from wire to optical fibers at a physical layer without affecting the data-link layer or the network layer except to provide more traffic capacity, and (b) altering the operational protocols at the network level without altering the physical layer.
This concept can also be applied to cloud computing system architecture, to enable each subsystem to have its cloud computing resources changed or re-scaled, without impacting the subsystems it interacts with. This design approach allows scaling subsystem resources on an as-needed basis, preventing performance bottlenecks without over-provisioning cloud resources in general.
The layered system design concept is a highly applicable design model for cloud computing as well as for networking, to allow a specific subsystem’s cloud resources to be changed or re-scaled without impacting the subsystems it interacts with.
- Nonproprietary systems architecture.
Definition #2 above is also widely applicable; it’s the architecture common PC workstations and servers.
Applying Open Systems Architecture Concepts
It is important to realize that high-level design for our security systems will, very shortly, need to integrate with a multitude of external systems and devices that will provide real-time information and real-time control that extend outside of the traditional boundaries of our security system deployments. Device and system products that are “open” (which we’ll consider more closely below) will be required to build the kind of security system infrastructures appropriate for today’s world.
IT World Definitions of Open
There are definitions of Open Architecture and Open Platform that are applicable to security industry technology because todays security devices and systems are based on information technology (computing, database, networking and user interaction technology).
Definition: An architecture whose specifications are public. This includes officially approved standards as well as privately designed architectures whose specifications are made public by the designers. The opposite of open is closed or proprietary.
The great advantage of open architectures is that anyone can design add-on products for it. By making an architecture public, however, a manufacturer may be allowing others to duplicate its product.
Definition: In computing, an open platform describes a software system that is (a) based on open standards, such as published and fully documented external application programming interfaces (API) based on protocol standards and that (b) allow using the software to function in other ways than the original programmer intended, without requiring modification of the source code. Using these interfaces, a third party could integrate with the platform to add functionality.
Only the first part of this definition applies to current security industry systems that are being labelled as Open Platform. PSIM (Physical Security Information Management) products utilize existing security products and platform that conform to the first of the Open Platform definition above.
An open platform of this type implies that the vendor allows, and perhaps supports, the ability to create new functionality and to use the platform in ways not previously conceived. Using such an open platform, a developer could add features or functionality that the platform vendor had not completed or had not conceived of.
A service-oriented architecture (SOA) allows applications, running as services, to be accessed in a distributed computing environment, such as between multiple systems or across the Internet. A major focus of Web services is to make functional building blocks accessible over standard Internet protocols that are independent from platforms and programming languages. An open SOA platform would allow anyone to access and interact with these building blocks.
Despite the limitations of existing security systems technology, there are some bright minds that are thinking along the lines of the second part of this definition in order to create innovative security products.
Open Products and Systems
There are several definitions of “open” that apply to security products and systems, and it is possible to reduce the resulting confusion by categorizing and ranking them in a way that enables better security system design thinking and planning. Thus, I developed the scale below for ranking the open capabilities of products and systems. Note that even a highly proprietary system can still be open in ways that are valuable.
Customers, consultants and integrators should nudge vendors in the direction of being “open” based upon the security operations capabilities that such development would provide. Product advancement can be envisioned using the scale below.
Each level of ranking includes one version or another of the levels below it. Note that this is intended to be a simple and practical scale, and so it is not complicate by other possible rating factors such as cybersecurity capabilities, which are also important but can be evaluated independently of the openness factors.
An Openness Scale
- Evolvable Interaction. A device or system whose providers or end users can define, configure and set up two-way interaction with other systems using only the system’s front-end user interface, enabling users to vary and expand the interactions as their technology infrastructure grows and evolves.
- Interaction by Design. A system structured to encourage interaction by other systems.
- Available to any provider or owner using standards-based protocols.
- Available to any provider or owner using proprietary but well-documented protocols.
- Available only to licensed partners using standards-based protocols
- Available only to licensed partners using proprietary protocols
- Two-Way Interaction. A device or system designed to allow two-way interaction with other products and systems.
- One-Way Interaction. A device or system designed to allow one-way interaction with other products and systems.
- Not designed for interaction with other products or systems.
Use this scale to rate your existing security system infrastructure, as well as the new products that you encounter.
Example of Good Documentation
One example of good documentation is Milestone’s Open Platform page describing exactly what Milestone means by Open Platform. It’s great when manufacturers also go one step further than documentation, by providing training and engineering support for integration projects, which is usually done as part of a partner program.
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 (www.go-rbcs.com). 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.