Skip to main content
Adrià García
Menu
← All services

Service

Platform selection

I compare requirements with real capabilities and expose the integration, operating, and ownership trade-offs before recommending an option.

What is included

  1. 01

    Agreed requirements and decision criteria.

  2. 02

    A technical and operating comparison of the agreed platform list.

  3. 03

    Integration, operating, and ownership cost drivers.

  4. 04

    Assumptions, risks, and dependencies that could change the decision.

  5. 05

    A reasoned recommendation and decision record.

The warehouse is becoming the source of truth, and every family is building its bridge to it. The question is no longer whether you connect, but on what contract.

Market convergence diagram. At the center, the warehouse as source of truth, with Snowflake, BigQuery, Databricks and Fabric. From above, the suites connect, each through its own bridge: Adobe through Federated Audience Composition, Salesforce through its zero-copy partner network, Oracle through Fusion Unity and APIs, and SAP through Business Data Cloud. From below, the agile architectures connect: Tealium through CloudStream, HubSpot through connectors, and composable through reverse ETL. Every route ends at the same warehouse.

There is no universally best stack. There are questions that order the decision, and the order matters more than the answer to any one of them.

Decision tree for choosing an architecture. The first question is whether there is enterprise budget and more than twelve months. If the answer is yes, the next question is whether millions of profiles need unifying across legacy systems: if that is also yes, the answer is an integrated suite; if it is no, an engagement-centric architecture, which suits an owned channel and short cycles. If the first answer is no, the question becomes whether the warehouse is already the source of truth: if it is, the answer is warehouse-native, with an in-house data team; if it is not, composable, which demands engineering in house.

The same question asked of all four. What changes shows up reading down a column, not across a row.

Comparison of the four customer data architecture archetypes, with the same four questions asked of each: where data is captured, where the profile lives, where segmentation and decisions happen, and how activation works. First row, integrated suite: capture through SDKs and connectors from web, app and batch; the profile lives in the suite itself, in real time; audiences and decisions are resolved inside the platform; activation goes out through a destination catalog covering edge, streaming and file. Second row, engagement-centric: capture through SDK and API plus warehouse loads; the user profile lives inside the tool; segments and orchestration belong to the channel; activation is the owned channels, push, email and in-app. Third row, warehouse-native: capture is scheduled loads into the warehouse; the warehouse is the source of truth; compute happens in place and identity has to be brought in separately; activation is reverse ETL to each tool. Fourth row, composable: identical to the previous one in capture, warehouse and activation, differing only in that pieces are assembled rather than computing in place, with identity also separate. The last two rows look alike because they share almost everything.

Related experience and reasoning

  1. Built 2024–2025

    AEP architecture across several business lines

    XDM model, identities, Web SDK, and offer decisioning for separate business lines on one instance. The first line is never the problem. The problem is keeping the second one from forcing a rewrite of the first.

    • XDM
    • Identities
    • Web SDK
    • Decisioning

Frequently asked questions

Can you be neutral if you mostly work with Adobe?

That is the right question to ask. I have implemented on Adobe and on Tealium, and that experience is exactly what makes it possible to estimate the real cost of each option instead of just reading the vendor site. The recommendation comes with the criteria, assumptions, and risks in writing, so you can argue with it.

What if the conclusion is not to change platform?

That is a valid outcome and it happens. Sometimes the problem is not the product but the data model, identity, or who operates it. Changing platform with those unresolved just moves them somewhere else and adds a migration on top.

Does it help if we already started an RFP?

Yes, and that is often when it helps most. With the proposals on the table you can compare what each one promises against what it costs to operate, which is where the decision really happens. The briefing tool on this site prepares those questions.

How do I defend the recommendation internally?

The deliverable includes the decision record: what was compared, against which criteria, which assumptions were taken, and which risks stay open. It is meant to be taken to a steering committee, not to sit in your folder.

Free tool

Prepare the questions for your next demo

Select the vendor claims and generate a briefing that tests them through data, evidence, and specific ownership.

Prepare the briefing →

Does this fit your problem?

Send me the context and I will tell you whether this scope fits or a different starting point makes more sense.

Discuss the scope