Programma

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?

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.

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.

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.

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.

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.

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.