Læs om vores opdateringsplaner heri.

Hensigtsmæssige løsninger leverer forretningsværdi med det samme og over tid. Hensigtsarkitekturer er planlagt og leveret strategisk, kan vedligeholdes effektivt og er nemme for mennesker at læse og forstå.

Funktioner og rettelser prioriteres og leveres på måder, der er gennemsigtige for forretnings- og teknologi interessenter på samme måde. Ingeniørvalg opretter implementeringer, der er nemme for levering og vedligeholdelsesteams at arbejde med, uden yderligere funktioner eller komplikationer. Hensigtsarkitekturer er nemmere at eje, vedligeholde og udvikle med forretningen, fordi de følger tydelige og ensartede implementeringsmønstre. Konstruktører kan fortolke og implementere designs for nye funktioner, og vedligeholdelsesteams kan forstå dokumentation for, hvad der er implementeret.

Du kan oprette mere hensigtsmæssige systemer ved at fokusere på tre nøgleområder: strategi, vedligeholdelse og læsbarhed.

Strategi i arkitektur betyder, at systemer er omhyggeligt planlagt og leveret. Det betyder, at leverings- og vedligeholdelsesteams har en tydelig visning af det arbejde, der skal udføres i dag og i fremtiden, og alle er i overensstemmelse med "hvorfor" det arbejde, der skal udføres. Det betyder, at vigtige anmodninger kan sorteres effektivt og effektivt, og interessenter kan tydeligt forstå påvirkningen og afvejningerne af anmodninger.

Du kan opbygge en tydeligere strategi i din arkitektur ved at fokusere på prioritering, oversigt og ledelse.

Prioritering betyder planlægning af rækkefølgen og omfanget af det arbejde, du vil levere. Prioritering involverer forståelse af den sande påvirkning af leverancer på forretningen, evaluering af disse påvirkninger i forhold til andre arbejdsanmodninger og den generelle oversigt for dit produkt eller dit program.

En måde at evaluere påvirkningen af et givent arbejdselement på er at se på den faktiske udgift eller fordel for forretningen. Når du har identificeret KPI'er for automatiseringen, kan du bruge et arbejdsark til beregning af forretningseffekt til at evaluere de generelle omkostninger eller fordele ved implementeringen. Disse beregninger kan hjælpe dig med at få justering og buy-in fra dine interessenter om, hvilke automatiseringer der skal opbygges, og i hvilken rækkefølge. De kan også hjælpe dig med at identificere automatiseringer, der skal udsættes eller undgås. For automatiseringer kan du se procesdesign for at få mere at vide om at identificere effektivt arbejde.

Etablering af en prioriteringsstruktur for levering vil også hjælpe dig og dine vedligeholdelsesteam med at administrere brugerforventninger og forblive i overensstemmelse med din oversigt.

Nogle overvejelser, du kan bruge til prioritering, omfatter:

• Forretningseffekt (omkostninger/fordele) for det leverede
• Mængden af nyt arbejde, der kræves for den leverede
• Mængde arbejde, der kræves for at vedligeholde den leverede

Listen over mønstre og anti-mønstre nedenfor viser, hvordan korrekt (og dårlig) prioritering ser ud, når det kommer til Salesforce-arbejde. Du kan bruge disse til at validere dine implementeringsplaner eller identificere, hvor du har brug for bedre at identificere prioriteter, før du opbygger.

Hvis du vil vide mere om værktøjer, der er tilgængelige fra Salesforce for at få hjælp til prioritering, kan du se Værktøjer, der er relevante for hensigter.

En oversigtskort er en prioriteret, valideret, veldefineret visning af, hvad der skal gøres. Effektive oversigter giver et tydeligt billede af forretningspåvirkningen og teknologispåvirkningen af det arbejde, der kommer. Engagement med dine forretnings- og tekniske interessenter er en vigtig del af oversigtskortet. Med oversigter kan du få feedback og se nærmere på tilgangen og resultaterne, før noget arbejde begynder. I sidste ende justerer oversigter alle interessenter om "hvorfor" arbejdet kommer.

Hvis dit team bruger en forsinkelse, er det vigtigt at forstå, at din oversigt ikke er et sammendrag eller en liste over elementerne i forsinkelsen. Relationen er det modsatte: Elementer er kun til at angive forsinkelsen, hvis de tydeligt og troværdigt kan knyttes til en leveret på din oversigt. Vejledninger af høj kvalitet, der er oprettet med interessenters engagement, giver levering og vedligeholdelsesteams en tydelig visning af, hvad de skal fokusere på, og hvordan de skal prioritere anmodninger, hvilket gør det nemmere at sortere konfliktende anmodninger og administrere interessenters forventninger.

Dårlig eller ikke-eksisterende oversigt fører til:

• Manglende klarhed omkring, hvornår nye funktioner og funktionalitet vil være tilgængelige
• Konflikte prioriteter blandt interessenter
• En afbrydelse mellem de leverede løsninger og den generelle organisatoriske vision
• Problemer med at forstå, hvad der sker
• Uensartede arbejdsbelastninger på tværs af teams
• Manglende synlighed i relationer og afhængigheder mellem arbejdselementer
• Stoppe implementeringer på grund af ikke-administrerede afhængigheder

Interesserede har ofte brug for oplysninger, der passer til deres roller for at træffe beslutninger. Oprettelse af effektive oversigter kræver en tydelig forståelse af din målgruppe og den type oplysninger, de har brug for. Oversigter er kategoriseret i to typografier for at understøtte forretnings- og tekniske målgrupper. Hver typografi indeholder to niveauer af detaljer for at understøtte forskellige typer af oplysninger.

Forretningsoversigter hjælper interessenter med at planlægge organisationsændringer, udnytte vækstmuligheder og forblive i overensstemmelse med virksomhedens målsætninger. Forretningsoversigter giver også en måde til at sikre, at it-forbrug er i overensstemmelse med den generelle forretningsvision.

• Opret en forretningskapacitetsoversigt for at vise ledende interessenter de funktioner, der skal aktiveres. Denne type oversigt indeholder detaljer på højt niveau om selve funktionerne, og hvordan de stemmer overens med forretningsmålsætninger, f.eks. øget driftseffektivitet eller lancering af en ny produktlinje.
• Opret en forretningsfunktionsoversigt for at gå i detaljer med en specifik funktionalitet og vise dens understøttende funktioner og funktionalitet, når du har brug for at hjælpe forretningsinteressenter med ressourceplanlægning, budgettering og ændringsstyring.

Teknologioversigter hjælper tekniske interessenter med budget- og ressourcetildelingsplanlægning. De hjælper også implementeringsteams med at forstå, hvor deres projekter passer som en del af et større samlet billede og identificere eventuelle krydsteamafhængigheder.

• Opret en teknologisystemoversigt for at vise de specifikke systemer, der skal implementeres, sammen med eventuelle afhængigheder på systemniveau. Denne type oversigt viser systemoplysninger på højt niveau og justeringen mellem systemer og forretningsfunktioner.
• Opret en teknologikomponentoversigt for at gå i detaljer med de specifikke komponenter i et system, der skal implementeres for at hjælpe med ressourceplanlægning og aktiveringskrav. Denne type oversigt viser oplysninger på komponentniveau og implementeringskrav (f.eks. deklarativ udvikling, pro-code osv.).

Sørg for, at dine oversigter indeholder realistiske tidslinjer. En almindelig fejl er kun at inkludere den mængde tid, det vil tage at implementere et system uden også at tage højde for den mængde tid, det vil tage at fuldføre relaterede aktiviteter. Dette kan resultere i overallokering af implementeringsteammedlemmer og længere end forventede forsinkelser. Når du opretter en oversigt, skal du tage højde for den tid, det tager at fuldføre følgende:

• Dokumentation af al ny og opdateret funktionalitet
• Vedligeholdelse af eksisterende funktionalitet, der er nødvendig for at understøtte nye funktioner
• Opdateringer til relaterede systemer, der er påkrævet for at understøtte integrationer
• Forøget support fra projektteams umiddelbart efter live-start
• Test, uddannelse og ændringsstyring

Forretnings- og teknologioversigter, der er veljusterede, kommunikerer en holistisk visning af, hvornår funktionerne går live, og hvilken teknologi der ligger bag dem. Listen over mønstre og anti-mønstre nedenfor viser, hvordan rigtige (og dårlige) oversigter ser ud for en Salesforce-organisation. Du kan bruge disse til at validere eller forbedre din oversigtsstrategi.

Hvis du vil vide mere om Salesforce-værktøjer, der kan hjælpe dig med oversigt, kan du se Værktøjer, der er relevante for hensigter.

Styring er den struktur, du bruger til at håndtere prioritering, beslutningstagning og ændringsstyring med dine interessenter. Styring gør det tydeligt, hvordan beslutninger træffes og kommunikeres. Den giver ensartede måder for feedback og anmodninger om at deltage i beslutningsprocessen, og for alle interessenter at forstå statussen for vedligeholdelses- og udviklingsarbejde. Styring hjælper frigivelsesstyringsprocesser med at være tydelige og ensartede og hjælper alle teammedlemmer med at forstå deres roller og ansvarsområder.

Uden korrekt ledelse vil teams opleve en række problemer, herunder:

• Anmodninger om overlappende funktioner og funktionalitet ankommer ad hoc
• Implementeringsteams prioriterer "enkler" bestræbelser eller anmodninger fra mere indflydelsesrige interessenter uden korrekt overvejelse af forretningsværdi, afvejninger eller generelle organisationsmål
• Manglende ensartede godkendelses- og gennemgangsprocesser
• Inkonsekvente frigivelseskadencer og -kvalitet
• Høje fejlfrekvenser, overskrivelser, konflikter og overflødigt arbejde i udviklingsbestræbelser

Måske er det tydeligste tegn på, at et system ikke har effektiv styring, langsomme og besværlige versioner. Det er vigtigt at anerkende, at størrelsen på et styringssystem ikke er et mål for dets effektivitet. Faktisk kan avancerede systemer til styring (som dem, der findes i mange store virksomheder) begrænse hastigheden og frekvensen af frigivelser.

God styring handler om at gøre det vanskeligt for dårlige tilpasninger at komme over de tidlige faser af udvikling og få gode tilpasninger ind i produktionen forudsigeligt og ensartet.

For ofte er styringsbestræbelser reaktionære. De startes eller fordobles, når et problem, f.eks. overdreven teknisk gæld, begynder at blive et forretningsproblem. I mange tilfælde er den uheldige reaktion for virksomheden at "låse ned" udviklingsbestræbelser og udgivelser i stedet for at skabe effektive designstandarder og byggeautomatisering for at håndhæve disse standarder i udviklerværktøjskæder og kildekontrolsystemer.

Når du opbygger strukturen for dit Salesforce-styringssystem, skal du inkludere følgende elementer og overveje at få svar på disse nøglespørgsmål:

• Arbejdsanmodninger. Hvordan kan brugere bede om funktionalitet eller funktioner? Hvordan rapporteres fejl?
• Prioritering og arbejdsplanlægning. Hvem bestemmer, hvad arbejdsanmodninger betyder? Hvordan er arbejde omfanget, prioriteret og accepteret eller signeret på?
• Miljø og frigivelsesplanlægning. Hvad er miljøpipelinen for udvikling, test og frigivelse? Hvem gør hvad til at klargøre, opdatere og give adgang? Hvem håndterer implementeringer og validering? Hvordan og hvornår frigives ændringer? Hvordan håndterer du implementeringer eller miljøer under en Salesforce-frigivelsescyklus? (Hvis du ønsker flere oplysninger om dette, kan du se Applikationslivscyklusstyring).
• Serviceejerskab og produktionsstøtte. Hvem understøtter hvad? Hvem håndterer "hot-fix"-produktionsproblemer? Hvordan testes og frigives disse elementer? Hvem er ansvarlig for organisationens generelle sikkerhedsstandarder?

Listen over mønstre og modmønstre nedenfor viser, hvordan korrekt (og dårlig) ledelse ser ud for en Salesforce-organisation. Du kan bruge disse til at validere eller forbedre din styringsstrategi.

Hvis du vil vide mere om Salesforce-værktøjer, der er tilgængelige for styring, kan du se Værktøjer, der er relevante for hensigter.

Følgende tabel viser et udvalg af mønstre, der skal søges efter (eller opbygges) i din organisation, og anti-mønstre, der skal undgås eller målrettes for rettelse.

✨ Oplev flere mønstre for strategi i Pattern & Anti-Pattern Explorer.

Vedligeholdelighed betyder, at et system kan bevares i en sund tilstand med nye funktioner, der flytter ind, og teknisk gæld, der flytter ud af systemet på en regelmæssig, forudsigelig basis. Vedligeholdelige systemer gør det muligt for dine teams at levere værdi til forretningen med forudsigelig hastighed og kvalitet. Vedligeholdelsesmuligheden af et system afhænger af flere faktorer, herunder hvor læsbar det er, hvor løst koblet det er, og hvor grundig dens teststrategi er.

Vigtigst af alt afhænger vedligeholdelsesmuligheden af et system af, hvor ligetil dets design er. Dette afsnit dækker måder til at oprette mere umiddelbare løsningedesign og øge vedligeholdelsesmuligheden.

Du kan opbygge løsninger, der er nemmere at vedligeholde, ved at fokusere på to nøgler: brug af standard over tilpasset funktionalitet og håndtering af teknisk gæld.

Salesforce tilbyder en række løsninger, der er bygget på forhånd – Sales Cloud, Service Cloud og mange Salesforce-brangeløsninger – samt fleksibiliteten til at oprette dine egne tilpassede løsninger. De grundlæggende tjenester, der styrer Salesforces egne cloudløsninger, er også tilgængelige for alle tilpassede løsninger, der bygger på Salesforce Customer 360 Platform. Brug de tjenester og løsninger, der er bygget på forhånd, fra Salesforce som et betroet fundament for så mange af dine løsninger som muligt.

Brug af platformstjenester, der er bygget på forhånd, har to forskellige fordele. Først skal dine apps naturligvis drage fordel af de seneste Salesforce-innovationer med hver version. Og for det andet kan dine udviklingsteams fokusere på at udvide og uddybe de forretningsfunktioner, der leveres af dine Salesforce-løsninger, i stedet for at håndtere grundlæggende arkitektonisk tungt arbejde.

Korrekt valg af, hvornår du vil bruge standardfunktionalitet, og hvornår du vil opbygge tilpasset funktionalitet, er ikke udfordrende fra et arkitektonisk synspunkt. Nøglerne er:

• At tilpasse platformen betyder at ændre og udvide, ikke at kopiere. Når du designer eller evaluerer din arkitektur, bør du spørge: Findes det allerede et eller andet sted på Salesforce Platform? Hvis svaret er “Ja, men...[indsæt ændringer en virksomhed interessent ønsker her...]”, så brug den forudbyggede funktion i platformen. Det arkitektoniske arbejde, der skal udføres, er at identificere de mest nyttige måder til at konfigurere den Salesforce-funktion, der er bygget på forhånd, til at opfylde forretningsforventninger.
• Ingen tilpasninger er trivielle. Over tid har hver ændring konsekvenser. Hvis du har brug for at implementere en tilpasset løsning, kan du reducere den uundgåelige tekniske gæld dit system vil akkumulere ved at vælge at bruge lavkode teknologi, når det er muligt, og ved at skabe komponerbare enheder i dine implementeringer.
• Tænk på build-buy-spektret. Salesforce AppExchange er en markedsplads med apps og løsninger til at udvide Salesforce. AppExchange apps kan levere funktionalitet uden overhead involveret i at opbygge og vedligeholde en tilpasset løsning. Overvej følgende, når du evaluerer AppExchange:
  • Identificer løsningsfunktioner og mangler. Ideelt vil du finde en app, der opfylder alle dine forretningskrav. I virkeligheden vil du måske ikke finde et perfekt match. Når du vurderer løsninger, skal du tilknytte funktionalitet i den potentielle løsning til en prioriteret liste over forretningskrav. Dette vil hjælpe dig med at finde den løsning, der bedst opfylder dine mest kritiske krav.
  • Brug sandboxes og gratis prøveversioner. Brug gratis prøveperioder til at evaluere apps i sandbox-miljøer og identificere dem, der passer bedst. Bestem, om apps vil kræve, at du foretager konfigurationsændringer, der er i konflikt med din eksisterende konfiguration.
  • Overvej kortsigtede og langsigtede omkostninger. Evaluer langsigtede vedligeholdelsesbesparelser i forbindelse med tilbagevendende omkostninger i abonnementbaserede apps. Undgå scenarier, hvor du skal betale tilbagevendende omkostninger for masser af funktionalitet, som dine forretningsinteressenter aldrig vil bruge.
• Brug de forudbyggede datamodeller fra Salesforce. Salesforce leverer forhåndsbyggede datamodeller for Salg, Service og en række branchevertikaler. Brug af de datamodeller, der leveres af Salesforce, sikrer, at funktioner i dit system kun defineres en gang (eliminerer redundans og siloer), etablerer en enkelt kilde til sandhed på tværs af hele systemet, gør det nemmere at forstå applikationsdata med analyser, gør det nemmere at bruge Salesforces kunstige intelligenstjenester, der er bygget på forhånd, reducerer vedligeholdelsesomkostninger (ved at reducere tilpasninger, du har brug for at understøtte) og reducerer teknisk gæld.

Det er så enkelt. Som du kan se i mønstrene og anti-mønstrene nedenfor, består anti-mønstrene i at kopiere standardfunktioner i en tilpasset løsning eller bruge mere kompleks teknologi til at levere tilpasninger.

I praksis kan du støde på et scenarie, hvor et tilpasset funktionalitetsmønster ses af forretningsinteressenter som den bedste eller eneste levedygtige måde fremad. I disse situationer er det vigtigt, at du forklarer interessenterne de afvejninger, der er involveret i at vælge denne sti, og derefter dokumenterer beslutningen grundigt, dens begrundelse og dens implementering. Dette er også et område, hvor levering af kerneværdi tidligt og tilpasning over tid kan hjælpe dine interessenter med bedre at forstå den bedste måde frem.

Hvis du vil vide mere om Salesforce-værktøjer, der kan hjælpe dig med at øge vedligeholdelsesmuligheden, kan du se Værktøjer, der er relevante for hensigter.

Teknisk gæld er en naturlig del af ethvert system. I går kan lyddesign blive modmønstre, når teknologi eller forretningsbehov ændres. Måske bliver noget, der er bygget til at udfylde et hul i Salesforce Platform-funktionalitet, pludselig overflødigt med en ny Salesforce-version eller produktlancering. Måske erstatter en mere effektiv eller fleksibel teknologi en teknologi, du allerede har implementeret. Teknisk gæld kan oprettes på mange måder.

En vigtig fordel ved at opbygge applikationer med Salesforce Customer 360 Platform er den bagudkompatibilitet, der er indbygget i platformen. Dette betyder, at nye platformsinovationer kan ændre det mønster, du bør bruge til løsninger, der går fremad, men den daglige funktion af løsninger, du har bygget på tidligere Salesforce-teknologier, vil fortsætte med at fungere. Over tid vil enhver løsning, der er baseret på ældre teknologi, begynde at udgøre risici eller flaskehalse for tilføjelse af nye funktioner i dine apps og nedsætte den generelle løsningstilstand.

Planlægning og udførelse af regelmæssigt arbejde for at håndtere teknisk gæld er vigtigt for at vedligeholde sunde, ukomplicerede designs i en Salesforce-løsning. Hvis du ikke kan planlægge, overvåge og afhjælpe teknisk gæld, er det en sikker måde at oprette et system, der er dårlig arkitekteret.

En måde at minimere den tekniske gæld på er at undgå at indføre den så meget som muligt ved at undgå genveje og ved at foretrække standardfunktionalitet frem for tilpasset funktionalitet. Genveje, som hardcodede værdier, kan være fristende at spare tid på, men på lang sigt skaber de gæld, der skal betales tilbage.

Nøglerne til at håndtere teknisk gæld fra et arkitektonisk perspektiv omfatter:

• Identificering af de faktiske omkostninger eller fordele ved handling kontra manglende handling
• Korrekt vejledning
• Bygning af forenelige løsninger

Vanskeligheden kan være at få interessenter til at tilpasse sig handling. Nogle interessenter kan opfatte igangværende vedligeholdelse som at håndtere "fortidens fejl" eller tage væk fra de funktioner, de ønsker, at deres budget skal understøtte.

Visning af de virkelige forretningseffekter af handling og inaktivitet sammen med tydeligt definerede leverancer og tidslinjer kan hjælpe dine interessenter med at forstå værdien og den relative prioritet ved at håndtere teknisk gæld. Ved konsekvent at udføre arbejdet for at forbinde teknisk gæld med forretningspåvirkninger vil det ikke kun hjælpe dine interessenter med bedre at forstå det arbejde, der skal udføres. Det vil også hjælpe dig med at sikre, at du identificerer og håndterer teknisk gæld på måder, der virkelig gavner brugerne.

Listen over mønstre og modmønstre nedenfor viser, hvordan korrekt (og dårlig) teknisk gældsstyring ser ud for en Salesforce-organisation.

Hvis du vil vide mere om Salesforce-værktøjer, der kan hjælpe dig med teknisk gæld, kan du se Værktøjer, der er relevante for hensigter.

Følgende tabel viser et udvalg af mønstre, der skal søges efter (eller opbygges) i din organisation, og anti-mønstre, der skal undgås eller målrettes for rettelse.

✨ Oplev flere mønstre til vedligeholdelse i Pattern & Anti-Pattern Explorer.

Kernen i begrebet læselighed handler om at skabe ensartethed, der gør det nemt for folk at forstå, hvordan tingene fungerer. Opbygning af læsbare systemer justerer leverings- og vedligeholdelsesteams og hjælper personer, der ikke er bekendte med systemet, med hurtigt at forstå, hvordan dele passer sammen. Det betyder, at dit team kan være mindre afhængigt af enkeltpersoner med institutionel eller historisk Knowledge for effektivt at introducere leverandører eller nye teammedlemmer. Det betyder, at dygtige personer i et team kan fokusere på kvaliteten og afvejningerne af de foretagede valg, fordi systemets konfiguration og kode er nemme for mennesker at læse og forstå. Læselighed kan sætte fart på styrings- og kvalitetssikringsprocesser og hjælpe teams med bedre at identificere, hvornår de muligvis opretter overflødige tilpasninger. Det kan også øge chancerne for at have et system, der fungerer på måder, der kan genbruges og testes.

Du kan øge læsbarheden via effektive designstandarder og dokumentation.

Designstandarder giver vejledning til at holde alle tilpasninger ensartede, selv i de tidligste udviklingsfaser. Designstandarder fungerer som vagtstænger og holder alle leveringsteams og vedligeholdelsesteams, der arbejder på dit system, i overensstemmelse med, hvordan tilpasninger skal tilgås og implementeres. Definering af designstandarder hjælper med til at øge produktiviteten hos dine leverings- og vedligeholdelsesteam, gør det nemmere at udføre kode- og arkitektoniske gennemgange og giver grundlag for bedre dokumentation.

Uden designstandarder er det mere sandsynligt, at teams arbejder i siloer. Uden den sammenhæng, som designstandarder leverer, vil forretninger have problemer med at:

• Leverandører og udviklingsteams, der anvender ad hoc-mønstre og tilgange på tværs af løsninger, hvilket potentielt indfører anti-mønstre og reducerer genanvendeligheden (se Separation of Concerns).
• Øget tid til at løse produktionsproblemer og supportteams, der kræves for at introducere nye teammedlemmer og hjælpe dem med at forstå et uensartet sæt af mønstre og tilgange.
• Dårligt krydsteamsamarbejde, redundans i arbejde på tværs af teams, tabt tid på at løse konflikter og fejl, der blev fundet under integrationstest.
• Øget frustration og højere omsætningsfrekvenser.

En vigtig fordel ved designstandarder stammer fra de samtaler og beslutninger, som interessenter skal træffe for at oprette dem. Specifikt giver processen dine forretnings- og teknologiemner mulighed for at justere, hvordan optimalt design ser ud for din forretning.

Medtag følgende i dine designstandarder

• Navngivningskonventioner for Salesforce-metadata. Definer et sæt konventioner for, hvordan hver tilpasning i et system skal navngives. Gode navnekonventioner gennemtvinger ikke kun ensartethed på tværs af navnene på objekter, felter, kode, forløb og andre elementer i dit system. Gode navnekonventioner hjælper også udviklingsteams med at bruge navne, der overfører oplysninger om formålet og funktionaliteten af det, de opbygger. Som resultat kan andre interessenter bedre forstå en bestemt tilpasning ved blot at se dens navn.
• Godkendte designmønstre og anvendelsessituationer. Opret et bibliotek i Pattern & Anti-Pattern Explorer sammen med nøgleoplysninger om, hvornår (og hvornår ikke) at bruge hvert mønster. Biblioteket kan indeholde krævede Apex-udløsermønstre eller forløbsorkestreringsmønstre baseret på den ønskede komponerbarhed i dit system.
• Udviklingsmiljø og værktøjsvejledning. Vedligehold en tydelig liste over de værktøjer, som udviklingsteams skal bruge til deres arbejde. Dette kan inkludere godkendte værktøjskæder og sprog for alle, der skriver kode, eller deklarative funktioner, der er (eller ikke er) godkendt til udvikling med lav kode. Dine standarder kan inkludere en liste over kildekontrolsystemer til tilpasning og dokumentation og påkrævede ind-/udcheckningstrin. De kan også inkludere en liste over miljøer, der skal bruges til forskellige typer udviklingsarbejde.

Sammen med definition af disse standarder skal du beslutte, hvordan og hvor du vil vedligeholde og lagre dem. Hvis teams på tværs af dit firma ikke kan finde dine designstandarder (eller ikke engang er klar over, at de findes), vil de ikke være effektive. Ideelt vil dine designstandarder fungere i samme system som din dokumentation (se næste afsnit for at få flere oplysninger).

Listen over mønstre og anti-mønstre nedenfor viser, hvordan rigtige (og dårlige) designstandarder ser ud for en Salesforce-organisation. Du kan bruge disse til at validere eller forbedre dine designstandarder.

Hvis du vil vide mere om Salesforce-værktøjer, der kan hjælpe dig med at definere designstandarder, kan du se Værktøjer, der er relevante for hensigter.

Dokumentationen forklarer hvad, hvordan og hvorfor i dit system. Uden meningsfuld og ensartet dokumentation bruger teams meget tid på at forstå systemet, som det er (og potentielt misforstå funktioner og tilpasninger).

God dokumentation kræver tid at oprette. Selvom de fleste teams er enige om, at dokumentation er vigtigt for store projekter, kan det være et fristende trin at springe over, når du foretager hurtige ændringer som konfigurationsopdateringer eller mindre justeringer af en automatisering. Ikke at dokumentere de ændringer, du foretager i dit system, er altid et modmønster. Ignorering af dokumentation kan spare en lille mængde tid på forhånd, men mængden af tid, der kræves for at fejlfinde en organisation, der ikke er korrekt dokumenteret, vil mere end annullere disse tidsbesparelser. Inkluder altid nok tid til at oprette dokumentation i alle dine estimater, uanset niveauet af indsats, der kræves for de opdateringer, du planlægger at foretage.

Manglen på tydelig dokumentation kan føre til en række problemer, herunder:

• Udviklingscyklusser, der er brugt på omarbejdning af eksisterende implementeringer
• Gentagende diskussioner, der gentager eller forvirrer over tidligere beslutninger
• Længere introduktion for nye teammedlemmer eller leverandører
• Overafhængighed af personer med institutionel eller historisk Knowledge
• Overflødige arkitekturer til at understøtte de samme eller lignende funktioner på tværs af forretningen
• Problemer med at kommunikere formålet og værdien af din løsning til vigtige interessenter

For Salesforce-løsninger skal du vedligeholde dokumentation for:

• Løsningsoversigter. Diagrammer gør det muligt for dig og dine interessenter at visualisere løsninger på forskellige detaljeniveauer. Salesforce-diagrammestrukturen hjælper dig med at oprette diagrammer, der viser forretningsfunktionerne for løsninger samt tekniske implementeringsdetaljer.
• Beslutningsregistreringer. Hold en registrering over de overvejede indstillinger, afvejninger, endelige beslutninger og argumenter på et centralt sted, som alle teammedlemmer har adgang til til fremtidig reference.
• Kode. Kodeformatet i sig selv er et vigtigt dokument, og dette kan (og bør) matche dine designstandarder. Du ønsker også at have en log over nøgleoplysninger og opdatere den med hver ændring af et kodestykke. For alle klasser, udløsere og komponenter skal du dokumentere følgende:
  • Hvem der oprettede koden
  • Hvornår koden blev skrevet
  • Hvad koden skal gøre
  • Nøgleafhængigheder
  • Alle ændringer
• Declarative tilpasning. For enhver tilpasning, der kan foretages af metadataene i din organisation, leverer Salesforce indbyggede attributter til teams for at give nyttige oplysninger om formålet og hensigten med metadataene. Som en del af dine designstandarder skal du inkludere, hvordan teams skal bruge disse indbyggede funktioner, og hvordan de skal navngive deklarative tilpasninger. Vedligehold også en log over nøgleoplysninger, der er identiske med det, du bruger til kode.

Udvikle et sæt dokumentationsstandarder for at sikre, at alle nuværende og fremtidige teammedlemmer kan fortolke dokumenter på samme måde (designstandarder kan hjælpe med dette). Det er også vigtigt at overveje, hvordan brugere vil kunne søge i dokumentation for at finde relevante afsnit eller udtryk. Efterhånden som dit system bliver ældre og bliver mere kompleks, vokser dokumentationen også. Brugervenligheden af oplysningerne i din dokumentation vil være direkte relateret til, hvor ofte, hvor hurtigt og hvor nemt brugere kan søge efter og finde relevante elementer.

Listen over mønstre og anti-mønstre nedenfor viser, hvordan korrekt (og dårlig) dokumentation ser ud for en Salesforce-organisation. Du kan bruge disse til at validere eller forbedre din dokumentationsstrategi.

Hvis du vil vide mere om Salesforce-dokumentværktøjer, kan du se Værktøjer, der er relevante for hensigter.

Følgende tabel viser et udvalg af mønstre, der skal søges efter (eller opbygges) i din organisation, og anti-mønstre, der skal undgås eller målrettes for rettelse.

✨ Oplev flere mønstre til læsbarhed i Pattern & Anti-Pattern Explorer.

Hjælp os med at holde Salesforce Well-Architected relevant for dig. Tag vores undersøgelse for at give feedback om dette indhold og fortæl os, hvad du gerne vil se som det næste.