Introduction

Data Framework is a data life cycle framework that provides the Temenos Transact customers to realise the huge potential value of the transactional data generated by Temenos Transact. This is achieved by using a read-only Dimensional (DIMal) database optimised for near real-time predictive analytics and modelling tools.

Data Framework provides the infrastructure to create and maintain a read-only database in near real time using Extract Transform and Load (ETL) process, to ensure a database which is optimised for reporting. It also provides the ability to design and execute queries against the read only database. It leverages the Temenos Transact Interaction and Integration frameworks, so that the data is available in near real-time.

The below diagram represents the components of Data Framework reporting.

The Temenos Transact transactional database contains the current (live) and aged (historical) data. The historical data is non-volatile and is used mainly for query and reporting purposes. Hence, this data can be moved to a Reporting database (DB) which is then used for querying purposes. This also leads to the reduced size of Temenos Transact Transactional database to a greater extent which improves the turnaround time of the transaction processing during online and Close of Business (COB).

The data life cycle management performs the following activities:

• Processes the business event initiated in Temenos Transact transactional database and updates the relevant tables in Temenos Transact Transactional database.
• As business events occur, the data is collected and stored in the Integration framework event table.
• Data captured by the Integration Framework is extracted (no ESB) into the staging area.
• Mappings are defined between the source data structure and reporting model, including transforms where required.
• Data is picked up from the staging area, transformed into reporting model format (organised) and then loaded into the model in the Reporting DB in near real time.
• Each Business Reporting model covers one or more business functions or domains.
• A DIMal data model is created which identifies this as selectable data (optimised for fast read).
• Data is stored with full history of change at the lowest level of detail possible.
• Views, queries and reports can be created in the read-only operational Reporting DB for near real-time predictive analytics.

The Operational Reporting DB is deployed as a series of reporting models targeting different business domain such as:

• Customer and Account Balance Reporting model (product - DA).
• Financial Reporting model (product - DZ).

Product Configuration

The DIMal data model consists of tables grouped into Domain and Support tables.

• Domain tables relate to specific business Domain and Support tables provide additional details to the business domain, and is common across all the other business domains.
• Some attributes of the Domain and Support tables are volatile in nature while the others are non-volatile.
• The volatile attributes are stored in FACT tables, like account movements and balances. The non-volatile attributes are stored in Dimension (DIM) tables, like customer, currency and account officer.

The database also consists of Reference tables and Snowflake schema tables:

• Snowflake schema - Since some attributes of certain DIMal tables are multi-valued, these DIM tables are normalised into multiple related tables in a Snowflake schema.
• Reference tables - Some tables are added into the DB model to provide additional description or values to a field(s) defined in the DIM or FACT tables.

Each Business Reporting model has their own FACT and DIM tables depending on the nature of the data being used for the model.