ClouDonnaClouDonna
Home of Architects

Where architecture becomes a decision executives understand

A place for enterprise, solution, data, AI and cloud architects to structure the trade offs behind a decision, and explain them in language the business already speaks.

Why this architecture?Why now?Why this platform?What are the trade offs?What does it cost us strategically?What happens if our assumptions change?How do I explain this to the CFO?
Home of Architects

Home of Architects

How architects turn a platform decision into something a CFO can read in one page.

Architecture patterns

A few illustrative patterns, each answering the questions that actually matter for the decision.

SAP BDC + DatabricksA governed SAP-native data core paired with open compute for advanced AI and data science.
What problem it solves

SAP data stays governed and trustworthy while AI teams keep the flexibility a purely SAP-native platform doesn't offer.

What matters
  • SAP Business Data Cloud as the governed core
  • Databricks for advanced AI, ML and data science workloads
  • A defined data product boundary between the two
Trade offs
  • Two platforms to operate instead of one
  • Requires clear ownership of the boundary between governed core and open compute
Who should care:CIOChief AI OfficerEnterprise Architect
What the CFO needs to know

Two platforms means two commercial relationships to manage, but each is scoped to what it's actually good at, rather than paying for capability you don't use.

What changes this choice

If AI ambitions stay modest, a single SAP-native platform may cover the need without Databricks at all.

SAP BDC + SnowflakeA governed SAP-native core paired with Snowflake for company-wide governed analytics beyond SAP.
What problem it solves

Many enterprises have significant non-SAP data that still needs the same governance discipline as the SAP core.

What matters
  • SAP Business Data Cloud as the governed SAP core
  • Snowflake as the governed analytics layer for non-SAP data
  • Data sharing between the two rather than duplication
Trade offs
  • Requires deliberate data sharing design to avoid duplicating the same data in both platforms
  • Two governance models to keep aligned
Who should care:CIOChief Data OfficerEnterprise Architect
What the CFO needs to know

Avoids paying twice for governance capability that both platforms already provide, if the data sharing boundary is designed well.

What changes this choice

If most valuable data is SAP-native, the case for a second governed platform weakens considerably.

Clean Core extension architectureExtend SAP S/4HANA functionality without custom code inside the core, keeping upgrades and cloud migration viable.
What problem it solves

Years of custom ABAP code inside the SAP core make every upgrade slower and riskier, and block a path to SAP's cloud roadmap.

What matters
  • SAP BTP as the extension platform
  • SAP Integration Suite for connecting extensions to the core
  • A defined policy for what may and may not be customized inside the core
Trade offs
  • Extension development requires different skills than traditional ABAP customization
  • Existing custom code needs a migration plan, not just a policy going forward
Who should care:CIOEnterprise ArchitectSAP Solution Architect
What the CFO needs to know

Slower, more expensive upgrades are a real recurring cost this pattern reduces, but the migration of existing customizations is itself a project to budget for.

What changes this choice

If an upcoming SAP upgrade or cloud migration isn't on the roadmap, the urgency of adopting this pattern now is lower.

Enterprise AI architectureA shared foundation for AI initiatives across the company, instead of each team building its own stack.
What problem it solves

AI pilots multiply across departments on inconsistent platforms, making governance, reuse and scaling nearly impossible.

What matters
  • A shared, governed data foundation feeding every AI use case
  • Central model governance and monitoring
  • Federated access for teams to build within defined guardrails
Trade offs
  • More upfront coordination than letting teams build independently
  • Guardrails need active enforcement, not just documentation
Who should care:Chief AI OfficerCIOChief Data Officer
What the CFO needs to know

The real cost comparison isn't this architecture against nothing, it's this architecture against N independent AI stacks that don't share investment.

What changes this choice

If AI activity is genuinely limited to one team with no near-term plan to expand, a shared foundation may be premature.

Before and after

What actually changes when a modernization like this happens, in architecture and in business terms.

SAP BW modernization

Before
  • SAP BW as the sole reporting layer
  • Multiple extracts feeding different downstream tools
  • Point-to-point integration between systems
  • The same data duplicated across several targets
  • Manual reconciliation before executive reporting
  • Fragmented analytics owned by different teams with different numbers
After
  • A modern, governed data architecture with a single source of truth
  • Reusable data products instead of one-off extracts
  • A shared semantic layer so metrics mean the same thing everywhere
  • Data prepared and governed well enough for AI workloads, not just BI
  • Modern, self-service analytics on top of governed data
  • Meaningfully less redundant data movement between systems
Architecture impact

Trades a web of point-to-point extracts for a smaller number of governed data products with clear ownership — fewer integration points to maintain, but each one now carries more responsibility.

Business impact

Executive reporting stops requiring manual reconciliation between teams' numbers, and new analytics use cases (including AI) can build on data that is already governed instead of starting from scratch.

Example decisions

Illustrative Architecture Decision Records, each translated into plain business language.

Lakehouse or data warehouse for the next platform

Context
Analytics and early AI workloads both need to sit on the same platform, but the two patterns optimize for different things: a warehouse for governed, structured reporting, a lakehouse for flexible, large-scale data and model work.
Decision
Choose the pattern that matches where most future workload growth actually comes from, not where most data sits today.
Consequences
A lakehouse buys flexibility for AI and unstructured data at the cost of a steeper governance and skills curve. A warehouse keeps governance simple but can slow down AI ambitions later.
In business terms

This decision trades near-term simplicity against how fast the company can act on AI in two to three years.

Single cloud or multi cloud

Context
One cloud provider already hosts most of the estate. A second provider offers a genuinely better fit for one upcoming workload.
Decision
Stay single cloud unless a second provider creates a clear, durable advantage that outweighs the operational cost of running two.
Consequences
Single cloud keeps operations, skills and vendor leverage concentrated. Multi cloud adds real flexibility and negotiating power, at the cost of duplicated tooling and skills.
In business terms

This is a trade between negotiating leverage and operating cost, not a technology preference.

Central integration platform or point to point integrations

Context
The number of systems that need to talk to each other has grown past what point to point connections can support cleanly.
Decision
Move to a central integration layer once the cost of maintaining point to point connections starts slowing delivery down, not before.
Consequences
A central platform reduces long term complexity but is a real upfront investment. Point to point stays cheap short term but compounds risk with every new system added.
In business terms

This decision is about paying down complexity now versus paying it back later, with interest.

Build or buy a core capability

Context
A capability central to the business could be built in house or bought as a platform.
Decision
Build only where the capability is a genuine source of competitive advantage. Buy everywhere else.
Consequences
Building keeps full control and differentiation but carries ongoing engineering cost and delivery risk. Buying is faster and lower risk but creates a real dependency on the vendor.
In business terms

The real question for the business is whether this capability is where the company wins, or where it just needs to keep up.

Bring your own architecture decision

Every Architecture Decision Record here runs on the same Donna engine your team would use.

Start with Donna