Dusting Off the Data Warehouse

Businesses all over the world have spent millions and millions building data warehouses and implementing Business Intelligence (BI) without coming anywhere near the promised business benefits.

That is about the change.

And the thing that will change this is interactive, visual analytics on tablets.

Tablets and modern interactive graphics are a match made in heaven. Business users who will reluctantly spend half an hour looking at a BI report will happily spend hours playing around with their business data when presented beautifully. The demos I have seen here at Oracle OpenWorld in San Francisco show that this future is already here. You can finally unlock the value you have accumulated in your expensive data warehouses.

Preparing for Oracle OpenWorld

The big annual Oracle event is almost here – starting Sunday 28 Sep with the User Group Sunday followed by four days of presentations in around 50 tracks!

If the agenda seems a bit overwhelming, read the OTech Magazine Special OpenWorld Issue to find some of the highlights and can’t-miss sessions.

My sessions are:

  • Mastering Oracle ADF Bindings: Advanced Techniques (UGF3484). Sunday Sep 28 at 10am in Moscone South room 270
  • Starting Your Oracle Application Development Framework Project Right (CON3407). Wednesday Oct 1 at 2pm in Moscone South room 302

See you in San Francisco!

 

If You Build It, They Still Won’t Come

I’m at Oracle Headquarters for pre-OpenWorld briefings this week, and am seeing many great things (that I’m not allowed to blog about yet ;-)

One thing that still puzzles me is that Oracle still don’t get social. They have very nice Social Network features (their product is called Oracle Social Network), but they insist on keeping this inside a walled garden with no integration to the outside world. In this, they are no different from Yammer and other enterprise social/collaboration tools.

They admit that “adoption is a challenge” – you bet! Why would I spend time on an internal social network that contains only 5-10% of my contacts?

The solution is obvious but mysteriously resisted by Oracle: They need need to import posts from Twitter, LinkedIn, Facebook etc and integrate them into the company social network. In that way, I could go to one site to get all my social feeds (minus the obviously Not-Safe-For-Work posts that the company could filter out).

Maybe they’ve never thought to ask their users what they wanted?

Collect only actionable data

We are collecting more and more data, but using less and less.

You only need data for two reasons:

  • To take action based on the data
  • To store for possible future reference

Every time I shop online or interact with a support service, I’m inundated with requests to review and answer surveys. Not much of this is useful. If I rate your support staff 7 out of 10, what action will you take? Do not gather these useless vanity metrics.

Designing Door Acoustics

I just watched a video with a very dedicated professional. He was in charge of door acoustics at a major car manufacturer – in effect, his job was to make sure that the door makes a satisfying sound when you close it.

It is this kind of attention to detail that differentiate brands. An Audi shares 80-90% of components with Volkswagen and Skoda, but still manages to command a hefty premium.

Are you building a Bentley, an Audi, a Volkswagen, a Skoda or a Lada? Don’t spend time on the door acoustics unless that’s something your users value and are willing to pay for.

Useless Documentation

Not all documentation is created equal. Too much time is spent on formal design documents that are immediately outdated, and too little is spent on writing code comments.

Useless DocumentationMake sure your process requires and rewards good code comments. And make sure your architecture diagrams are kept up-to-date.

This illustration is from my weekly “Technology That Fits” newsletter – sign up here.

White Elephant Requirements

I’m often engaged with clients helping them respond to Requests for Proposals (RFPs), and there are way too many bad RFPs out there.

These bad RFPs not only specify what the customer actually needs, they also specify that the customer can possibly think he will ever need. Typical requirements are that the user must be able to add extra attributes to all entities, or that the user can dynamically change which attributes are mandatory, or that the user can freely configure the order in which fields appear on the screen.

These are not real requirements. But because the customer isn’t sure there will be money to maintain the system, he specifies a system with enough flexibility to ensure that he will never have to speak to a programmer again.

Unfortunately, meeting these requirements takes complex and expensive code, and the customer ends up paying for a lot of flexibility he will never need. Specify only what you need.