What's Your Baseline? Enterprise Architecture & Business Process Management Demystified

There has been a lot of consolidation in the process/architecture space in the last few years, mostly driven by PE firms. But why is that so, and why does it seem that there is no alternative to this business model?
Back in the day there were foundations behind the companies, or they were privately held, and the only thing (besides a few smaller players you might not even have heard of) that I see are some open-source projects in the automation space … mostly driven by the decision to go closed-source by Camunda.

To implement AI (and processes) correctly, you need good data. But what does that mean? Well, firstly it means that you can define your data product and to achieve that you need good data governance.

But are we now in a super-nerdy topic? No, this is what we all do in some form or another … but in different fidelities and maturities.

To shed some light on the topic of data governance, we invited Angelika Rinck for this episode. She started her career studying public administration and then served in the German federal police before switching to the regular industry (in the aerospace industry, and while that might not be enough, she studied economics in parallel).

Somehow she found her way into consulting and is working now in digitalization and IT projects. Her main focus here is product lifecycle management and data governance.

In this episode of the podcast, we talk about:

• Angelika’s career journey: from e-commerce working student in Hamburg to aerospace, engineering, and ultimately major IT and data governance initiatives.
• Her first agile project—complete with a physical Kanban box—sparked her love for IT project management and structured delivery.
• A detour into underwater orienteering reveals surprising parallels to data work: precision, navigation, and making decisions in the dark.
• Defining data governance: the framework of rules, processes, and responsibilities that guide how organizations create, use, secure, and improve data.
• Why it matters: Governance drives clarity, accountability, and value creation—not just control or compliance.
• Understanding the difference between data governance (framework and value creation) and data management (the operational “doing”).
• A common failure pattern: organizations naming “business data stewards” without training, tooling, or understanding the expectations.
• Governance only works when decentralized experts feed real issues into a central team—not when policies are pushed top-down in isolation.
• Data products demystified: they’re the outcome of well-governed data—reusable, high-value information assets that improve processes, decisions, speed, or cost.
• Real examples: using historical field data instead of simulation data to accelerate engineering calculations or using decades of bird-flight video to predict weather with AI.
• Risks of bad data with AI: incorrect system guidance, support tickets exploding, contradictions between outdated documents, and misplaced trust in “the easy button.”
• Governance foundations: critical data identification, metadata transparency, ownership, RASCI clarification, and understanding who creates, changes, and consumes data.
• The messy reality: access rights often don’t match process needs—leading to shortcuts, bypasses, and unintended process redesign opportunities.
• Final takeaway: data governance isn’t bureaucracy—it's a structured path to value, clarity, and safer AI adoption, but it requires real effort, definitions, ownership, and cultural change.

In this episode, we welcome Finnish enterprise architect and author Eetu Niemi to explore what it means to make enterprise architecture (EA) “lightweight”—practical, collaborative, and relevant in the real world. From frameworks to fiction writing, from ivory towers to coffee-fueled collaboration, this conversation dives into how to make EA actually work for organizations.

With over 16 years of experience in architecture consulting at CGI, Coala, and Accenture, Eetu has guided more than 45 private and public organizations in transforming their business and IT landscapes. He specializes in enterprise and solution architecture, helping organizations align technology with strategy, improve EA practices and tools, and strengthen information security.

A published author and recognized thought leader, he wrote the first EA book in Finnish and two bestsellers on IT consulting and frequently shares insights through blogs, newsletters, and speaking engagements. Holding a PhD in enterprise architecture benefit realization and an MSc (Econ.), his cross-industry work spans finance, telecom, manufacturing, and the public sector—delivering results in EA modeling, governance, and tool implementation with platforms such as BiZZdesign, Ardoq, and Sparx EA.

In this episode of the podcast, we talk about:

• Eetu’s background — Author, architect, and advocate for democratizing enterprise architecture so it’s accessible beyond the ivory tower.
• Rethinking EA’s relevance — Success comes when EA shifts from being “nice diagrams” to being indispensable guidance that helps organizations plan, adapt, and reduce risk.
• Defining “lightweight EA” — It’s all about communication and cooperation, using models as tools for dialogue, not as ends in themselves.
• Avoiding EA’s common traps — Filling every box in a framework or modeling everything down to cables and servers misses the point. EA should focus on solving real business problems.
• Where to draw the line — Model at the logical level (applications, processes, data) — not every internal detail. EA is the layer above IT and process modeling, not a replacement for them.
• Kickstarting EA right — Start small, plan with stakeholders, and document goals and methods early. Collaboration beats over-engineering every time.
• Who to talk to first — Don’t wait for the C-suite; start where you have access, build trust, and work your way upward.
• Quick wins matter — Focus on tangible outcomes like system maps for upcoming projects — those early wins open doors and earn invitations “to the next party.”
• Light tools for light EA — Begin with approachable modeling tools instead of overcomplicated platforms. Save the big systems for when you truly need them.
• Governance without the grind — Keep EA blueprints current but concise. A handful of well-maintained diagrams is better than hundreds of forgotten files.
• Collaboration is key — EA succeeds through engagement: creating models with people, validating them with people, and helping those people make better decisions.
• Selling the value — Show how EA helps others succeed — whether that’s IT planning, compliance, or transformation — and you’ll overcome “I have no time for this” resistance.
• EA + AI = opportunity — Complexity is growing, not shrinking. AI can help classify, visualize, and assist — but architects still provide the judgment and storytelling.
• Making EA stick — Keep the practice alive through persistence and visibility. Even when budgets tighten, lightweight EA thrives by staying practical, connected, and useful.

Last week we took a deep(-er) look at what BPMN is today and pointed out the scope, difficulties, and misconceptions in the current specification.

But what are ideas for improvements?

I am glad that you asked, because this episode is exactly about this (with a slight twist to the business side of things). In this episode of the podcast, we talk about:

• Today’s topic: What should BPMN 3.0 look like? Spoiler—it's more than just dots and arrows.
• The hosts unpack the missing hierarchy in BPMN—why we need clear distinctions between high-level, process, and task models. Roland argues for flexibility and “N levels of process”—from value chains down to sub-processes.
• J-M pushes for decision levels—models as tools for making decisions, not just communication artifacts.
• Call activities: misused, misunderstood, and overcomplicated. The guys agree—most analysts don’t touch them right.
• A deep dive into lanes and pools—why they’re conceptually fine but practically messy. (Stop naming your pool after your process, people!)
• Both want organizational elements as first-class citizens—RACI, org roles, and system links built right into the spec.
• Execution vs. documentation: the eternal BPMN dilemma. Should the spec drive engines, or help humans? (Hint: both.)
• J-M dreams of BPMN models training AI agents. Roland gets heartburn just thinking about it.
• “Lanes need intelligence.” The duo agree that automation, RPA, and AI will force clarity in BPMN sooner rather than later.
• Roland throws shade at the spec’s quality control—gateways aren’t decisions, folks! Read the fine print.
• The conversation drifts into data, risks, and controls—areas where BPMN could learn a lot from EPC and real-world practice.
• We are discussing other objects: “page connectors” (process interfaces), groups, milestones, etc.
• Closing thoughts: BPMN 3.0 should unify the best of documentation and execution, EPC’s expressiveness, and OMG’s rigor—with a bit more consistency, please.