Mapping the Architecture Landscape: Integration Patterns, NFR Categories, and Child-Topic Sequencing (Part 2)

Once the 'why' is established, an architect needs a working map of the landscape: what are the categories of decisions, what options exist within each, and in what order should deeper learning happen. This lesson builds that map at a level of detail suitable for someone who understands individual SAP modules but is now assembling the bigger picture.

Integration patterns generally fall into a few families. Batch/file-based integration (still common for legacy interfaces and large data loads) trades real-time responsiveness for simplicity and robustness under network interruption. Synchronous RFC/API calls give immediate responses but create tight coupling - if the receiving system is down, the calling process fails immediately, which can be good (fail-fast) or bad (cascading outage) depending on the process. Asynchronous messaging and event-driven patterns (increasingly emphasized on BTP with event mesh and integration services) decouple systems in time, improving resilience but adding complexity in tracking message state and handling duplicates or out-of-order delivery. IDocs remain relevant in many ECC and S/4HANA on-premise landscapes for master data and transactional document exchange, but SAP's cloud-first direction favors REST/OData APIs and events for new builds, particularly in public cloud scenarios where IDoc-based custom extensions may be restricted or unavailable.

Non-functional requirements should be organized into categories an architect can govern systematically: performance and scalability (response times, batch windows, data volume growth, sizing), availability and resilience (uptime targets, failover, disaster recovery, graceful degradation when an interface partner is down), security (authentication/authorization models, data protection, segregation of duties, interface-level access control), maintainability and clean core (how much custom logic lives in the ABAP stack versus BTP, upgrade impact, technical debt), auditability and compliance (logging, traceability of cross-system transactions, regulatory retention), and operability (monitoring, alerting, support handover, runbooks). Each category needs an explicit target, not just 'as fast as possible' or 'as secure as possible,' because every NFR has a cost and a trade-off against others - for example, end-to-end encryption improves security but can add measurable latency to high-volume interfaces, and real-time synchronous validation improves data quality but reduces resilience if the validating system has downtime.

Migration and rollback thinking must be layered onto both integration and NFR decisions from the start, not bolted on later. When moving from ECC to S/4HANA, interfaces built on obsolete transaction codes or fields need remediation; cutover plans need parallel run periods where feasible, explicit rollback triggers (what conditions cause reverting to the legacy system), and clear data reconciliation checkpoints between old and new integration paths. In hybrid landscapes (ECC or S/4HANA on-premise plus BTP extensions), rollback of a BTP-side change is often easier and faster than rollback of a core ABAP change, which is one more reason clean core separation has operational value beyond just upgrade friendliness.

Governance ties this together: architecture decisions should be documented as explicit trade-off records (what was chosen, what alternatives were rejected, why, and under what conditions the decision should be revisited), reviewed by an architecture board or equivalent, and revisited when deployment model, scale, or regulatory context changes. This lesson's map should guide the order in which a learner explores child topics: start with integration technology deep-dives, then move into security architecture, then performance/scalability engineering, then data migration and cutover strategy, and finally governance and operating model topics - each of which will go far deeper than this parent overview can.

During a private cloud S/4HANA rollout, an architecture team initially chose synchronous API calls for a real-time credit check integration with an external finance system. Load testing revealed that peak-season order volume caused response time breaches whenever the external system had brief slowdowns, cascading into order entry delays. The team redesigned the flow to an asynchronous pattern with a cached credit status and periodic refresh, trading a small amount of data freshness for significantly better resilience, and documented the trade-off in an architecture decision record for future reference.

• Choosing an integration pattern based on familiarity rather than the resilience and coupling needs of the specific process.
• Setting vague non-functional targets like 'fast' or 'secure' instead of measurable thresholds.
• Bolting migration and rollback planning onto a project late instead of designing for it from the start.
• Assuming IDoc-based patterns are equally available and equally recommended across ECC, on-premise S/4HANA, and public cloud S/4HANA.
• Skipping documentation of why a trade-off was chosen, making future re-evaluation harder when conditions change.

• Classify every integration requirement by coupling tolerance (can the process wait, or does it need an immediate answer) before selecting a pattern.
• Define measurable NFR targets for performance, availability, security, and auditability separately, and record accepted trade-offs.
• Treat clean core separation as both an upgrade-friendliness measure and an operational resilience measure.
• Build rollback and reconciliation checkpoints into migration plans from the initial design phase, not as a late addition.
• Maintain lightweight architecture decision records so trade-off reasoning survives staff turnover and project handover.

Expect questions asking you to compare integration patterns for a given scenario and justify the choice using NFR trade-offs, such as 'would you use synchronous or asynchronous integration for a real-time inventory check, and why.' Interviewers may also probe governance maturity by asking how you would document or defend an architecture decision months later, testing whether you think beyond the initial build to long-term maintainability.