Model the business, not just its tables.

An enterprise ontology defines the kinds of things a business works with, their properties and the relationships between them. Customer, Order and Shipment are concepts; order date and promised delivery date are properties; “a customer places an order” and “a shipment fulfils an order” are relationships. The model makes business assumptions explicit instead of leaving them hidden in application code or individual knowledge.

A schema describes the structure of stored data. An ontology describes the meaning of business concepts and their relationships. A knowledge graph can represent specific entities and connections using such a model. These ideas complement one another: an ontology does not automatically replace a database, and not every graph provides a clear business definition for its edges.

An order connects a customer to purchased products. Shipments describe fulfilment; invoices describe billing; payments describe settlement. These relationships let you investigate why an order was late or whether an invoice has been paid without treating sales, logistics and finance as unrelated datasets. Real data may contain partial shipments, multiple invoices and incomplete links; those cases need explicit treatment.

The Talamys website demonstrates a shared business foundation, a connected enterprise map and evidence behind a KPI. You can move from a business object to its relationships and then to illustrative supporting records. This makes the model understandable to people who know the business without requiring them to start from database structure.

Choose a concrete question and identify the smallest set of concepts needed to answer it. Define relationships with business owners, map them to source records and check exceptions. Expand only after the initial model answers the question clearly. A useful ontology is maintained as definitions and sources change; a large diagram alone is not enough.