Waarom Een Gedeelde Datalaag Wint Van Point-To-Point-Integraties

Elk revenue-team stuit uiteindelijk op dezelfde splitsing. Een nieuwe tool heeft data nodig van een bestaande. Zeg dat het sales-engagementplatform accounttiers nodig heeft van het CRM. Het snelle antwoord is een directe sync: verbind de twee, map een paar velden, lever het op. Het snelle antwoord is ook hoe stacks onbeheersbaar worden. Tegen de tijd dat u een dozijn tools heeft, heeft de reflex van "verbind ze gewoon" een kluwen point-to-point-integraties opgeleverd die niemand volledig begrijpt en niemand wil aanraken.

Het alternatief is een gedeelde datalaag waar elk systeem uit leest en naar schrijft, in plaats van tools rechtstreeks met elkaar te bedraden. Het is een van de dragende beslissingen in de referentiearchitectuur voor een modern revenue-platform, en de moeite waard om op zichzelf te begrijpen omdat de afweging niet vanzelfsprekend is totdat het aantal integraties groot wordt.

De wiskunde wordt snel lelijk

Point-to-point schaalt slecht om een puur combinatorische reden. Met n systemen is het aantal mogelijke directe verbindingen n(n-1)/2. Drie tools hebben tot drie integraties nodig, wat niets is. Tien tools hebben tot vijfenveertig nodig. En elke integratie is geen pijpleiding. Het is een set veldmappings, een syncschema, een transformatie, en een faalmodus. Vermenigvuldig dat met vijfenveertig en u heeft een onderhoudsoppervlak dat geen enkel team schoon houdt.

Een gedeelde laag verandert de wiskunde. Elk systeem integreert eenmalig, met de hub, dus n systemen hebben n verbindingen nodig. Groei gaat van kwadratisch naar lineair. Belangrijker nog: de semantiek leeft op één plek. In plaats van vijfenveertig licht verschillende meningen over wat "MQL" of "actieve opportunity" betekent, is er één canonieke definitie die elke tool erft.

De initiële bouw van een directe sync is echt snel. De verborgen kost is de veranderkost. Wanneer het CRM een veld hernoemt, breken de drie of vier integraties die het aanraken stilzwijgend, en u komt erachter door een verkeerd getal in een bordpresentatie. We hebben in die meeting gezeten. Het is niet leuk.

Wat "gedeelde datalaag" eigenlijk betekent

Een gedeelde datalaag is meer dan een database die iedereen kan bevragen. Drie eigenschappen scheiden het van een gedeelde stortplaats.

Canonieke entiteiten. Accounts, contacten, opportunities en revenue-events worden opgelost en gededupliceerd tot enkele records met stabiele identifiers. Entiteitsresolutie gebeurt hier, eenmalig, in plaats van opnieuw geïmplementeerd te worden in elke tool. Het hangt volledig af van schone inputs, en daarom is RevOps-datahygiëne een voorwaarde en geen bijzaak.

Een expliciet schema. Elk consumerend systeem leest tegen een gedocumenteerd, geversioneerd schema. Wanneer het schema verandert, worden consumenten daarvan op de hoogte gesteld. Ze ontdekken het niet in productie.

Bidirectionele stroom. De laag is niet alleen-lezen. Centraal berekende inzichten worden teruggeschreven naar actiesystemen via een gedisciplineerde terugschrijflaag, zodat de hub in beide richtingen de bron van waarheid is.

Zonder deze drie heeft u een datalake dat toevallig in het midden zit, en dat reproduceert de point-to-point-puinhoop met extra stappen.

Hoe dat eruitziet in één scenario

Een mid-market SaaS-bedrijf draait een CRM, een marketingautomatiseringsplatform, een productanalysetool, een facturatiesysteem en een datawarehouse. Het team wil leadscoring die marketingengagement, productgebruik en accountfirmografie combineert.

Point-to-point: marketingautomatisering synct naar het CRM. Productanalytics synct naar marketingautomatisering voor engagementscoring. Facturatie synct naar het CRM voor renewal-vlaggen. Het warehouse haalt op afzonderlijke schema's uit alle drie. De leadscore wordt berekend in marketingautomatisering vanuit een gedeeltelijk beeld, en vervolgens overschreven door een andere score berekend in het CRM. Er bestaan twee scores, ze zijn het oneens, en reps stoppen binnen een maand met beide vertrouwen.

Gedeelde laag: alle vier systemen voeden de hub. Entiteitsresolutie naait het productaccount, het facturatie-account en het CRM-account aaneen tot één canoniek account. De score wordt eenmalig berekend, op het complete beeld, en identiek teruggeschreven naar het CRM en het marketingplatform. Eén score, en die is uitlegbaar omdat elke input op één plek zit.

De tweede opzet is de enige waarin iemand de score kan vertrouwen, omdat vertrouwen in een metric afhangt van één enkele lineage erachter.

Wanneer point-to-point prima is

Architectuuradvies zonder uitzonderingen is ideologie. Directe integratie is de juiste keuze wanneer u twee of drie stabiele systemen heeft en geen plan om er meer toe te voegen, wanneer de stroom eenrichtingsverkeer en simpel is (een webhook die formulierinzendingen naar het CRM post, bijvoorbeeld), of wanneer u prototypt en van plan bent de verbinding weg te gooien.

Point-to-point als standaard is het probleem, omdat dat is hoe het de architectuur wordt. Een vuistregel die wij graag gebruiken: het moment waarop een derde systeem data nodig heeft die twee anderen al delen, betaalt een hub zichzelf terug. Voorbij dat punt wordt het bepalen hoe vers elke stroom moet zijn, het onderwerp van Real-Time vs. Batch: Wanneer Versheid Van Revenue-Data Ertoe Doet, een keuze per stroom die de hub u toestaat bewust te maken in plaats van per ongeluk.

De kluwen ontwarren

Als u de kluwen al heeft, rukt u die niet in één nacht eruit. Het pad dat werkt:

1. Inventariseer elke bestaande integratie en de velden die hij aanraakt. De meeste teams vinden er meer dan verwacht, soms veel meer.
2. Zet de gedeelde laag op en verbind eerst het systeem van record met de hoogste waarde. Meestal is dat het CRM.
3. Leid één stroom tegelijk om via de hub, en pensioneer de directe link pas nadat de hub-versie is gevalideerd.
4. Bevries nieuwe point-to-point-links via beleid, zodat de kluwen stopt te groeien terwijl u hem ontwart.

Het is dezelfde stapsgewijze discipline die migreren weg van spreadsheets overleefbaar maakt. Verander de leidingen zonder het water af te sluiten.

Belangrijkste inzichten

• Directe integraties groeien met het kwadraat van uw aantal tools. Een hub groeit met het aantal tools. Het verschil wordt zichtbaar rond de tiende tool.
• De syncs zijn goedkoop om te bouwen. Het dure deel is elke veldnaamwijziging die stilzwijgend drie ervan breekt.
• Een echte gedeelde laag lost entiteiten eenmalig op, publiceert een geversioneerd schema, en schrijft terug. Een warehouse in het midden is niet hetzelfde.
• Twee of drie simpele, stabiele verbindingen zijn prima als directe syncs. Het probleem is wanneer directe sync de standaard is.
• Migreer één stroom tegelijk en bevries nieuwe directe links terwijl u dat doet.

Een gedeelde datalaag is het verschil tussen een stack die tegen u vecht en een die zich opstapelt, en het is het fundament dat een revenue-orchestratieplatform als Revnewo gebouwd is om te bieden. Als uw aantal integraties blijft stijgen, loont het de moeite in kaart te brengen welke links een hub als eerste zou samenvoegen.