SAP BTP – IS – How to prevent your integration architecture from becoming a Frankenstein landscape

Disclaimer: This article shares architectural lessons learned from real-world projects. It does not promote or discourage any specific vendor; the focus is on platform coherence, governance, long-term maintainability, and a homogeneous integration landscape.

I will not present negative points or direct comparisons between platforms, and any sensitive data is out of scope. The intention is to generate reflection within the audience.

I’m also not to speak about SAP BTP in its entirety, as that would be lying and is outside my area of competence and knowledge; I only explore SAP Integration Suite.

Introduction

This blog was not written based on slides or frameworks; it was based on my experience over several years since the emergence of SAP BTP and the consolidation of the SAP Integration Suite component.

Here I will present some truths from the thinking of an out-of-the-box SAP XI/PI/PO/CPI developer. I will present 3 scenarios; I do not see much sense in more than that, it will already be enough for the integration audience to understand what I am trying to explain, or guide, or look for a point of reflection.

When I talk about “thinking outside the box,” I am not using a trendy term. I mean that if we limit ourselves to being mere technical executors of tickets—whether in PI/PO or in SAP Integration Suite SAP CPI—we will lose the overall vision of the whole. If our vision is reduced to connecting boxes, creating mappings, or writing pieces of code in Groovy or JavaScript, XML to JSON or JSON to XML conversion, we will be underutilizing both the platform and not exploring the full knowledge we have in between the external world and the SAP backend (ECC or S/4HANA – on-prem or on-cloud).

Think big, think high, do not be afraid to express your opinion.

When you have knowledge and truly know what SAP BTP Integration Suite offers, you gain the necessary authority to talk on equal terms with architects — and to help build environments that really make sense.

Let’s go to our interesting journey.

​ Disclaimer: This article shares architectural lessons learned from real-world projects. It does not promote or discourage any specific vendor; the focus is on platform coherence, governance, long-term maintainability, and a homogeneous integration landscape.I will not present negative points or direct comparisons between platforms, and any sensitive data is out of scope. The intention is to generate reflection within the audience.I’m also not to speak about SAP BTP in its entirety, as that would be lying and is outside my area of competence and knowledge; I only explore SAP Integration Suite.IntroductionThis blog was not written based on slides or frameworks; it was based on my experience over several years since the emergence of SAP BTP and the consolidation of the SAP Integration Suite component.Here I will present some truths from the thinking of an out-of-the-box SAP XI/PI/PO/CPI developer. I will present 3 scenarios; I do not see much sense in more than that, it will already be enough for the integration audience to understand what I am trying to explain, or guide, or look for a point of reflection.When I talk about “thinking outside the box,” I am not using a trendy term. I mean that if we limit ourselves to being mere technical executors of tickets—whether in PI/PO or in SAP Integration Suite SAP CPI—we will lose the overall vision of the whole. If our vision is reduced to connecting boxes, creating mappings, or writing pieces of code in Groovy or JavaScript, XML to JSON or JSON to XML conversion, we will be underutilizing both the platform and not exploring the full knowledge we have in between the external world and the SAP backend (ECC or S/4HANA – on-prem or on-cloud).Think big, think high, do not be afraid to express your opinion.When you have knowledge and truly know what SAP BTP Integration Suite offers, you gain the necessary authority to talk on equal terms with architects — and to help build environments that really make sense.Let’s go to our interesting journey.How I saw some Frankenstein architectures being born: three real casesThroughout my career, I witnessed moments when tools “with more know-how” ended up complicating what should have been simple.Let’s be sincere and honest here: any platform or application, whether SAP or non-SAP, always has strengths and weaknesses. However, the benefits of homogenizing these architectures are very strong: lower customization, better support, unified teams.Scenario 1: Wasted PotentialI must confess that in this first scenario, I really saw myself only as an SAP PI/PO/CPI consultant connecting little boxes, mappings, and others. I did not have the knowledge or the courage at that time to express my position, and I believe this may have worsened the definitions, but I took a lesson from it.Everything was organized: rules, standards, development guidelines, design, and models. At the beginning of a migration to S/4HANA, external architects ignored what was already implemented. SAP BTP (SAP Integration Suite – APIM and CPI) already existed, but they chose to neglect the investment or any larger decision and used only the minimum necessary.APIM was completely excluded and SAP CPI was limited to standard pre-content packages with the minimum possible modification; another market platform took over the entire APIM framework and custom integrations. The result? The erosion of a strategy that was already winning.Negative impacts:Redundancy and Duplicate Costs: Maintenance of two integration platforms (BTP and a third-party tool) to perform functions that SAP Integration Suite was already designed to handle natively.Operational Inefficiency: Managing security, logs, and monitoring in two different environments increases the workload of the teams.Loss of Native Optimization: By ignoring the APIM layer and the full potential of CPI, the organization loses the ability to govern, and the ecosystem becomes increasingly difficult to govern.Scenario 2: Imposition of External Architecture PatternsIn this case, a “three-layer architecture – Intelligence Layer, Processing/Routing Layer, Delivery Layer” borrowed from a completely different ecosystem was imposed on SAP CPI. To keep this artificial construction standing, the solution turned into a tangle of hundreds of JMS queues.Negative impacts:Unnecessary Complexity and Latency: Each extra JMS hop adds processing overhead and potential failure points that would not exist in a flow optimized for CPI.High Maintenance Debt: Troubleshooting requires tracing messages through dozens of queues, making root-cause analysis extremely difficult and slow.Resource and Cost Exhaustion: Excessive use of JMS queues can lead to resource bottlenecks in the tenant, affecting the performance of other critical integrations and the high operational cost of keeping this complex structure running.Scenario 3: Fragmented Teams and ToolsAn organization adopted BTP in a fragmented way, using events and APIs; only SAP CPI was consolidated and very well structured in its usage. They split responsibilities among teams that did not communicate with each other. In the end, they increased costs and complexity, wasting the natural synergy of SAP BTP – SAP Integration Suite.Negative impacts:Logic and Data in Silos: Without communication, teams frequently rebuild similar logic or connectors, leading to inconsistent data mappings in the same landscape.Architectural Inconsistency: Different teams apply different security and naming standards, resulting in a “patchwork” ecosystem that is difficult to govern.Integration Friction: The lack of synergy prevents the organization from effectively leveraging Event-Driven Architecture (EDA).The Rise of Fragmented Integration Architectures (“Frankenstein” Patterns)I have seen organizations invest heavily in SAP BTP, only to leave these strategic assets idle while external tools, patterns, and “borrowed architectures” are stitched together into what I call Frankenstein Architectures, where I already provided three examples I experienced: powerful in isolation, fragile together.These environments rarely arise from a technical necessity; more often, they emerge from disconnected decisions, architectural bias coming from professionals less familiar with SAP integration ecosystems, or lack of communication with the front line—developers specialized in SAP Integration Suite—or from uncritical reuse or following market trends that platform X or Y is better here or there, comparing applications instead of seeing homogeneity and the benefits for the final customer, thus using architectures designed for completely different ecosystems.I am not saying it cannot be done or should not be done; different ecosystems can coexist as long as it is in a harmonious way. But when we talk about native integrations, add-ons, connectors, and others, SAP BTP – SAP Integration Suite is definitely unbeatable when the backend is SAP, whether ECC or S/4HANA.Figure 1: Frankenstein ArchitectureThe “Legacy Mindset” Trap: The True Obstacle to InnovationWe can discuss tools, vendors, and platforms all day long, but very little of this is really limited by technology. The biggest barrier between us and a good innovation experience is habit — based on years developing legacy systems (“we will not touch it, it is working, who developed it already left the company, there is no documentation”), stable but rigid architectures, with familiar but inflexible experiences, and primitive fears of change.Many companies still think with the logic of on-premise integration landscapes from a decade ago. This mindset generates frustration: fear of the new, discomfort with unfamiliar paradigms, and, in most cases, a fundamental lack of technical understanding of what modern platforms really offer.Treating SAP BTP as if it were an on-premise PI/PO is not a technological limitation, but a mindset limitation. When cloud-native services become only point replacements for legacy runtimes, their true potential is never reached.Real innovation does require a mindset change. The question should no longer be “How do I create this mapping?”, but instead:“Should this be a mapping? Should it be an event? An API? Or should it even exist in its current form?”Without this transition, organizations repeat historical patterns in new terrain, bringing the limitations of the past into today’s technologies. The result is not modernization, but legacy running in the cloud.The Voice of the SAP Integration Suite Consultant: You Are the Integration BridgeAn experienced, senior, or specialist integration consultant, with knowledge in EM / EAM / APIM / IA / CPI, should not be just a ticket executor or focused exclusively on project delivery. We must act as strategic advisors. Our responsibility is to position ourselves — not to complain, but to help architects and business stakeholders make better decisions.When technical expertise aligns with business objectives, ISA-M (Integration Solution Advisory Methodology) stops being a forgotten PDF and becomes a living instrument, capable of guiding projects to success.We have already gone through several topics; now I would like to enter a topic that can help a lot, from a major SAP partner where one of its co-owners is one of the biggest influencers and who contributed for years to the SCN community, @MichalKrawczykLet’s talk about INT4 Shield, a tool that can help your company get out of this tangle of applications, the disconnected ecosystem that can be characterized as a Frankenstein architectureDismantling the Frankenstein Architecture in case of Multiples PlatformsThe Int4 Suite (previously known as Int4 IFTT/Shield) is a test automation and service virtualization tool designed specifically for SAP ecosystems. It acts as an “accelerator” to dismantle the Frankenstein architecture and simplify complex migrations.Image 2 – Dismantling the Frankenstein ArchitectureTo bring integrations from external platforms back to SAP BTP, or migration from SAP PI/PO, the biggest fear is functional regression (breaking what already works).Third-Party Virtualization: Int4 Shield can simulate the responses of those “external platforms” that today hold the APIM framework and custom integrations. This allows you to develop on SAP BTP and test the end-to-end flow without needing the external system to be ready or available.Parity Guarantee: You can capture the behavior of the external platform and validate whether the new implementation on SAP Integration Suite delivers exactly the same result, ensuring that the original “winning” strategy is restored without operational risks.PI/PO Migration: The End of Manual Reverse EngineeringThe scenario of migrating UDFs (User Defined Functions) and complex Java mappings without documentation is one of the biggest time and cost bottlenecks. Int4 Shield addresses exactly these points:Payload Capture AutomationInstead of a consultant needing to manually extract payloads from production (which involves security and compliance risks), Int4 Shield automates the capture of real messages from the PI/PO production or QA environment. It creates a “test case repository” based on real business data.Comparative Tests (Side-by-Side)Int4 Shield executes the mapping in the old PI/PO and, simultaneously, the new mapping in SAP Integration Suite (BTP).Automatic Comparison: It compares the output XML/JSON of both. If there is a difference of a single cent or character due to a complex UDF, the tool points out exactly where the error is.No Reverse Engineering: The consultant does not need to understand every line of legacy Java code. They need to ensure that Output A (Legacy) is equal to Output B (BTP). Int4 Shield validates this massively, testing hundreds of scenarios in minutes.Resource and Time ReductionElimination of Manual Testing: The effort to manually test complex mappings is reduced by up to 80%.Independence from Documentation: As the tool uses the real message behavior as the “absolute truth,” the lack of UDF documentation is no longer a critical blocker.Summary of Technological BenefitsManual ChallengeSolution with Int4 ShieldPayload ExtractionAutomated and secure capture of real messages.UDFs/Java MappingsValidation by result comparison (Black-box testing).Reverse EngineeringFocus on the final result, not the old code.Frankenstein ArchitectureSecure validation of migration from external components to BTP.Dismantling the Frankenstein SAP PI/PO mappings and othersThe Figaf tool is from another the bigg influencers and who contributed for years to the SCN community, @daniel.graversen (specifically the Figaf DevOps Suite and its Migration Edition) is focused almost exclusively on the integration layer, serving as the go-to solution for migrations from SAP PI/PO to SAP Integration Suite (BTP).While it is not a ‘generic’ migration tool for any external application (such as a legacy database or a non-SAP ERP), it facilitates the migration of the integration flows that connect those applications to the SAP ecosystem.Figaf: Focus and CapabilitiesFigaf acts as a DevOps and Migration accelerator. It doesn’t just move code; it attempts to “translate” legacy logic into the new BTP environment.Automated Migration: Automatically converts PI/PO ICOs (Integrated Configuration Objects) into Cloud Integration (iFlows).Logic Translation: Transforms complex Java/Mapping UDFs (User-Defined Functions) into BTP-compatible Groovy scripts.Lifecycle Management: Offers tools for transports, Git versioning, and automatic documentation—areas where standard SAP BTP functionality can sometimes fall short.Scope: Focused on SAP PI/PO, SAP Integration Suite (CPI), and API Management.Perspective:FeatureFigaf (Migration Edition/DevOps)Int4 ShieldTool DNAFocused on Migration and DevOps. Helps create and move integration objects.Focused on Regression Testing. Ensures nothing broke after the change.iFlow AutomationYes. Automatically creates iFlows and converts mappings.No. It tests what you have already migrated (manually or via Figaf).Backend TestingLimited to the integration layer.Strong. Validates the final result within S/4HANA or ECC (e.g., if the IDoc generated the correct Sales Order).Simulation (Mocking)Tests flows by sending messages.Simulates external systems. Allows testing without needing peripheral systems to be connected.PlatformsSAP PI/PO and SAP Integration Suite.Multi-platform (Boomi, MuleSoft, WebMethods, etc.).Both “migration PI/PO” and “dismantling Frankenstein landscape” can coexist ? Off course Which one to choose?Choose Figaf if: You have hundreds of interfaces in PI/PO and want to automate their creation in BTP, saving months of manual development and Groovy scripting.Choose Int4 Shield if: Your focus is Quality Assurance (QA) and you need to prove to the business that the “end-to-end” process (from the external system to the S/4HANA database) remains identical after the migration.RISE with SAP and Clean Core: The Last Chance to Fix the PastThe RISE with SAP methodology is not only a path to move the backend to S/4HANA — it represents a rare opportunity to rethink historical decisions, clean up excesses, and correct distortions that accumulated over the years. When we talk about Clean Core, the focus usually falls almost exclusively on the backend: excessive ABAP Z, direct core modifications, custom logic created to address momentary urgencies that became permanent.This effort is correct, necessary, and inevitable, but there is a critical point that often stays out of the equation: the integration layer.If the company is willing to revisit decades of customized developments in SAP ECC or S/4HANA, why not apply the same principle to the integration architecture?Integration is not optional. It is essential for the business to function. It is where processes connect, data flows, partners integrate, and critical operations happen in real time.Ignoring this layer during a RISE initiative is losing half of the transformation value.The Clean Core concept should not stop at ABAP. It needs to extend to how integrations are designed, governed, and evolved. Keeping the core clean while fragmenting integration with multiple external tools, borrowed architectures, and misaligned standards creates a paradox: a modern backend supported by a chaotic integration.SAP Integration Suite, within the SAP BTP ecosystem, exists exactly to absorb this complexity outside the core. APIs, events, message-oriented integrations, and B2B were designed so that the backend remains stable, standardized, and ready for continuous evolution. Breaking this logic, outsourcing native capabilities to external solutions without a clear strategic reason, goes in the opposite direction of what RISE and Clean Core propose.The RISE moment is the right moment to visit, observe, and question:Why does this integration exist in this way?Why was this mapping created like this? Where is the documentation?How are we going to migrate this tangle of integrations from SAP PI/PO, which has no documentation, to SAP CPI? Is this not the moment to evaluate what is worth migrating and what is worth rebuilding in a cleaner way?Should this logic be in ABAP Z or outside the core?Does this functionality already exist natively in SAP Integration Suite?Are we really homogenizing the architecture or just replacing one fragmented architecture with another?RISE with SAP offers the context, executive sponsorship, and organizational momentum that rarely happen in day-to-day work. It is exactly at this moment that structural decisions need to be made — not only in the backend, but across the entire integration landscape.Cleaning the core and ignoring integration is an incomplete transformation. Thinking Clean Core without Clean Integration is postponing known problems to a more expensive and more complex future.True modernization happens when backend and integration evolve together, in a coherent, governed way and aligned with the business strategy.Image 3 – Rise and Clean core backend plus Integration refactoringDisclaimer: The views expressed in this article are based on personal professional experience and do not represent SAP, its partners, or any affiliated organization. ConclusionI hope this reflection encourages Integration Consultants to think outside the box. It is vital that we are involved in strategic decisions and the application of the SAP ISA-M (Integration Solution Advisory Methodology).We must act as strategic advisors, not just ticket executors. Our responsibility is to help architects and stakeholders make better decisions. Your opinion is not just a technical preference; it is a vital contribution to long-term maintainability. When we understand the full potential of the platform, we stop being “box connectors” and become the architects of a truly connected, clean future. Thank you.Kind regards,Viana.   Read More Technology Blog Posts by Members articles 

#SAP

#SAPTechnologyblog