Understanding Concepts, Details, and Events: The Fundamental Building Blocks of AgileData Design

09 Aug 2023 | AgileData Product, AgileData Way of Working, Blog


In the complex domain of data management and data modeling, the AgileData Way of Working introduces a hybrid pattern called Data Design, bridging Business Modeling and Physical Modeling patterns.

This pattern centers around three foundational terms:

Concepts, Details, and Events.

Concepts represent the core entities the organisation focuses on, like Customers or Products.

Details flesh out these concepts with specific attributes or characteristics.

Events capture the dynamic relationships and interactions between Concepts at particular point in time.

Together, these three elements form a shared language, likened to the nouns, adjectives, and verbs in a sentence, enabling a more coherent understanding and consumption of data across both business and data domains.

Shane Gibson - AgileData.io

Three Foundational Things

In the complex world of data management and modeling, understanding fundamental data modeling patterns is essential.

There are a myriad of data modeling patterns, relational, dimensional, data vault, activity schema and the very popular OBT (One Big Table)

As part of our AgileData Way of Working we have combined patterns from a Business Modeling pattern, BEAM and Physical Modeling pattern, Data Vault. 

Combining and adapting these patterns allowed us to create a hybrid set of patterns that can enable us to capture the required Business Model quickly in the AgileData App and then automagically convert it to a physical data model in the AgileData Platform.  We call this pattern Data Design.

Critical to Data Design are three foundational terms: Concepts, Details, and Events.

Concepts:  The Pillars of Data

Concepts are things that your Organisation manages or the main things they care about.

They are the main entities or objects that represented in data. Concepts act as keys that enable us to identify specific aspects within a vast ocean of data.

For example, in a retail domain, concepts might include Customers, Products, Orders, or Suppliers.

One way to identify Concepts is to look at the Core Business Process the Organisation is involved in  For example:

  • Customer Orders Product via Channel

  • Customer Pays for Order

  • Store Ships Order
  • Customers Return Product

Another way of identifying Concepts, is looking for the things the Organisation regularly counts. For example:

  • How many Customers do we have?

  • How many Products did we sell?

  • What is the total amount of the Orders for this month?

  • What Suppliers have not Shipped on-time this month?

  • Which Employee has taken more than 5 days Annual Leave this month.

Details:  Describing the Concepts

While Concepts provide the overarching categories, Details fill in the specifics.

Details are the attributes or characteristics that describe the Concepts.

Using our retail example, if “Customers” is a Concept, then the Details might include their Names, Date of Birth, Gender.  For the “Product” Concept, then the Details might include Product Name, SKU, Product Type, Price. For the “Order” Concept, then the Details might include Order Type, Quantity, Order Amount, Order Date.

Details give life to Concepts, adding depth and dimension. They help in personalising and understanding the concepts on a granular level, transforming abstract ideas into tangible information.

One way of identifying Details, is looking for the things the Organisation regularly counts. For example:

  • How many Male Customers do we have?
  • How many Products are in the Clothing Category
  • What is the total Sold Amount of the Orders for this month? 

Events: Capturing Relationships and Interactions

Events are perhaps the most dynamic component of the three. They represent the relationships or interactions between different Concepts at a specific point in time.

An Event could be a Customer Purchases Product, where a Customer (Concept) Purchased (Concept) a Product (another concept) on a specific Date (Detail).

Events are vital as they allow us to capture changes, transactions, and the connections between different entities. They tell the story of how Concepts interact with one another, providing a timeline and context to the data.

A Shared Language

Together, Concepts, Details, and Events create a rich and multifaceted language that can be shared by experts in both the business and data domains.

  • Concepts are like the nouns, representing the main subjects within the data.
  • Details act as the adjectives, adding descriptions and characteristics to those subjects.
  • Events are the verbs, describing the actions or relationships between the concepts at different moments.

In other words, if data were a sentence, Concepts would be the subjects, Details would provide the descriptors, and Events would illustrate the actions or interactions taking place.

The Data Design Triad

The triad of Concepts, Details, and Events forms the foundation of AgileData Design.

By distilling complex data into these foundational elements, organisations can navigate the vast seas of information with precision and clarity.

This shared language not only bridges the gap between technical and business stakeholders but also paves the way for innovative solutions, adaptive strategies, and more informed decision-making.


Keep making data simply magical

We leverage the Data Design pattern in our AgileData App, Platform and Way of Working.

The Core Business Event area on the Information Product Canvas is where we record any Concepts or Events we have discovered as we use our AgileData Ways of Working to quickly capture requirements. 

We then quickly capture the required Business Model in the AgileData App.

Then we automagically convert it to a physical data model in the AgileData Platform. 


Conceptually Modeling Concepts, Details and Events in AgileData

Join Shane and Nigel as they discuss on the AgileData Podcast how and why we define a conceptual model of Concepts, Details and Events in AgileData and how we map these to a physical Data Vault model.