HOOK

Yes, you are right, you might have not heard, or implemented HOOKS before. This is a new term introduced by Andrew Foad.

HOOK is a technique to Data Warehousing especially proper to Data Lakehouse and virtualized architectures, but having said that it can be applied on any SQL based database. It is a hybrid methodology that borrows features from other methodologies such as Data Vault and Kimball dimensional modelling.

Whereas Data Vault and Kimball methodologies have multiple table types (Hubs, Links, Satellites, Dimension, Facts, etc.), HOOKS has a single structure called a Bag, which is used to wrap existing data warehouse table and exposes Business Keys which align to Business Concepts define in the Enterprise Data Model (EDM).

Bags align with data ingested into the data warehouse from the operational system (source-aligned) and Business Concepts defined in the Enterprise Data Model (business-aligned).

Typically, Bags are implemented as views (though they don’t have to be) defined over existing data warehouse tables. Business Keys are exposed as HOOKS Keys, each aligning with a Business Concept that must be represented in the EDM, for example, Customer, Order and Product.

Each HOOKS Key must be qualified with a Key Set, which formally identifies a set of values to which the Business Key belongs. Keys Sets make certain that after Bags are joined in SQL queries, best Business Keys with the identical Key Set will match, which avoids unintended matches.

Unlike Data Vault, HOOKS does not require upfront modelling before ingesting data. Ingestion/acquisition and business modelling are performed independently in separate sprints. Once complete, Bags are constructed at some stage in Alignment sprints.

There is a common misconception that HOOKS is a data warehouse modelling approach. It is not; it is an approach used to organize data warehouse objects around business language. Bags, therefore, are self-describing, telling us what parts of the business might be impacted by or responsible for the data and where it came from.

It should also be noted that HOOKS does not prescribe any specific modelling approach. For example, if you want to build Kimball-style dimensional models, then you are free to do so, but you must also embed the necessary HOOKS Keys.

HOOKS is an extremely simple and flexible approach to data warehousing. It can be layered over existing architecture with little or no impact. Because Bags can be represented as views, they can be dropped and recreated without reloading data or consuming any resources, which makes the approach extremely agile.

Podcast

SELECT

la.LoanApprovalID,

la.HK_Loan,

c.Name AS CustomerName,

c.Segment AS CustomerSegment,

o.Name AS OfficerName,

o.Branch AS OfficerBranch,

d.CalendarDate,

la.LoanAmount,

la.InterestRate,

la.Status

FROM Frame_LoanApproval la

LEFT JOIN Frame_Customer c

ON la.HK_Customer = c.HK_Customer

LEFT JOIN Frame_Officer o

ON la.HK_Officer = o.HK_Officer

LEFT JOIN Frame_Date d

ON la.HK_Date = d.HK_Date;

Teaching Point

• Notice that all joins use Hook columns (HK_Customer, HK_Officer, HK_Date) instead of raw business IDs.
• Because Hook values include Key Sets, there’s no risk of C123 from CRM colliding with C123 from CoreBank.
• This enforces integration + subject orientation without redesigning source schemas.

How this reads (Hook logic in one line)

• LoanApproval LA001 is HK_Loan = ‘LSYS1.LOAN.ID|L001’, belongs to HK_Customer = ‘CRM.CUS.ID|C123’ (Ali), handled by HK_Officer = ‘HR.OFF.ID|O045’ (Noor), and approved on HK_Date = ‘CAL|20250105’.
• LoanApproval LA002 is HK_Loan = ‘LSYS2.LOAN.ID|L002’, belongs to HK_Customer = ‘CBNK.CUS.ID|C456’ (Sara), handled by HK_Officer = ‘HR.OFF.ID|O067’ (Rizal), and approved on HK_Date = ‘CAL|20250110’.