De vraag die deze module beantwoordt: Hoe teken ik een landschap dat laat zien waar de data heen gaat?
Geef me een nieuw scenario en een leeg whiteboard, en een van de eerste dingen die ik teken is het systeemlandschap. Niet mooi, niet elke API, nog niet het datamodel. Ik wil de enterprise zien: wie de gebruikers zijn, welke systemen erbij betrokken zijn, waar Salesforce staat, wat het omringt, waar data vandaan komt en waar ze heen gaat. En dan wil ik de pijlen doorlopen. Een goed landschap is geen plaatje van vakjes. Het is een manier om architectuurbeslissingen bloot te leggen.
Ik laat CTA-kandidaten dit oefenen. Lees het scenario en begin dan te tekenen. Wacht niet tot je alles in je hoofd opgelost hebt; het tekenen helpt je het op te lossen. Daarom is het huiswerk na dag één het landschap beginnen voordat je je aan het datamodel waagt. Teken eerst het datamodel en je hebt al aangenomen wat er in Salesforce hoort. Teken eerst het landschap en je ziet de systemen die die beslissing zouden moeten vormen.
Begin hoog en zoom dan in: eerst de hele enterprise, dan het detail waar het ertoe doet.
Er zijn veel manieren om een systeemlandschap te tekenen. Dit is gewoon mijn manier, een die ik in de loop van vele jaren verfijnd heb, en ik deel haar zodat je ziet hoe je er snel een in elkaar zet. Ik gebruik haar voor elk Salesforce-landschap, en ze leest als een zin: mensen links bereiken Salesforce in het midden, vertrouwd via de systemen erboven, bediend via de kanalen eronder, en verbonden met de backoffice rechts.
Mensen links, van boven naar beneden: interne gebruikers, partners, klanten. Nog niet elke persona; genoeg om te beantwoorden wie probeert deze architectuur te bereiken? Elke groep wijst naar waar ze binnenkomt: interne gebruikers naar Salesforce, partners naar de partnercommunity, klanten naar de klantcommunity. Systemen bestaan niet op zichzelf. Iemand, of iets, probeert ze te gebruiken.
Stap 2 van 6: wie probeert deze architectuur te bereiken?
Salesforce in het midden. Eén eenvoudig vak. Niet omdat Salesforce het middelpunt van de enterprise is (we hebben net drie modules lang gezegd dat het dat niet is), maar omdat het het systeem is waaromheen ik ontwerp. Het is het anker.
De communities er direct onder, tegen Salesforce aan. Een partnercommunity en een klantcommunity zijn aparte eindpunten, dus ze krijgen hun eigen vakken. Maar ze staan tegen Salesforce aan, omdat er niets geïntegreerd hoeft te worden om ze te bereiken: ze draaien in dezelfde org.
Stap 3 van 6: Salesforce in het midden, de communities er direct onder.
Identiteit erboven. De identiteitsproviders gaan bovenaan, degene die developers vergeten: één voor interne gebruikers, misschien nog een voor partners. AppExchange-pakketten gaan daar ook heen, naar rechts geschoven, omdat dat mogelijkheden zijn die de org binnengehaald worden en geen backofficesystemen die er data mee uitwisselen. Publieke websites staan linksboven.
Stap 4 van 6: identiteit erboven, het vak dat developers vergeten.
Integratie, dan de backoffice, rechts. De integratielaag, een ESB of iPaaS (of MuleSoft, als die genoemd wordt), is een hoge balk net rechts van Salesforce. De interne systemen staan erachter: de ERP’s, finance, orderbeheer, legacysystemen, het datawarehouse. Nu leest de pagina van links naar rechts: mensen, Salesforce, integratie, backoffice.
Kanalen eronder. Alles wat een directe lijn naar klanten heeft: email-to-case, web-to-lead, telefoon, messaging.
Data in en uit, rechtsonder. Externe databronnen, archieven, dataloads.
Data 360 rechts, onder de integratielaag. Gebruikers verbinden er nooit mee, en zijn tenant verbindt met veel backendsystemen, dus het staat bij het leidingwerk, waar die lijnen kort blijven: naast de interne systemen, het datawarehouse en de data rechtsonder. Datateams openen de schermen wel, maar die schermen staan in de org: Data 360 is near-core, beheerd in de core en gehost buiten de core (module 1). Eén lijn terug naar Salesforce laat zien wie het beheert. Waar je het vak zet, moet het verhaal vertellen van wat het doet.
Niets van deze geometrie is heilig. De waarde van een conventie is dat ik niet elke keer de visuele taal opnieuw uitvind, en dat iedereen die een van mijn diagrammen gezien heeft de volgende sneller kan lezen.
Houd de notatie simpel. Elk systeem is een kaart: zijn naam, zijn rol, en een klein icoon dat zegt wat voor ding het is: een ERP, een database, een identiteitsprovider, een groep mensen. De gebieden die ik net beschreef worden als vage, gelabelde zones getekend, zodat de indeling zelf zichtbaar is. Een legenda onderaan zegt wat elk icoon en elke lijn betekent.
Stop niet te veel in een vak. Alleen bij een heel ingewikkeld landschap open ik Salesforce in zijn onderdelen (Sales Cloud en Service Cloud binnen de org, met pijlen ertussen). En verzin geen vijftien vormen tenzij elke vorm de lezer iets vertelt. Ik wil dat iemand dertig seconden naar het landschap kijkt en de architectuur begint te begrijpen. Chique helpt niet. Duidelijk wel.
Wacht niet tot het detailontwerp om over volume na te denken. Een pijl die 500 producten per nacht draagt en een die 200.000 gps-metingen per dag draagt, kunnen er op het landschap precies hetzelfde uitzien. Het is niet hetzelfde probleem. Dus tel wat er beweegt voordat je ook maar één pijl tekent. Begin de inventaris achter de tekening met de aantallen: één rij per belangrijke dataset, met zijn volume. De nullen komen misschien nooit op de pijlen, maar je moet weten wanneer je in hoge getallen terechtkomt: duizenden of miljoenen per uur, honderdduizenden transacties, zelfs tientallen tot honderden transacties per seconde.
Die getallen sturen het mechanisme. Een paar honderd records per nacht is een batch. Een aanroep waar iemand op wacht kan synchroon zijn, als het volume dat toelaat. Tientallen tot honderden per seconde hebben misschien events nodig, zoals platform events, in plaats van een aanroep per record. De pijl ziet er hetzelfde uit; het volume bepaalt wat hem draagt, dus leg het vast in de inventaris, waar het mechanisme gekozen wordt.
Het mechanisme kan zelfs de richting van de pijl veranderen. Stuur een paar records per minuut, en Salesforce kan gewoon naar buiten aanroepen: de pijl begint bij Salesforce. Stuur er veel meer, en Salesforce publiceert misschien events op de eventbus; het externe systeem abonneert zich en roept naar binnen aan om ze op te halen, dus nu begint de pijl aan de andere kant. Nog groter, zeg een nachtelijke synchronisatie van miljoenen records, en het is een batchproces. Ken je aantallen dus vroeg, als je de mechanismen begint te ontwerpen, want de aantallen kunnen de pijlen opnieuw tekenen.
Volume doet ertoe op twee plekken, om twee redenen. Bij een datamodel heb ik het nodig om op grote datavolumes te letten en archivering te plannen; Deel 2 gaat daar diep op in. Bij een systeemlandschap sturen de grote getallen in de inventaris de keuze van integratiepatroon en mechanisme. Module 6 zet echte nullen op het landschap van Steve Trucking en zijn inventaris. Met de aantallen in de hand teken je de pijlen.
Met de systemen op hun plek verbind je ze, en het landschap wordt architectuur. Een vak is een systeem; de pijl laat zien wie de verbinding opent. Hij begint bij het systeem dat de verbinding opent en wijst naar het systeem dat het aanroept: client naar server. Het label zegt wat er beweegt, en in welke richting.
Die regel geldt voor systeemlandschappen, waar systemen met systemen praten. Op een dataflowdiagram volgt de pijl de data, zoals je zou verwachten. Neem de landschapsregel niet mee naar andere diagrammen; dat geeft alleen verwarring.
De pijlen erbij gezet. Elk vak staat waar het stond; elke pijl begint bij het systeem dat de verbinding opent, en zijn label zegt wat er beweegt en in welke richting.
Dus als de integratielaag producten naar Salesforce pusht, loopt de pijl van de integratielaag naar Salesforce, met het label producten in. Als Salesforce naar buiten aanroept om ze op te halen, begint de pijl bij Salesforce, nog steeds met het label producten in. Dezelfde data, een ander gesprek, en dat verschil vertelt me wie de credentials nodig heeft en wie de fout moet afhandelen. Salesforce stuurt de order via de integratielaag: orders uit. De fulfilment van het ERP komt terug: orderstatus in. Nu zie ik wie elk gesprek begint, waar data Salesforce binnenkomt en waar ze vertrekt, welke stromen grenzen oversteken, waar het eigenaarschap waarschijnlijk ligt, en waar ik meer moet vragen.
En onthoud module 1: als ik maar één flow zie, maak ik me zorgen. Op hoog niveau hangt een pijl orders uit af van terugstromen: klanten in, producten in, prijzen. Kijk nog dieper en daar is de terugweg: acceptatie, weigering, status, een factuurnummer, een annulering. De pijlen geven me iets concreets om ter discussie te stellen.
Hier houdt het landschap op PowerPoint-kunst te zijn. Bij de review board kan elke pijl drie vragen oproepen, en ik wil dat je de antwoorden hebt:
Hoe authenticeert hij? OAuth, een certificaat, een named credential, iets anders?
Is hij synchroon of asynchroon? Wacht Salesforce op het ERP, of publiceert het en gaat het verder? Hoe snel heeft het bedrijf het resultaat nodig?
Wat is het mechanisme? Een REST-aanroep, een event, een bestand, een message queue, via MuleSoft of direct?
En dan: wat gebeurt er als de andere kant uitvalt? Elke pijl heeft een mechanisme nodig. Als je het niet kunt uitleggen, is de lijn versiering.
En “fire and forget” is geen antwoord. Meestal betekent het “ik heb niet ontworpen wat er na het afvuren gebeurt.” Is het aangekomen? Is het geaccepteerd? Is het mislukt? Wordt het opnieuw geprobeerd? Wie weet dat het vastzit? Wat als hetzelfde bericht twee keer aankomt? Niets daarvan gaat op het landschap, dat zou onleesbaar worden. Maar de pijl moet je laten weten dat die vragen bestaan.
Zoom in op één pijl en er is een client en een server, en elk is eigenaar van zijn helft. De client opent de verbinding: hij heeft het endpoint en de poort nodig, haalt eerst een token bij de authenticatieserver, roept het protocol en contract aan dat de server definieert, en kiest of hij wacht. Alleen de client ziet de hele heen-en-terugreis, dus alleen de client kan opnieuw proberen. De server luistert, definieert het protocol, het contract en de payload, valideert wat er binnenkomt, en ziet alleen zijn eigen deel. Als ik een pijl teken, weet ik al welk uiteinde welk is, en dat vertelt me wie eigenaar is van elk van deze vragen.
Eén pijl, ingezoomd: de client handelt af, de server definieert. Niets hiervan gaat op het landschap, maar elke pijl heeft het.
Draai de pijl nu om. Als het ERP Salesforce aanroept, is Salesforce de server: het definieert de API’s, draait zijn eigen autorisatieserver, en beslist via een External Client App en een integratiegebruiker wat de aanroeper mag doen. Dezelfde vragen, de andere kant.
Hier verpesten architecten een goed diagram: ze laten één artefact alles beantwoorden. Het landschap krijgt API-namen, payloads, retries, foutwachtrijen, transformaties, elke callback, en al snel kan niemand het lezen. Doe dat niet. Het landschap is het grote plaatje: systemen en de belangrijke stromen ertussen.
Als ik een interactie moet uitleggen, teken ik een tweede diagram, maar niet voor elke integratie. Als systeem A iets naar B stuurt, of zelfs iets vraagt en een antwoord krijgt, is de gelabelde pijl genoeg. Ik wil een swimlane als het proces een gesprek wordt: A roept B aan, B checkt bij C, C antwoordt, B maakt iets aan en roept A terug, een persoon keurt goed, een ander systeem gaat verder. Mijn vuistregel: meer dan één of twee heen-en-weeruitwisselingen, en de volgorde krijgt een eigen swimlane. Pijlen op het landschap; het gesprek in de swimlane.
En let op dat een pijl daar iets anders betekent. Op het landschap is een pijl een verbinding: wie hem opent, en wat er beweegt. In een swimlane is elke pijl één bericht in een gesprek, op volgorde gelezen: een verzoek gaat de ene kant op, een antwoord komt de andere kant terug, en de volgende stap volgt.
Drie pijlen op het landschap; zes stappen in de swimlane. Op het landschap is een pijl een verbinding; in een swimlane is elke pijl één bericht, op volgorde.
Als het landschap er grotendeels klaar uitziet, loop het dan door, pijl voor pijl. ERP naar Salesforce: wat beweegt er, wie is eigenaar, hoe authenticeert het, wat is het mechanisme, synchroon of asynchroon, hoe actueel moet het zijn? Dan de volgende pijl, en de volgende. Hier verschijnen de gaten. “O, we hebben nooit uitgezocht hoe de partner dat eigenlijk stuurt.” “We sturen orders naar het ERP, maar we hebben niet ontworpen hoe geweigerde terugkomen.” Goed. Je vond het op het whiteboard in plaats van in productie.
De tekening moet leesbaar blijven, dus de details gaan in de inventaris erachter. Je bent ermee begonnen met de aantallen; maak hem nu af, één rij per belangrijke dataset of stroom:
Daarom vind ik dit artefact fijn: het helpt me denken. “Hoe gaan we rapporteren over Salesforce en het ERP?” Het is de vraag uit module 3: welk van mijn diagrammen lost dit prachtig op? Het landschap. Als alles in de core staat: standaardrapporten. Als de data in het ERP en het datawarehouse staat, zie je dat meteen. “Waar moet dit klantattribuut beheerd worden?” Kijk welke systemen het gebruiken en welk al eigenaar is van de klant. “Heeft Salesforce elke gps-meting nodig?” Wie maakt haar, wie gebruikt haar, wat is de workload? Misschien heeft Salesforce de huidige positie nodig en bewaart een ander platform de historie. Het landschap geeft je niet het antwoord. Het geeft je de juiste kijk op het probleem.
Teken de huidige situatie voordat je haar repareert
Nog één discipline. Teken in een bestaande enterprise wat er bestaat, niet wat je zou willen dat er bestond. De spreadsheet die elke vrijdag gemaild wordt: teken hem. De CSV van de partner op een SFTP-server: teken hem. De integratie die om historische redenen om de ESB heen gaat: teken haar. Mensen die data tussen twee systemen overtypen: laat het zien. Ruim de werkelijkheid niet op terwijl je haar documenteert. Je hebt het huidige landschap nodig voordat je het doellandschap ontwerpt, en dat doen we voor Steve Trucking in module 6.
Voorbij het examen: wat AI verandert. Het landschap wordt een agentkaart. Als een agent “waar blijft mijn levering?” beantwoordt, moet het landschap zeggen of het antwoord uit Salesforce komt, uit een partnersysteem, telematica, het ERP, of een mix. Agents halen systeemgrenzen niet weg; ze maken het nog belangrijker om te weten welk systeem gezaghebbend is en hoe je het veilig bereikt.
Welke systemen en gebruikersgroepen op het landschap horen, en hoe hun plaats hun rol laat zien.
Welke stromen systeemgrenzen oversteken, in welke richting, en wat er terugkomt.
Hoe elke verbinding authenticeert, welk mechanisme haar draagt, en of ze synchroon, asynchroon, batch of gefedereerd is.
Wanneer een gelabelde pijl genoeg is en wanneer een interactie een eigen swimlane nodig heeft.
Wat de inventaris achter de tekening vastlegt: eigenaar, workload, volume, org, timing, authenticatie, en kopiëren, verwijzen of federeren.
Het landschap is niet iets wat ik teken nadat de architectuur klaar is. Het is hoe ik de architectuur vind. En als je denkt dat het af is, bewonder het dan niet. Loop het door. Elke pijl die je nog niet kunt uitleggen, laat je zien waar het werk zit.
