ClouDonnaClouDonna
Home of Architects

Dove l'architettura diventa una decisione che i dirigenti capiscono

Uno spazio per gli architetti per strutturare i compromessi dietro una decisione e spiegarli nel linguaggio che il business già parla.

Perché questa architettura?Perché adesso?Perché questa piattaforma?Quali sono i compromessi?Cosa ci costa questo strategicamente?Cosa succede se le nostre ipotesi cambiano?Come lo spiego al CFO?
Home of Architects

Home of Architects

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

Pattern architetturali

Alcuni pattern illustrativi, ciascuno risponde alle domande che contano davvero per la decisione.

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

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

Cosa conta
  • 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
Compromessi
  • Two platforms to operate instead of one
  • Requires clear ownership of the boundary between governed core and open compute
Chi dovrebbe interessarsene:CIOChief AI OfficerEnterprise Architect
Cosa deve sapere il 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.

Cosa cambierebbe questa scelta

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.
Quale problema risolve

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

Cosa conta
  • 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
Compromessi
  • Requires deliberate data sharing design to avoid duplicating the same data in both platforms
  • Two governance models to keep aligned
Chi dovrebbe interessarsene:CIOChief Data OfficerEnterprise Architect
Cosa deve sapere il CFO

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

Cosa cambierebbe questa scelta

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.
Quale problema risolve

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

Cosa conta
  • 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
Compromessi
  • Extension development requires different skills than traditional ABAP customization
  • Existing custom code needs a migration plan, not just a policy going forward
Chi dovrebbe interessarsene:CIOEnterprise ArchitectSAP Solution Architect
Cosa deve sapere il 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.

Cosa cambierebbe questa scelta

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.
Quale problema risolve

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

Cosa conta
  • A shared, governed data foundation feeding every AI use case
  • Central model governance and monitoring
  • Federated access for teams to build within defined guardrails
Compromessi
  • More upfront coordination than letting teams build independently
  • Guardrails need active enforcement, not just documentation
Chi dovrebbe interessarsene:Chief AI OfficerCIOChief Data Officer
Cosa deve sapere il 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.

Cosa cambierebbe questa scelta

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

Prima e dopo

Cosa cambia davvero con una modernizzazione di questo tipo, in termini architetturali e di business.

SAP BW modernization

Prima
  • 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
Dopo
  • 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
Impatto architetturale

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.

Impatto di 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.

Decisioni di esempio

Architecture Decision Record illustrativi, ciascuno tradotto in un linguaggio di business chiaro.

Lakehouse or data warehouse for the next platform

Contesto
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.
Decisione
Choose the pattern that matches where most future workload growth actually comes from, not where most data sits today.
Conseguenze
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 termini di 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

Contesto
One cloud provider already hosts most of the estate. A second provider offers a genuinely better fit for one upcoming workload.
Decisione
Stay single cloud unless a second provider creates a clear, durable advantage that outweighs the operational cost of running two.
Conseguenze
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 termini di business

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

Central integration platform or point to point integrations

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

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

Build or buy a core capability

Contesto
A capability central to the business could be built in house or bought as a platform.
Decisione
Build only where the capability is a genuine source of competitive advantage. Buy everywhere else.
Conseguenze
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 termini di business

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

Porta la tua decisione di architettura

Ogni Architecture Decision Record qui gira sullo stesso motore Donna che userebbe il tuo team.

Inizia con Donna