BI tools like Microstrategy have to retool to be able to query multiple sources to satisfy a single query (they are doing that in the upcoming release 9, I believe). All of the other BI vendors will do the same.

The reason it is important to get some clarity on the definitions is that the wider BI industry (and I don't know what to call it) is driven by marketing, not by function or requirements. Software vendors invent things, acquire or get acquired by other vendors and give names to the combined capabilities they possess. Then it's packaged and sold to companies.

This meeting is not to be confused with the much larger Enterprise 2.0 conference. The attendees are members of nGenera's network and gather a few times a year to listen to and present their progress on various research topics/projects at nGenera.

Back to the topic. I listened carefully for the better part of two-and-a-half hours last week to Thomas Kurian, Sr. VP of Oracle, present the entire product set and positioning of Oracle's Fusion Middleware. He didn't crack any jokes and more or less stuck to the slide deck; nevertheless it was amazingly interesting. I liked almost everything I heard, especially the parts that were user-centric, such as unified metadata, common business semantics with shared logical models, single development environment, etc.

So why is Wall Street melting down?

After the brief introduction, the question was, "I want to ask some questions about your database."

"Excuse me," I said, "I'm an analyst."

"A what?"

The answer is, both.

The idea that you can go "do" requirements gathering is canonical, but it's surprising and ironic how few practitioners actually believe in its value. This isn't a bias you want to expose to your clients, though. I find it particularly vexing that training sessions and conferences on data warehousing and BI usually have requirements gathering classes, taught by people who really ought to know better. I guess that's a subject for another day — why industry "experts" are content to disgorge training, for a fee, that they know is misleading, but is widely accepted.

Gary claims that James "marginalizes Performance Management as being too narrow." Instead, he (Gary) suggests that "Performance Management and EDM are arguably very similar." James claims that EDM "goes one step further."

Back then, it seemed clear to me that Web services could provide more than just a way for Web-based applications to operate. With loosely coupled services communicating via standard protocol, while centralized directories allowed these services to describe their APIs, the sky seemed the limit. Reuse, long-chased but never achieved, seemed almost automatic. Platform independence, long-running transactions, and asynchronous processes — it would be like world peace.

Teamwork: There aren't many engagements where the success of the operation is dependent on just one player. It's important to organize for success and enhance everyone's contribution in a "whole is greater than the sum of the parts" mentality. That special esprit de corps that develops among small groups provides the energy to keep a difficult assignment on track. And, sometimes, teamwork requires splitting the team up.

• "We have the tools, we have the talent"
• "I love this plan! I'm excited to be a part of it!"
• "Let's split up, we can cause more damage that way"

Tom Davenport suggests that the competitive playing field for businesses is analytics. I think we'd all be a lot better off if we could do some analytics for ourselves. What do you think? Here are some things I wonder about:

Consider that the density of hard drives in the same period has increased five orders of magnitude, CPU speed even more so and the cost per unit of storage or MIP has fallen off the table. With that kind of improvement, a new BMW today would go from 0 to 60 mph in 0.00008 seconds, have a top speed of 15 million miles per hour and would burn gas at a rate of 2 million miles per gallon. Oh, and it would cost about 30 cents to buy. I haven't figured out the lease yet.