when not to use technology

I came across a link to a story where a South African company was using homing pigeons to transport data because it was faster than their broadband connection:

Workers will attach a memory card containing the data to bird’s leg and let nature take its course.

Experts believe the specially-trained 11-month-old pigeon will complete the flight in just 45 minutes – and at a fraction of the cost.

To send four gigabytes of encrypted information takes around six hours on a good day. If we get bad weather and the service goes down then it can up to two days to get through.

If you’re curious, doing the math on that works out to roughly 1.5 Mbps for the broadband connection and, if a 4GB card is used with the pigeon, just under 12 Mbps for the pigeon.

Of course, such a solution isn’t without risk:

‘With modern computer hacking, we’re confident well-encrypted data attached to a pigeon is as secure as information sent down a phone line anyway.

‘There are other problems, of course. Winston [the pigeon] is vulnerable to the weather and predators such as hawks. Obviously he will have to take his chances, but we’re confident this system can work for us.’

Though the story is amusing, the point it reinforces is I think a helpful one – namely, that the use of particular technology might not necessarily be the best solution to a business problem. It may just be due to the area I work in, but I have seen instances where organizations are so focused on the use of technology (or in some cases a particular type of technology) that they don’t consider alternatives that may achieve their goals better, cheaper or faster.

Certainly not necessarily advocating the widespread use of PigeonNets, but the story is an amusing example of someone overcoming the law of the golden hammer.

data/privacy breaches – costs are increasing – time for investment?

An interesting piece in E-Commerce News about a new report from PGP and Poneman about the cost of data/privacy/security breaches and the reasons for them. Some excerpts:

Data breach incidents cost U.S. companies US$202 per compromised customer record last year compared with $197 in 2007 according to the study. The average total per-incident cost rose to $6.65 million in 2008 up 5.3 percent from $6.3 million in 2007.

Healthcare and financial services companies experienced the highest customer churn rates — 6.5 percent and 5.5 percent respectively.

Third-party organizations accounted for more than 44 percent of all data breaches in 2008 and the resulting investigation and consulting fees made these the most costly form of data breaches.

Nearly 90 percent of all cases in the 2008 study involved insider negligence.

Many of the security problems companies face are preventable — but most organizations don t have the right software tools and security policies in place to deal with data breaches he observed.

“It s a combination of software and risk management ” explained Ponemon. “Good technology like encryption data-loss prevention tools and data-access tools can help — but they re not the complete answer because so many of these incidents are due to negligence and carelessness.”

Of course, there is a bit of of a conflict here given that the sponsors of the study also happen to offer security solutions. Nonetheless, the figures are important to keep in mind to drive home the point that the direct costs (not to mention the reputational costs) of a privacy or data breach are very real. And very substantial. Hopefully, some figures like this will prompt companies to invest more in proactive measures to reduce the risk (and costs) of privacy breaches.

If you’re beyond that stage, then you might want to read this: Practical Tips for Responding to Privacy Breaches (full disclosure: I work for the firm that published this article).

The Costs of Sarbanes-Oxley

No, this post is definitely not what you’re thinking. Its not about how more and more companies are looking into going private or going to markets like AIM instead to try to avoid the increasingly greater burden of legislation like SOX.  In fact, quite different altogether. Its a story about how Apple will be charging a few dollars to unlock a feature already built into one of its products. That in itself is nothing particularly earth-shattering. What is a bit wonky is the reason Apple cites. According to another story at iLounge, its because of SOX:

Another Apple representative has added details on the Sarbanes situation: it’s about accounting. Because of the Act, the company believes that if it sells a product, then later adds a feature to that product, it can be held liable for improper accounting if it recognizes revenue from the product at the time of sale, given that it hasn’t finished delivering the product at that point. Ridiculous.

I don’t purport to be an expert on SOX but I thought it had to do with internal controls, rather than accounting standards, which I thought, if memory serves, were still at least primarily driven by the pronouncements of the Financial Accounting Standards Board in the US, and not SOX.

So, if you are the proud owner of Core 2 Duo Macintosh, you too will be personally experiencing the cost consequences of SOX, even if you are not a US public corporation. And you can’t even avoid it by going private. Very odd indeed.


The Virtues and Evils of Open Source

Yes, I know, I’ve been behind lately. A ton of very interesting things to catch up on. But I’d like to put in one quick note about open source code. I recently came across an article, written last year by a lawyer, generally advising development companies not to use open source. I don’t quite recall where it was (if I did I’d link to it) but I do remember it being quite clear in stating that using open source is A Bad Thing and to avoid it altogether – not just to be careful, but rather to treat it as one would radioactive waste.

With respect, I don’t quite agree. I certainly advise my clients to take a great deal of caution in using open source code, particularly the GPL variety, and very particularly if they have a desire to keep some or all of their own secret, proprietary code secret and proprietary. That being said, I do have many, many clients who have used open source code to great advantage in various ways. Some have simply used existing open source code to avoid reinventing the wheel (and saving on costs), while taking care to keep viral elements out of their proprietary code. Others have been more aggressive with the open source model and have intentionally decided to use open source as the basis for their business model and making their very own code, or parts of it, either open source or subject to a dual-licensing model. As the Red Hats, JBosses, Sleepycats, MySQLs etc. etc. of the world have demonstrated, you can go open source and still have a pretty viable business. And, of course, there are the “old world” companies like IBM who have decided to go open source (in some limited ways – e.g. IBM’s DB2 Express-C thing).

Of course, this is not to suggest that anyone through caution to the wind and just start pulling down stuff from Sourceforge and whacking it into your product. Use of open source definitely requires some planning ahead and consideration of what the business model and value proposition of your business will be. Optimally, enlist the help of a lawyer who’s familiar with open source licenses to discuss what you plan to do and the packages you plan to use. Or, if that’s not feasible, try at least to read the applicable licenses yourself and ensure you comply with them, because if you don’t think that anyone will notice, or that no one will actually sue you, you may want to pay a visit to the GPL Violations Site and reconsider, in addition to the questions that will be asked of you when the due diligence starts on your next round of financing or, even worse, your (aborted) exit event. Can badly managed open source usage (and I emphasize badly managed, not simply open source usage) kill a deal? Definitely.

In short – I don’t think open source is necessarily a bad thing. In fact, it can be a pretty good thing, not just in the social good sense and all that, but also as a business. But it need to be used taking into account its terms of use and ensuring that its consistent with the strategy you plan to take.

If perhaps there’s one thing I’d recommend it would be for shops to make absolutely sure they have a disciplined approach in tracking where code comes from and the terms under which its being used and why its being used. That applies not only to open source stuff, but also, for example, your programmers taking neat snippets of code from Dr. Dobbs or something else, or coming across a nice little script somewhere on the Web and saying “Gee, that’s neat, let’s use it in our product”.

Anyway, if I remember where the article was I’ll update this to include a link.