--- title: Why SAP AI Needs Integrated Process and Architecture Data description: Discover how integrating process and architecture data is essential for effective SAP AI execution, ensuring reliable performance across technology layers. image: https://blog.sap-press.com/hubfs/Why%20SAP%20AI%20Needs%20Integrated%20Process%20and%20Architecture%20Data.jpg --- [![rheinwerk-sappress-logo-header-1](https://blog.sap-press.com/hubfs/rheinwerk-sappress-logo-header-1.svg)](https://blog.sap-press.com/) [Blog](https://blog.sap-press.com) - Books - Get an overview of our books and courses on every relevant SAP topic. - [Programming](https://sap-press.com/programming/) - [Administration](https://sap-press.com/administration/) - [BI](https://sap-press.com/business-intelligence/) - [Finance](https://sap-press.com/finance-controlling/) - [Logistics](https://sap-press.com/logistics/) - [HR](https://sap-press.com/human-resources/) - [CRM & Sales](https://sap-press.com/marketing-sales/) - [HANA](https://sap-press.com/hana/) - [Introductions](https://sap-press.com/introductions/) - [E-Bites](https://sap-press.com/e-bites/) - [Certification Guides](https://www.sap-press.com/certification-guides/) - [Rheinwerk Courses](https://www.sap-press.com/online-courses/) - Book Subscription - Get unlimited access to all SAP PRESS books! - [SAP PRESS Subscription](https://sap-press.com/subscriptions/) [Programming](https://blog.sap-press.com/tag/programming) # Why SAP AI Needs Integrated Process and Architecture Data ![SAP PRESS](https://blog.sap-press.com/hubfs/Twitter_profile_pic.svg) by [SAP PRESS](https://blog.sap-press.com/author/sap-press) on November 13, 2026 SAP AI covers a wide range of systems, from the rule-based logic behind an MRP run to Joule agents that plan and carry out multistep tasks on their own.   Every one of those layers depends on the process and architecture data underneath it, and generative and agentic AI depend on it the most. In this post, we’ll look at why SAP AI needs that data to be integrated, how [SAP BTP](https://learning.sap-press.com/sap-btp) holds the integration together, and which actions AI should never be allowed to take on its own.   ## Why SAP AI Requires Unified Semantic Context Process and architecture in isolation are insufficient foundations for execution. This post argues something stronger: SAP AI, as it is being delivered in 2026 and beyond, makes the integration of those foundations a hard requirement rather than a desirable improvement. To make that argument precisely, you need a working model of what SAP AI actually refers to. The phrase has become so overloaded in vendor communications that we must first clarify its structure before making the integration argument. ### SAP AI Is Layered, Not Monolithic There is no single tool called SAP AI. There is an AI operating stack, in which distinct technology layers run simultaneously, each with different governance needs and different appetites for semantic context. The stack, ordered from foundation to frontier, runs through rule-based and expert systems, industrial control systems, neural networks, classical machine learning, predictive analytics, the Internet of Things (IoT), deep learning, transformers, edge AI, generative AI, and agentic AI. The frontier above that—artificial general intelligence (AGI) and beyond—remains speculative.   What matters for an SAP transformation architect is not that this list is comprehensive, but that none of the lower layers has been replaced by the higher ones. Rule-based systems still execute the SAP tax determination logic and the materials requirement planning (MRP) run. Industrial control systems still operate plants in real time, irrespective of whether a [Joule](https://blog.sap-press.com/what-is-sap-joule)agent is reasoning about scheduling. Classical machine learning still powers most demand forecasting and predictive maintenance models in production today. Generative AI did not displace these layers; it stacked on top of them and depends on them. The figure below shows all thirteen layers of the AI operating stack in dependency order.   *![The AI Operating Stack](https://blog.sap-press.com/hs-fs/hubfs/image-png-Nov-04-2026-01-41-58-8278-PM.png?width=781&height=885&name=image-png-Nov-04-2026-01-41-58-8278-PM.png)*   SAP’s AI investments make the layered nature of the stack explicit. SAP AI Core executes models. SAP AI Launchpad catalogs them. The generative AI hub provides curated access to a portfolio of foundation models, including SAP’s own models. SAP-RPT-1 is a tabular foundation model designed for the rows-and-columns data that lives natively in enterprise resource planning (ERP) systems. SAP-ABAP-1 is a foundation model fine-tuned on [ABAP](https://learning.sap-press.com/abap), the language in which most SAP custom logic is written. Joule provides a unified way for end users, developers, and consultants to use SAP’s AI capabilities. Joule agents build on this by taking actions on their own, using tools and executing tasks autonomously. Each of these components has a different role, and each of them imposes different requirements on the underlying semantic context. ### What Each Layer Requires from the Semantic Foundation Different layers of the AI operating stack require different things from the underlying semantic foundation. Rule-based systems require complete and consistent configuration data. Classical machine learning models require clean, well-governed training data with stable feature definitions. Predictive analytics requires reliable operational signals correlated with stable identifiers. Generative AI requires grounded context: structured data, scoped documents, and stable references that allow the model to retrieve rather than invent. Agentic AI requires all of the above as well as an explicit, permissioned action surface, audit trails, and human-in-the-loop checkpoints for actions that affect systems of record.   These requirements are all about identity, version, and ownership. Every layer of the stack assumes that the artifacts it consumes can be referred to by stable identifiers, that the version of those artifacts is unambiguous, and that the ownership of those artifacts is technically enforced rather than conventionally agreed. When an enterprise cannot supply those three guarantees, every layer of the stack degrades, but generative and agentic AI do so most visibly and most expensively. ### The Specific Requirements of Generative and Agentic AI Generative AI introduces a particular sensitivity to ambiguous semantics. A foundation model is, in effect, a confident pattern matcher. Given two plausible references to the same business object—one current, one deprecated—the model has no intrinsic mechanism to choose the current one. Given three concurrent draft versions of the same process, it has no intrinsic mechanism to identify the authoritative one. *Hallucination* is what happens when a model is forced to produce an output without sufficient grounding. The remedy for hallucination is better grounding, not a better model. Better grounding means stable identifiers, approved versions, and explicit ownership flowing from the integration layer into the AI runtime.   Agentic AI raises the stakes by an order of magnitude. An agent is a generative model that has been given tools, permissions, and the autonomy to plan a multistep task. Joule agents and the agents built in the Joule Studio agent builder operate this way. Each agent is a named actor in the SAP landscape, and each action an agent takes must be auditable to the same standard as a human user. This is not an aspirational standard; it is what auditors, regulators, and internal control frameworks already require. The agent that drafts a goods receipt or proposes a configuration change must be able to explain, in production, which process version it consulted, which application it acted against, which approved data it used, and which human authority approved its proposal.   The agent can’t answer any of those questions by itself. They can only be answered by the integration layer that supplied the agent with its context in the first place. If the integration layer cannot answer them, the agent’s output is unauditable. In any regulated environment, unauditable output is unusable, no matter how fluent it sounds. ### AI Grounding Bundles and the Role of the Canonical Layer The practical mechanism by which structured context flows into SAP AI is the AI grounding bundle. A grounding bundle is a curated, versioned, role-scoped package of data and metadata that the AI service is permitted to reason over for a specific purpose. It typically contains the relevant published process definition, the associated activities and their execution context, the [SAP LeanIX](https://blog.sap-press.com/what-is-sap-leanix) application and interface references, and any in-scope master data references. A grounding bundle should not be assembled by the AI service but by the canonical integration layer that owns the underlying semantics and that enforces the publication boundary.   The reason this matters is that the canonical integration layer is the only place in the architecture where the boundaries between systems of record can be enforced consistently. [SAP Signavio](https://blog.sap-press.com/what-is-sap-signavio) cannot enforce SAP LeanIX boundaries. SAP LeanIX cannot enforce SAP Signavio boundaries. Neither can enforce master data boundaries that belong to [SAP Master Data Governance](https://blog.sap-press.com/what-is-sap-mdg), [SAP S/4HANA](https://learning.sap-press.com/sap-s4hana-overview-benefits), or [SAP SuccessFactors](https://learning.sap-press.com/sap-successfactors). The canonical layer is where these boundaries are reconciled and where the rules that govern AI consumption are enforced.   The argument of this section can therefore be summarized as follows: SAP AI does not require a unified semantic context for marketing purposes. It requires one because the operating model of generative and agentic AI, applied to systems of record, is structurally incompatible with fragmented identity, ambiguous versions, and implicit ownership. The next section examines how SAP BTP discharges this requirement.   ## The Role of SAP BTP as the Data Spine, Integration Layer, and Extension Layer SAP BTP is frequently introduced as middleware. That description is technically not wrong, but it is incomplete. Middleware, in the traditional sense, moves data between applications, while a data spine preserves meaning across them. This distinction is important because moving data is a transport concern and preserving meaning is a semantic concern. SAP BTP is capable of doing both, but only if it is designed and governed as a semantic layer rather than as a set of integration flows. This section walks you through how SAP BTP fulfills these roles. ### Three Architectural Roles of SAP BTP SAP BTP plays three distinct architectural roles, and they should be kept conceptually separate even when they are physically co-located. As the data spine, SAP BTP hosts the canonical entities and relationships that normalize process semantics from SAP Signavio, architecture semantics from SAP LeanIX, master data references from SAP S/4HANA and SAP SuccessFactors, and adoption telemetry from [WalkMe](https://blog.sap-press.com/what-is-sap-walkme). As the integration layer, it hosts the ingestion flows, validation logic, and publication services that move governed semantics in and out of the spine. As the extension layer, it hosts the execution services, AI grounding services, and human-in-the-loop workflows that consume the spine on behalf of business users and AI agents.   These three roles must be kept conceptually separate because they have different governance regimes. The data spine is governed by lifecycle rules: which version of which entity is published, who approved it, and which downstream consumers are entitled to see it. The integration layer is governed by data-quality rules: which ingestion is reconciled, which validation has passed, and which errors require human intervention. The extension layer is governed by application-level rules: which execution service performs which action, with which authority, and with which audit trail. Treating all three roles of SAP BTP as if they were a single kind of middleware is the most common reason architectures fail to scale.   This figure shows SAP BTP as the semantic integration layer. This is the only layer where process, architecture, master data, and telemetry are reconciled into a single governed view. AI consumes only published, validated, and role-scoped grounding bundles assembled from the data spine.   *![SAP BTP as the Semantic Integration Layer](https://blog.sap-press.com/hs-fs/hubfs/image-png-Nov-04-2026-01-42-26-2220-PM.png?width=1460&height=768&name=image-png-Nov-04-2026-01-42-26-2220-PM.png)* ### Why Canonical Semantics Live on SAP BTP The canonical entities on SAP BTP—processes, process versions, activities, applications, interfaces, execution contexts, master-data references, adoption artifacts, and governance overlays—are deliberately smaller than any of the upstream systems they reconcile. The data spine does not duplicate SAP Signavio, SAP LeanIX, or SAP S/4HANA’s master data tables. It captures only the minimum semantics required to make execution and AI consumption safe. This minimalism is not a cost-saving measure; it is a governance decision. Every additional attribute the data spine duplicates is an additional attribute that can drift from its system of record. ### Validation, Publication, and the Role of Boundary Enforcement Two specific responsibilities of the SAP BTP integration layer deserve emphasis. The first is *validation*. Before any canonical entity is exposed to execution services or AI grounding, it must be validated for structural integrity: stable identifiers must resolve, version state must be consistent, execution context must be unambiguous, and master-data references must be valid against their systems of record. Validation is a deterministic function. It either passes or fails, and the failure modes must be both observable and actionable.   The second responsibility is *publication*. Validation determines correctness, but publication determines authority. Only entities that have been explicitly published by an authorized governance role are eligible for downstream consumption. This boundary cannot be enforced by convention; it must be enforced technically, through service-layer authorization that prevents any path of consumption from reaching an unpublished entity. ### SAP BTP as the Coordinator of the Design-to-Delivery Loop SAP BTP coordinates that loop because it is the only layer that brings all three inputs together: It takes design from SAP Signavio, architecture from SAP LeanIX, and adoption telemetry from WalkMe, and then provides a governed, published view of all three to execution and AI services. Without SAP BTP in this role, the design layer and the delivery layer remain in different conversations. With SAP BTP in this role, the conversation closes and improvement becomes data-driven rather than experience-driven.   Keep in mind that SAP AI Core and the generative AI hub are the AI platforms, not SAP BTP. The role of SAP BTP is to make those AI platforms safe to use. It is the layer at which semantic discipline is enforced, version boundaries are protected, and the AI consumption audit trail is anchored. Programs that try to deploy SAP AI without first establishing a governed SAP BTP foundation will discover why this distinction matters, usually after their first audit cycle.   ## Non-Goals: What AI Must Not Automate Every architectural argument about AI eventually reaches the question of where AI should not be permitted to act. This is sometimes treated as a matter of ethics or policy. In an SAP execution context, it is more useful as a matter of architecture. The boundaries that AI must respect are the same boundaries that protect the integrity of the canonical layer, the authority of the systems of record, and the auditability of the operating model. They are not optional. ### AI Must Not Mutate Canonical Truth The canonical entities on SAP BTP—processes, versions, activities, applications, execution contexts, and master data references—are the structural memory of the enterprise. AI services may read from them, propose changes against them, and surface anomalies in them. AI services must not write to them. Modification of canonical truth remains the responsibility of the relevant system of record and the human or service account authorized by that system. This boundary is enforced by service-layer authorization, not by convention. ### AI Must Not Bypass Governance An AI service that consumes a draft process version, an unvalidated execution context, or a deprecated application reference is consuming ungoverned data, and its output inherits the risk. AI services must consume only published, validated, and entitled artifacts. The temptation to expose a draft to AI in the name of agility must be resisted; it almost always produces output that cannot be defended in audit. ### AI Must Not Autopublish Versions An AI service may detect that a process is out of date, that a control activity is missing, or that an architectural relationship has drifted. It may propose the remediation, but it must not unilaterally publish the new version. Publication is a governance act and must remain bound to a human or service account explicitly authorized for that act. ### AI Must Not Directly Execute Configuration Generating a configuration specification is not the same as executing a configuration change. The boundary between the two is exactly where [SAP Build Process Automation](https://blog.sap-press.com/what-is-sap-build-process-automation), [SAP Solution Manager](https://learning.sap-press.com/sap-solution-manager)’s Change and Request Management (ChaRM), and the relevant transport mechanisms operate. AI may produce a candidate configuration artifact. The artifact must enter the same review, transport, and validation path as any human-authored configuration. Direct execution of AI-generated configuration in production environments is not an automation gain; it is an audit failure waiting to occur. ### AI Must Not Bypass Separation of Duties (SoD) Controls SoD is the structural protection that prevents a single actor from executing every step of a sensitive process. Whether the actor is human or AI-driven, the protection must hold. An agent that creates a vendor master record must not also approve the first invoice paid to that vendor. An agent that drafts a configuration change must not also transport it to production. Modeling AI agents as named actors in the SAP authorization model, and applying the same SoD rules that apply to human users, is the architectural answer to this requirement. This control is part of the integration layer, not the AI service itself.   The unifying principle behind these five non-goals is that AI is a powerful augmenter of governance and a poor substitute for authority. Authority, in an SAP execution context, is the legally and operationally meaningful capacity to publish a process version, release a configuration, approve a payment, or retire an application. That authority is held by human roles and service accounts explicitly delegated to act on behalf of those roles. AI may inform, propose, accelerate, and explain, but it does not, in this architecture, hold authority. Audit, regulatory, and operational consequences of any other design are unacceptable.   ## Conclusion SAP AI is only as trustworthy as the context it receives, and that context has to come from one governed source where process, architecture, and master data agree on identity, version, and ownership. SAP BTP is where that agreement is enforced, and that enforcement is what makes SAP AI Core, the generative AI hub, and Joule agents safe to run against systems of record. Before you expand AI across your SAP landscape, get the integration layer in place and limit AI to proposing changes, with people keeping the authority to approve them.    *Editor’s note:* This post has been adapted from a section of the book *[Integrating Architecture, Processes, and AI on SAP BTP: Designing an AI-Ready Execution Layer Using SAP Signavio, SAP LeanIX, and WalkMe](https://www.sap-press.com/integrating-architecture-processes-and-ai-on-sap-btp_6352/?utm_source=sappressblog&utm_medium=referral&utm_campaign=Blogs&utm_term=2880_chapter1&utm_content=2880)* by [Kumar Piraviperumal](https://www.linkedin.com/in/kumarpiraviperumal/). Kumar has worked with SAP technologies since 1997 and leads a global SAP business transformation practice at Cognitus, spanning more than 19 countries, where he sets architecture standards, delivery governance, and execution models for large S/4HANA programs. His experience is concentrated in utilities, automotive, and IT services, covering global rollouts, regulatory-driven change, and post-merger integration. He has written for SAPinsider magazine, taught courses through SAP University Alliances and SAP Education Services, and speaks regularly at SAPPHIRE, SAP TechEd, and SAPinsider events. His current focus is execution-grade transformation and the responsible application of AI in SAP environments. ## Recommendation [![Integrating Architecture, Processes, and AI on SAP BTP](https://blog.sap-press.com/hs-fs/hubfs/social-suggested-images/2880-Aug-10-2026-12-02-44-4266-PM.jpg?width=170&name=2880-Aug-10-2026-12-02-44-4266-PM.jpg)](https://www.sap-press.com/integrating-architecture-processes-and-ai-on-sap-btp_6352/?utm_source=sappressblog&utm_medium=referral&utm_campaign=Blogs&utm_term=2880_chapter1&utm_content=2880) **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! [Learn More](https://www.sap-press.com/integrating-architecture-processes-and-ai-on-sap-btp_6352/?utm_source=sappressblog&utm_medium=referral&utm_campaign=Blogs&utm_term=2880_chapter1&utm_content=2880) ![SAP PRESS](https://blog.sap-press.com/hubfs/Twitter_profile_pic.svg) **by [SAP PRESS](https://blog.sap-press.com/author/sap-press)** SAP PRESS is the world's leading SAP publisher, with books on ABAP, SAP S/4HANA, SAP IBP, intelligent technologies, SAP Business Technology Platform, and more! [Programming](https://blog.sap-press.com/tag/programming) [Featured](https://blog.sap-press.com/tag/featured) [![Share on facebook](https://7528309.fs1.hubspotusercontent-na1.net/hub/7528309/hubfs/raw_assets/public/mV0_d-web-default-modules_hubspot/img/facebook-color.png?width=24&name=facebook-color.png)](https://www.facebook.com/share.php?u=https%3A%2F%2Fblog.sap-press.com%2Fwhy-sap-ai-needs-integrated-process-and-architecture-data%3Futm_medium%3Dsocial%26utm_source%3Dfacebook) [![Share on linkedin](https://7528302.fs1.hubspotusercontent-na1.net/hub/7528302/hubfs/raw_assets/public/mV0_d-web-default-modules_hubspot/img/linkedin-color.png?width=24&name=linkedin-color.png)](https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Fblog.sap-press.com%2Fwhy-sap-ai-needs-integrated-process-and-architecture-data%3Futm_medium%3Dsocial%26utm_source%3Dlinkedin) [![Share on twitter](https://7528304.fs1.hubspotusercontent-na1.net/hub/7528304/hubfs/raw_assets/public/mV0_d-web-default-modules_hubspot/img/twitter-color.png?width=24&name=twitter-color.png)](https://twitter.com/intent/tweet?original_referer=https%3A%2F%2Fblog.sap-press.com%2Fwhy-sap-ai-needs-integrated-process-and-architecture-data%3Futm_medium%3Dsocial%26utm_source%3Dtwitter&url=https%3A%2F%2Fblog.sap-press.com%2Fwhy-sap-ai-needs-integrated-process-and-architecture-data%3Futm_medium%3Dsocial%26utm_source%3Dtwitter&source=tweetbutton&text=) [![Share on email](https://7528311.fs1.hubspotusercontent-na1.net/hub/7528311/hubfs/raw_assets/public/mV0_d-web-default-modules_hubspot/img/email-color.png?width=24&name=email-color.png)](mailto:?subject=Check+out+https%3A%2F%2Fblog.sap-press.com%2Fwhy-sap-ai-needs-integrated-process-and-architecture-data%3Futm_medium%3Dsocial%26utm_source%3Demail&body=Check+out+https%3A%2F%2Fblog.sap-press.com%2Fwhy-sap-ai-needs-integrated-process-and-architecture-data%3Futm_medium%3Dsocial%26utm_source%3Demail) ### Comments ### Latest Blog Posts [![Aligning WalkMe with SAP Signavio and SAP Build Work Zone](https://blog.sap-press.com/hs-fs/hubfs/Aligning%20WalkMe%20with%20SAP%20Signavio%20and%20SAP%20Build%20Work%20Zone.jpg?height=600&name=Aligning%20WalkMe%20with%20SAP%20Signavio%20and%20SAP%20Build%20Work%20Zone.jpg)](https://blog.sap-press.com/aligning-walkme-with-sap-signavio-and-sap-build-work-zone) [Programming](https://blog.sap-press.com/tag/programming) ## [Aligning WalkMe with SAP Signavio and SAP Build Work Zone](https://blog.sap-press.com/aligning-walkme-with-sap-signavio-and-sap-build-work-zone) [Read More](https://blog.sap-press.com/aligning-walkme-with-sap-signavio-and-sap-build-work-zone) [![Business Functionalities of SAP BTP](https://blog.sap-press.com/hs-fs/hubfs/Business%20Functionalities%20of%20SAP%20BTP.jpg?height=600&name=Business%20Functionalities%20of%20SAP%20BTP.jpg)](https://blog.sap-press.com/business-functionalities-of-sap-btp) [Programming](https://blog.sap-press.com/tag/programming) ## [Business Functionalities of SAP BTP](https://blog.sap-press.com/business-functionalities-of-sap-btp) [Read More](https://blog.sap-press.com/business-functionalities-of-sap-btp) **Subscribe to our blog!**Get notified about future blog updates. - - - - - ### The official SAP PRESS Blog As the world’s leading SAP publisher, SAP PRESS’ goal is to create resources that will help you accelerate your SAP journey. The SAP PRESS Blog is designed to provide helpful, actionable information on a variety of SAP topics, from SAP ERP to SAP S/4HANA. Explore ABAP, FICO, SAP HANA, and more! ### SAP Blog Topics - [All Topics](https://blog.sap-press.com) - [Logistics](https://blog.sap-press.com/tag/logistics) - [Programming](https://blog.sap-press.com/tag/programming) - [FICO](https://blog.sap-press.com/tag/fico) - [Administration](https://blog.sap-press.com/tag/administration) - [Featured](https://blog.sap-press.com/tag/featured) - [Business Intelligence](https://blog.sap-press.com/tag/business-intelligence) - [What Is?](https://blog.sap-press.com/tag/what-is) - [CRM & Sales](https://blog.sap-press.com/tag/crm-sales) - [Human Resources](https://blog.sap-press.com/tag/human-resources) - [Video](https://blog.sap-press.com/tag/video) ### Blog curated by [![Rheinwerk Publishing & SAP PRESS Logo](https://blog.sap-press.com/hubfs/rheinwerk-sappress-logo-header-1.svg)](https://sap-press.com) [Visit the SAP PRESS Store](https://sap-press.com) ### About - [Home](https://sap-press.com/) - [About Us](https://sap-press.com/the-publisher/) - [Contact](mailto:info@rheinwerk-publishing.com) - [Legal Notes](https://sap-press.com/legal-notes/) - [Privacy Policy](https://sap-press.com/privacy/) - [Terms of Use](https://sap-press.com/terms/) - [Guest Posting](https://blog.sap-press.com/guest-posting) © 2026 Rheinwerk Publishing, Inc. | Change Privacy Options ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "SAP PRESS", "url" : "https://blog.sap-press.com/author/sap-press" }, "dateModified" : "2026-11-13T14:00:04.147Z", "datePublished" : "2026-11-13T14:00:04.000Z", "headline" : "Why SAP AI Needs Integrated Process and Architecture Data", "image" : [ "https://blog.sap-press.com/hubfs/Why%20SAP%20AI%20Needs%20Integrated%20Process%20and%20Architecture%20Data.jpg" ], "mainEntityOfPage" : { "@id" : "https://blog.sap-press.com/why-sap-ai-needs-integrated-process-and-architecture-data", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.sap-press.com/hubfs/Logo-1.jpg" }, "name" : "Rheinwerk Publishing, Inc." } } ```