Beyond the Pipeline – Sam Matysen | Craft 2026

June 04, 2026

Beyond the Pipeline – Sam Matysen (Talk Outline)

Sam Matysen argues that becoming a “true data-driven enterprise” takes more than pipelines and dashboards — you want data that enables and informs decisions. He shares the journey he is running together with Allianz Technology, moving data from an IT project to a business-owned product, via federated governance, domain-driven ownership, and evolutionary architecture. The talk runs: why data is special → what typically goes wrong → guiding principles → a phased approach → a real Allianz example → role-specific takeaways → Q&A.

1. Why Data Is a Special Area

1.1 Data is transparent

It’s a footprint of everything the company/operating entity does — showing what’s going wrong and what’s going well.
Managed well, it gives a clear picture of what’s happening in the company.

1.2 Data is inclusive

Generated by everyone — accounting, sales, every function.
Consumable by everyone — an “open book” so everyone can see where the company stands and how they can help growth.

1.3 Data is enabling

Especially in the age of AI, data matters more and more.
Beyond integrations with operational systems and dashboards, you want real, fast decisions and insights that would otherwise be hard to make.

2. What Tends to Go Wrong

2.1 Silo methodology

Big companies with many operating entities/business units where everyone does their own thing.
Result: many similar-but-slightly-different systems/solutions → reuse is hard (getting easier with AI).
More important: scattered logic — one part of the business signs off on logic, another disagrees, and the two never talk. This is the main thing to avoid.

2.2 Tech-first thinking

Data projects are still treated as an IT thing; better to treat them as a data product where IT and business come together.
The town-hall trap: a slick tech demo (“look what we built with Databricks, with GenAI”) — but who’s actually using it? → low adoption.
For leaders: unclear return on investment, driven by that low adoption.

2.3 Governance as an afterthought

Governance should be considered from the start of any data project; otherwise you build on shaky foundations.
Their practice: choose a governance model, iterate, and implement from the start.
Skipping it risks compliance issues (critical in insurance/Allianz) and a lack of ownership — ownership being essential for long-term product success.

2.4 Wrong operating model — “project” not “product”

Data is often run as a project: start, budget, goal, finish, then a “change and run” phase.
Bad fit for data, which must constantly evolve with the business and needs feedback loops.
Without that, projects “bleed out” — good at the initial stage, then the business moves on while the project stays stuck → declining added value and rising cost.

3. Guiding Principles (High-Level Approach)

3.1 Federated governance

Not one central authority defining everything — instead a shared framework with agreement on certain base elements.
Reality: every enterprise has multiple maturity levels — finance is usually strong with data (they can’t work efficiently otherwise); sales historically weaker (focused on selling / being close to the customer).

3.2 Domain-driven data ownership

The bridge between business, IT, and the data product — what keeps data products aligned to business needs.
Without it, business and data implementation drift apart over time.
Both data and business sides must know exactly what their responsibilities are — ideally reflected in each person’s yearly goals/targets.

3.3 Composability

A common approach to tackling data initiatives across areas so you don’t reinvent the wheel each time.

3.4 Evolutionary architecture

It’s easy to design a “perfect” architecture — but business needs change, data changes, and AI arrived with impact you couldn’t fully predict 2–3 years ago.
Architecture doesn’t need perfection; it needs to be robust to change.

4. Starting From Enterprise Architecture

4.1 Four connected areas

Business, Information, Application, Technology — data must connect to all four; it doesn’t live in a separate area.
First step: bring enterprise architecture into consideration.

4.2 Start from the business — capability + value stream

Most important: start with one business area (a capability), and within it pick a value stream — an end-to-end collection of processes where value is generated.
Map your data initiative to a capability and a value stream. Skip this and you’ll struggle to define ownership, domains, and everything else.
From the top, you also derive the business goals/achievements the initiative can enable.

5. The Phased Approach (as run at Allianz Technology)

5.1 Phase 1 — Align to capability & value stream

Align the data product to a capability and a value stream.
Run a value-stream mapping exercise covering both the data and the business side; assess maturity (where they stand, what’s possible).
Sit with business and define business outcomes — not an output, dashboard, self-service interface, or AI chatbot, but a business outcome.

5.2 Phase 2 — Solutioning

Once there’s agreement, establish domain ownership — a direct connection to business, from the start, as part of governance.
Design data contracts and interfaces — they provide both automation and transparency toward business and everyone working with the data.
Build with a big focus on data quality and lineage so everything is observable — people know what data they use, produce, consume, and own.
Incorporate context from the beginning — increasingly important as AI use cases grow.

5.3 Phase 3 — Operating-model evolution

Move from a project approach to product delivery — you maintain a data product (a conglomeration of what business needs to make informed decisions), not just ship a one-off.
Establish more cross-functional teams, implement feedback loops.
Evolve the governance model “from gate to garden” (detailed in the example).

5.4 Phase 4 — Scaling

Once the first three phases are proven, pick and choose what works.
Leverage the observability, context, and documented decisions to extract a reusable playbook — new domains/capabilities/value streams start not from scratch.
Big focus on communication — people need to know the data exists, what you’re doing, and what you achieved → network effects compound.

6. Real-Life Example — Allianz Commercial Data Platform

6.1 The situation

Multinational insurance company with multiple data platforms; Matysen’s is focused on the commercial portfolio.
Running 2–3 years with good early wins, but not seeing adoption → decision to revamp.

6.2 Phase Zero — align with EA and business

Sit with enterprise architecture and business leadership: understand goals, pain points, and priorities before anything technical.

6.3 Strategic anchoring — pick by business impact

Nominate a pilot capability based not on data maturity but on biggest business impact.
Chosen: Sales & Distribution, specifically the customer acquisition value stream.
Concrete target: increase medium-sized customers by 2% by year end (“doesn’t sound exciting, but a lot goes into it”).
Done with business and IT via workshops bringing the whole team together (not just a product owner or business analyst) so they understand each other and the goal.

6.4 The go/no-go milestone

A major milestone gates the next phase: every team member can articulate the transformation goal — non-technical, no solution, everyone on the same page about the problem and the goal. Only then continue.

6.5 Design & build — “Customer 360”

Create a new domain, Customer 360 — all customer data in one place so people can make informed decisions (acquiring customers, examining the base, matching external market data).
Set up the governance framework: data stewards, product owners, and business champions (consulted when questions arise).
Set up core platform components with scalability and observability from the start — fast to implement, but scalable when a new value stream/capability arrives.
- Leverage Databricks components (strong for discoverability).
- Parameterize pipelines rather than writing declarative “if this line of business, then that” logic — everything scalable based on the data.
- Capture and enrich data streams with context — so both people and AI agents can work with the data efficiently.

6.6 Operating model in practice

Initial delivered product: a Customer 360 profile dataset — a full view of existing customers, showing where the company is competitive in the market and where the gaps are.
Enable more teams: new data products like account relationship graphs and customer portfolio health.
Formalize a feedback framework — primarily scaled agile methodologies (which already have good feedback loops), plus documenting and sharing it.
Governance shift: a rules-and-roles-based approach — reframing governance from “what people shouldn’t see” (limiting) to “what people need to make decisions” (enabling) — the shift “from gate to garden.”

6.7 Scaling out — framework, communication, upskilling

Build scaffolding for a framework by extracting the documented decisions from the initial phase.
Dedicated communication people: gather use cases/input and do “marketing” for the project — an often-overlooked outward step; a good solution is worthless if no one knows about it.
Big focus on upskilling — become a trusted advisor to the business so they come to you with issues and become a stronger partner.
Result so far: adoption and interaction growing, more “buzz,” business units reaching out proactively to join → now in the scaling phase (exciting, with challenges “maybe for next year”).

7. Takeaways by Role

7.1 For data engineers & analysts

Think beyond the pipeline — understand the business and the capability you’re enabling (logistics, finance, insurance…). A prerequisite is understanding what you’re trying to achieve. (“One of the things I love about data is you get to see so many businesses in depth.“)
Design for reuse — not so much in the pipelines as in architecture and ways of working: data contracts, self-service interfaces — to unburden yourself of menial work.
Document everything — helps in later discussions and in handing over repetitive work.

7.2 For architects & tech leaders

Treat data as a first-class citizen — in the EA roadmap and in the enterprise itself.
See governance as an enabler, not a blocker.
Look beyond dashboards/products to the “glue”: metadata, lineage, context, observability.

7.3 For business leaders

Co-own your data product — data is collaborative by nature, not an IT thing.
Don’t start with solutions/outputs — start with success in business terms, then trust the executors to find the best solution.
Fund products, not projects — a mindset change toward long-term enablement over A-to-B delivery.

8. Q&A

Q1 — Biggest friction with multiple tools in delivery; how to manage? Start from enterprise architecture direction, work IT+business together toward a common way of working. Architecture must adapt to multiple sources/tools; a clear long-term direction becomes a driver, with the data product “in the driving seat.”
Q2 — What specialties are in your cross-functional data product teams? Technical people (data engineers, DevOps), plus strong business/data analysts who understand data but talk in business terms — the key translators between business and data concepts.
Q3 — Balancing quick wins vs. a scalable foundation? Everyone struggles with this. Start with a pilot, not a full scalable foundation (which would be obsolete by the time it’s built). Iterate on what works, then branch out — consistently doing this yields both delivery speed and long-term consistency.
Q4 — Friction with multiple tools (repeat). In the age of AI/agents, where you focus efforts matters less; what matters is portable observability and lineage and that data is consumable. “It’s not that important what’s in the back end.”
Q5 — Change one thing about how orgs approach data transformation? The collaboration between business and IT — see data as the connection between the two, enabling the enterprise to evolve, not just software to develop.
Q6 — Starting a new data project next month, one thing to do differently? Start by looking at the business — don’t think about data yet. Understand it, be able to communicate it, then move to data and solutioning.
Q7 — When existing architectures don’t fit / adopting new tech? They’re doing a restart: keep the historical data, but declare a cut-off point and restart the implementation.
Q8 — A surprising lesson from transformation at Allianz scale? Hard to surprise a veteran, but: you assume business already has the answers and alignment; up close, some data can’t integrate because there’s no business integration — acquisitions and mergers take a long time to align. Business transformation must happen first, then data transformation; data is a footprint, so without business alignment you won’t get the expected results.

People, Companies & References Cited

Sam Matysen — speaker.
Allianz Technology / Allianz — multinational insurance company; IT provider context for the case study.
Databricks — platform components leveraged (esp. for discoverability).
Customer 360 — the pilot domain / delivered data product.
Scaled agile — the feedback framework used.
Concepts: federated governance, domain-driven data ownership, data contracts, evolutionary architecture, “gate to garden” governance, value-stream mapping, “fund products, not projects.”

Video: https://www.youtube.com/watch?v=Hm3ylIzf-vY — Transcript via yt-transcript.sh; outline generated from the transcript.