Kalido briefed me last week, under pre-TDWI embargo. To a first approximation, their story is confusingly buzzword-laden, as is evident from their product names. The Kalido suite is called the Kalido Information Engine, and it comprises:
- Kalido Business Information Modeler (the newest part)
- Kalido Dynamic Information Warehouse
- Kalido Universal Information Director
- Kalido Master Data Management
But those mouthfuls aside, Kalido has some pretty interesting things to say about data warehouse schema complexity and change.
For the long-timers among us, the best way to describe what Kalido really offers is CASE (Computer Aided Software Engineering) organized around modeling concepts relevant to data warehousing and analytic queries. The middleware or data movement tools that actually do anything are basically just implementers for the models.
Kalido positions these tools as helping with two big challenges:
- Changing schemas. That’s what we focused on in the call.
- Reconciling conflicting schemas. Generic example – different ways of setting up the dimensional hierarchy in different countries. (Kalido was originally an internal project at Royal Dutch Shell, which does business in 130 countries or so.)
Kalido’s defining application seems to be the tracking of revenue, profitability, etc. in a complex organization. Typical customers are product companies (including those in extraction businesses) or heavily regulated ones. Applications and scenarios Kalido with which might be less helpful are ones where the warehouse structure and is simple and relatively fixed, such as credit scoring, call detail record apps in telcos, or retailing. Similarly, Kalido doesn’t focus on helping with repetitive production reporting, although I suspect that point would be misleading if one tried to take it to an extreme.
In line with this application focus, Kalido supports Oracle, SQL Server, and DB2. They don’t see warehouses over 10 Tb of user data. They don’t have much demand for Teradata support (ditto other data warehouse specialists). And they don’t seem to live in the part of the data warehouse world where Mike Stonebraker estimates 99% of users have single-fact-table schemas.
The core functionality of Kalido’s suite is:
- You (re)design the schema of your warehouse with boxes and arrows.
- Your desired schema is generated (both in the database and in, e.g., Business Objects universes).
The design information is stored in a very thin schema – mainly one table. Generation happens only occasionally – i.e., when you’re rolling out new business intelligence apps or important reports, and making associated schema changes.
Different CASE tools are “intelligent” about different kinds of things. Kalido’s focuses on automagic handling of dimensional hierarchies. I.e., give it enough information to specify a hierarchy, and it will do so, without demanding that you fill in the rest. It will generate various denormalizations upon request. Kalido’s product will also remember old versions of the information, which can be helpful in running reports about historical periods. And it’s workflow/collaborative capabilities are focused on data governance and schema development.
Kalido’s overall claim is that data warehouse projects go 5-10X faster with their tools than without. (Presumably, this is based on experience without the latest iteration of their visual tools – and do please recall that it’s a vendor estimate, on a matter that can’t be rigorously tested.) Obviously, such a claim is plausible only if the schemas aren’t very simple, and if they aren’t already purchased from, say, an application vendor. And of course, since Kalido claims a development speed advantage, they also offer a rapid/agile/get-to-what-the-business-user-really-wants development-cycle story as a potential benefit.