Läs om våra uppdateringsscheman här.

Medvetna lösningar levererar verksamhetsvärde direkt och över tid. Syftesarkitekturer planeras och levereras strategiskt, kan underhållas effektivt och är enkla för människor att läsa och förstå.

Funktioner och fixar prioriteras och levereras på sätt som är transparenta för både affärs- och teknikintressenter. Tekniska val skapar implementeringar som är enkla för leverans- och underhållsteam att arbeta med, utan ytterligare funktioner eller komplikationer. Syftesarkitekturer är enklare att äga, underhålla och utveckla med verksamheten eftersom de följer tydliga och enhetliga implementeringsmönster. Byggare kan tolka och implementera design för nya funktioner, och underhållsteam kan förstå dokumentation om vad som implementerats.

Du kan skapa mer avsiktliga system genom att fokusera på tre nyckelområden: strategi, underhållbarhet och läsbarhet.

Strategi i arkitektur innebär att system planeras och levereras genomtänkt. Detta innebär att leverans- och underhållsteam har en tydlig överblick av det arbete som ska utföras idag och i framtiden, och alla är överens om "varför" det arbete som ska utföras. Det innebär att brådskande begäranden kan prioriteras effektivt och ändamålsenligt och att intressenter tydligt kan förstå påverkan och kompromisser av begäranden.

Du kan bygga in en tydligare strategi i din arkitektur genom att fokusera på prioritering, vägkarta och styrning.

Prioritering innebär att planera ordningen och omfattningen av det arbete du ska leverera. Prioritering innefattar att förstå den sanna påverkan av leveranser på verksamheten, utvärdera dessa effekter mot andra arbetsbegäranden och den övergripande vägkartan för din produkt eller program.

Ett sätt att utvärdera påverkan av ett givet arbetsobjekt är att titta på den faktiska kostnaden eller nyttan för verksamheten. När du har identifierat nyckeltalen för automatiseringen kan du använda ett kalkylblad för verksamhetspåverkanberäkning för att utvärdera den övergripande kostnaden eller nyttan med implementeringen. Dessa beräkningar kan hjälpa dig att få anpassning och stöd från dina intressenter om vilka automatiseringar som ska byggas och i vilken ordning. De kan även hjälpa dig identifiera automatiseringar att skjuta upp eller undvika. För automatiseringar, se processdesign för mer information om att identifiera effektivt arbete.

Att etablera ett prioriteringsramverk för leverans hjälper dig och dina underhållsteam att hantera användarnas förväntningar och hålla koll på din vägkarta.

Några saker att tänka på vad gäller prioritering är:

• Verksamhetspåverkan (kostnad/nytta) av leveransen
• Mängd nytt arbete som krävs för leveransen
• Mängd arbete som krävs för att upprätthålla leveransen

Listan över mönster och antimönster nedan visar hur korrekt (och dålig) prioritering ser ut när det gäller Salesforce-arbete. Du kan använda dessa för att validera dina implementeringsplaner, eller identifiera var du bättre behöver identifiera prioriteringar innan du bygger.

Mer information om verktyg som finns tillgängliga från Salesforce för hjälp med prioritering finns i Verktyg relevanta för syfte.

En vägkarta är en prioriterad, validerad, väldefinierad vy av vad som ska göras. Effektiva färdplaner ger en tydlig bild av verksamhetspåverkan och teknikpåverkan av det kommande arbetet. Att engagera dina affärsintressenter och tekniska intressenter är en viktig del av vägkartan. Med hjälp av färdplaner kan du få feedback och stöd om tillvägagångssättet och resultaten innan något arbete påbörjas. I slutändan anpassar färdplanerna varje intressent om "varför" det framtida arbetet.

Om ditt team använder en eftersläpning är det viktigt att förstå att din vägkarta inte är en sammanfattning eller lista över objekten i eftersläpningen. Relationen är den motsatta: Objekt ska endast hamna i eftersläpningen om de tydligt och trovärdigt kan knytas till en leverans på din vägkarta. Högkvalitativa vägkartor, skapade med engagemang från intressenter, ger leverans- och underhållsteam en tydlig vy av vad de ska fokusera på och hur de ska prioritera begäranden, vilket gör det enklare att reda ut motstridiga begäranden och hantera intressenters förväntningar.

Dålig eller obefintlig vägkarta leder till:

• Oklarhet kring när nya funktioner och funktionalitet kommer att vara tillgängliga
• Motstridiga prioriteringar bland intressenter
• En koppling mellan de lösningar som levereras och den övergripande organisationsvisionen
• Svårt att förstå vilket arbete som pågår
• Ojämna arbetsbelastningar mellan team
• Brist på insyn i relationer och beroenden mellan arbetsobjekt
• Uppskjutna implementeringar, på grund av felaktigt hanterade beroenden

Intressenter behöver ofta information som stämmer överens med deras roller för att kunna fatta beslut. Att skapa effektiva vägkartor kräver en tydlig förståelse av din målgrupp och vilken typ av information de behöver. Vägkartor kategoriseras i två stilar för att stödja verksamhetsmålgrupper och tekniska målgrupper. Varje format innehåller två detaljnivåer för att stödja olika typer av information.

Verksamhetsplaner hjälper intressenter planera organisationsförändringar, dra nytta av tillväxtmöjligheter och hålla jämna steg med företagets mål. Verksamhetsplaner ger även ett sätt att säkerställa att IT-utgifterna stämmer överens med den övergripande verksamhetsvisionen.

• Skapa en vägkarta för verksamhetskapacitet för att visa chefsintressenter vilka kapaciteter som kommer att aktiveras. Denna typ av vägkarta innehåller detaljer på hög nivå om själva kapaciteten och hur de ligger i linje med verksamhetsmålen, till exempel att öka den operativa effektiviteten eller lansera en ny produktlinje.
• Skapa en vägkarta för verksamhetsfunktioner för att fördjupa dig i en specifik kapacitet och visa dess stödfunktioner och funktionalitet när du behöver hjälpa verksamhetsintressenter med resursplanering, budgetering och ändringshantering.

Teknikvägplaner hjälper tekniska intressenter med planering av budget och resurstilldelning. De hjälper även implementeringsteam förstå var deras projekt passar som en del av en större helhetsbild och identifiera eventuella beroenden mellan team.

• Skapa en vägkarta för tekniksystem för att visa de specifika system som ska implementeras, tillsammans med eventuella beroenden på systemnivå. Denna typ av vägkarta visar systeminformation på hög nivå och anpassningen mellan system och verksamhetskapacitet.
• Skapa en vägkarta för teknikkomponenter för att fördjupa dig i de specifika komponenterna i ett system som ska distribueras för att hjälpa till med resursplanering och aktiveringskrav. Denna typ av vägkarta visar information på komponentnivå och implementeringskrav (till exempel deklarativ utveckling, prokod och så vidare).

Se till att dina vägkartor innehåller realistiska tidslinjer. Ett vanligt misstag är att endast inkludera den tid det kommer att ta att implementera ett system utan att även överväga den tid det kommer att ta att slutföra relaterade aktiviteter. Detta kan resultera i överallokering av implementeringsteammedlemmar och längre förseningar än förväntat. När du skapar en vägkarta, ta hänsyn till den tid det kommer att ta att slutföra följande:

• Dokumentation av all ny och uppdaterad funktionalitet
• Underhåll av befintlig funktionalitet som behövs för att stödja nya funktioner
• Uppdateringar av relaterade system som krävs för att stödja integreringar
• Ökat stöd från projektteam direkt efter live
• Tester, utbildning och ändringshantering

Vägkartor för verksamhet och teknik som är väl anpassade kommunicerar en helhetsbild av när kapaciteter kommer att tas i bruk och vilken teknik som ligger bakom dem. Listan över mönster och antimönster nedan visar hur korrekta (och dåliga) vägkartor ser ut för en Salesforce-organisation. Du kan använda dessa för att validera eller förbättra din vägkarta.

Mer information om Salesforce-verktyg som kan hjälpa dig med vägkarta finns i Verktyg relevanta för syfte.

Governance är den struktur du använder för att hantera prioritering, beslutsfattande och ändringshantering med dina intressenter. Styrningen gör det tydligt hur beslut fattas och kommuniceras. Det ger enhetliga sätt för feedback och begäranden att gå in i beslutsprocessen och för alla intressenter att förstå status för underhåll och utvecklingsarbete. Governance hjälper releasehanteringsprocesser att vara tydliga och enhetliga, och hjälper alla teammedlemmar förstå sina roller och ansvar.

Utan korrekt styrning kommer team att uppleva en mängd olika problem, inklusive:

• Begäranden om överlappande funktioner och funktionalitet anländer ad hoc
• Implementeringsteam prioriterar "enklare" insatser eller förfrågningar från mer inflytelserika intressenter, utan att ta hänsyn till affärsvärde, kompromisser eller övergripande organisatoriska mål
• Brist på enhetliga godkännande- och granskningsprocesser
• Inkonsekventa releasekadenser och kvalitet
• Höga felfrekvenser, överskrivningar, konflikter och överflödigt arbete i utvecklingsinsatser

Det kanske tydligaste tecknet på att ett system inte har effektiv styrning är långsamma och besvärliga utgåvor. Det är viktigt att inse att storleken på ett styrsystem inte är ett mått på dess effektivitet. Faktum är att genomarbetade system för styrning (som de som finns i många stora företag) kan begränsa hastigheten och frekvensen av utgivningar.

God styrning handlar om att göra det svårt för dåliga anpassningar att komma förbi de tidiga utvecklingsfaserna, och att få bra anpassningar i produktion på ett förutsägbart och konsekvent sätt.

Alltför ofta är styrningsarbetet reaktionärt. De inleds eller fördubblas när ett problem, som till exempel överdriven teknisk skuld, börjar bli ett verksamhetsproblem. I många fall är det olyckliga svaret att verksamheten "låser" utvecklingsinsatser och releaser, istället för att skapa effektiva designstandarder och byggnadsautomatisering för att tillämpa dessa standarder inom utvecklarverktygskedjor och källkontrollsystem.

När du bygger ramverket för ditt Salesforce-styrningssystem inkludera följande element och tänk på dessa nyckelfrågor som ska besvaras:

• Arbetsbegäranden. Hur kan användare be om funktionalitet eller funktioner? Hur rapporteras buggar?
• Prioritering och arbetsplanering. Vem bestämmer vilka arbetsbegäranden som är viktiga? Hur begränsas, prioriteras och accepteras eller signeras arbete?
• Miljöer och releaseplanering. Vad är miljöpipeline för utveckling, tester och utgivning? Vem gör vad för att provisionera, uppdatera och ge åtkomst? Vem hanterar distribueringar och validering? Hur och när släpps ändringar? Hur hanterar du distribueringar eller miljöer under en Salesforce-utgivningscykel? (Mer information om detta finns i Hantering av programlivscykel.)
• Serviceägande och produktionssupport. Vem stöder vad? Vem hanterar problem med "hotfix"-produktion? Hur testas och släpps dessa objekt? Vem ansvarar för organisationens övergripande säkerhetsstandarder?

Listan över mönster och antimönster nedan visar hur korrekt (och dålig) styrning ser ut för en Salesforce-organisation. Du kan använda dessa för att validera eller förbättra din styrningsstrategi.

Mer information om Salesforce-verktyg som är tillgängliga för styrning finns i Verktyg relevanta för syfte.

Följande tabell visar ett urval av mönster att leta efter (eller bygga) i din organisation och antimönster att undvika eller rikta in sig på för att åtgärda.

✨ Upptäck fler mönster för strategi i Mönster & Anti-Mattern Explorer.

Underhållbarhet innebär att ett system kan hållas i ett sunt tillstånd, med nya funktioner som flyttas in och tekniska skulder som flyttas ut ur systemet på en regelbunden, förutsägbar basis. Underhållbara system låter dina team leverera värde till verksamheten med förutsägbar hastighet och kvalitet. Underhållbarheten för ett system beror på flera faktorer, inklusive hur läsbart det är, hur löst kopplat det är och hur grundlig dess teststrategi är.

Viktigast av allt är att underhållbarheten för ett system beror på hur enkel dess design är. Denna sektion täcker sätt att skapa enklare lösningsdesigner och öka underhållbarheten.

Du kan bygga lösningar som är enklare att underhålla genom att fokusera på två nycklar: använda standard över egen funktionalitet och hantera teknisk skuld.

Salesforce erbjuder en rad färdigbyggda lösningar — Sales Cloud, Service Cloud och många Salesforce-branschlösningar — samt flexibiliteten att skapa dina egna anpassade lösningar. De grundläggande tjänster som driver Salesforces egna molnlösningar är även tillgängliga för egna lösningar byggda på Salesforce Customer 360 Platform. Använd de färdigbyggda tjänsterna och lösningarna från Salesforce som en betrodd grund för så många av dina lösningar som möjligt.

Att använda färdigbyggda plattformstjänster har två unika fördelar. För det första kan dina appar naturligtvis dra nytta av de senaste Salesforce-innovationerna i varje utgåva. För det andra kan dina utvecklingsteam fokusera på att utöka och fördjupa de verksamhetsmöjligheter som dina Salesforce-lösningar ger istället för att hantera grundläggande tunga arkitektoniska lyft.

Att korrekt välja när man ska använda standardfunktionalitet och när man ska bygga egen funktionalitet är inte svårt ur en arkitektonisk synvinkel. Nycklarna är:

• Att anpassa plattformen innebär att ändra och utöka, inte kopiera. När du utformar eller utvärderar din arkitektur bör du fråga: Finns detta redan någonstans i Salesforce Platform? Om svaret är "Ja, men...[infoga ändringar som en affärsintressent vill ha här...]", använd den färdigbyggda funktionen i plattformen. Det arkitektoniska arbete som ska utföras är att identifiera de mest användbara sätten att konfigurera den färdigbyggda Salesforce-funktionen så att den uppfyller verksamhetens förväntningar.
• Inga anpassningar är triviala. Över tid har varje ändring konsekvenser. Om du behöver implementera en egen lösning kan du minska den oundvikliga tekniska skuld som ditt system kommer att få genom att välja att använda lågkodsteknik när så är möjligt, och genom att skapa sammansättningsbara enheter i dina implementeringar.
• Överväg byggköpsspektrumet. Salesforce AppExchange är en marknadsplats för appar och lösningar för att utöka Salesforce. AppExchange kan leverera funktionalitet utan den extra kostnad det innebär att bygga och underhålla en egen lösning. Tänk på följande när du utvärderar AppExchange lösningar:
  • Identifiera lösningsfunktioner och luckor. Det bästa är om du hittar en app som uppfyller alla dina verksamhetskrav. I verkligheten kanske du inte hittar en perfekt passform. När du bedömer lösningar, mappa funktionalitet i den potentiella lösningen till en prioriterad lista över verksamhetskrav. Detta hjälper dig att hitta den lösning som bäst uppfyller dina mest kritiska krav.
  • Använd sandboxar och gratis provversioner. Använd gratis provperioder för att utvärdera appar i sandboxmiljöer och identifiera den bästa passformen. Avgör om appar kräver att du gör konfigurationsändringar som står i konflikt med din befintliga konfiguration.
  • Tänk på kortsiktiga och långsiktiga kostnader. Utvärdera långsiktiga besparingar i appunderhåll mot de återkommande kostnaderna för prenumerationsbaserade appar. Undvik scenarion där du måste betala återkommande kostnader för mycket funktionalitet som dina affärsintressenter aldrig kommer att använda.
• Använd de färdigbyggda datamodellerna från Salesforce. Salesforce tillhandahåller färdigbyggda datamodeller för försäljning, service och en mängd olika branschvertikaler. Att använda de datamodeller som tillhandahålls av Salesforce säkerställer att kapaciteter i ditt system endast definieras en gång (vilket eliminerar överflödighet och silos), etablerar en enskild källa till sanning i hela systemet, gör det enklare att förstå programdata med analyser, gör det enklare att använda Salesforces färdigbyggda tjänster för artificiell intelligens, sänker underhållskostnaderna (genom att minska anpassningar som du behöver stödja) och minskar teknisk skuld.

Så enkelt är det. Som du kan se i mönstren och antimönster nedan handlar antimönstren om att replikera standardfunktioner i en egen lösning, eller att använda mer komplex teknik för att leverera anpassningar.

I praktiken kan du stöta på ett scenario där ett eget antimönster för funktionalitet ses av affärsintressenter som den bästa eller enda hållbara vägen framåt. I dessa fall är det viktigt att du förklarar för intressenterna vilka kompromisser det innebär att välja denna väg och sedan noggrant dokumenterar beslutet, dess logiska grund och dess genomförande. Detta är också ett område där att leverera kärnvärde tidigt och anpassa sig över tid kan hjälpa dina intressenter att bättre förstå den bästa vägen framåt.

Mer information om Salesforce-verktyg som kan hjälpa dig att öka underhållbarheten finns i Verktyg relevanta för syfte.

Teknisk skuld är en naturlig del av alla system. Gårdagens ljuddesign kan bli antimönster när teknik eller verksamhetsbehov ändras. Kanske något som byggts för att fylla ett tomrum i Salesforce Platform-funktionalitet plötsligt blir överflödigt med en ny Salesforce-utgåva eller produktlansering. En mer effektiv eller flexibel teknik kanske ersätter en teknik som du redan har implementerat. Teknisk skuld kan skapas på många sätt.

En viktig fördel med att bygga program med Salesforce Customer 360 Platform är den bakåtkompatibilitet som byggts in i plattformen. Detta innebär att nya plattformsinnovationer kan ändra det mönster du ska använda för lösningar som går framåt, men den dagliga funktionen för lösningar som du har byggt på tidigare Salesforce-tekniker kommer att fortsätta att fungera. Över tid kommer alla lösningar baserade på äldre teknik att innebära risker eller flaskhalsar för att lägga till nya funktioner i dina appar och minska den övergripande lösningshälsan.

Att planera och utföra regelbundet arbete för att hantera tekniska skulder är viktigt för att upprätthålla sunda, enkla konstruktioner i en Salesforce-lösning. Att inte planera, granska och åtgärda tekniska skulder är ett säkert sätt att skapa ett system som är dåligt utformat.

Ett sätt att minimera teknisk skuldsättning är att undvika att introducera den så mycket som möjligt, genom att undvika genvägar och genom att föredra standardfunktionalitet framför egen funktionalitet. Genvägar, som hårdkodande värden, kan vara frestande att spara tid, men på lång sikt skapar de skulder som måste betalas tillbaka.

Nyckeln till att hantera teknisk skuld från ett arkitektoniskt perspektiv inkluderar:

• Identifiera den faktiska kostnaden eller nyttan för åtgärden jämfört med passivitet
• Korrekt vägkarta
• Bygga kompositlösningar

Svårigheten kan vara att få intressenterna att anpassa sig till att vidta åtgärder. Vissa intressenter kan uppfatta löpande underhåll som att åtgärda "gårdagens misstag" eller ta bort de funktioner de vill att deras budget ska stödja.

Att visa de verkliga verksamhetseffekterna av åtgärder och inaktivitet, tillsammans med tydligt definierade resultat och tidslinjer kan hjälpa dina intressenter förstå värdet och den relativa prioriteten av att hantera tekniska skulder. Att konsekvent utföra arbetet för att ansluta teknisk skuld till verksamhetspåverkan hjälper inte bara dina intressenter att bättre förstå det arbete som ska utföras. Det hjälper dig även att säkerställa att du identifierar och hanterar tekniska skulder på ett sätt som verkligen gynnar användarna.

Listan över mönster och antimönster nedan visar hur korrekt (och dålig) teknisk skuldhantering ser ut för en Salesforce-organisation.

Mer information om Salesforce-verktyg som kan hjälpa dig med tekniska skulder finns i Verktyg relevanta för syfte.

Följande tabell visar ett urval av mönster att leta efter (eller bygga) i din organisation och antimönster att undvika eller rikta in sig på för att åtgärda.

✨ Upptäck fler mönster för underhåll i Mönster & Anti-Mattern Explorer.

Kärnan i begreppet läsbarhet är att skapa enhetlighet som gör det enkelt för människor att förstå hur saker fungerar. Att bygga läsbara system anpassar leverans- och underhållsteam och hjälper personer som inte är bekanta med systemet att snabbt förstå hur bitar hänger ihop. Detta innebär att ditt team kan vara mindre beroende av enskilda personer med institutionell eller historisk Knowledge för att effektivt introducera leverantörer eller nya teammedlemmar. Det innebär att skickliga personer i ett team kan fokusera på kvaliteten och kompromisserna i de val som görs, eftersom systemets konfiguration och kod är enkla för människor att läsa och förstå. Läsbarhet kan snabba på styrning och kvalitetssäkringsprocesser och hjälpa team att bättre identifiera när de kan skapa överflödiga anpassningar. Det kan också öka chanserna att ha ett system som beter sig på ett sätt som är återanvändbart och testbart.

Du kan öka läsbarheten genom effektiva designstandarder och dokumentation.

Designstandarder ger vägledning för att hålla alla anpassningar enhetliga, även i de tidigaste utvecklingsfaserna. Designstandarder fungerar som skyddsräcken och håller alla leveransteam och underhållsteam som arbetar med ditt system i linje med hur de ska närma sig och implementera anpassningar. Att definiera designstandarder hjälper till att öka produktiviteten för dina leverans- och underhållsteam, gör det enklare att utföra kodgranskningar och arkitektgranskningar och ger en grund för bättre dokumentation.

Utan designstandarder är det mer troligt att team arbetar i silos. Utan den enhetlighet som designstandarder ger kommer företag att brottas med:

• Säljare och utvecklingsteam som använder ad hoc-mönster och -metoder för olika lösningar, vilket kan introducera antimönster och minska återanvändningsbarheten (se Separering av problem).
• Ökad tid för att lösa produktionsproblem och supportteam som behövs för att introducera nya teammedlemmar och hjälpa dem förstå olika mönster och tillvägagångssätt.
• Dåligt samarbete mellan team, överflödigt arbete mellan team, förlorad tid för att lösa konflikter och buggar som upptäckts under integreringstester.
• Ökad frustration och högre omsättningshastigheter.

En viktig fördel med designstandarder är de konversationer och beslut intressenter måste fatta för att skapa dem. Specifikt ger processen dina verksamhets- och teknikleads möjlighet att anpassa sig kring hur optimal design ser ut för din verksamhet.

Inkludera följande i dina designstandarder

• Namnkonventioner för Salesforce-metadata. Definiera en uppsättning konventioner för hur varje anpassning i ett system ska namnges. Bra namnkonventioner upprätthåller inte bara enhetlighet för namnen på objekt, fält, kod, flöden och andra element i ditt system. Bra namnkonventioner hjälper även utvecklingsteam att använda namn som förmedlar information om syftet och funktionaliteten hos det de bygger. På så sätt kan andra intressenter bättre förstå en viss anpassning, bara genom att se dess namn.
• Godkända designmönster och deras användningsfall. Upprätta ett bibliotek med Mönster- och antimönsterutforskare, tillsammans med viktig information om när (och när) varje mönster ska användas. Biblioteket kan innehålla obligatoriska Apex utlösarmönster, eller flödesorkestreringsmönster baserat på den komponerbarhet du vill ha i ditt system.
• Utvecklingsmiljö och verktygsvägledning. Ha en tydlig lista över de verktyg som utvecklingsteam ska använda i sitt arbete. Detta kan inkludera godkända verktygskedjor och språk för alla som skriver kod, eller deklarativa funktioner som är (eller inte är) godkända för utveckling med låg kod. Dina standarder kan innehålla en lista över källkontrollsystem för anpassning och dokumentation, och obligatoriska steg för in- och utcheckning. De kan även innehålla en lista över miljöer att använda för olika typer av utvecklingsarbete.

Utöver att definiera dessa standarder måste du bestämma hur och var du vill underhålla och lagra dem. Om team i ditt företag inte kan hitta dina designstandarder (eller inte ens är medvetna om att de finns) kommer de inte att vara effektiva. Det bästa är om dina designstandarder finns inom samma system som din dokumentation (se nästa avsnitt för mer information).

Listan över mönster och antimönster nedan visar hur korrekta (och dåliga) designstandarder ser ut för en Salesforce-organisation. Du kan använda dessa för att validera eller förbättra dina designstandarder.

Mer information om Salesforce-verktyg som kan hjälpa dig definiera designstandarder finns i Verktyg relevanta för syfte.

Dokumentation förklarar vad, hur och varför ditt system används. Utan meningsfull och konsekvent dokumentation slösar team mycket tid på att försöka förstå systemet som det är (och eventuellt missförstå funktioner och anpassningar).

Bra dokumentation tar tid att skapa. Även om de flesta team är överens om att dokumentation är viktigt för stora projekt kan det vara ett frestande steg att hoppa över när du gör snabba ändringar som konfigurationsuppdateringar eller mindre justeringar av en automatisering. Att inte dokumentera de ändringar du gör i ditt system är alltid ett anti-mönster. Att hoppa över dokumentation kan spara lite tid direkt, men den tid som krävs för att felsöka en organisation som inte är korrekt dokumenterad kommer mer än att ta bort dessa tidsbesparingar. Inkludera alltid tillräckligt med tid för att skapa dokumentation i alla dina uppskattningar, oavsett vilken ansträngningsnivå som krävs för de uppdateringar du planerar att göra.

Bristen på tydlig dokumentation kan leda till en rad olika problem, inklusive:

• Utvecklingscykler som används för att omarbeta befintliga implementeringar
• Upprepande diskussioner som återkommer eller förbryllar tidigare beslut
• Längre introduktioner för nya teammedlemmar eller leverantörer
• Överberoende av individer med institutionell eller historisk Knowledge
• Överflödiga arkitekturer för att stödja samma eller liknande kapacitet i hela verksamheten
• Svårigheter att kommunicera syftet och värdet av din lösning till viktiga intressenter

För Salesforce-lösningar, upprätthåll dokumentation för:

• Lösningsöversikter. Diagram låter dig och dina intressenter visualisera lösningar på olika detaljnivåer. Salesforce-diagramramverket hjälper dig skapa diagram som visar affärskapaciteten för lösningar, samt tekniska implementeringsdetaljer.
• Beslutsposter. Håll ett register över de alternativ som övervägs, kompromisser, slutgiltiga beslut och resonemang på en central plats som alla teammedlemmar kan komma åt för framtida referens.
• Kod. Själva kodformatet är en viktig dokumentation, och detta kan (och bör) överensstämma med dina designstandarder. Du vill även ha en logg med nyckelinformation och uppdatera den med varje ändring av en kod. För alla klasser, utlösare och komponenter, dokumentera följande:
  • Vem som skapade koden
  • När koden skrevs
  • Vad koden ska göra
  • Nyckelberoenden
  • Alla ändringar
• Deklarativ anpassning. För varje typ av anpassning som kan göras av metadata i din organisation tillhandahåller Salesforce inbyggda attribut för team för att ge hjälpsam information om syftet med metadata. Som en del av dina designstandarder, inkludera hur team ska använda dessa inbyggda funktioner och hur de ska namnge deklarativa anpassningar. Upprätthåll även en logg med nyckelinformation som är identisk med vad du använder för kod.

Utveckla en uppsättning dokumentationsstandarder för att säkerställa att alla nuvarande och framtida teammedlemmar kan tolka dokument på samma sätt (designstandarder kan hjälpa till med detta). Det är även viktigt att tänka på hur användare kommer att kunna söka i dokumentation för att hitta relevanta sektioner eller termer. Allt eftersom ditt system åldras och blir mer komplext kommer din dokumentation också att växa. Användbarheten av informationen i din dokumentation kommer att vara direkt relaterad till hur ofta, hur snabbt och hur enkelt användare kan söka efter och hitta relevanta objekt.

Listan över mönster och antimönster nedan visar hur korrekt (och dålig) dokumentation ser ut för en Salesforce-organisation. Du kan använda dessa för att validera eller förbättra din dokumentationsstrategi.

Mer information om Salesforce-verktyg för dokumentation finns i Verktyg relevanta för syfte.

Följande tabell visar ett urval av mönster att leta efter (eller bygga) i din organisation och antimönster att undvika eller rikta in sig på för att åtgärda.

✨ Upptäck fler mönster för läsbarhet i Mönster & Anti-Mattern Explorer.

Hjälp oss hålla Salesforce Well-Architected relevant för dig. Gå igenom vår undersökning för att ge feedback om detta innehåll och berätta vad du vill se härnäst.