Home of Architects

Wo Architektur zu einer Entscheidung wird, die Führungskräfte verstehen

Ein Ort für Architektinnen und Architekten, um die Abwägungen hinter einer Entscheidung zu strukturieren und sie in der Sprache des Business zu erklären.

Warum diese Architektur?Warum jetzt?Warum diese Plattform?Welche Trade-offs gibt es?Was kostet uns das strategisch?Was passiert, wenn sich unsere Annahmen ändern?Wie erkläre ich das dem CFO?

Home of Architects

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

Architekturmuster

Ein paar illustrative Muster, jedes beantwortet die Fragen, die für die Entscheidung wirklich zählen.

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

Welches Problem es löst

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

Was zählt

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

Abwägungen

Two platforms to operate instead of one
Requires clear ownership of the boundary between governed core and open compute

Wen es betrifft:CIOChief AI OfficerEnterprise Architect

Was der CFO wissen muss

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.

Was diese Wahl ändert

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.

Welches Problem es löst

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

Was zählt

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

Abwägungen

Requires deliberate data sharing design to avoid duplicating the same data in both platforms
Two governance models to keep aligned

Wen es betrifft:CIOChief Data OfficerEnterprise Architect

Was der CFO wissen muss

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

Was diese Wahl ändert

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.

Welches Problem es löst

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

Was zählt

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

Abwägungen

Extension development requires different skills than traditional ABAP customization
Existing custom code needs a migration plan, not just a policy going forward

Wen es betrifft:CIOEnterprise ArchitectSAP Solution Architect

Was der CFO wissen muss

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.

Was diese Wahl ändert

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.

Welches Problem es löst

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

Was zählt

A shared, governed data foundation feeding every AI use case
Central model governance and monitoring
Federated access for teams to build within defined guardrails

Abwägungen

More upfront coordination than letting teams build independently
Guardrails need active enforcement, not just documentation

Wen es betrifft:Chief AI OfficerCIOChief Data Officer

Was der CFO wissen muss

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

Was diese Wahl ändert

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

Vorher und nachher

Was sich bei einer solchen Modernisierung tatsächlich ändert, architektonisch und geschäftlich.

SAP BW modernization

Vorher

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

Nachher

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

Architektur-Auswirkung

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.

Geschäftliche Auswirkung

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.

Beispielentscheidungen

Illustrative Architecture Decision Records, jeweils in verständliche Business-Sprache übersetzt.

Lakehouse or data warehouse for the next platform

Kontext: 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.
Entscheidung: Choose the pattern that matches where most future workload growth actually comes from, not where most data sits today.
Konsequenzen: 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-Sprache

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

Kontext: One cloud provider already hosts most of the estate. A second provider offers a genuinely better fit for one upcoming workload.
Entscheidung: Stay single cloud unless a second provider creates a clear, durable advantage that outweighs the operational cost of running two.
Konsequenzen: 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-Sprache

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

Central integration platform or point to point integrations

Kontext: The number of systems that need to talk to each other has grown past what point to point connections can support cleanly.
Entscheidung: Move to a central integration layer once the cost of maintaining point to point connections starts slowing delivery down, not before.
Konsequenzen: 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-Sprache

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

Build or buy a core capability

Kontext: A capability central to the business could be built in house or bought as a platform.
Entscheidung: Build only where the capability is a genuine source of competitive advantage. Buy everywhere else.
Konsequenzen: 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-Sprache

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

Bringen Sie Ihre eigene Architekturentscheidung mit

Jedes Architecture Decision Record hier läuft auf derselben Donna-Engine, die auch Ihr Team nutzen würde.

Mit Donna starten