Otimização de recurso e custo

A otimização de recurso e a otimização de custo funcionam juntos para que sua empresa atinja o valor máximo por custo. O Salesforce gerencia a infraestrutura multilocatário, impõe os limites do controlador que mantêm a plataforma justa para todos os locatários e precifica o acesso por meio de licenças e créditos de consumo. O que você otimiza é o valor retornado: quanto do resultado comercial cada dólar gasto e cada unidade de capacidade da plataforma retorna. A otimização de recursos é o mecanismo: ele faz um uso eficiente do que você já paga. A otimização de custo é o resultado: ele direciona o gasto deliberadamente para o que gera vantagem competitiva. Esse pilar os trata como uma única decisão porque são duas visões da mesma meta.

Essa visualização de valor por custo forma cada decisão arquitetônica que você toma. Quando você entende o custo total de propriedade, faz melhores compensações entre capacidade e investimento. Você cria soluções no tamanho certo para atender aos requisitos de negócios, em vez de sobreprovisionar recursos que ficam inutilizados ou investem pouco em recursos que aceleram a entrega de valor. Uma licença, um crédito de consumo, uma chamada à API e um ambiente de sandbox são entradas para a mesma equação. O que importa é o valor que cada um retorna, não em qual razão ele fica. A pergunta nunca é "este é um custo ou um recurso", mas "essa entrada tem um retorno adequado?"

Negligenciar esse pilar produz consequências previsíveis. As empresas acumulam licenças não usadas que consomem orçamento enquanto outros recursos permanecem sem financiamento. Arquiteturas ineficientes desperdiçam capacidade da API, armazenamento e esforço de desenvolvimento em problemas que um melhor design evita. Ineficiência do recurso em determinados compostos ao longo do tempo de maneiras previsíveis:

O desempenho diminui à medida que os volumes de dados aumentam.
Os tempos limite de consulta aparecem em algumas centenas de milhares de registros quando consultas não seletivas verificam tabelas inteiras.
Exceções de limite de heap aparecem quando as soluções recuperam campos desnecessários.
Os tempos limite de CPU são exibidos quando cálculos complexos são executados de modo síncrono.
As soluções alternativas se multiplicam à medida que as equipes corrigem cada novo limite.

Cada uma dessas falhas é um problema de confiabilidade e um problema de custo, pois o cálculo desperdiçado consome a capacidade que você paga. O mais crítico é que as equipes perdem oportunidades para investir em inovação porque o orçamento e a capacidade de engenharia são consumidos por resíduos, em vez de por iniciativas estratégicas.

Soluções econômicas maximizam o valor:

Usar recursos de plataforma que já foram comprados
Alinhar o consumo e o licenciamento no tamanho certo ao uso real
Modelar o custo completo antes de confirmar uma abordagem
Monitorar o gasto continuamente em relação aos resultados dos negócios

Estas práticas compostas. Equipes que criam consciência de custo e eficiência de recursos em seu design fornecem mais capacidade por dólar do que equipes que tratam a otimização como um exercício de limpeza depois que o gasto já aumentou.

O recurso e a Otimização de custo se conectam a outros pilares arquitetônicos diretamente. A Excelência Operacional reduz os custos contínuos com automação que reduz o esforço manual. A fiabilidade e a Trust justificam investimentos premium por meio da garantia de continuidade de negócios e do valor da conformidade regulatória. Juntos, esses pilares ajudam as empresas a investir com confiança, pois sua arquitetura gera o máximo de retorno.

Use esses princípios para orientar suas decisões arquitetônicas para otimização de recursos e custo na plataforma.

Otimize para o custo total de propriedade. O custo total de propriedade (TCO) se estende além das tarifas de assinatura para créditos de consumo, custos de implementação, custos operacionais, despesas de integração e esforço de gerenciamento de mudanças. Avalie decisões usando a análise de TCO para revelar o panorama completo do investimento ao longo da vida útil de uma solução. Às vezes, um investimento inicial maior reduz significativamente os custos operacionais em andamento, e a análise de TCO detecta isso. Otimize para valor de longo prazo, não minimizar o custo de curto prazo.
Alinhe o gasto com o valor dos negócios. Conecte cada investimento do Salesforce a um resultado de negócios mensurável. O gasto de licença habilita a produtividade do usuário medida pela adoção e conclusão da tarefa. O investimento do Data 360 capacita a tomada de decisão medida pela conversão e pelo valor da vida útil do cliente. Custos de sandbox da velocidade de desenvolvimento do fundo medidos pela frequência e qualidade da implementação. Quando o gasto se alinha ao valor, você investe com confiança no que conduz ao sucesso e identifica os gastos que não ganham mais seu retorno.
Design dentro dos limites da plataforma. Os limites do controlador definem o que uma solução pode processar por transação. Trate-as como restrições de design desde o início, não como obstáculos para contornar. Projete transações que operam confortavelmente dentro dos limites sob carga máxima e volumes de dados máximos e crie margem para recursos futuros, outros pacotes instalados e padrões de dados inesperados. As soluções projetadas dentro dos limites da concepção têm desempenho previsível e evitam o refatoramento de emergência mais tarde.
Otimize os recursos que você já paga. Antes de comprar mais capacidade, maximize a taxa de transferência, a eficiência e o valor dos ativos de plataforma já provisionados. Consultas eficientes, processamento de registros em massa (massificação), armazenamento em cache e ciclo de vida de dados disciplinado reduzem o consumo de computação, armazenamento e API de que uma solução precisa. Essa eficiência de recursos é o mecanismo que conduz a otimização de custo sustentável: resíduos eliminados de recursos provisionados melhoram o desempenho e o TCO de longo prazo.
Licenciamento e consumo do tamanho certo para o uso real. Combine cada usuário com o tipo de licença exigido pelo trabalho e projete automações e agentes para chamar serviços medidos de maneira eficiente. Sobre-licenciamento e créditos de consumo não monitorados estão entre as fontes de resíduos mais comuns e caras. Auditorias regulares de papéis, atividade de login e oportunidades de uso de recurso e visibilidade clara de queima de crédito mantêm os custos baseados em consumo previsíveis.
Estabelecer a governança financeira e uma cultura sensível aos custos. Gerencie o gasto do Salesforce como um investimento estratégico por meio de supervisão ativa e responsabilidade compartilhada. A governança financeira leva a análise de custo-benefício para decisões de design em vez de descobrir custos após a implementação. A conscientização de custo é uma responsabilidade compartilhada entre as partes interessadas dos negócios, arquitetos e desenvolvedores que consideram as implicações de custo junto com os requisitos funcionais, de modo que decisões de investimento inteligentes aconteçam em todos os níveis sem gargalos centralizados.
Prática de otimização contínua. A otimização é uma prática contínua, não um exercício único. Monitore o gasto e o consumo de recursos por meio de painéis acessíveis a partes interessadas técnicas e de negócios. Configure alertas que são acionados quando o gasto de consumo atingir limites antes de o consumo não percebido. As análises regulares descobrem resíduos que se acumulam gradualmente, validam se os investimentos de otimização anteriores geraram o retorno esperado e descobrem novas oportunidades conforme as prioridades de negócios e os volumes de dados evoluem.

Entender o que o Salesforce opera ajuda você a concentrar o esforço de otimização no que você controla. A plataforma lida com o gerenciamento de recursos no nível da infraestrutura que requer equipes dedicadas em ambientes de TI tradicionais:

Alocação de recursos de tenente: O Salesforce garante o compartilhamento justo de conexão de CPU, memória e banco de dados entre todos os clientes em uma infraestrutura compartilhada, monitora o consumo do locatário e impõe limites que impedem que um único locatário diminua o desempenho de outros.
Arquitetura do limite do governador: Limites impostos pela plataforma (100 consultas SOQL por transação síncrona, 10 segundos de tempo de CPU, 6 MB de tamanho de heap) protegem todos os locatários contra o esgotamento de recursos. O Salesforce calcula esses limites para a capacidade da infraestrutura multilocatário. Esses limites são limites arquitetônicos, não restrições arbitrárias.
Otimizador de consulta e mecanismo de execução: O otimizador de consulta do Salesforce gera planos de execução, mantém estatísticas sobre a distribuição de dados e seleciona caminhos de consulta ideais. Os índices gerenciados pela plataforma em campos padrão aceleram padrões de consulta comuns e o otimizador se adapta a alterações de volume de dados automaticamente.
Escalonamento de infraestrutura: O Salesforce provisiona a capacidade de hardware, gerencia clusters de banco de dados, distribui a carga e escala a infraestrutura conforme o uso aumenta. Você nunca provisionará servidores, gerenciará a replicação do banco de dados nem configurará balanceadores de carga.
Otimização de desempenho da plataforma: O Salesforce otimiza continuamente o código da plataforma principal, a execução de consultas, os tempos de resposta da API e o desempenho da estrutura de interface do usuário e oferece melhorias de infraestrutura por meio de suas versões regulares sem exigir ação do cliente.

O Salesforce também gerencia o lado comercial da plataforma, o que faz com que o licenciamento e o consumo pertençam ao mesmo pilar de computação e armazenamento. A plataforma define as edições, os tipos de licença, os complementos e os modelos de crédito de consumo pelos quais a capacidade é comprada e mede o uso que obtém esses créditos. Você não define esses preços mais do que provisiona os servidores, mas decide quanto de cada um consome: que licença cada usuário possui, com que eficiência uma automação chama um serviço medido, quantos sandboxes permanecem ativos.

Essas operações de plataforma são a base em que você cria. Como o Salesforce gerencia a infraestrutura e o modelo de precificação, seu esforço de otimização se concentra inteiramente nas decisões de arquitetura que você toma com base nelas: quão eficiente você usa os recursos provisionados a você e quão deliberadamente direciona os gastos que os provisão.

O Modelo de responsabilidade compartilhada significa que você possui a eficiência do recurso para tudo o que você cria no Salesforce. O gerenciamento de recursos de plataforma dá suporte ao seu trabalho, mas não substitui sua necessidade de otimização. Uma solução eficiente retorna mais valor comercial da capacidade de computação, armazenamento e API que você já paga, e esse é o mecanismo que mantém a otimização de custo sustentável, em vez de um corte de orçamento único. Computação de resíduos, por outro lado, consome recursos de infraestrutura sem fornecer valor comercial e seus compostos de custo. O desempenho diminui de modo previsível à medida que os volumes de dados aumentam e as soluções alternativas se multiplicam à medida que as equipes corrigem limites que podiam ter projetado dentro deles.

Suas responsabilidades de otimização abrangem quatro áreas interconectadas: desempenho, organização de código, empacotamento e dados. Cada uma é uma decisão de valor por custo antes de uma decisão técnica. Esta seção explica como tomar essa decisão e por que isso importa. As receitas de implementação exatas, os modelos de nível de código, a navegação em Configuração e os limites de ajuste específicos mencionados nesta seção estão na biblioteca de padrões de Recurso e Otimização de custo.

A otimização de desempenho começa com uma mudança no modo como você considera os limites do regulador. Eles não são obstáculos para contornar. São restrições arquitetônicas que, quando adotadas a partir do design inicial, produzem soluções com características de desempenho previsíveis. Cada transação é executada dentro de limites fixos, e esses limites existem para impor o compartilhamento de recurso justo em todos os locatários na plataforma. Uma transação do Apex que consome 95 de suas 100 consultas SOQL permitidas não deixa margem para recursos futuros, acionadores adicionados por outras equipes ou padrões de dados inesperados. Os arquitetos que mantêm as transações bem abaixo da metade do limite criam soluções que podem crescer sem refatoramento de emergência quando um limite é esgotado. A disciplina é projetar bem dentro dos limites sob carga máxima e nos volumes de dados máximos, de modo que adicionar um recurso ou a automação de outro pacote nunca faça uma transação passar pela borda. Uma falha comum e cara: a solução funciona perfeitamente com 10 registros em um Developer Sandbox, mas atinge limites de regulador na produção. Os Developer Sandboxes copiam apenas a configuração e não contêm dados. Testar com relação a volumes realistas em um Sandbox de Cópia Completa detecta problemas de escalabilidade antes que os clientes o façam.

A seletividade de consulta é a única maior alavanca em se uma solução é dimensionada para milhões de registros ou atinge centenas de milhares. Consultas seletivas usam índices para localizar registros com eficiência, enquanto consultas não seletivas verificam tabelas inteiras, consomem recursos de banco de dados excessivos e, por fim, atingem o tempo limite. A plataforma mantém índices padrão em um conjunto definido de campos e aplica limites de seleção que se apertam à medida que um objeto ultrapassa seus primeiros milhões de registros. O arquiteto para seletividade significa filtrar em campos indexados como seu critério principal e validar com a Ferramenta de plano de consulta antes de implementar em objetos grandes, pois uma consulta que mostra uma verificação de tabela em um objeto de alto volume é um incidente de produção que espera para acontecer. Selecionalidade é capacidade que você não precisa comprar: uma consulta eficiente retorna em milissegundos e deixa os recursos do banco de dados disponíveis para cada outro locatário e cada outra transação em sua própria organização.

A massificação é o padrão fundamental de escalabilidade que distingue o Apex que funciona em escala do Apex que atinge limites. O antipadrão (uma consulta ou uma instrução DML colocada dentro de um loop) funciona corretamente com pequenos conjuntos de registros, mas viola os limites do regulador do momento em que uma operação em massa é executada. A solução é consultar todos os dados necessários em instruções únicas fora de loops, organizar os resultados em mapas com ID chave para pesquisa rápida durante a iteração e processar uma coleção inteira com DML em lote. Projete cada automação para lidar com o lote do acionador de 200 registros padrão sem se aproximar de limites e a mesma escala de código, independentemente da carga na produção.

O processamento assíncrono existe para trabalho que não pode ou não deve ser concluído dentro dos limites síncronos de uma transação do usuário. Mover esse trabalho para um contexto assíncrono duplica os limites de controlador disponíveis para ele e impede que operações de execução longa bloqueiem usuários. Esse espaço reservado é real, mas não é gratuito, e procurar por assíncrono sempre que um limite parecer próximo é um erro. Assíncrono é uma compensação arquitetônica deliberada: ele introduz consistência eventual, de modo que o resultado do trabalho não está visível na transação que o solicitou, o que força decisões de experiência do usuário que não dependem de confirmação instantânea. Ele exige o manuseio e o monitoramento de erros explícitos, pois uma falha aparece em um registro de trabalho em vez do usuário que a acionou. E isso pode complicar o modelo mental do sistema quando uma única operação comercial abrange várias transações. A decisão de valor por custo é ponderar essa complexidade adicional em relação à capacidade de que o trabalho realmente precisa e manter o trabalho síncrono quando ele se encaixa de maneira conveniente.

Quando assíncrono é a chamada certa, a escolha entre os mecanismos segue a forma do trabalho, em vez do tamanho do limite. O Apex em lote é para volume. Ele processa milhões de registros dividindo-os em blocos, cada um com seus próprios limites de controlador independente. É por isso que a migração de dados, o arquivamento de dados e o aprimoramento em massa pertencem aqui. Enfileirável é para sequência: ele lida com fluxos de trabalho de várias etapas que excedem limites síncronos, mas não precisam de escala em lote, e oferece suporte ao encadeamento de um trabalho de outro para etapas que devem ser executadas em ordem. Platform Events são para desacoplamento: um produtor emite um evento sem saber ou aguardar seus consumidores. Use esse padrão para notificação entre sistemas e para separar o trabalho que não pertence à mesma transação, considerando que a entrega pelo menos uma vez requer assinantes idempotentes. Métodos futuros abrangem o caso estreito de trabalho assíncrono simples com entradas primitivas, mais comumente uma chamada de um acionador síncrono. Sua incapacidade de encadear ou aceitar objetos complexos é exatamente por isso que eles não são uma ferramenta para trabalho assíncrono de todas as finalidades. Combine o mecanismo assíncrono com a forma do trabalho. Caso contrário, você trocará um problema de limite do regulador por custos de consistência e monitoramento que excedam o ganho.

O armazenamento em cache converte o trabalho repetido na capacidade que você mantém. O Cache da plataforma armazena dados serializáveis entre limites de transação, assim, um ataque de cache evita a reexecução da consulta ou recomputação que produziu o valor, reduzindo diretamente o consumo de SOQL e CPU. A decisão que faz ou quebra um cache é o que você escolhe colocar nele e por quanto tempo. Armazene em cache dados que são lidos com muito mais frequência do que mudam, como metadados personalizados, configuração e valores de lista de opções, e defina o tempo de ativação para corresponder à volatilidade dos dados, em vez de um único padrão. Dados de referência que mudam mensalmente podem ser armazenados em cache com segurança por horas, enquanto os ajustes que alternam ao longo do dia precisam de uma janela curta para que o cache nunca apresente um valor obsoleto o bastante para ser importante. Um cache muito agressivo troca um ganho de desempenho por um risco de correção, e um cache com uma taxa de alcance ruim gasta o armazenamento sem retornar capacidade, o que é por isso que a taxa de alcance é uma métrica a ser monitorada e não uma configuração a ser presumida. A escolha de partição é uma decisão de segurança: use a partição da organização para dados compartilhados entre usuários, use a partição da sessão para dados no escopo do usuário que devem permanecer isolados e nunca coloque informações de identificação pessoal na partição da organização em que cada usuário possa lê-las. O Lightning Data Service estende a mesma ideia ao cliente: ele compartilha registros em cache em cada componente em uma página e elimina viagens de ida e volta ao servidor redundantes. Cada ocorrência de cache é uma capacidade de API e computação que você não precisa gastar, desde que o valor retornado ainda esteja correto.

O desvio de dados é um hotspot de desempenho criado por distribuição de registros desequilibrada. Quando um único registro pai acumula mais de 10 mil filhos, o desempenho da consulta diminui e a contenção de bloqueio de linha aparece durante operações simultâneas. O limite é um sinal de design, não um limite permanente. Ele determina que você distribua a carga entre vários pais, monitore objetos de alto volume com trabalhos agendados que alertam conforme qualquer pai se aproxima do limite e classifique as cargas em massa por ID pai para que lotes simultâneos não entrem nas mesmas linhas. O desvio de propriedade, em que um usuário de integração é proprietário de centenas de milhares de registros, produz a mesma contenção de bloqueio e merece a mesma distribuição de carga.

O Salesforce fornece ferramentas para manter as características de desempenho saudáveis conforme uma solução evolui. O Centro de escala oferece visibilidade no nível da transação de operações de execução longa, contenção de bloqueio de linha e transações que se aproximam dos limites, então dá um nome ao acionador e ao objeto específicos envolvidos. O ApexGuru aplica a análise de IA à telemetria de tempo de execução de produção para detectar antipadrões antes que eles cheguem à escala, e o Salesforce Code Analyzer realiza a análise estática no pipeline CI/CD para que as compilações falhem quando as consultas aparecem dentro de loops ou outros defeitos de desempenho são detectados. O Monitoramento de evento revela tendências de consumo ao longo do tempo e o Proactive Monitoring, um recurso do Plano de sucesso de assinatura, avalia continuamente a organização quanto a riscos de desempenho e escalabilidade.

A organização de código é uma decisão de custo expressa como capacidade de manutenção. A manutenção geralmente consome a maioria da capacidade de desenvolvimento para uma solução madura, portanto, a estrutura escolhida determina quanto da capacidade futura vai mudar em vez de trabalhar novamente. Três padrões têm a maior parte desse valor. O padrão do manipulador de acionador centraliza a lógica do acionador em classes de manipulador e reduz o arquivo de acionador em si a um ponto mínimo de delegação, o que mantém a lógica testável independentemente do contexto do acionador e dá controle de recursão uma única página inicial. O padrão da camada de serviço encapsula a lógica de negócios em classes que expõem operações invocáveis de um acionador, um ponto de extremidade REST, um fluxo invocável ou um trabalho em lote, de modo que uma regra de negócios reside em uma implementação, em vez de ser duplicada em cada ponto de entrada e se desviando da sincronização. O padrão seletor centraliza o SOQL para cada objeto em classes dedicadas, o que torna o ajuste da consulta uma mudança de ponto único e dá a cada consulta uma intenção nomeada explícita.

Erros de DML mistas são um perigo organizacional distinto que vale a pena projetar explicitamente. Elas ocorrem quando uma transação realiza DML em objetos de configuração, como Usuário e PermissionSet, e objetos não de configuração, como Conta e objetos personalizados, pois as alterações de configuração que afetam o acesso de um usuário devem ser confirmadas em uma transação separada. A falha aparece em escala em trabalhos de integração, na configuração de teste e na automação de provisionamento de usuários. Os remédios arquitetônicos são separar DML de configuração e não de configuração entre limites de transação usando processamento assíncrono ou Eventos de plataforma, projetar modelos de dados que evitam combinar as duas operações em uma única etapa de negócios e isolar DML de configuração em testes.

As opções de empacotamento moldam o custo de desenvolvimento de longo prazo e a reutilização que você pode alcançar em uma empresa. Os pacotes gerenciados de segunda geração fornecem desenvolvimento modular orientado por origem com proteção de namespace e são a escolha certa para produtos de fornecedor de software independente (ISV) distribuídos por meio do AgentExchange. Pacotes desbloqueados oferecem às equipes internas a mesma modularidade e gerenciamento de dependência sem sobrecarga de namespace, o que é adequado para aplicativos corporativos que precisam de implantação independente, mas sem listagem de mercado. Os pacotes gerenciados de primeira geração permanecem em uso para produtos existentes, mas não têm o fluxo de trabalho conduzido por origem que torna o novo desenvolvimento modular mantido.

A modularidade se estende aos componentes que você cria. Projetar Componentes da Web Lightning em torno de uma única responsabilidade com interfaces de propriedade claras, favorecer a composição em vez de herança para que as UIs complexas sejam montadas a partir de pequenos componentes focados e usar eventos personalizados para comunicação pai em vez de entrar diretamente em um pai. Exponha o Apex reutilizável como ações invocáveis para que os administradores possam criar a automação no Flow Builder a partir de recursos criados pelo desenvolvedor, o que reduz a duplicação e faz a ponte entre os mundos declarativo e programático. É a modularidade bem projetada que permite que um recurso seja criado uma vez e reutilizado, em vez de reimplementado e mantido separadamente em cada lugar necessário.

O crescimento de dados não gerenciado é a fonte mais comum de degradação gradual do desempenho e gera custos de armazenamento e tempo de atualização de sandbox em paralelo. Duas decisões regem a eficiência dos dados. A primeira é o design de modelo de dados. Os relacionamentos entre mestre e detalhes fornecem exclusão em cascata, resumos de totalização e compartilhamento de dados ao custo de acoplamento mais rígido. As pesquisas fornecem flexibilidade ao custo da lógica de distribuição personalizada, e uma estratégia de índice deliberada nos campos filtrados mantém as consultas seletivas conforme os objetos crescem. A segunda é o ciclo de vida dos dados. Defina um ciclo de vida completo da criação ao arquivamento em vez de permitir que os objetos acumulem registros indefinidamente, pois um objeto que cresce para milhões sem uma estratégia de arquivamento, eventualmente produz tempos limite de consulta, consultas não seletivas e modos de exibição de lista que atingem o tempo limite.

Escolha o mecanismo de arquivamento apenas depois de definir a conformidade. Antes de escolher um mecanismo, confirme se os requisitos de residência de dados, direito de exclusão ou retenção restringem suas opções. Não é possível modificar Objetos grandes após a inserção, o que torna uma exclusão somente de registros de dados pessoais arquivados uma operação de exclusão e recriação que pode afetar as trilhas de auditoria. Os objetos grandes armazenam conjuntos de dados históricos enormes em armazenamento separados dos limites padrão e combinam transações concluídas e registros de auditoria que não são mais necessários para o trabalho diário. O armazenamento externo mantém os dados consultáveis por meio do Salesforce Connect enquanto reduz o volume da organização e é adequado para padrões de consulta flexíveis ou integração com um armazém de dados corporativo. Monitore o consumo de armazenamento no nível do objeto para que o crescimento fique visível antes de se tornar um problema, use o Salesforce Files em vez de anexos legados e configure a retenção da Trilha de auditoria de campo por campo para o que a conformidade exige, em vez de aplicar um máximo geral que desperdiça armazenamento.

A otimização de custo equilibra o valor dos negócios com o custo da solução e depende de estabelecer um custo preciso em primeiro lugar. Para fazer isso, considere cada componente de custo, pois olhar para um único componente, como custo de licença, leva a uma compreensão incorreta do que a solução realmente custa. Uma taxa de licença modesta pode ocultar custos de implementação, operacionais, de integração e de alteração que o prejudicam. Uma decisão feita apenas sobre o número visível usa apenas parte da imagem. O Custo total de propriedade é o modelo que captura o panorama geral. Ele engloba todos os custos associados a uma solução do Salesforce ao longo da sua vida útil e os separa em custos diretos, que estão claramente associados à solução, e custos indiretos, que são reais, mas fáceis de ignorar. A modelagem de ambos transforma uma estimativa de custo em uma decisão de arquitetura informada que pesa o valor de longo prazo, em vez de apenas a despesa inicial.

Os custos diretos são incorridos pela implementação, operação e manutenção do sistema:

Os custos de licença e consumo são taxas de assinatura contínuas que variam de acordo com a edição, o tipo de usuário e o conjunto de recursos, além de créditos baseados em consumo. A escolha da edição é uma decisão de custo fundamental, pois as diferenças por usuário são significativas. Os custos de consumo são difíceis de modelar com antecedência, portanto, revise essas estimativas conforme as decisões de design são tomadas.
Os custos de implementação cobrem projeto de solução, desenvolvimento, testes, migração de dados e treinamento. Eles são predominantemente únicos, mas criam obrigações de manutenção contínuas proporcionais à complexidade. As empresas sistematicamente subestimam o esforço de implementação porque se concentram em desenvolvimento e subvalorizam testes e treinamento.
Os custos operacionais cobrem administração, suporte ao usuário, monitoramento, resposta a incidentes e ferramentas operacionais. Eles crescem com a complexidade da solução e geralmente são invisíveis no planejamento porque se manifestam como esforço interno, em vez de faturas externas.
Os custos de manutenção cobrem o aprimoramento, a remediação técnica da dívida, a adaptação da liberação e as mudanças de configuração. A manutenção geralmente consome 60 a 80% da capacidade de desenvolvimento para soluções maduras, o que a torna a maior categoria de custo contínuo.
Os custos de integração incluem licenças de plataforma de integração, consumo de API, desenvolvimento de sincronização e manutenção contínua. Eles crescem com a complexidade do ecossistema porque os compostos de manutenção de integração de ponto a ponto aumentam à medida que a contagem do sistema aumenta.
Os custos de mudança cobrem redesign de processos de negócios, gerenciamento de mudanças, adoção e coordenação das partes interessadas. Eles aumentam com o alcance entre unidades de negócios e regiões e geralmente são omitidos porque se manifestam como esforço da equipe de negócios.

Os custos indiretos não são imediatamente visíveis no planejamento inicial, mas se acumulam significativamente ao longo da vida útil de uma solução, e, para implementações maduras, eles geralmente excedem os custos diretos. Uma empresa que otimiza apenas seus custos diretos e ignora gastos indiretos perde a maioria de seu investimento total. Várias categorias merecem atenção explícita.

Os custos organizacionais são os investimentos que promovem o sucesso do Salesforce, mas nunca aparecem em uma fatura do Salesforce. Eles incluem salários da equipe interna para administradores, desenvolvedores e arquitetos, infraestrutura de desenvolvimento, como controle de versão e ferramentas de CI/CD, treinamento e manutenção de certificação e desenvolvimento de habilidades, e o custo de oportunidade da capacidade de desenvolvimento alocada para manutenção, em vez de inovação. Esse último item é difícil de detectar, pois ele não aparece como gasto. Aparece como a inovação que nunca foi enviada.

O juros de débito técnico é o custo de composição de atalhos arquitetônicos. Atalhos feitos para cumprir um prazo de lançamento criam uma carga de manutenção que pode exigir várias vezes o esforço original para ser resolvido mais tarde, e cada sprint gasto para remediar o débito é um sprint que não gera novo valor de negócios. Equipes que adiam melhorias de arquitetura por tempo suficiente acabam descobrindo que a maior parte de sua capacidade vai para manutenção, em vez de novos recursos.

A sobrecarga de governança consome tempo em processos de aprovação, reuniões de coordenação e análises manuais. A governança fornece valor real por meio da redução de risco e da consistência, mas a governança excessiva cria custos ocultos por meio de decisões atrasadas e esforço duplicado, o que faz com que o objetivo seja projetar sistemas que promovam a autonomia segura em vez de exigir um gargalo de aprovação centralizado para cada alteração.

A funcionalidade não utilizada se acumula quando os recursos são implementados, mas nunca totalmente adotados. Uma solução implementada parcialmente consome manutenção em andamento sem entregar valor proporcional, e o monitoramento de utilização de licença e adoção de recurso revela recursos para investir mais ou descontinuar para redirecionar a capacidade.

A visibilidade de custo abrangente exige atribuir itens de linha diretos e indiretos, pois apenas o panorama completo dá suporte a uma boa decisão de investimento.

Crie modelos de TCO para sua linha de base e para alternativas arquitetônicas otimizadas antes de confirmar uma abordagem. Modelos que projetam custos de 3 a 5 anos com pressuposições documentadas permitem comparar opções de maneira sistemática. Execute a análise de confidencialidade nas pressuposições mais importantes para determinar as variações e os limites das estimativas de custo. Planeje revisitar as decisões conforme as condições mudam. A disciplina de escrever as pressuposições faz parte do valor, pois torna uma reavaliação posterior uma comparação baseada em evidências, em vez de um argumento novo.

Avalie as soluções disponíveis comercialmente em relação ao desenvolvimento personalizado usando uma comparação abrangente de TCO, em vez de apenas o custo inicial. As decisões de construção versus compra moldam o investimento de longo prazo por meio de tarifas de assinatura em andamento ou obrigações de manutenção em andamento, e os dois caminhos têm perfis de investimento fundamentalmente diferentes.

O AgentExchange (anteriormente conhecido como AppExchange) é a fonte líder de soluções prontas da comunidade de ISV do Salesforce. Seu perfil de investimento favorece a velocidade e a manutenção compartilhada. A implantação é medida em semanas, em vez dos meses de uma compilação personalizada comparável. O fornecedor mantém a funcionalidade, incluindo compatibilidade de versão da plataforma, sem esforço do cliente. A funcionalidade é comprovada por uma base de clientes existente, o que reduz o risco de implementação. Os recursos especializados se beneficiam de conhecimento do domínio do fornecedor e investimento em pesquisa que excede o que uma única empresa financiaria sozinha. A disponibilidade de suporte varia de acordo com o ISV, geralmente com um caminho de escalação definido para problemas, e carrega um custo de assinatura contínuo para o modelo.

O desenvolvimento personalizado favorece ajuste e controle. Ele se alinha exatamente aos requisitos organizacionais exclusivos sem comprometer padrões de solução genéricos, dá controle total sobre as prioridades de funcionalidade e roteiro, não carrega nenhuma assinatura contínua além das licenças de plataforma básica e pode criar vantagem competitiva por meio de recursos indisponíveis para os concorrentes usando as mesmas soluções prontas para uso. A compensação é que a empresa assume toda a responsabilidade pela manutenção e pela compatibilidade da solução com cada versão do Salesforce.

Uma comparação de TCO de longo prazo transforma esses perfis em uma decisão. As soluções prontas para uso trazem taxas de assinatura anuais complexas, mas incluem atualizações de manutenção, aprimoramento e compatibilidade fornecidas pelo fornecedor. As soluções personalizadas exigem um investimento de desenvolvimento único, mas têm custos de manutenção contínuos, além de responsabilidade total pela compatibilidade da versão. Projete totais de 3 a 5 anos para ambos, de modo que a comparação reflita o investimento completo em vez da despesa inicial, que geralmente favorece a opção que parecia mais barata no primeiro dia.

Além do custo bruto, quatro fatores moldam a decisão de criar vs. comprar.

A diferenciação estratégica determina se uma funcionalidade é uma vantagem competitiva que vale a pena criar ou uma commodity melhor comprada.
O tempo para valorização favorece a compra quando um recurso é necessário imediatamente para capturar uma oportunidade ou responder à pressão da concorrência, pois uma funcionalidade personalizada substancial leva meses.
O recurso organizacional favorece a criação apenas quando há uma equipe interna capaz de manter e evoluir a solução ao longo do tempo e favorece a compra quando essa funcionalidade está ausente.
O custo de saída favorece opções que preservam a flexibilidade, pois uma solução que cria um bloqueio profundo por meio de formatos proprietários ou personalização extensa é um risco se os requisitos mudarem.

Sistematize a decisão para que ela dependa de avaliação consistente, em vez de estimativa ad hoc.

Licença e consumo são entradas para a equação de valor por custo, assim como computação e armazenamento, e estão entre as fontes de resíduos mais comuns. A otimização deles não se refere a reduções simples. Trata-se de combinar cada usuário com a licença certa para seu trabalho e chamar cada serviço medido de maneira eficiente.

A otimização de licença combina cada usuário com o tipo de licença correto. No seu núcleo, é sobre combinar cada usuário na empresa com a licença de que seu trabalho precisa. A licença excessiva, como atribuir licenças de plataforma completas a usuários que precisam apenas de funcionalidades limitadas (acesso somente leitura ou aprovações de fluxo de trabalho simples), é um dos erros mais comuns e caros que as empresas cometem e fica invisível até que alguém olhe. Uma auditoria regular de papéis de usuário, atividade de login e uso de recursos gera economias significativas aumentando o tamanho das atribuições em toda a base de usuários. Execute-o em um ritmo, não apenas na renovação – as incompatibilidades crescem de modo silencioso à medida que os papéis mudam e as pessoas mudam de posição na empresa.

A otimização do crédito de consumo torna-se cada vez mais importante à medida que as empresas adotam o Agentforce, o Data 360 e outros recursos desenvolvidos com IA que preços por uso em vez de por local. Os pools de crédito podem ser esgotados surpreendentemente rapidamente quando as equipes projetam seus processos de modo ineficiente ou não monitoram seus padrões de uso. Diferentemente de uma contagem de licenças fixa, o consumo pode aumentar sem nenhuma decisão de provisionamento ser tomada. Estabeleça visibilidade clara das taxas de queima de crédito, defina limites de consumo que acionam a revisão e projete automações e agentes para serem eficientes em como eles chamam serviços medidos. O mesmo trabalho de eficiência que mantém uma transação dentro dos limites do controlador mantém um serviço medido dentro de seu orçamento de crédito. Essa é a mesma ideia de valor por custo, expressa em termos de consumo.

A estratégia de ambiente e sandbox é uma decisão de recurso com consequências de custo diretas, e um modelo de entrega maduro do Salesforce requer uma estratégia de ambiente bem estruturada. Ambientes de desenvolvimento, teste, preparação e produção atendem a um propósito distinto, e a combinação certa de tipos de sandbox permite que as equipes criem e validem alterações com segurança antes de chegarem à produção. O desafio é que, sem uma governança deliberada, o número de sandboxes ativos se multiplica rapidamente, especialmente em programas grandes ou de execução longa, e aumenta o custo de maneiras que atrapalham as empresas. A solução é tratar o provisionamento de sandbox com a mesma intencionalidade de qualquer outro recurso. Atualize ou desprovisione sandboxes que não estão mais ativamente em uso em vez de deixá-los ociosos, deixe a escolha do tipo de sandbox ser conduzida pela necessidade real de fidelidade de dados, em vez de conveniência, e defina políticas claras para propriedade, ritmo de atualização e desativação para que a propriedade permaneça dimensionada para o trabalho.

A arquitetura de várias organizações multiplica o custo. Uma arquitetura de organização única se beneficia de licenciamento consolidado, infraestrutura de plataforma compartilhada e sobrecarga administrativa reduzida, pois simplesmente há menos para gerenciar, configurar e manter. Quando todas as unidades de negócios operam em uma organização, as integrações são internas em vez de organizações cruzadas, o compartilhamento de dados é nativo e a pegada total de sandboxes, suporte e ferramentas de governança permanece proporcionalmente menor. As arquiteturas de várias organizações, embora às vezes sejam necessárias para geografia, conformidade regulatória ou separação organizacional, apresentam um efeito multiplicador em algumas categorias de custo. Cada organização adicional traz seus próprios requisitos de licenciamento, sua própria propriedade de sandbox, sua própria sobrecarga de integração e seu próprio esforço administrativo, e exige ferramentas mais sofisticadas para gerenciar a implantação entre organizações, a federação de identidade e a sincronização de dados. Entenda o verdadeiro custo total de propriedade para cada organização adicional antes de tomar uma decisão arquitetônica difícil e cara de reverter.

Os custos de API e integração estão entre os fatores de custo mais subestimados em um ecossistema do Salesforce. Conectar o Salesforce a um sistema externo pode parecer simples, mas os requisitos de integração complexos rapidamente acumulam custos em licenciamento de middleware, esforço de desenvolvimento, manutenção em andamento e consumo de API que flui de cada troca de dados. Empresas com muitos sistemas integrados, altos volumes de dados ou requisitos de sincronização quase em tempo real estão especialmente expostas. A abordagem arquitetônica importa aqui. Integrações simples e finas que tornam pequenas chamadas à API frequentes mais caras e mais frágeis do que padrões bem projetados em massa ou conduzidos por evento que minimizam as viagens de ida e volta e multiplicam os compostos de diferença conforme os aplicativos conectados. Controle os padrões de design de integração, consolide as plataformas de integração quando possível e revise regularmente se as integrações existentes ainda funcionam com a eficiência que foram projetadas originalmente.

Uma arquitetura sustentável exige mais do que otimizações de design iniciais. Isso exige supervisão contínua e responsabilidade estruturada. O monitoramento de custo e a governança são a estrutura que transforma a otimização de um exercício único em uma prática operacional contínua. Rastreamento consistente e propriedade clara reduzem o risco de excedentes de custo inesperados para que cada dólar gasto se alinhe ao valor dos negócios.

Crie visibilidade dos padrões de gasto por meio de painéis acessíveis a equipes técnicas e partes interessadas de negócios para que as conversas de investimento dependam de dados, em vez de faturas. A visibilidade de custo inicia uma conversa orientada por dados sobre prioridades de investimento e oportunidades de otimização e funciona melhor quando três visualizações distintas estão disponíveis. Os painéis de utilização de licença revelam usuários inativos, usuários sobrelicenciados e incompatibilidades do tipo de licença, que são as oportunidades de otimização ocultas dentro de uma contagem simples. Os painéis de capacidade mostram o consumo de armazenamento, API e processamento com tendências de crescimento, de modo que as equipes otimizam antes de um limite causar uma interrupção, em vez de depois. Os painéis de investimento mostram gastos por unidade de negócios, custos ambientais pela equipe proprietária, custos complementares em relação à utilização e gastos projetados com base no crescimento atual, o que transforma uma conversa de orçamento em uma conversa de alocação.

Esses painéis podem vir de uma variedade de ferramentas, incluindo Digital Wallet e relatórios personalizados que consultam metadados. A ferramenta é menos importante que a disciplina de exibir os dados em que as decisões são tomadas. Compartilhe os painéis com as partes interessadas dos negócios e a liderança para criar a transparência para uma discussão de investimento informada em vez de um debate de orçamento reativo. Uma equipe financeira que vê padrões de utilização pode otimizar o gasto. Uma equipe que vê apenas uma fatura total só pode cortá-la.

Implemente a conscientização de gasto em toda a empresa, incluindo alertas proativos que sinalizam a otimização antes de você exceder os limites:

Os orçamentos de licença definem metas de alocação por departamento com alertas à medida que se aproximam da capacidade, de modo que o provisionamento não controlado não é detectado apenas na renovação.
Os orçamentos de armazenamento monitoram a taxa de crescimento com alertas quando as tendências projetam ultrapassar limites antes do próximo ciclo de renovação. Esses alertas fornecem um aviso antecipado para que o arquivamento possa ser implementado antes que ocorram excedentes.
Os orçamentos da API rastreiam o consumo em relação aos limites com alertas em limites de utilização de exemplo, como 70% e 85%, de modo que a otimização é proativa e não uma resposta de emergência depois que os limites causam falhas.
Os orçamentos de sandbox controlam a proliferação ambiental por meio de limites de alocação e processos de aprovação.

Os controles de orçamento criam consciência de custo sem bloquear o investimento necessário. Os limites de alerta fornecem avisos antecipados que permitem uma otimização cuidadosa em vez de uma manipulação reativa.

A alocação de custo cria responsabilidade e tomada de decisão informada entre unidades de negócios, e as empresas a implementam por meio de um dos dois modelos que diferem quanto à responsabilidade que impõem. O Showback relata os custos por unidade de negócios sem aplicar uma cobrança financeira real. Ela cria transparência e promove a discussão e a priorização de otimização sensíveis ao custo sem a contenção de faturamento interno, o que é adequado para uma empresa que prefere o gerenciamento de custo colaborativo em vez da responsabilidade financeira. O Chargeback aloca os custos reais a unidades de negócios e cria a responsabilidade financeira direta para decisões de consumo. Ela gera um comportamento de otimização mais forte porque os custos afetam diretamente os orçamentos do departamento, mas exige uma metodologia de alocação precisa para evitar disputas sobre quem paga por quê. De qualquer forma, as regras de alocação seguem a mesma lógica: custos de licença por departamento do usuário, custos ambientais por propriedade da equipe de desenvolvimento, custos de integração pelo processo de negócios que consome a integração e custos de desenvolvimento pela iniciativa que financia o trabalho. Quando essas regras estão ausentes, cada custo fica em um orçamento de TI central e as partes interessadas da empresa tratam a plataforma como gratuita, que é precisamente a condição que produz solicitações feitas sem consciência de custo.

Adapte as práticas FinOps da nuvem à economia da plataforma Salesforce para criar um recurso de otimização contínua em vez de uma limpeza periódica. Cinco práticas têm o peso.

A colaboração interfuncional entre as partes interessadas financeiras, de arquitetura e de negócios garante que as decisões de custo ponderem o valor comercial junto com o gasto. Ele leva conhecimento financeiro para discussões de arquitetura e compreensão técnica para planejamento de orçamento.
Um ritmo de otimização contínuo impede o desvio de custos pelos ciclos de revisão regulares: uma revisão de anomalia mensal que captura picos de gasto, uma auditoria de utilização trimestral que valida atribuições de licença e uso de capacidade e uma avaliação de TCO abrangente anual que realinha o gasto com prioridades estratégicas.
As decisões de investimento orientadas por dados usam dados de utilização e modelos de TCO em vez de pressuposições ou hábitos históricos. Essas decisões substituem "sempre fizemos assim" pela análise de se o gasto atual fornece o valor ideal.
A automação do monitoramento de custo reduz o esforço manual de rastreamento de utilização, identificação de oportunidades de otimização e geração de relatórios, de modo que a prática é dimensionada com a complexidade organizacional sem crescimento linear da equipe.
A educação sobre custo-benefício ajuda as equipes a entender como as decisões arquitetônicas afetam o custo total de propriedade, pois um arquiteto que entende o custo projeta melhores compensações e um desenvolvedor que entende a economia da plataforma escreve automação mais eficiente.

Integre a consciência de custo ao processo de análise de arquitetura para que as implicações de investimento sejam visíveis junto com considerações funcionais e técnicas, em vez de descobertas após a implementação. Inclua uma avaliação de impacto de custo nos Registros de decisão de arquitetura que documente as principais opções de design. Exigir uma projeção de TCO para soluções que excedem um limite de investimento definido. Avalie as implicações de licença durante o design, determinando se uma abordagem requer licenças premium ou complementos antes de ser confirmada. Avalie o custo de integração antes de adotar um padrão que afete o consumo da API ou o licenciamento de middleware. Um painel de análise de arquitetura que leva uma perspectiva de custo junto com requisitos funcionais e não funcionais produz decisões de investimento mais alinhadas. Trate o custo como uma entrada em uma decisão de arquitetura, em vez de seu único condutor, para que as empresas investam adequadamente no que é importante, ao mesmo tempo que evitam desperdício no que não é.

A sustentabilidade da computação em nuvem se concentra em minimizar o impacto ambiental da infraestrutura digital por meio do uso eficiente dos recursos e se alinha naturalmente ao valor por custo: a mesma eficiência que reduz o consumo de recursos também reduz o custo. A Salesforce e os arquitetos compartilham a responsabilidade pelos resultados de sustentabilidade. O Salesforce gerencia a infraestrutura do data center, incluindo otimização de eficiência de uso de energia, eficiência de resfriamento e gerenciamento de ciclo de vida do hardware, junto com o pool de recursos de vários locatários e melhorias de eficiência no nível da plataforma. Você influencia os padrões de consumo de recursos de suas soluções dentro desse ambiente multilocatário.

O relacionamento entre uma solução individual e as emissões do data center é indireto, e ser preciso sobre isso é importante. As otimizações de um único locatário não reduzem diretamente as emissões do data center. O que eles fazem é contribuir para um efeito agregado: ganhos de eficiência em todos os locatários permitem que o Salesforce opere sua infraestrutura com maior utilização e adiar a expansão de capacidade. As métricas de eficiência de recursos, incluindo consultas SOQL, tempo de CPU, consumo de heap e armazenamento, servem, portanto, como indicadores proxy para sustentabilidade. Eliminar o desperdício de computação melhora o desempenho e o custo e contribui para os objetivos de eficiência de toda a plataforma. Os princípios de design nesse pilar, incluindo massificação, consultas seletivas, armazenamento em cache, processamento assíncrono e ciclo de vida de dados disciplinado, criam soluções que consomem menos recursos. A sustentabilidade não é uma iniciativa separada integrada à arquitetura. É assim que a eficiência do recurso se parece quando você a mede em relação ao impacto ambiental, em vez de apenas em relação ao custo financeiro.

Várias práticas arquitetônicas carregam a maior parte do valor de sustentabilidade, e cada uma também melhora o desempenho ou o custo, o que faz com que pertençam ao mesmo pilar.

Automação inativa consome recursos de infraestrutura sem fornecer nenhum valor de negócio. Acionadores que processam registros irrelevantes, fluxos de trabalho que são executados desnecessariamente e trabalhos agendados que são executados quando não há trabalho, são todos resíduos de cálculo, armazenamento e energia. A solução é uma auditoria de automação trimestral com critérios explícitos para o que conta como não utilizado: nenhuma execução nos últimos 90 dias, trabalhos em lote que processam de modo consistente zero registros e automação substituídos por implementações mais novas, mas nunca desativados. Documente cada desativação para que ela possa ser revertida se um requisito de negócios for exibido novamente. Uma empresa com dezenas de Process Builders restantes de implementações anteriores, a maioria sem execuções no último ano, paga para avaliar cada um deles em cada salvamento de registro relevante.

Agendar operações com uso intensivo de recursos fora do horário de pico distribui a carga entre janelas de tempo. Em um ambiente de vários locatários, essa disciplina melhora a responsividade da plataforma durante o horário comercial e, agregado entre locatários, permite que o Salesforce opere a infraestrutura com maior utilização média. Agende o arquivamento em lote, aprimoramento e limpeza para janelas de baixo uso, escalonie trabalhos em vez de iniciar 20 à meia-noite e causar um pico de processamento e prefira padrões conduzidos por evento em vez de pesquisas agendadas para que nenhum ciclo seja gasto verificando trabalho que não está lá.

Calcular o mesmo valor repetidamente desperdiça ciclos de CPU e capacidade da infraestrutura. Calcule uma vez, armazene o resultado em cache e reutilize-o entre transações e usuários. O Cache da plataforma fornece dados de referência consultados repetidamente, valores de distribuição armazenados em cache evitam consultas agregadas em tempo real quando a precisão quase em tempo real é suficiente, campos de fórmula são recalculados dinamicamente no acesso ao registro em vez de armazenar um valor e exigem automação para mantê-lo, e o Lightning Data Service elimina solicitações de servidor redundantes no cliente. Cada cálculo evitado é a capacidade retornada à plataforma.

O armazenamento de dados consome recursos de infraestrutura e degrada o desempenho da consulta à medida que cresce. As políticas de retenção que arquivam ou excluem dados que não são mais necessários para operações ativas mantêm as tabelas ativas pequenas e as consultas rápidas. Arquive registros antigos em objetos grandes ou armazenamento externo em um trabalho agendado, exclua permanentemente quando estiver em conformidade, em vez de depender de exclusão temporária que continue consumindo armazenamento, e configure a retenção da Trilha de auditoria de campo por campo, em vez de aplicar um máximo que armazene muito mais histórico do que o necessário para a conformidade. Como acontece com o processamento agendado, as decisões de arquivamento individuais não reduzem diretamente o uso de energia do data center, mas a disciplina de ciclo de vida de dados agregado em todos os locatários melhora a eficiência da plataforma e atrasa a expansão da infraestrutura de armazenamento.

Integrações externas consomem recursos tanto no Salesforce quanto nos sistemas aos quais ele se conecta. A Captura de dados de alteração e outros padrões conduzidos por eventos eliminam as chamadas de pesquisa que verificam repetidamente alterações e não encontram nenhuma, o que reduz o consumo da API, beneficia os limites do regulador e elimina o cálculo desperdiçado. Os padrões de API compostos agregam várias operações em uma única chamada, a API em massa v2 processa grandes volumes com muito mais eficiência do que milhares de chamadas REST individuais, e a lógica de repetição com reversão exponencial evita que um sistema externo tenha dificuldade. Uma única integração que pesquisa a cada cinco minutos e não encontra nada para fazer a maior parte do tempo é pura perda, enquanto a mesma integração conduzida por eventos de alteração processa apenas alterações reais.

As arquiteturas de agente consomem recursos computacionais por meio de uma inferência de modelo de idioma grande e a mesma mentalidade de eficiência se aplica. Minimize a duração do aviso, resuma o histórico da conversa em vez de levar transcrições verbais completas que crescem sem limite, use o menor modelo suficiente para uma tarefa em vez de usar como padrão o mais capaz e armazene em cache dados de referência e respostas determinísticas. Recuperar 50 resultados de pesquisa vetorial quando apenas 5 forem avaliados gasta recursos de inferência e recuperação sem valor adicional, portanto, configure limites de recuperação para corresponder ao uso real.

A sustentabilidade, como o restante desse pilar, requer monitoramento contínuo, em vez de uma passagem única, pois os padrões de consumo de recursos mudam conforme as soluções evoluem, os volumes de dados aumentam e as populações de usuários se expandem. O monitoramento importa apenas quando aciona uma ação. Defina limites acionáveis para cada métrica – contagem de consultas SOQL que excede uma meta por transação, crescimento de armazenamento além de uma porcentagem mensal ou uma taxa de interação de cache abaixo de uma meta – e documente quais otimizações realizar primeiro. Concentre o esforço em transações de alto volume e automação executada com frequência, em que as melhorias de eficiência têm o maior impacto agregado. O Criador de processos atingiu o fim do suporte em 31 de dezembro de 2025 Migre os criadores de processos restantes para o Fluxo; não simplesmente desative-os.

Use essa lista de verificação para avaliar se uma solução retorna o valor máximo por custo. Ele combina as práticas de eficiência de recursos e custo-disciplina desse pilar em uma revisão, pois as duas são uma única decisão.

Modelização de valor e custo

Conecte cada investimento significativo do Salesforce a um resultado de negócios mensurável.
Modele o custo total de propriedade entre categorias diretas, indiretas, únicas e contínuas antes de confirmar uma abordagem.
Compare o TCO para a linha de base e para alternativas de arquitetura otimizadas em um horizonte de 3 a 5 anos.
Aplique uma avaliação de compilação vs. compra consistente que pondera diferenciação estratégica, tempo para valor e custo de saída em vez de depender de estimativas ad hoc.

Eficiência dos recursos

Projete transações para operar confortavelmente dentro dos limites do controlador sob carga máxima e volumes máximos de dados.
Torne as consultas seletivas em campos indexados e valide com a Ferramenta do plano de consulta antes de implementar em objetos grandes.
Massifique todas as operações de dados e escolha o processamento assíncrono deliberadamente quando os limites síncronos o exigirem.
Armazenar em cache os dados de referência por meio do Cache da plataforma e do Lightning Data Service para evitar consultas repetidas e recálculos.
Evite o desvio de dados distribuindo o carregamento e monitorando objetos de alto volume.
Centralize a lógica de acionador, serviço e seletor para que a lógica de negócios permaneça testável e barata para alteração.
Defina um ciclo de vida de dados completo da criação ao arquivamento e monitore o consumo de armazenamento no nível do objeto.

Licenciamento e consumo

Combine cada usuário com o tipo de licença exigido pelo trabalho e audite os papéis, a atividade de login e o uso de recursos regularmente.
Estabeleça visibilidade das taxas de queima de crédito de consumo e projete automações e agentes para chamar serviços medidos com eficiência.
Controle o provisionamento de sandbox com propriedade clara, ritmo de atualização e políticas de desativação.
Entenda o multiplicador de custo completo de várias organizações antes de adicionar uma organização e favorecer integração em massa ou conduzida por evento em relação a padrões de chat.

Monitoramento e governança

Forneça painéis de custo e capacidade acessíveis a equipes técnicas e partes interessadas de negócios.
Defina alertas de orçamento para licenças, armazenamento, consumo de API e sandboxes para que a otimização seja proativa em vez de reativa.
Estabeleça um showback ou um chargeback para que a alocação de custo crie responsabilidade entre unidades de negócios.
Adote um ritmo FinOps: revisão de anomalia mensal, auditoria de utilização trimestral e avaliação de TCO abrangente anual.
Integre a avaliação de impacto de custo a revisões de arquitetura e registros de Decisão de arquitetura.

Otimização contínua e sustentabilidade

Trate a otimização como uma prática contínua e valide se os investimentos de otimização anteriores geraram o retorno esperado.
Elimine automação não utilizada e cálculos redundantes por meio de auditorias regulares.
Acompanhe o consumo do recurso ao longo do tempo e defina limites acionáveis que acionam a otimização quando uma métrica os cruza.

Compartilhe seu feedback sobre o Framework bem-construído.