November 3, 2008 Leave a comment
Recently, I received a question from a colleague that I found to be particularly stimulating from my point of view:
I have a client who is currently looking at OBIEE and BOBJ (Xcelsius) dashboard solutions. The client recently became aware of another dashboard tool from Adobe called Flex. Do you have any experience with this tool? Do you have any precautions or considerations around leveraging this simplified and substantially less expensive solution?
I do have some experience w/ Xcelsius and a lot of recent experience with Oracle Business Intelligence Enterprise Edition (at my current client). I don’t have any direct experience w/ using Flex to build dashboards, but I’m very intrigued and have been meaning to learn more about it.
Lately, I’ve been turned off by the big players in this space platforms. They make good sense for large enterprises w/ varied business & technical needs, but I continue to get very frustrated by their limited data visualization options, their bloated architecture, inefficient code, and inflexible customization options (for both data visualizations and web presentation [CSS, XHTML, …]). In turn, meeting the client’s business requirements becomes increasingly difficult. I discuss some of these challenges in my presentation on Effective Dashboard Design.
Alternatively, I’m intrigued by the “smaller” & less expensive options. Their high points are the contrast for the low points of the big boys. They don’t spread themselves thin by trying to solve every possible problem. Instead, they go deep on what they do best, offer a wide variety of customization options, and allow themselves to be plugged into other clients/platforms (web apps, portals, even office apps like excel). Instead of trying to be the be-all-end-all, they just become plug-able components to a larger architecture. That makes them easier to absorb/invest in, besides the fact that they are cheaper, too. In addition to Xcelsius and Flex, I’d also add the follow to this genre: Google Charts API, Dundas, Microcharts, Juice Analytics, Prefuse, Open Flash Chart. At one point, I’d include Alphablox in there, too, but IBM has buried it since its acquisition over 4 years ago.
The biggest hurdle for these cheaper options is probably distribution. Especially if the tools being leveraged are Excel-based (plugins, macros, hacks, …) like if the physical dashboard being distributed is just an Excel file. Part of the reason the collective enterprise moved to the web is because it solved a massive distribution and maintenance issues. The thin client removes the need to figure out how to publish new files and/or get software updates required for the thicker alternatives.
I don’t buy the “support” argument (e.g. big software vendor “X” has better support than these small niche shops). It sounds like a repeat of a portion of the Firefox vs. MSIE argument (e.g. security patches depend on the desire of a so-called disorganized, unaccountable set of freelance developers vs. a large organization w/ the experience, know-how, and funding to provide sufficient levels of support). Smaller organizations are typically more open, nimble, ready, and willing to respond to all their customers (both to support requests and ideas for new features)…and their user community is better connected and more willing to share learnings. When it comes to support issues, I’ve enjoyed dealing on these “smaller” scales than waiting for someone to pick up my support request of a bloated and bureaucratic queue.
That being said, you might always feel more comfortable investing in a product from a large vendor vs. something else, for the simple reason of long-term viability. There are no guarantees in life, but the big boys aren’t going anywhere. However, this is probably another weak argument, because eventually, even the biggest of software vendors will sunset support for the product you invest in today. Software life spans are incredibly short no matter who’s name is on the box.
So, I say go for it. At least go through a trial period and use it to prototype/POC something. If you don’t end up using it for a production app, at least the prototype can serve as a requirements gathering tool. I’m a big proponent of high-fidelity prototyping, which is very difficult to do for BI applications. I haven’t done this before, but toolsets like Google Charts API might make high-fidelity prototyping more of a reality in BIPM solutions.