The Switzerland of standards

The folks at Milestone today pointed me to a blog entry by John Blem, their CTO, regarding this whole standards issue that's been getting a lot of attention (from me, anyway), with the PSIA, SIA, and ONVIF (Sony-Axis-Bosch) initiatives.

I'm going to ignore for a moment that he's linking to John Honovich's standards post and not one of mine (look how big a person I am (actually, you all know how petty I am. Who am I kidding?)) to get things started, and point out a few interesting things Blem has to say about the whole situation. Why do we care what Milestone thinks? Well, without throwing my weight behind anyone (and I'm pretty skinny, anyway), I have to say that I hear more often about Milestone's "openness" than anyone else's. That's just a fact.

So, here goes:

Almost daily, I get questions with regard to standards being set on the camera or hardware side. Specifically, asking me why Milestone as an open platform company is not leading the charge for one of these standardizations. My answer is always the same: As an open platform software provider, we will adopt any standards emerging, but obviously we do not want to take sides when we plan to support everything. It is more important for us to follow all these standards instead of creating them.

But, jeez, doesn't that cost Milestone an awful lot of money, having to constantly adapt to all of the new ways of sending information about? Wouldn't the company be well-served if there was one universal way of communicating? And I guess there's another implicit argument here as well: That there is a need to take sides. Theoretically, there could be one universal standards body that everyone got behind and there wouldn't be a need to take sides. And, also theoretically, if Milestone was active in that one universal body, wouldn't that help provide it validation? Couldn't taking sides also end the sides-taking? I'm not sure about the answers to those questions.

Then John goes into a well-reasoned discussion of who benefits from standards and why. I agree with about 99 percent of it so I won't reproduce it here. Just go read it.

Done with that?

Okay, back to the blogging:

On the analytics side, you see standards being driven as well. I cannot be sure of the motivation, but the stance that Milestone takes on this is that you cannot standardize something that has not been invented yet. What I mean by this is that the sheer speed of innovation on that particular side is moving so rapidly that it is impossible to standardize everything at this point. Eventually, I think we will see a polarized market in both the analytic and camera side where we have value-driven products versus price-driven products. This will ultimately lead to a subsequent shakeout in the market.

I agree with a lot of this, but I think this is where the standards talk often gets confusing for integrators and end users and I think there's a point to be made here. Sure, analytics are still very young and I agree that you can't standardize before the largest part of the innovation happens, but I don't think using standards (here being equated with price-driven) and having differentiating features (value-driven) are diametrically opposed. I've had it explained to me a couple of times that, for example, you can use standard H.264 encoding that could be played back on any Qucktime viewer, but that doesn't limit you from having all kinds of cool features that appear in your playback and not in other people's playbacks. So, you're using a standard way of communicating, but you have better stuff to say than other people. We're standardized on the English language, in general, but some people are better talkers/writers than others, right?

I don't think that's as bad an analogy as it might initially seem.

One could wonder, however, why companies claiming to seek a global standard do not join an already established standards committee instead of launching a competing one. To me, it seems contradictory to have several standards driven at the same time when the overall message is that there should be a common standard. Maybe it is more important to be in the driver seat instead of trying to get as many companies as possible represented under one common standard committee?

Well, I think maybe John has Bingo here, but it's also still very early in this process. It's not impossible that these competing (and only we observers say they're competing - it's not necessarily true they're working at cross purposes) entities will eventually come together to work out the best standard for the industry as a whole. That's kind of where I have my hopes pinned.

I'll be seeing ONVIF's news at Essen next week, so stay posted.

Now the IT guys are paying attention (is that a good thing?)

Cisco's increasing activity in the physical security space is, predictably, drawing the attention of traditional IT media. Sometimes, they have something interesting to offer on a story, sometimes they muddy the waters.

With this story, I think they muddy the waters.

The actual content of the IT World Canada story is mostly fine, it's the title that's dead wrong:

New standard to unite physical and IT security

Wowzer! That would be awesome!

But they're just talking about the PSIA (see discussion below and details here) and their device discovery API. How does something that lets video cameras integrate with video management systems "unite physical and IT security"? It doesn't, and I suspect the author of the story knows that, since it's not mentioned in the story at all, and some editor just slapped on an incendiary headline. Oh well. That'll happen.

Still, this is the kind of confusion that can be created when industries that have long been separate start to come together, and it's important to define terminology and nomenclature early. By my definition, IT security is making sure no one messes with your network - firewalls, passwords, content filtering, network access, etc. There's no way that Cisco's cameras easily integrating with Genetec's video management software is going to have anything to do with someone hacking your network and stealing your data (or, for that matter, making sure someone doesn't hack your network and look through your cameras).

Also, by the way, even the PSIA will tell you that what they've got to offer is a specification, and not a standard. There's a difference. Jeez.

What can we learn from IT standards processes?

I found an interesting article in today's Times about IBM throwing a bit of a hissy fit because a standards discussion was not going its way. Essentially, IBM is threatening to bail out of certain standards bodies unless they change the way they go about their business.

For example,

Microsoft submitted OOXML to the ISO under a so-called Fast Track process, which some opponents believed was too rushed and resulted in a poor-quality standard. Many countries and technical experts questioned the need for another standard document format.

Similarly, people are labeling the PSIA (no, not the Professional Ski Instructors of America; the Physical Security Interoperability Alliance. Geez) the "Cisco Group," and expressing similar concerns, because the essentials of its first recommended specification (I'm going to get to the difference between a specification and a standard) came from a document supplied by Cisco.

And this is why this standards discussion can get so murky.

First, the difference between standards and specifications: A specification is a way of doing something issued by an industry group or manufacturer that's kind of like a recommendation or a theory on the best way of doing things. That specification only becomes a standard when an accredited body, like an IEEE or ANSI, vets that specification, puts it through its paces, and then issues it as an accredited standard.

Second, the murkiness: Say you're a big manufacturer who'd like to get on this whole "open standards" wave, but would still like to retain its dominance in the marketplace, which was attained through a semi-proprietary way of doing things. Wouldn't you submit your specification for a way of doing things to a standards body and try to fast-track it through, so your way of doing things became the standard and all of your competitors had to play catch-up?

And if your competitor did that, wouldn't you, like IBM, cry foul and threaten to take your ball and go home?

So, here are some of the questions: Is Cisco using the PSIA as a puppet, knowing that it's done so much heavy lifting on creating the specification for device discovery that the PSIA member companies would be unlikely to change much and just generally be happy with it? Is the Sony-Axis-Bosch alliance (sorry, I mean the ONVIF) similar to IBM's fuss-making, or are they really the more "open" discussion?

Here's the essence of the IBM position:

IBM's guidelines are based on its belief that open standards increase the range of software products that are interchangeable. Standards prevent one software vendor from capturing a large part of a market by locking users into a proprietary format and limiting their ability to easily switch to another product.

Microsoft has long been accused of dominating the market for office productivity programs due to its use of closed file formats. Microsoft changed course, however, and submitted its OOXML format to become an international standard, which means other vendors could implement OOXML in their products.

But OOXML was criticized for being unnecessarily complex. Also, Microsoft was accused of pressuring countries to support the standard, which left companies such as IBM fuming. IBM is a long-time backer of ODF.

The analogy to security is less than perfect, since the standards are much more developed in IT and security is really just beginning to iron things out, but the potential political situation seems kind of similar to me. Long-time backers of standards are going to resent new positions by old vanguards that, no, really, we're totally into this open standards thing. But that doesn't mean that the old vanguards don't have an ability to write good specifications that would actually be of benefit to the industry.

What's going to be important is that people actually look at the documents being created by the PSIA and Sony-Axis-Bosch (and hopefully it won't come to the point where they're issuing competing specs for device discovery, because that would just seem wasteful) and actually figure out which makes more sense for the security community, and not just side with whomever they're friendliest. That would simply be counter-productive in the long run.

We've talked here not too long ago about the benefits of standards, and they seem legion, but no one said the process was enjoyable.

ASIS, day 3

Much of today's discussion was dominated by standards, especially video standards and the seemingly competing PSIA and Sony-Axis-Bosch video standards groups. I say seemingly because there's a lot that can be misconstrued in the "standards" discussion.

First and foremost, it's not even standards we're talking about. As has been noted often today, anything either group releases will really just be a specification. Without the verification of a standards body like SIA or ANSI, they don't quite reach the level of "standards," even if people talk about the specifications they hope to release in that way.

Second, there's the perception on the show floor that the two groups are competing, and that both groups are competing with SIA in some way, but most conversations I've had with the interested players have seemed to indicate that everyone would ideally like to play together. As evidence, SIA treasurer Rob Hile was named PSIA chairman today, and as for creating a good relationship with SIA, he said today, "I'm personally going to take that on my shoulders."

Are standards a big deal anyway? The are and they aren't. On one hand, just about every major camera company works with every major video management software company, so what's the big deal? Well, both David Bunzel, an originator of the PSIA, and Fredrik Nilsson, general manager at Axis, made the point that software makers like Milestone, Genetec, OnSSI, etc., spend way too much time and energy integrating cameras. What if they never had to spend that money again? Wouldn't that allow those companies to spend much more time and energy on improving functionality and adding features? Seems like a no brainer.

So, no, the industry isn't being dragged down by a lack of standards, but, yes, the industry could be made much more efficient with a solid group of interoperability standards.

I'll have more on this in the next paper.

Get on the standards train (or bus, or whichever mode of transportation is your preferred participation metaphor)

In my most recent editorial, I counsel participation in standards-making processes. Basically, no one knows better how products should operate than those who install the products and have to make them work to satisfy end users. Similarly, if you're involved in a process - dispatch, etc. - you ought to make sure you don't have that process dictated to you by a standards body that doesn't have the appropriate input from those who will be most affected by the resultant standard.

Well, here's a good chance to poke your nose in, even though it's more directed toward manufacturers. SIA (the Security Industry Association - in case you're not up on your acronyms) is exercising considerable muscle and energy in trying to create technology standards and it's my belief that the association will wind up being the de facto standards-making body for the security industry, at least in the short term, before historically IT-focused standards-making bodies might conceivably take over some of the technology standards in the industry.

Anyway, what I'm pointing you to does seem a little dense, I'll admit. Check out this paragraph:

The OSIPS Framework is the foundational standard for the OSIPS family of standards. Since OSIPS is directed at enabling the open integration of so many different types of components, it is essential to establish precise definitions of shared system elements and common means to communicate. OSIPS Framework provides the requisite definition needed to create this goal including interface infrastructure requirements and special interfaces for shared activities such as event reporting, schedules exchange, and other common functions.

I mean, "create this goal"? Still, the comment period is open till Jan. 7, which gives you some time to figure out what this all means and whether you have an opinion.

Read the proposed standard here.

Comment here.

Seriously. Do it.