Cubegeek

Myth of the Fisher-Price Interface

When I was a technical remora, attached to the hip of my sales shark swimming the seas of business software in perfect symbiosis, I invented a phrase called the Fisher-Price Interface. It was a shorthand way of suggesting, somewhat slyly, that business managers had to have their computers dumb data down for them. The interface had to have big buttons and bright colors and be perfectly obvious how to operate for anyone with a second grade education. And so we spent a lot of time making our n-tier, java-enabled, third generation, enterprise-class, mission critical, multi-million dollar systems look 'intuitive'. Sometimes it worked.

But there was a deception going on there and we all knew it. After all we were part of a conspiracy to get the IT people at our prospect important jobs on big hardware with career-insuring complex software. So whatever catchphrase we could use to sell that stuff was valuable. Getting IT to buy into the myth of their business-side boss' pointy-hairisms was a device that took little prodding. At the same time we were genuinely trying to improve data provision, we understood a dirty secret, which was that the people with the best grasp of the data and the context of the business were already living in a computing hell that didn't require us to uproot and re-engineer. Anybody who really knows the umpteen factors that are making your Days Sales Outstanding 72 instead of 56 where it should be has a very complicated and integrated of sales operations and the profit and loss statement and all the jungle of systems and spreadsheets that make up that number. Sticking a Fisher Price interface in front of such an individual is an insult to their intelligence. As a sales guy, I'm telling him that I can rearrange his backend systems for what, to deliver a bar chart?

What everyone really wants to do is avoid the nightmarishly complex job of organizing from a process, technology and fiscal perspective all of the ways a company ought to be orienting their knowledge. That would be delivering on a promise that lies beneath decades of effort and tens of billions of dollars. It would make running the knowledge of a business as easy as playing a video game. We call that 'boiling the ocean', and the hubris of buyers, techies and sellers that attempt such projects has fueled disaster after disaster. And yet the timidity of incrementalism is what keeps so many business operating on 80s tech. Think about it, the maximum number of cells in an Excel (65536 x 255) spreadsheet has not changed since its introduction. Make no mistake, America runs on Excel. But some balance must be struck.

That is why I think we ought to be past the point at which we sell interface in BI. The widgets are built, and 95% of them aren't used. That is because the level of integration between process, technology and finances has been skewed towards the amount of that that can be managed into a sales-cycle. Very rarely do buyers, sellers and technologists in the various enterprise class software markets have an independent method of understanding what they're involved in with regards to upgrades to systems. Every deal is different and involves a different mix of concepts and team members. These days, the trend is towards forgetting the promise and simply saving money. Outsource it! It turns out that people half a world away can produce bar charts at one fifth the price of domestic providers. But what they cannot do is deliver on the promise of integrating process, technology and finances to the benefit of the company. That require a balance between boiling the ocean and timid incrementalism, a well-comprehended methodology and face time. Most importantly, it involves the most difficult kind of knowledge transfer, the kind that takes place as business is conducted in a dynamic context.

BI 2.0?

Neil Raden opines on the prospects for Web 2.0 in the BI space:

For example, though BI vendors have ported most desktop functionality to browsers, for the most part, we do not leverage the Web, we just deploy "WebTops." While Web 1.0 gave us portals, process integration and Web services, the wider capabilities made possible by Web 2.0, such as collaboration, advisers, personal agents and cognitive engines, have not entered the BI space yet. The catalyst for developing far better Web browser applications is a souped-up Javascript called Asynchronous JavaScript and XML (Ajax) that communicates small bits of data with a remote Web app without the clunky reloading of an entire page with each change. When Google Maps, developed with Ajax, was introduced, a new industry was born: writing apps for browsers that operate just like desktops.

Another fundamental shift in Web 2.0 is the whole process of software distribution. The way BI software is licensed and deployed is still firmly rooted in pre-Internet thinking, unlike Web 2.0 leaders like Google, which operates with no software upgrades, just continuous improvement. There's no upfront licensing cost, just usage, all running on massively scalable commodity hardware running open-source operating systems.

Thinking about DRM

DRM in broadcast and mass media is foolish for a basic reason which is that putting restraints on something with a small incremental profit margin is counter-productive. The evidence in this is manifest at your local Pic N Save.

What's at Pic N Save? Hulk hands. Beanie Babies. King Kong toys. All products from the blockbuster mentality which is market saturation with hefty licensing fees. In the end it's all just pop culture.

I'm old enough to remember when Frisbees were first released. The original Frisbee flying disk used to come in different weights and were certified by the Wham-O corporation to be official Frisbees. The 'Professional' Frisbee even had serial numbers. And everybody paid extra for that official sticker, the end result was that only a few people (in my neighborhood at least) had real Frisbees. Everyone else had knockoffs. Same with Hula Hoops and Hot Wheels. At some point we all grew up and recognized that Band Aids were just bandages, Vaseline was just petroleum jelly and GI Joe was just a doll. Commodities. Meanwhile at Pic N Sav, you see what people in the less than fashionable neighborhoods are buying their kids.

The more your DRM and pay for your marketing, the less you can get in market share. When you have a commodity product that never goes out of style, it may be worth it to spend that money and get a premium price. But it seems to me that you can't have both a premium price, enable DRM lockout and a fashion product. If you want DRM, then you need to be able to expire it once you get stuck with inventory. Inventory in the case of a digital product is low product flow as a function of upfront marketing expense.

The Hyperion Blog Experiment

I just discovered that Hyperion heads did a bit of blogging in some nice corporately maintained sites over on blogspot. They've got the flavor but not quite the fever. Still, something is better than nothing. This was related strictly to the procedings of Solutions 2006, the Vegas user conference, but it ought to go on.

I was talking to JB last week about blogging and it looks like there is some interest in the marketing departments about the potential. But so far as I know, I'm the only guy blogging this beat. So why are there no popular OLAP blogs? The reasons are strange and varied if you ask me. So here are my educated guesses in no particular order.

No Open Source Community
There is no open developer community in the BPM and OLAP space. Pentaho is just getting off the ground. So there is not the usual crowd of people who are out there talking about development issues and problems.

Portal Profit Motive
There are probably 10 people on the planet who understand OLAP and have two brain cells to rub together who haven't made money off of this knowlege. Everybody is getting paid and nobody is paid so much that they don't care about speaking out of school, or paid so little that any bit of information can't be turned into a buck. So basically all of the people who think they're clever enough to put together a BI information service, also think they'll make money on it. So you have a lot of click-market portals with a very high ad to information ratio.

I built the Cubegeek portal a couple years ago to be free and cross platform, but it has basically turned into a job board and a marketing vehicle for various interests. That's fine with me, but it wasn't my intent. You can't argue with what people actually do.

Weak Marketing
I've certainly been shushed by my superiors back in my HYSL days. But I think those who get paid to know honestly believe that if negative information comes out of any web orifice, that it will effect the bottom line. This is nothing more or less than an admission that the most puny website can overcome powerful corporate marketing. Or should I change those adjectives? In other words, typical spin control and information monopoly tactics borne of lack of imagination. Hyperion, of all companies, ought to be bigger than that, considering the strength of their products and customer loyalty.

Just the other day at Solutions, somebody in the audience mentioned that they heard 'somewhere on the web' that Hyperion was no longer supporting Java. The product marketing manager who heard that had this expression on his face like, OK we need to find out exactly who leaked that information. The information was false, but the very idea that the leaker could be found and stifled shows how insular we have become - to the detriment of wider market acceptance.

I recognize that this particular complaint of mine flies in the face of all the corporate wordsmiths and sales enablers. I was one myself. But sooner or later people are going to have to realize that free mass communications is the way to expand beyond bullet point flamewars.

Investors & Geeks
Network 54 and the Yahoo board are the most popular public discussion places for Hyperion. One is dominated by programmers and newbs hashing technical questions, the other by daytraders and spammers trying to manipulate capital markets. Neither is a friendly place for people who actually work as users with BPM or BI apps. Everything is biased and there are few good writers. It's a jungle out there. These folks are crowding out the ranks of people who would ordinarily have intelligent questions that would be more appropriately handled by a community of bloggers.

Master Data Secretaries
One of the most fun, challenging and interesting parts of my job, building BPM systems, is the data hunt. I call it finding out where the bones are buried. Inevitably, the people who hold the keys are financial and systems analysts & secretaries who know what the spreadsheets mean and what it takes to navigate through the ERP data jails to get the data businesses need to run. These people have no idea that there are legions of folks like me who would love to talk about their problems. I'm sure they are convinced that such decisions are 'way above their pay grade'. These are foot soldiers in the BPM revolution and they understand what it's like to use Google or Yahoo. We need to show them that they can have that in their BPM and BI apps.

Retardation
I hate to say it but I think that a lot of people who do databases and financial systems are just web-retarded. They don't know what a blog is. Considering the number of people I've met in this business who still use Lotus Notes without complaint, this comes as a big disappointment but no surprise. Fortunately, this is a problem that can be easily solved. We can accellerate them.

So I think there is a great potential here to get stuff rolling in the blog world, and I am more than happy to welcome all the Yukon guys who may end up driving on the technical side this once MDX becomes a real standard. Hyperion (and Cognos, maybe) has a real opportunity to assist in the expansion of a blogospheric discussion. It's going to take some independent blowhards to get things rolling, and people are going to have to get used to people saying what they want. Sock puppetry will get the vendors in big trouble. Other than that, the only thing to fear is fear itself. That and obscurity.

A Google ASP for BI

I've been thinking about explaining the basics of BI to noobs as well as senior managers whose companies have yet to exploit the economies. In answering an imaginary question of where the industry will be in 10 years (actually the iQuestion was 'Where do you see yourself in 10 years?'), I said that there will be four players. They will be Microsoft, Oracle, SAP and ... Google. I'm hoping to see myself with Google, the reason isn't obvious but I have mentioned it before:

Google does not charge the user. All of Google's software and hardware is at Google, behind locked doors, just like the IBM data center. To Google, you are a user, not an owner. You couldn't own the Google software because you would clog up Google's precious computers with your idiot code which couldn't possibly be as efficient and secure as Google's own code. They are masters of the algorithms and queue management. Google releases no product that doesn't scale to infinity. Google never gets a virus. Google is a free IBM datacenter. Google is the opposite of IBM despite all these similarities because its business model does not involve charging the user. Microsoft and IBM are the same because they charge the user. Microsoft makes you configure your machine and calls it freedom.

Furthermore, Google deals in human scale media. Google does not deliver compacted abstracted codes. Google delivers whole books, whole libraries of books. Google delivers satellite images of the whole planet. You are incapable of asking too much of Google, and their orientation is to deliver that all to you for free. Plus they take away all of the headaches that Gates delivered, the world of limitations of PCs. Clunky, insecure software written by anybody.

Google is one of the only computing products that hasn't bloated. Even Linux is running into controversy over kernel bloat. Pigs aren't flying, they're recompiling RPMs on their anti-Microsoft boxes. Same paradigm, same headaches. Free software approaches perfection, but there is no guarantee. Google guarantees, and that is why Google is rich and there are only two or three Linuxes left worth mentioning, all equally user poor.

But Google could charge the corporate user because Google has got what every enterprise desires: fundamentally unlimited scalability. They have the opportunity to license the way they do business and thereby revolutionize the IT business. Google is the ultimate ASP - they always have been, and they've been providing incredibly fast information for years now. Google can simply wait for every Tom, Dick and Ajax to write their little Web 2.0 app, and then determine whether or not it scales into a nice business model. They plug it into the Googleplex and voila.

It is not a stretch for me to see them doing this with 2 million spreadsheets, which is very likely what your corporation's finances are really running on despite MSFT's, Oracle's and SAP's protestations to the contrary.

So here's the question I posed to my BI noob interviewer. 'It takes about 15 minutes for you to find out whenever a car bomb goes off in Baghdad. How long does it take you to learn that your business has lost a customer?'. The answer to this question is generally sub-Google speed, which ultimately is unacceptable. The gap between real-time analytics is not so much technology as it is IT methodologies and captialization. This is something most companies would rather have, but not pay for up front. Some enterprising practitioners (like me) and some Google people could meet one day and come up with an ASP business model for enterprise BI. If and when that happens, MSFT, Oracle and SAP will find that they are a lot slower to the middle-tier webware market than they thought.

I am consistently surprised that people remain skeptical of fat clients. We are seeing 3GHz PCs with 100GB of disk and still people go Web. The hows and whys of that we can discuss later, but it is clearly a fait accompli. Whatever happened to port 80? It's now a thousand different ones for everyone's 'administrative client'. Client server has been swallowed up by very specific clients, ie browsers running interpreters. Whoda thunk? That being the case, applications development companies are essentially web development companies.

I have a hard time believing that people who built WebMethods or Vignette (nothing personal) are going to be developing the applications of the future. The narrow scopes of what IT organizations and (outsourced) consultants build these days unfortunately don't stand a chance against the big huge apps Google rolls out.

One final analogy. Once upon a time, Bloomberg relied on hardware. He had a near monopoly when it came to (bond trading I think). The smarts of that moved to PCs and the second revolution was exemplified in the day-trading bubble. (By the way, once upon a time the same was true of Metaphor DIS, specialty hardware to fat-client software to running on browsers in the BI space). Clearly the next evolution in tiered computing will be making browsers smart enough to do all fat clients do, cleaner. Now it's all about the scalability of the back-end. I have a hard time believing that the same decision makers who are gung-ho about punting to procurement departments when it comes to <strike>outsourcing</strike> staffing IT are going to think twice when offered the opportunity for 2 second response time without capital spending.