Computerworld solicited opinions about the future of BI from a remarkable variety of expert industry participants, mainly vendors of products and services.  Their opinions, unsurprisingly, were very well aligned with their respective business strategies, and varied all over the place.  

My thoughts on a few of the major themes and points made include:

Experiments have started with cell-phone-based payment systems.   Most arguments in favor of smart cards also support the cell phone alternative; indeed, it may be even better.  Smart cards are something that wouldn't be inconvenient for people to carry; cell phones are things they WANT to carry.  Cell phones have plenty of processing power for encryption, a keyboard for PIN number entry, and the potential for voice authentication. 

eWeek came to the same conclusion I did -- Microsoft will drive a boom in smart cards-based two-factor authentication.  But they went on to highlight a key challenge to any two-factor scheme -- provisioning the second factor. 

Meanwhile, Robert Mitchell reminds us of the dangers of card insecurity.   And Patricia Reaney of Computerworld gave a pessimistic view of future identity theft dangers, which is supported by a sobering report on the ongoing battle with credit card fraudsters.  

As Computerworld reports, RAND estimates US savings of $81 billion per year from electronic health records, although a $346 billion figure is also mentioned.

$4 billion of that is attributed to improved safety.   I don't know what figures RAND is using for the value of life these days, or what is included in safety other than life savings, but that doesn't sound like it's terribly supportive of the "tens of thousands of lives" kind of figure that Newt Gingrich and I (but not a lot of other people) have been using.

According to Bob Muglia, two-factor authentication .. now is the norm within Microsoft.  And everybody else should use it too, because passwords aren't secure.  Admittedly, this is part of one of those "any decade now" Microsoft long-term visions.   But the problems with passwords are indeed pretty unsolvable, and so the dominance of two-factor authentication is a matter of "when", not "if".

One factor will of course be a memorized password/PIN number; what will the other be?  The answer will almost certainly be a smart card.   So one of these years, your PC replacement cycle will need to include card readers as a standard element.

In my column that is appearing Monday I pointed out several application areas that:

1.  Cannot, in my opinion, be addressed by dogmatic relational approaches
2.  Literally are life and death

These are electronic health records and homeland/national security (intelligence analysis).

The key factor that makes them hard to handle relationally is the difficult, ever-changing nature of the analysis they need to support.  There simply is no stable way to define what the data is, exactly, or how it is to be evaluated. 

Alex Scoble has a long, well-argued post on why people may not switch to free software.   Basically, it's that switching costs are too high, in reality or perception, mainly because of the difficulty of learning new software.  

I am particularly fond of this argument, since it was the genesis of the best recommendation of my Paine Webber career.  In 1985, I was lucky enough to recommend Lotus within a few days of its bottom, and then I happened to sell out within a few days of its top in 1987.  (When you're that precise, luck is playing a huge role.)   I could go on at some length reminiscing about how cool the recommendation was -- attaboys came in from, among other, guys name Gates, Shirley, Kapor, and Esber -- but let's get back to the matter at hand:

The Dutch are instituting a national database of children.   At first blush, the safeguards sound reasonable, although they're very much in the European vein of trying to control the data itself, rather than the use of the data, an approach I think will ultimately fail.

Truth be told, I don't know as much as I'd like to about how the Dutch and others handle privacy issues.  Especially the Dutch, because of an interesting paradox.  On the one hand, the country is famously libertarian in some ways.  On the other, they have very Germanic police.  (I know a Dutchman who, having been out of the country for years, was awakened by the police his first night back over unpaid parking tickets.  Or so he says ...)   The liberty/control issue will be a tough one for all of us, and I'm sure that in the US at least, it hasn't been properly thought through.

My compatriots are active this week blogging about electronic health records.   And such records are a major part of my column to appear Monday.   So let me reiterate what I think are the basic points:

1.   The cost savings from electronic health records can be huge.   The US government estimate is $300 billion annually.

2.   So can life savings.  Those are harder to estimate.   Studies of deaths due to medical error tend to focus on things that health records wouldn't necessarily avert.   Still, estimates in the tens of thousands of lives saved annually in the US alone are defensible.  In fact, I agree with them.  Numbers in that range for the entire world are an obvious slam dunk. 

Microsoft is adding graphical pizzazz to the target apps for its development suites.    AJAX/RIA (Rich Internet Application) is picking up some buzz and momentum, as per TIBCO's release of a dev tool it acquired 10 months or so ago.   What does this all portend?

It's best to think about this from the standpoint of three different groups of applications.

1.  Analytic applications.  Dashboards obviously require richer interfaces than data entry apps.  I'll write about this area more soon, perhaps next week when Computerworld wants me to blog my heart out about BI.

In my previous post, I raised the general question of preparing for extreme disasters, and linked to a good article.  Here I'd like to follow up with some specific points.

1.  Geographic diversity is key.   Your backups need to be in a different geographic region than your primary copies.  Period.   Even if you send encrypted tapes by UPS to your brother in Oshkosh, that's better than nothing.

2.  Don't even think of violating Rule #1 unless your data is on a small enough object (laptop, backup disk, whatever) to always be accessible in your office, home, and when you travel -- i.e., if your data truly is practical to evacuate with.

Katrina has spurred a flood of pronouncements on disaster preparation, such as this Security Focus article.  (Particularly important are Point #2, infrastructures are codependent, and #7, you have to train your people.)   Well, here's another one, on a fairly high meta level.

You need to develop the most complete answer possible to a pair of questions like

1.  "What do we do in the face of physical destruction, mandatory evacuation, destruction of communications facilities, and death/disability of our senior officers?"

If there's one area in which I'd like to see Oracle/Siebel strive for leadership, it's in privacy.  Oracle has for years been whiffing on the opportunity to make hay with a "better privacy through database security," story, but this acquistion gives it one more chance.   The two private sector application areas with really scary privacy implications are electronic health records and analytical CRM, and I'd love to see app vendors do something about them proactively even before they're forced to.  

In a seeming quest to buy every available app vendor, Oracle is acquiring Siebel.  This deal makes considerable, albeit somewhat morbid, sense.   The victim of past arrogance and a frazzled technical architcture, Siebel was perhaps the biggest doesn't-realize-it's-dead company out there.  And Oracle's apps story is so jumbled that one more huge integration task won't really make things appreciably worse.   Indeed, Siebel is the one major apps company that can reasonably expect to have its product line enhanced by the Oracle acquisition experience.

A brief discussion about the word "orthogonal" broke out in another comment thread at about the same time I saw this post on "orthogonality", advocating the separation of application logic and infrastructure-related implementation details.   That's hardly an earthshaking idea, but the coincidence of two occurences of the same* unusual  word inspired me to post on the subject.

*Give or take some aggressive stemming

Here's an excellent two-paragraph overview of a closely-related principle from the Wikipedia's entry on "orthogonal."

Orthogonality is a system design property which enables the making of complex designs feasible and compact. The aim of an orthogonal design is to guarantee that operations within one of its components neither create nor propagate side-effects to other components. For example a car has orthogonal components and controls, e.g. accelerating the vehicle does not influence anything else but the components involved in the acceleration. On the other hand, a car with non orthogonal design might have, for example, the acceleration influencing the radio tuning or the display of time. Consequently, this usage is seen to be derived from the use of orthogonal in mathematics; one may project a vector onto a subspace, by projecting it each member of a set of basis vectors separately and adding the projections if and only if the basis vectors are mutually orthogonal.