Resurssien ja kustannusten optimointi

Resurssien optimointi ja kustannusten optimointi toimivat yhdessä, jotta yrityksesi voi saavuttaa maksimiarvon per kustannus. Salesforce hallitsee usean vuokralaisen infrastruktuuria, noudattaa hallintarajoituksia, jotka pitävät sovellusalustan oikeudenmukaisena kaikille vuokralaisille, ja hinnoittelee käyttöoikeuksia lisenssien ja kulutusluottojen avulla. Optimoit palautettavan arvon: kuinka paljon liiketoiminnan lopputulosta kulutetut dollarit ja sovellusalustan kapasiteetin yksiköt palauttavat. Resurssien optimointi on mekanismi: se hyödyntää jo maksamiasi tietoja tehokkaasti. Kustannusten optimointi on lopputulos: se ohjaa kulut tarkoituksella siihen, mikä edistää kilpailukykyä. Tämä pilari käsittelee niitä yhtenä päätöksenä, koska ne ovat kaksi näkymää samasta tavoitteesta.

Tämä arvokohtainen näkymä määrittää kaikki tekemäsi arkkitehtoniset päätökset. Kun ymmärrät omistajuuden kokonaiskustannukset, voit tehdä paremman kompromissin kapasiteetin ja sijoituksen välillä. Sovellat oikeanlaisia ratkaisuja liiketoimintavaatimusten mukaisesti sen sijaan, että ylimääräisesti provisioisit ominaisuuksia, jotka jäävät käyttämättömiksi tai investoit liikaa ominaisuuksiin, jotka nopeuttavat arvonsiirtoa. Lisenssi, kulutushyvitys, API-kutsu ja sandbox-ympäristö ovat kaikki syötteitä samaan yhtälöön. Tärkeintä on jokaisen palauttama arvo, eikä mihin kirjanpitoon se osuu. Kysymys ei ole koskaan "onko tämä kustannus vai resurssi", vaan "tarjoaako tämä syötetty tieto sopivaa tuottoa?"

Tämän pilarin ohittaminen aiheuttaa ennustettavia seurauksia. Yritykset kerääntyvät käyttämättömiä lisenssejä, jotka kuluttavat budjettia, kun taas muut ominaisuudet eivät ole rahoitettuja. Ei-hyödylliset arkkitehtuurit tuhlaavat API-kapasiteettia, tallennustilaa ja kehitysvaikutuksia ongelmiin, joita parempi suunnittelu estää. Resurssien tehottomuus tietyissä yhdisteissä ajan myötä ennustettavilla tavoilla:

Suorituskyky heikkenee, kun datamääriä kasvaa.
Kyselyiden aikakatkaisut ilmestyvät muutamaan sataan tuhanteen tietueeseen, kun ei-valinnaiset kyselyt skannaavat kokonaisia taulukoita.
Heap-rajoituspoikkeukset näytetään, kun ratkaisut noutavat tarpeettomia kenttiä.
CPU aikakatkaistaan, kun monimutkaiset laskutoimet suoritetaan synkronoidusti.
Korjaukset moninkertaistuvat, kun tiimit korjautuvat uuden rajoituksen ympärille.

Jokainen näistä virheistä on sekä luotettavuusongelma että kustannusongelma, koska tuhlattu laskenta kuluttaa kapasiteettia, josta maksat. Tärkeintä on, että tiimit menettävät mahdollisuudet investoida innovaatioihin, koska budjetti ja suunnittelukapasiteetti kulutetaan jätteen sijaan strategisten aloitteiden vuoksi.

Kustannustehokkaat ratkaisut maksimoivat arvon seuraavasti:

Käyttämällä jo ostettuja sovellusalustan ominaisuuksia
Oikean koon lisenssien ja kulutuksen tasaaminen todelliseen käyttöön
Kokonaiskustannusten mallinnus ennen lähestymistapaan sitouttamista
Kulutuksen jatkuva valvonta liiketoiminnan lopputulosten perusteella

Nämä käytännöt ovat yhdistelmä. Tiimit, jotka lisäävät suunnitteluunsa tietoisuutta kustannuksista ja resurssitehokkuudesta, tarjoavat enemmän kapasiteettia per dollari kuin tiimit, jotka käsittelevät optimointia siivoustyönä, kun kulutus on jo kasvanut.

Resurssien ja kustannusten optimointi muodostaa yhteyden muihin rakenteellisiin pilareihin suoraan. Operational Excellence vähentää jatkuvia kustannuksia automaatiolla, joka vähentää manuaalista vaivaa. Luotettavuus ja Trust oikeuttavat premium-investointeja liiketoiminnan jatkuvuuden ja säännösten noudattamisen ansiosta. Yhdessä nämä pilarit auttavat yrityksiä sijoittamaan luottavaisesti, koska niiden arkkitehtuuri tuottaa eniten tuottoa.

Käytä näitä periaatteita opastaaksesi resurssien ja kustannusten optimointia koskevia arkkitehtonisia päätöksiä alustalla.

Optimoi omistajuuden kokonaiskustannukset. Omistuksen kokonaiskustannukset (TCO) ulottuvat tilausmaksujen lisäksi kulutusluottoihin, toteutuskustannuksiin, toimintakustannuksiin, integrointikustannuksiin ja muutostenhallintatyöhön. Arvioi päätöksiä käyttämällä TCO-analyysiä nähdäksesi kokonaiskuvan sijoituksista ratkaisun elinkaarelta. Joskus korkeampi ennakkoinvestointi vähentää käynnissä olevia liiketoimintakustannuksia merkittävästi, ja TCO-analyysi aiheuttaa kompromisseja. Optimoi pitkäaikainen arvo, älä lyhytaikaisten kustannusten minimointi.
Sovita kulut liiketoiminta-arvoon. Yhdistä kaikki Salesforce-investoinnit mitattavissa olevaan lopputulokseen. Lisenssien käyttö mahdollistaa käyttäjien tuottavuuden, jota mitataan sopeutumisen ja tehtävien suorittamisen kautta. Data 360 -investoinnit tukevat päätöksentekoa, jota mitataan muunnoksen ja asiakkaan elinkaaren arvon perusteella. Sandbox-kustannukset rahoittavat kehitysnopeutta, joka mitataan käyttöönoton yleisyyden ja laadun perusteella. Kun kuluttaminen vastaa arvoa, sijoitat luottavaisesti menestymiseen ja tunnistat kulut, jotka eivät enää tuota tuottoa.
Suunnittele sovellusalustan rajoitusten sisällä. Hallintarajoitukset määrittävät, mitä ratkaisu voi käsitellä per transaktio. Käsittele niitä suunnittelurajoituksina alusta alkaen, äläkä esteinä, joita sinun kannattaa välttyä. Suunnittele transaktioita, jotka toimivat kätevästi enimmäiskuormituksen ja datan enimmäismäärien rajoissa, ja luo marginaali tuleville ominaisuuksille, muille asennetuille paketeille ja odottamattomille datakuvioille. Suunnitelman rajoissa suunniteltujen ratkaisujen suorituskyky on ennustettavissa ja vältyt hätätilanteiden refaktoroinnilta myöhemmin.
Optimoi jo maksamasi resurssit. Ennen kuin ostat kapasiteettia, maksimoi jo provisioitujen sovellusalustan resurssien läpimeno, tehokkuus ja arvo. Tehokkaat kyselyt, tietueiden käsittely joukkona (bulkkaaminen), välimuistiin tallentaminen ja kurinalainen datan elinkaari vähentävät ratkaisun laskenta-, tallennus- ja API-kulutusta. Tämä resurssitehokkuus on mekanismi, joka edistää kestävän kehityksen kustannusten optimointia: Provisioiduista resursseista poistettu jäte parantaa suorituskykyä ja pitkäaikaista kokonaiskustannuksia.
Oikean kokoinen lisenssi ja kulutus todelliseen käyttöön. Täsmää käyttäjät heidän työnsä vaatimaan lisenssityyppiin ja suunnittele automatisointeja ja agentteja kutsumaan mitattuja palveluita tehokkaasti. Ylisenssit ja valvomat kulutuksen krediitit ovat yleisimpiä ja kalliimpia jätteen lähteitä. Roolien, sisäänkirjautumistoimintojen ja ominaisuuksien käytön säännölliset auditoinnit ja luotonpolttoa koskeva selkeä näkyvyys pitävät kulutukseen perustuvat kustannukset ennustettavissa.
Luo taloushallinto ja kustannustietoinen kulttuuri. Hallitse Salesforcen menoja strategisena sijoituksena aktiivisen valvonnan ja jaetun vastuun avulla. Taloushallinta tuo kustannus-hyöty-analyysin suunnittelupäätöihin sen sijaan, että se löytäisi kustannukset käyttöönoton jälkeen. Kustannusten tietoisuus on yhteinen vastuu liiketoiminnan sidosryhmille, arkkitehdeille ja kehittäjille, jotka punnitsevat kustannusvaikutuksia toiminnallisten vaatimusten rinnalla, joten älykkäät sijoituspäätökset tehdään kaikilla tasoilla ilman keskitettyjä pullonkaulakohteita.
Käytä jatkuvaa optimointia. Optimointi on jatkuva käytäntö, ei kertaluonteinen. Valvo kulutusta ja resurssien kulutusta mittaristojen avulla, jotka ovat teknisten ja liiketoiminnan sidosryhmien käytettävissä. Määritä hälytyksiä, jotka käynnistyvät, kun kulutuskulutuksen kynnysarvot saavutetaan ennen kuin kulutusta ei havaita. Säännölliset tarkastukset paljastavat jäte, joka kerääntyy asteittain, vahvistavat, että aiemmat optimointiinvestoinnit ovat tuottaneet odotetun tuotonsa, ja paljastavat uusia mahdollisuuksia liiketoimintaprioriteettien ja datamäärien muuttuessa.

Salesforcen toimintojen ymmärtäminen auttaa sinua keskittymään optimointiin sen perusteella, mitä hallitset. Sovellusalusta käsittelee infrastruktuuritason resurssien hallinnan, joka vaatii erityisiä tiimejä perinteisissä IT-ympäristöissä:

Multitenant-resurssien allokointi: Salesforce varmistaa oikeudenmukaisen CPU-, muisti- ja tietokantayhteyksien jakamisen kaikille asiakkaille jaetussa infrastruktuurissa, valvoo vuokralaisten kulutusta ja noudattaa rajoituksia, jotka estävät yksittäisiä vuokralaisia heikentämästä muiden suorituskykyä.
Governor limit -arkkitehtuuri: Sovellusalustan käyttöönotetut rajat (100 SOQL-kyselyä per synkronoitu transaktio, 10 sekuntia CPU-aikaa, 6 Mt joukkokokoa) suojaavat kaikki vuokralaiset resurssien väsymiseltä. Salesforce kalibroi nämä rajoitukset usean palveluntarjoajan infrastruktuurin kapasiteettiin. Nämä rajoitukset ovat arkkitehtuurirajoituksia, eivät satunnaisia rajoituksia.
Kyselyiden optimointi ja suoritusjärjestelmä: Salesforcen kyselyiden optimointi luo suoritussuunnitelmia, ylläpitää datan jakauman tilastoja ja valitsee optimaaliset kyselypolut. Sovellusalustan hallitsemat vakiokenttien indeksit nopeuttavat yleisimpiä kyselykuvioita, ja optimointi sopeutuu datamäärän muutoksiin automaattisesti.
Infrastruktuurin skaalaus: Salesforce provisioi laitteistokapasiteetin, hallitsee tietokantaklustereita, jakaa latauksia ja skaalaa infrastruktuuria, kun käyttö kasvaa. Et koskaan provisioi palvelimia, hallitse tietokannan replikointia tai määritä kuormituksen tasaajia.
Sovellusalustan suorituskyvyn optimointi: Salesforce optimoi jatkuvasti sovellusalustan ydinkodin, kyselyiden suorituskyvyn, API-vastausajat ja käyttöliittymän kehysjärjestelmän suorituskyvyn ja tarjoaa infrastruktuurin parannuksia säännöllisillä julkaisuillaan ilman, että asiakkaat tarvitsevat toimia.

Salesforce hallitsee myös sovellusalustan kaupallista osaa, minkä vuoksi lisensointi ja kulutus kuuluvat samaan pilariin kuin laskenta ja tallennus. Sovellusalusta määrittää Edition-versiot, lisenssityypit, lisäosat ja kulutusluottomallit, joiden kautta kapasiteetti ostetaan, ja mittaa käyttöä, joka vähentää luottoja. Et määritä näitä hintoja enempää kuin tarjoat palvelimia, mutta päätät kuluttamasi hinnat: mitä lisenssejä kullakin käyttäjällä on, kuinka tehokkaasti automaatio kutsuu mitattua palvelua ja kuinka monta sandboxia pysyy aktiivisena.

Nämä sovellusalustan toiminnot ovat perustasi. Koska Salesforce hallitsee sekä infrastruktuuria että hinnoittelumallia, optimointitoimesi keskittyy kokonaan niiden perusteella tekemäsi arkkitehtonisiin päätöksiin: kuinka tehokkaasti käytät sinulle tarjottuja resursseja ja miten tarkoituksellisesti ohjaat niihin liittyviä kuluja.

Jaetun vastuun malli tarkoittaa, että omistat resurssitehokkuuden kaikille Salesforcessa luomillesi kohteille. Sovellusalustan resurssien hallinta tukee töitäsi, mutta se ei korvaa optimointitarpeitasi. Tehokas ratkaisu palauttaa enemmän liiketoiminta-arvoa jo maksamastasi laskenta-, tallennus- ja API-kapasiteeteista, ja se on mekanismi, joka pitää kustannusten optimoinnin kestävänä kertaluonteisen budjetin vähentämisen sijaan. Jätelaskenta sen sijaan kuluttaa infrastruktuuriresursseja ilman liiketoiminta-arvoa ja sen kustannusyhdistelmät. Suorituskyky heikkenee ennustettavasti, kun datamääriä kasvaa, ja ratkaisut moninkertaistuvat, kun tiimit korjaavat rajoituksia, joita he olisivat voineet suunnitella.

Optimointitehtäväsi kattavat neljä toisiinsa liittyvää aluetta: suorituskyky, koodin organisointi, pakkaaminen ja data. Jokainen on hintakohtainen päätös ennen teknistä päätöstä. Tässä osiossa kerrotaan, miten tehdä kyseinen päätös ja miksi se on tärkeää. Tässä osiossa viitatut tarkat toteutusreseptit, kooditasomallit, määritysnavigointi ja tiettyjen säätöjen kynnysarvot löytyvät Resurssien ja kustannusten optimoinnin kuvioiden kirjastosta.

Suorituskyvyn optimointi alkaa hallintorajoituksiin liittyvällä muutoksella. Ne eivät ole esteitä, joita sinun tulisi välttyä. Ne ovat arkkitehtonisia rajoituksia, jotka, kun ne otetaan käyttöön alustavasta suunnittelusta, tuottavat ratkaisuja, joilla on ennustettavia suorituskykyominaisuuksia. Jokainen transaktio suoritetaan tietyissä rajoissa, ja nämä rajat ovat olemassa, jotta resurssien oikeudenmukainen jakaminen voidaan noudattaa kaikkien sovellusalustan vuokralaisten kesken. Apex, joka kuluttaa 95 sen 100 sallitusta SOQL-kyselystä, ei jätä marginaalia tuleville ominaisuuksille, muiden tiimien lisäämille käynnistimille tai odottamattomille datakuvioille. Arkkitehdit, jotka pitävät transaktiot alle puolet rajoituksesta, rakentavat ratkaisuja, jotka voivat kasvaa ilman hätätilanteita, kun rajoitus on tyhjennetty. Tavoitteena on suunnitella rajoitukset hyvin ruuhka-aikojen aikana ja datan enimmäismäärällä, jotta ominaisuuden tai toisen paketin automatisoinnin lisääminen ei koskaan työnnä transaktiota reunan ylle. Yleinen, kallis virhe: ratkaisu toimii täydellisesti 10 tietueelle Developer Sandboxissa, mutta saavuttaa hallintarajoitukset tuotantoympäristössä. Developer-sandboxit kopioivat vain kokoonpanon eivätkä sisällä mitään dataa. Todellisten määrien testaaminen Full Copy -sandboxissa aiheuttaa skaalattavuusongelmia ennen kuin asiakkaat tekevät niin.

Kyselyiden valikoivuus on yksi suurimmista osatekijöistä, kun ratkaisu skaalaa miljooniin tietueisiin tai aikakatkaistaan satoihin tuhanteen. Valinnaiset kyselyt käyttävät indeksejä löytääkseen tietueita tehokkaasti, kun taas ei-valinnaiset kyselyt skannaavat kokonaisia taulukoita, kuluttavat liikaa tietokantaresursseja ja lopulta aikakatkaistaan. Sovellusalusta ylläpitää vakiomuotoisia indeksejä määritetyille kentille ja soveltaa valikoivuusrajoituksia, jotka tiukentuvat, kun objekti ylittää ensimmäisen miljoonan tietueensa. Arkkitehtuuri valikoivuuden vuoksi tarkoittaa indeksoitujen kenttien suodattamista ensisijaisena ehtona ja vahvistusta kyselyn suunnittelutyökalulla ennen kuin se otetaan käyttöön suurille objekteille, koska kysely, joka näyttää raskaan objektin taulukon skannauksen, on tuotantotapahtuma, joka odottaa tapahtumista. Valmius on kapasiteetti, jota sinun ei tarvitse ostaa: tehokas kysely palautetaan millisekunteina ja tietokantaresurssit ovat käytettävissä jokaiselle toiselle vuokralaiselle ja jokaiselle organisaatiosi muulle transaktiolle.

Bulkkaaminen on perustavanlaatuinen skaalattavuuskuvio, joka erottaa skaalatta toimivan Apexin rajoituksista. Anti-pattern — kysely tai silmukan sisään sijoitettu DML-lauseke — toimii oikein pienien tietuejoukkojen kanssa, mutta rikkoo joukkotoiminnon suoritusajankohdan rajoituksia. Korjausvaihtoehto on kysellä kaikkia tarvittavia tietoja silmukoiden ulkopuolella olevissa yksittäisissä lausekkeissa, organisoida tulokset Id-näppäimellä määritettyihin karttoihin nopeuttaaksesi hakua iteroinnin aikana ja käsitellä koko kokoelma erä DML:llä. Suunnittele jokainen automaatio käsittelemään 200-tietuekäynnistimen vakiomuotoinen erä ilman rajoituksia, ja sama koodi skaalaa riippumatta latauksesta tuotantoympäristössä.

Ei-synkronoitu käsittely on olemassa töille, joita ei voi tai ei pitäisi suorittaa käyttäjän transaktion synkronoitujen rajoitusten mukaisesti. Työn siirtäminen asynkroniseen kontekstiin kaksinkertaistaa sen käytettävissä olevat hallintarajoitukset ja estää pitkäaikaisia operaatioita estämästä käyttäjiä. Tämä arvoalue on todellinen, mutta se ei ole ilmainen, ja asynkronointia käytetään aina, kun rajoitus tuntuu olevan lähellä. Asynkronointi on tarkoituksellinen arkkitehtuurinen kompromissi: se tuo käyttöön mahdollisen yhdenmukaisuuden, joten työn tuloksia ei näytetä sen pyytäneessä transaktiossa, mikä pakottaa käyttäjäkokemuksen tekemään päätöksiä, jotka eivät riipu välittömästä vahvistuksesta. Se vaatii erillistä virheiden käsittelyä ja valvontaa, koska virhe ilmestyy työlokiin sen käynnistäneen käyttäjän sijaan. Lisäksi se voi monimutkaistaa järjestelmän henkistä mallia, kun yksi liiketoiminta kattaa useita transaktioita. Arvo-kustannuspohjainen päätös on punnita lisääntynyt monimutkaisuus työn todellisen tarpeen kapasiteettiin ja pitää työt synkronoituina, kun se sopii mukavasti.

Kun asynkronointi on oikea kutsu, mekanismien valinta noudattaa työn muotoa rajoituksen koon sijaan. Erä Apex on tarkoitettu määrälle. Se käsittelee miljoonia tietueita jakamalla ne osioihin, joilla jokaisella on omat itsenäiset hallintarajoituksensa — minkä vuoksi datan siirto, datan arkistointi ja joukkorajaus kuuluvat tähän. Jonotettava on joukolle: se käsittelee monivaiheisia työnkulkuja, jotka ylittävät synkronointirajoitukset, mutta jotka eivät tarvitse eräasteikkoa, ja se tukee yhden työn ketjutusta toisesta vaiheeseen, joka täytyy suorittaa järjestyksessä. Sovellusalustan tapahtumat on tarkoitettu liittämiseen: tuottaja lähettää tapahtuman tietämättä tai odottamatta sen kuluttajia. Käytä tätä kuviota järjestelmien välisille ilmoituksille ja erottamaan töitä, jotka eivät kuulu samaan transaktioon, ottaen huomioon, että vähintään kerran toimitus vaatii paikallisia tilaajia. Tulevat menetelmät kattavat yksinkertaisen asynkronisen työn, jossa on primitiivisiä syötteitä, tavallisesti synkronoidusta käynnistimestä saatu callout. Koska he eivät kykene ketjuttamaan tai hyväksymään monimutkaisia objekteja, he eivät välttämättä ole käyttövalmiita asynkronointityökaluja. Täsmää asynkronointimekanismi työn muotoon. Muussa tapauksessa vaihdat hallintarajoitusten ongelman johdonmukaisuuden ja seurannan kustannusten vuoksi, jotka ovat suurempiä kuin voitto.

Välimuistiin tallentaminen muuntaa toistuvat työt säilyttämääsi kapasiteettiin. Sovellusalustan välimuisti tallentaa sarjanumeroitavaa dataa transaktioiden rajojen yli, joten välimuistin osuma välttää arvon tuottaneen kyselyn tai uudelleenlaskennan suorittamisen uudelleen, mikä vähentää suoraa SOQL- ja CPU-kulutusta. Päätös välimuistin luomisesta tai rikkomisesta riippuu siitä, mitä päätät asettaa siihen ja kuinka kauan. Tallenna välimuistiin tietoja, joita luetaan paljon useammin kuin niitä muutetaan, kuten mukautettu metadata, kokoonpano ja valintaluetteloarvot, ja määritä live-arvo vastaamaan datan volatiliteettia yhden oletusarvon sijaan. Viitetiedot, jotka muuttuvat kuukausittain, voidaan tallentaa turvallisesti välimuistiin tuntikausia, kun taas kokoonpano, joka siirtyy päivän aikana, tarvitsee lyhyen ajanjakson, jotta välimuisti ei koskaan tarjoa vanhentunutta arvoa tarpeeksi pitkään, jotta sillä olisi merkitystä. Liian aggressiivinen välimuisti vaihtaa suorituskyvyn voittamisen oikeellisuusriskin vuoksi, ja välimuisti, jolla on heikko saavutussuhde, kuluttaa tallennustilaa palauttamatta kapasiteettia, minkä vuoksi saavutussuhde on valvottava tilasto eikä oletusasetusta. Osioiden valinta on suojauspäätös: Käytä organisaation osiota tiedoille, jotka on jaettu käyttäjille, käytä istuntoosiota käyttäjille tarkoitetulle datalle, jonka täytyy pysyä erillään, äläkä koskaan aseta henkilötietoja organisaation osioon, jossa kaikki käyttäjät voivat lukea niitä. Lightning Data Service laajentaa saman idean myös asiakkaalle: se jakaa välimuistiin tallennetut tietueet sivun jokaiselle komponentille ja välttää tarpeettomat palvelimen kiertoajelut. Jokainen välimuistin kohde on laskenta- ja API-kapasiteetti, jota sinun ei tarvitse käyttää, kunhan palautettu arvo on edelleen oikein.

Datavirhe on suorituskyvyn hotspot, joka johtuu tietueiden epätasapainoisesta jakautumisesta. Kun yksi ylätason tietue kerää yli 10 000 alitason tietuetta, kyselyn suorituskyky heikkenee ja rivien lukkojen ristiriita ilmenee samanaikaisten toimintojen aikana. Kynnysarvo on suunnittelusignaali, ei kova rajoitus. Se käskee sinua jakamaan kuormituksen useisiin ylätason objekteihin, valvomaan raskaita objekteja ajoitetuilla töillä, jotka ilmoittavat hälytyksestä, kun ylätason objekti lähestyy rajaa, ja lajittelemaan joukkolataukset ylätason tunnuksen perusteella, jotta samanaikaiset erät eivät taistele samoilla riveillä. Omistajuusvirhe, jossa integraatiokäyttäjä omistaa satoja tuhansia tietueita, tuottaa saman lukkojen ristiriidan ja ansaitsee saman kuormituksen jakauman.

Salesforce tarjoaa työkaluja pitääkseen suorituskykyominaisuudet terveinä ratkaisun kehittyessä. Skaalauskeskus tarjoaa transaktiotason näkyvyyden pitkäaikaisiin toimintoihin, rivin lukitsemiseen liittyviin ristiriitoihin ja rajoituksiin lähestyvään transaktioon, ja nimeää sitten kyseisen käynnistimen ja objektin. ApexGuru soveltaa tekoälyn analyysiä tuotantoympäristön suorituksen aikaiseen telemetriaan paljastaakseen anti-kuviot ennen kuin ne saavuttavat skaalan, ja Salesforce Code Analyzer suorittaa staattisen analyysin CI/CD-putkessa, joten rakentaa epäonnistumisen, kun kyselyitä näytetään silmukoissa tai kun muita suorituskykyvirheitä havaitaan. Event Monitoring paljastaa kulutustrendejä tietyltä aikaväliltä ja Proactive Monitoring, joka on allekirjoitusten onnistumissuunnitelman ominaisuus, arvioi organisaatiosi jatkuvasti suorituskyky- ja skaalattavuusriskien varalta.

Koodiorganisaatio on kustannuspäätös, joka ilmaistaan ylläpitokyvyksi. Huolto kuluttaa tavallisesti suurimman osan kehityskapasiteetista kypsälle ratkaisulle, joten valitsemasi rakenne määrittää, kuinka paljon tuleva kapasiteetti muuttuu sen sijaan, että sitä käsitellään uudelleen. Kolme kuviota sisältävät suurimman osan arvosta. Käynnistimen käsittelijäkuvio keskittää käynnistimen logiikan käsittelijäluokkiin ja vähentää itse käynnistimen tiedoston minimaaliseen delegointipisteeseen, mikä pitää logiikan testattavissa käynnistimen asiayhteydestä riippumatta ja tarjoaa rekursioinnin hallinnan yhdellä aloitussivulla. Palvelutasokuvio sisältää liiketoimintalogiikkaa luokissa, jotka paljastavat operaatiot, joita voidaan kutsua käynnistimestä, REST-päätepisteestä, kulun kutsuttavasta tai erätyöstä, joten liiketoimintasääntö toimii yhdessä toteutuksessa sen sijaan, että se kopioituisi jokaiselle syöttöpisteelle, jolloin synkronointi häviää. Valintakuvio keskittää SOQL:n kullekin objektille erillisissä luokissa, mikä tekee kyselyn hienosäätämisestä yhden pisteen muutoksen ja antaa jokaiselle kyselylle selkeän nimetyn tarkoituksen.

Yhdistelmäiset DML-virheet ovat erillinen organisaation riski, jota kannattaa suunnitella erikseen. Ne tapahtuvat, kun yksi transaktio suorittaa DML:n määritysobjekteille, kuten User ja PermissionSet, sekä muille kuin määritysobjekteille, kuten Account ja mukautetut objektit, koska määritysmuutokset, jotka vaikuttavat käyttäjän käyttöoikeuksiin, täytyy sitouttaa erilliseen transaktioon. Virhe ilmenee laajalti integraatiotöissä, testausmäärityksissä ja käyttäjien provisioinnin automatisoinnissa. Arkkitehtuurin korjaustoimenpiteet ovat määritysten ja ei-määritysten DML:n erottaminen transaktioiden rajoista käyttämällä ei-synkronoitua käsittelyä tai sovellusalustan tapahtumia, suunnitellaksesi datamalleja, jotka välttävät näiden kahden toiminnon yhdistämisen yhteen liiketoimintavaiheeseen, ja eristääksesi määritysten DML:n testeistä.

Pakkauksen valinnat määrittävät pitkän aikavälin kehityskulut ja yrityksessä mahdollisesti saavutetun uudelleenkäytön. Toisen sukupolven hallitut paketit tarjoavat lähdekoodiin perustuvaa modulaarista kehitystä nimitilan suojauksella, ja ne ovat oikea valinta AgentExchangesta jaetuille itsenäisen ohjelmiston tarjoajan (ISV) tuotteille. Lukitsemattomat paketit tarjoavat sisäisille tiimeille saman modulaarisuuden ja riippuvuuksien hallinnan ilman nimitilan ylittymistä, mikä soveltuu yrityssovelluksille, jotka tarvitsevat itsenäisen käyttöönoton, mutta eivät markkinapaikkamerkintää. Ensimmäisen sukupolven hallitut paketit ovat edelleen käytössä olemassa olevissa tuotteissa, mutta niillä ei ole lähdekohtaista työnkulkua, joka mahdollistaa uuden modulaarisen kehityksen.

Modulariteetti ulottuu rakentamiisi komponentteihin. Suunnittele Lightning yhden vastuun ympärille selkeillä ominaisuuksien käyttöliittymillä, suosittele koostumusta periytymisen sijaan, jotta monimutkaiset käyttöliittymät on koottu pienistä keskitetyistä komponenteista, ja käytä mukautettuja tapahtumia ylätason viestintään sen sijaan, että ne saataisiin suoraan pääkomponenttiin. Näytä uudelleenkäytettävä Apex kutsuttavina toimintoina, jotta pääkäyttäjät voivat kirjoittaa automatisointia Flow Builderissa kehittäjien luomista ominaisuuksista, mikä vähentää identtisiä tietoja ja luo sillan deklaratiivisille ja ohjelmallisille maailmoille. Hyvin suunniteltu modulaarisuus sallii kyvyn rakentaa kerran ja käyttää sitä uudelleen sen sijaan, että se otettaisiin uudelleen käyttöön ja ylläpidettäisiin erikseen jokaisessa tarvittavassa paikassa.

Ei-hallittu datan kasvu on yleisin lähde suorituskyvyn asteittaiseen heikentymiseen, ja se lisää tallennuskustannuksia ja sandboxien päivitysaikoja rinnakkain. Datan tehokkuutta koskevat kaksi päätöstä. Ensimmäinen on datamallin suunnittelu. Päätiedot–lisätiedot-suhteet tarjoavat vaiheittaisen poistamisen, yhteenvetojen ja datan jakamisen tiiviimmän yhdistämisen kustannuksella. Haut tarjoavat joustavuutta mukautetun yhteenvetologiikan kustannuksella, ja suodatettavien kenttien tarkoituksenmukainen indeksointistrategia pitää kyselyt valikoivina, kun objektit kasvavat. Toinen on datan elinkaari. Määritä koko elinkaari luomisesta arkistointiin sen sijaan, että objektit kerääntyisivät tietueisiin määrittämättömästi, koska objekti, joka kasvaa miljooniksi ilman arkistointistrategiaa, tuottaa lopulta kyselyiden aikakatkaisut, ei-valinnaiset kyselyt ja aikakatkaisut.

Valitse arkistointimenetelmä vasta, kun olet hyväksynyt vaatimustenmukaisuuden. Varmista ennen mekanismin valitsemista, rajoittavatko datan sijainnin, poistamisen oikeuden tai säilyttämisen vaatimukset vaihtoehtojasi. Big-objekteja ei voi muokata lisäämisen jälkeen, mikä tekee arkistoitujen henkilötietojen poistamisesta vain tietueita sisältävän poistotoiminnon, joka voi vaikuttaa kirjausketjuihin. Big-objektit sisältävät suuria historiallisia datajoukkoja tallennustilaan, jotka ovat erillään tavallisista rajoituksista, ja ne soveltuvat suoritettuihin transaktioihin ja kirjauslokeihin, joita ei enää tarvita päivittäisiin töihin. Ulkoinen tallennustila pitää datan kyseltavissa Salesforce Connectin kautta vähentämällä organisaation määrää ja soveltuu joustaviin kyselykuvioihin tai integrointiin yritystietovarastoon. Valvo tallennustilan kulutusta objektitasolla, jotta kasvu näkyy ennen kuin siitä tulee ongelma, käytä Salesforce Files -tiedostoja vanhojen liitteiden sijaan ja määritä kenttien kenttien kirjausketjujen säilyttäminen vaatimustenmukaisuuden vaatimuksiin sen sijaan, että käytettäisiin tyhjää enimmäismäärää, joka tuhlaa tallennustilaa.

Kustannusten optimointi tasapainottaa liiketoiminta-arvon ratkaisun kustannuksiin nähden, ja se riippuu siitä, onko kustannus tarkka. Tee näin ottamalla huomioon kaikki kustannuskomponentit, koska yhden komponentin, kuten lisenssien kustannusten, tarkasteleminen johtaa siihen, että ymmärrät väärin, mitä ratkaisu todellisuudessa maksaa. Lyhyt lisenssimaksu voi piilottaa toteutuksen, toiminnan, integraation ja muutosten kustannukset, jotka aiheuttavat sen. Vain näkyvälle numerolle tehty päätös käyttää vain osaa kuvasta. Omistuksen kokonaiskustannukset -malli kaappaa kokonaiskuvan. Se kattaa kaikki Salesforce-ratkaisuun liittyvät kustannukset sen elinkaaren aikana ja erottaa ne välittömiin kustannuksiin, jotka liittyvät selkeästi ratkaisuun, ja epäsuoriin kustannuksiin, jotka ovat todellisia, mutta joita on helppo jättää huomiotta. Molemmat muuntavat kustannusarvioinnin tietoiseksi arkkitehtuuripäätökseksi, joka painottaa pitkäaikaista arvoa alustavien kustannusten sijaan.

Järjestelmän toteutus, käyttö ja ylläpito aiheuttaa suoria kustannuksia:

Lisenssi- ja kulutuskustannukset ovat jatkuvia tilausmaksuja, jotka vaihtelevat Edition-version, käyttäjätyypin ja ominaisuusjoukon mukaan sekä kulutukseen perustuvia krediittejä. Edition-version valinta on tärkeä kustannuspäätös, koska käyttäjäkohtaiset eroavaisuudet ovat merkittäviä. Kulutuskustannuksia on vaikea mallinntaa ajoissa, joten tarkasta arvioinnit uudelleen, kun suunnittelupäätökset tehdään.
Toteutuskulut kattavat ratkaisun suunnittelun, kehittämisen, testauksen, datan siirron ja koulutuksen. Ne ovat pääosin kertaluonteisia, mutta luovat jatkuvia huoltovelvoitteita monimutkaisuudesta riippuen. Yritykset aliarvioivat toteutustehtäviä järjestelmällisesti, koska ne keskittyvät kehitykseen ja aliarvioivat testausta ja koulutusta.
Toimintakulut kattavat hallinnan, käyttäjien tuen, valvonnan, vahinkotapahtumien vastauksen ja toiminnallisten työkalujen. Ne kasvavat ratkaisun monimutkaisuuden myötä, ja ne ovat usein näkymättömiä suunnittelussa, koska ne ilmenevät sisäisenä vaivana ulkoisten laskujen sijaan.
Ylläpitokustannukset kattavat parannuksen, teknisen velan korjauksen, julkaisun mukautuksen ja kokoonpanon muutokset. Huolto kuluttaa tavallisesti 60–80 % kehityskapasiteetista kypsille ratkaisuille, mikä tekee siitä suurimman jatkuvan kustannuskategorian.
Integroinnin kustannukset sisältävät integraatioalustan lisenssit, API-kulutuksen, synkronoinnin kehittämisen ja jatkuvan huollon. Ne kasvavat ekosysteemien monimutkaisuuden myötä, koska järjestelmän määrän kasvattamisen myötä Pisteestä pisteeseen -integraation ylläpitokomponentit kasvavat.
Muutosten kustannukset kattavat liiketoimintaprosessien uudelleen suunnittelun, muutosten hallinnan, sopeutumisen ja sidosryhmien koordinoinnin. Ne kasvavat liiketoimintayksiköiden ja alueiden kattavuuden mukaan, ja ne ohitetaan usein, koska ne ilmenevät liiketoimintatiimin työstä.

Epäsuorat kustannukset eivät ole välittömästi näkyvissä alustavassa suunnittelussa, mutta ne kertyvät merkittävästi ratkaisun elinkaaren aikana, ja kypsissä toteutuksissa ne ovat usein suurempiä kuin suorat kustannukset. Yhtiö, joka optimoi vain suorat kustannukset, mutta ei huomioi epäsuoria kustannuksia, menettää suurimman osan kokonaisinvestoinneistaan. Useat kategoriat ansaitsevat erityistä huomiota.

Organisaation kustannukset ovat sijoituksia, jotka edistävät Salesforcen menestymistä, mutta joita ei koskaan näytetä Salesforce-laskussa. Ne sisältävät sisäisten tiimien palkat pääkäyttäjille, kehittäjille ja arkkitehdeille, kehitysinfrastruktuurin, kuten versiohallinnan ja CI/CD-työkalujen, koulutus- ja sertifikaattien ylläpidon ja taitojen kehittämisen sekä mahdollisuuksien kustannukset, jotka liittyvät ylläpitoon ja innovaatioihin kohdistettuun kehityskapasiteettiin. Viimeistä kohdetta on vaikea havaita, koska sitä ei näytetä ollenkaan kulutettuna. Se näytetään innovaationa, joka ei koskaan toimitettu.

Tekninen korko on arkkitehtonisten pikavalintojen kokonaiskustannukset. Käynnistyspäivämäärän täyttämiseksi suoritetut pikavalinnat aiheuttavat huoltotyön, joka saattaa vaatia useita kertoja alkuperäistä vaivaa ratkaistakseen ne myöhemmin, ja jokainen velan korjaamiseen käytetty pikavalinta ei tuota uutta liiketoiminta-arvoa. Tiimit, jotka lykkäävät arkkitehtuurin parannuksia tarpeeksi pitkään, huomaavat lopulta, että suurin osa kapasiteetistaan menee ylläpitoon eikä uusiin ominaisuuksiin.

Hallinta kuluttaa aikaa hyväksymisprosesseissa, koordinointikokouksissa ja manuaalisissa tarkastuksissa. Hallinta tarjoaa todellista arvoa riskien vähentämisen ja johdonmukaisuuden avulla, mutta liiallinen hallinta aiheuttaa piilotettuja kustannuksia viivästyneiden päätösten ja päällekkäisten töiden ansiosta, minkä vuoksi tavoitteena on suunnitella järjestelmiä, jotka edistävät turvallista itsenäisyyttä eikä vaadi keskitettyä hyväksymiskulkua jokaiselle muutokselle.

Käyttämättömät ominaisuudet kerääntyvät, kun ominaisuuksia otetaan käyttöön, mutta ei koskaan täysin käyttöön. Osittain käyttöönotettu ratkaisu kuluttaa jatkuvaa huoltoa tuomatta suhteellista arvoa, ja lisenssien käyttöasteen ja ominaisuuksien omaksumisen valvonta paljastaa kyvyt, joihin voit sijoittaa enemmän tai poistaa kapasiteetin uudelleenohjauksen.

Kattava kustannusten näkyvyys vaatii sekä suorien rivikohteiden että näiden epäsuorien kohteiden kohdistamisen, koska vain koko kuva tukee järkeviä sijoituspäätöksiä.

Rakenna TCO-malleja perustasollesi ja optimoiduille arkkitehtuurivaihtoehdoille ennen kuin sitoudut lähestymistapaan. Mallit, jotka ennustavat 3–5 vuoden kulut dokumentoiduilla oletuksilla, sallivat sinun vertailla vaihtoehtoja järjestelmällisesti. Suorita luottamuksellisuusanalyysi tärkeimmille oletuksille määrittääksesi kustannusarvioiden variaatiot ja rajat. Suunnittele tarkastella päätöksiä uudelleen, kun ehdot muuttuvat. Oletusten kirjoittaminen alas on osa arvoa, koska se tekee myöhemmästä uudelleenarvioinnista todisteisiin perustuvan vertailun eikä tuoretta argumenttia.

Arvioi kaupallisesti saatavilla olevia ratkaisuja ja mukautettua kehitystä käyttämällä kattavaa TCO-vertausta alustavien kustannusten sijaan. Rakennus-vasta-osto-päätökset määrittävät pitkäaikaiset sijoitukset joko jatkuvien tilausmaksujen tai jatkuvien huoltovelvoitteiden avulla, ja molemmat polut sisältävät perusteellisesti erilaisia sijoitusprofiileja.

AgentExchange (aiemmin AppExchange) on Salesforce ISV -yhteisön johtava valmiiden ratkaisujen lähde. Sen sijoitusprofiili suosii nopeutta ja jaettua ylläpitoa. Käyttöönotto mitataan viikkoina eikä kuukausina, jotka vastaava mukautettu rakenne vaatii. Toimittaja ylläpitää ominaisuuksia, mukaan lukien sovellusalustan julkaisujen yhteensopivuutta, ilman asiakkaan vaivaa. Toiminnallisuus on todistettu olemassa olevassa asiakaskannassa, mikä vähentää toteutuksen riskiä. Erikoistuneet ominaisuudet hyötyvät jälleenmyyjien toimialueen ammattitaidosta ja tutkimusinvestoinneista, jotka ylittävät yksittäisen yrityksen rahoituksen. Tuen saatavuus vaihtelee ISV:n mukaan, tavallisesti ongelmien eskalointipolulla, ja se aiheuttaa malliin jatkuvat tilauskustannukset.

Mukautettu kehitys suosii sovitusta ja hallintaa. Se noudattaa tarkalleen yksilöllisiä organisaation vaatimuksia vaarantamatta yleisiä ratkaisukuvioita, antaa täydellisen hallinnan toiminnallisista ja etenemissuunnitelman prioriteeteista, ei sisällä jatkuvaa tilausta perusalustalisenssien ulkopuolelle ja voi luoda kilpailukykyä ominaisuuksilla, joita kilpailijat eivät voi käyttää käyttämällä samoja käyttövalmiita ratkaisuja. Kompromissina on, että yritys ottaa täyden vastuun ratkaisun ylläpidosta ja sen yhteensopivuuden pitämisestä jokaisen Salesforce-julkaisun kanssa.

Pitkäaikainen TCO-vertailu tekee näistä profiileista päätöksen. Valmiit ratkaisut sisältävät monimutkaisia vuosittaisia tilausmaksuja, mutta ne sisältävät toimittajien tarjoamia huolto-, parannus- ja yhteensopivuuspäivityksiä. Mukautetut ratkaisut vaativat kertaluonteisen kehitysinvestoinnin, mutta niillä on jatkuvat huoltokustannukset sekä täysi vastuu julkaisun yhteensopivuudesta. Projektien 3–5 vuoden kokonaissummat molemmille, jotta vertailu vastaa kokonaisinvestointia alkuperäisen kustannuksen sijaan, mikä suosii yleensä vaihtoehtoa, joka näytti halvemmalta ensimmäisenä päivänä.

Raakakakustannusten lisäksi neljä tekijää määrittävät rakentamisen vs. ostopäätöksen.

Strateginen eriytyminen määrittää, onko kapasiteetti kilpailukykyinen etu, joka kannattaa rakentaa, vai paremmin ostettu tuote.
Aika arvon muodostamiseen suosii ostamista, kun kyky vaaditaan mahdollisuuden keräämiseen välittömästi tai kilpailun painostukseen reagoimiseen, koska huomattava määrä mukautettuja ominaisuuksia kestää kuukausia.
Organisaation kapasiteetti suosii rakentamista vain paikassa, jossa on toimiva sisäinen tiimi, joka pystyy ylläpitämään ja kehittämään ratkaisua ajan myötä, ja suosii ostamista, kun kykyä ei ole.
Poistumisen kustannukset suosivat vaihtoehtoja, jotka säilyttävät joustavuuden, koska ratkaisu, joka luo syvällisen lukituksen omistetuilla muodoilla tai laajalla mukautuksella, on riski, jos vaatimukset muuttuvat.

Järjestelmällistä päätös siten, että se perustuu johdonmukaiseen arviointiin ad hoc -arvioinnin sijaan.

Lisenssi ja kulutus ovat syötteitä arvokustannusten yhtälöön, aivan kuten laskenta ja tallennus, ja ne ovat yleisimpiä jätteen lähteitä. Niiden optimointi ei koske pelkkiä alennuksia. Sen tarkoitus on täsmätä jokainen käyttäjä työhönsä sopivaan lisenssiin ja kutsua kaikkia tilattuja palveluita tehokkaasti.

Lisenssien optimointi etsii jokaiselle käyttäjälle oikean lisenssityypin. Sen ydin on täsmätä yrityksen kaikki käyttäjät heidän työhönsä vaadittuun lisenssiin. Ylikirjoittaminen, kuten täysien sovellusalustan lisenssien kohdistaminen käyttäjille, jotka tarvitsevat vain rajoitettuja ominaisuuksia (vain luku -oikeus tai yksinkertaiset työnkulkuhyväksynnät), on yksi yleisimmistä ja kalleimmista virheistä, joita yritykset tekevät, ja se on näkymätöntä, kunnes joku katsoo. Käyttäjäroolien, sisäänkirjautumistoimintojen ja ominaisuuksien käytön säännöllinen auditointi säästää merkittävästi, kun kohdistuksia laajennetaan oikealle käyttäjäkannalle. Suorita se vaiheittain, äläkä vain uusimisen yhteydessä — epäjohdonmukaisuudet kasvavat hiljaa, kun roolit muuttuvat ja ihmiset muuttavat sijaintejaan yrityksessä.

Kulutusluottojen optimointi on yhä tärkeämpää, kun yritykset ottavat Agentforcen, Data 360:n ja muiden tekoälyä hyödyntävien ominaisuuksien käyttöön, jotka hinnoitellaan käyttötarkoituksen sijaan. Hyvitysjoukot voivat loppua yllättävän nopeasti, kun tiimit suunnittelevat prosessinsa tehottomasti tai eivät valvo käyttökuvioitaan. Toisin kuin kiinteä lisenssien määrä, kulutus voi nousta ilman provisiointipäätöstä. Luo selkeä näkyvyys luotonpolttosuhteisiin, määritä kulutuksen kynnysarvoja, jotka käynnistävät tarkastuksen, ja suunnittele automaatioita ja agentteja, jotta he voivat käyttää mitattuja palveluita tehokkaasti. Sama tehostustyö, joka pitää transaktion hallintarajoitusten sisällä, pitää määritetyn palvelun sen luotto-budjetin sisällä. Tämä on sama arvo kustannukselle -idea, joka ilmaistaan kulutuksessa.

Ympäristö- ja sandbox-strategia on resurssin päätös, joka vaikuttaa suoraan kustannuksiin, ja Salesforcen kehittynyt toimitusmalli vaatii hyvin rakenteellisen ympäristöstrategian. Kehitys-, testaus-, vaiheistus- ja tuotantoympäristöt palvelevat erillistä käyttötarkoitusta, ja sandbox-tyyppien oikea yhdistelmä sallii tiimien laatia ja vahvistaa muutoksia turvallisesti ennen kuin ne saavuttavat tuotantoympäristön. Haasteena on, että ilman tarkoituksellista hallintaa aktiivisten sandboxien määrä lisääntyy nopeasti, varsinkin suurissa tai pitkäaikaisissa ohjelmissa, ja se nostaa kustannuksia siten, että yritykset eivät ole varovaisia. Korjausvaihtoehto on käsitellä sandbox-provisiointia samalla tavoin kuin muita resursseja. Päivitä tai poista käytöstä sandboxit, jotka eivät ole enää aktiivisesti käytössä, vaan jätä ne tyhjäksi, anna sandbox-tyypin valinta perustuu todellisiin datan vaatimuksiin, eikä mukavuuksiin, ja määritä selkeitä käytäntöjä omistajuudelle, päivitysvaiheelle ja käytöstä poistamiselle, jotta kiinteistö pysyy kokoisena töille.

Usean organisaation arkkitehtuuri kertoisi kustannukset. Yhden organisaation arkkitehtuuri hyötyy yhdistetystä lisenssistä, jaetusta sovellusalustan infrastruktuurista ja vähäisemmistä hallinnallisista kustannuksista, koska hallintaa, määrittämistä ja ylläpitoa on yksinkertaisesti vähemmän. Kun kaikki liiketoimintayksiköt toimivat yhdessä organisaatiossa, integraatiot ovat sisäisiä eikä organisaatioiden välisiä, datan jakaminen on natiivista ja sandboxien, tuen ja hallintatyökalujen kokonaisjalanjälki pysyy suhteellisesti pienempänä. Monen organisaation arkkitehtuurit, vaikka ne ovat joskus tarpeen maantieteelliselle sijainnille, säännösten noudattamiselle tai organisaation erottamiselle, vaikuttavat useisiin kustannuskategorioihin. Jokainen lisäorganisaatio sisältää omat lisenssien vaatimuksensa, oman sandbox-alueensa, omat integraatiokustannuksensa ja omat hallintatyönsä, ja se vaatii kehittyneempiä työkaluja organisaatioiden välisen käyttöönoton, identiteettien yhdistämisen ja datan synkronoinnin hallintaan. Ymmärrä kunkin lisäorganisaation todelliset omistajuuden kokonaiskustannukset ennen kuin teet arkkitehtonisen päätöksen, jonka palauttaminen on vaikeaa ja kallista.

API- ja integraatiokustannukset ovat Salesforce-ekosysteemissä aliarvioituja kustannustekijöitä. Salesforcen yhdistäminen ulkoiseen järjestelmään saattaa näyttää yksinkertaiselta, mutta monimutkaisten integraatioiden vaatimukset laskevat nopeasti kustannukset mittaristolisenssien, kehitystyön, jatkuvan huollon ja jokaisesta datanvaihdosta kulkevan API-kulutuksen perusteella. Erityisesti yritykset, joilla on paljon integroituja järjestelmiä, paljon dataa tai lähes reaaliaikaisia synkronointivaatimuksia, ovat alttiina. Arkkitehtuurinen lähestymistapa on tärkeä tässä. Chatty, hienosäädetty integraatiot, jotka tekevät usein pieniä API-kutsuja, ovat kalliimpia ja hauraampia kuin hyvin suunniteltu joukko- tai tapahtumiin perustuvat kuviot, jotka minimoivat pyöreät matkat, ja yhdistettyjen sovellusten eroavaisuudet moninkertaistuvat. Hallitse integraation suunnittelun standardeja, yhdistä integraatioalustat mahdollisuuksien mukaan ja tarkasta säännöllisesti, toimivatko olemassa olevat integraatiot edelleen yhtä tehokkaasti kuin alunperin suunniteltu.

Kestävän kehityksen arkkitehtuuri vaatii enemmän kuin alustavia suunnittelun optimointeja. Se vaatii jatkuvaa valvontaa ja rakenteellista vastuullisuutta. Kustannusten valvonta ja hallinta ovat kehysjärjestelmä, joka muuntaa optimoinnin kertaluonteisesta käytännöstä jatkuvaan toimintatapaan. Johdonmukainen seuranta ja selkeä omistajuus vähentävät odottamattomien ylikustannusten riskiä, jotta kaikki kulutetut dollarit vastaavat liiketoiminnan arvoa.

Näytä kulutuskuviot mittaristojen avulla, jotka ovat sekä teknisten tiimien että liiketoiminnan sidosryhmien käytettävissä, jotta sijoituskeskustelut perustuvat dataan laskujen sijaan. Kustannusten näkyvyys käynnistää dataan perustuvan keskustelun sijoitusprioriteeteistä ja optimointimahdollisuuksista, ja se toimii parhaiten, kun kolme erillistä näkymää ovat käytettävissä. Lisenssien käyttöaste -mittaristot paljastavat ei-aktiiviset käyttäjät, ylikirjoitetut käyttäjät ja lisenssityyppien epäjohdonmukaisuudet, jotka ovat optimointimahdollisuuksia, jotka piilotetaan kiinteän määrän sisällä. Kapasiteettimittaristot näyttävät tallennustilan, API:n ja käsittelyn kulutuksen kasvustrendeillä, jotta tiimit optimoivat ennen kuin rajoitus aiheuttaa käyttökatkoksen sen jälkeen. Sijoitusmittaristot näyttävät kulut liiketoimintayksikön mukaan, ympäristökustannukset omistavan tiimin mukaan, lisäkustannukset niiden käyttöasteen mukaan ja ennustetut kulut tämänhetkisen kasvun perusteella, mikä tekee budjettikeskustelusta allokointikeskustelun.

Nämä mittaristot voidaan luoda useista eri työkaluista, kuten Digital Wallet ja mukautetut raportit, jotka kyselevät metadataa. Työkalu ei ole niin tärkeä kuin tietojen esittelytapa, jossa päätökset tehdään. Jaa mittaristot liiketoiminnan sidosryhmille ja johtajille luodaksesi läpinäkyvyyttä sijoituskeskustelulle, eikä reagoivalle budjettikeskustelulle. Finanssitiimi, joka näkee käyttöasteen kuviot, jotka voivat optimoida kulutuksen. Tiimi, joka näkee vain kokonaislaskun, voi vain leikata sen.

Ota käyttöön kulutustietoisuus koko yhtiössä, mukaan lukien ennakoivat hälytykset, jotka merkitsevät optimointia ennen rajoitusten ylittymistä:

Lisenssien budjetit määrittävät allokointikohteita osastoittain hälytyksillä, kun ne lähestyvät kapasiteettia, joten ei-ohjaamatonta provisiointia ei havaita vain uusittaessa.
Säiliöbudjetit valvovat kasvua hälytyksillä, kun trendit ylittävät rajoitukset ennen seuraavaa uusintasykliä. Nämä hälytykset tarjoavat varoituksen etukäteen, jotta arkistointi voidaan suorittaa ennen ylikäytöstä.
API-budjetit seuraavat kulutusta rajoitusten mukaisesti hälytyksillä, joiden käyttöasteen kynnysarvot ovat esimerkiksi 70 % ja 85 %, joten optimointi on ennakoivaa hätätilanteen sijaan, kun rajoitukset aiheuttavat virheitä.
Sandbox-budjetit hallitsevat ympäristön lisääntymistä rajoitusten ja hyväksymisprosessien avulla.

Budjetin ohjaimet luovat tietoisuutta kustannuksista estämättä tarvittavia investointeja. Hälytysten kynnysarvot tarjoavat varhaisia varoituksia, jotka sallivat harkitun optimoinnin reaktiivisen peukaloinnin sijaan.

Kustannusten allokointi luo vastuullisuutta ja tietoon perustuvaa päätöksentekoa liiketoimintayksiköissä, ja yritykset toteuttavat sen jollakin kahdesta mallista, jotka eroavat vastuullisuuden määrän perusteella. Showback-raportit kustannukset liiketoimintayksikön mukaan ilman todellisia talousmaksuja. Se luo läpinäkyvyyttä ja edistää kustannustietoista keskustelua ja optimoinnin priorisointia ilman sisäistä laskutusta, mikä sopii yritykselle, joka suosii yhteistyöhön perustuvaa kustannusten hallintaa taloudellisen vastuullisuuden sijaan. Chargeback jakaa todelliset kustannukset liiketoimintayksiköille ja luo suoran taloudellisen vastuun kulutuspäätöksille. Se edistää tehokkaampaa optimointitapaa, koska kustannukset vaikuttavat suoraan osastojen budjetteihin, mutta se vaatii tarkan allokointitavan välttyäkseen riidoilta siitä, kuka maksaa mistä. Joko niin, allokaatiosäännöt noudattavat samaa logiikkaa: lisenssien kustannukset käyttäjäosaston mukaan, ympäristökustannukset, kun kehitystiimi omistetaan, integraatiokustannukset integraatiota kuluttavan liiketoimintaprosessin mukaan, ja kehityskustannukset työn rahoittaneen aloitteen mukaan. Kun näitä sääntöjä ei ole, kaikki kustannukset lasketaan keskeiseen IT-budjettiin, ja liiketoiminnan sidosryhmät käsittelevät sovellusalustaa ilmaisena, mikä on juuri ehto, joka tuottaa pyyntöjä ilman kustannustietoisuutta.

Mukauta Cloud FinOps -käytäntöjä Salesforcen sovellusalustan taloudelle luodaksesi jatkuvan optimointivaihtoehdon säännöllisten päivitysten sijaan. Viisi käytäntöä kantaa painon.

Toimintojen välinen yhteistyö rahoitus-, arkkitehtuuri- ja liiketoiminnan sidosryhmien välillä varmistaa, että kustannuspäätökset painottavat liiketoiminta-arvoa kulutuksen rinnalla. Se tuo taloustieteen ammattitaidon arkkitehtuurikeskusteluihin ja tekniseen ymmärrykseen budjetin suunnitteluun.
Jatkuva optimointitapa estää kustannusten heikentymisen säännöllisten tarkastussyklien aikana: kuukausittainen poikkeusten tarkastus, joka havaitsee kulutuspisteitä, neljännesvuosittainen käyttöasteen tarkastus, joka vahvistaa lisenssien kohdistukset ja kapasiteetin käytön, sekä vuosittainen kattava TCO-arviointi, joka kohdistaa kulut uudelleen strategisiin prioriteetteihin.
Dataan perustuvat sijoituspäätökset käyttävät käyttöasteen dataa ja TCO-malleja oletusten tai historiallisten käytäntöjen sijaan. Nämä päätökset korvaavat "Olemme aina tehneet niin" -arvon analysoimalla, tarjoavatko nykyiset kulut optimaalista arvoa.
Kustannusten valvonnan automatisointi vähentää käyttöasteen seuraamiseen, optimointimahdollisuuksien tunnistamiseen ja raporttien luomiseen liittyviä manuaalisia vaivaa, joten käytäntö skaalataan organisaation monimutkaisuudella ilman, että henkilöstön määrä kasvaisi lineaarisesti.
Kustannusten tietoisuuden koulutus auttaa tiimejä ymmärtämään, miten arkkitehtoniset päätökset vaikuttavat omistajuuden kokonaiskustannuksiin, koska kustannuksia ymmärtävä arkkitehti suunnittelee parempia kompromisseja ja sovellusalustan taloustietoja ymmärtävä kehittäjä kirjoittaa tehokkaampaa automatisointia.

Integroi kustannusten tietoisuus arkkitehtuurin tarkastusprosessiin, jotta sijoituksiin liittyvät vaikutukset näytetään toiminnallisten ja teknisten huomioiden lisäksi sen sijaan, että ne havaittaisiin käyttöönoton jälkeen. Sisällytä arkkitehtuurin päätöstietueisiin kustannusten vaikutusten arviointi, joka dokumentoi tärkeimmät suunnitteluvaihtoehdot. Vaadi TCO-ennuste ratkaisuille, jotka ylittävät määritetyn sijoituskynnysarvon. Arvioi lisenssien vaikutukset suunnittelun aikana määrittämällä, vaatiiko lähestymistapa premium-lisenssejä tai lisäosia ennen kuin se sitoutetaan. Arvioi integraation kustannukset ennen kuin otat käyttöön kuvion, joka vaikuttaa API-kulutukseen tai middleware-lisenssiin. Arkkitehtuurin tarkastusohjelma, joka sisältää kustannusnäkymän toiminnallisten ja ei-toiminnallisten vaatimusten lisäksi, tuottaa paremmin räätälöityjä sijoituspäätöksiä. Käsittele kustannuksia yhtenä osatekijänä arkkitehtuuripäätöksessä sen ainoana edistäjänä, jotta yritykset investoivat asianmukaisesti tärkeisiin asioihin, mutta välttyvät tuhlaamatta niitä.

Pilvipalveluiden kestävän kehityksen tavoitteena on minimoida digitaalisen infrastruktuurin ympäristövaikutukset resurssien tehokkaan käytön avulla, ja se noudattaa luonnollisesti arvoa per kustannus: sama tehokkuus, joka vähentää resurssien kulutusta, vähentää myös kustannuksia. Salesforce ja arkkitehdit ovat vastuussa kestävän kehityksen lopputuloksista. Salesforce hallitsee datakeskuksen infrastruktuuria, mukaan lukien energiankulutuksen tehokkuuden optimointi, jäähdytystoiminnot ja laitteiston elinkaaren hallinta sekä usean palveluntarjoajan resurssien yhdistämisen ja sovellusalustan tason tehokkuuden parannukset. Sinä vaikutat ratkaisujesi resurssien kulutuskuvioihin monivaltuuden ympäristössä.

Yksittäisen ratkaisun ja datakeskuksen päästöjen välinen suhde on epäsuora, ja sen tarkkuus on tärkeää. Yksittäisen vuokralaisen optimoinnit eivät vähennä datakeskuksen päästöjä suoraan. He vaikuttavat aggregaatti-efektiin: kaikkien vuokralaisten tehokkuuden parantaminen sallii Salesforcen käyttää infrastruktuuriaan tehokkaammin ja lykätä kapasiteetin kasvua. Resurssien tehokkuuden tilastot, mukaan lukien SOQL-kyselyt, CPU-aika, kauppojen kulutus ja tallennustila, toimivat siis välityspalvelimen osoittimina kestävälle kehitykselle. Laskentamaton poistaminen parantaa suorituskykyä ja kustannuksia ja edistää sovellusalustanlaajuisia tehokkuustavoitteita. Tämän pilarin suunnitteluperiaatteet, mukaan lukien bulkkaaminen, valikoivat kyselyt, välimuistiin tallentaminen, ei-synkronoitu käsittely ja kurinalainen datan elinkaari, luovat ratkaisuja, jotka kuluttavat vähemmän resursseja. Kestävä kehitys ei ole erillinen aloite, joka perustuu arkkitehtuuriin. Resurssien tehokkuus näyttää tältä, kun mitataan sitä ympäristövaikutusten perusteella eikä vain taloudellisten kustannusten perusteella.

Useat arkkitehtitoiminnot sisältävät kestävän kehityksen arvon, ja ne parantavat myös suorituskykyä tai kustannuksia, minkä vuoksi ne kuuluvat samaan pilariin.

Ei-aktiivinen automatisointi kuluttaa infrastruktuuriresursseja tarjoamatta mitään liiketoiminta-arvoa. Käynnistimet, jotka käsittelevät asiaankuuluvia tietueita, työnkulut, jotka suoritetaan tarpeettomasti, ja ajoitetut työt, jotka suoritetaan, kun töitä ei ole, kaikki jätelaskenta, tallennus ja energia. Korjaus on neljännesvuosittainen automatisointitarkastus, jossa on selkeät ehdot käyttämättömille kohteille: ei suorituksia edellisen 90 päivän ajalta, erätöitä, jotka käsittelevät jatkuvasti nolla tietuetta, ja automatisointia, joka on korvattu uusilla toteutuksilla, mutta joita ei ole koskaan deaktivoitu. Dokumentoi jokainen deaktivointi, jotta se voidaan peruuttaa, jos liiketoimintavaatimus ilmestyy uudelleen. Yhtiö, jolla on kymmeniä menneistä toteutuksista jäljellä olevia Process Builderia, joista useimmat eivät suorittaneet mitään viime vuonna, maksaa arvioidakseen jokaisen niistä jokaisen asiaankuuluvan tietueen tallentamiseen.

Resurssiintensivisten toimintojen ajoittaminen ruuhka-aikojen ulkopuolella jakaa kuormituksen eri ajanjaksoille. Tämä tieteenala parantaa sovellusalustan interaktiivisuutta toimistoaikojen aikana usean vuokralaisen ympäristössä ja sallii Salesforcen käyttää infrastruktuuria korkeammalla keskiarvoisella käyttöasteella. Ajoita erien arkistointi, rikastaminen ja siivous vähäisen käytön ikkunoille, vähennä töitä keskiyöllä käynnistämisen ja käsittelyn kiihtymisen sijaan, ja suosittele tapahtumiin perustuvia kuvioita ajoitettujen kyselyiden sijaan, jotta töiden tarkastamiseen ei käytetä yhtään sykliä.

Saman arvon laskeminen toistuvasti kuluttaa CPU-sykliä ja infrastruktuurikapasiteettia. Laske kerran, tallenna tulos välimuistiin ja käytä sitä uudelleen transaktioissa ja käyttäjissä. Sovellusalustan välimuisti tarjoaa viitetietoja, joita kysellään useita kertoja, välimuistiin tallennetut yhteenvetoarvot välttyvät reaaliaikaisilta aggregaattikyselyiltä, joissa lähes reaaliaikainen tarkkuus riittää, kaavakentät lasketaan uudelleen dynaamisesti tietueen käyttöoikeuksien perusteella sen sijaan, että ne tallentaisivat arvon ja vaativat sen ylläpidon automaattisesti, ja Lightning Data Service välttää tarpeettomat palvelinpyynnöt asiakassovelluksesta. Jokainen vältetty laskenta palauttaa kapasiteetin sovellusalustaan.

Datan tallennustila kuluttaa infrastruktuuriresursseja ja heikentää kyselyiden suorituskykyä, kun se kasvaa. Säilytyskäytännöt, jotka arkistoivat tai poistavat tietoja, joita ei enää tarvita aktiivisille toiminnoille, pitävät aktiiviset taulukot pieninä ja nopeuttavat kyselyitä. Arkistoi vanhentuneet tietueet Big-objekteihin tai ajoitetun työn ulkoiseen tallennustilaan, poista ne pysyvästi, kun ne noudattavat säännöksiä, eikä luota tietueiden pysyviin poistoihin, jotka kuluttavat edelleen tallennustilaa, ja määritä kenttäkohtainen kenttien kirjausketjun säilyttäminen sen sijaan, että käytettäisiin enimmäismäärää, joka tallentaa paljon enemmän historiaa kuin mitä vaatimustenmukaisuus vaatii. Kuten ajoitetun käsittelyn tapauksessa, yksittäiset arkistointipäätökset eivät vähennä suoraan datakeskuksen energiankulutusta, mutta kaikkien vuokralaisten yhteenlaskettu datan ja elinkaaren kurinalaisuus parantaa sovellusalustan tehokkuutta ja lykkää tallennusinfrastruktuurin laajentumista.

Ulkoiset integraatiot kuluttavat resursseja sekä Salesforcessa että järjestelmissä, joihin ne muodostavat yhteyden. Muutosdatan datan taltiointi ja muut tapahtumiin perustuvat kuvioet poistavat kyselykutsut, jotka tarkastavat muutokset toistuvasti ja eivät löydä mitään, mikä vähentää API-kulutusta, hyödyttää hallintorajoituksia ja poistaa turhaa laskentaa. Yhdistelmä-API-kuviot keräävät useita operaatioita yhteen kutsuun, Bulk API -versio käsittelee suuria määriä huomattavasti tehokkaammin kuin tuhannet yksittäiset REST-kutsut, ja kokeilulogiikka eksponenttisella rästityksellä välttää kovaa ulkoista järjestelmää. Yksittäinen integraatio, joka kyselee viiden minuutin välein eikä löydä mitään tekemistä suurimman osan ajasta, on pelkkää roskaa, kun taas sama muutostapahtumiin perustuva integraatio käsittelee vain todelliset muutokset.

Agenttien arkkitehtuurit kuluttavat laskentaresursseja suurten kielimallien päätelmien avulla, ja sama tehokkuuden ajattelutapa pätee. Minimoi kehotteen pituus, tee yhteenveto keskusteluhistoriasta sen sijaan, että sisällytettäisiin täysiä kirjaimellisia keskustelulokeja, jotka kasvavat ilman rajoituksia, käytä tehtävälle tarpeeksi pienintä mallia sen sijaan, että ne olisivat oletusarvoisesti tehokkaimpia, ja tallenna viitetiedot ja deterministiset vastaukset välimuistiin. 50 vektorihakuhaun tuloksen noutaminen vain viidellä arvioidulla tuloksella kuluttaa johtopäätöksiä ja noutoresursseja ilman lisäarvoa, joten määritä haun rajoitukset todellisen käytön perusteella.

Kestävä kehitys vaatii tämän pilarin muiden osa-alueiden tavoin jatkuvaa valvontaa kertaluonteisen käytön sijaan, koska resurssien kulutuskuvio muuttuu ratkaisujen kehityksen, datamäärien kasvun ja käyttäjäjoukkojen kasvun myötä. Valvonta on tärkeää vain, kun se käynnistää toiminnon. Määritä kullekin tilastolle interaktiivisia kynnysarvoja — eli SOQL-kyselyiden määrää, joka ylittää tavoitteen per transaktio, tallennustilan kasvua yli kuukausittaisen prosenttiluvun tai välimuistin saavutussuhdetta, joka laskee tavoitteen alle — ja dokumentoi, mitä optimointeja haluat suorittaa ensin. Keskity raskaisiin transaktioihin ja usein suoritettuihin automaatioihin, joissa tehokkuuden parannukset vaikuttavat eniten yhteen. Process Builderin tuki päättyi 31. joulukuuta 2025 Siirrä loput Process Builderit kulkuun, älä vain deaktivoi niitä.

Käytä tätä tarkistuslistaa arvioidaksesi, palauttaako ratkaisu enimmäisarvon per kustannus. Se yhdistää resurssitehokkuuden ja kustannusten kurinalaisuuden käytännöt tästä pilarista yhteen tarkastukseen, koska ne ovat yksi päätös.

Arvo- ja kustannusmallinnus

Yhdistä kaikki Salesforcen merkittävät investoinnit mitattavissa olevaan lopputulokseen.
Mallinnat suorien, epäsuorien, kertaluonteisten ja jatkuvien luokkien omistajuuden kokonaiskustannukset ennen lähestymistapaan sitouttamista.
Vertaa perustason ja optimoitujen arkkitehtuurivaihtoehtojen kokonaissummaosuutta 3–5 vuoden ajalta.
Käytä yhdenmukaista build-vs-buy-arviointia, joka painottaa strategista eriytymistä, aika-arvoa ja poistumiskustannuksia ad hoc -arvioinnin sijaan.

Resurssien tehokkuus

Suunnittele transaktiot toimimaan kätevästi hallintarajoitusten sisällä huippukuormituksen ja datan enimmäismäärän ollessa käytössä.
Tee kyselyistä valikoivia indeksoituihin kenttiin nähden ja vahvista ne kyselyn suunnittelutyökalulla ennen kuin otat ne käyttöön suurille objekteille.
Bulkata kaikki datatoiminnot ja valitse asynkroninen käsittely tarkoituksella, kun synkronointirajoitukset sitä vaativat.
Tallenna viitetiedot välimuistiin sovellusalustan välimuistin ja Lightning Data Servicen kautta välttyäksesi toistuvilta kyselyiltä ja uudelleenlaskutoimilta.
Estä datavirheitä jakamalla ja valvomalla raskaita objekteja.
Keskitä käynnistimen, palvelun ja valitsimen logiikka, jotta liiketoimintalogiikkaa voi edelleen testata ja muuttaa halvalla.
Määritä täydellinen datan elinkaari luonnista arkistointiin ja valvo tallennustilan kulutusta objektitasolla.

Lisensointi ja kulutus

Täsmää käyttäjät heidän työnsä vaatimaan lisenssityyppiin ja tarkasta roolit, sisäänkirjautumiset ja ominaisuuksien käyttö säännöllisesti.
Luo näkyvyys kulutusluoton polttosuhteisiin ja suunnittele automaatioita ja agentteja kutsumaan mitattuja palveluita tehokkaasti.
Hallitse sandboxien provisiointia selkeällä omistajuudella, päivitystiheydellä ja käytöstä poistamisen käytännöillä.
Tutustu monen organisaation koko kustannuskertoimeen ennen organisaation lisäämistä ja suosittele joukko- tai tapahtumiin perustuvaa integraatiota chat-kuvioiden sijaan.

Valvonta ja hallinta

Tarjoa sekä teknisten tiimien että liiketoiminnan sidosryhmien käytettävissä olevia kustannus- ja kapasiteettimittaristoja.
Määritä lisenssien, tallennustilan, API-kulutuksen ja sandboxien budjettihälytykset, jotta optimointi on ennakoivaa, eikä reaktiivista.
Luo showback tai chargeback, jotta kustannusten allokointi luo vastuullisuutta liiketoimintayksiköissä.
Ota FinOps-tapaus käyttöön: kuukausittainen poikkeusten tarkastus, neljännesvuosittainen käyttöasteen auditointi ja vuosittainen kattava TCO-arviointi.
Integroi kustannusten vaikutusten arviointi arkkitehtuurin tarkastuksiin ja arkkitehtuurin päätöstyötietueisiin.

Jatkuva optimointi ja kestävyys

Käsittele optimointia jatkuvana käytännönä ja varmista, että aiemmat optimointiinvestoinnit ovat tuottaneet odotetun tuotonsa.
Vältä tarpeettomia automatisointeja ja tarpeettomia laskutoimia säännöllisten auditointien avulla.
Seuraa resurssien kulutusta pitkältä aikaväliltä ja määritä interaktiivisia kynnysarvoja, jotka käynnistävät optimoinnin, kun tilasto ylittää ne.

Jaa palautetta hyvin rakennetusta kehysjärjestelmästä.