ClouDonnaClouDonna
Home of Architects

Là où l'architecture devient une décision que les dirigeants comprennent

Un espace pour que les architectes structurent les arbitrages derrière une décision et les expliquent dans le langage que parle déjà l'entreprise.

Pourquoi cette architecture ?Pourquoi maintenant ?Pourquoi cette plateforme ?Quels sont les arbitrages ?Qu'est-ce que cela nous coûte stratégiquement ?Que se passe-t-il si nos hypothèses changent ?Comment l'expliquer au directeur financier ?
Home of Architects

Home of Architects

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

Modèles d'architecture

Quelques modèles illustratifs, chacun répondant aux questions qui comptent vraiment pour la décision.

SAP BDC + DatabricksA governed SAP-native data core paired with open compute for advanced AI and data science.
Quel problème ça résout

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

Ce qui compte
  • 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
Arbitrages
  • Two platforms to operate instead of one
  • Requires clear ownership of the boundary between governed core and open compute
Qui est concerné:CIOChief AI OfficerEnterprise Architect
Ce que le directeur financier doit savoir

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.

Ce qui changerait ce choix

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.
Quel problème ça résout

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

Ce qui compte
  • 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
Arbitrages
  • Requires deliberate data sharing design to avoid duplicating the same data in both platforms
  • Two governance models to keep aligned
Qui est concerné:CIOChief Data OfficerEnterprise Architect
Ce que le directeur financier doit savoir

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

Ce qui changerait ce choix

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.
Quel problème ça résout

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

Ce qui compte
  • 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
Arbitrages
  • Extension development requires different skills than traditional ABAP customization
  • Existing custom code needs a migration plan, not just a policy going forward
Qui est concerné:CIOEnterprise ArchitectSAP Solution Architect
Ce que le directeur financier doit savoir

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.

Ce qui changerait ce choix

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.
Quel problème ça résout

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

Ce qui compte
  • A shared, governed data foundation feeding every AI use case
  • Central model governance and monitoring
  • Federated access for teams to build within defined guardrails
Arbitrages
  • More upfront coordination than letting teams build independently
  • Guardrails need active enforcement, not just documentation
Qui est concerné:Chief AI OfficerCIOChief Data Officer
Ce que le directeur financier doit savoir

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

Ce qui changerait ce choix

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

Avant et après

Ce qui change réellement lors d'une telle modernisation, sur le plan architectural et business.

SAP BW modernization

Avant
  • 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
Après
  • 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
Impact architectural

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.

Impact business

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.

Décisions types

Des Architecture Decision Records illustratifs, chacun traduit dans un langage business clair.

Lakehouse or data warehouse for the next platform

Contexte
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.
Décision
Choose the pattern that matches where most future workload growth actually comes from, not where most data sits today.
Conséquences
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.
En langage business

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

Contexte
One cloud provider already hosts most of the estate. A second provider offers a genuinely better fit for one upcoming workload.
Décision
Stay single cloud unless a second provider creates a clear, durable advantage that outweighs the operational cost of running two.
Conséquences
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.
En langage business

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

Central integration platform or point to point integrations

Contexte
The number of systems that need to talk to each other has grown past what point to point connections can support cleanly.
Décision
Move to a central integration layer once the cost of maintaining point to point connections starts slowing delivery down, not before.
Conséquences
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.
En langage business

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

Build or buy a core capability

Contexte
A capability central to the business could be built in house or bought as a platform.
Décision
Build only where the capability is a genuine source of competitive advantage. Buy everywhere else.
Conséquences
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.
En langage business

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

Apportez votre propre décision d'architecture

Chaque Architecture Decision Record ici s'appuie sur le même moteur Donna que votre équipe utiliserait.

Commencer avec Donna