Social Media Marketing 101 - The New Fountain of Youth

I was recently asked to opine on what makes a social media manager and his (or her) strategy successful in today's market. Having dabbled in the field for a little while now (perhaps what can be considered a long time in this emerging medium) it forced me to stop and reflect on my own trials and tribulations in the realm of social media marketing (SMM). The first thing I pondered is how to even define "success" in social media and community management. It's not something that can be pinned down easily like an engineering project where criteria are clearly defined. Namely, does the product work as expected, is budget under control, and are the customers happy? Managing a brand or product via social media channels is more akin to wine making or political campaigning. It's something that takes considerable time, involves a myriad of tools and tactics, and, quite honestly, more than a little bit of luck. And it also takes a special kind of personality.

So first off, what is "social media"? It is a set of web-based communication channels connecting a brand with existing and potential customers. These typically include a website, Twitter, video channels (YouTube or Vimeo, for example), several social networking sites like MySpace, Facebook, or LinkedIn, maybe some IM services, throw in a couple photo sites like Flikr, and perhaps some opt-in email or SMS push channels. Social media marketing (SMM) and social media optimization (SMO, a subset), is the art of juggling all these channels simultaneously to build brand recognition and increase customer acquisition. The reality is in fact a bit more complicated, but those are the basics. 

Note that I called this SMM endeavor an "art" - and purposely so - because to the best of my knowledge, there are no clear well-defined best-practice recipes for success in this business and most companies tend to fly this bird by the seat of their pants. Some better than others. Yes, there are numerous self-proclaimed social media experts and consultants out there. People like Brian Solis, for example, who clearly know what they're doing and contribute substantially to educating the community about what works and what doesn't but in reality, no one really knows what works for sure. There are no magic formulas or guarantees. Just lists of obvious pitfalls to avoid and generally-accepted best practices, but that's about it. So here are my distilled two cents on SMM strategy based on personal and vicarious experiences of the past couple of years.

You know your SMO strategy is starting to pay off when:

1. Your web analytics indicate growing popularity and visit stickiness.

2. You see increased public participation in all your social media outlets.

3. You start getting unsollicited interest from the press and industry influencers.

4. You find it easier to establish relationships and partnerships with distribution channels.

5. You start getting attention from competitors.

6. Customers start evangelizing your product to their peers.

7. Your brand awareness starts spreading outside your targeted segments.

8. You start seeing measurable and sustained growth in customer acquisition.

9. You start seeing repeat orders from customers.

10. You pick up positive comments about the experience of doing business with you.

What does it take to become successful at this game? A couple of tips here:

1. Do not profess expertise on topics you know little about. Eventually, it will show.

2. Always remain honest. Never lie. Your most important asset is credibility. You can fix almost any mistake except credibility damage.

3. Be genuine. Maintaining a special "online" personality is not genuine.

4. Be obsessed about customers. Walk in their shoes. They're always right.

5. Do not let fear of mistakes (or failure) paralyze you. It's OK to make mistakes. What's important is quick admission and correction.

6. Be either loved or hated. Middle ground is not compelling.

7. It's not a job, it's a way of life and a mission. Understand the expectations. It's a marriage, not a date.

8. At the end of the day, it's all about the "story". Understanding show business is crucial.

9. If you suck at building relationships in real life, you will suck at it online. The inverse is not necessarily true.

10. Question everything, keep an open mind, but be wary of "experts" (the field is too new).

I've had my share of SMM boo-boos in the past years; online successes and failures. Stuff I thought would never work (that did) and things I knew for sure would take off (but never did). There's nothing like this new media to bang some realism back into one's ego and topple pre-conceived notions. That's why I love it. The beauty of this new "frontier" is its never-ending capacity to change, evolve and teach. Try it. It'll keep you young :)

The Wailing Wall of Open Source BI

Henry David Thoreau once wrote: "The mass of men lead lives of quiet desperation". Much the same can be said of the multitude of users struggling with open source reporting and analysis tools like Mondrian or Jaspersoft. The difference, of course, if that those folks happen to be pretty vocal. And nowhere more so than on those vendors' own "support" forums.

I double-quote the term purposely. Because what you witness on these forums falls far (very far) short of what I consider to be minimally acceptable customer support levels. Now, it's a fact that many people find solace in these communities - after all, given the massive amounts of questions posed there, some are bound to get answered quickly and (hopefully) correctly. And it's a fact that many people achieve success (or some level of it) with open source BI solutions. At what cost, we can only surmise, but clearly, resilient, persistent and courageous people are getting some work done on these platforms.

But more often than not, the levels of post abandonment (ignored questions) and the arrogant responses are high enough to be shocking. I am stunned at the number of times where posting users are treated like it's their fault. The implication is that they are stupid or negligent. As a matter of fact, if you spend the time analyzing the language semantics, what you see are fearful, timid, often desperate users mustering the courage to post questions in the hope that somehow, someday, they will be answered by the Grand Wizards of [fill in the OSS BI vendor name]. This is not unlike the Wailing Wall in Jerusalem, where masses of people stick written prayers between the stones.

I find that these forum "masters" are too often condescending and consequently, they generate a "master-pupil" environment I find somewhat repulsive. It reminds me a lot of the old school systems in Europe, where Professors would stand on an elevated stage above the class to seal their social superiority. There's nothing wrong with respect but in my opinion, it has to be earned. When you berate, ignore or insult those who seek to learn from you, you are far from deserving respect, Grasshopper.

I do realize that these vendors provide some level of "enterprise" support for those wishing to license the software but given what you see in the public forums, it's hard to imagine it can be any better on the paid side because, quite honestly, Open Source companies simply don't "get" service. They are too often blinded by the magnificence of their code or product and forget that without users and healthy bi-directional communities, there wouln't be a company, Open Source or not.

My experience navigating through several Open Source forums was similar. At the time I figured, it's just me. I'm an impatient SOB and it's my problem. But when you start analyzing these forums (and I spent hours doing so), you quickly realize the disease is wide-spread.  All of a sudden, it's not just you anymore - almost everyone has the darn infection! I often wonder why people put up with this nonsense. Deep inside, I know the answer of course: because they don't have a choice. Either they can't find an easier product to use, or they are compelled to use it for organizational reasons (as in, my boss told me to check this out <sigh>). I do believe the advent of SaaS BI analytical tools spell the end of an era for the multitudes who must suffer through Open Source to get even the simplest of reports and dashboard out in less than three months!

But don't take my word for it. After all, I work on the SaaS side of BI and am likely biased. Even worse, I actually blogged a while ago about the merits of using Mondrian for OLAP. Indeed, after many months of putzing with it, I was able to accomplish something useful but I have twenty years of experience in IT. Read that again: two decades of messing around with difficult stuff and figuring out how to make it work. So sure, for someone like me (and if forced into it) you bet open source can work. But what about the poor guys who don't have that kind of experience? What about the people tasked with just getting reports or analytics done? I feel bad for those folks who invest time and considerable effort in open source solutions only to be left at the altar of success. And if you don't believe me when I say they're out there en masse, then feast your eyes on the following selected quotes and links from Pentaho and Jaspersoft OSS BI forums (they are reproduced verbatim, grammar, spelling and emotional content intact).


"It seems I first have to dive in pentaho source code to figure how the printing function in pentaho is working"

"I am new user to Pentaho. I downloaded mondrian-3.1.2.13008. Now please advise me the steps I need to follow to configure modrian in my system."

"Although I'm no expert, I think Spreadsheet services has been discontinued, well I've never seen a Pentaho Employee mention otherwise"

"I've been trying to use IIF all morning but I'm getting nowhere."

"I have two questions, which I barely dare to ask, but I am sitting here and can't get over my problem:"

"I tryed all combinations. The only combination that works is fact table,dimension tables and aggregates tables in the same Mysql schema, and a datasource that point to that schema."

"Hi everybody. Though I've run the demo applications and read almost every thread about this, still I can't get an exact understanding of the relation existing between Pentaho Server and Mondrian."

"I think that the preconfigured examples of JSPs, catalogs etc. are confusing at best - bad practice at worst."

"I am fairly new to Mondrian, and I am stuck at ths point"

"This might be very trivial for some of you but I'm really having a hard time figuring this out. So any help is greatly appreciated. Thanks so much."

"I've goggle this one down to my knuckles. I suspect my chopsticks are tangled on the Mondrian/Pentaho side? I would appreciate any thoughts the community might have."

"Nobody can help? If so, does anyone know where else I can go to find the answer ... I've pretty much exhausted Google's list of MDX links, and am getting a little desperate now. Don't want to tell my client "it can't be done" without good cause..."

"Desperate for assistance. Last big issue to overcome and deliver my pentaho bi solution."

"Need some Help again.. I told my Boss that I will get the prototype ready by tommorow. Any help would be appreciated"

"I'm quite desperate.... ... please... help...."

"Helloo...???? Anyone there?? My question may be silly, still any of your ideas would be much helpfull..Am really desperate to find the logic.. Am not good in java and am in verge of my project and solving this issue resolves half of my task...Please respond..!!!"

"We are pretty desperate by now. We tried to manually re-insert the UNC server part into the file name, but this is getting dirtier and dirtier as we build new jobs."

"Sorry bothering you again, but I'm in a desperate situationn. We are trying to run the new Pentaho GA, but we have a lot of problems when we try to run this with Oracle."

"I'm really fed up now trying to make charts working over couple of days. I have created a database connection and given the field names correctly. Can someone please help me? I'm really desperate to get this working.."

"I know this has been logged by both myself and others before, however I am desperate for an answer here."

"I  checkd out all the sample dashboards of cdf.. but am clueless to create a dashboard of my own.. is there a dashboard builder for cdf??"

"I dont consider myself a fool when it comes to working with technology, and I have found myself frustrated and confused beyond belief at what should be a seemingly simple task..."

"And...regarding the timestamp....how in the heck to I tell that to not show up if I have no idea where it's coming from? Sorry if I seem frustrated, but I am."

"I've just recently begun working with Pentaho, so forgive me if this is a known issue or feature...I did a search on these forums and couldn't find an answer...a frustrated contractor in DC."

"I got frustrated that i cannot get a decent quality, well formatted pdf output."

"However, I do have to say I really had to grind through the first 10 days or so in order to get this thing down to a point of not hitting hurdles every step of the way. In fact, I've got a colleague who is really pretty frustrated and trying to jump ship"

"A few weeks ago I was very frustrated that I was completely lost withing thePentaho suite. I cannot afford training (I'm broke, plus I live too far away from the traing venues) so my only means at this stage is all of the above"

"I’m not trying to start a ruckus or anything I just wanted to state when I am coming from and what I would like to see from Pentaho. Judging from the many unanswered post on this subject I think there are many more like me out there."

"Sorry about the begginer question. But i'm getting frustrated"

"I am getting increasingly more frustrated it is quite hard to get started. The documentation seems only to touch the very basics. "

"I am a bit frustrated right now as I haven't been able to solve any of my problems."

"...first, *I* don't think i'm an idiot. what frustrated me was the lack of TASK-ORIENTED information i found. i had a fairly simple, fairly small TASK i needed to GET DONE... i dont care about kettle or apis or what great problems Kettle could solve... I had a TASK and an IRATE BOSS."

"I'm pretty frustrated at this point: I mean seriously how much more simple could a transformation be!?!?!?!?!?!"

"If I am posting about that, it is because I ve been frustrated much!"

"I was very excited to find Pentaho and eagerly wanted to create my first Dashboard. Now I’m just completely frustrated. And as I search these posts, I see thousands of people are looking for the same basic answer with little to no response from Pentaho: How do you create/deploy a non-sample dashboard; i.e. how do you actually use this thing?"

"Maybe a non-IT guy doesn't want to deal with SQL queries at all...

Now let's look at a couple of "answers" to many of these posts (unfortunately, questions outnumber answers significantly):

"You use the search button. Version 2/3/3.5 brings in lots of changes to the way Pentaho does things, please mention which version of the BI server you are running.
Join the Unofficial Pentaho IRC channel on freenode. Server: chat.freenode.net Channel: ##pentaho - Please try and make an effort and search the wiki and forums before posting!"

"If all that is true then it is clearly a bug in mondrian and you should report it in jira."
Here, the moderator seems to question whatever the premise of the question was (as if people bothered posting lies...)

"The procedure is exactly as I have told you. You must have done something wrong somewhere. Just check through carefully;"
Typical "you must have screwed up something" response. How encouraging and a little condescending if you ask me.

"If not, please post the error. We're not clairvoyant."

"There might be a simpler way... search the doc."

In this post, a user actually bothers pasting a novel sized exception asking for help. Specifically, he asks: "Any help or even pointers to documentation more than Spring/Acegi provides would be greatly appreciated".

What does the Jasper guy reply with?

"JAAS authentication can certainly be done. Have a look at the Acegi documentation...The forum is also a great resource. - Is he kidding? Did he even read the post?

Here's another classic: a user is complaining about the advanced search in the Jasper forums. The moderator's suggestion is terse: "it is what it is". Then he suggests using Google! Are these people serious?

How about this comment: "I am desperate to use JasperReports , however I am having hard time understainding it".  Or this one: "Still can't compile - getting desparate...I am getting nowhere trying to get my reports to compile."

What can we conclude from this mass of desperation, frustration and confusion? Why would these vendor create and maintain such an environment to begin with? Because quite honestly, if I were looking for a BI platform for a critical project or client, and came upon these forums in the process, I'd run so fast the other way it's not even funny.

As I mentioned above, if you have some serious software development and IT background, the luxury of time, (the right hardware and software) and a propensity for hacking complex nebulous systems, or the courage to read a 600 page book on working with Pentaho, for example, these open source solutions might just do the trick. If your organization or client is insisting on going the Open Source route, and you have no say in the tooling selection, then clearly you have to deal with the pain, hope for the best, and pray for a check (or a job) at the end of the ordeal.

But if you're just a normal analyst or consultant tasked with a BI implementation on a tight deadline with an impatient boss breathing down your neck, there is an alternative. And if you're just a guy (or gal) who needs to get the job done now (as in, this week) without the drama and headaches of open source theatrics, you'll likely be looking at a SaaS BI solution.  Now, SaaS BI may not turn out to be your bag, but you owe it to yourself to at least give it a whirl and here's why (putting my pitching hat on):

It takes very little time, effort and money to try it out. In many cases, it's free. There's nothing to install or configure. It takes hours or days, not weeks or months, to build and showcase prototypes. Most of the time (as in 80%) the functionality is sufficient to do the job. And features/functionality increases dramatically with each release. Oh, and there's updated documentation. But here's the kicker: you'll actually get just-in-time support from people who actually care about your success.  As a matter of fact, they're invested in it. They will welcome your questions and use them to improve the offering. They won't ignore you and they won't treat you like an inferior species.

I know this is sounding a lot like "Miracle on 34th Street". Must be the season. Truth be told, SaaS BI is not for everyone, and your mileage may vary. But it's worth an honest shot. Because the alternative is an endless Wailing Wall of pain, misery and isolation that no one in BI should have to put up with anymore.

Of CRM Golden Calves and Ten Commandments of SaaS Landlordship.

I have a pet peeve concerning two things I’ve been meaning to write about lately, namely CRM and multi-tenancy. I recently read an excellent article referencing both concepts and thought it might be a good stepping stone to a quick blog post.

In his article Don’t Get Conned – The many disguises worn by software-as-a-service, Matt Wallach discusses CRM software and the concept of SaaS multi-tenancy.  Matt’s business is life sciences, and he discusses the state of CRM software for his industry.  His argument is along the lines of “be wary of on-premise wolves in SaaS sheep clothing”. The wolves, in this case, are on-premise CRM vendors who simply throw servers over a wall and call it a SaaS day.  The sheep (aka the good guys) are those genuine SaaS vendors riding a multi-tenant architecture. He then proceeds to define what multi-tenancy means using the well-known “neighborhood versus apartment” analogy.  Sounds innocuous enough (and the piece is well-written) but here’s the problem I have.

I am going to get a lot of heat for this statement, but truth be told, CRM is a hoax. There is no such thing as CRM.  It’s all smoke and mirrors, and you cannot nurture customer relationships (or any other form of relationship) using a bunch of bits. It’s a cop-out. I know of CRM market segments and sizes. I am well aware of CRM dissemination and popularity in corporate America. I don’t question its omnipresence in virtually all businesses in one form or another. My claim, however, is that it does not and cannot work as billed.  In numerous cases, it is simply a waste of “feel-good” money. Here’s why.

The companies and industries making the most use of CRM packages are those with the worst customer service. This in itself should be eye-opening. Airlines are perfect examples. Can anyone think of an industry with worse customer service? I can’t. Yet they spend gazillions on CRM and boast about it frequently. How about retail? When’s the last time these guys used CRM to do anything besides manage their “rewards programs” (who are they rewarding please tell me?) or push advertizing gimmicks? How about Telecoms? How many people are happy with their cell carriers in the US? When was the last time your interaction with a carrier’s customer service department was either useful, efficient, or pleasant? How about the automobile industry or even car rental outfits? When was the last time you were wowed by one of those big corporate CRM consumers?

Now, I’m not saying all companies who use CRM manage customers poorly. Some do get lucky. And others use it as a tool, not a means to an end, which is perfectly fine.  What I am pointing out is that customer service quality seems inversely proportional to the resources spent on CRM at the corporate level. And that’s ironic. The problem is in the C-suite. These folks see CRM as a panacea but inherently, deep down, these people do not have customer service “genes”.  They have Board of Directors genes, profit margin genes, or MBA ones, but they don’t know the first thing about worshipping customers – It’s a form of autism on their part.

Because in my experience, customer service is not something you can learn on the fly (although I suspect it is taught in business schools).  And it’s not something you can acquire via software. Companies, like people, are either born with it or not. It’s a nature not a nurture trait. And no amount of software or resources will change the behavior of a company whose culture isn’t obsessively centered on the customer. It sounds obvious, and everyone talks about it, but most of the time, it’s nothing more than lip service.  It’s a sham I tell you.

Luckily, the solution is simple: throw the software out the window. Really, honestly, you don’t need it. You can’t even prove you need it anyway. Most of the time, you don’t know how to interpret or filter the results. And worse yet, you have too much information.  You get overloaded with it in a drunken stupor and it ends up clouding your judgment.  And shortly thereafter, you throw common sense out the window.  Malcom Gladwell makes excellent anecdotal arguments against information overload in Blink, one of his classics.  It’s a fascinating read (specifically I refer to section 4 of chapter 4).  CRM and software overload have the same effect on corporate management as those described by Gladwell affecting ER doctors’ decision making. Too much information leads to disastrous results.

I’m not suggesting the demise of customer or performance management software as a whole obviously.  Keep the databases, the warehouses and the BI in-house (because analysis and insight are still obviously crucial) but take your big honking CRM software and pull the plug. You will likely learn more (and spend a whole lot less) by talking to your five top customers. If you want to stay in control and get 360 customer views, sign up for something like TeamSupport – it’s all you need. Most importantly, do something truly revolutionary: get out of the building and walk a mile in your customers’ shoes.

Order your own product, fly your own airline (in coach), rent your own cars, dial your customer service numbers repeatedly – from a roaming zone, for example – visit your retail stores (incognito) and talk to your customers. Order your own food, visit your own bathrooms, wear your own clothes. Engage customers one on one, on the streets, in the stores, at their home, face to face, and listen like you mean it. Listen like your life (and job) depended on it – because it does.  You cannot manage customer relationships from a spreadsheet or a SQL query any more than you can steer a marriage successfully via the web (yes I know, there’s probably an iPhone app for that). It’s that simple.  Your fancy CRM system is the blue pill. Take the red one!

So now, having sufficiently ticked off everyone in the CRM industry, let me tackle the SaaS “badge of honor” also known as multi-tenancy. Here’s a reality check: no one really knows what multi-tenancy means. How do I know this? Because if you ask three people what it means you will get five different answers.  And when you search for it online, you get multiple descriptions, some more convincing than others. So unless I missed something, there is no official definition, only qualified opinions.

To me, the gist of it involves partitioning software application space very quickly and cheaply to accommodate exponential mass market adoption cycles (there’s a mouthful).  Exactly how you achieve this, from a technical perspective, is open to interpretation. Some people partition inside the database and share schemas (like Salesforce.com, where every tenant shares database tables), others partition on the application layer where processes may serve multiple requests, some consider virtualization to be a form of multi-tenancy, and yet others implement a hybrid approach.

At the end of the day, multi-tenancy is a design methodology. Multi-tenancy (however you implement it) allows faithful cloud landlords to follow basic rules. If Moses had come down from “The Cloud” instead of Mount Sinai, he might have brought these back instead:

(1) You shall provision tenants quickly without affecting other parts of the system.
(2) You shall be able to provide deterministic system metrics on a 24/7 basis.
(3) You shall let non-technical staff (or software) handle provisioning.
(4) You shall monitor your platform’s health day and night.
(5) You shall implement and frequently simulate doomsday scenarios.
(6) You shall make it as easy to provision one tenant as it is for one hundred.
(7) You shall segregate and protect thy tenant’s data at all cost.
(8) You shall upgrade transparently and automatically for all tenants.
(9) You shall allow tenants some degree of customization but not more.
(10) You shall have a simple, clear and consistent pricing model.

In my opinion, what goes on behind the scenes to support this is irrelevant because it’s irrelevant to the user. The user just wants to be “on-boarded” and provisioned pronto and safely without hassle. If you happen to be able to pull this off technically and cost-effectively, then you’re multi-tenant! If not, you have some pain coming your way.

Whether or not you can support thousands of tenants per instance (however you define “instance”) is, for all intents and purposes, really your problem, not the user’s.  And I have yet to meet a prospect who’s first and foremost concern involves “multi-tenancy”.

This might suggest we cease using the term as a marketing asset because I don’t think it resonates clearly. In my experience, the only things that matter to a cloud user are simplicity, service levels, trust, and cost. So let’s give users exactly what matters to them, explain it simply, and keep it real.

Yours in BI.

BRBR45DDTK3B

S&M: Where the SaaS rubber doesn’t meet the BI road.

I was lucky enough to be at Dreamforce 2009 last week and wanted to pen down a few thoughts while the event is still fresh in my mind. I don’t think there was any earth-shattering news there, and I got the feeling (both onsite and online) that a lot of people didn’t really grasp the value of Benioff’s announcement (or strategy) about “socializing” the platform with Chatter.  I, for one, certainly couldn’t make sense of Colin Powell’s presence at one of the keynotes (not sure what he can possibly offer the world of SaaS but maybe I missed something).  But overall it was an enlightening conference and here are some of my impressions (and they pertain mostly to the SaaS BI realm).

First, the sheer number of bodies at the event was impressive. I understand 18,000 people took part and that is quite a large crowd given how undersold (to put it mildly) other conferences have been this year. Businesses have been reluctant to invest in conferences in 2009 as evidenced by abysmal attendance numbers and the rising popularity of “ virtual conferencing”.  So if one conference was preferred over all others, it must have been Dreamforce 2009, because it seemed like everybody and his mother sent people there.

Second, I was impressed by the level of “education” the typical attendee exhibited. I didn’t really see or hear people asking basic “big picture” questions. Rather, the inquiries were very focused, deep, and to the point, revealing mature customers (buyers) who had done some serious homework. Actually, most of these folks have had meaningful experience in the cloud (some good, some bad) and knew how to hit the right vendor pressure points. From my standpoint, it is always vastly better (and more enriching) to deal with well educated buyers in a no-nonsense approach. This is exactly the user profile I experienced at Dreamforce.com manning the GoodData booth.

Third, and I realize this is subjective, but to be honest, there are a lot of small clueless companies out there having nothing to do with cloud per say who clutter these shows for the publicity of slapping “cloud” onto their marketing literature. I’m not going to name names, but let’s just say when you sell gardening shoes, mailboxes, or kitchen countertops, I’m not sure you should be spending marketing dollars on Dreamforce.

Fourth, I didn’t pick up any “religious” fervor at the show from either buyer or vendor sides. I assumed this was going to be a major rah-rah for everything cloud (with Open Source type of fervor) but I found the discussions to be much more measured and rational with most people objectively comparing both approaches (when applicable) with few pre-conceived notions. I believe this is a sign of industry maturation as people are getting better at separating the wheat from the chaff. I feel for the most part that SaaS limitations are well understood by most (not all) people and expectations are becoming more reasonable for the most part.

Fifth, I believe that SaaS beachheads have been claimed.  This is particularly true in the BI space. This has a lot to do with perception obviously but in my opinion, the winners and losers have already been tagged.  Most companies (if not all) are fairly new in the cloud space yet already, they have public reputations as in “these guys aren’t serious” or “these folks are the ones you want to talk to”.  Obviously first-to-market matters a great deal in any industry and cloud is no different.  Except with SaaS of course, you can be first to market with a virtual product (vaporware, in the on-premise world), and it takes longer for people to read the fine print but, eventually, they do.  When people have an interest in a particular SaaS domain, they go directly to the “top dogs” without stopping anywhere else.  I believe there is plenty of space for new companies in the cloud but for those having established an early lead (perceived or not, and with compelling technology), the future seems bright.

Sixth, everybody in the BI cloud space faces the exact same problems.  And no one has clear answers so this is still a very “trial and error” process.  The difference is between vendors who admit this, and those who don’t (mostly to themselves).  This is a sweeping statement but overwhelmingly, when you talk to other vendors, the same themes come out time and again.  Namely, how to scale fast enough (or onboard efficiently with minimal customer “touch”), and how to control sales and marketing costs which are turning out to be higher than anticipated.   Although adoption is growing, in my opinion, the technical hurdles are not remotely as high as the business ones.

Most of the BI cloud vendors have managed to get by on minimal engineering costs.  Offshore labor is cheap enough that you can afford competent engineering teams in India, Central Europe or China (to name a few) for literally dollars a day and minimal liability.  Some of these vendors are making ends meet with two-man engineering teams!  And only two I know of have engineering teams exceeding ten people. So clearly, the money pit is elsewhere.

And elsewhere is S&M (no, not the fun kind) namely Sales and Marketing. The original proposition for cloud was that the “service”, unlike traditional enterprise software, was going to kind of sell itself.  S&M budgets were going to be minimal. No more travelling field sales force, expensive face-to-face customer visits, pre or post-sales engineers.  It was all going to be “automatic” and on the web. But my limited experience contradicts this.

Because now, adoption and competition are growing.  For example nowadays in SaaS BI, you have dozens of vendors. You skim enough to get to the “serious” ones (see #5 above) and now you’re left with maybe four or five guys.  Next year, there will likely be ten serious contenders.  The more competition you have, the higher sales cycles and costs get.  Next thing you know, you’re back to boots on the ground and to a more traditional enterprise software sales models. This is the danger facing many SaaS players these days.  CEOs and investors are edgy about this emerging trend. It breaks the anticipated mold.

The other problem is what I call customer “touch-too-much”.  In a SaaS model, efficient on-boarding is crucial. This is not only about flipping the proverbial switch – because properly-engineered multi-tenant systems achieve this quite well – but more about the time it takes to get a user’s business problem solved.  Namely, the costly interaction spent on a given customer to handle specific needs and the amount of customization needed to achieve satisfaction (and final sign-off on the purchase order). POCs, sales cycles and marketing costs are growing.

This is a huge problem in the BI space because the requirements phase can be long and even there agility is not necessarily a Holy Grail.  The basic problem is simple: it is very difficult to remove the “human factor” when implementing BI.  Cookie cutter never satisfies a particular business problem entirely. The money’s in the customization and the subject matter expertise.  You must solve difficult business problems, not engineering ones.  The same challenges apply to software engineering, and history has seen a flurry of “blissful automation” endeavors fail in that space (remember 4GL?).  At the end of the day, you can’t remove what’s between the chair and the keyboard, and you can’t efficiently and consistently automate it in software – whether in the cloud or not.

Now, this is not so bad for a company like Salesforce.com because they’re a platform play.  So by definition, they provide efficient functionality (large offering surface), but it’s all fairly mediocre and “cookie cutter” – Users are free to (try and) customize their modules as they see fit.  In the analytics space, for example, Salesforce reporting and analysis is shallow. Consequently, users looking for customer data insight and trending statistics (say for pipeline analysis) will look for integrated solutions fitting their specific business needs.

But for the after-market players who “plug” into something like Salesforce, it’s a major hurdle. Unless they can very quickly and cheaply customize their offerings for a myriad of different business cases, and move through POCs quickly, the SaaS hosting and costing model won’t do them much good.  In my opinion, most existing BI SaaS vendors are currently struggling with this conundrum. Lucidera seems to have as well. Its demise was a shot across the bow.  The first SaaS BI player to move past this problem wins the game and keeps the investors happy.

I have a hard time thinking of a SaaS BI vendor currently striking a reasonable balance between zero S&M and massive S&M.  On one end of the scale, I see folks adamantly opposed to spending a dime on marketing and expecting serendipitous results. On the other end, I see vendors placing heavy bets on misguided or highly-targeted verticals.  I see both strategies as precarious and hope for more level-headedness in the coming months.

No matter which way this goes, we're in for a wild ride. No prisoners will be taken. It's a great time to be in this business.

Yours in BI.

Of Birthrights and DNA in the BI Cloud World

I have been so busy getting ramped up on GoodData that I haven’t had a minute to post here in over a week.  On Friday, I am headed out to our R&D Center in Prague, Czech Republic - looks horrible doesn't it? :) - for a week to do a brain-meld with our engineering team and deep-dive the GoodData architecture. I’ve learned a lot about it in the past two weeks but clearly, there’s nothing like sitting down with the hard-core developers and discovering how the sausage has really been made for the past two years.

One of the unique things about this platform is the fact it was designed for the cloud from the get-go. “Born and bred in the cloud” as they say.  And that was several years ago, before the cloud “explosion”, when the idea of running a full BI stack in the cloud was just a fantasy to most people.  They said it couldn’t be done (matter of fact, some folks still claim that, but reality proved them wrong in 2009) but Roman Stanek and his guys did it and I think the results speak for themselves (here's one of many examples).

I think the “born and bred in the cloud” stamp is important because there is so much hype and hyperbole about all things “cloud” these days. Especially in the BI space.  A lot of times when you hear or read things about clouds, it tends to feel like this (with apologies to my Thailand readers who obviously understand that script).

To separate the wheat from the chaff, you really have to ask the right questions. Namely, is your architecture really cloud-based or did you simply throw bits over the wall onto a bunch of hosted boxes (or VMs)?  Do you understand the meaning and implications of real multi-tenancy? Are you simply shifting technology because it’s hip (marketing-wise), or do you truly possess cloud DNA? And on the non-technical side, do the economics make sense?

In the mid-1990s, ASPs (application service providers) were all the rage. Everyone wanted to “go ASP”.  I worked for some of them. But the “software” crawled, got in the users’ way, was hell to maintain and deploy, and the costing model didn’t work.  Many (most) went belly-up. But hey, at the time, it sounded good and the VCs wrote checks.  But already back then, painful lessons were learned.  Namely that it’s virtually impossible to change horses in the middle of a race. 

The inherent value of “born and bred in the cloud” platforms is not simply technical to me.  Clearly the engineering is intricate and “cool”, but what’s really at stake is what Roman calls “price-based costing”.  (Speaking of pricing and clouds, check out Roman’s latest blog post, it’s à propos!).  This is a Peter Drucker concept but it applies really nicely to cloud-based economics.    

Price-based costing is defined as “choosing a desired sales price and costing out production to meet that sales price with a desired profit margin”.  The idea is to first determine what you want to charge for a product or service, and then work the development economics backwards to achieve that price point. When you’re starting from scratch with a cloud-based technology, you can pull that off, because parameters, cost and elasticity are linearly deterministic.  The up-front costs are fairly low and the flexibility is fantastic.  Additionally, the tools are cheap, commonly available and simple.  

Consider that the GoodData backend is almost all coded in Perl on Linux with a REST interface!  (I’m not suggesting Perl or Linux are “simplistic” but I worked the MSFT development stack all my life, and I can see orders of magnitude in complexity reduction here).  

So now, if you have legacy bits and a “ground-based” engineering platform (and people), you’re stuck on a price structure in this bearish economy, and you can’t just flip to a cloud model as a panacea, no matter what your Marketing people tell you.  Whether you sell proprietary or open source software, you’re in the same predicament. Sure, you can provide less functionality or cripple your offering (or worse yet, try to make do with less people), but just throwing it inside a “cloud” won’t do it economically, and the outcome will likely be painful. The DNA just isn’t there. 

So when some BI vendors simply slap some code (open source or not) onto AMIs (say like Mondrian for example) and call it a BI on-demand offering with a ROLAP engine, it makes me wonder if they “get” the concept at all.  Mind you I ponder the same thing about big league BI tooling players who simply re-package their (oh so heavy) bits into virtual boxes and call it a cloud day as well. 

With a genuine “born and bred” cloud model, you have fine grained leeway in adjusting the pricing dial. Guess what, you can even turn it down all the way to zero and still survive for a long time at given data volumes.  At GoodData, for example, you can get 10MB accounts for free.  Not a huge amount, certainly, yet sufficient to “play with”.  But no matter how many people sign up for that, GoodData’s cloud platform can handle it both volume wise and cost wise at ridiculous scale and at the flip of a switch.  Scalability in a “born and bred” cloud platform is very (did I say very?) cheap.  And pricing can be finely tuned by throttling the technology, not the other way around. And this isn’t about taking a loss for marketing purposes. GoodData, like any other sound business (except OSS maybe), isn’t about giving stuff away for free, believe you me.

So I guess my point would be: caveat emptor.  The next time you’re considering replacing that big honking on-premise BI tool with the vendor’s “new improved” cloud-based on-demand version, check under the hood and make sure that “born and bred” DNA is there (hint: not likely).  And the next time you’re considering a “native” SaaS cloud vendor for your BI analytics, ask the right questions about what makes their backend tick.  You might be in for an interesting smoke and mirrors show.

On Bringing the Good News While Clearing Out Fungus.

I wanted to spend a little time sharing some good news with you.  I am going to be Technical Evangelist for a relatively new company called GoodData.  As evangelism means "bringing the Good News" to the world, this is truly a match made in Heaven for yours truly, as I will now be bringing the GoodData news to the world.


Many of you will have heard about GoodData before of course.  Most people in our industry know it was founded by serial entrepreneur Roman Stanek of NetBeans and Systinet fame.  Sun acquired NetBeans circa 1999 for $10M and HP grabbed Systinet in 2006 for a mere bag of shells ($100M of them actually). 


GoodData is backed by heavy-hitting investors including Andreessen Horowitz  (Marc was also an initial angel investor) but also O'Reilly AlphaTech Ventures  and General Catalyst.  It's always nice when you can point to Marc Andreessen pitching your company on CNNMoney.  GoodData also cleared another funding round last week as anyone following our industry will have heard.  This kind of news does not go unnoticed these days.


So what is GoodData about?  GoodData is an on-demand business intelligence platform for collaborative analytics (phew!).  This means the software runs in the cloud (Amazon's EC2 to be precise), so clearly the model benefits from all the usual technical, deployment, and financial benefits SaaS brings to the table.  But more importantly, and what really sold me on the concept, is the following equation (and those who follow me know my affinity for all things KISS):

gd = BI - BS

In English, this says GoodData is business intelligence without all the "bullshiitake" (term borrowed from my hero Guy Kawasaki).  So let's talk a little bit about that breed of mushroom.

• When you need to implement a BI project but depend on IT to setup infrastructure and purchase software before you can even get started, that's bullshiitake.
• When you need a PhD or significant training to start using a complicated overkill BI tool, that's bullshiitake.
• When it takes you weeks or even months to analyze time-critical data for your company and show results to an impatient boss, that's bullshiitake.
• When you can't collaborate with your peers and customers (internal or external) or integrate with outside apps while doing agile BI, that's bullshiitake.

GoodData represents a new way of thinking and acting about BI by removing these "mushrooms".  In that sense, GoodData is really re-inventing how BI consumers and producers interact, behave, grow, and produce results together.   And that, to me, goes way beyond a pure technology play.  It is a “next curve” move and an industry-shifting vision I wanted to help forge.


So in the coming weeks and months, I am going to be talking about the technical and social aspects of this industry-shifting platform. You'll be able to reach me at my new work email and I will be twitting on the @gooddata stream as well.

My pitch to BI professionals will be simple. If you seek independence, control of your environment, quick and deep results, and the flexibility to enhance your company’s bottom line, then you need to try out GoodData. We represent a fundamental new way of thinking about BI.  My role will be to show you how and why.

BI in a New York Minute is Born

In my last post, I mentioned I was going to do a "trial & error" run on a recent concept of providing weekly BI tidbits (news items) for people on the go.  Having had some time to reflect on this endeavor a little further over the weekend, and after consulting with some key people, I've decided to try another tack.  Fact is, I prefer keeping my main blog for "deeper" less frequent posts. 


So instead, I've decided to create another way to dessiminate this information. Additionally, I'm giving up on the idea of posting items on a weekly basis. Why cover weekly periods when in fact, BI news is occurring pretty much 24/7 in real time nowadays including weekends.  


To deliver better, I have created a new blog called "BI News in a New York Minute" where I simply post tidbits in real time.  When I get them, you get them.  People can subscribe to this stream via the blog (obviously) or by pulling feeds from http://biminute.blogspot.com/atom.xml.  Additionally, I've linked BI News in a New York Minute to Twitter so updates are also broadcast there when available (almost, but not annoyingly, in real time).  So if you aren't following me in twitland yet, point here and click "follow" :)


This is just one modality of a more general media concept I am working on for the Business Intelligence industry.  In the meantime, I am hopeful (and grateful if) you will give me feedback and suggestions!


Yours in BI.
J.

Your Weekly BI News in a “New York Minute”

I’m a glutton for BI information to the point of addiction. A day rarely goes by without my “scanning” three hundred or so feeds, blogs, twits, websites and other news and information sources pertaining to business intelligence.  I did the same thing when I was on the software development side, mind you, but using significantly less online sources and way more books. I find BI to be so dynamic an industry that by the time most books are published, the information is already obsolete.  And that’s just on the technical side.  On the business front, things change and evolve even faster.

So I started looking around for an aggregated “digest” of the day’s salient BI news points. I was looking for something that spanned the multitude of industry areas in BI from engineering and product news (platform to front-end), to business development, partnerships, personnel (who quit, joined or got fired), distribution (SaaS and cloud issues), venture funding, important conferences, and so on.  In a nutshell, all the areas that affect our industry one way or another. To my surprise, I couldn’t find anything readily available.  Something someone could take on a train or pull down to a mobile device during a daily commute to get a quick “scoop” on the week’s happenings in BI.

Then I figured, why not try my hand at compiling such a list on a weekly basis.  I know this is fairly subjective, but while scanning my own sources, I always “pull over” several items for more in-depth examination. I do this very quickly (I’m a very fast reader) and often “bucketize” these links using Delicious.com for further examination and/or analysis.  Clearly people have different areas of interest but I figured this pruned list could benefit some folks with no more than a “New York Minute” to spare.

I’m not sure how best to format and present this yet. I didn’t want to start off with some sort of mailing list offering because, quite honestly, I’ve never stuck with a mailing list subscription more than a couple of weeks myself.  So for now I’m going to try and post this on my blog on a weekly basis every Friday.  If I detect minimal interest, then I’ll try another approach.  I'll also include more items in future weeks.  This is more of a "trial and error" endeavor at this point.  Meanwhile, and without further ado (or order), here’s my BI Digest for the week of October 5^th, 2009 "in a New York Minute".

• Discrete SaaS player 1010Data scores a big contract in the retails space by signing up Dollar General.
• MicroStrategy is far from Open Source but giving away software for free nevertheless now. Trojan horse or good value?
• Awesome webinar on what was learned in the past 20 years in BI compliments of Claudia Imhoff and WhereScape
• "But can it core a apple"? On integrating OLTP and OLAP in the same database engine. One of the most commented (and educational, for me) Curt Monash posts I’ve seen.
• First of a two-part in-depth series on MapReduce vs. relational databases.
• You might not be paying your DBA enough money to put up with this (alternatively, you might be using the wrong DBMS platform ).
• BI and DW “implementors“ take heed. You may need more duct tape after all (this doesn’t just apply to the software development community, believe me).
• For a deep (and I mean deep) dive into what customer analytics in retail are all about.
• A really novel (read: smart) way to engage your market without the BS, hassle and expenses of conventional physical conferences as described by Merv Adrian who tried it.
• Dashboards in Excel 2010 (yawn). Sorry it’s been hard to get excited about MSFT BI in, oh say about 18 months now.
• Can (or should) InfoBright actually kick MonetDB’s rear-end? The numbers are (almost) in.
• In-memory databases and the Kognitio men who love them.
• Well, looks like nobody is using EC2 after all (NOT!)
• Larry invites Marc to Oracle Open World next week. See rumors fly...
• At least one person is excited about Gemini (but it’s a monkey so..).
• If you live and breathe “fabric” and grok fiber over Ethernet, this one’s for you.

And that's the way BI is.  Goodnight, and enjoy your weekend!

Baking MapReduce into Database Engines - Worth the Reduction Sauce?

MapReduce (implementations include Hadoop and CloudDB) has gained popularity in the industry. It also serves as marketing fodder for several new-breed ADBMS vendors who now claim to support it in various forms. So what is really behind this magic pixel dust, what problems does it solve, and how relevant is it to someone deciding on a new (or additional) ADBMS platform these days?

First, let’s point out MapReduce is not a technology but an algorithm. Wikipedia defines an algorithm as “an effective method for solving a problem using a finite sequence of instructions.” In MapReduce’s case, the problem being solved is the processing and analysis of very large data sets. The solution is a parallelized divide-and-conquer approach and works like this. First, you split up the “problem” into small manageable chunks. Second, you fan out each chunk in parallel to individual “work units” (maps). Third, you take individual results from each unit and recombine them into your final result (reducers). In SQL parlance, conceptually, it’s like doing a select aggregate with a group by.

There are file based and database-centric applications of MapReduce in existence. Of course, the presumption is that your “problem space” can be split up in distinct pieces and recombined without information loss. And not all problems are either large enough or mathematically suited to this approach. But luckily data management is, by definition, perfectly well suited because, as a mathematician once told me “every data management task can be broken down into two and only two activities: partitioning and equivalence”.

Some folks think MapReduce is a modern breakthrough concept, but they’re wrong. The application of this algorithm to the management of large data is nothing new, as pointed out by Dr. Stonebraker in a 2008 posting. What’s “new” about MapReduce is that Google has popularized it. And the thought is, if Google can process and analyze the entire world via MapReduce, then clearly MapReduce must be the Holy Grail of monster data management. But Google has unique challenges (gargantuan data volumes), and some very impressive (and plentiful) gray matter at its disposal.

Because the interesting thing about this “divide and conquer” approach is that, although fairly easy to conceptualize, it’s incredibly hard to implement properly. The human brain is really not “wired” to think in parallel. Research has shown that the top brains can at best juggle seven different objects simultaneously (and for short time periods). To understand the intellectual challenges at play here, I strongly recommend watching this Google video series.

As I understand it, implementing MapReduce correctly and efficiently is probably as hard as conquering multi-threaded programming. And in twenty years, I have met three people who really understood multi-threading correctly and two of them were Russian PhDs. I've had battle-tested architects tell me they would rather shave with broken glass than tackle the risk and difficulty of multi-threading (luckily, they weren’t designing operating or flight-control systems!). My point is, it takes some pretty special skill and talent to do it right. Nothing inherently wrong with that, but it’s neither quick nor cheap.

So why then would database vendors race to support MapReduce? After all, dealing with and managing relational systems is complicated enough as is. But at least people have been trained in the art for decades, and SQL is lingua franca. So the pitfalls and solutions are well established. Additionally, Codd’s premise guaranteed abstraction by separating the logical layer (SQL and a normalized schema) from the physical one (hardware and storage). But MR is heavy with non-standard cross-layer implementation details by necessity. Clearly a step backward from the KISS principle (even a “major step backwards” if you buy into Dr. Stonebraker’s argument that MapReduce is offensive).

Regardless, three well-known new-breeders, namely Aster Data, Vertica and Greenplum jumped on the bandwagon early on and announced “MapReduce implementations” for their product. I wondered what compelled them to invest time and resources into something that didn’t seem essential (or cheap) to the market at large. Are users really clamoring for MapReduce support in their warehouse engines?

To learn more, I went to YouTube and checked out Aster’s video “In Database MapReduce Applications”. In it, I learned that graph theory problems (think: travelling salesman) were well suited to MapReduce but not SQL. Examples included social networking (LinkedIn), Government (intelligence), Telecom (routing statistic), and retail (CRM, affinities), and finance (risk, fraud). Pretty much anything that can be modeled using interconnected nodes. But a connection from a node to another is really a “relation”, and so clearly well suited to a “relational engine”. So I might have missed something.

I also learned that existing applications typically extracted data from the database, performed some analytic work on it, and then pushed the data back into the store. In other words, they couldn’t perform processing inside the database. I found that generalization hard to swallow but reminiscent of numerous past battles on whether “business logic” belongs in the application or database layer.

Aster’s implementation of MapReduce is “deep inside” their engine, from what I understand. One example I could find was yet another YouTube video called “In-Database MapReduce Example: Sessionize”. In it, Shawn Kung shows a MapReduce function being used inside a SQL statement to “sessionize” user IDs in a clickstream context. Aster also provides very basic how-to’s on their website and blog. Clearly Aster is targeting this new MapReduce capability at the DBA side of their users, and it looks a lot like leveraging UDFs to me. Aster’s conclusion: “we need to think beyond conventional databases.” I’m all for that!

Next, I wanted to learn about Vertica’s implementation. Especially since Vertica’s own Dr. Stonebraker had initially nailed MapReduce pretty hard as mentioned above. But Vertica’s new position seems to be that MapReduce is a-ok after all, provided it remains external and doesn't pollute the purity of the relational engine. I couldn't find much on YouTube or their website save for a press release dated 8/4/09 stating “With version 3.5, Vertica also introduces native support for MapReduce via connectivity to the standard Hadoop framework”. It seems the “scoop” on the Vertica/MapReduce wedding is best described in their corporate blog. Basically Vertica is OK with "integrating" or connecting to but not "ingesting" MapReduce (via Hadoop) if I understand clearly.

I was also able to glean some tidbits from Omer Trajman on Twitter. Namely that Vertica supports Hadoop “adapters” which allow you to read and write into the database (which is basically the press release). I wish I had more in-depth information about Vertica’s MR functionality but even a basic search for the term on their overly busy website yields zero information and, unless I missed it, I couldn’t find any relevant webcasts either.

Greenplum were, if I am not mistaken, first to support MapReduce. Greenplum has the best MR resource online if you ask me. It’s clear, detailed and full of insight. Greenplum has a merged/cooperative DBA/programmer approach in their offering. Programmers can write maps and reducers in their language of choice, leveraging DBA generated data sets as (and if) needed, and DBAs can use MR functions along with SQL without (presumably) getting their hands dirty. There isn’t much to add to this excellent resource so I won’t.

So having mapped out all these facts, what can we reduce from it (I’m so funny) and more importantly, should any of this stuff matter to prospects when evaluating ADBMS vendors? IMHO, you might benefit from a MR-enabled ADBMS if:

(1) You have petabytes (or more) of data, an MPP architecture, and a search, scientific research, or mining problem a high-performance SQL engine cannot handle.

(2) You don’t have heavy legacy systems. Integrating (or migrating) existing business and relational code with a new-breed MR-enabled engine can’t be fun, quick or cheap. You might be one of the lucky few with pet projects on the table.

(3) You’re in Academia and have access to numerous cheap and competent programming resources, lots of metal, plenty of time, and limited pressure to succeed.

(4) Your organization has a track record of successful projects dependant on symbiotic working relationships between your DBAs and your programmers. In my experience, DBAs and programmers don’t work well together. They have different goals and approaches. And it seems intellectual and political integration of both resources would be a sine qua non condition to success with an MR database product.

Short of that, I can’t imagine too many people lining up at the MR-ADBMS vendors’ doors simply based on their MapReduce capabilities. And I don’t think vendors make that case either. In my opinion, supporting MR in the product simply says “Hey, look at me, I’m at the forefront of technology. See how smart I am.” But as a buyer, I’d be a little concerned about overreach.

In fact, I wonder how these vendors spread resources efficiently (and economically!) between database engine building, cloud provisioning (which Aster and Vertica now pitch), and MapReduce integration. I suppose marketing requires less focus than engineering as a discipline but still, that’s a lot on one’s plate.

SELECT SUM(blessings) FROM working_in_bi

If you’re working in the business intelligence industry, you should really count your blessings.  Mind you, you can do that if you’re employed anywhere these days.  But there’s something special about what I call the “BI Family”.  I’m not referring to a specific segment of BI, and I am not focusing on any particular job function. I’m talking about working in the BI industry as a whole.

I feel somewhat qualified to comment on this because, in the past twenty years, I’ve worked in numerous industries.  To name a few: life sciences, research, semi-conductor, telecom, payroll, accounting, systems integration, consulting, audio-visual, online media, financials, accounting, and insurance.  So I have a lot of background to compare from.  And believe me, there are worse adoption outcomes than membership in the “BI Family”.  Here’s my subjective top ten list of why working in this industry is really cool (no specific order).

#1. Brains

People are really smart. I’m not suggesting other industries spawn dummies, but the proportion of high IQs in the BI world always amazes me.  It’s often humbling and always stimulating.

#2. Strength

As we all know, the BI market is not only huge, but getting larger and growing yearly to the tune of 8-10% a pop. Other industries are not so healthy to say the least.   Simply put, BI is clearly not a fad, and no one questions its future.  It’s one of the fuels of our free-market system by protecting businesses and providing them with competitive tools.

 #3. Meaning

Guy Kawasaki says: “make meaning”.  He’s right.  Life’s too short to be in a meaningless industry.  And if BI isn’t about making meaning then I don’t know what is.  The whole purpose of the industry is to make meaning and support critical decision making.  This industry yields real-life significant solutions to crucial sectors like health, research, medicine, and defense (to name a very few).  

#4. Quality of life

In light of ominous HR predictions, news of recurring layoffs, and current employment trends in the IT industry, the BI sector has been relatively spared. Clearly I haven’t done any formal polling but I get the “vibe” that people are generally pretty happy to be in this game.  And why not. Compensation is generally good.  And location-wise, BI companies are clustered around national funding clusters namely Northern California and the New York/Boston areas.  These comprise some of the most magnificent (and most expensive, granted) landscapes and vibrant urban areas in the country.  Other industries have centers in, shall we say, less compelling geographic areas.

#5. Funding

I lamented the VC situation in my previous post, and clearly this doesn’t apply to all segments of BI, but if you have any sort of compelling BI proposition with the word “cloud” in your business plan, trust me you will get a VC’s attention.  Maybe not an official invite to pitch in person, but most likely a phone call.  In other industries, that opportunity is long gone.

#6. Gratification

BI projects used to take many months (sometimes years) to implement (when they even got completed).  But nowadays the industry is in “agile” mode.  And those who don’t embrace that won’t likely be in this business much longer.  This means you get to build solutions and see results quickly.  That’s gratifying. 

#7. Globalism

BI is world-wide.  True, so are most other industries, but from my experience, there is less of an “us versus them” attitude.  It has a fraternal feel to it.  Hands and minds seamlessly reach across continents in ways I have not experienced elsewhere. (I’ll go hug a tree now).

#8. Bozos

Most people are genuinely nice and unassuming.  I know this sounds naïve at best but it’s true.  I have not seen the level of ego, axe grinding, or personal animosity frequent in other industries.  Every contact I’ve initiated from top analysts to CEOs in this industry has been followed up promptly with courteous, genuine and insightful discussion. I’ve found most people to be more generous with their time and advice than in many other industries. Maybe they fear less for their jobs or fancy titles. In either case, the BI industry is fairly low on the bozo scale.

#9. Passion

People in BI are passionate about their field.  I’m not saying they get out of bed every morning to go save the world (onward BI soldiers), but overall they value their work and their contribution.  Most people I’ve met in this business are workaholics.  They know their stuff inside-out and boy do they love to talk about it.  Passion signals a great, vibrant industry.  Additionally (and this key), there seems to be better customer advocacy in this industry than others.  It’s not perfect, but vendors often do listen and react accordingly.

#10. Innovation

I hate to reveal this well-kept secret (don’t tell anyone!), but there isn’t a lot of desire to innovate in the financial, accounting or insurance fields, for example.  I’d be preaching to the choir by pointing out the myriad of new-breed ADBMS players out there, but also the multitude of new OLAP, data mining and analysis products, approaches and new (non-relational) ways of looking at data, cloud BI, EC2, etc.  We’ve seen orders of magnitude of both hardware and software innovation in the BI world.  It is a rich intellectual field teaming with innovation levels typical of a “new frontier” because it is.

So what’s the point of this apologist diatribe?  Just to remind people in this field to count their blessings. There are many worse places and industries to be in.  And it’s easy to take things for granted in the heat and excitement of daily business life.     

In the past eighteen months I’ve met many challenges in this business.  From coding to QA, to technical writing, from sales engineering to evangelism, from product management to market analysis. You name it.  So I’ve seen a lot of the facets in a very intense, very short amount of time.  

And I’ve also been lucky to interact with numerous players in the industry, many of which have generously spent time and resources supporting my self-education efforts with their insight, connections, and advice.  You guys (and gals) know who you are and I thank you for the help. There are many mensches in this business.

For the first time in my life, I think I can say I’ve found a home here in the BI industry.  I’ve never felt this way in the past twenty years, and I’m not exactly sure how to explain it, but like the old pair of shoes my wife keeps insisting I ditch, it just feels right and I’d like to keep it that way.