Integrating Architecture, Processes, and AI on SAP BTP
Planning to implement AI and automation? Start by preparing your foundation. Most organizations document processes and architecture, but don’t connect them in a way that’s useful for AI models and automation workflows. This book shows you how to use SAP Signavio, SAP LeanIX, and WalkMe to transform your architecture and process data into a unified execution layer on SAP BTP. You’ll learn to model processes, map applications to process steps, capture adoption telemetry, design integration flows, and prepare data for AI and automation. Move from static documentation to an execution-ready SAP architecture!
- Integrate SAP Signavio, SAP LeanIX, and WalkMe data using SAP BTP
- Build an execution-ready canonical data spine for AI and automation
- Implement execution services, workflows, and SAP AI capabilities using the unified data model
You'll learn about:
- Designing the Canonical Data Spine:
Discover why point-to-point integrations fail and how to implement a normalized canonical model on SAP BTP. Define stable identifiers, ownership rules, versioning strategies, and audit mechanisms that support execution-grade automation and AI.
- Integrating Process and Architecture Data:
Structure process and architecture data for downstream consumption using SAP Signavio and SAP LeanIX. Map L4/L5 process steps to applications and interfaces, design ingestion flows, and build reusable execution services for process lookup, context enrichment, and change impact analysis.
- Enabling AI and Automation:
Prepare enterprise data for SAP’s AI services. Define eligibility rules, role-based scoping, grounding constraints, and human-in-the-loop validation. Deploy AI services on top of a secure, integrated foundation.
Key Highlights:
- SAP Signavio
- SAP LeanIX
- WalkMe
- AI execution
- SAP AI Core
- Generative AI Hub
- Automated workflows
- SAP Build Process Automation
- SAP Build Work Zone
- Security
- Monitoring
View Full Table of Contents
- Preface
- PART I Technical Context and Integration Principles
- 1 Why Enterprise Architecture and Business Process Architecture Data Must Be Integrated for AI Execution
- 1.1 The Structural Failure of Most Transformation Programs
- 1.1.1 Design, Delivery, Telemetry, and Improvement
- 1.1.2 The Enterprise Execution Pyramid
- 1.1.3 Why AI Amplifies Both Coherence and Fragmentation
- 1.2 Limitations of Isolated Process Repositories
- 1.3 Limitations of Isolated Enterprise Architecture Repositories
- 1.3.1 Architecture Without Execution Semantics
- 1.3.2 Middleware Drift and Disconnected Integration Logic
- 1.3.3 Architecture Describes Systems; Process Describes Execution
- 1.4 Why SAP AI Requires Unified Semantic Context
- 1.4.1 SAP AI Is Layered, Not Monolithic
- 1.4.2 What Each Layer Requires from the Semantic Foundation
- 1.4.3 The Specific Requirements of Generative and Agentic AI
- 1.4.4 AI Grounding Bundles and the Role of the Canonical Layer
- 1.5 The Role of SAP BTP as the Data Spine, Integration Layer, and Extension Layer
- 1.5.1 Three Architectural Roles of SAP BTP
- 1.5.2 Why Canonical Semantics Live on SAP BTP
- 1.5.3 Validation, Publication, and the Role of Boundary Enforcement
- 1.5.4 SAP BTP as the Coordinator of the Design-to-Delivery Loop
- 1.6 Non-Goals: What AI Must Not Automate
- 1.7 Summary
- 1.7.1 Key Learning Points
- 1.7.2 Common Design Pitfalls
- 1.7.3 Review Questions
- 1.7.4 Student Companion Notes
- 2 Reference Integration Architecture
- 2.1 Logical Architecture Overview
- 2.2 Authoritative Systems of Record
- 2.3 Data Ownership and Write Boundaries
- 2.3.1 The Three Write Boundary Rules
- 2.3.2 Why Boundary Enforcement Cannot Be Conventional
- 2.3.3 Worked Example: Tracing a Cost Center Update Across the Architecture
- 2.4 Integration and Extension Responsibilities
- 2.5 Execution and Consumption Layers
- 2.6 Security Architecture Principles for Process- and AI-Driven Integration
- 2.7 Identity, Authentication, and Authorization in SAP Signavio, SAP LeanIX, and SAP BTP
- 2.8 Data Access Segmentation and Role-Based Exposure of the Data Spine
- 2.8.1 Three Dimensions of Segmentation
- 2.8.2 Segmentation in the Token
- 2.8.3 Segmentation for AI Consumers
- 2.8.4 The Scope Vocabulary in Practice
- 2.9 Security Boundaries Between Execution Services, AI Services, and User Interfaces
- 2.10 Auditability, Traceability, and Non-Repudiation by Design
- 2.11 Allocation of Security Responsibilities Across Platforms
- 2.12 Summary
- 2.12.1 Key Learning Points
- 2.12.2 Common Design Pitfalls
- 2.12.3 Review Questions
- 2.12.4 Student Companion Notes
- PART II Configuring SAP Signavio for Execution and AI Readiness
- 3 SAP Signavio Data Model for Integration
- 3.1 L4 and L5 Process Object Requirements
- 3.1.1 L4 Process Step Objects
- 3.1.2 L5 Work Instruction Objects
- 3.1.3 Digital Discovery Assessment as the Source for L4
- 3.2 Process and Activity Identifiers
- 3.2.1 The Identifier Standard
- 3.2.2 Immutability and Renaming
- 3.2.3 Identifier-to-System Mappings
- 3.3 Mandatory Execution Attributes
- 3.3.1 Step Identifier
- 3.3.2 Performing Role
- 3.3.3 System Trigger
- 3.3.4 Application Reference
- 3.3.5 Control Intent
- 3.3.6 Data Objects In and Out
- 3.3.7 Key Performance Indicator Anchor
- 3.4 Roles, Variants, and Localization
- 3.4.1 The Six-Role Taxonomy
- 3.4.2 Swimlane Discipline
- 3.4.3 Variant Classification
- 3.4.4 Localization Markers
- 3.5 Versioning and Lifecycle Management
- 3.5.1 The Version State Machine
- 3.5.2 Change Rules: Major, Minor, Patch, and Variant
- 3.5.3 The Digital Thread: DDA to BPMN to Runtime
- 3.6 What Must Not Be Modeled in SAP Signavio
- 3.7 Summary
- 3.7.1 Key Learning Points
- 3.7.2 Common Design Pitfalls
- 3.7.3 Review Questions
- 3.7.4 Student Companion Notes
- 4 Extending SAP Signavio for Downstream Consumption
- 4.1 Standard Attributes Versus Custom Attributes
- 4.1.1 The Role of Attributes in an Integration-Ready Process Model
- 4.1.2 Standard Attributes: What They Cover and Where They Stop
- 4.1.3 A Disciplined Custom Attribute Strategy
- 4.1.4 Naming Conventions and Dictionary Management
- 4.1.5 Common Pitfalls in Attribute Design
- 4.1.6 Attribute Scoping: Process, Activity, Lane, and Workspace
- 4.1.7 Data Types and Controlled Enumerations
- 4.1.8 Worked Example: Custom Attributes Across Three Process Domains
- 4.2 External Reference Patterns
- 4.2.1 Defining an External Reference
- 4.2.2 Why URL-Based Linking Is Avoided
- 4.2.3 Reference Patterns by Target System
- 4.2.4 Multi-Valued and Qualified References
- 4.2.5 Governance of References Across Lifecycles
- 4.3 Preparing SAP Signavio APIs for Extraction
- 4.3.1 The SAP Signavio API Landscape
- 4.3.2 Authentication, Tokens, and Service Identities
- 4.3.3 Endpoint Inventory for Spine Ingestion
- 4.3.4 Scoping and Permissioning
- 4.3.5 Rate Limits, Pagination, and Backoff
- 4.3.6 Schema Versioning and Compatibility Discipline
- 4.3.7 Sample API Calls and Response Handling
- 4.3.8 Calling SAP Signavio APIs: SAP Integration Suite Versus Direct from SAP BTP
- 4.3.9 Operational Telemetry for the Extraction Flow
- 4.4 Event Versus Batch Export Considerations
- 4.4.1 Two Patterns, Two Failure Modes
- 4.4.2 Batch Export Design
- 4.4.3 Event-Driven Export Design
- 4.4.4 Reconciliation Between Event and Batch Exports
- 4.4.5 Decision Heuristics: Choosing the Right Pattern
- 4.4.6 Worked Example: A Reconciliation Cycle
- 4.4.7 Failure Handling and Operational Runbooks
- 4.5 Validation and Data Quality Checks
- 4.5.1 Where Validation Runs in the Extension Contract
- 4.5.2 Categories of Validation Checks
- 4.5.3 Severity Levels and Outcome Handling
- 4.5.4 Quarantine Versus Reject: Handling Bad Records
- 4.5.5 Closing the Loop with Modeling Teams
- 4.5.6 Worked Example: Validating an Execution-Ready Activity
- 4.5.7 Quality Scoring as a Leading Indicator
- 4.5.8 Worked Example: Validation Across a Process Variant
- 4.5.9 Auditability of the Validation Layer
- 4.6 Summary
- 4.6.1 Key Learning Points
- 4.6.2 Common Design Pitfalls
- 4.6.3 Review Questions
- 4.6.4 Student Companion Notes
- PART III Configuring SAP LeanIX for Dependency and Context Data
- 5 SAP LeanIX Data Model for Integration
- 5.1 The Running Scenario: Cost Center to Position
- 5.2 Application Objects Required for Integration
- 5.2.1 The Integration-Eligible Application
- 5.2.2 The Mandatory Attribute Set
- 5.2.3 Application Versus IT Component
- 5.2.4 Worked Anatomy of an Application Factsheet
- 5.2.5 The Application Inventory Discipline
- 5.2.6 Application Factsheet: Build Specification
- 5.3 Interface and Dependency Modeling
- 5.3.1 What Belongs on an Interface Factsheet
- 5.3.2 Dependency Modeling and Chains
- 5.3.3 Worked Example: Cost Center to Position
- 5.3.4 Hub Interfaces and the Limits of Direct Modeling
- 5.3.5 Interface Factsheet: Build Specification
- 5.4 Lifecycle and Change-Related Attributes
- 5.4.1 The Five-Phase Lifecycle Model
- 5.4.2 The Two Approval Flags
- 5.4.3 Lifecycle Transitions as Governance Events
- 5.4.4 Beyond Phases: Other Change-Related Attributes
- 5.4.5 Phase-to-Consumer Visibility Matrix
- 5.4.6 Lifecycle Attribute Set: Build Specification
- 5.5 Stable Identifiers and Keys
- 5.5.1 The factSheetId as a Primary Key
- 5.5.2 External Identifiers as Resolvable References
- 5.5.3 Identifier Changes as Governance Events
- 5.5.4 Binding Identifiers to Activities
- 5.5.5 SAP Fiori App ID as a Secondary Identifier
- 5.5.6 Identifier Set: Build Specification
- 5.5.7 Cross-Chapter Field Name Glossary
- 5.6 Avoiding Overlap with SAP Signavio
- 5.6.1 The Division of Responsibility
- 5.6.2 Anti-Patterns and Their Costs
- 5.6.3 Worked Example: Boundary: Cost Center to Position Propagation
- 5.7 Summary
- 5.7.1 Key Learning Points
- 5.7.2 Common Design Pitfalls
- 5.7.3 Review Questions
- 5.7.4 Student Companion Notes
- 6 Mapping SAP LeanIX to Process Semantics
- 6.1 Linking Applications to L4/L5 Activities
- 6.1.1 The LEANIX|APPLICATION Reference
- 6.1.2 Cardinality and the Single-Execution Location Rule
- 6.1.3 Activity_Stable_ID as the Owner of the Binding
- 6.1.4 Resolution at Lookup Time, Not at Binding Time
- 6.1.5 Worked Example: Cost Center to Position Application Bindings
- 6.2 Interface-to-Process Relationships
- 6.2.1 The LEANIX|INTERFACE Reference
- 6.2.2 Role Tag Semantics
- 6.2.3 Hub Interfaces and Two-Sided Bindings
- 6.2.4 The Activity-Level Data Flow Statement
- 6.2.5 Worked Example: Cost Center to Position Interface Bindings
- 6.2.6 What the Interface Binding Does Not Carry
- 6.3 Capability and Domain Alignment
- 6.3.1 The Capability Map in SAP LeanIX
- 6.3.2 The Domain Layer Above the Capability Map
- 6.3.3 Capability and Domain Inheritance Through the Data Spine
- 6.3.4 End-to-End Process Views from Inherited Capabilities
- 6.3.5 Worked Example: Cost Center to Position Capability and Domain Inheritance
- 6.4 Change Impact Use Cases
- 6.4.1 Use Case 1: Application Phase-Out
- 6.4.2 Use Case 2: Interface Deprecation
- 6.4.3 Use Case 3: Role Reorganization
- 6.4.4 Use Case 4: Control Intent Change
- 6.4.5 Worked Example: Cost Center to Position Composite Change Impact
- 6.5 Data Preparation for SAP BTP Ingestion
- 6.5.1 Stage 1: Extract
- 6.5.2 Stage 2: Validate
- 6.5.3 Stage 3: Stage
- 6.5.4 Stage 4: Enrich
- 6.5.5 Stage 5: Publish
- 6.5.6 Composition with the SAP Signavio Pipeline
- 6.5.7 Worked Example: Cost Center to Position Bundle Publication Record
- 6.6 Cross-Chapter Vocabulary Continuity
- 6.7 Summary
- 6.7.1 Key Learning Points
- 6.7.2 Common Design Pitfalls
- 6.7.3 Review Questions
- 6.7.4 Student Companion Notes
- PART IV WalkMe for Process-Aware Adoption and Telemetry
- 7 Designing WalkMe for Process-Aware Adoption
- 7.1 Positioning WalkMe in a Process-Driven Architecture
- 7.1.1 Why the Target Distinction Matters
- 7.1.2 WalkMe as a Knowledge Graph
- 7.1.3 WalkMe in the Reference Architecture's Trust Zones
- 7.2 Mapping WalkMe Content to L4/L5 Process Steps
- 7.2.1 Stable Identifiers as the Binding Mechanism
- 7.2.2 The WALKME_ASSET_BINDING Entity and the Data Model
- 7.2.3 Worked Example: Cost Center to Position with WalkMe Overlay
- 7.2.4 Resolution at Render Time
- 7.3 Aligning WalkMe with SAP Signavio and SAP Build Work Zone
- 7.3.1 SAP Signavio: The Authoritative Process Reference
- 7.3.2 SAP Build Work Zone: The Launch Surface
- 7.3.3 WalkMe: The Guidance Surface
- 7.3.4 Joint Operating Cadence
- 7.4 Governance of In-App Guidance and Change
- 7.4.1 The Lifecycle of a WalkMe Asset
- 7.4.2 Approval and Separation of Duties
- 7.4.3 WalkMe as a Target for AI Agents
- 7.4.4 Change Coordination with SAP Signavio and SAP LeanIX
- 7.4.5 Audit Evidence and Retention
- 7.5 Summary
- 7.5.1 Key Learning Points
- 7.5.2 Common Design Pitfalls
- 7.5.3 Review Questions
- 7.5.4 Student Companion Notes
- 8 Using WalkMe Telemetry to Improve Process and Integration Outcomes
- 8.1 Capturing User Interaction Signals
- 8.1.1 The Four Signal Channels
- 8.1.2 Identity Tagging at the Edge
- 8.1.3 The Single Governed Gateway
- 8.2 Linking Adoption Data to the SAP BTP Data Spine
- 8.2.1 The Telemetry Data Model
- 8.2.2 The Five-Stage Ingestion Pipeline
- 8.2.3 The Dead-Letter Queue and Replay
- 8.3 Detecting Friction, Deviations, and Training Gaps
- 8.3.1 Friction Detection
- 8.3.2 Deviation Detection
- 8.3.3 Training Gap Detection
- 8.4 Feeding Adoption Insights into Downstream AI Services
- 8.4.1 WalkMe as a Target for AI Agents
- 8.4.2 The Two Downstream Destinations
- 8.4.3 Adoption Signals in the Knowledge Graph
- 8.4.4 The End-to-End Loop
- 8.5 Summary
- 8.5.1 Key Learning Points
- 8.5.2 Common Design Pitfalls
- 8.5.3 Review Questions
- 8.5.4 Student Companion Notes
- PART V The Data Spine on SAP BTP
- 9 Designing the Canonical Data Spine
- 9.1 Why Point-to-Point Integrations Fail
- 9.2 Canonical Data Spine Entities and Relationships
- 9.2.1 Domain Model Overview and Architectural Boundaries
- 9.2.2 From Domains to Canonical Entities
- 9.2.3 Execution Context as the Structural Pivot
- 9.2.4 Logical Consolidation of the Canonical Model
- 9.3 Process, Activity, Application, and Interface Keys
- 9.3.1 Stable Identity and Version: Process and Activity
- 9.3.2 Architecture Keys and Identity: Applications and Interfaces
- 9.3.3 Mapping Tables: Process-to-Architecture and System Involvement
- 9.3.4 Execution Context: Ownership Clarity in Multisystem Processes
- 9.3.5 Master Data Referencing (Not Replication)
- 9.3.6 Adoption and Telemetry: WalkMe
- 9.3.7 Configuration Objects and Activity Mapping
- 9.3.8 Governance Overlay: Validation and Publication
- 9.3.9 AI Artifacts: Separated from Canonical Truth
- 9.4 Use Case: Creation of a New Position
- 9.4.1 Sample Data Set
- 9.4.2 Business Context and SAP Best Practice Alignment
- 9.4.3 End-to-End Cross-System Flow
- 9.4.4 Execution Context as Structural Control
- 9.4.5 Master Data Referencing in the Data Spine
- 9.4.6 Configuration Dependencies
- 9.4.7 Validation and Publication Discipline
- 9.4.8 AI-Governed Suggestion Flow
- 9.4.9 Architectural Outcome
- 9.5 Versioning and Lineage Strategy
- 9.5.1 Structural Identity and Version Separation
- 9.5.2 Version Graph and Lineage Modeling
- 9.5.3 Temporal Validity and Runtime Resolution
- 9.5.4 Publication as an Execution Structural Boundary
- 9.5.5 Dependency Revalidation on Structural Change
- 9.5.6 AI Grounding and Bundle Immutability
- 9.5.7 Managing Variant and Regulatory Branches
- 9.5.8 Versioning as an Operational Control System
- 9.6 Ownership and Lifecycle Rules
- 9.6.1 Entity Ownership Boundaries
- 9.6.2 Identity and Mutability Boundaries
- 9.6.3 Lifecycle State Model
- 9.6.4 Validation and Publication Authority
- 9.6.5 Cross-Domain Change Discipline
- 9.6.6 Separation of Duties and Access Control
- 9.6.7 AI Consumption Boundaries
- 9.6.8 Governance as Structural Integrity
- 9.7 Summary
- 9.7.1 Key Learning Points
- 9.7.2 Common Design Pitfalls
- 9.7.3 Review Questions
- 9.7.4 Student Companion Notes
- 10 Implementing the Data Spine on SAP BTP
- 10.1 Persistence Options on SAP BTP
- 10.1.1 SAP HANA Cloud as the Canonical Relational Core
- 10.1.2 Object Store for Raw Telemetry and Archival Payloads
- 10.1.3 Document Store for Schemaless and Variant Payloads
- 10.1.4 SAP HANA Cloud Vector Engine for AI Grounding Embeddings
- 10.1.5 Event Mesh for Change Propagation
- 10.1.6 SAP Build Process Automation for Workflow States
- 10.1.7 Choosing the Right Store for Each Canonical Concern
- 10.2 Table and Schema Design
- 10.2.1 Process and Activity Tables
- 10.2.2 Architecture Tables
- 10.2.3 Execution Context: Where Process Meets Architecture
- 10.2.4 Master Data and Adoption References
- 10.2.5 Audit and AI Consumption Tables
- 10.3 Data Extension Patterns
- 10.3.1 Why the Canonical Core Stays Closed
- 10.3.2 The Extension Side-Table Pattern
- 10.3.3 The Anti-Pattern That Destroys the Data Spine
- 10.3.4 Industry Variants and Vertical Extensions
- 10.3.5 AI-Derived Extensions
- 10.3.6 Extension Discoverability
- 10.4 API Design for Ingestion and Access
- 10.4.1 The Ingestion API: Idempotent Writes from Upstream Sources
- 10.4.2 The Access API: Read with Role and Version Context
- 10.4.3 The Governance API: State Transitions Through Workflow
- 10.4.4 AI Grounding Endpoints
- 10.4.5 Event Mesh Integration
- 10.4.6 Versioning the API Surface
- 10.4.7 Alignment with SAP API Policy v.4.2026a
- 10.5 Governance and Auditability
- 10.5.1 Hash-Chained Audit Events
- 10.5.2 Lineage as a First-Class Query Path
- 10.5.3 Separation of Duties Through SAP Authorization and Trust Management Service Scopes
- 10.5.4 Retention Tiering and Cryptographic Anchoring
- 10.5.5 Compliance Evidence Chain
- 10.6 Summary
- 10.6.1 Key Learning Points
- 10.6.2 Common Design Pitfalls
- 10.6.3 Review Questions
- 10.6.4 Student Companion Notes
- PART VI Integration Flows and Execution Services on SAP BTP
- 11 Integration Flows from SAP Signavio and SAP LeanIX
- 11.1 SAP Signavio to SAP BTP Ingestion Flows
- 11.1.1 Reference Architecture for SAP Signavio Ingestion
- 11.1.2 Event-Driven and Batch Ingestion Patterns
- 11.1.3 End-to-End SAP Signavio Ingestion Flow
- 11.1.4 Payload Mapping into the Canonical Data Spine
- 11.1.5 Adapter Implementation Notes
- 11.1.6 Authentication and Credential Rotation
- 11.2 SAP LeanIX to SAP BTP Ingestion Flows
- 11.2.1 SAP LeanIX as the Architecture System of Record
- 11.2.2 Dependency-First Ingestion Order
- 11.2.3 Capability and Domain Alignment
- 11.2.4 SAP LeanIX Webhook Semantics and Bulk Export Sizing
- 11.2.5 Data Classification and Sensitive Attribute Handling
- 11.3 Synchronization and Reconciliation
- 11.3.1 States and Transitions
- 11.3.2 Daily Reconciliation Cycle
- 11.3.3 Drift Classification: Material Versus Immaterial
- 11.3.4 Snapshot Retention and Forensic Replay
- 11.3.5 Watermarks and Hot Restart Semantics
- 11.3.6 Operational Cadence and On-Call Posture
- 11.4 Error Handling and Retries
- 11.4.1 Error Classification
- 11.4.2 Idempotency Discipline
- 11.4.3 Retry, Backoff, and Dead-Letter Routing
- 11.4.4 Observability Tied to Failures
- 11.4.5 Service-Level Objectives and Alerting Thresholds
- 11.4.6 Poison Messages and Circuit Breakers
- 11.5 Data Consistency Validation
- 11.5.1 Four-Tier Validation Model
- 11.5.2 Validation Rules Catalog
- 11.5.3 Validation Log as the Audit Spine
- 11.5.4 Rule Lifecycle and Versioning
- 11.5.5 Validation Discipline and Financial Reporting Trust
- 11.5.6 Worked Example: A Single Activity Through the Pipeline
- 11.6 Summary
- 11.6.1 Key Learning Points
- 11.6.2 Common Design Pitfalls
- 11.6.3 Review Questions
- 11.6.4 Student Companion Notes
- 12 Process-Aware Execution Services
- 12.1 Process Lookup Services
- 12.1.1 Service Boundaries and Read-Only Contract
- 12.1.2 Latency Budget and Throughput Target
- 12.1.3 Worked Example: A Single Process Lookup Call
- 12.1.4 Filter Predicates and Their Cost
- 12.2 Context Enrichment APIs
- 12.2.1 The Three Distinguishing Properties
- 12.2.2 Latency Budget and Caching
- 12.2.3 Why Context Enrichment Is the Source for AI Grounding
- 12.2.4 Enrichment Output Schema
- 12.3 Change Impact Resolution Services
- 12.3.1 Forward Impact
- 12.3.2 Reverse Impact
- 12.3.3 Performance and Caching of Graph Walks
- 12.3.4 Graph Traversal Patterns by Use Case
- 12.3.5 Worked Example: Retiring an Interface
- 12.3.6 Edge Cases the Service Handles Explicitly
- 12.4 Reusable Integration Services
- 12.4.1 The Action Library
- 12.4.2 Versioning and Deprecation of Actions
- 12.4.3 Contract Stability
- 12.4.4 Action Definition Format
- 12.4.5 Service Contract: Process Lookup View
- 12.5 Performance and Scalability Considerations
- 12.5.1 Latency Budgets and Throughput Targets
- 12.5.2 Three-Tier Caching
- 12.5.3 Cache Invalidation and Stale Reads
- 12.5.4 Service Composition and Versioning
- 12.5.5 Capacity Planning
- 12.5.6 Failure Modes and Graceful Degradation
- 12.5.7 Multiregion Deployment
- 12.5.8 Cost and Resource Considerations
- 12.5.9 Financial Planning and Analysis Drilldown and the Controller’s Trace
- 12.5.10 AI Grounding Bundle Shape
- 12.6 Summary
- 12.6.1 Key Learning Points
- 12.6.2 Common Design Pitfalls
- 12.6.3 Review Questions
- 12.6.4 Student Companion Notes
- PART VII SAP AI Consumption of the Data Spine
- 13 Introducing SAP AI Architecture
- 13.1 SAP AI Core Execution Model
- 13.1.1 Scenarios, Executables, Deployments, and Serving
- 13.1.2 Resource Groups and Tenancy
- 13.1.3 Scaling Policy and Capacity Reasoning
- 13.1.4 Inference Lineage and INFERENCE_EVENT
- 13.1.5 Worked Example: Deployment Manifest
- 13.2 SAP AI Launchpad and Model Access
- 13.2.1 Provider Categories and Their Governance Properties
- 13.2.2 Generative AI Hub and the Foundation Model Interface
- 13.2.3 Catalog Dimensions and the Deployment Decision
- 13.3 AI Lifecycle and Governance
- 13.3.1 Lifecycle States and What They Promise
- 13.3.2 Gates and Their Verdicts
- 13.3.3 Continuous Evaluation: Why the Gate Is Not a One-Time Check
- 13.3.4 Lifecycle Verdicts and the Financial Planning and Analysis Trace
- 13.4 Joule as the Interaction Layer
- 13.4.1 Joule Studio and Agent Authoring
- 13.4.2 The Agent Capability Matrix
- 13.4.3 Joule’s Tool Catalog Is the SAP Build Process Automation Action Library
- 13.5 Integrating AI with SAP BTP APIs
- 13.5.1 AI Grounding Endpoints: The Consumer Contract
- 13.5.2 AI Consumption Pathways and Their Audit Signatures
- 13.5.3 End-to-End Trace: The Controller’s Variance Question
- 13.5.4 Cost Lineage: INFERENCE_EVENT as a Controllable
- 13.6 Summary
- 13.6.1 Key Learning Points
- 13.6.2 Common Design Pitfalls
- 13.6.3 Review Questions
- 13.6.4 Student Companion Notes
- 14 Preparing Data for SAP AI
- 14.1 Data Eligibility for AI Consumption
- 14.1.1 The Eligibility Policy
- 14.1.2 Three Eligibility Classes
- 14.1.3 The Ineligibility Default
- 14.1.4 Review Cadence and Reevaluation
- 14.1.5 The Eligibility Decision Matrix
- 14.1.6 Worked Example: A German Payroll Master-Data Row
- 14.2 Filtering and Role-Based Scoping
- 14.2.1 Why Prepared Data Sets Are Never Reused Across Actors
- 14.2.2 The Role-Scoped Assembly Algorithm
- 14.2.3 The Composite-Role Case
- 14.2.4 Refusal Rather Than Partial Return
- 14.3 Version Control and Approvals
- 14.3.1 The PROCESS_VERSION Pin
- 14.3.2 The AS-OF Semantic
- 14.3.3 The Approval Chain
- 14.3.4 Worked Example: Approval
- 14.3.5 Freshness Budgets and Their One-Way Property
- 14.4 Grounding Rules and Constraints
- 14.4.1 Grounding as a Property of the Prepared Data Set
- 14.4.2 Manifest Signing and Immutability
- 14.4.3 The Citation Contract
- 14.4.4 Grounding Constraints: What May and May Not Be Bound
- 14.5 Preventing Hallucination and Drift
- 14.5.1 Hallucination Prevention as Structural Property
- 14.5.2 Drift as an Ongoing Concern
- 14.5.3 Drift Detection in Practice
- 14.5.4 A Worked Drift Detection Cycle
- 14.6 Summary
- 14.6.1 Key Learning Points
- 14.6.2 Common Design Pitfalls
- 14.6.3 Review Questions
- 14.6.4 Student Companion Notes
- 15 Generating Process Suggestions Using AI
- 15.1 Definition of Process Suggestions
- 15.1.1 The Suggestion Artifact
- 15.1.2 The Suggestion Table
- 15.1.3 The Suggestion Lifecycle
- 15.1.4 Enforcing the Stated AI Boundary
- 15.1.5 Where the Suggestion Pipeline Sits Operationally
- 15.2 Pattern Detection and Similarity Analysis
- 15.2.1 Worked Example: A Harmonization Suggestion
- 15.2.2 The Reference Corpus Is Itself a Governed Artifact
- 15.2.3 Failure Modes the Discipline Is Designed Against
- 15.3 Scoring and Prioritization Logic
- 15.3.1 The Four Factors in Detail
- 15.3.2 Worked Example: Scoring a Control-Gap Suggestion
- 15.3.3 Weights Are Configuration, Not Learning
- 15.3.4 Rescoring and the Stability Guarantee
- 15.4 Explainability and Traceability
- 15.4.1 The SUGGESTION_EXPLANATION Table
- 15.4.2 What the Validator Sees
- 15.4.3 The Explanation Under Adversarial Review
- 15.5 Human-in-the-Loop Validation
- 15.5.1 The VALIDATION_VERDICT Table
- 15.5.2 The Governed Commit Chain
- 15.5.3 Hybrid and Non-SAP Agents Submit Through the Same Path
- 15.5.4 What the Verdict Does Not Settle
- 15.6 Summary
- 15.6.1 Key Learning Points
- 15.6.2 Common Design Pitfalls
- 15.6.3 Review Questions
- 15.6.4 Student Companion Notes
- PART VIII SAP Build Consumption
- 16 SAP Build Process Automation: Workflow on Top of the Data Spine
- 16.1 Positioning SAP Build Process Automation on the Data Spine
- 16.1.1 Building Block and What Each Is Allowed to Do
- 16.1.2 Projects, Releases, and Why Versioning Lives in the Data Spine
- 16.1.3 Destinations, Identity, and the Single Write Path
- 16.2 Approval Workflows
- 16.2.1 Why the Trigger Is Keyed to the Accepted Suggestion, Not the Raw Suggestion
- 16.2.2 Deriving the Approver Chain from Process Context
- 16.2.3 Separation of Duties as a Structural Property
- 16.2.4 What the Approval Writes Back, and How
- 16.2.5 An Annotated Reference Approval Process
- 16.2.6 Approval Forms: What They Display and What They Must Never Collect
- 16.2.7 The Anatomy of a Verdict-Keyed Trigger
- 16.2.8 Risk Bands and the Shape of the Approver Chain
- 16.2.9 Worked Example: A Cross-Region Sequencing Change
- 16.2.10 Time, Escalation, and the Standing Approver Problem
- 16.3 Exception and Remediation Flows
- 16.3.1 An Exception Is a Typed, Severity-Banded Event
- 16.3.2 Three Governed Remediation Paths
- 16.3.3 Worked Example: A Failed Control-Gate Validation
- 16.3.4 The Exception Event Schema
- 16.3.5 Auto-Remediation Is a Governed Rule, Not a Code Path
- 16.3.6 The Remediation Case as a Data Spine Object
- 16.3.7 Reconciliation Between Workflow State and Data Spine Truth
- 16.3.8 Worked Example: Telemetry-Driven Remediation
- 16.4 AI-Assisted Recommendations
- 16.4.1 The Recommendation Is Advisory by Design
- 16.4.2 What the Recommendation Panel Must Carry
- 16.4.3 An Annotated Human Task Contract
- 16.4.4 The Verdict Records What the Human Did with the Advice
- 16.4.5 Why the Panel Cannot Prefill the Decision
- 16.4.6 Worked Example: A Recommendation Inside an Approval Task
- 16.4.7 Disposition Analytics: The Controller’s Earliest Signal
- 16.5 Governance and Audit Handling
- 16.5.1 Every Workflow Instance Is an Audit Row
- 16.5.2 The One-Query Reconstruction
- 16.5.3 Governance Exceptions Are First Class, Not Errors
- 16.5.4 What an Auditor Actually Asks, and the Answer’s Shape
- 16.5.5 Where Workflow State Lives, and Why It Matters for Audit
- 16.5.6 The Refusal Ledger
- 16.5.7 The Control Catalog: Mapping Workflow Controls to Audit Frameworks
- 16.5.8 Audit Handling Across Programs and Regions
- 16.5.9 One Change, End to End
- 16.6 Summary
- 16.6.1 Key Learning Points
- 16.6.2 Common Design Pitfalls
- 16.6.3 Review Questions
- 16.6.4 Student Companion Notes
- 17 SAP Build Work Zone: Process-Aware User Experiences
- 17.1 Positioning SAP Build Work Zone on the Data Spine
- 17.1.1 Components and What Each Is Allowed to Do
- 17.1.2 Why the Experience Layer Holds No Data
- 17.1.3 The Single Read Path and the Absent Write Path
- 17.1.4 What May Live in SAP Build Work Zone and What May Not
- 17.2 Process-Driven Navigation
- 17.2.1 Navigation Is a Query, Not a Menu
- 17.2.2 The Process-to-Space Mapping
- 17.2.3 Search Is a Scoped Projection, Not an Index
- 17.2.4 Worked Example: The Cost Center to Position Journey
- 17.2.5 Deep Links, Bookmarks, and the Stale URL Problem
- 17.3 Role-Based Task Views
- 17.3.1 A Task View Is a Role-Scoped Assembly
- 17.3.2 Where the Tasks Come From: SAP Build Process Automation
- 17.3.3 Separation of Duties Is Visible, Not Just Enforced
- 17.3.4 Delegation and Substitution Without Scope Escalation
- 17.4 Surfacing AI Insights
- 17.4.1 An Insight Is a Citation, Not an Answer
- 17.4.2 Joule in SAP Build Work Zone
- 17.4.3 The Insight Card Contract, Annotated
- 17.4.4 Multi-Suggestion Cards and the Comparison Trap
- 17.4.5 When the Bundle Is Stale: Insight Expiration and Regrounding
- 17.5 User Interaction Boundaries
- 17.5.1 The User Interface Offers Only What the Data Spine Would Permit
- 17.5.2 The Absent Control Is the Strongest Control
- 17.5.3 Break-Glass Is a Separate, Human-Authenticated Path
- 17.5.4 The Mobile and Offline Case
- 17.5.5 One Interaction, End to End: Across the Boundaries
- 17.6 Summary
- 17.6.1 Key Learning Points
- 17.6.2 Common Design Pitfalls
- 17.6.3 Review Questions
- 17.6.4 Student Companion Notes
- PART IX Operations, Security, and Extensibility
- 18 Operating the Integrated Platform
- 18.1 The Operating Model of the Integrated Platform
- 18.2 Monitoring and Observability
- 18.2.1 Three Signal Classes
- 18.2.2 The Golden Signals per Layer
- 18.2.3 Service-Level Objectives and the Error Budget
- 18.2.4 The Severity Model and On-Call Posture
- 18.2.5 Correlation: One Identity for Health and Evidence
- 18.2.6 The Observability Data Model
- 18.2.7 Dashboards as Operated Artifacts, Not Decoration
- 18.2.8 Worked Example: The Incident Response Lifecycle
- 18.3 Data Quality Management
- 18.3.1 Quality Is an Operated Property
- 18.3.2 The Steward Operating Model
- 18.3.3 The Quarantine Economy
- 18.3.4 AI as a Quality Pattern Detector and Its Boundary
- 18.3.5 The Validation Rule Lifecycle
- 18.3.6 Worked Example: Reconciliation Is the Engine of the Scorecard
- 18.4 Version Drift and Resynchronization
- 18.4.1 The Drift Taxonomy, Carried Forward
- 18.4.2 The Resynchronization Decision Flow
- 18.4.3 Drift Never Mutates in Place
- 18.4.4 Forensic Replay
- 18.4.5 Hot Restart and Regrounding
- 18.4.6 The Reconciliation Cadence, Operated
- 18.4.7 Snapshot Retention Economics
- 18.4.8 Worked Example: A Drift Event, End to End
- 18.5 Scaling Across Programs
- 18.5.1 Program Tenancy on Resource Groups
- 18.5.2 Multiregion Topology and Jurisdiction-Bounded Replication
- 18.5.3 The Program Onboarding Lifecycle
- 18.5.4 Verifying Tenant Isolation
- 18.5.5 Scaling the AI Tier
- 18.5.6 The Federated Team and Its Accountabilities
- 18.5.7 Work Example: Cost Lineage and the AI Tier as a Controllable
- 18.6 Summary
- 18.6.1 Key Learning Points
- 18.6.2 Common Design Pitfalls
- 18.6.3 Review Questions
- 18.6.4 Student Companion Notes
- 19 Security, Controls, and Audits
- 19.1 Data Access and Authorization
- 19.1.1 Identity Is the First Control, Not a Prerequisite to It
- 19.1.2 Defense in Depth as an Architectural Property
- 19.1.3 The Authorization Vocabulary: Scopes Bound to Canonical Operations
- 19.1.4 The Four Canonical Operations in Detail
- 19.1.5 Worked Example: An AI Agent Reaches Its Boundary
- 19.1.6 Role-Based Segmentation of the Data Spine
- 19.1.7 AI Agents as Named Actors
- 19.1.8 Worked Example: A Data Residency Question
- 19.2 Control Effectiveness
- 19.2.1 Effectiveness Is Design Adequacy Multiplied by Operating Evidence
- 19.2.2 The Three Control Classes
- 19.2.3 Why the Refusal Ledger Is the Most Valuable Evidence
- 19.2.4 The Control Catalog as a Generated Register
- 19.2.5 The Dimensions of a Catalog Entry
- 19.2.6 Worked Example: Evidencing a Preventive Control Over a Quarter
- 19.2.7 Effectiveness Is a Property of the Architecture, Not the Effort
- 19.3 Audit Trails and Evidence
- 19.3.1 The Hash-Chained Audit Event
- 19.3.2 Lineage as a First-Class Query Path
- 19.3.3 What the Auditor Actually Asks
- 19.3.4 Worked Example: The Controller Variance Question, Step by Step
- 19.3.5 Worked Example: Forensic Replay of a Past Decision
- 19.3.6 Retention, Anchoring, and Forensic Replay
- 19.4 Compliance Considerations
- 19.4.1 Obligation, Control, Evidence
- 19.4.2 Why Mapping to Queries Rather Than Binders Matters
- 19.4.3 Worked Example: Decomposing a Compliance Obligation
- 19.4.4 Why the Same Mechanisms Satisfy Independent Regimes
- 19.4.5 Jurisdiction, Residency, and Multiregion Compliance
- 19.4.6 The Compliance Posture Is Continuous, Not Periodic
- 19.5 Summary
- 19.5.1 Key Learning Points
- 19.5.2 Common Design Pitfalls
- 19.5.3 Review Questions
- 19.5.4 Student Companion Notes
- 19.6 Conclusion: The Integrated, AI-Ready Enterprise
- The Author
- Index
