Decompose by Cadence, Not by Module: A Composability Rule That Survives SAP

Nearly every SAP modernization plan we review has the same picture in it: a core box labelled S/4HANA, a ring of side-by-side extensions on BTP, and arrows labelled "composable." The decomposition follows module boundaries — finance stays in, order management moves out, commerce becomes its own stack. It looks disciplined. Two years later the extensions release on the same quarterly cycle as the core, because every meaningful change still requires a coordinated regression test across all of them. The architecture was composed; the delivery was not. The cut line was wrong.

Module boundaries are a licensing artifact, not a design principle

SAP modules exist because software was sold and implemented that way. They are a reasonable map of functional ownership and a poor map of where change actually originates. Pricing logic changes monthly in some businesses. Tax determination changes when legislation does. A promotions engine in a consumer business changes weekly; the same engine in industrial distribution barely changes at all. When you decompose along module lines, you bundle a weekly-cadence capability with an annual-cadence one and then wonder why the release train runs at the speed of the slowest passenger.

The alternative rule is blunt: things that change together at the same rate belong together; things that change at different rates need a seam between them. That single test does more architectural work than any reference diagram, and it survives contact with SAP's own roadmap, which keeps redrawing module edges anyway.

What the composability data is actually telling us

The MACH Alliance's 2025 global research reported that roughly nine in ten organizations running composable technology say it met or exceeded ROI expectations — a meaningful improvement over prior years. Read that alongside the migration reality: a 2025 ASUG research report on S/4HANA journeys found customers shifting emphasis from deadline compliance toward measurable value, while a Horvath study cited by CIO found implementations running around 30% longer than planned. The composable wins are real, but they are concentrated in places where teams isolated a genuinely fast-moving capability and gave it its own lifecycle — not in places where they redrew boxes.

Agentic AI sharpens the argument. SAP now ships hundreds of AI features and Joule agents across the Business Suite, and agents amplify whatever cadence structure you already have. An agent that resolves order exceptions needs the exception-handling logic to be deployable without a core release; if it isn't, the agent becomes a suggestion engine that waits on a change board.

How to run the cadence audit

This is a two-week exercise, not a program. Pull the last 24 months of change records and map them against capabilities:

• Count changes, not story points. Frequency of change requests per capability is the signal. Effort is noise introduced by your current architecture.
• Separate regulatory from commercial cadence. Both change, but regulatory change is scheduled and testable; commercial change is unpredictable and needs a shorter path to production.
• Find the coupling tax. For each fast-moving capability, note how many slow-moving components had to be retested. That number is your business case.
• Check the data direction. A capability can only run at its own cadence if it owns its write path. Shared writes to the same master data object collapse two cadences into one.
• Name the seam technology per boundary. Event, API, or batch — decided by latency and consistency needs, not by platform fashion.

Where this changes the SAP conversation

Cadence-based decomposition usually produces a smaller extension estate than module-based plans, because most capabilities genuinely don't need to move fast. It also produces sharper priorities: the two or three high-cadence capabilities that deserve real isolation, proper contracts, and their own deployment pipeline. That is the work we typically front-load in SAP modernization engagements, and it is what makes later AI and agent work deployable rather than demo-only.

The forward-looking version of this is uncomfortable for roadmap owners: as AI agents take on more exception handling, cadence differentials inside the landscape will widen, not narrow. Architectures cut along module lines will feel that as friction; architectures cut along cadence lines will absorb it. If your modernization program has no cadence map, that is the artifact to build before the next architecture review.