Is IT governance a problem?  Using internal charge back schemes to manage costs for IT?  A simpler solution might just be SaaS.  Check out RSR’s article on IT Chargebacks: Tools for Business Alignment or Past their Prime?

I agree with them that internal chargebacks for IT have past their prime.  SaaS is helping to further make such schemes unnecessary by helping companies stay specialized on their business and not building ‘infrastructure’ that is outside their core competence.  It seems to especially make sense in business segments where technology isn’t the core product or competency.

As part of my on-going responsibilities I meet with investors (both my current and some potential future investors) throughout the year. My current investors, Columbia Capital, High Country Ventures (the Colorado state technology fund that is managed by local private equity firm Tango), and Dan Caruso meet with me monthly during our monthly board calls. I meet with other potential new investors all the time whenever I travel as it is always good to build relationships with potential partners regardless of whether you are actively seeking additional funding. (For the record, we aren’t actively seeking funding having just closed another round with our existing investors last month - although this could change in the next ~18 months as we look to accelerate our growth even further)

In any case, I’ve talked to more than a half dozen investors that I know over the past couple of weeks and came away with a very consistent theme that I’m not sure the rest of the security industry has internalized yet. The takeaway relates to how Venture Capital firms view recurring revenue.

Monthly Recurring Revenue (MRR), if you come from telecom or Recurring Monthly Revenue (RMR), which seems to be the term used more frequently in the security space, means on-going revenue that you get each month for an on-going service that you provide to a customer. MRR is the new holy grail in the security space. The appeal of MRR is simple, you get to wake up in the morning knowing that you have revenue already coming in for the month without having to go out and sell another thing. Assuming your churn (the rate at which customers decide to stop using/paying for your service) is low, it is much easier to grow revenue when you are in a recurring revenue business b/c you don’t have to start from zero each month and can build on your previous successes. Security providers see the advantages of having a predictable on-going revenue stream and are looking for ways to build that part of their business. There are segments (alarm monitoring for example) that have been MRR businesses for a long time, so this is not entirely new to the space.

The takeaway on how VCs view MRR is that not all MRR is created equal. A number of providers (systems integrators, DVR manufacturers, etc) are trying to build MRR by financing equipment. They take what used to be an upfront purchase (the sale of a DVR and cameras for a couple thousand dollars) and make it a monthly payment instead (the lease of a DVR and cameras for a couple of hundred dollars per month). There are a number of providers out there that are pushing this model heavily as they see the multiples that financial and strategic buyers pay on recurring revenue and that is very appealing to them.

Problem is this type of recurring revenue is not valued as much as the more classic recurring revenue businesses. Why would this be the case? Because leasing equipment is not at all the same as providing an on-going service and doesn’t have the same financial characteristics as other MRR businesses.

First, the only real difference between buying and leasing hardware is the nature of the payments (get cash now or get cash over time) as the customer gets the gear in either case; it isn’t really a true on-going service that is being provided.

Second, the recurring revenue is only really recurring during the lease period, then it ends (most leases have a buyout clause at the end where customer can keep the gear for a nominal amount like $1). This means that three years after a lease is signed the customer can keep using the gear but stop paying until they decide they want to buy new gear. Contrast this with alarm monitoring where the customer pays in perpetuity as long as they want their alarms monitored or with MVaaS where the customer pays in perpetuity as long as they want to use the service.

Third, the scale economics are not as strong and the working capital requirements are worse for equipment financing models. The more leased equipment you sell, the more upfront capital you need as you have to pay upfront for the gear (which you could also lease yourself). The only real scale benefit you get would come from volume discounts. Compare this to a software service where you have a fixed cost of maintaining and supporting the service, but incremental customers and monthly recurring revenue have almost no variable cost. Once you get to scale to cover your relatively fixed costs, all of your incremental revenue drops straight to the bottom line as cash.

The net of this is that VCs place a much higher valuation on true MRR than they do on equipment financing revenue. If you want to create massive shareholder value, focus on building compelling services that customers will want to pay for over time that you can deliver in a very scalable way to drive material on-going profitability. If you want to be a bank/financing company in one of the worst credit environments in recent history, that works too - just don’t expect to get the same multiples on that revenue as you would with a true service.

I was reminded today of the number of applications and the massive numbers of downloads of iPhone applications out there.  As of this writing nearly 1 billion downloads of iPhone apps have occurred.  That sure is a lot.  It also reminds me of a great quote from Sci-Fi author Kurt Vonnegut:

“It has been theorized that an infinite number of monkeys banging on an infinite number of typewriters would eventually reproduce the written works of Shakespeare. Thanks to the Internet, we now know this is not true.” ~Kurt Vonnegut

No, I don’t have an iPhone, but there’s a few apps I’d like to have. 

[Note: this is a guest post by Ori Pessach. Ori is one of the most gifted software developers I have ever had the pleasure to work with and fortunately, also our senior-most developer across our video platform]

I was asked to be on a conference call with a customer a few weeks ago. The customer was using our system for a while and it was working well, but then, mysteriously and suddenly, video streaming stopped working. It was a baffling problem - the customer assured us that he did not install any new software on his PC, that every other application that uses the network was still working fine, and we just couldn’t figure out what could be causing that.

I was asked to be on that call because I’m in charge of developing our video player. One of the challenges we had to tackle around the time I joined Envysion two years ago was making video playback rock solid. We install our recorders in many different environments, from small mom and pop stores with the cheapest DSL connection that money can buy to tightly controlled corporate computing environments where the customer’s IT staff is very wary of any new piece of equipment that appears on their network. Our system is designed to work reliably with no need to configure anything on the video recorder - in most cases, installation involves plugging everything in and powering the system up.

Since our client is web based, it works everywhere where our customers can get connected to the internet - if you can browse the web, you can use our application. But there is one exception: The video player is a browser plug in, and it opens its own network connections to stream video from our system, and we found that it can be a little tricky to get that to work reliably. Sometimes, web proxies didn’t like the way we formatted our video stream and blocked it. We found that some anti-virus products handled our network traffic incorrectly and blocked it. We fixed those issues, and did so relatively quickly, largely thanks to a feature of our video player that most of our users will never see - the debug log.

I’ve been writing software for over 20 years, and over that time I came to realize that software can be broadly (and, I have to admit, glibly) categorized into two groups: Software that produces extensive debug logs, and software with mysterious, hard to reproduce bugs that never get fixed.

A debug log is simply a file containing messages that the software outputs during its normal operation. Those messages aren’t meant to be seen by users, but they can be an invaluable tool when tracking down bugs. It’s a bit as if the software is talking to itself while it’s working, describing everything it does, sometimes in great detail.

Why is that important? Remember that we were trying to track down various issues that manifested themselves in different network configurations, on machines running various combinations of software that may or may not have an effect on the problem. In almost all the cases when playback failed, the bug report was identical: The user tries to play video, the player displays a message saying that it’s connecting, but video never plays.

This sort of problem can be very difficult to fix because the developer most likely never sees it. And it happens all the time - take this cnet report of a bug in Adobe’s Flash plugin:

http://news.cnet.com/8301-17939_109-10027752-2.html

and this response from an Adobe employee:

http://blogs.adobe.com/jd/2008/08/firefox_video_dropouts.html

If you’re not in the mood to read two lengthy articles about an obscure bug in Flash, here’s the executive summary: The cnet blog post talks about a bug that causes Flash to stop playing video after 2 seconds, and the Adobe employee’s reply boils down to “it works for us, and saying that it doesn’t work does not a bug report make.”

Which is very true. And also very wrong. It’s technically true, because most bug reports don’t provide enough useful information for a developer to fix the bug, or even know what the bug might be. In most cases, a developer fixing a bug in a piece of software spends a lot more time trying to figure out what’s broken than actually fixing the problem, and it’s a long and tedious process which can involve spending time with the customer trying to understand what it is that they’re doing, and what exactly they mean when they say “it doesn’t work.”

But it’s very wrong, because the customer doesn’t care about any of those things. The customer sent you a check, and he expects the product to work. He doesn’t want to spend time talking to technical support, and he doesn’t want to read obscure error messages over the phone, and he has better things to do than spend any time trying to help us fix the product he paid good money for thinking that it was working fine, because that’s what we told him when we sold it to him.

And this is exactly why I like software that logs extensively - because it makes customers happy. How? Simple - now, if a customer sees a problem with our player, I see the problem, because the player tells me where the problem is. I don’t have to ask the customers and have them repeat their actions while describing them over the phone, because I have a log of their actions and everything that the player did in response to those actions. Typically, once I have the log it takes me a few minutes to figure out what went wrong and offer a workaround.

I was reminded of this a few weeks ago while on the conference call with our customer. I was getting ready to run some diagnostics on the customer’s PC when someone in the room suggested that we use the Big Red Button.

The Big Red Button is a feature in our application that submits an instant ticket report from the application itself. One of the things that the ticket report includes is a short summary of the player log. I helped implement that feature, but I completely forgot about it. Still, there it was, and in less than a minute I was looking right at the problem - the customer had a new firewall that was installed recently, right when our application started misbehaving, and the firewall’s response to our network messages appeared in the player log - the player was being blocked. We were able to offer a workaround on the spot, and to confirm that it works.

We didn’t implement that feature because it was cool. We implemented it because it’s 100% necessary to serving our customers, and to making sure that they’re happy. Our job isn’t done when we cash the customer’s check - it’s just beginning, and that’s exactly why what we do is called Managed Video As A Service.

I am somewhat of a twitter user. I have an account, I tweat once in a blue moon. Personally, I find facebook status updates to be much more compelling than twitter. Dennis Stevenson has an interesting blog entry about how twitter helped him get customer service issue resolved.

The facinating thing about his story is that you can search the Twitterverse (all tweats) for specifc phrases. Twitscoop is a site that lets you do this. Trolling the Twitterverse for mentions of your company … an interesting way to find your customers with issues!

Other thoughts for twitter might be to use it to send alerts about video events. Anyone looking at that?

Taking a cue from Brad Feld’s blog about daily data, we’ve come up with our own daily data template. For those of you who didn’t take the bait and click thru the previous link, the idea of daily data is a short email based summary of significant metrics about a service business. It is meant as a short daily pulse on the service. Here are a few that we are using here at Envysion:

Reports defined: Total Number of reports defined
Myclips #clips saved: Total number of clips saved
Myclips hours saved: Total number of hours of clips saved
# groups created: Total number of groups created
# group members: Total number of members of all groups
# videos saved to group: Total number of videos saved into groups
# POS events stored: Total number of rows in the database table that stores POS events
# users: Total number of users that have accounts
# logins yesterday: Total number of logins yesterday (logging in twice counts as 2)
# distinct logins yesterday: Total number of unique logins yesterday (logging in twice counts as 1)
Event Agent Online: Total number of EnVRs that have received POS data within the last 24 hours
EnVRs Provisioned: Total number of EnVRs configured (less those in RMA and Inventory domains)
EnVRs Online: Total number of EnVRs with an active openvpn connection into the datacenter
Open tickets: Total number of trouble tickets open
New tickets yesterday: Total number of trouble tickets created yesterday

This list will change as certain metrics become more or less important.

Thanks Brad! (And Dan, who pointed out Brad’s post!)

Perhaps expansion of broadband into rural areas will help bring managed services to locations where they were previously not possible due to lack of high speed Internet.

Controversy over stimulus for rural broadband as covered by NPR

Some data on broadband penetration in rural areas from 2007.

Clearwire and Open Range Communications are a couple of large providers that focus on delivering rural broadband access.  They are typically using wireless for this (both are using WiMax based systems that can deliver 2Mbps or more in certain configurations).  I don’t know if they will be reciepent’s of any stimulus.

Tomorrow will mark the 1 year anniversary of the government brokered sale of Bear Stearns to JP Morgan for $2/share and of course $30 Billion of our (taxpayer) money.

If you haven’t seen Frontline’s 1 hour news report on the wall street meltdown, here’s a link to watch it online.  http://www.pbs.org/wgbh/pages/frontline/meltdown/

This is a great show that covers the timeline of the meltdown from Bear Stearns, Lehman and AIG.  It helped me understand the motivations behind the banking bail outs a bit more.

Systemic Risk and Moral Hazard often come up in the show just as they do today as conflicting issues.   Is there enough risk to the banking system to justify bailing out a company?  Won’t bailing out a company cause other companies to behave as if they too will also be bailed out?

It would be interesting to hear more about the relationship between then secretary of the treasury Henry Paulson and CEO of Lehman Brother Richard S. Fuld, Jr. The Frontline report seemed to imply they were heated competitors and that perhaps some of that history led Paulson to not bail out Lehman.

However even after this show I still must say that the lack of transparency in the handling of the banking bailout still makes me furious.  I wonder if some transparency could have reduced the systemic risk in Wall Street.  If we had know just how leveraged these companies were, would quite as much money been poured into them?

Busy week so far.

We spent Sunday night through Wednesday this week at the Multi-unit Retail Technology (MURTEC) conference in Las Vegas.  It was a great event for us as we met with 20-30 CIO/GM types from some of the leading retail brands in the industry.  In another sign of how far MVaaS has come there was even a topic table on MVaaS as part of the conference.  While the conference was definitely muted from prior years (at least one of the major POS providers didn’t even come this year), there was a very encouraging vibe at the conference from my perspective.

The vibe was not one of panic nor of hopelessness in the face of the current economic challenges these operators are facing.  Instead it was one of practical determination.  These CIOs and key decision makers were focused on sharing insights and learning about technology solutions that can enable them to help their businesses cope in the current market despite their lower budgets.  For example, there was a session on Cloud Computing (another word for Software as a Service) and how this trend is going to pick up and enable operators to leverage new technologies without the traditional capital and management required to implement and manage software.

I’ve said it before.  This market is going to create an opportunity for SaaS providers like Envysion.  Not everyone yet understands the differences and advantages of SaaS and MVaaS, but we are getting there.

I’ve had many conversations lately with partners and prospects regarding IP camera capabilities and more specifically, the merits of Megapixel and PTZ cameras. While each camera type has its own unique set of pros and cons, it’s easy to get caught up in cutting edge technology that’s available versus what’s actually necessary.

The necessity of a PTZ camera is largely determined by the presence of a live operator to control the camera. There are several environments where this is particularly handy, such as high-end retailers, big-box retailers, banks, casinos and airports. This gives LP and security personnel the ability to track suspects and zoom in for better detail using live video.

However, what happens to the larger field of view when zooming in on a narrow square-foot of view? If there’s a commotion on one end of a jewelry display which draws the close attention of the camera, the other end of the display is not only out of view, but not being recorded either. Organized crime rings have figured this out. Further, without a live operator, a PTZ camera defaults to a stationary fixed-view camera.

For the rest of the pack who do not have live operators on PTZ controls, Megapixel cameras offer some unique advantages. First is the clarity of the higher resolution. Second is the wide field of view. These advantages offer a superior coverage area and digital zoom capability without compromising clarity. In many instances, Megapixel cameras offer superb coverage and clarity without taking any eye off the bigger picture and without the need for live operation.

In most cases, standard re or hi-res analog cameras will be plenty of technology. Sure there’s better, just be sure you’re getting what’s necessary and appropriate for your situation.