Kalido — CASE for complex data warehouses
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.
Comments
One Response to “Kalido — CASE for complex data warehouses”
Leave a Reply
Curt,
There are a couple of things that make Kalido different to “CASE for data warehouses” (which is why we refer to it as an Information Management Engine).
1) Kalido has components in the runtime environment. Load, validation, suspense processing, housekeeping utilities for database rebuild, purge, archive, restore. When you use Kalido you are really getting a data warehouse, not just a data warehouse design tool.
2) The MDM component of Kalido is an application. It is functionality for business users to govern and manage the content of master data before it enters the warehouse.
These runtime components adapt to changes in the business model without programming too, which is part of the secret sauce, and how Kalido BI systems can be changed very rapidly (because so much is driven from the business model rather than being ‘hard coded’)
Regards
Cliff
So I just wanted to set the record straight