Nieuwe tijden: Van Data voor AI naar AI voor Data
We zijn gewend om data te beheren vóór de inzet van AI: zorgvuldig verzamelen, schonen en structureren. Maar die tijd kantelt. AI helpt nu zélf om data te verbeteren: automatisch te verrijken, te valideren, te integreren en te documenteren. Van statisch beheer gaan we naar dynamische verbetering: AI maakt data levend en verandert hoe we met data omgaan.
De volgende onderwerpen en discussiepunten worden behandeld:
- Data wordt door AI een levend, zelflerend systeem.
- Fouten en ontbrekende data kunnen automatisch worden opgespoord en gecorrigeerd.
- Databronnen vloeien straks automatisch samen.
- Classificatie, documentatie en compliance worden in toenemende mate realtime ondersteund.
- De belofte van minder handwerk lijkt binnen handbereik, hoe ver staan we er werkelijk vanaf?
Grounded AI in Data Warehousing: How to Make Your LLM Stop Lying [Engelstalig]
Hallucinaties door AI kunnen het vertrouwen in Business Intelligence-outputs ondermijnen. Deze live technische sessie laat zien hoe u een door LLM aangestuurde analyse-assistent bouwt die alleen antwoord geeft op basis van gecontroleerde, geverifieerde gegevens. Met behulp van Snowflake Cortex Semantic Models, Cortex Analyst en Cortex Search brengen we zakelijke termen in kaart aan de hand van daadwerkelijke definities, genereren we automatisch veilige SQL en traceren we elke stap voor controleerbaarheid. U ziet de volledige stack in actie, met architectuurdiagrammen en codepatronen die u kunt implementeren.
De belangrijkste punten zijn:
- Hoe u LLM’s in uw semantische laag kunt integreren.
- Hoe u tekst-naar-SQL veilig in BI-workflows kunt integreren.
- Hoe u AI-output traceerbaar en verdedigbaar kunt maken.
- Hoe u ongestructureerde documenten en gestructureerde data in één systeem kunt koppelen.
- Hoe u observatievermogen in AI kunt inbouwen, zodat u weet wanneer het systeem faalt.
Semantic modeling or modeling semantics?
Een semantische context is benodigd voor zowel menselijke gebruikers als AI-agents om te begrijpen waar de data die ze zien over gaat en hoe ze deze moeten gebruiken. Semantische lagen zijn de technologische oplossing die onze engineering teams momenteel graag als oplossing voorstellen. Maar hoeveel van het werk dat we rond semantische lagen doen heeft eigenlijk met semantiek te maken? En hoe zit het met alle andere gegevens in de organisatie die nooit door uw semantische laagtechnologie gaan?
Hoewel de bedoeling van semantische lagen en de bijbehorende modellering goed is, richten veel implementaties zich op technologie en houden ze geen rekening met de feitelijke semantiek. We zullen dit schijnbaar paradoxale probleem onderzoeken en een weg voorwaarts overwegen, naar een echte bedrijfscontext die niet alleen op individuele datasets wordt toegepast, maar ook op bedrijfsniveau.
De volgende onderwerpen en discussiepunten worden behandeld:
- De huidige rol van de semantische laag als query-abstractie.
- Waar halen we de semantiek vandaan – de lelijke waarheid.
- De volwassenheidscurve van semantische modellering, van cargo cults tot universele semantiek.
- Het ontdekken van de werkelijke bedrijfscontext met behulp van conceptuele modellering.
- Semantiek die verder gaat dan één laag – het koppelen van datasets op oplossingsniveau aan semantiek op bedrijfsniveau.
- Semantiek voorbij analytics – AI-use cases en meer.
De holistische data-architectuur: van bron tot inzicht
Veel organisaties worstelen met complexe datavraagstukken. Denk aan het vastleggen van datagebruik (zowel transactioneel als analytisch), het correct en volledig beheren van datahistorie, het synchroniseren van bronsystemen, het kunnen reconstrueren van gebeurtenissen (operationele lineage), het toegankelijk maken van data en rapportages via metadata, het stroomlijnen van data-uitwisseling en het voorbereiden van data voor AI-toepassingen.
Vaak wordt de oplossing gezocht in referentie-architecturen zoals het datawarehouse, datalake, datalakehouse of de datafabric. Hoewel waardevol, bieden deze architecturen geen antwoord op bovengenoemde uitdagingen. Ze richten zich slechts op een deel van het datatraject en lossen de kernproblemen niet op.
Om deze uitdagingen écht aan te pakken, moet een data-architectuur het volledige datatraject omvatten: van bron tot inzicht. Alleen een holistische benadering kan dit realiseren. Tijdens deze sessie bespreken we een data-architectuur die het hele traject beschrijft. Hierin kunnen de genoemde architecturen wel een rol spelen, maar slechts als onderdeel van een groter geheel.
De sessie behandelt onder andere:
- De drie soorten IT-systemen: bronsystemen, compensatiesystemen en analysesystemen
- De positionering van datawarehouses, datalakes en datalakehouses als compensatiesystemen
- Een overzicht van de Delta data-architectuur
- Hoe bronsystemen toekomstbestendig gemaakt kunnen worden door ze te ‘wrappen’ met aanvullende modules
- Het belang van abstractie en dataminimalisatie binnen een data-architectuur
- De rol van metadata als drijvende kracht achter een moderne datawinkel.
Data Governance Sprint: Start Governance in Slechts Enkele Weken
Zijn jouw data governance-inspanningen vastgelopen in eindeloze discussierondes of blijven ze steken op papier, zonder tastbare resultaten? De Data Governance Sprint™ is een bewezen en versnelde methode om binnen vijf weken een praktische basis voor data governance neer te zetten. Deze sessie introduceert een gestructureerde, workshop-gerichte aanpak die verder gaat dan theorie en concrete resultaten oplevert: duidelijke rollen, een business glossary, een werkend operating model en snelle successen die momentum creëren. Ontwikkeld voor data-leiders en praktijkmensen helpt deze methodologie je alignment-problemen te overwinnen, stakeholders te betrekken en meetbare vooruitgang te boeken.
- Begrijp waarom governance-initiatieven vaak mislukken—van gebrek aan momentum tot niet-betrokken stakeholders—en hoe een sprintaanpak deze barrières wegneemt
- Ontdek de 5-weekse Data Governance Sprint™-structuur—een getimede, herhaalbare methode om kerncomponenten van governance te ontwerpen, bouwen en valideren
- Leer praktische facilitatie-technieken om onproductieve meetings om te vormen tot impactvolle workshops die business en IT rond gedeelde doelen op één lijn brengen
- Leer om een prototype te maken en minimale governance-deliverables te testen zoals een business glossary, een lichtgewicht operating model en duidelijke data stewardship-rollen
- Ontdek praktijkvoorbeelden en lessons learned van organisaties die de sprint toepasten om adoptie te versnellen, valkuilen te vermijden en verandering duurzaam te maken
- Vertrek met een concreet actieplan om een governance-initiatief in jouw organisatie te lanceren of te herstarten, met snelle resultaten én een basis voor langetermijnsucces.
Van Hive naar Iceberg: De nieuwe generatie open table formats voor data lakes
Data lakes staan op een kantelpunt. Waar Hive jarenlang de standaard was, zien we nu een explosie van nieuwe open table formats: Apache Iceberg, Apache Hudi, Delta Lake en nieuwkomers zoals DuckDB. Ze beloven allemaal betere prestaties, ACID-transacties en flexibeler schema-beheer. Maar welke keuze maakt u?
Deze sessie biedt praktische handvatten voor architecten en engineers die voor deze beslissing staan. U krijgt inzicht in hoe elk format omgaat met schema-evolutie, time travel, transacties en metadata. Belangrijker nog: wat betekenen deze verschillen voor de prestaties, betrouwbaarheid en kosten van uw dataplatform?
Aan de hand van concrete implementaties bespreken we de valkuilen, verrassende voordelen en verborgen complexiteit van elk format. Of u nu een bestaande Hive-omgeving moderniseert, een nieuw data lake bouwt of een lakehouse-architectuur overweegt: u gaat naar huis met een helder besliskader om het juiste format te kiezen én te kunnen verantwoorden richting het management en uw team.
Highlights:
- Formats vergeleken: Diepgaande vergelijking van Ducklake, Iceberg, Hudi, Delta Lake en Hive op ACID-garanties, partitionering, query-performance en operationeel beheer
- Lessen uit de praktijk: Ervaringen uit productieomgevingen, migratiestrategieën, performance-optimalisatie en kostenoverwegingen bij petabyte-schaal
- Ecosysteem-integratie: Hoe elk format werkt met bv Spark, Flink, Trino, Dremio en DuckDB, welke cloudplatforms worden ondersteund en waar vendor lock-in dreigt
- Verborgen kosten: Operationele overhead, benodigde teamkennis en onderhoudskosten die verder gaan dan storage en compute
- Beslismodel: Praktisch stappenplan om te bepalen welk format past bij uw architectuur, workloads en strategische ambities.
Lunchpauze
Borrel
Data Mesh Information Architecture: modeling data products and domains [Engelstalig]
Data Mesh is a federated approach to data management and governance developed by Zhamak Dehghani. It’s structure is based on domains and data products, elements that have also seen wide attention from organizations that are not otherwise working towards a full Mesh implementation. Working with autonomous domains who share data to the rest of the organization via data products is an excellent way to bring data work closer to the business and to allow domain-specific prioritization instead of a massive centralized bottleneck team. However, with domains having their own understanding of business and its core concepts, semantic interoperability becomes a challenge. This workshop focuses on the problems of Information Architecture in a de-centralized landscape. How can we document what data we have available, how do we understand what other teams’ data means, and how do we maintain a big picture of what is where? We will explore conceptual modeling as a key method of documenting the business context and semantics of domains and data products, more detailed logical modeling as a means to document data product structures, and consider both within-domain and cross-domain linking of various models and objects in them. As a hands-on exercise, we will model a domain and design some example data products that maintain strong links with their domain-level semantics. The workshop will give you the basic skills to do data modeling at these higher levels of abstraction, and understanding of the key characteristics and challenges of the Data Mesh that affect the way we need to do data modeling.
Learning objectives
- Understand the basics of the Data Mesh paradigm and its challenges relating to information architecture and semantics
- Learn the basics of conceptual modeling as a method of defining the business context of domains and data products
- Learn the basics of logical modeling as a part of data product design process
- Learn how solution-level metadata (e.g. data contracts) can expose domain-level context across domain boundaries
- Understand the basic operating model of information architecture management in the context of independent domain teams within a Data Mesh setup
Who is it for
- Data Architects
- Chief Data Officers and Heads of Data interested in federated operating models
- Data Product Owners and Team Leads working in a federated model
- Data Governance experts
Detailed Course Outline
1. Introduction
- Welcome and introductions
- Course agenda and goals
2. Data Mesh basics
- General idea
- Four pillars of Data Mesh according to Dehghani
- Domains and domain teams
- Data products
- The interoperability challenge
3. How conceptual models help with cross-domain understanding
- Basics of conceptual modeling: entities, relationships, and attributes
- How to identify the real business objects
- Building definitions and glossaries
4. Hands-on exercise: modeling a domain
- Domain boundaries
- Identifying entities within the domain
- Definitions and “domain ontology”
5. Data modeling as part of data product design
- Understanding product scope as part of the domain model
- Logical model as product-level design & documentation
- Deriving logical models from conceptual model
- Maintaining links with the domain model
- What happens when the product expands beyond the domain?
6. Ensuring semantic interoperability at the domain boundary
- Exposing metadata from domains and data products
- Data contract basics
- Domain glossaries vs. shared enterprise glossaries
- Dealing with polysemes
7. Data Mesh information architecture operating model
- Domain team responsibilities
- Data product owner responsibilities
- Platform team responsibilities
- Federated governance
8. Conclusion
- Key takeaways
- Where to start in your organization
- How to learn more
Concept Modelling for Business Analysts [Engelstalig]
Whether you call it a conceptual data model, a domain model, a business object model, or even a “thing model,” the concept model is seeing a worldwide resurgence of interest. Why? Because a concept model is a fundamental technique for improving communication among stakeholders in any sort of initiative. Sadly, that communication often gets lost – in the clouds, in the weeds, or in chasing the latest bright and shiny object. Having experienced this, Business Analysts everywhere are realizing Concept Modelling is a powerful addition to their BA toolkit. This session will even show how a concept model can be used to easily identify use cases, user stories, services, and other functional requirements.
Realizing the value of concept modelling is also, surprisingly, taking hold in the data community. “Surprisingly” because many data practitioners had seen concept modelling as an “old school” technique. Not anymore! In the past few years, data professionals who have seen their big data, data science/AI, data lake, data mesh, data fabric, data lakehouse, etc. efforts fail to deliver expected benefits realise it is because they are not based on a shared view of the enterprise and the things it cares about. That’s where concept modelling helps. Data management/governance teams are (or should be!) taking advantage of the current support for Concept Modelling. After all, we can’t manage what hasn’t been modelled!
The Agile community is especially seeing the need for concept modelling. Because Agile is now the default approach, even on enterprise-scale initiatives, Agile teams need more than some user stories on Post-its in their backlog. Concept modelling is being embraced as an essential foundation on which to envision and develop solutions. In all these cases, the key is to see a concept model as a description of a business, not a technical description of a database schema.
This workshop introduces concept modelling from a non-technical perspective, provides tips and guidelines for the analyst, and explores entity-relationship modelling at conceptual and logical levels using techniques that maximise client engagement and understanding. We’ll also look at techniques for facilitating concept modelling sessions (virtually and in-person), applying concept modelling within other disciplines (e.g., process change or business analysis,) and moving into more complex modelling situations.
Drawing on over forty years of successful consulting and modelling, on projects of every size and type, this session provides proven techniques backed up with current, real-life examples.
Topics include:
- The essence of concept modelling and essential guidelines for avoiding common pitfalls
- Methods for engaging our business clients in conceptual modelling without them realizing it
- Applying an easy, language-oriented approach to initiating development of a concept model
- Why bottom-up techniques often work best
- “Use your words!” – how definitions and assertions improve concept models
- How to quickly develop useful entity definitions while avoiding conflict
- Why a data model needs a sense of direction
- The four most common patterns in data modelling, and the four most common errors in specifying entities
- Making the transition from conceptual to logical using the world’s simplest guide to normalisation
- Understand “the four Ds of data modelling” – definition, dependency, demonstration, and detail
- Tips for conducting a concept model/data model review presentation
- Critical distinctions among conceptual, logical, and physical models
- Using concept models to discover use cases, business events, and other requirements
- Interesting techniques to discover and meet additional requirements
- How concept models help in package implementations, process change, and Agile development
Learning Objectives:
- Understand the essential components of a concept model – things (entities) facts about things (relationships and attributes) and rules
- Use entity-relationship modelling to depict facts and rules about business entities at different levels of detail and perspectives, specifically conceptual (overview) and logical (detailed) models
- Apply a variety of techniques that support the active participation and engagement of business professionals and subject matter experts
- Develop conceptual and logical models quickly using repeatable and Agile methods
- Draw an Entity-Relationship Diagram (ERD) for maximum readability
- Read a concept model/data model, and communicate with specialists using the appropriate terminology.
Boek ook een van de praktische workshops!
Drie internationale topsprekers verzorgen de dag na het congres boeiende en zeer praktische workshops. Congresdeelnemers genieten combinatiekorting dus aarzel niet en boek snel want deelname aan de workshops is gelimiteerd.
24 maart 2026
Zaal 1 Eevamaija Virtanen
Zaal 1 Mathias Vercauteren
Zaal 1 Jos van Dongen
Plenair
Workshops 2026
25 maart Juha Korpela