Les om våre oppdateringsplaner heri.

Hensiktsmessige løsninger gir forretningsverdi umiddelbart og over tid. Hensiktsarkitekturer planlegges og leveres strategisk, kan vedlikeholdes effektivt og er enkle for mennesker å lese og forstå.

Funksjoner og rettelser prioriteres og leveres på måter som er transparente for både forretnings- og teknologileverandører. Tekniske valg oppretter implementeringer som er enkle for levering og vedlikeholdsteam å arbeide med, uten tilleggsfunksjoner eller komplikasjoner. Hensiktsarkitekturer er enklere å eie, vedlikeholde og utvikle med virksomheten fordi de følger tydelige og konsistente implementeringsmønstre. Byggere kan tolke og implementere utforminger for nye funksjoner, og vedlikeholdsteam kan forstå dokumentasjon av hva som er implementert.

Du kan opprette mer hensiktsmessige systemer ved å fokusere på tre nøkkelområder: strategi, vedlikehold og lesbarhet.

Strategi i arkitektur betyr at systemer planlegges og leveres med omtanke. Det betyr at leveringsteam og vedlikeholdsteam har en klar oversikt over arbeidet som skal gjøres i dag og i fremtiden, og alle er i samsvar med "hvorfor" arbeidet skal gjøres. Det betyr at hasteforespørsler kan sorteres effektivt og effektivt, og interessenter kan tydelig forstå innvirkningen og avveiningene av forespørsler.

Du kan bygge en tydeligere strategi i arkitekturen ved å fokusere på prioritering, veikart og styring.

Prioritering betyr å planlegge rekkefølgen og omfanget av arbeidet du vil levere. Prioritering involverer å forstå den sanne innvirkningen av leveringer på virksomheten, evaluere disse innvirkningene mot andre arbeidsforespørsler og den generelle veikartet for produktet eller programmet.

En måte å evaluere innvirkningen av et gitt arbeidselement på, er å se på den faktiske kostnaden eller fordelen for virksomheten. Når du har identifisert KPI-ene for automatiseringen, kan du bruke et beregningsregneark til å evaluere den generelle kostnaden eller fordelene med implementeringen. Disse beregningene kan hjelpe deg å få justering og innkjøp fra interessentene om hvilke automatiseringer som skal bygges og i hvilken rekkefølge. De kan også hjelpe deg å identifisere automatiseringer som skal utsettes eller unngås. Hvis du vil vite mer om automatiseringer, kan du se prosessutforming for å finne ut mer om å identifisere effektivt arbeid.

Å etablere et prioritetsrammeverk for levering vil også hjelpe deg og vedlikeholdsteamene med å håndtere brukerforventninger og holde seg på linje med veikartet.

Nogle overvejelser, du kan bruge til prioritering, er:

• Forretningsinnvirkningen (kostnad/fordel) av det kan leveres
• Mengden nytt arbeid som kreves for det leverbare
• Mengden arbeid som kreves for å vedlikeholde det kan leveres

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) prioritering ser ut når det gjelder Salesforce-arbeid. Du kan bruke disse til å validere implementeringsplanene eller identifisere hvor du trenger å identifisere prioriteringer bedre før du bygger.

Hvis du vil vite mer om verktøy som er tilgjengelig fra Salesforce for hjelp med prioritering, kan du se Verktøy som er relevante for hensikt.

Et veikart er en prioritert, validert, veldefinert visning av hva som skal gjøres. Effektive veikart gir et tydelig bilde av forretningsinnvirkningen og teknologiinnvirkningen av arbeidet frem i tid. Engasjement av forretnings- og tekniske interessenter er en viktig del av veikartet. Med veikart kan du få tilbakemeldinger og kjøpe inn om tilnærmingen og utfallene før noe arbeid starter. I siste instans justerer veikart alle interessenter om hvorfor arbeidet skal gå fremover.

Hvis teamet bruker en etterslep, er det viktig å forstå at veikartet ikke er et sammendrag eller en liste over elementene i etterslepsloggen. Relasjonen er det motsatte: Elementer er bare å legge inn i etterslepsloggen hvis de tydelig og troverdig kan knyttes til en leveringsform på veikartet. Veikart av høy kvalitet, opprettet med engasjement fra interessenter, gir levering og vedlikeholdsteam en tydelig oversikt over hva de bør fokusere på og hvordan de skal prioritere forespørsler, noe som gjør det enklere å sortere ut motstridende forespørsler og behandle interessenters forventninger.

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

• manglende klarhet når nye funksjoner og funksjonalitet blir tilgjengelig
• Konflikt mellom prioriteringer blant interessenter
• En frakobling mellom løsningene som leveres, og den generelle organisasjonsvisjonen
• Vanskelighet med å forstå hva slags arbeid som pågår
• Ujevne arbeidsbelastninger på tvers av team
• manglende synlighet av relasjoner og avhengigheter mellom arbeidselementer
• Midlertidig stansede implementeringer på grunn av feil administrerte avhengigheter

Interessenter trenger ofte informasjon som er i samsvar med rollene sine, for å ta beslutninger. Opprettelse av effektive veikart krever en klar forståelse av målgruppen og typen informasjon de trenger. Veikart er kategorisert i to stiler for å støtte forretnings- og tekniske målgrupper. Hver stil inneholder to nivåer med detaljer for å støtte forskjellige typer informasjon.

Forretningsvejskart hjælper interessenter med at planlægge for organisationsændring, udnytte vækstmuligheder og forblive på linje med virksomhedsmålene. Forretningsveikart gir også en måte å sikre at IT-utgifter er i samsvar med den generelle forretningsvisjonen.

• Opprett et veikart for forretningskapasitet for å vise ledende interessenter hvilke funksjoner som skal aktiveres. Denne typen veikart inneholder detaljer på høyere nivå om selve funksjonaliteten og hvordan den er i samsvar med forretningsmålene, som å øke driftseffektiviteten eller lansere en ny produktlinje.
• Opprett en veikart for forretningsfunksjoner for å vise detaljer om en bestemt funksjonalitet og vise dens støttefunksjoner og funksjonalitet når du trenger å hjelpe forretningsinteressenter med ressursplanlegging, budsjettering og endringsbehandling.

Teknologireiser hjelper tekniske interessenter med planlegging av budsjett og ressurstildeling. De hjelper også implementeringsteam med å forstå hvor prosjektene deres passer som en del av et større samlet bilde, og identifisere eventuelle avhengigheter på tvers av team.

• Opprett et teknologisystemkjørekort for å vise de spesifikke systemene som skal implementeres, sammen med eventuelle avhengigheter på systemnivå. Denne typen veikart viser systeminformasjon på høyt nivå og justeringen mellom systemer og forretningsmuligheter.
• Opprett en teknologikomponentplan for å vise detaljer om de spesifikke komponentene i et system som skal distribueres for å bidra til ressursplanlegging og aktiveringskrav. Denne typen veikart viser informasjon på komponentnivå og implementeringskrav (for eksempel deklarativ utvikling, pro-kode og så videre).

Forsikre deg om at veikartene inneholder realistiske tidslinjer. En vanlig feil er å inkludere bare hvor lang tid det tar å implementere et system, uten også å vurdere hvor lang tid det tar å fullføre relaterte aktiviteter. Dette kan føre til overfordeling av implementeringsteammedlemmer og lengre forsinkelser enn forventet. Når du oppretter et veikart, må du ta hensyn til hvor lang tid det tar å fullføre følgende:

• Dokumentasjon av all ny og oppdatert funksjonalitet
• Vedlikehold av eksisterende funksjonalitet som er nødvendig for å støtte nye funksjoner
• oppdateringer til relaterte systemer som kreves for å støtte integrasjoner
• Økt støtte fra prosjektteam umiddelbart etter aktivering
• Testing, opplæring og endringsbehandling

Forretnings- og teknologiruteplaner som er godt tilpasset, kommuniserer en helhetlig oversikt over når funksjonalitet vil komme i bruk og hvilken teknologi som ligger bak den. Listen over mønstre og motmønstre nedenfor viser hvordan riktige (og dårlige) veikart ser ut for en Salesforce-organisasjon. Du kan bruke disse til å validere eller forbedre veikartplanleggingsstrategien.

Hvis du vil vite mer om Salesforce-verktøy som kan hjelpe deg med veikarting, kan du se Verktøy som er relevante for hensikt.

Styring er strukturen du bruker til å håndtere prioritering, beslutningstaking og endringsbehandling med interessentene. Styring gjør det klart hvordan beslutninger tas og kommuniseres. Den gir konsistente måter for tilbakemeldinger og forespørsler å komme inn i beslutningsprosessen på, og for at alle interessenter skal kunne forstå status for vedlikeholds- og utviklingsarbeid. Styring bidrar til at ledelsesprosesser blir tydelige og konsistente, og hjelper alle teammedlemmer med å forstå sine roller og ansvarsområder.

Uten riktig styring vil team oppleve en rekke problemer, inkludert:

• Forespørsler om overlappende funksjoner og funksjonalitet ankommer ad hoc
• Implementeringsteam prioriterer "enkler" innsats eller forespørsler fra interessenter med større innflytelse, uten riktig vurdering av forretningsverdi, avveininger eller generelle organisasjonsmål
• manglende konsistente godkjennings- og gjennomgangsprosesser
• Inkonsistente utgivelseskadenser og kvalitet
• Høye defektfrekvenser, overskrivinger, konflikter og overflødig arbeid i utviklingsarbeid

Kanskje det tydeligste tegnet på at et system ikke har effektiv styring, er trege og omfattende utgivelser. Det er viktig å erkjenne at størrelsen på et styringssystem ikke er et mål for dets effektivitet. Utvidede systemer for styring (som de som finnes i mange store virksomheter) kan faktisk redusere hastigheten og frekvensen av utgivelser.

God forvaltning handler om å gjøre det vanskelig for dårlige tilpassinger å komme forbi de tidlige fasene i utviklingen, og å få gode tilpassinger inn i produksjonen på en forutsigbar og konsistent måte.

For ofte er styringsarbeidet reaksjonært. De startes eller fordobles når et problem, som overdreven teknisk gjeld, begynner å bli et forretningsproblem. I mange tilfeller er den uheldige reaksjonen at virksomheten "låser ned" utviklingsarbeid og utgivelser, i stedet for å lage effektive designstandarder og bygningsautomatisering for å håndheve disse standardene i utviklerverktøykjeder og kildekontrollsystemer.

Når du bygger rammeverket for Salesforce-styringssystemet, inkluderer du følgende elementer og vurderer å få svar på disse viktige spørsmålene:

• Arbeidsforespørsler. Hvordan kan brukere be om funksjonalitet eller funksjoner? Hvordan rapporteres feil?
• Prioritering og arbeidsplanlegging. Hvem bestemmer hva arbeidsforespørsler betyr? Hvordan blir arbeid omfanget, prioriteres og godtatt eller signert?
• Miljøer og utgivelsesplanlegging. Hva er miljøet under behandling for utvikling, testing og utgivelse? Hvem gjør hva for å klargjøre, oppdatere og gi tilgang? Hvem håndterer distribusjoner og validering? Hvordan og når frigis endringer? Hvordan håndterer du distribusjoner eller miljøer i løpet av en Salesforce-utgivelsessyklus? (Se Livssyklusbehandling for program for å få mer informasjon om dette.)
• Tjenesteeierskap og produksjonsstøtte. Hvem støtter hva? Hvem håndterer "hot-fix"-produksjonsproblemer? Hvordan blir disse elementene testet og utgitt? Hvem er ansvarlig for de generelle sikkerhetsstandardene i organisasjonen?

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) styring ser ut for en Salesforce-organisasjon. Du kan bruke disse til å validere eller forbedre styringsstrategien.

Hvis du vil vite mer om Salesforce-verktøy som er tilgjengelig for styring, kan du se Verktøy som er relevante for hensikt.

Tabellen nedenfor viser et utvalg av mønstre som det skal søkes etter (eller bygges) i organisasjonen, og motmønstre som det skal unngås eller rettes opp mot.

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

Vedlikehold betyr at et system kan holdes i en sunn tilstand, med nye funksjoner flyttet inn og teknisk gjeld flyttet ut av systemet på en regelmessig, forutsigbar basis. Vedlikeholdbare systemer gir teamene mulighet til å levere verdi til virksomheten med forutsigbar hastighet og kvalitet. Vedlikehold av et system avhenger av flere faktorer, inkludert hvor lesbar det er, hvor løskoblet det er og hvor grundig teststrategien er.

Viktigst av alt er at vedlikehold av et system avhenger av hvor enkel utformingen er. Denne delen dekker måter å opprette mer enkle løsningsutforminger på og øke muligheten for vedlikehold.

Du kan bygge løsninger som er enklere å vedlikeholde, ved å fokusere på to nøkler: å bruke standard over tilpasset funksjonalitet og håndtere teknisk gjeld.

Salesforce tilbyr en rekke forhåndsbygde løsninger – Sales Cloud, Service Cloud og mange Salesforce-bransjeløsninger – i tillegg til fleksibiliteten til å opprette egne tilpassede løsninger. De grunnleggende tjenestene som leverer Salesforces egne skyløsninger, er også tilgjengelig for alle tilpassede løsninger som bygger på Salesforce Customer 360 Platform. Bruk de forhåndsbygde tjenestene og løsningene fra Salesforce som et klarert grunnlag for så mange av løsningene som mulig.

Bruk av forhåndsbygde plattformtjenester har to distinkte fordeler. Først får appene dine naturlig nytte av de nyeste Salesforce-innovasjonene med hver utgivelse. Og for det andre kan utviklingsteamene fokusere på å utvide og utdype forretningskapasitetene som leveres av Salesforce-løsningene, i stedet for å håndtere grunnleggende tunge arkitektoniske løft.

Å velge riktig når standardfunksjonalitet skal brukes og når tilpasset funksjonalitet skal bygges, er ikke utfordrende fra et arkitektonisk synspunkt. Nøklene er:

• Å tilpasse plattformen betyr å endre og utvide, ikke kopiere. Når du utformer eller evaluerer arkitekturen, bør du spørre: Finnes dette allerede et sted i Salesforce Platform? Hvis svaret er "Ja, men...[innsette endringer en forretningsinteressent ønsker her...]", bruker du den forhåndsbygde funksjonen i plattformen. Det arkitektoniske arbeidet som skal gjøres, er å identifisere de mest nyttige måtene å konfigurere den forhåndsbygde Salesforce-funksjonen på for å oppfylle forretningens forventninger.
• Ingen tilpassinger er trivielle. Over tid har alle endringer konsekvenser. Hvis du trenger å implementere en tilpasset løsning, kan du redusere den uunngåelige tekniske gjelden systemet vil akkumulere ved å velge å bruke lavkodeteknologi når det er mulig, og ved å opprette komponerbare enheter i implementeringene.
• Vurder bygg-kjøp-spekteret. Salesforce AppExchange er en markedsplass for apper og løsninger for å utvide Salesforce. AppExchange kan levere funksjonalitet uten overhead involvert i å bygge og vedlikeholde en tilpasset løsning. Vurder følgende når du evaluerer AppExchange:
  • Identifiser løsningsfunksjoner og hull. Ideelt sett vil du finne en app som oppfyller alle forretningskravene dine. I virkeligheten kan det hende du ikke finner en perfekt tilpassing. Når du vurderer løsninger, tilordner du funksjonalitet i den potensielle løsningen til en prioritert liste med forretningskrav. Dette vil hjelpe deg med å finne den løsningen som best oppfyller de viktigste kravene dine.
  • Bruk Sandbox-organisasjoner og gratis prøveversjoner. Bruk gratis prøveperioder til å evaluere apper i Sandbox-miljøer og identifisere de som passer best. Finn ut om apper vil kreve at du gjør konfigurasjonsendringer som er i konflikt med den eksisterende konfigurasjonen.
  • Vurder kortsiktige og langsiktige kostnader. Evaluer langsigtede appvedligeholdelsesbesparelser mod de gentagende omkostninger for abonnementsbaserede apps. Unngå scenarier der du må betale gjentakende kostnader for mye funksjonalitet som forretningsinteressentene aldri vil bruke.
• Bruk de forhåndsbygde datamodellene fra Salesforce. Salesforce leverer forhåndsbygde datamodeller for salg, service og en rekke sektorvertikaler. Bruk av datamodellene som leveres av Salesforce, sikrer at funksjonaliteten i systemet bare defineres én gang (eliminerer overflødighet og enstemmighet), etablerer en enkelt sannhetskilde på tvers av hele systemet, gjør det enklere å forstå programdata med analyser, gjør det enklere å bruke Salesforces forhåndsbygde kunstige intelligenstjenester, reduserer vedlikeholdskostnader (ved å redusere tilpassinger du må støtte), og reduserer teknisk gjeld.

Det er så enkelt. Som du kan se i mønstrene og anti-mønstrene nedenfor, går anti-mønstrene ned til å replikere standardfunksjoner i en tilpasset løsning, eller bruke mer kompleks teknologi til å levere tilpassinger.

I praksis kan du støte på et scenario der et tilpasset funksjonalitetsmønster blir sett på av forretningsinteressenter som den beste eller eneste gjennomførbare veien videre. I disse tilfellene er det viktig at du forklarer til interessentene hvilke avveininger som er involvert i å velge denne banen, og deretter grundig dokumenterer du beslutningen, dens begrunnelse og implementeringen. Dette er også et område der levering av kjerneverdi tidlig og tilpassing over tid kan hjelpe interessentene med å bedre forstå den beste veien fremover.

Hvis du vil vite mer om Salesforce-verktøy som kan hjelpe deg med å øke vedlikehold, kan du se Verktøy som er relevante for hensikt.

Teknisk gjeld er en naturlig del av ethvert system. Gårdagens lydutforminger kan bli anti-mønstre når teknologi eller forretningsbehov endres. Kanskje noe som er bygd for å fylle ut et hull i Salesforce Platform-funksjonaliteten, plutselig blir overflødig med en ny Salesforce-utgivelse eller produktoppstart. Kanskje en mer effektiv eller fleksibel teknologi erstatter en teknologi du allerede har implementert. Teknisk gjeld kan opprettes på mange måter.

En viktig fordel ved å bygge programmer med Salesforce Customer 360 Platform er den bakoverkompatibiliteten som er innebygd i plattformen. Det betyr at nye plattforminnovasjoner kan endre mønsteret du bør bruke til løsninger som går fremover, men den daglige funksjonen til løsninger du har bygd på tidligere Salesforce-teknologier, vil fortsatt fungere. Over tid vil en løsning som er basert på eldre teknologi, begynne å utgjøre risikoer eller flaskehalser for å legge til nye funksjoner i appene, og redusere den generelle tilstanden til løsningen.

Planlegging av og gjennomføring av regelmessig arbeid for å løse teknisk gjeld er viktig for å opprettholde sunne, enkle utforminger i en Salesforce-løsning. Å ikke planlegge for, revidere for og rette opp teknisk gjeld er en sikker måte å opprette et system som er dårlig arkitektonisk.

En måte å minimere teknisk gjeld på er å unngå å innføre den så mye som mulig, ved å unngå snarveier og ved å foretrekke standardfunksjonalitet fremfor tilpasset funksjonalitet. Snarveier, som hardkodede verdier, kan være fristende for å spare tid, men på lang sikt skaper de gjeld som må betales tilbake.

Nøklene til å løse teknisk gjeld fra et arkitektonisk perspektiv inkluderer følgende:

• Identifisere den faktiske kostnaden eller fordelene for virksomheten av handling kontra inaktivitet
• Riktig veikart
• Bygge komponerbare løsninger

Vanskeligheten kan være å få interessenter til å ta tiltak. Enkelte interessenter kan oppfatte pågående vedlikehold som å løse "i gårsdagens feil" eller ta fra funksjonene de vil at budsjettet skal støtte.

Å vise de reelle forretningseffektene av handling og inaktivitet sammen med klart definerte resultater og tidslinjer kan hjelpe interessentene med å forstå verdien og den relative prioriteten ved å håndtere teknisk gjeld. Konsekvent arbeid for å knytte teknisk gjeld til forretningseffekter vil ikke bare hjelpe interessentene med å bedre forstå arbeidet som skal gjøres. Det vil også hjelpe deg å sikre at du identifiserer og håndterer teknisk gjeld på måter som virkelig er til nytte for brukerne.

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) teknisk gjeldsbehandling ser ut for en Salesforce-organisasjon.

Hvis du vil vite mer om Salesforce-verktøy som kan hjelpe deg med teknisk gjeld, kan du se Verktøy som er relevante for hensikt.

Tabellen nedenfor viser et utvalg av mønstre som det skal søkes etter (eller bygges) i organisasjonen, og motmønstre som det skal unngås eller rettes opp mot.

✨ Oppdag flere mønstre for vedlikehold i Pattern & Anti-Pattern Explorer.

Kjernen i konseptet med lesbarhet er å skape konsistens som gjør det enkelt for folk å forstå hvordan ting fungerer. Bygging av lesbare systemer justerer levering og vedlikeholdsteam og hjelper personer som ikke er kjent med systemet, raskt å forstå hvordan deler passer sammen. Det betyr at teamet ditt kan være mindre avhengig av enkeltpersoner med institusjonell eller historisk Knowledge for å effektivt sette inn leverandører eller nye teammedlemmer. Det betyr at kvalifiserte personer i et team kan fokusere på kvaliteten og avveiningen av valgene som gjøres, fordi systemets konfigurasjon og kode er enkelt for mennesker å lese og forstå. Lesbarhet kan øke hastigheten på styrings- og kvalitetssikringsprosesser, og hjelpe team med å bedre identifisere når de kan opprette overflødige tilpassinger. Det kan også øke sjansene for å ha et system som fungerer på måter som er gjenbrukbare og testbare.

Du kan øke lesbarheten via effektive designstandarder og dokumentasjon.

Designstandarder gir veiledning for å holde alle tilpassinger konsistente, selv i de tidligste utviklingsstadiene. Utformingsstandarder fungerer som vaktskjermer, og holder alle leveringsteam og vedlikeholdsteam som arbeider på systemet, på linje med hvordan tilpassinger skal tilpasses og implementeres. Definering av designstandarder bidrar til å øke produktiviteten til leverings- og vedlikeholdsteamene, gjør det enklere å utføre kode- og arkitektoniske gjennomganger og gir et grunnlag for bedre dokumentasjon.

Uten utformingsstandarder er det mer sannsynlig at team arbeider i en silo. Uten den sammenheng som designstandarder gir, vil virksomheter få problemer med:

• Leverandører og utviklingsteam som bruker ad hoc-mønstre og tilnærminger på tvers av løsninger, potensielt innføre anti-mønstre og redusere gjenbrukbarhet (se Separation of Concerns).
• Økt tid til å løse produksjonsproblemer og støtteteam som kreves for å introdusere nye teammedlemmer og hjelpe dem med å forstå et mangfoldig sett mønstre og tilnærminger.
• Dårlig samarbeid på tvers av team, overflødig arbeid på tvers av team, tapt tid med å løse konflikter og feil som oppdages under integrasjonstesting.
• Økt frustrasjon og høyere omsetningsgrad.

En viktig fordel med utformingsstandarder kommer fra diskusjonene og beslutningene interessenter må ta for å opprette dem. Spesifikt gir prosessen virksomheten og teknologisalgsemner muligheten til å justere hvordan optimal utforming ser ut for virksomheten.

Inkluder følgende i designstandardene

• Navnekonvensjoner for Salesforce-metadata. Definer et sett konvensjoner for hvordan alle tilpassinger i et system skal navngis. Gode navnekonvensjoner fremtvinger ikke bare konsistens på tvers av navnene på objekter, felt, kode, flyter og andre elementer i systemet. Gode navnekonvensjoner hjelper også utviklingsteam med å bruke navn som overfører informasjon om formålet og funksjonaliteten til det de bygger. Resultatet er at andre interessenter kan forstå en bestemt tilpassing bedre bare ved å se navnet på den.
• godkjente designmønstre og deres brukstilfeller. Opprett et bibliotek med Pattern & Anti-Pattern Explorer, sammen med viktig informasjon om når (og når ikke) å bruke hvert mønster. Biblioteket kan inkludere nødvendige Apex-utløsermønstre eller flytorkestreringsmønstre basert på komposisjonsmuligheten du ønsker i systemet.
• Utviklingsmiljø og verktøyveiledning. Ha en tydelig liste over verktøyene som utviklingsteamene skal bruke til arbeidet sitt. Dette kan inkludere godkjente verktøykjeder og språk for alle som skriver kode, eller deklarative funksjoner som er (eller ikke) godkjent for utvikling med lite kode. Standardene kan inkludere en liste over kildekontrollsystemer for tilpassing og dokumentasjon, og nødvendige inn-/utsjekkingstrinn. De kan også inneholde en liste over miljøer som skal brukes til forskjellige typer utviklingsarbeid.

Ved å definere disse standardene må du bestemme hvordan og hvor du vil vedlikeholde og lagre dem. Hvis team på tvers av firmaet ikke finner utformingsstandardene dine (eller ikke engang er klar over at de finnes), blir de ikke effektive. Ideelt sett vil utformingsstandardene være i samme system som dokumentasjonen (se neste del for å få mer informasjon).

Listen over mønstre og motmønstre nedenfor viser hvordan riktige (og dårlige) designstandarder ser ut for en Salesforce-organisasjon. Du kan bruke disse til å validere eller forbedre utformingsstandardene.

Hvis du vil vite mer om Salesforce-verktøy som kan hjelpe deg å definere designstandarder, kan du se Verktøy som er relevante for hensikt.

Dokumentasjonen forklarer hva, hvordan og hvorfor systemet fungerer. Uten meningsfylt og konsistent dokumentasjon mister team mye tid på å prøve å forstå systemet slik det er (og potensielt misforstå funksjoner og tilpassinger).

Det tar tid å opprette god dokumentasjon. Selv om de fleste team er enige om at dokumentasjon er viktig for store prosjekter, kan det være et fristende trinn å hoppe over når du gjør raske endringer som konfigurasjonsoppdateringer eller mindre endringer i en automatisering. Å ikke dokumentere endringene du gjør i systemet, er alltid et motmønster. Hopp over dokumentasjon kan spare litt tid på forhånd, men tiden det tar å feilsøke en organisasjon som ikke er riktig dokumentert, vil gjøre mer enn å avbryte disse tidsbesparelsene. Inkluder alltid nok tid til å opprette dokumentasjon i alle beregningene, uavhengig av innsatsnivået som kreves for oppdateringene du planlegger å utføre.

Mangelen på tydelig dokumentasjon kan føre til en rekke problemer, inkludert:

• Utviklingssykluser brukt på omarbeidelse av eksisterende implementeringer
• Gjentagende diskusjoner som går tilbake eller forvirrer tidligere beslutninger
• Lengre introduksjon for nye teammedlemmer eller leverandører
• Overavhengighet av enkeltpersoner med institusjonelle eller historiske Knowledge
• Overflødige arkitekturer for å støtte samme eller lignende funksjonalitet på tvers av virksomheten
• Vanskeligheter med å kommunisere formålet med og verdien av løsningen til viktige interessenter

For Salesforce-løsninger vedlikeholder du dokumentasjon for følgende:

• Løsningsoversikter. Diagrammer gjør det mulig for deg og interessentene å visualisere løsninger på ulike detaljnivåer. Salesforce-diagramrammet hjelper deg å opprette diagrammer som viser forretningsfunksjonaliteten til løsninger, i tillegg til tekniske implementeringsdetaljer.
• Beslutningsposter. Hold en oversikt over vurderte alternativer, avveininger, endelige beslutninger og vurderinger på et sentralt sted som alle teammedlemmer har tilgang til for fremtidig referanse.
• Kode. Kodeformatet i seg selv er en viktig del av dokumentasjonen, og dette kan (og bør) være i samsvar med dine designstandarder. Du vil også ha en logg over nøkkelinformasjon og oppdatere den med hver endring av en kodebit. Dokumenter følgende for alle klasser, utløsere og komponenter:
  • hvem som forfattet koden
  • Når koden ble skrevet
  • Hva koden skal gjøre
  • Nøkkelavhengigheter
  • Alle endringer
• Declarative tilpassing. For alle typer tilpassinger som kan gjøres på metadataene i organisasjonen, tilbyr Salesforce innebygde attributter for team for å gi nyttig informasjon om formålet med og hensikten med metadataene. Som en del av utformingsstandardene inkluderer du hvordan team skal bruke disse innebygde funksjonene og hvordan de skal navngi deklarative tilpassinger. Vedlikehold også en logg over nøkkelinformasjon som er identisk med den du bruker til kode.

Utvikle et sett med dokumentasjonsstandarder for å sikre at alle nåværende og fremtidige teammedlemmer kan tolke dokumenter på samme måte. (Designstandarder kan bidra til dette.) Det er også viktig å vurdere hvordan brukere kan søke i dokumentasjon for å finne relevante deler eller termer. Etter hvert som systemet blir eldre og mer komplekst, vil dokumentasjonen også vokse. Nytten av informasjonen i dokumentasjonen din vil være direkte relatert til hvor ofte, hvor raskt og hvor enkelt brukere kan søke etter og finne relevante elementer.

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) dokumentasjon ser ut for en Salesforce-organisasjon. Du kan bruke disse til å validere eller forbedre dokumentasjonsstrategien.

Hvis du vil vite mer om Salesforce-verktøy for dokumentasjon, kan du se Verktøy som er relevante for hensikt.

Tabellen nedenfor viser et utvalg av mønstre som det skal søkes etter (eller bygges) i organisasjonen, og motmønstre som det skal unngås eller rettes opp mot.

✨ Oppdag flere mønstre for lesbarhet i Pattern & Anti-Pattern Explorer.

Hjelp oss å holde Salesforce Well-Architected relevant for deg, ta vår undersøkelse for å gi tilbakemelding om dette innholdet og fortell oss hva du vil se videre.