ClouDonnaClouDonna
Home of Architects

Donde la arquitectura se convierte en una decisión que los directivos entienden

Un espacio para que los arquitectos estructuren las compensaciones detrás de una decisión y las expliquen en el lenguaje que ya habla el negocio.

¿Por qué esta arquitectura?¿Por qué ahora?¿Por qué esta plataforma?¿Cuáles son las compensaciones?¿Qué nos cuesta esto estratégicamente?¿Qué pasa si cambian nuestras suposiciones?¿Cómo se lo explico al CFO?
Home of Architects

Home of Architects

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

Patrones de arquitectura

Algunos patrones ilustrativos, cada uno respondiendo a las preguntas que realmente importan para la decisión.

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

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

Qué importa
  • 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
Compensaciones
  • Two platforms to operate instead of one
  • Requires clear ownership of the boundary between governed core and open compute
A quién le concierne:CIOChief AI OfficerEnterprise Architect
Qué necesita saber el CFO

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.

Qué cambiaría esta elección

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.
Qué problema resuelve

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

Qué importa
  • 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
Compensaciones
  • Requires deliberate data sharing design to avoid duplicating the same data in both platforms
  • Two governance models to keep aligned
A quién le concierne:CIOChief Data OfficerEnterprise Architect
Qué necesita saber el CFO

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

Qué cambiaría esta elección

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.
Qué problema resuelve

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

Qué importa
  • 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
Compensaciones
  • Extension development requires different skills than traditional ABAP customization
  • Existing custom code needs a migration plan, not just a policy going forward
A quién le concierne:CIOEnterprise ArchitectSAP Solution Architect
Qué necesita saber el CFO

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.

Qué cambiaría esta elección

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.
Qué problema resuelve

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

Qué importa
  • A shared, governed data foundation feeding every AI use case
  • Central model governance and monitoring
  • Federated access for teams to build within defined guardrails
Compensaciones
  • More upfront coordination than letting teams build independently
  • Guardrails need active enforcement, not just documentation
A quién le concierne:Chief AI OfficerCIOChief Data Officer
Qué necesita saber el CFO

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

Qué cambiaría esta elección

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

Antes y después

Qué cambia realmente con una modernización así, en términos de arquitectura y de negocio.

SAP BW modernization

Antes
  • 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
Despué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
Impacto en la arquitectura

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.

Impacto en el negocio

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.

Decisiones de ejemplo

Architecture Decision Records ilustrativos, cada uno traducido a un lenguaje de negocio claro.

Lakehouse or data warehouse for the next platform

Contexto
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.
Decisión
Choose the pattern that matches where most future workload growth actually comes from, not where most data sits today.
Consecuencias
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 términos de negocio

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

Contexto
One cloud provider already hosts most of the estate. A second provider offers a genuinely better fit for one upcoming workload.
Decisión
Stay single cloud unless a second provider creates a clear, durable advantage that outweighs the operational cost of running two.
Consecuencias
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 términos de negocio

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

Central integration platform or point to point integrations

Contexto
The number of systems that need to talk to each other has grown past what point to point connections can support cleanly.
Decisión
Move to a central integration layer once the cost of maintaining point to point connections starts slowing delivery down, not before.
Consecuencias
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 términos de negocio

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

Build or buy a core capability

Contexto
A capability central to the business could be built in house or bought as a platform.
Decisión
Build only where the capability is a genuine source of competitive advantage. Buy everywhere else.
Consecuencias
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 términos de negocio

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

Trae tu propia decisión de arquitectura

Cada Architecture Decision Record aquí funciona sobre el mismo motor de Donna que usaría tu equipo.

Empezar con Donna