Lees hier meer over onze updateschema's.

Opzettelijke oplossingen leveren onmiddellijk en in de loop van de tijd bedrijfswaarde op. Opzettelijke architecturen worden strategisch gepland en geleverd, kunnen effectief worden onderhouden en zijn gemakkelijk te lezen en begrijpen voor mensen.

Voorzieningen en oplossingen krijgen prioriteit en worden geleverd op manieren die transparant zijn voor zowel zakelijke als technologische belanghebbenden. Met engineeringkeuzes worden implementaties gemaakt waarmee leverings- en onderhoudsteams gemakkelijk kunnen werken, zonder extra voorzieningen of complicaties. Opzettelijke architecturen zijn gemakkelijker in eigendom, onderhoud en ontwikkeling met het bedrijf, omdat ze duidelijke en consistente implementatiepatronen volgen. Samenstellers kunnen ontwerpen voor nieuwe voorzieningen interpreteren en implementeren, en onderhoudsteams kunnen documentatie begrijpen van wat er is geïmplementeerd.

U kunt meer intentionele systemen maken door u te richten op drie belangrijke gebieden: strategie, onderhoudbaarheid en leesbaarheid.

Strategie in de architectuur betekent dat systemen zorgvuldig worden gepland en geleverd. Het betekent dat leverings- en onderhoudsteams een duidelijk zicht hebben op het werk dat vandaag en in de toekomst moet worden uitgevoerd, en dat iedereen het eens is over het “waarom” van het uit te voeren werk. Dit betekent dat urgente verzoeken effectief en efficiënt kunnen worden beoordeeld en dat belanghebbenden duidelijk de gevolgen en nadelen van verzoeken kunnen begrijpen.

U kunt een duidelijkere strategie in uw architectuur inbouwen door u te richten op prioritering, roadmapping en governance.

Prioriteren betekent het plannen van de volgorde en omvang van het werk dat u gaat leveren. Prioritering omvat inzicht in de werkelijke impact van deliverables op het bedrijf, het evalueren van die impact ten opzichte van andere werkverzoeken en de algemene roadmap voor uw product of programma.

Eén manier om de impact van een bepaald werkitem te evalueren is te kijken naar de feitelijke kosten of baten voor het bedrijf. Zodra u de KPI's voor de automatisering hebt geïdentificeerd, kunt u een werkblad voor bedrijfsimpactberekening gebruiken om de algemene kosten of baten van implementatie te evalueren. Deze berekeningen kunnen u helpen om uw belanghebbenden te overtuigen van welke automatiseringen u moet samenstellen en in welke volgorde. Ze kunnen u ook helpen bij het identificeren van automatiseringen die u wilt uitstellen of vermijden. Zie voor automatiseringen Procesontwerp voor meer informatie over het identificeren van effectief werk.

Het opstellen van een prioriteringsframework voor levering helpt u en uw onderhoudsteams ook om de verwachtingen van gebruikers te beheren en op één lijn te blijven met uw roadmap.

Enkele overwegingen die u kunt gebruiken voor prioritering zijn:

• Bedrijfsimpact (kosten/baten) van het te leveren product
• Hoeveelheid nieuw werk die vereist is voor het te leveren product
• Hoeveelheid werk die nodig is voor het onderhoud van het te leveren product

De onderstaande lijst met patronen en antipatronen toont hoe de juiste (en slechte) prioritering eruitziet als het gaat om Salesforce-werk. U kunt deze gebruiken om uw implementatieplannen te valideren of om te bepalen waar u prioriteiten beter moet identificeren voordat u gaat samenstellen.

Zie Tools Relevant to Intentional voor meer informatie over tools die beschikbaar zijn vanuit Salesforce voor hulp bij prioritering.

Een roadmap is een geprioriteerde, gevalideerde, goed gedefinieerde weergave van wat er moet worden gedaan. Effectieve roadmaps bieden een duidelijk beeld van de impact van het werk op het bedrijf en de technologie. Het betrekken van uw zakelijke en technische belanghebbenden is een belangrijk onderdeel van roadmapping. Stappenplannen stellen u in staat om feedback te krijgen over de aanpak en uitkomsten voordat er werk begint. Uiteindelijk stemmen roadmaps elke belanghebbende af op het “waarom” van het werk dat voor ons ligt.

Als uw team een achterstand gebruikt, is het belangrijk om te begrijpen dat uw routekaart geen samenvatting of lijst is van de items met een achterstand. De relatie is het tegenovergestelde: Items komen alleen in de achterstand als ze duidelijk en geloofwaardig kunnen worden gekoppeld aan een te leveren product op uw roadmap. Stappenplannen van hoge kwaliteit, gemaakt met betrokkenheid van belanghebbenden, bieden leverings- en onderhoudsteams een duidelijk zicht op waarop ze zich moeten richten en hoe ze verzoeken moeten prioriteren, waardoor het gemakkelijker wordt om conflicterende verzoeken op te lossen en verwachtingen van belanghebbenden te beheren.

Slechte of niet-bestaande roadmapping leidt tot:

• Onduidelijkheid over wanneer nieuwe voorzieningen en functionaliteit beschikbaar komen
• Conflicterende prioriteiten bij belanghebbenden
• Een loskoppeling tussen de oplossingen die worden geleverd en de algemene organisatievisie
• Moeite met begrijpen wat er aan de hand is
• Ongelijke werkbelasting binnen teams
• Gebrek aan inzicht in relaties en afhankelijkheden tussen werkitems
• Vastgelopen implementaties vanwege verkeerd beheerde afhankelijkheden

Belanghebbenden hebben vaak informatie nodig die overeenkomt met hun rol om beslissingen te kunnen nemen. Het maken van effectieve roadmaps vereist een duidelijk inzicht in uw doelgroep en het type informatie dat ze nodig hebben. Routekaarten worden gecategoriseerd in twee stijlen om zakelijke en technische doelgroepen te ondersteunen. Elke stijl bevat twee niveaus van fijnkorreligheid om verschillende typen informatie te ondersteunen.

Bedrijfsroadmaps helpen belanghebbenden bij het plannen van organisatorische veranderingen, het benutten van groeimogelijkheden en het op één lijn houden van bedrijfsdoelstellingen. Bedrijfsroadmaps bieden ook een manier om ervoor te zorgen dat IT-uitgaven overeenkomen met de algemene bedrijfsvisie.

• Maak een roadmap voor bedrijfscapaciteiten om leidinggevende belanghebbenden de mogelijkheden te tonen die worden ingeschakeld. Dit type roadmap bevat details op hoog niveau over de mogelijkheden zelf en hoe deze overeenkomen met bedrijfsdoelstellingen, zoals het verhogen van de operationele efficiëntie of het lanceren van een nieuwe productlijn.
• Maak een stappenplan voor bedrijfsvoorzieningen om door te klikken naar een specifieke mogelijkheid en de ondersteunende voorzieningen en functionaliteit ervan te tonen wanneer u zakelijke belanghebbenden wilt helpen met resourceplanning, budgettering en veranderingsbeheer.

Technologiestappenplannen helpen technische belanghebbenden bij het plannen van budgetten en resourcetoewijzingen. Ze helpen implementatieteams ook begrijpen waar hun projecten passen als onderdeel van een groter totaalbeeld en eventuele teamafhankelijkheden identificeren.

• Maak een roadmap voor technologiesystemen om de specifieke systemen te tonen die zullen worden geïmplementeerd, samen met eventuele afhankelijkheden op systeemniveau. Dit type roadmap toont systeeminformatie op hoog niveau en de afstemming tussen systemen en bedrijfsmogelijkheden.
• Maak een roadmap voor technologiecomponenten om door te klikken naar de specifieke componenten van een systeem dat wordt geïmplementeerd om te helpen bij resourceplanning en enablement-vereisten. Dit type roadmap toont informatie op componentniveau en implementatievereisten (bijvoorbeeld declaratieve ontwikkeling, pro-code, enzovoort).

Zorg ervoor dat uw roadmaps realistische tijdlijnen bevatten. Een veel voorkomende fout is om alleen de hoeveelheid tijd op te nemen die nodig is om een systeem te implementeren, zonder ook rekening te houden met de hoeveelheid tijd die nodig is om gerelateerde activiteiten te voltooien. Dit kan leiden tot een overmatige toewijzing van implementatieteamleden en langer dan verwacht. Houd bij het maken van een roadmap rekening met de tijd die nodig is om het volgende te voltooien:

• Documentatie van alle nieuwe en bijgewerkte functionaliteit
• Onderhoud van bestaande functionaliteit die nodig is voor de ondersteuning van nieuwe voorzieningen
• Updates van gerelateerde systemen vereist voor ondersteuning van integraties
• Verhoogde ondersteuning van projectteams onmiddellijk na livegang
• Testen, training en veranderingsbeheer

Roadmaps voor bedrijf en technologie die goed op elkaar zijn afgestemd, bieden een holistische weergave van wanneer mogelijkheden live gaan en welke technologie erachter zit. De onderstaande lijst met patronen en antipatronen toont hoe goede (en slechte) roadmaps eruitzien voor een Salesforce-organisatie. U kunt deze gebruiken om uw roadmapstrategie te valideren of te verbeteren.

Zie Tools Relevant voor Intentional voor meer informatie over Salesforce-tools die u kunnen helpen bij roadmapping.

Governance is de structuur die u gebruikt voor het afhandelen van prioritering, besluitvorming en veranderingsbeheer met uw belanghebbenden. Governance maakt duidelijk hoe beslissingen worden genomen en gecommuniceerd. Het biedt consistente manieren voor feedback en verzoeken om deel te nemen aan het besluitvormingsproces, en voor alle belanghebbenden om de status van onderhouds- en ontwikkelingswerk te begrijpen. Governance zorgt ervoor dat beheerprocessen voor releases helder en consistent zijn en helpt alle teamleden hun rollen en verantwoordelijkheden te begrijpen.

Zonder goed bestuur zullen teams verschillende problemen ervaren, waaronder:

• Verzoeken om overlappende voorzieningen en functionaliteit komen ad hoc binnen
• Implementatieteams prioriteren "gemakkelijkere" inspanningen of verzoeken van meer invloedrijke belanghebbenden, zonder de juiste aandacht voor bedrijfswaarde, nadelen of algemene organisatorische doelen
• Gebrek aan consistente goedkeurings- en beoordelingsprocessen
• Inconsistente releasecadansen en kwaliteit
• Hoge defectpercentages, overschrijvingen, conflicten en redundant werk bij ontwikkelingsinspanningen

Het duidelijkste teken dat een systeem geen effectief bestuur heeft, is wellicht langzame en omslachtige releases. Het is belangrijk om te erkennen dat de omvang van een governancesysteem geen meeteenheid is voor de effectiviteit ervan. Uitgebreide governancesystemen (zoals die in veel grote ondernemingen voorkomen) kunnen de snelheid en frequentie van releases zelfs vertragen.

Goed bestuur gaat over het moeilijk maken voor slechte aanpassingen om door de vroege ontwikkelingsfasen te komen, en het voorspelbaar en consistent in productie krijgen van goede aanpassingen.

Te vaak zijn governance-inspanningen reactionair. Ze worden geïnitieerd of verdubbeld wanneer een probleem, zoals een buitensporige technische schuld, een bedrijfsprobleem begint te worden. In veel gevallen is de ongelukkige reactie dat het bedrijf ontwikkelingsinspanningen en releases “vastzet”, in plaats van effectieve ontwerpstandaarden te maken en automatisering te bouwen om die standaarden af te dwingen binnen ontwikkelaarstoolketens en bronregelingssystemen.

Neem bij het samenstellen van het framework voor uw Salesforce-governancesysteem de volgende elementen op en overweeg deze belangrijke vragen te beantwoorden:

• Werkverzoeken. Hoe kunnen gebruikers om functionaliteit of voorzieningen vragen? Hoe worden bugs gemeld?
• Priorisatie en werkplanning. Wie bepaalt welke werkverzoeken ertoe doen? Hoe wordt het bereik van werk bepaald, geprioriteerd en geaccepteerd of ondertekend?
• Omgevingen en releaseplanning. Wat is de milieupijplijn voor ontwikkelen, testen en vrijgeven? Wie doet wat om te leveren, vernieuwen en toegang te verlenen? Wie zorgt voor implementaties en validatie? Hoe en wanneer worden wijzigingen vrijgegeven? Hoe gaat u om met implementaties of omgevingen tijdens een Salesforce-releasecyclus? (Zie Levenscyclusbeheer van toepassingen voor meer informatie hierover.)
• Service-eigendom en productieondersteuning. Wie ondersteunt wat? Wie behandelt "hot-fix" productieproblemen? Hoe worden die items getest en vrijgegeven? Wie is verantwoordelijk voor de algemene beveiligingsnormen van de organisatie?

De onderstaande lijst met patronen en antipatronen toont hoe goed (en slecht) bestuur eruitziet voor een Salesforce-organisatie. U kunt deze gebruiken om uw governance-strategie te valideren of te verbeteren.

Zie Tools Relevant voor Intentional voor meer informatie over Salesforce-tools die beschikbaar zijn voor governance.

De volgende tabel toont een selectie van patronen die u in uw organisatie kunt zoeken (of samenstellen) en antipatronen die u kunt vermijden of die u kunt gebruiken voor herstel.

✨ Ontdek meer patronen voor strategie in de Patroon & Anti-Patroon Explorer.

Onderhoudbaarheid betekent dat een systeem in een gezonde staat kan worden gehouden, met nieuwe voorzieningen die op regelmatige, voorspelbare basis naar het systeem worden verplaatst en technische schulden die uit het systeem worden verwijderd. Onderhoudbare systemen stellen uw teams in staat om waarde te leveren aan het bedrijf met voorspelbare snelheid en kwaliteit. De onderhoudbaarheid van een systeem is afhankelijk van verschillende factoren, waaronder hoe leesbaar het is, hoe losjes het is gekoppeld en hoe grondig de teststrategie ervan is.

Het belangrijkste is dat de onderhoudbaarheid van een systeem afhankelijk is van de rechtlijnigheid van het ontwerp. Deze sectie behandelt manieren om eenvoudigere oplossingsontwerpen te maken en de onderhoudbaarheid te vergroten.

U kunt eenvoudiger te onderhouden oplossingen samenstellen door u te richten op twee sleutels: het gebruik van standaard over aangepaste functionaliteit en het afhandelen van technische schulden.

Salesforce biedt een reeks vooraf samengestelde oplossingen — Sales Cloud, Service Cloud en vele Salesforce-brancheoplossingen — en de flexibiliteit om uw eigen aangepaste oplossingen te maken. De basisservices die de eigen cloudoplossingen van Salesforce aansturen, zijn ook beschikbaar voor aangepaste oplossingen die zijn gebouwd op het Salesforce Customer 360 Platform. Gebruik de vooraf samengestelde services en oplossingen van Salesforce als een vertrouwde basis voor zoveel mogelijk van uw oplossingen.

Het gebruik van vooraf samengestelde platformservices heeft twee duidelijke voordelen. Ten eerste profiteren uw apps bij elke release natuurlijk van de nieuwste Salesforce-innovaties. En ten tweede kunnen uw ontwikkelteams zich richten op het uitbreiden en verdiepen van de zakelijke mogelijkheden die uw Salesforce-oplossingen bieden, in plaats van het afhandelen van basaal architectonisch zwaar werk.

Goed kiezen wanneer standaardfunctionaliteit wordt gebruikt en wanneer aangepaste functionaliteit wordt samengesteld, is vanuit architecturaal oogpunt geen uitdaging. De sleutels zijn:

• Aanpassen van het platform betekent wijzigen en uitbreiden, niet kopiëren. Terwijl u uw architectuur ontwerpt of evalueert, moet u het volgende vragen: Bestaat dit al ergens in het Salesforce-platform? Als het antwoord luidt "Ja, maar...[voeg hier wijzigingen in die een zakelijke belanghebbende wenst...]", gebruikt u de vooraf samengestelde voorziening in het platform. Het architectonische werk dat moet worden uitgevoerd, is het identificeren van de nuttigste manieren om de vooraf samengestelde Salesforce-voorziening te configureren om te voldoen aan zakelijke verwachtingen.
• Geen aanpassingen zijn triviaal. Na verloop van tijd heeft elke wijziging gevolgen. Als u een aangepaste oplossing moet implementeren, kunt u de onvermijdelijke technische schulden die uw systeem zal opbouwen, verminderen door ervoor te kiezen om waar mogelijk low-code technologie te gebruiken en door samenstelbare eenheden in uw implementaties te maken.
• Denk aan het bouw-koopspectrum. De Salesforce AppExchange is een marktplaats van apps en oplossingen om Salesforce uit te breiden. AppExchange apps kunnen functionaliteit leveren zonder de overhead die nodig is voor het samenstellen en onderhouden van een aangepaste oplossing. Denk aan het volgende bij het evalueren van AppExchange oplossingen:
  • Identificeer oplossingsvoorzieningen en hiaten. Idealiter vindt u een app die aan al uw bedrijfsvereisten voldoet. In werkelijkheid vindt u mogelijk niet de perfecte pasvorm. Terwijl u oplossingen beoordeelt, wijst u functionaliteit in de potentiële oplossing toe aan een geprioriteerde lijst van bedrijfsvereisten. Zo vindt u de oplossing die het beste voldoet aan uw meest kritieke vereisten.
  • Gebruik sandboxen en gratis proefversies. Gebruik gratis proefperioden om apps in sandboxomgevingen te evalueren en de beste oplossing te vinden. Bepaal of apps vereisen dat u configuratiewijzigingen aanbrengt die conflicteren met uw bestaande configuratie.
  • Denk aan kosten op korte en lange termijn. Evalueer besparingen op het onderhoud van apps op de lange termijn in vergelijking met de terugkerende kosten van op abonnementen gebaseerde apps. Vermijd scenario's waarin u terugkerende kosten moet betalen voor veel functionaliteit die uw zakelijke belanghebbenden nooit zullen gebruiken.
• Gebruik de vooraf samengestelde gegevensmodellen van Salesforce. Salesforce biedt vooraf samengestelde gegevensmodellen voor Sales, Service en een verscheidenheid aan verticale sectoren. Het gebruik van de gegevensmodellen van Salesforce zorgt ervoor dat mogelijkheden in uw systeem slechts één maal worden gedefinieerd (redundantie en silo's worden geëlimineerd), zorgt voor één waarheidsbron voor het hele systeem, maakt het inzichtelijker in toepassingsgegevens met analyses, maakt het gebruik van vooraf samengestelde kunstmatige intelligentieservices van Salesforce gemakkelijker, verlaagt onderhoudskosten (door aanpassingen te verminderen die u moet ondersteunen) en vermindert technische schulden.

Zo simpel is het. Zoals u kunt zien in de onderstaande patronen en antipatronen, komen de antipatronen neer op het repliceren van standaardvoorzieningen in een aangepaste oplossing of het gebruik van complexere technologie om aanpassingen te leveren.

In de praktijk kunt u te maken krijgen met een scenario waarin een antipatroon voor aangepaste functionaliteit door zakelijke belanghebbenden wordt beschouwd als de beste of enige haalbare weg vooruit. In deze gevallen is het essentieel dat u de belanghebbenden uitlegt welke nadelen er zijn verbonden aan het kiezen van dit traject en vervolgens de beslissing, de motivering en de implementatie ervan grondig documenteert. Dit is ook een gebied waar het leveren van kernwaarde in een vroeg stadium en het aanpassen ervan in de loop van de tijd uw belanghebbenden kan helpen beter te begrijpen wat de beste manier van handelen is.

Zie Tools Relevant voor Intentional voor meer informatie over Salesforce-tools die u kunnen helpen de onderhoudbaarheid te vergroten.

Technische schuld is een natuurlijk onderdeel van elk systeem. De geluidsontwerpen van gisteren kunnen antipatronen worden wanneer technologie of bedrijfsbehoeften veranderen. Misschien wordt iets dat is samengesteld om een hiaat in de functionaliteit van het Salesforce-platform op te vullen, plotseling overbodig met een nieuwe Salesforce-release of productlancering. Misschien vervangt een meer performante of flexibele technologie een technologie die u al hebt geïmplementeerd. Technische schuld kan op vele manieren worden gemaakt.

Een belangrijk voordeel van het samenstellen van toepassingen met het Salesforce Customer 360 Platform is de achterwaartse compatibiliteit die in het platform is ingebouwd. Dit betekent dat nieuwe platforminnovaties het patroon kunnen veranderen dat u moet gebruiken voor oplossingen in de toekomst, maar dat de dagelijkse functie van oplossingen die u hebt samengesteld op basis van eerdere Salesforce-technologieën, blijft werken. In de loop van de tijd zal elke oplossing op basis van oudere technologie risico's of bottlenecks gaan opleveren voor het toevoegen van nieuwe voorzieningen aan uw apps en de algehele gezondheid van oplossingen verminderen.

Het plannen en uitvoeren van regelmatig werk om technische schulden aan te pakken is essentieel voor het behoud van gezonde, duidelijke ontwerpen in een Salesforce-oplossing. Het niet plannen, controleren en verhelpen van technische schulden is een veilige manier om een systeem te creëren dat slecht is ontworpen.

Eén manier om technische schulden te minimaliseren, is het zo veel mogelijk vermijden, door sneltoetsen te vermijden en door de voorkeur te geven aan standaardfunctionaliteit boven aangepaste functionaliteit. Shortcuts, zoals hard-coding waarden, kunnen verleidelijk zijn om tijd te besparen, maar op de lange termijn creëren ze schulden die moeten worden terugbetaald.

De sleutels voor het aanpakken van technische schulden vanuit een architectonisch perspectief omvatten:

• De feitelijke kosten of baten van actie versus niet-actie bepalen
• Goede roadmapping
• Samenstelbare oplossingen bouwen

De moeilijkheid kan zijn belanghebbenden op één lijn te krijgen met het ondernemen van actie. Sommige belanghebbenden ervaren doorlopend onderhoud mogelijk als het aanpakken van "fouten van gisteren" of het wegnemen van de voorzieningen die ze met hun budget willen ondersteunen.

Het tonen van de werkelijke zakelijke impact van actie en inactiviteit, in combinatie met duidelijk gedefinieerde deliverables en tijdlijnen, kan uw belanghebbenden helpen de waarde en relatieve prioriteit te begrijpen van het aanpakken van technische schulden. Het consistent uitvoeren van het werk om technische schulden te koppelen aan bedrijfsimpact zal uw belanghebbenden niet alleen helpen om beter te begrijpen welk werk er moet worden uitgevoerd. Het zal u ook helpen ervoor te zorgen dat u technische schulden identificeert en aanpakt op manieren die gebruikers echt ten goede komen.

De onderstaande lijst met patronen en antipatronen toont hoe goed (en slecht) technisch schuldbeheer eruitziet voor een Salesforce-organisatie.

Zie Tools Relevant voor Opzettelijk voor meer informatie over Salesforce-tools die u kunnen helpen met technische schulden.

De volgende tabel toont een selectie van patronen die u in uw organisatie kunt zoeken (of samenstellen) en antipatronen die u kunt vermijden of die u kunt gebruiken voor herstel.

✨ Ontdek meer patronen voor onderhoudbaarheid in de Patroon & Anti-patroon Explorer.

In de kern gaat het concept van leesbaarheid over het creëren van consistentie die het voor mensen gemakkelijk maakt om te begrijpen hoe dingen werken. Het samenstellen van leesbare systemen brengt leverings- en onderhoudsteams op één lijn en helpt mensen die niet vertrouwd zijn met het systeem snel te begrijpen hoe onderdelen in elkaar passen. Het betekent dat uw team minder afhankelijk kan zijn van individuele mensen met institutionele of historische Knowledge om leveranciers of nieuwe teamleden effectief te onboarden. Dit betekent dat ervaren personen in een team zich kunnen richten op de kwaliteit en nadelen van de keuzes die worden gemaakt, omdat de configuratie en code van het systeem gemakkelijk te lezen en begrijpen zijn voor mensen. Leesbaarheid kan governance- en kwaliteitsborgingsprocessen versnellen en teams helpen beter te identificeren wanneer ze mogelijk redundante aanpassingen maken. Het kan ook de kansen vergroten op een systeem dat werkt op manieren die herbruikbaar en testbaar zijn.

U kunt de leesbaarheid vergroten door middel van effectieve ontwerpstandaarden en documentatie.

Ontwerpnormen bieden richtlijnen om alle aanpassingen consistent te houden, zelfs in de vroegste ontwikkelingsfasen. Ontwerpnormen fungeren als vangrails, zodat alle leveringsteams en onderhoudsteams op uw systeem afgestemd blijven op de manier waarop aanpassingen moeten worden benaderd en geïmplementeerd. Het definiëren van ontwerpnormen helpt de productiviteit van uw leverings- en onderhoudsteams te verhogen, maakt het uitvoeren van code- en architectuurbeoordelingen gemakkelijker en biedt een basis voor betere documentatie.

Zonder ontwerpnormen werken teams eerder in silo's. Zonder de samenhang die ontwerpnormen bieden, zullen bedrijven worstelen met:

• Leveranciers en ontwikkelingsteams die ad-hocpatronen en -benaderingen voor oplossingen gebruiken, waardoor mogelijk antipatronen worden geïntroduceerd en hergebruik wordt verminderd (zie Scheiding van zorgen).
• Meer tijd voor het oplossen van productieproblemen en ondersteuningsteams die nieuwe teamleden moeten onboarden en ze moeten helpen een ongelijksoortige set patronen en benaderingen te begrijpen.
• Slechte samenwerking tussen teams, redundanties in werk binnen teams, tijdverlies bij het oplossen van conflicten en bugs die zijn ontdekt tijdens integratietests.
• Meer frustratie en hogere omzetcijfers.

Een belangrijk voordeel van ontwerpnormen is dat belanghebbenden gesprekken voeren en beslissingen nemen om ze te maken. Het proces biedt uw bedrijf en technologische leads de mogelijkheid om af te stemmen hoe het optimale ontwerp eruitziet voor uw bedrijf.

Neem het volgende op in uw ontwerpnormen

• Benoemingsconventies voor Salesforce-metagegevens. Definieer een set conventies voor de manier waarop elke aanpassing in een systeem een naam moet krijgen. Goede naamgevingsconventies dwingen niet alleen consistentie af voor de namen van objecten, velden, code, stromen en andere elementen van uw systeem. Goede naamgevingsconventies helpen ontwikkelingsteams ook namen te gebruiken die informatie geven over het doel en de functionaliteit van wat ze samenstellen. Hierdoor kunnen andere belanghebbenden een bepaalde aanpassing beter begrijpen, alleen al door de naam ervan te zien.
• Goedgekeurde ontwerppatronen en hun gebruikscases. Maak een bibliotheek van Patroon- en antipatroonverkenner, samen met belangrijke informatie over wanneer (en wanneer niet) u elk patroon moet gebruiken. De bibliotheek kan vereiste Apex trigger patronen bevatten, of flow doeltreffende patronen op basis van de composability die u in uw systeem wenst.
• Ontwikkelomgeving en toolbegeleiding. Houd een duidelijke lijst bij van de tools die ontwikkelteams voor hun werk moeten gebruiken. Dit kan bestaan uit goedgekeurde toolketens en talen voor iedereen die code schrijft, of uit declaratieve voorzieningen die al dan niet zijn goedgekeurd voor ontwikkeling met weinig code. Uw normen omvatten mogelijk een lijst van bronregelingssystemen voor aanpassing en documentatie, en verplichte in-/uitcheckstappen. Ze kunnen ook een lijst bevatten van omgevingen die moeten worden gebruikt voor verschillende soorten ontwikkelingswerk.

Naast het definiëren van deze standaarden moet u bepalen hoe en waar u ze wilt onderhouden en opslaan. Als teams in uw hele bedrijf uw ontwerpnormen niet kunnen vinden (of zich er niet eens van bewust zijn dat ze bestaan), zijn ze niet effectief. Idealiter bevinden uw ontwerpstandaarden zich in hetzelfde systeem als uw documentatie (zie de volgende sectie voor meer informatie).

De onderstaande lijst met patronen en antipatronen toont hoe goede (en slechte) ontwerpnormen eruitzien voor een Salesforce-organisatie. U kunt deze gebruiken om uw ontwerpnormen te valideren of te verbeteren.

Zie Tools Relevant voor Intentional voor meer informatie over Salesforce-tools waarmee u ontwerpnormen kunt definiëren.

Documentatie legt uit wat, hoe en waarom van uw systeem. Zonder zinnige en consistente documentatie verspillen teams veel tijd aan het proberen te begrijpen van het systeem zoals het is (en potentieel verkeerde functies en aanpassingen).

Goede documentatie vergt tijd om te maken. Hoewel de meeste teams het erover eens zijn dat documentatie belangrijk is voor grote projecten, kan het een verleidelijke stap zijn om deze over te slaan wanneer u snelle wijzigingen aanbrengt, zoals configuratie-updates of kleine aanpassingen aan een automatisering. Het niet documenteren van de wijzigingen die u aanbrengt in uw systeem is altijd een anti-patroon. Het overslaan van documentatie kan vooraf een kleine hoeveelheid tijd besparen, maar de hoeveelheid tijd die nodig is om problemen op te lossen in een organisatie die niet goed is gedocumenteerd, zal die tijdbesparing meer dan tenietdoen. Neem altijd voldoende tijd op om documentatie te maken in al uw schattingen, ongeacht de hoeveelheid inspanning die nodig is voor de updates die u van plan bent aan te brengen.

Het ontbreken van duidelijke documentatie kan leiden tot een verscheidenheid aan problemen, waaronder:

• Ontwikkelingscycli besteed aan het herwerken van bestaande implementaties
• Herhalende discussies die eerdere beslissingen herhalen of verwarren
• Langere onboarding voor nieuwe teamleden of leveranciers
• Overmatige afhankelijkheid van individuen met institutionele of historische Knowledge
• Redundante architecturen voor ondersteuning van dezelfde of soortgelijke mogelijkheden binnen het hele bedrijf
• Moeite met het communiceren van het doel en de waarde van uw oplossing aan de belangrijkste belanghebbenden

Onderhoud voor Salesforce-oplossingen documentatie voor:

• Oplossingsoverzichten. Met diagrammen kunnen u en uw belanghebbenden oplossingen op verschillende niveaus van detail visualiseren. Met het Salesforce-diagramframework kunt u diagrammen maken die de zakelijke mogelijkheden van oplossingen tonen, evenals technische implementatiedetails.
• Beslissingsrecords. Houd de overwogen opties, de nadelen, de definitieve beslissing en de redenering bij op een centrale locatie waartoe alle teamleden toegang hebben voor toekomstige raadpleging.
• Code. Het formaat van code zelf is een belangrijk stuk documentatie en dit kan (en moet) overeenkomen met uw ontwerpstandaarden. U wilt ook een logboek met belangrijke informatie hebben en deze bijwerken bij elke wijziging van een stukje code. Documenteer voor alle klassen, triggers en componenten het volgende:
  • Wie de code heeft geschreven
  • Wanneer de code is geschreven
  • Wat de code moet doen
  • Sleutelafhankelijkheden
  • Alle wijzigingen
• Declaratieve aanpassing. Salesforce biedt ingebouwde kenmerken voor teams om nuttige informatie te geven over het doel en de bedoeling van de metagegevens voor elk soort aanpassing die kan worden aangebracht in de metagegevens in uw organisatie. Als onderdeel van uw ontwerpnormen neemt u op hoe teams deze ingebouwde voorzieningen moeten gebruiken en hoe ze declaratieve aanpassingen moeten benoemen. Houd ook een logboek bij van sleutelgegevens die identiek zijn aan wat u voor code gebruikt.

Ontwikkel een set documentatienormen om ervoor te zorgen dat alle huidige en toekomstige teamleden documenten op dezelfde manier kunnen interpreteren (ontwerpnormen kunnen hierbij helpen.) Het is ook belangrijk om te bedenken hoe gebruikers documentatie kunnen doorzoeken om relevante secties of termen te vinden. Naarmate uw systeem ouder wordt en complexer wordt, neemt ook uw documentatie toe. Het nut van de informatie in uw documentatie hangt rechtstreeks samen met hoe vaak, hoe snel en hoe gemakkelijk gebruikers relevante items kunnen zoeken en vinden.

De onderstaande lijst met patronen en antipatronen toont hoe de juiste (en slechte) documentatie eruitziet voor een Salesforce-organisatie. U kunt deze gebruiken om uw documentatiestrategie te valideren of te verbeteren.

Zie voor meer informatie over Salesforce-tools voor documentatie Tools Relevant voor Intentional.

De volgende tabel toont een selectie van patronen die u in uw organisatie kunt zoeken (of samenstellen) en antipatronen die u kunt vermijden of die u kunt gebruiken voor herstel.

✨ Ontdek meer patronen voor de leesbaarheid in de Patroon & Anti-patroon Explorer.

Help ons Salesforce Well-Architected relevant voor u te houden; neem deel aan onze enquête om feedback te geven over deze inhoud en vertel ons wat u als volgende wilt zien.