Is Your Data GenAI Ready for Data Citizens with Paul Grobler

Executive Summary

This webinar addresses the challenges that drive the high failure rate of Gen AI projects, emphasising the need for a robust Business Architecture that aligns data citizens with strategic objectives. Howard Diesel and Paul Grobler highlight the risks of misalignment, the significance of a robust capability foundation, and the ArchiMate framework as a common language for Enterprise Architecture. Additionally, the webinar emphasises the importance of modelling stakeholders and their pain points, establishing measurable SMART goals, and introducing a prioritisation framework to balance value and feasibility in project execution.

Webinar Details

Title: Is Your Data GenAI Ready for Data Citizens with Paul Grobler
Date: 2026-02-12
Presenter: Howard Diesel & Paul Grobler
Meetup Group: African Data Management Community
Write-up Author: Howard Diesel

Introduction: Why 95% of Gen AI Projects Fail

Howard Diesel opens the webinar and shares that this session will address the alarming industry reality. According to PMI research, 70% of projects fail, while Harvard studies show that 95% of generative AI projects fail to deliver ROI. This training course tackles these statistics by starting where organisations should begin—at the business level, not with technology.

Howard and Paul Grobler begin their presentation of a Data Architecture course that will explore a comprehensive framework, from strategy to execution, designed to close the gap between implementation and the delivery of actual AI requirements. The course integrates multiple enterprise frameworks: BizBok, TOGAF, DCAM, DMBoK, ISO 42001, NIST frameworks, and ISO 30401 (knowledge management).

Five core training outcomes drive the curriculum: business alignment (ensuring data and AI strategies support business goals), scalable architecture (creating systems that meet current and future requirements), governance by design (embedding governance principles from the beginning), knowledge as a product (treating organisational knowledge as a strategic asset), and practical application of frameworks.

The four-day training agenda progresses logically: Day 1 focuses on Business Architecture; Day 2 covers Information Architecture, including semantics and taxonomy; Day 3 addresses Data and Technical Architecture, as well as Governance and AI; and Day 4 features a capstone project. Participants work through realistic insurance-industry case studies and then apply their learnings to their own organisational contexts. This hands-on approach ensures immediate implementation capability across government, banking, and other sectors.

Figure 1 AI-Ready Enterprise Architecture

Figure 2 From Strategy to Execution: AI-Ready Enterprise Architecture & Governance

Figure 3 Training Outcomes

Figure 4 Course Agenda (4+1 Days)

The Business Architecture Challenge – Why Data Citizens Need It

A fundamental challenge repeatedly emerges: data citizens rarely receive a comprehensive Business Architecture to align their strategies with. Howard emphasises that while data citizens don’t need to create Business Architecture themselves, they must understand what they need and how to request it from Enterprise Architects.

Howard then poses a direct question: “If you want me to align my data strategy and AI models, please give me a Business Architecture to align to. What am I building a data strategy on without it?” This captures common frustration: being asked to develop data strategies without valid business strategies or a clear vision.

Attendees share their own sobering real-world experiences. One attendee describes being hired for “data strategy” that actually meant technical platform architecture—data modelling techniques and technology selection. When requesting a business or product strategy, he often discovers that nothing exists or only “another consultant’s one-slide with a triangle.” Without understanding how the business makes money and its direction, what’s created isn’t strategy—it’s a guess.

Another attendee shared a striking example from a large oil company that once prided itself on process management and Enterprise Architecture. When new leadership arrived with a “back to profit” mandate, they laid off entire teams—business process management and Enterprise Architecture—to improve the share price. While the stock doubled, this represents “lip service” to strategy.

The consensus: data citizens need specific artefacts from Business Architecture—value streams, capability maps, process models, and clear business objectives. These provide the essential foundation for successful data and AI initiatives.

Figure 5 Business Architecture and Strategy Alignment

Figure 6 Business Architecture and Strategy Alignment: Foundations for Business-Driven Data & AI Initiatives

Consequences of Misalignment and the Capability Foundation

Howard presents a cautionary tale from his experience: an AI innovation hub built on a “build it, and they will come” philosophy. The team analysed data to create impressive visualisations using Python, virtual reality, and cutting-edge technologies. Business visitors became excited—one person described a visualisation as looking “like a butterfly.”

However, when asked how they could apply these innovations to their business, most admitted they didn’t know. Despite the technology being cool and visualizations fancy, there was no clear business application. Within six months, the innovation hub closed, resulting in wasted investment and a mismatched solution.

This illustrates fundamental consequences: technology that looks impressive but delivers no business value, and failure to meet actual AI requirements. The “build it, and they will come” mentality works for some high-tech companies introducing groundbreaking technologies, but for most organisations, jumping on technology without a sound business foundation rarely succeeds.

Howard introduces a critical concept many organisations overlook: business capabilities. While most people understand business processes, capabilities represent a more strategic, stable view. A capability answers: “What do we need to be capable of doing to deliver value?”

An attendee then provides a practical example: his oil company created a business capability matrix with 27 high-level boxes—produce oil, transport oil, trade oil—with drilldowns to processes and data elements. The critical distinction: capabilities define the “what” independent of “how,” making them more permanent than processes and technology-independent, providing ideal anchor points for architecture.

Figure 7 Why Business-Driven?

Figure 8 Business Architecture Basics

Business Capabilities Explained – The Stable Foundation

Business capabilities provide the stable foundation that processes cannot. The insurance example illustrates this clearly: to deliver value to customers (protecting them against theft or accidents and paying claims), the company must be able to settle claims, establish policies, process payments, and reassess value. These capabilities remain stable even as technology and processes change dramatically.

Howard emphasises the critical distinction: capabilities define the “what” independent of “how.” Business processes can be changed, automated, or eliminated entirely by AI. An AI system might settle claims with a button press, making the process almost disappear. But the organisation still needs the capability to settle claims regardless of the implementation method.

This stability makes capabilities the ideal anchor point for aligning architecture and strategy. Processes come and go—they can be delivered by people, applications, AI, or automation. Process models can change dramatically with new technology. But capabilities persist.

For example, whether claims settlement takes two weeks with manual processing or two minutes with AI automation, the organisation needs a claim settlement capability. Whether policy establishment is done on paper forms or mobile apps, the organisation needs this capability.

This permanence and technology independence make capabilities foundational. Data strategies, AI initiatives, and technology roadmaps should be anchored in capabilities rather than transient processes. When process models change—as they inevitably will with digital transformation—capability-anchored architectures remain valid. This approach prevents the constant rework that plagues process-centric architectures when organisations adopt new technologies or methodologies.

Figure 9 Frameworks: BIZBoK and TOGAF

Figure 10 Link to Data Strategy (DCAM)

Figure 11 InsuranceCo Context

Figure 12 InsuranceCo Context pt.2

ArchiMate Framework – A Common Language for Enterprise Architecture

Howard then introduces ArchiMate, an Enterprise Architecture language developed by The Open Group. Paul differentiates between ArchiMate, the language (an open standard notation), and Archi, the tool (an open-source, free application for ArchiMate modelling). ArchiMate serves Enterprise Architecture the same way UML serves system design, or ERD serves data modelling.

An attendee shares how ArchiMate literally saved his job during a cyber incident. When contractors were sent home and couldn’t access the company’s enterprise modelling tool (Abacus), having Archi installed on his Mac allowed him to continue working standalone, earning him two months of income during furlough.

The ArchiMate framework uses intuitive colour-coding across layers from strategy to implementation: yellow represents business objects (processes, services, actors), dark orange indicates strategy elements (capabilities, value streams), purple shows motivational objects (goals, drivers, assessments), blue represents application and Data Architecture, and green indicates Technology and Physical Architecture. This aligns with TOGAF’s four layers, making diagrams immediately interpretable.

Paul then demonstrates how to translate business challenges into ArchiMate models. In the insurance company example, the high-level goal “modernise claims” is negatively affected by three factors: slow settlements, fraud, and significant pressure on customer experience. These become typed objects with specific influence relationships—making implicit knowledge explicit.

Practical trade-offs: while best-practice documents describe objects, displaying them as visible notes improves readability. An important insight about audiences: C-level executives often prefer cleaner slides, while senior citizens appreciate ArchiMate diagrams because they demonstrate rigorous thinking and provide confidence that recommendations are well-modelled.

Figure 13 ArchiMate Framework

Figure 14 Architecture Model

Figure 15 Stakeholders & Pain Points

Modelling Stakeholders and Pain Points – Building the Ontology

Effective Business Architecture begins with understanding stakeholders and their challenges. The insurance company case identifies four key stakeholder groups: policyholders (customers frustrated by slow payouts and lack of claim status transparency), claims adjusters (internal operations burdened by manual processes and data access difficulties), agents and brokers (struggling with outdated interfaces and information gaps), and management and finance (leadership needing visibility but lacking real-time dashboards).

In ArchiMate modelling, stakeholder objects represent these groups and are connected to assessment objects that describe specific pain points. This process forces important questions: Is a policyholder a type of customer? How do roles relate to organisational structure? Paul introduces the “party master” view—a dedicated ArchiMate view modelling how parties (individuals or organisations) relate to roles, specialisations, and contexts.

The demonstration shows how Archi‘s visualizer feature reveals the ontology being built. Each object and relationship creates a graph database, allowing traversal. Clicking “policyholder” shows it connects to the assessment “frustrated by slow payouts” and belongs to the “customers” container. This becomes invaluable during meetings—when someone mentions a name, process, or system, searching the model instantly reveals all connections.

This stakeholder analysis isn’t static documentation—it becomes a living ontology that team members reference during engagements. Paul shares that he always keeps Archi open during meetings. Names are easy to forget, but the model captures organisational context. This knowledge capture transforms documentation into an interactive analysis tool, providing context across complex organisations and capturing not just job titles but also SME roles for specific data pipelines or processes.

Figure 16 Stakeholders and Pain Points

Figure 17 You’re also Building an Ontology

Figure 18 ArchiMate: Stakeholder Analysis Visualiser

Figure 19 ArchiMate: Pain point Analysis Visualiser

Figure 20 Pain point Analysis Visualiser Expanded

Figure 21 Pain Points Expanded

Figure 22 Strategic Objectives

Strategic Objectives and SMART Goals – Making Strategy Measurable

Strategic goals must translate into specific, measurable objectives. The insurance company’s claims modernisation initiative establishes four SMART objectives (Specific, Measurable, Achievable, Relevant, Time-bound): reduce settlement time by 50% within 12 months, reduce fraud losses through earlier identification of suspicious patterns, improve renewal rates by enhancing the customer experience, and raise Net Promoter Score.

In ArchiMate modelling, these require careful interpretation and untangling. Goal objects represent objectives, driver objects capture underlying business motivations (like customer satisfaction), and outcome objects define target metrics and timeframes. An important insight emerges during modelling: customer satisfaction appeared twice in the original materials but wasn’t explicitly connected. Creating the ArchiMate model reveals this duplication and allows consolidation.

This demonstrates how modelling doesn’t just document existing knowledge—it clarifies and improves strategic thinking by forcing precision and revealing hidden relationships. Goals can specialise into sub-goals, creating manageable hierarchies. The big goal, “modernise claims,” breaks into four specific goals.

Howard then emphasises that each objective needs a clear rationale. For “reduce settlement time,” the rationale is that faster payouts directly improve customer satisfaction, with a target metric to reduce average cycle time. This level of precision prevents common KPI challenges—misunderstandings of metrics, unclear ownership, and inconsistent definitions.

When organisations talk about revenue or customer lifetime value, confusion often arises about what it means, who owns it, and where it’s defined. Doing this work upfront—clearly defining metrics and their relationships—should significantly reduce that confusion later during implementation.

Figure 23 Strategic Objectives

Figure 24 Strategic Objectives pt.2

Figure 25 Stakeholder and Pain Points

Live ArchiMate Demonstration – Interactive Knowledge Navigation

Paul demonstrates Archi live, showing how the tool creates interactive, traversable knowledge graphs. Opening any view and clicking an object activates the visualizer panel, which displays all relationships as an ontology. The depth setting controls how many relationship levels display—one level keeps views simple, while two levels show more complex connection patterns.

Each view in Archi focuses on a specific aspect (stakeholders, objectives, capabilities), but all views share the same underlying model. Drawing a line between objects in any view updates the entire ontology. This creates a powerful capability: during engagements with Archi, always open, searching for any person, process, or system mentioned in meetings instantly shows all connections, roles, and responsibilities.

Paul shares he’s been using ArchiMate for 10 years, often sitting with CTOs and even CEOs doing live modelling during sessions. Executives adopt this approach because they’re not accustomed to seeing discussions at this level of precision—it creates clarity and confidence in recommendations.

The visualizer isn’t a generated presentation view—it’s an interactive analysis tool. While you wouldn’t include it in board presentations, for architects, consultants, and data citizens navigating complex organisations, this capability proves invaluable. The ability to instantly traverse relationships, understand context, and recall organisational structure compensates for natural memory limitations.

As architects model concepts and draw relationships, they’re building what amounts to a graph database—an organisational knowledge graph that captures not just structure but also the semantic relationships between business elements, technology components, and strategic drivers. This becomes organisational memory that persists beyond individual recall.

Figure 26 Defining Use Cases: the Data Initiative Canvas

Figure 27 Prioritising Use Cases: Impact Vs. Feasibility

Figure 28 The Data Product Lifecycle: From Idea to Value

Figure 29 Value Stream: Settle Claims

Prioritisation Framework and Moving Forward – Balancing Value and Feasibility

A critical question emerges: with multiple strategic objectives and defined metrics, how do you prioritise? Should prioritisation happen at the Business Architecture level, data strategy level, or AI implementation level? Mark notes that prioritisation often occurs above the Data Architect level, with senior Enterprise Architects making decisions based on broader business mandates.

Howard presents a challenge from experience: within two weeks of one engagement, 120 business challenges were identified. How do you define priorities among so many competing needs? He introduces his data value realisation framework using a data initiative canvas for each use case, linking to value propositions and evaluating risks and metrics.

The key innovation is a two-dimensional prioritisation matrix assessing both commercial feasibility (business value) and technical feasibility (skills, data availability, technology complexity). Paul Bolton contributes crucial insight: it’s a balance. Prioritising too early at the Business Architecture level without understanding technical constraints leads to unrealistic commitments. But waiting too long misses the essential business value perspective.

The consensus: business stakeholders own value and should prioritise at their level, but this must be informed by technical feasibility. Some objectives, like “reduce settlement time”, require end-to-end processing changes and complex AI implementation—larger initiatives. Others, such as “cutting fraud losses”, might be simpler, contained projects delivering quicker wins.

An attendee raises an important closing question about industry collaboration. Multiple groups work on similar frameworks—product lifecycles, data product workflows, prioritisation models. Is there an opportunity for cross-pollination? Even without standardisation, creating aliases showing alignment and divergence would prevent everyone from spending the same effort multiple times.

Figure 30 Mapping Capabilities to Value Stream