ClouDonnaClouDonna
Example Decisions

See how Donna works through a real decision

Five illustrative enterprise decisions, worked through end to end. Not real customer data, but the exact same method.

Illustrative exampleTechnology StrategyTransformation Decisions

SAP BW modernization

Modernize SAP BW into SAP Business Data Cloud, Databricks, Microsoft Fabric, or a hybrid architecture?

Context
Customer input

A global manufacturer runs SAP BW on HANA alongside a patchwork of point to point extracts feeding regional reporting. Reporting is slow to change, data is duplicated across three systems, and AI initiatives have no governed foundation to build on.

Priorities
Preserve SAP-native reporting continuityCreate a governed foundation for AIReduce duplicate data flowsKeep migration risk manageable
Shortlist
SAP Business Data CloudRecommended

Strongest SAP-native continuity, governed foundation ships largely pre-built

Databricks

Strongest AI and data science flexibility, more integration work upfront

Microsoft Fabric

Best fit if Power BI and Microsoft 365 are already central to reporting

Hybrid (SAP BDC + Databricks)

SAP-native core with open compute for advanced AI workloads

Recommendation
Calculated
SAP Business Data Cloud, with Databricks as a companion platform for advanced AI workloads

The governed SAP-native foundation directly resolves the duplication problem with the least new integration work, while a companion AI platform avoids boxing in future data science ambitions.

AI interpretation
Read this as

This removes a structural blocker to every AI initiative that depends on trustworthy company-wide data.

Trade offs
  • Faster continuity with SAP BDC trades off some of the open ecosystem flexibility a pure Databricks or Fabric path would offer
  • Running two platforms (SAP BDC plus Databricks) adds operational surface area versus a single-platform choice
Risks
Calculated
  • Migration sequencing risk if legacy extracts aren't decommissioned on schedule
  • Skills gap for teams new to the governed data product model
Assumptions
Assumption
  • Regional reporting requirements stay materially similar during migration
  • No near-term divestiture or acquisition changes the SAP landscape
What could change this recommendation
Databricks becomes the better fit if ai and data science ambitions grow faster than the sap-native roadmap can support.
Microsoft Fabric becomes the better fit if power bi and the microsoft stack become the primary reporting surface company-wide.
Staying on SAP BW becomes the better fit if the ai and governance case turns out to be weaker than expected once scoped in detail.
Illustrative exampleAI and Data DecisionsTechnology Strategy

Enterprise AI platform strategy

Should AI run on a single central platform, a federated model, or a hybrid?

Context
Customer input

A financial services firm has six AI pilots running on three different platforms, none of them production-grade. Leadership wants one enterprise AI strategy instead of pilots multiplying independently.

Priorities
Governance and auditability for regulated use casesSpeed for lower-risk experimentationAvoid re-platforming every pilot from scratch
Shortlist
Fully centralized platform

Strongest governance, slower for teams wanting to experiment quickly

Fully federated model

Fastest for individual teams, weakest for regulated use cases

Hybrid: central governance, federated experimentationRecommended

Balances regulatory need with team-level speed

Recommendation
Calculated
Hybrid model: central governance and a shared data foundation, federated experimentation within guardrails

Regulated use cases (credit, fraud) need centralized auditability that a fully federated model can't provide, but forcing every low-risk experiment through the same central process would slow the exact speed leadership also wants.

AI interpretation
Read this as

One strategy instead of six independent pilots is what turns AI spend into AI results.

Trade offs
  • More coordination overhead than a single fully centralized model
  • Requires clear guardrails so federated teams don't drift from governance standards
Risks
Calculated
  • Guardrails not being enforced consistently across federated teams
  • Regulatory scrutiny increasing faster than governance maturity
Assumptions
Assumption
  • Regulated use cases stay a minority of total AI initiatives, not the majority
  • A central data foundation already exists or is being built in parallel
What could change this recommendation
Fully centralized platform becomes the better fit if regulatory requirements tighten enough that federated experimentation becomes untenable.
Fully federated model becomes the better fit if regulated use cases turn out to be a small minority of total ai activity.
Illustrative exampleTechnology StrategyVendor Decisions

Databricks versus Snowflake versus Microsoft Fabric

Which platform best fits governed analytics plus growing AI ambitions?

Context
Customer input

A retailer needs one analytics and AI platform for its next five years, replacing a legacy on-premise warehouse.

Priorities
Multi-cloud flexibilityAI and machine learning maturityCost predictability at scaleTime to first value
Shortlist
DatabricksRecommended

Strongest for AI and machine learning maturity, more setup complexity

Snowflake

Strongest for governed, predictable analytics; AI capability growing but younger

Microsoft Fabric

Fastest time to value if Microsoft is already the default stack

Recommendation
Calculated
Databricks

AI and machine learning maturity was the deciding priority, and the retailer's roadmap leans heavily on demand forecasting and personalization use cases that benefit most from that maturity.

AI interpretation
Read this as

This platform choice determines how fast AI-driven personalization can actually ship.

Trade offs
  • Higher initial setup complexity than Fabric
  • Requires more specialized skills than a fully managed warehouse-first platform
Risks
Calculated
  • Skills availability for Databricks-native engineering
  • Cost governance discipline needed for consumption-based pricing
Assumptions
Assumption
  • AI and machine learning use cases remain the primary growth driver, not just reporting
  • Multi-cloud flexibility stays a real requirement, not just a preference
What could change this recommendation
Snowflake becomes the better fit if governed, predictable analytics becomes more important than ai maturity.
Microsoft Fabric becomes the better fit if the organization consolidates further onto the microsoft stack.
Illustrative exampleInvestment DecisionsAI and Data Decisions

Build versus buy for enterprise AI

Build a custom AI capability, or buy a specialized platform?

Context
Customer input

A logistics company needs a customer service AI capability and is deciding between building on foundation models directly or buying a specialized vendor platform.

Priorities
Speed to a working capabilityDifferentiation versus commodity capabilityTotal cost over three yearsOngoing maintenance burden
Shortlist
Build on foundation models

Maximum differentiation and control, slowest to a production capability

Buy a specialized platformRecommended

Fastest to production, less differentiation versus competitors using the same platform

Recommendation
Calculated
Buy a specialized platform for the initial capability, revisit build once the use case is proven

Customer service AI is not this company's core differentiator. Buying gets a working capability to market fastest, and the build option can be reconsidered later if the use case proves valuable enough to justify the investment.

AI interpretation
Read this as

Fastest path to a working capability, with the option to invest further once value is proven.

Trade offs
  • Less differentiation versus competitors on the same vendor platform
  • Some vendor dependency until a build decision is revisited
Risks
Calculated
  • Vendor platform limitations discovered only after deeper implementation
  • Switching cost if a build decision is made later
Assumptions
Assumption
  • Customer service AI is not a core competitive differentiator for this company
  • The vendor platform can integrate with existing customer data within the required timeline
What could change this recommendation
Build on foundation models becomes the better fit if the capability proves valuable enough to justify becoming a genuine differentiator.
A different vendor platform becomes the better fit if integration limitations with existing customer data prove more severe than expected.
Illustrative exampleOperating Model DecisionsTransformation Decisions

Centralized versus federated data platform

Should data infrastructure become fully centralized, stay federated, or move to a data mesh model?

Context
Customer input

A multi-division industrial group has five business units, each historically running its own data infrastructure with little consistency.

Priorities
Consistency and governance across divisionsSpeed for divisions with urgent local needsCost efficiency at group levelRespecting real differences between divisions
Shortlist
Fully centralized platform

Strongest consistency and cost efficiency, slowest for divisions with urgent local needs

Fully federated (status quo)

Fastest locally, weakest consistency and highest total group cost

Data mesh: federated ownership, shared platform standardsRecommended

Balances division autonomy with group-level consistency

Recommendation
Calculated
Data mesh model: shared platform standards and governance, federated ownership of data products by division

The divisions have genuinely different data needs that a fully centralized model would slow down, but the current fully federated approach has produced real duplication and inconsistency. A shared-standards model addresses both.

AI interpretation
Read this as

This resolves years of division-level inconsistency without forcing a slow, centralized rebuild.

Trade offs
  • Requires more upfront investment in shared standards than either extreme
  • Federated ownership needs strong cross-division governance discipline to avoid drifting back toward the status quo
Risks
Calculated
  • Divisions reverting to fully independent practices without sustained governance
  • Shared standards becoming a bottleneck if not designed with division input
Assumptions
Assumption
  • Divisions are willing to adopt shared standards in exchange for keeping local ownership
  • Group leadership will sustain governance investment beyond the initial rollout
What could change this recommendation
Fully centralized platform becomes the better fit if divisions prove unable to sustain federated governance discipline over time.
Fully federated (status quo) becomes the better fit if shared standards turn out to slow divisions down more than expected.
Illustrative exampleRisk DecisionsTechnology Strategy

Single hyperscaler versus multi cloud

Stay single hyperscaler, or deliberately introduce a second cloud provider?

Context
Customer input

A pharmaceutical company runs nearly everything on one hyperscaler today. A new regulatory requirement raises the question of whether that concentration is now a liability.

Priorities
Reduce vendor concentration riskAvoid unnecessary operational complexityMaintain negotiating leverageMeet regulatory expectations on resilience
Shortlist
Stay single hyperscaler

Lowest operational complexity, highest concentration risk

Introduce a second cloud for critical workloads onlyRecommended

Targeted risk reduction without full multi-cloud overhead

Full multi-cloud architecture

Lowest concentration risk, highest ongoing operational cost

Recommendation
Calculated
Introduce a second cloud provider, scoped to the specific workloads the new regulation actually concerns

A full multi-cloud architecture would address a risk that, on closer inspection, only applies to a narrow set of regulated workloads. Scoping the second provider to those workloads gets the regulatory benefit without paying for full multi-cloud complexity everywhere.

AI interpretation
Read this as

This addresses the regulatory exposure directly instead of over-rotating into full multi-cloud complexity.

Trade offs
  • Two providers to operate, even if scoped narrowly, adds real operational surface area
  • Negotiating leverage improves only partially versus a full multi-cloud commitment
Risks
Calculated
  • Scope creep if the second provider's use expands without a deliberate decision
  • Skills investment needed for a second cloud provider's operational model
Assumptions
Assumption
  • The regulation's concentration concern is genuinely limited to the workloads identified today
  • The primary hyperscaler relationship stays otherwise stable
What could change this recommendation
Full multi-cloud architecture becomes the better fit if regulatory scope expands well beyond the workloads currently identified.
Stay single hyperscaler becomes the better fit if the regulatory requirement is clarified or narrowed before implementation begins.
Illustrative exampleExecutive PrioritizationAI and Data Decisions

AI use case prioritization

Which AI use cases should be funded first?

Context
Customer input

A telecommunications company has twelve candidate AI use cases proposed across departments, and a budget that realistically covers three to start.

Priorities
Business value if successfulData readiness todayImplementation effortTime to first value
Shortlist
Customer churn predictionRecommended

High value, data already largely ready, moderate effort

Network fault prediction

High value, but data readiness is the weakest of the shortlist

Customer service copilot

Fast time to value, moderate business value

Demand forecasting

High value, high effort, longer time to first result

Recommendation
Calculated
Fund customer churn prediction and customer service copilot first, sequence network fault prediction and demand forecasting behind them

The two funded first both combine real business value with data that's actually ready today, which is what turns a use case into a working result instead of another stalled pilot. The other two are worth doing, but need more groundwork first.

AI interpretation
Read this as

Two working AI results beat four AI pilots that stall for lack of ready data.

Trade offs
  • Network fault prediction has the highest long-term value on this list but is sequenced behind two lower-effort use cases
  • Sequencing means some departments wait longer than they'd like
Risks
Calculated
  • Data readiness for the deferred use cases doesn't improve on its own without a deliberate investment
  • Departments whose use cases are deferred may lose momentum
Assumptions
Assumption
  • Budget realistically supports two to three use cases at a time, not all twelve in parallel
  • Data readiness for churn prediction and the copilot holds up under closer technical review
What could change this recommendation
Network fault prediction becomes the better fit if a parallel data quality investment closes its readiness gap faster than expected.
Demand forecasting becomes the better fit if a near-term business event makes forecasting accuracy urgent rather than merely valuable.
Case Study

Bring your own decision

Every example here runs on the same Donna engine you would use.

Start with Donna