Software and Beer: Steve Mitchell's Blog

Non-consumers

February 8, 2012 Leave a comment

Ask a business owner 30 years ago if he’d pay for cell phones for their employees and they’d ask, “what’s a cell phone?”

In 1982 the business market for mobile devices didn’t exist yet. This is for two reasons. One, the technology wasn’t there to make portable communication devices practical. Two, since the technology didn’t exist, the market didn’t know it existed yet either.

Or did it?

Of course, mobile communication devices existed since the first Marconi wireless was installed on board an ocean going vessel early in the last century. So the market for wireless communication was actually very old, matured, and all-played-out by 1982, right? If wireless communication is nothing new, why is the cell phone and now the smart phone such an obvious revolution in just the past 5 years?

The answer is less in the technology–although the steady, mostly incremental advances in technology are an enabling substrate–but rather in the emergence of new markets from a base of what Clayton Christensen calls “non-consumers.”

The “non-consumer” is a market made up of people that currently consume nothing to satisfy a need they don’t know they have.

And before you scoff at the idea of selling people worthless stuff they don’t know they need, think again about the business utilization of the cell phone. Thirty years ago we were faxing memos to each other (if we were sophisticated enough for that kind of technology). But today we sit on conference calls on our cell phones, tap out emails and texts, and operate our businesses via smart phone apps at a blistering pace. Today businesses find their mobile devices to be as indispensable as their trucks, factories, and employees at earning revenue and keeping the wheels on their operations.

This analogy is too easy. It’s so obvious it’s boring. What’s a more challenging analogy then? Let’s say social gaming. Social gaming is such a good example because it’s so pointless. This because it’s easy to forget how many people in the 1980’s told us that the “cell phone” was a waste of time and money.

Take a look at the interactive chart on A Brief History of Computing Platforms. Keep in mind that the scale on the left is logarithmic. So numbers (volume shipped) of the floating dots towards the top of the graph are very very large. The lesson learned from this graph? The iPhone/iPad and Android are the most successful computing platforms in the history of personal computing, and have emerged as such in just the last few years.

One could argue that there were technology advances that made this possible, and they’d be right. But no single technology like the touch screen, or lighter, longer lasting batteries, or smaller memory and CPU, or better wireless chipsets is responsible for this growth.

What’s responsible for the explosive growth of these new computing platforms is their entry into markets of non-consumers. Think about that. What’s responsible for the largest growth of the emerging dominant personal computing platform is not the advancement of its technology but rather its ability to find new customers. And these are customers who were (as far as they knew) completely satisfied by the status-quo at the time.

The smart phone didn’t displace any single device that came before it, even though many preceded devices are now irrelevant. Rather, it ventured into new markets of non-consumers who didn’t know they needed what was possible until they were presented with the offer and they found it satisfying.

You can scoff at social gaming, but it is one of many reasons for the meteoric growth of these platforms. And it’s an excellent example of the non-consumer in action. Simply because it’s not obvious (even today), and its significance was not predicted.

Think back ten years ago to a world in which social gaming didn’t exist. The social networks existed in the form of chat rooms, web forums, and some budding social networks. On-line gaming existed, of course. But the confluence of capable mobile devices, wide reaching social networks, and creative game platforms needed to come together to discover an untapped market of non-consumers.

The reason I’m writing about all this is because as somebody who’s supposed to say something about innovation in a large company, I believe it’s important that we recognize the significance that the non-consumer pattern has played in history of business and culture in general.

The fact is, if you want a company to grow, you’ve got to plan beyond capturing the biggest piece of the pie in your existing markets and consumer segments as defined by industry analysts and your industry in general. You’ve got to match up what’s possible as the state-of-the-art advances with the non-consumers.

So in the video surveillance business, we’ve got to wallow in the technology. We’ve got get its stink all over us and wrap our brain around what’s going to be possible and practical in the next few years. Then we’ve got to think about people who are not using video today. Yes, non-consumers. People who will never bother to call a “security” integrator in their life–because as far as they’re concerned they don’t have any security problems to solve. We’ve got to think about the businesses who are spending money solving problems in ways that newly minted video technology (probably combined with other emerging trends) might solve better, faster, or cheaper.

The real breakthroughs will come when we discover ways to make money doing things that are as different from video security today as social gaming is from the cell phone 30 years ago.

Filed under Innovation

Skeuomorphs

February 2, 2012 Leave a comment

Brent Aurenheimer posted a great article on Google Plus about Skeuomorphs — a derivative object that retains ornamental design cues to a structure that was necessary in the original. Analog Designs in the Digital Age

Examples of Skeuomorphs are things like slider buttons on GUI displays, or fake spokes on a hubcap. It’s interesting to think about how design of analog systems influence digital systems.

A lot of video surveillance system design is influenced by the model of the analog matrix switch. In an analog system, the “data” being handled is really an NTSC/PAL analog signal. Many signals flow through a switch then out to recorders and/or displays.

Unfortunately, today’s digital systems tend to recreate this model. Camera IP video stream into some VMS software responsible for laying bits down linearly on disk or putting them up on displays as needed.

A truly digital system could approach video in terms that make more sense to the end user and the problem being solved.

One good way to handle video might be in discrete events because this is the mental model of the real world that people care about. So rather than streams being wired to recorders or displays, discrete events are captured and passed around as needed.

This is made even more powerful when contextual metadata is associated with the events–which also ties them more closely to the problem domain. So, for example, if there exists a discrete video event in my system showing a check-out line, and that is associated with a cash drawer transaction, I can query the system to find the video associated with a return or a sale greater than some dollar amount for audit or review.

Events tend to be approached from a few different perspectives, usually based on what the end user knows about real-world events at the time they approach the system. For example, when the house across the ally from mine was robbed, the police asked me for the video from the cameras in my home system for the hours between noon and 2PM–because that’s all they knew about the event.

Certainly there’s nothing wrong with a simple strategy that says you lay down all the video, then index it by overlaying metadata of real-world discrete events. We already do this with the timeline, which is sufficient for the police example, above.

But this misses an opportunity presented by distributed systems where video might be recorded on-camera vs on-NVR vs on-Cloud. Or highly distributed systems–for example, DVRs in many small retail sites that are centrally managed by a regional loss prevention manager.

The gist being, we should question the “video stream” as a potential skeuomorph and try thinking about discrete real-world events as first class citizen within digital video system design.

Filed under Innovation Tagged with innovation

Death by a Thousand Features

August 30, 2011 Leave a comment

[The following is a memo originally written by our CTO, Greg Millar some years ago. I've edited it slightly to remove any proprietary bits. I am publishing it here with Greg's permission and for the general benefit of the product development community.]

Abstract

When and how does a feature set for a product get defined? What is important to include and more importantly, what is important to leave out? This article discusses the need to have a clear vision of what makes a product have high utility early in the design cycle. It also covers the development costs of adding incremental features. The bottom line is to pick the right small subset of features that matter to the customer most and make them near perfect. Everything else should be sacrificed to shorten time to market.

This weekend I was reading the April [2008] Issue of IEEE Spectrum and two short articles caught my attention. The first was a book review of The Design of Future Things: By Donald A. Norman and the second was on Zipf’s Law. Although each was interesting, the combination of ideas presented in these two short articles seems to directly apply to intelligent product design.

First I will boil down the articles. In The Design of Future Things Donald Norman talks about how often “intelligent” systems behave differently than users expect, and thus that unexpected behavior makes those products seem less than intelligent. Good product design should augment or enhance the desire of the user, not second guess it. In our world that could be presenting several clips of video thumbnails from a search and let the user identify the best one.

The second article is about Zipf’s Law which states that the distribution word usage of English words follows power-law statistics:

“The most common word, the, is used twice as often as the second most popular word (of) and three times as often as the third (and). Similarly, the nth most popular word has a relative frequency of use of 1/n.”

Likewise so do a lot of other things in natural and manmade systems.

The thought occurred to me regarding design and features and focus in regard to this phenomenon. Let’s just talk about software features. Any software package contains a set of features which only a few are used most of the time. (I heard a story once that the vast majority of feature requests for MS Word are fulfilled by the features that are already in there. Users just don’t know how to get to the feature.) So in Word that might be: entering text, simple formatting, printing, spell check. And indeed these features are pretty easy to get to (OK, the formatting stinks). On a DVR those basic features are: viewing live video, reviewing recorded video, exporting video. Everything else falls on the “long tail” of features.

So how does that affect software and system design? First it must be recognized that any feature included in a system must be spec’d, designed, implemented, and tested before it ships. This is true of the most often used feature as well as the nth most used feature. Given that there are never enough resources to implement every feature requested it might seem a waste to apply scarce design, development and test resources for features that may never or seldom get used. Likewise, it seems wise to apply more than the average amount of work on the features making up the “top 10” used features of a product so that they are as near perfect as possible.

Scaling of Effort

Let’s look at this quantitatively first. As the number of features/functions increase the amount of work to complete those features increases at least linearly (see Effort chart). This is true as long as each feature takes the same amount of effort to implement, test, etc. Of course this is not always true, but turns out to be a good enough estimate for the average case. Furthermore it can be rationally argued that as the number of features increase that the amount of work increases more than linearly (see Effort chart again). This is because of the interactions (intended or not) of the features, the increased number of transactions between developers and the eventual throwing away of uncompleted work at the end of the project due to time constraints and the desire to hit the ship date.

Product Utility

If feature usage is distributed by a power-law (and this seems intuitively right) then we can predict the amount of work required to deliver a measure of functionality. That is if the most used feature is used with a utility of 1 and the second most used feature is exercised with 1/2, the nth with 1/n and so on and so forth, then we can show graphically how the feature usage is distributed in the next chart.

As can be seen the incremental utility of a feature is shown in red and decreases rapidly. The long tail of incremental utility is the enemy of efficient product development. The total or cumulative utility is determined from the integral of the incremental utility line and is shown here in green. This plot is normalized to 100 and therefore the scale is arbitrary. Even so, 50% of the utility is achieved with just 7 out of 100 features implemented. It takes an additional 14 features (or 3X the features) to achieve an additional 20% utility, 80% utility is had with 35 features and 90% with 59 features. In reality this overstates how many features you need to achieve some state of utility since it is widely understood that adding more features can undermine the utility of an application due to increased complexity and decreased ease of use.

Return on Development Investment

Now let’s plot the cost of these incremental features. We will compare the linear and non-linear effort with the cumulative utility. In other words, how much does an incremental feature “cost”. This cost is important in absolute dollars or perhaps more important in opportunity cost of perfecting a more important feature or moving the development resources onto the next project.

This last chart (Utility Return on Development) shows the utility return (how much incremental utility can be added to an application) for a given amount of development resource. Two plots are shown, one that corresponds to the simple (but unlikely) assumption that in order to add 2X features you require 2X engineers/testers, etc. This is shown with a heavy light blue line. This shows that the last feature added (100^th) has a return of 5 vs a return of 100 for the 1^st feature added. In other words it can take 20x the resources to add a given amount of marginal utility. It is even worse for the more conservative approach of non-linear effort ― in this case we show a better than 60x increase of effort to add a given amount of marginal utility.

Conclusions

If a company has an aggressive roadmap and product plan, it would be prudent to pay a lot of attention to not only which products are selected for development, but what features are included in those products. All of this analysis assumes that one is able to 1) sort features by the amount of utility they add to a product and 2) intelligently chose the cut-off line for those features to implement early in the development cycle. Waiting until the end of the development cycle to determine the cut-off line wastes valuable development and test resources.

A well worn example of this type of thinking is evident in the Apple iPod. The iPod was first delivered in 2001 with a very minimal feature set compared with the other MP3 players then on the market. Some examples of its limitations at first launch:

it only attached to Macintosh computers
it did not (and still does not) play Windows audio files (WMA)
it had a simple text UI
it used FireWire (IEEE 1394) as its connection to a computer
the host application (iTunes) did not support any other MP3 players (still doesn’t)
it was expensive
its memory was not expandable (still isn’t)
its battery is not user replaceable

Apart from these intentional “shortcomings” the iPod had a series of issues that caused a lot of grief:

the battery life was far shorter than the stated spec from Apple
3rd generations iPods had weak bass response
a 13.7% failure rate in 2005, higher for HDD based units

It did however solve some key user problems that other MP3 players did not:

it was very easy to operate
it was very easy to transfer music from a computer to the iPod
it held a large number of songs (initially 1000 songs on a 5GB drive)
it had a simple design and look

Why was it a success? Because Apple understood the needs of the end user, they understood the limitations and poor design choices of the competition and they focused all their effort on a very simple design. Apparently their well established competition (Creative Labs, Sony, others) did not. They continue to this day to dominate the portable music player market with a 70% unit market share and a 84% $ volume market share. Apple is now struggling with what has become essentially a replacement unit market. Most of the growth is gone. Microsoft’s Zune has been a very public failure gathering only 4% of unit sales. Second place SanDisk has 11%.

Filed under Development, Innovation

Video Delivery Over Public Internet

August 23, 2011 Leave a comment

Akami has nice whitepaper on delivering video over the public internet. While this is about 1-n broadcast delivery, and might just be an Akami ad, we’ve found that many of the complexity issues they raise are valid.

http://www.akamai.com/dl/technical_publications/network_overview_osr.pdf

Filed under cloud

Analytics Validation at HCI International 2011

December 2, 2010 Leave a comment

Do video content analytics work? That’s a raging question in the video surveillance industry. Personally, I know it’s amazing technology. But I also feel that its delivery to market has set the expectations incorrectly about what it’s good for, how it should be deployed, and what it’s worth (both as an enterprise and value to the customer).

Regardless of its positioning in the industry, it’s a fascinating technology to work with. A while back we needed to validate analytic algorithms. Not so much for absolute accuracy, but to protect against regression. We wanted to make sure that changes to products didn’t negatively affect the analytics algorithms behavior, but quickly realized that if we relied only on functional testing, different operators (that is, the test tech who was configuring the analytics algorithm for a test) had different levels of skill at setup, and thus could produce quite different results, even using the same test procedures.

Also, considering that analytics are often applied to mission critical applications, there was a property of “trustworthiness” that we had to convey to the user that the analytic would in fact work as they intended during live operation. In other words, how confident the customer felt about the configuration experience was an important aspect of operation. The big ah-ha came when it was pointed out to us that the user was a component of the system under test, and thus their training was being scrutinized as well as the algorithm. Think of a pilot flying an airplane–the pilot is effectively part of the system.

Eventually we decided to apply strict standards to context of use in testing (which includes the user). We normalized operator training to remove variability (this was preceded by usability testing designed to identify the UI issues that might cause problems with effectiveness, and training was designed to optimize around those issues). We standardized a video clip library to use in testing (in our case, i-Lids). We then adopted guidelines and metrics to use to determine “quality in use” that included effectiveness, productivity, safety and satisfaction (see ISO 9241-11).

Through the use of both functional testing as well as QIU metrics, we are able to deterministically test video analytics with greater confidence.

We wrote a paper about this adventure which will be presented at the Human Computer Interaction (HCI) International 2011 conference in Orlando, Florida in July 2011. I’m looking forward to that publication so we can share more about the details of this method.

Credit is due to Steve Loveless and Sukhpreet Gill for the majority of this work. And to Dr. Brent Auernheimer for his wisdom and guidance in HCI as well as the validation of critical systems.

(I guess credit is also due to Morten Tor Nielsen’s blog, where much of this post originally appeared in the form of a comment to one of his posts.

Filed under analytics

The Barriers to Entrepreneurship

November 30, 2010 Leave a comment

If you spend any time fooling around with the various “cloud” service offerings related to Platform as a Service (PaaS) or Infrastructure as a Service (IaaS) you get the impression not that the impossible is now possible, but rather that the possible is now really really easy. And by easy I mean not just simple to apply, but inexpensive as well.

The early question was “what’s different about this so-called ‘cloud’ thing vs a conventional web site?” And the answer it turns out is (technologically) not much. The Cloud is an architectural style. The fundamental best practices for building web sites have pretty much prevailed since the app-server and the n-tier architecture were distilled out of the client-server and web site architectures back in the late 1990′s. Sure there are new things like NoSQL and Hadoop that have emerged over the past few years. But those really only apply to huge scalability problems–which are still luxury problems for all but Facebook, Twitter, Google, et. al.

What’s different today is how mind numbingly easy it is to tool up, work with, and deploy world class software systems to a world-wide audience of potential customers. Where ten years ago you needed to raise capital just to buy hardware and software to operate your business, now you can rent or leverage free services. Where ten years ago you had to invest in data centers and hire people to build complex systems atop expensive software infrastructure, today you plan to deploy increasingly capable open-source middleware atop highly scalable and easily accessible PaaS providers. And don’t even get me started about accessibility to the mobile platforms in everybody’s pockets (think: Angry Birds).

“Whoa! Hold the phone!” you say. At the heart of any valuable piece of software there’s a difficult business problem, right? And solutions towards that end are non-trivial to develop and solve, right? Yes. But that’s changing too. Not because the problems are simpler, but because its now practical to break them up into smaller more manageable chunks that are easy for your customers to digest. Given how easy it is to consume (say) a service like DropBox, customers are increasingly open to the idea of a single point solution addressing the problem which that system solves–without the need to hire consultants and spend hundreds of thousands on a “comprehensive data management architecture for their storage needs.” Big comprehensive (and expensive) solutions (and their vendors) are being nipped at by a thousand piranha-like start-ups. Each of which solves a problem simply and inexpensively. This is the Software as a Service (SaaS) portion of the equation. The IaaS and PaaS models make it easy to create and deploy solutions, the SaaS model makes them easy to consume.

I’m not presenting any ground-breaking original thoughts here. Just presenting my take on Steve Blank’s blog post entitled “When It’s Darkest Men See the Stars.” Which chronicles how entrepreneurship in the software business has become easier than ever. I’m not sure if it in fact saves us from global economic whoas. And I still think access to customers is a difficult problem unless you’re willing to latch your destiny to the whims of viral marketing. But otherwise, a good read.

Filed under cloud, Innovation

The API and Video Surveillance

November 22, 2010 1 Comment

A couple of weeks ago I sat through a talk on APIs by Justin Kitagawa from GoGrid. He had a great slide entitled “anatomy of an API” that spawned several thoughts that might be worth talking about here.

APIs are the unsung heroes of interoperability within the highly fragmented (IP) video surveillance industry. But most video surveillance practitioners don’t have (nor necessarily need) a thorough understanding of what they are or how APIs work.

Necessary or not, here are the gory details.

History

I’m one of the few geeks who might find a history of computing interesting, so feel free to skip to “An API is a recipe for interoperability” if you’re non-technical.

Back in the 1980’s the client-server model was going full blast. We wrote server software with clients that communicated with the server over the network. We used relatively straight forward techniques to accomplish this.

First, one would write a server. The server contained code that opened a network socket and listened for requests from across the network. When a client connected to the server, the client would send a string of text that consisted of verbs and arguments to indicate some action requested of the server. The server would parse the verbs and arguments, execute code to handle the request, and return some data to the client to indicate the results. Client and server could carry on a complex dialog with back and forth requests and responses. These were good times because we had fun inventing protocols (the specifics of the dialog between the client and the server) and implementing servers. Take a look at the IETF RFC’s for some of the older protocols such as SMTP, POP, or FTP if you’d like to see how these are specified.

Example: A POP3 Sequence Diagram. Source: tcpipguide.com

This technique didn’t scale well, business-wise. For one thing, if you wanted some new functionality, you had to go invent a new protocol, and implement servers and clients. This put the burden of a lot of code on whoever was going to write the clients. Not only did they have to implement your protocol correctly, there was also the problem of marshalling and demarshalling the data that was to be exchanged between the client and the server. You could give people sample code, or provide them with libraries that implemented your protocol (this is an SDK), but this was poor system architecture as it implied tight coupling and low cohesion between the client and the server.

What’s more, writing multi-threaded servers that scale well is surprisingly difficult (interesting, but difficult to do well).

Security is a concern within communication protocols. Many security vulnerabilities that expose a system to attack use a low level protocol as an attack vector. Thus protocols need to be carefully hardened against abuse or intrusion.

Architectural layering in the form of Web Services addressed many of these concerns.

The Anatomy of an Web Service

In the early 1990’s HTTP emerged and it changed everything. This protocol was designed for getting documents off a server, but it provided many building blocks that are necessary for the dialog between a client and server in distributed computing tasks. While it is terse (it provides only a handful of verbs–not the least of which are GET and POST), it provides just enough convention and ubiquity to become a viable building block for implementing similar functionality to what we used to implement in lower level protocols.

What’s more, some great, multi-threaded implementations of HTTP servers quickly emerged, which took a lot of the busy-work and security risk out of writing one’s own server. Reuse of HTTP for the development of different communication protocols had immediate value and its use towards this end exploded.

About the same time that HTTP was taking over the world, XML was emerging as a convenient way to specify how structured data should be represented, and as a format for exchanging data as documents (often across HTTP). This helped with the marshalling and demarshalling problem because now we had conventions and lots of tools at our disposal.

The term Web Services was coined to describe protocols developed using these techniques. These are loosely coupled services that often leverage HTTP and XML.

Now we have the terminology in place to describe the anatomy of a Web Service:

Authentication — Client id, a secrent, signatures, etc.
Transport Method – HTTP or HTTPS
Architectural Style — SOAP or REST
Response Format — XML or JSON

A Web Service will specify this anatomy clearly, and will name whatever underlying protocols are required in adjunct to the Web Service.

In the case of authentication, several options exist, but “HTTP Authentication” is convenient, capable, and common. This also makes sense since HTTP is often used for transport. Authentication helps ensure that unauthorized clients don’t access the server, and when built upon hardened protocols and implementations, can provide a reasonable degree of security.

The choice of architectural style for the web service itself can be controversial. Early standardization efforts grew into the quite elaborate SOAP architectural style. SOAP is a great way to work with complex object ontologies–which is what it was designed for. Services based on SOAP provide ways to specify how complex objects will be represented and exchanged. But it does this with the requirement of some heavy weight programming–which not all programmers are in the mood for.

Many modern web services are implemented in REST as an alternative to SOAP. REST-ful web services tend to be simpler for a programmer to work with cognitively, and can be implemented quickly with less ceremony. Some argue that they scale better–but that might be best stated as they can be more easily implemented in a highly scalable environment.

SOAP and REST have their strengths and weaknesses and their respective supporters and detractors. I’m not going to take sides. But personally I like the idea of Web Services that use SOAP for the complete implementation, and also provide REST-ful interfaces for the most common system integration tasks that programmers are likely to encounter “in the field.” I believe this strategy provides the best of both worlds.

It used to be that response and data formats were text strings, then XML. Now the JSON format is popular due to its terseness and simplicity. Today one finds many REST/JSON based services as alternatives to SOAP/XML based Web Services.

An API is a recipe for interoperability

What I described above is the relatively low level protocol, followed by the higher level anatomy of the Web Service. But APIs are more than just protocols and Web Services. While the definition of an API can be very specific and technical, APIs are really a method for two programmers to communicate with each other through specification.

When I publish an API to my product it will specify to you (another programmer) how you need to write programs that will operate with my software over the network. My “API” may be a single protocol specification, Web Service specification, or maybe it’s an SDK (a programming library) I hand you that you can incorporate in your program which will take care of the communication work for you.

The point being that API’s are a means to achieve interoperability. API’s specify the underlying protocols, Web Services, and standards or conventions that must be used for any two software products to operate with each other over the network. An API is like a recipe, and the protocols and standards it uses are the ingredients. Those ingredients need to be used in the correct order and in the proper amounts to achieve the desired interoperability result.

Get to the part about Video Surveillance

All this geeky stuff about protocols, Web Services, and APIs is great, but what does it have to do with Video Surveillance?

Well, in the highly fragmented market of (IP) video surveillance, interoperability means winning jobs and market share. APIs are the grease that makes interoperability happen.

One company that grasped the importance of good APIs early was Axis Communications. As a self-professed “IT” company, and with an early history developing printer servers, they had a deep understanding of what’s required to provide interoperability. It seems that APIs were in their DNA.

Axis implements their own VAPIX API in their IP cameras and encoders. Axis has gone out of their way to support developers and interoperability through VAPIX as a method to ensure that their cameras are compatible with as many other products as possible, and that integration is deterministic and straight forward. The clever reader will point out that VAPIX is not just one API but a collection of several protocols and web services, not all of which are based on HTTP or that strictly conform to the “anatomy of an web service” presented above. And that’s the point. The VAPIX API represents a clear definition of what’s required to communicate with Axis cameras–and Axis appears to put strategic value in its development and support.

Intentional or not, Axis’ API strategy has played a significant role in their success in the IP video surveillance market. For the past several years VAPIX has been Axis’ secret recipe interoperability–and interoperability was key to gaining market share in the IP video surveillance market.

Now Axis has led the development of an industry consortium to design ONVIF, which is a specification (not a standard!) that defines the protocols, web services, standards, and conventions used to guarantee interoperability between respective video surveillance devices implementing the spec.

Throughout the ONVIF spec you’ll find reference to 30 or more other protocols, standards, and sub APIs. The specification is heavily based on SOAP based web services and uses the standard WS-* framework. Implementation of these other protocols and APIs as per the ONVIF spec guarantees interoperability between devices and software systems that also implement said specification.

Now, one can point to the core services within the specification and see new services unique to ONVIF. These are about the command and control of cameras by other devices, and they conform to the “anatomy of a web service” from above. But the point is ONVIF is a collection of protocols and services that together make up an API specification designed for programmers to get on the same page with each other about interoperability. And that’s an important force in the software business.

Alternative collections of protocols, standards, and specifications to ONVIF exist. But interoperability is a harsh mistress. Devices conforming to these alternatives will only work with other like-minded devices, regardless of the qualities of their specifications. They are a different recipe that will achieve a different result. ONVIF is a specific recipe for interoperability. If you don’t follow it, you’re not interoperable.

Filed under APIs

The Cloud and Video Surveillance

November 2, 2010 2 Comments

Cloud computing is ambiguous and unfortunately overly hyped terminology. As of this writing, cloud computing is at the peak of the Gartner Hype Cycle. Use caution when evaluating cloud as it relates to video surveillance as it may be more hype than susbstance. That being said, there do exist specific definitions of what cloud means, as well as some concrete (read: not hype) examples of cloud application and success.

I developed Internet accessible, on-line systems (think CompuServe) in the 1980’s. I started working with HTML/HTTP/CGI (aka The World Wide Web) in the early 1990s. I’ve traditionally had one foot in programming distributed or large scale applications and the other in operating the infrastructure upon which those applications will operate. I say this not to toot my own horn, but to illustrate that on-line systems have been around for a long time, and as somebody who’s lived through the last 25 years of their evolution, I can say that what we know today as cloud is a significant evolution.

I’d like to explain what makes the cloud unique, and how it might be applied to the video surveillance applications with which I’m most concerned today. Just as it was difficult to predict exactly how email or the WWW would affect business in the 1980′s and 1990′s, it’s difficult to predict precisely how cloud based deployment models will affect an individual industry in this coming decade. However, we can learn a lot by looking at the cloud service trends that are emerging, and how they’re playing out.

The What

First, a primer. The National Institute of Standards and Technology (NIST) has published some surprisingly good material to describe the cloud in definitive (standard) terms.

According to NIST (and echoed by others who should know–such as Verner Vogles), cloud computing has several essential attributes:

On-Demand Self Service — This means that consumers and beneficiaries of cloud computing resources can provision, configure, and utilize resources themselves.
Broad Network Access — Consumers can access cloud computing resources from anywhere in their network, or anywhere in the world–no special network configuration is required to provide access.
Resource Pooling — Implicit within cloud computing is lower cost due to the economies of scale arising from massive resource pooling.
Measured Service — Utilization of resources are measured, and the consumer only pays for those resources they actually utilize.
Rapid Elasticity — This is an important characteristic that is going to come up later in this discussion. Rapid elasticity means that resources can be provisioned and put into service quickly and automatically. Additionally, as resource needs shrink, those same resources can be quickly and automatically freed in order to save costs. Technically, if there’s not an element of rapid elasticity involved–either directly to the end user or under the covers being utilized by the service provider, it’s not cloud.
Shared Multiple Tenants — Again, implicit within cloud computing is lower cost realized via economies of scale. These economies of scale are achieved through pooled and shared resources. Multiple tenants upon a shared pool of resources give rise to the greatest efficiencies. Additional, more complex dynamics such as the ability to over-provision network, disk, and CPU resources are only possible within multi-tenant scenarios. This attribute is critical to the positive economics of cloud computing.

The Why

It’s easy to dismiss several points of the essential attributes listed above as “optional.” Certainly they’re not all necessary to provide on-line software applications and services. However, these attributes are not invented by marketing folks to sell a new type of service. Rather, they are distilled out of massive on-line services and data centers in the past 10-15 years. They are a means to an end, not an end in themselves.

Over the past five to ten years on-line services like Google, Facebook, Yahoo, Amazon, etc., have perfected the art of deploying large-scale software applications to millions of users. In the time it takes to read this sentence, Google will have satisfied several hundred thousand search queries. These service providers have re-invented how software is deployed and how infrastructure (the networks, services, and operating systems underlying that software) are provisioned and managed. They have necessarily developed efficiencies through economies of scale using commodity hardware, flexible software frameworks designed to deploy applications on demand, and have greatly advanced the state-of-the-art in server and network virtualization.

An important parallel trend to cloud computing is IT automation. Like the modern data center, cloud computing technology is largely API driven and can be highly automated. Rather than human deployment of virtual assets manually, automated procedures manage and deploy infrastructure as needed. A good example is Amazon AWS, which has a well-defined virtual machine format (AMI), an API that defines cloud operations to deploy and configure virtual machines, as well as storage APIs.

Finally, the unique resource economic opportunities enabled by the above essential attributes have caused a significant shift in the way software is sold. One could argue that most software consumed today is free, with profitability derived indirectly through the use of the software. The so-called “freemium” model would not be possible without cloud computing and will have a significant impact on the future of the software (and hardware!) industry.

Get to the part about video surveillance

These stories about the cloud are wonderful. But how does it apply to video surveillance?

The most critical question is how video surveillance architectures translate into the essential attributes of cloud. While it’s relatively easy to imagine Broad Network Access, Measured Service, and even On-Demand Self Service, it’s more difficult to imagine how other attributes translate. Specifically, Rapid Elasticity causes trouble when we attempt a straight translation of the conventional video surveillance systems into a cloud deployment.

In terms of their general architecture, video surveillance systems today (even IP video systems) have not progressed much past the analog video switch. Generally, cameras still stream video into a central server where the video is recorded and sometimes distributed out to a small number of displays. In terms of the way bits and bytes move around the system, it’s hard to imagine elastic work loads within this conventional architecture.

However, if one looks at the environments being surveilled, they’re loaded with use cases that are elastic in nature. Here’s a simple example. This graph represents resource utilization of a video system imaging a portion of our building. Through the night, few resources are in use. Utilization picks up dramatically at the start of business (times are shown in UTC, local time is PDT). Resource utilization settles down through the morning hours, then picks up again around the lunch hour.

CPU Utilization

This graph directly maps the movement of people through a building to tangible resource utilization (in this case CPU load). Other IT resources such as network utilization, storage required, etc., have roughly congruent graphs. There is a use case here that could conceivably benefit from the elastic attribute of cloud. The challenge is to tightly couple the cost of surveillance to this utilization curve. The ultimate goal of cloud and video surveillance would be to reduce the overall capital and operational cost to the end user by relieving them the burden of paying for resources they’re not using (overnight) and to require an outlay proportional to what they actually use.

Philosophically, a video surveillance system only provides value to the customer when it’s surveilling activity of interest to that customer. If at all possible, the customer should only pay for what’s of value to them. Today this is fantasy, but our industry needs to recognize that optimization towards this end will be a persistent force driving technology and business models forward over the next decade.

This doesn’t make sense in all situations and obviously doesn’t map directly from current approaches to video surveillance infrastructure deployment. Thus we need to break down the possible video surveillance cloud service types and understand how they’re different from video surveillance today.

Video Surveillance Cloud Service Types

Cloud computing isn’t as simple as a single type of service offering. There are several different types of services being offered in the cloud, each solving a slightly different problem for the end user and each with their own value to a different set of stakeholders.

Today there are three commonly recognized types of cloud services among IT.

Cloud Service Types

Software as a Service

Software as a Service (SaaS) is a model in which an end user accesses software over the Internet. The user does not need to buy software or deploy it to their local infrastructure. Rather, the user pays for software on a per use or per period basis. The prototypical example of SaaS is Salesforce.com–which is largely credited with pioneering the delivery model.

There are currently two variations of SaaS that apply to video surveillance. Collectively they’re referred to as Video Surveillance as a Service (VSaaS), but are broken down into Hosted Video where video is streamed from cameras into the cloud, and Managed Video where storage of the video remains on site, but it’s “managed” via a cloud based interface.

Hosted Video

The simplest implementation of Hosted Video is a redeployment of existing recording systems to a cloud service provider. Video is streamed from on-site cameras to a remote data center for storage and management. This is the most straight forward type of cloud service to imagine in video surveillance, but its cost effectiveness is thwarted by high transit costs in the form of bandwidth fees to the customer and high networking costs to the service provider within the data center. Bandwidth prices are coming down, but so are the costs of on-site storage (both are roughly following Moore’s Law). A “DVR in the cloud” alone may never be as cost effective as on-site storage until it provides additional services and additional value to the customer. That is, a “DVR in the cloud” is not necessarily a better DVR.

Additionally, Hosted Video solutions, while essentially functionally similar to an on-site DVR, may not be compatible with traditional DVR sales channels. As John Honovich points out, many industry go-to-market strategies are centered around equipment sales, while service based offerings will derive profit from recurring revenue. Business-wise, Hosted Video offerings are not a simple replacement to DVRs/NVRs, even though their congruent functional model will encourage that they be applied to the same problems in the same way as an on-site DVR.

Also, remember that essential property of cloud, Rapid Elasticity? I don’t think the “DVR in the cloud” model is a good way to exploit elastic use cases that we might find in the environments being surveilled. That is, to truly realize the benefits of the cloud, we need to look elsewhere than the reimplementation of video storage from the local DVR to the cloud.

Managed Video as a Service

Managed Video as a Service (MVaaS) is a different take on services based video surveillance. In MVaaS, the recording of video remains largely on-site, but can be “managed” remotely via a cloud-based interface. In this model, the user may still buy and install video cameras, storage, and possibly management software on-site. The user will then connect that equipment to cloud-based services. For MVaaS to work, information about the assets, configuration, and some information about what’s going on in the environment being surveilled must be transmitted to the cloud.

New services are possible once the user’s equipment is connected to the cloud, and don’t necessarily require the regular transmission of video from on-site to the cloud data center. Additional value is provided when remote configure and diagnostics of the end-user’s equipment is possible by the integrator or manufacturer. MVaaS also makes a lot of sense within a geographically disparate business such as one with many centrally managed branches or franchise locations.

One can certainly imagine MVaaS type deployments taking on more responsibility for the remote storage and management of video over time. But early on I think we’ll see an emphasis on the management of discrete events and operational data remotely via cloud based interfaces against video data that remains on-site. These use cases lend themselves better to leverage the essential properties of cloud, and as such are a much more interesting model than those strictly embodied by Hosted Video.

The difference between Hosted Video and MVaaS is one of mindset. Where Hosted Video takes on the perspective that the DVR is being rehosted in the cloud, the MVaaS model may de-emphasize (but not eliminate) the DVR’s role on-site, and adds new value and benefit via cloud based services.

Platform as a Service

Programmers use Platform as a Service (PaaS) to construct services for other end users. The prototypical example of PaaS is a database service. Multiple programmers will subscribe to a database service and each will program against it as if it was their own private database. Google App Engine is a good example of PaaS, as are many of the services provided by Amazon AWS such as S3, SimpleDB, RDS, etc.

Generic, cloud based storage services fall under the category of PaaS. One could argue that any storage service available today is ready to become a “video” PaaS service. Products exist that provide on-site storage, backed by cloud-based storage such as Amazon S3 that is (theoretically) transparent to on-site video equipment. It will be interesting to see who and how this is put to use in our industry.

Infrastructure as a Service

Infrastructure as a Service (IaaS) is a model that appeals to IT personnel who wish to deploy infrastructure resources without buying hardware or building server facilities. The consumer pays for the infrastructure by essentially “renting” virtual servers, virtual storage, or network capacity and only pays for what they use. Much responsibility remains with the consumer to build, deploy and operate useful applications atop these resources. But they need not worry about the low level infrastructure itself. The leading example of IaaS is Amazon Elastic Compute Cloud (EC2) and Amazon Simple Storage Service (S3).

As it relates to our industry, IaaS is really only important in the context of dealing with the biggest IT shops. A notable example of a “big IT shop” is the United States Government. Where today many in our industry sell customers infrastructure in the form of servers and storage, tomorrow they’ll likely mandate a public or private cloud service provider upon which our software must operate. They may even go so far as to mandate certain PaaS level services which our software must utilize.

Standardization here is a long way off, but the trend is clear with the US Government. The Army is building a $250 million private cloud known as APC2. The federal government just announced a multivendor contract to provide Cloud Storage, Virtual Machines, and Web Hosting to federal entities through its Apps.gov program.

Cloud as Connectivity

Regardless of the cloud model, once connected, the ability to share and collaborate on video becomes much easier–to the point that new applications of video surveillance are possible. Today it is practically impossible to arrange ad-hoc access to video within your enterprise to some outside agency (for example, your fire or police department during a time of crisis), or even to a business colleague within the same company. But when sharing video is as easy as emailing a link to clip or live feed, this could change the way organizations operation and collaborate.

The connectedness that cloud attached video surveillance systems can offer may also become a driving force behind the adoption of mobile technology and devices in our industry. Mobile client applications are possible today. But the contortions required to connect the video source to the mobile device are sufficient to discourage wide spread use of these clients. If it was as easy to access your video system via your mobile phone is as it is to get your email, what new applications might be possible?

Filed under cloud

Five Principles of Innovation

September 12, 2010 Leave a comment

A few months ago I had the privilege of being added to the Solutions and Technology Office (STO) within the Pelco business at Schneider Electric. The reason for creating the group was to ensure that somebody was given the time to focus on development of future technology and exploiting opportunities somewhat outside of the traditional products and business.

A key to our success will be development of our own “innovation capacity.” This is the set of methods, process, and tools that facilitate innovation with and within the larger organization. It will also define how we work with the rest of the core business to co-develop new ideas, products, and business models.

This initiative isn’t a new idea. Smart companies have been successfully establishing innovation programs for many years. So there exists a lot of prior-art we can leverage. Here is a distillation of some of that prior-art into five principles of innovation worth considering.

1. Make The Time
Most organizations suffer from the “tyranny of the urgent.” There’s always a crisis to be managed, and rarely time to introspect or consider the impact of new technology on the very long term. There never seems to be time to explore possibilities that may not bring immediate profits or immediately actionable conclusions. Additionally, the core business is very good at viewing the world through the lens of immediate performance criteria rather than through the lens of the world in the future in which the criteria itself may change.

Organizations must make time for innovation. It will not happen accidentally. The time needs to be spent deliberately seeking out and culturing innovation. To borrow a phrase from Jeffery Phillips, they must “innovate on purpose.”

The dedicated innovation team officially sanctions innovation with people and resources to analyze new technology trends and look for opportunities for new applications of that technology. The best way to “make the time” is to dedicate real people and resources to those activities.

2. Don’t Go Rogue
Defining a distinct group for innovation work almost by definition labels the core business as NOT innovative. This isn’t true. It discounts the innovation that any good business practices every day. If this perspective is left alone, or encouraged, it will strain the necessary working relationship between the core business and the dedicated innovation team.

The fact is, the innovation group is not paying the bills, and does not have the resources to create products and bring them to market. The innovation group is simply the dedicated team that must be partnered with others in the business to achieve results. The relationship between the innovation group and the core business is a complex PARTNERSHIP, not a competition.

Leaders in both groups must culture relationships of cooperation and partnership or neither will benefit.

3. Seize The Whitespace
The Whitespace is defined as an area of opportunity that lies outside the core business’ ability to execute, and satisfies customer needs in a new way using fundamentally new offerings. This is where vast new opportunities lie and should be an area of focus for innovation projects.

Leveraging technology in The Whitespace is a challenge because precedents do not exist and because it is tempting to address Whitespace needs using the old methods that have been so successful to the core business in the past. The Whitespace, by definition, requires new methods, and thus innovation efforts should be managed carefully to avoid being caught in the trap of re-purposing old methods inappropriately.

4. Fail Forward
In most business, failure is not an option. However, in innovation projects, failure is not only likely but should be expected.

The primary product of an innovation project is learning. Learning necessitates exploration and discovery. While an innovation project may start with a goal in mind, it will more often than not fail to achieve that goal directly. However, innovation cannot follow without learning..

Innovation efforts should propose and test the validity of well-defined hypotheses. Will a new technology work for a given application? Will a customer find a certain application compelling and buy? Failure of the majority of these hypotheses is not exceptional. The process of testing and validating a hypothesis is valuable and necessary for innovation. The trick is to fail productively and keep moving forward.

5. Execution Is Key
The easy part of innovation is thinking up new ideas. The hard part is executing on those ideas. Execution must be methodical to generate ideas, culture them, winnow the ideas down areas of focus, and test the ideas for validity and measure their opportunity. Innovation is hard work and few companies do it well.

Companies like Xerox failed to exploit good ideas that were directly in front of them such as the mouse and the GUI. Other companies such as Apple distinguish themselves not by their genesis of a brilliant idea, but by their superior execution with products like the iPod.

Superior execution will require adherence to principles one through four, above, as well as application of a methodology that ensures focus on the right things and execution in the best way possible.

If all we do is think up ideas, we’re failing. Execution is still key.

Resources
For thought provoking articles on innovation, check out Jeffrey Phillips blog, “Innovate on Purpose” at http://innovateonpurpose.blogspot.com/

A valuable book on innovation, specifically how to develop and exploit whitespace opportunities is “Seizing The Whitespace” available at Amazon: http://www.amazon.com/Seizing-White-Space-Business-Innovation/dp/1422124819

The term “fail forward” may be attributed to John C Marks, although I have not read his book http://www.amazon.com/Failing-Forward-Turning-Mistakes-Stepping/dp/0785274308

A good resource on solving the execution challenge can be found in “The Other Side of Innovation” http://www.amazon.com/Other-Side-Innovation-Execution-Challenge/dp/1422166961/