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
- 01
Agreed requirements and decision criteria.
- 02
A technical and operating comparison of the agreed platform list.
- 03
Integration, operating, and ownership cost drivers.
- 04
Assumptions, risks, and dependencies that could change the decision.
- 05
A reasoned recommendation and decision record.
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.
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.
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
-
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.
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.