Coral8 highlights some key issues with dashboards
Coral8 today is rolling out the Coral8 Portal, offering some BI basics for CEP (Complex Event Processing) filters and queries. In Release 1, this is primitive compared with other BI portals, and of direct interest only to organizations that have already decided they’re using CEP technology. Even so, it serves as a useful illustration of several important issues in dashboarding.
The simplest is that real-time dashboards require different visualizations than others. Most obvious is the ever-popular graph marching from right to left across the screen as time advances along the x-axis. There also are difference in styles between reports and tables that you actually read, vs. read-outs that you merely watch for flickers of change. (Of course those two examples hardly make for a complete list.)
More interesting is the flexibility and parameterization. While Coral8 sells to multiple markets, the design point for the portal is clearly financial trading. So, for example, a query may be registered with one ticker symbol, and an end user can easily customize it to slot in another one instead. In a way, this is a step toward the much greater flexibility that dashboards need overall.
Truth be told, if you put all such Coral8 flexibility features together they’re not yet very impressive. So what’s even more interesting is the overall architecture that could support much greater flexibility in the future. If dashboards gain the flexibility they need, and queries continue to be done in the conventional manner, query volumes will increase enormously. If it further is the case that they are upgraded in some near real-time manner, that’s another huge increase.
How huge? Well, I can make a case that it could be well over three orders of magnitude: 1+ because of the generally larger number of BI users in an enterprise, each with her own queries; 1+ from much faster refresh rates; and a third 1+ because with improved technology people will just naturally want to track more kinds of information than they do today. But – and this is a crucial point – those queries will fall into large families that are closely related to each other.
The relationship between the queries is crucial, because that’s what CEP (Complex Event Processing) technology is optimized for. A CEP engine like Coral8’s (ditto StreamBase or Progress Apama) runs incrementally changed data across a whole lot of different queries and filters. A key part of such engines’ optimization is to make sure that common parts to the queries are executed once rather than many times in succession.
Are CEP engines suitable, unchanged, for general enterprise BI? Almost certainly not. But I do think next-generation dashboards are apt to require next-generation BI engines, and I further think those engines will, at a minimum, borrow a lot of ideas from today’s CEP servers.
Comments
3 Responses to “Coral8 highlights some key issues with dashboards”
Leave a Reply
[…] But pending a briefing, I’m guessing that Kickfire’s sense is similar to what underlies the case for using CEP in BI. […]
[…] this is getting long, I’ll describe what I think needs to happen under the covers in a separate post. Share: These icons link to social bookmarking sites where readers can share and discover new […]
[…] this is getting long, I’ll describe what I think needs to happen under the covers in a separate post. Share: These icons link to social bookmarking sites where readers can share and discover new web […]