Kalido
From Wikipedia, the free encyclopedia
| Kalido | |
 |
|
| Type | Private |
|---|---|
| Founded | 2003 |
| Headquarters | Burlington, MA, USA and London, UK |
| Key people | Bill Hewitt, President and Chief Executive Officer |
| Industry | Data Warehousing and Master Data Management Software |
| Website | www.kalido.com |
Contents |
[edit] History
The ideas behind Kalido started in 1985, when the Royal Dutch/Shell Group began twelve years of advanced data-modeling research, involving highly generic models and time variance.
Between 1997 and 2000, a Shell team led by Andy Hayler spotted the opportunity to develop KALIDO software on the basis of this research to solve the challenge of obtaining performance information across multiple Shell organizations throughout business change. The software was deployed within Shell in 100 countries worldwide, powering dozens of projects and generating tens of millions of dollars of annual cost savings.
2001
- Kalido is established as a software company within Shell and begins to market KALIDO externally, primarily in Europe
- Unilever buys the first KALIDO global license
2002
- Version 7 of KALIDO launched.
- Kalido opens first sales office in the US.
- Kalido wins first US customer.
2003
- Kalido becomes an independent software company and appoints a new CEO
- Atlas Venture and Benchmark Capital make significant Series A investments in Kalido
- Kalido incorporates in the US and opens US headquarters
- Kalido secures UK patent for the revolutionary technology that powers KALIDO
2004
- Kalido secures Series B investment led by Matrix Partners
- Kalido launches Systems Integrator Partner Program
- Version 8 of KALIDO is launched
- Kalido signs its 25th Global 2000 customer
- Kalido celebrates 1000th trained user of the KALIDO Active Information Management Software
2005
- Kalido signs largest deal in the company's history
- Kalido opens new, expanded headquarters in both Burlington, MA and London, UK
- Kalido Technical Advisory Board is launched
- Kalido secures Series C investment
- Bloor Research awards Kalido Gold Award in 2005 "Packaged Data Warehouses" report
- Kalido achieves nearly 70 percent year-over-year revenue growth
2006
- US Patent granted for the technology underlying some of the fundamental features of the KALIDO Active Information Management Software
[edit] Management Team
Bill Hewitt - President and Chief Executive Officer.
Brian Hartlen - Vice President, Marketing.
Cliff Longman - Chief Technology Officer.
Joan Nevins - Chief Financial Officer.
Nigel Turner - Vice President, Product Development.
Feb 2007
[edit] Applications
KALIDO DIW - the Dynamic Information Warehouse
KALIDO MDM - Master Data Management
[edit] KALIDO DIW - The Dynamic Information Warehouse
The architecture of KALIDO DIW is based on "generic data modeling" principles. Generic data modeling is an advanced database design technique that offers advantages over conventional designs. Shell developed the technique and offered the data design approach to the ISO standards community. The approach is now used extensively within the ISO STEP world.
The approach involves the structure of the data being held as data, rather than being defined by a specific physical database design. Generic data modeling is a radical departure from traditional data modeling principles.
[edit] KALIDO MDM - Master Data Manager
KALIDO MDM is a software application for harmonizing, storing and managing master data over time. It increases the consistency and accuracy of corporate performance reporting by enabling business people to collaboratively manage and control master data in a workflow-driven environment. It produces a master data warehouse from which “golden-copy” master data can be distributed to enterprise applications and business people throughout the organization.
KALIDO MDM features:
• Manages of any type of master data — from products and customers to brands, markets, territories and more.
• Facilitates data governance in a collaborative, workflow-driven environment
• Flexible master data modeling—featuring cataloging, segmenting, merging and mapping facilities
• Loads non-conformant master data — all master data is loaded even if it doesn’t conform to the master data model. Workflows can be used to ensure that the data—or the model—is revised accordingly
• Maintains master data history
[edit] Generic Modeling and the Data Warehouse
The generic structure, compared to the traditional data warehouse design based on third normal form schemas and snowflake or star schemas, has both advantages and disadvantages.
Advantages
- The generic structure can store time variant business context data (i.e., changes to the business context data that happen over time such as a reorganization where departments are grouped differently), without requiring any database design changes. By contrast, traditional data models represent a snapshot of the requirements that were valid at the time the model was created. This makes it difficult to store historic data, which may require as much analysis as the current data. Often historic information is discarded
due to the extra design required.
- The generic structure presents a highly standardized approach to loading and retrieval, enabling the automatic creation of loading and retrieval routines by KALIDO DIW.
- The generic structure enables the loading of new classes of data through the simple addition of a few records of metadata.
Conventionally, changes in requirements cause changes to the design, requiring a database administrator to alter the table structure of the warehouse and to reorganize the data in the database. The costs and time involved can be considerable.
- The generic structure allows the capture of complex business rules that are difficult to capture using a conventional relational structure.
- The use of metadata allows the structure of business context and transaction data to be easily understood by business users.
Disadvantages
A pure implementation of generic modeling principles will bring with it some disadvantages such as:
- Conventional star schema can give better performance than physical implementations of the generic structure8. KALIDO DIW addresses
these issues by combining elements of the generic structure with those of a star schema.
- The generic structure supports the business structure by holding multiple rows, linked by pointers, instead of the conventional
columns in a table. This makes the data difficult to read and the SQL difficult to write, requiring a codegenerating front-end to read and load data. KALIDO DIW has such a code-generating front-end.
- The star schema design is well understood by the data warehouse community, in particular by consultants and vendors of tools
for OLAP. The generic structure is an unconventional design that has more in common with object orientation techniques than traditional data modeling principles.
Despite the generic structure being different from conventional designs, it is far easier to query once understood as it combines the business metadata dictionary with the business context data. Finding out where something is stored is far simpler than navigating through hundreds of obscure tables.
Implications
Given the above advantages and disadvantages, a mix of the generic design for business context data and the star schema for transaction data and retrieval would make an ideal situation. This has been the basis for the physical implementation of KALIDO DIW. The results of the KALIDO implementation have proved that this innovative design can, and does, work. Kalido has UK patents on this design. The generic design of KALIDO DIW is highly flexible but could have made processing transactions against the hierarchies of business context data it rather inefficient. To improve performance, the complex hierarchies are automatically flattened out by KALIDO DIW to create "mapping" tables.
These mapping tables are complex and contain the full structure of the business context data hierarchies, including the date and time stamping of changes. They are regenerated when either the master data or its structure change so KALIDO DIW fully manages both the generic data storage and its replication in mapping tables. This replication is done incrementally and can be delayed so that bulk changes can be made over a period with only a single generation of the mapping tables concerned. This ensures that optimum performance is delivered, in accessing both the generic data for exploration queries and the mapping tables for OLAP queries.
The creation of mapping tables makes a KALIDO warehouse appear like any other star schema. Conventional star schemas include the business context data, but they are keyed reference tables with all the attributes, classifications, etc. as columns. This causes duplication of data and difficulty in maintenance, but is fast to process. This is why the KALIDO warehouse can equal the query performance of a conventional design. The creation of the mapping tables can be a scheduled task or the user can initiate it. Batch tasks can also be used for business context data loading, transaction loading, summary generation, mapping table generation, data mart building, or export of transaction or business context data.
Data marts are generated by extracting information from the warehouse in a form that can be analyzed using tools such as Excel or BusinessObjects to slice and dice, or drill-down through it. The data mart can be separated from the database, and small ones can take the form of Excel pivot tables, which can be taken away on a portable computer for offline analysis.
In summary, one of the requirements of a data warehouse is that it should be capable of storing and managing almost any data from any source.
In a KALIDO warehouse:
- Information is held in a neutral format, i.e. not limited to a particular type of business data.
- There are neutral formats for transaction data and business context data.
Metadata is used for:
- validation and loading of data into the warehouse
- structuring data in the warehouse
- defining data marts
The neutral formats allow you to select and view information as you want in data marts.
