Looking for Analytic App Dev Tools

The advance of analytic technology is hindered by a collective software industry blind spot: There is no clear, convincing vision of the future of analytic application development tools. This makes it hard for enterprises to firm up their analytic technology strategies.

Fortunately, there are work-arounds to this problem. But before discussing them, here's a quick review of how the industry got itself into this bind in the first place. (For more historical detail, see my new blog, specifically the post at www.computerworld.com/blogs/node/280.)

Confusingly, query/analysis/ad hoc reporting products for the most part are application development tools. We speak, and rightly so, of business intelligence tools being used to create (and deploy) departmental BI applications. Enterprise reporting products are also app dev tools -- just think of how many application software vendors resell Crystal Reports. And more specialized analytic tools -- such as statistical or simulation packages -- generally have custom programming languages at their core.

Nonetheless, in recent years BI vendors have collectively taken their eyes off the app dev ball. The reason is twofold. First, BI products may operate like app dev tools, but they are generally sold like actual applications. A few years ago, BI vendors decided that applications had higher price points than dev tools and explicitly emphasized the "application" aspect of their offerings. Second, the BI industry has even more recently refocused on system software -- but the emphasis has been almost entirely on grand integrated enterprise analytics servers, not on the tools that make them useful.

Thus, some interesting analytic app dev products have fallen between the cracks. For example, Cognos had an app dev lead in Metrics Manager, while Business Objects had some interesting pieces in the oddly named Application Foundation. However, as far as I can tell, neither capability has been significantly advanced in several years. Nor has Oracle's BI Beans amounted to much. And the same goes for most of the rest of the BI industry.

There are two exceptions to these trends that spring to mind. One is enterprise information integration, or EII, when it morphs all the way into composite apps. The other is SAP's xApps, coincidentally also a composite apps strategy. I say "coincidentally" because the composite apps aspect of EII involves knitting technical processes such as Web services together, while the composite apps aspect of SAP's strategy is focused on the business process side.

But when combined, these examples suggest that if and when good analytic app dev tools finally come together, there will be a strong composite apps flavor. There almost has to be: Analytic/BI user interfaces need to be flexible, so conventional application generation wouldn't work.

There's also another piece to the story. For the past 15 to 20 years -- i.e., the entire BI era, and probably the executive information systems era as well -- the fundamental BI app dev paradigm has been declarative rather than procedural. This has been true on both the data access and user interface sides, and that's pretty much all there's been to the apps, some simple arithmetic for calculated fields excepted.

Well, calculated fields begat key performance indicators (KPI), and now there's a lot of them. A whole lot. A hard-to-manage whole lot. Don't believe people who say that the right number of KPIs for an enterprise is seven; 700 often isn't enough. Seven may be enough for one person in an enterprise, or all of one person's direct reports, but I question even that. At every level of the organization, and in every department and subdepartment, the appropriate KPIs are different. And yet another level of complication is the need for alerts associated with all those KPIs. Ultimately, the BI vendor with the best app dev capability may be the one that makes this KPI explosion easiest to manage.

The best work-around I can think of for the lack of tools (other than just sticking with packaged apps, which aren't far enough along for that to be a good idea) is modularization -- deciding that transactions are transactions, analytics are analytics, and the way to knit them together is via composite app dev tools. This still leaves an annoying problem with KPI management, but you'll just have to grin and bear with that part until the entire BI industry gets its act together.

Curt A. Monash is a consultant in Acton, Mass. You can reach him at curtmonash@monash.com.

Copyright © 2005 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon