Originally Posted on April 15 2011
You know how I passionately advocate for what we call #newBI, but I got the inspiration for this post from the old BI, actually from spending the last 3 weeks struggling with more than one of the Big Guys out there (You know who they are, should I really mention them?), and I’m not over yet.
The large vendors have an amazing range of products, which cover an extremely huge amount of possible requirements. Things like Single Sign-On, translations and languages, software inventories, thorough auditing and complex data modeling. Each product is stuffed with features addressing all the possible needs.
And they do work, they’re a viable choice that provides real value. A large corporation with thousands of users can pick among four stacks and should stick to them.
But, sometimes, the devil is in the details. That cool feature, that is rather marginal to the package, has been fully exploited and built upon. It fixed an old hassle, maybe. Small things, like the ability to name the file that is automatically sent by e-mail after the parameters used to refresh it.
Being marginal features, they’re sometimes overlooked or not fully tested. Sometimes they’re removed without notice because used by very few customers and replaceable with a totally different, new, cool mailing engine.
So, after installing the new version, or a service pack, maybe, the small, but invaluable to you, feature stops working.
In a large corporation, an entire IT team would have thoroughly tested the product, raised a ticket to the vendor and, in the meanwhile, found a workaround.
In a smaller company, the issue is to be fixed by few, already overworked, people or consultants. While time passes, data are missing or are harder to be consumed, the confidence on the system plummets, old choices are discussed again and nobody is happy.
The large guys will likely reply to your cries: with a fix months later or with a workaround that often implies a lot of work.
Small players will do something different. They’ll dive deep in the issue, will realize that they made a mistake, and would spend their week-end confecting a fix for the Monday morning. You will likely get excuses with that, also.
This is the reason why, in software, sometimes, small is better than big. And small is often better for small. There are exceptions to this rule (MS Office, for example, or your accounting package) but the reply you’ll get from a small shop while in trouble is likely to be much faster and effective. We are trained to think that big companies can do bigger things more safely and professionally, but this is not necessarily true in software.
If you think that a small firm can cease business anytime, than think how large corps abandon entire product stacks for marketing purposes.
If you think that a big player will provide a constant stream of updates, think that a small firm will add the features that you asked for.
And so on.