Lea sobre nuestras programaciones de actualizaciones aquí.

Las soluciones intencionadas entregan valor de negocio inmediatamente y a lo largo del tiempo. Las arquitecturas intencionales se planifican y se entregan de forma estratégica, se pueden mantener de forma efectiva y son fáciles de leer y comprender para los humanos.

Las funciones y soluciones se priorizan y se entregan de formas transparentes para las partes interesadas de negocio y tecnología por igual. Las opciones de ingeniería crean implementaciones que son fáciles de trabajar para los equipos de entrega y mantenimiento, sin funciones o complicaciones agregadas. Las arquitecturas intencionales son más fáciles de poseer, mantener y evolucionar con el negocio porque siguen patrones de implementación claros y coherentes. Los constructores pueden interpretar e implementar diseños para nuevas funciones, y los equipos de mantenimiento pueden comprender la documentación de lo que se implementó.

Puede crear sistemas más intencionados centrándose en tres áreas clave: estrategia, capacidad de mantenimiento y capacidad de lectura.

Estrategia en arquitectura significa que los sistemas se planifican y entregan cuidadosamente. Significa que los equipos de entrega y mantenimiento tienen una visión clara del trabajo que se debe realizar hoy y en el futuro, y todos están alineados en torno al “por qué” del trabajo que se debe realizar. Significa que las solicitudes urgentes se pueden procesar de forma efectiva y eficiente, y las partes interesadas pueden comprender claramente la repercusión y las ventajas de las solicitudes.

Puede construir una estrategia más clara en su arquitectura centrándose en la priorización, la hoja de ruta y la gobernanza.

Priorización significa planificar el orden y el ámbito del trabajo que entregará. La priorización implica comprender la repercusión real de los productos en el negocio, evaluar esas repercusiones frente a otras solicitudes de trabajo y la hoja de ruta general para su producto o programa.

Una forma de evaluar la repercusión de un elemento de trabajo concreto es ver el costo o beneficio real para el negocio. Una vez que haya identificado los KPI para la automatización, puede utilizar una hoja de cálculo de impacto de negocio para evaluar el costo o beneficio general de la implementación. Estos cálculos pueden ayudarle a obtener la alineación y la aceptación de sus partes interesadas acerca de qué automatizaciones crear y en qué orden. También pueden ayudarle a identificar automatizaciones para posponer o evitar. Para automatizaciones, consulte Diseño de procesos para obtener más información acerca de la identificación de trabajo efectivo.

Establecer un marco de prioridades para la entrega también le ayudará a usted y a sus equipos de mantenimiento a gestionar las expectativas de los usuarios y permanecer alineados con su hoja de ruta.

Algunas consideraciones que puede utilizar para la priorización incluyen:

• Repercusión de negocio (costo/beneficio) del producto
• Cantidad de nuevo trabajo requerido para el producto
• Cantidad de trabajo requerido para mantener el producto

La lista de patrones y antipatrones a continuación muestra el aspecto de la priorización apropiada (y deficiente) cuando se trata de trabajo de Salesforce. Puede utilizarlos para validar sus planes de implementación o identificar dónde necesita identificar mejor las prioridades antes de construir.

Para obtener más información acerca de las herramientas disponibles en Salesforce para obtener ayuda con la priorización, consulte Herramientas relevantes para intencional.

Una hoja de ruta es una vista priorizada, validada y bien definida de lo que se debe hacer. Las hojas de ruta efectivas proporcionan una imagen clara de la repercusión de negocio y la repercusión tecnológica del trabajo futuro. Implicar a sus partes interesadas de negocio y técnicas es una parte clave de la hoja de ruta. Las hojas de ruta le permiten obtener comentarios y aceptación sobre el enfoque y los resultados antes de que comience cualquier trabajo. En última instancia, las hojas de ruta alinean a todas las partes interesadas sobre el “por qué” del trabajo por delante.

Si su equipo utiliza un retraso, es importante comprender que su hoja de ruta no es un resumen o una lista de los elementos en el retraso. La relación es la opuesta: Los elementos solo se incluyen en el retraso si se pueden vincular de forma clara y creíble a un producto en su hoja de ruta. Las hojas de ruta de alta calidad, creadas con la participación de las partes interesadas, proporcionan a los equipos de entrega y mantenimiento una visión clara de en qué deben centrarse y cómo deben priorizar las solicitudes, facilitando la tarea de ordenar las solicitudes en conflicto y gestionar las expectativas de las partes interesadas.

Una hoja de ruta deficiente o inexistente lleva a:

• Falta de claridad sobre cuándo estarán disponibles nuevas funciones y características
• Prioridades en conflicto entre las partes interesadas
• Una desconexión entre las soluciones que se están entregando y la visión organizativa general
• Dificultad para comprender qué trabajo está en curso
• Cargas de trabajo desiguales entre equipos
• Falta de visibilidad de las relaciones y dependencias entre elementos de trabajo
• Implementaciones estancadas, debido a dependencias mal gestionadas

Las partes interesadas a menudo necesitan información que se ajuste a sus funciones para poder tomar decisiones. La creación de hojas de ruta efectivas requiere una comprensión clara de su audiencia y el tipo de información que necesita. Las hojas de ruta se categorizan en dos estilos para dar cobertura a audiencias de negocio y técnicas. Cada estilo contiene dos niveles de granularidad para admitir diferentes tipos de información.

Las hojas de ruta de negocio ayudan a las partes interesadas a planificar cambios organizativos, capitalizar oportunidades de crecimiento y permanecer alineadas con objetivos corporativos. Las hojas de ruta de negocio también proporcionan una forma de garantizar que el gasto de TI se alinea con la visión de negocio general.

• Cree una hoja de ruta de funciones de negocio para mostrar a las partes interesadas ejecutivas las funciones que se activarán. Este tipo de hoja de ruta contiene detalles de alto nivel sobre las funciones en sí mismas y cómo se alinean con los objetivos de negocio, como el aumento de la eficiencia operativa o el lanzamiento de una nueva línea de productos.
• Cree una hoja de ruta de funciones de negocio para desglosar una función específica y mostrar sus funciones y funciones de asistencia cuando necesite ayudar a las partes interesadas de negocio con la planificación de recursos, el presupuesto y la gestión de cambios.

Las hojas de ruta de tecnología ayudan a las partes interesadas técnicas con la planificación de presupuestos y asignaciones de recursos. También ayudan a los equipos de implementación a comprender dónde se ajustan sus proyectos como parte de una imagen general más amplia e identificar cualquier dependencia entre equipos.

• Cree una hoja de ruta del sistema de tecnología para mostrar los sistemas específicos que se implementarán, junto con cualquier dependencia a nivel del sistema. Este tipo de hoja de ruta muestra información de sistema de alto nivel y la alineación entre sistemas y funciones de negocio.
• Cree una hoja de ruta de componente de tecnología para desglosar los componentes específicos de un sistema que se implementará para ayudar con la planificación de recursos y los requisitos de habilitación. Este tipo de hoja de ruta muestra información a nivel de componente y requisitos de implementación (por ejemplo, desarrollo declarativo, procódigo, etc.).

Asegúrese de que sus hojas de ruta contienen cronologías realistas. Un error común es incluir solo la cantidad de tiempo que se tardará en implementar un sistema sin tener en cuenta también la cantidad de tiempo que se tardará en completar las actividades relacionadas. Esto puede dar como resultado una asignación excesiva de miembros del equipo de implementación y retrasos más largos de lo previsto. Al crear una hoja de ruta, tenga en cuenta el tiempo que tardará en completar lo siguiente:

• Documentación de todas las funciones nuevas y actualizadas
• Mantenimiento de funciones existentes necesarias para dar cobertura a nuevas funciones
• Actualizaciones en sistemas relacionados requeridas para admitir integraciones
• Asistencia elevada de los equipos de proyectos inmediatamente después del lanzamiento
• Pruebas, capacitación y gestión de cambios

Las hojas de ruta de negocio y tecnología que están bien alineadas comunican una visión holística de cuándo se pondrán en marcha las funciones y qué tecnología hay detrás de ellas. La lista de patrones y antipatrones a continuación muestra el aspecto de las hojas de ruta apropiadas (y deficientes) para una organización de Salesforce. Puede utilizarlos para validar o mejorar su estrategia de hoja de ruta.

Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle con la hoja de ruta, consulte Herramientas relevantes para intencionado.

La gobernanza es la estructura que utiliza para gestionar la priorización, la toma de decisiones y la gestión de cambios con sus partes interesadas. La gobernanza deja claro cómo se toman y se comunican las decisiones. Proporciona formas coherentes para que los comentarios y las solicitudes entren en el proceso de toma de decisiones, y para que todas las partes interesadas comprendan el estado del trabajo de mantenimiento y desarrollo. La gobernanza ayuda a que los procesos de gestión de versiones sean claros y coherentes, y ayuda a todos los miembros del equipo a comprender sus funciones y responsabilidades.

Sin una gobernanza apropiada, los equipos experimentarán una variedad de problemas, incluyendo:

• Las solicitudes de funciones y funciones superpuestas llegan ad hoc
• Los equipos de implementación priorizan esfuerzos "más sencillos" o solicitudes de partes interesadas más influyentes, sin tener en cuenta adecuadamente el valor de negocio, las compensaciones o los objetivos organizativos generales
• Falta de procesos de aprobación y revisión coherentes
• Calidad y cadencias de versión incoherentes
• Altos índices de defectos, sobrescrituras, conflictos y trabajo redundante en esfuerzos de desarrollo

Quizás la señal más clara de que un sistema no tiene una regulación efectiva es la lentitud y la incomodidad de las versiones. Es importante reconocer que el tamaño de un sistema de gobernanza no es una medición de su eficacia. De hecho, los sistemas elaborados para la gobernanza (como los que se encuentran en muchas grandes empresas) pueden limitar la velocidad y la frecuencia de las versiones.

La buena gobernanza consiste en dificultar que las personalizaciones incorrectas superen las etapas tempranas del desarrollo y obtener buenas personalizaciones en producción de forma predecible y coherente.

Con demasiada frecuencia, los esfuerzos de gobernanza son reaccionarios. Se inician o redoblan cuando un problema, como una deuda técnica excesiva, comienza a convertirse en un problema de negocio. En muchos casos, la respuesta desafortunada es que el negocio “bloquee” los esfuerzos y las versiones de desarrollo, en vez de crear estándares de diseño efectivos y crear automatización para aplicar esos estándares en cadenas de herramientas de desarrollador y sistemas de control de origen.

Cuando cree el marco de trabajo para su sistema de gobernanza de Salesforce, incluya los siguientes elementos y considere estas preguntas clave para responder:

• Solicitudes de trabajo. ¿Cómo pueden los usuarios solicitar funciones o características? ¿Cómo se reportan los fallos?
• Priorización y planificación de trabajo. ¿Quién decide qué solicitudes de trabajo importan? ¿Cómo se define el ámbito, la prioridad y la aceptación o el inicio de sesión del trabajo?
• Entornos y planificación de versiones. ¿Cuál es la canalización de entorno para el desarrollo, las pruebas y la versión? ¿Quién hace qué para aprovisionar, actualizar y proporcionar acceso? ¿Quién gestiona las implementaciones y la validación? ¿Cómo y cuándo se publican los cambios? ¿Cómo gestiona implementaciones o entornos durante un ciclo de versión de Salesforce? (Para obtener más información sobre esto, consulte Gestión del ciclo de vida de la aplicación.)
• Propiedad del servicio y asistencia de producción. ¿Quién admite qué? ¿Quién gestiona problemas de producción de “solución rápida”? ¿Cómo se prueban y se publican esos elementos? ¿Quién es responsable de los estándares de seguridad generales de la organización?

La lista de patrones y antipatrones a continuación muestra el aspecto de la gobernanza adecuada (y deficiente) para una organización de Salesforce. Puede utilizarlos para validar o mejorar su estrategia de gobernanza.

Para obtener más información acerca de las herramientas de Salesforce disponibles para la gobernanza, consulte Herramientas relevantes para intencionado.

La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección.

✨ Descubra más patrones para la estrategia en el Explorador de patrones y antipatrones.

La capacidad de mantenimiento significa que un sistema puede mantenerse en un estado saludable, con nuevas funciones moviéndose hacia y deudas técnicas moviéndose fuera del sistema de forma regular y predecible. Los sistemas con capacidad de mantenimiento permiten a sus equipos ofrecer valor al negocio con velocidad y calidad predecibles. La capacidad de mantenimiento de un sistema depende de varios factores, incluyendo cuán legible es, cuán poco acoplado está y cuán minuciosa es su estrategia de prueba.

Lo que es más importante, la capacidad de mantenimiento de un sistema depende de la sencillez de su diseño. Esta sección trata formas de crear diseños de soluciones más sencillos y aumentar la capacidad de mantenimiento.

Puede crear soluciones que son más fáciles de mantener centrándose en dos claves: el uso de funciones estándar sobre personalizadas y la gestión de deudas técnicas.

Salesforce ofrece una gama de soluciones preconstruidas: Sales Cloud, Service Cloud y muchas soluciones de la industria de Salesforce, así como la flexibilidad de crear sus propias soluciones personalizadas. Los servicios fundacionales que impulsan las soluciones en la nube propias de Salesforce también están disponibles para cualquier solución personalizada creada sobre Salesforce Customer 360 Platform. Utilice los servicios y soluciones preintegrados de Salesforce como base de confianza para el mayor número posible de sus soluciones.

El uso de servicios de plataforma preintegrados tiene dos beneficios distintos. En primer lugar, sus aplicaciones se benefician naturalmente de las últimas innovaciones de Salesforce con cada versión. En segundo lugar, sus equipos de desarrollo pueden centrarse en ampliar y profundizar las funciones de negocio proporcionadas por sus soluciones de Salesforce en vez de gestionar tareas pesadas de arquitectura básica.

Seleccionar correctamente cuándo utilizar funciones estándar y cuándo crear funciones personalizadas no es un reto desde el punto de vista arquitectónico. Las claves son:

• Personalizar la plataforma significa modificar y ampliar, no copiar. A medida que diseña o evalúa su arquitectura, debe preguntar: ¿Existe ya esto en algún punto de la plataforma Salesforce? Si la respuesta es “Sí, pero...[inserte cambios que una parte interesada de negocio desea aquí...]”, utilice la función preconstruida en la plataforma. El trabajo arquitectónico que se debe realizar es identificar las formas más útiles de configurar la función de Salesforce preconstruida para cumplir las expectativas de negocio.
• Ninguna personalización es trivial. Con el tiempo, cada cambio tiene consecuencias. Si necesita implementar una solución personalizada, puede mitigar la inevitable deuda técnica que generará su sistema seleccionando utilizar tecnología de código bajo siempre que sea posible y creando unidades con capacidad de composición en sus implementaciones.
• Considere el espectro build-buy. Salesforce AppExchange es un mercado de aplicaciones y soluciones para ampliar Salesforce. Las aplicaciones AppExchange pueden entregar funciones sin la carga de trabajo que implica crear y mantener una solución personalizada. Tenga en cuenta lo siguiente cuando evalúe soluciones AppExchange:
  • Identifique funciones y brechas de soluciones. Idealmente, encontrará una aplicación que cumple todos sus requisitos de negocio. En realidad, es posible que no encuentre un ajuste perfecto. A medida que evalúa soluciones, asigne funciones en la solución potencial a una lista priorizada de requisitos de negocio. Esto le ayudará a encontrar la solución que mejor se ajuste a sus requisitos más críticos.
  • Utilice sandboxes y pruebas gratuitas. Utilice periodos de prueba gratuitos para evaluar aplicaciones en entornos sandbox e identificar el mejor ajuste. Determine si las aplicaciones le requerirán realizar cambios de configuración que entren en conflicto con su configuración existente.
  • Considere costos a corto y largo plazo. Evalúe los ahorros de mantenimiento de aplicaciones a largo plazo frente a los costos recurrentes de aplicaciones basadas en suscripciones. Evite escenarios donde tenga que pagar costos recurrentes por muchas funciones que sus partes interesadas de negocio nunca utilizarán.
• Utilice los modelos de datos preintegrados desde Salesforce. Salesforce proporciona modelos de datos preintegrados para Ventas, Servicio y una variedad de verticales de la industria. El uso de los modelos de datos proporcionados por Salesforce garantiza que las funciones en su sistema se definan solo una vez (eliminando la redundancia y los silos), establece una única fuente de verdad en todo el sistema, facilita la comprensión de los datos de la aplicación con análisis, facilita el uso de los servicios de inteligencia artificial preintegrados de Salesforce, reduce los costos de mantenimiento (reduciendo las personalizaciones que necesita asistencia) y reduce la deuda técnica.

Así de simple. Como puede ver en los patrones y antipatrones a continuación, los antipatrones se reducen a la replicación de funciones estándar en una solución personalizada o el uso de tecnología más compleja para entregar personalizaciones.

En la práctica, es posible que se encuentre con un escenario en el que las partes interesadas de negocio vean un antipatrón de funciones personalizado como la mejor o única forma viable de avanzar. En estos casos, es esencial que explique a las partes interesadas las compensaciones implicadas en la elección de esta ruta y luego documente minuciosamente la decisión, su justificación y su implementación. Este es también un área donde la entrega de valor principal de forma temprana y la adaptación con el tiempo pueden ayudar a sus partes interesadas a comprender mejor el mejor camino a seguir.

Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle a aumentar la capacidad de mantenimiento, consulte Herramientas relevantes para intencionado.

La deuda técnica es una parte natural de cualquier sistema. Los diseños de sonido de ayer pueden convertirse en antipatrones cuando cambian las necesidades de tecnología o negocio. Quizás algo creado para rellenar un vacío en la funcionalidad de la plataforma Salesforce de repente se convierte en redundante con una nueva versión de Salesforce o lanzamiento de producto. Quizás una tecnología de mayor desempeño o flexible sustituya a una tecnología que ya implementó. La deuda técnica se puede crear de muchas formas.

Un beneficio clave de la creación de aplicaciones con Salesforce Customer 360 Platform es la retrocompatibilidad incorporada en la plataforma. Esto significa que las nuevas innovaciones de plataforma pueden cambiar el patrón que debe utilizar para soluciones que avanzan, pero la función diaria de soluciones que creó en tecnologías anteriores de Salesforce seguirá funcionando. Con el tiempo, cualquier solución basada en tecnología antigua comenzará a plantear riesgos o cuellos de botella para agregar nuevas funciones a sus aplicaciones, y disminuirá el estado general de la solución.

La planificación y la realización de trabajo regular para abordar la deuda técnica es esencial para mantener diseños sencillos y saludables en una solución de Salesforce. No planificar, auditar y remediar deudas técnicas es una forma segura de crear un sistema mal diseñado.

Una forma de minimizar la deuda técnica es evitar introducirla en la medida de lo posible, evitando accesos directos y prefiriendo la funcionalidad estándar sobre la personalizada. Los accesos directos, como los valores de codificación permanente, pueden ser tentadores para ahorrar tiempo, pero a largo plazo crean deudas que se deben pagar.

Las claves para abordar la deuda técnica desde una perspectiva arquitectónica incluyen:

• Identificación del costo o beneficios reales para el negocio de acción frente a la inacción
• Hoja de ruta adecuada
• Creación de soluciones componebles

La dificultad puede ser conseguir que las partes interesadas estén alineadas con la acción. Es posible que algunas partes interesadas perciban que el mantenimiento continuo soluciona “los errores de ayer” o elimina las funciones que desean que admita su presupuesto.

Mostrar las repercusiones reales de la acción y la inacción en el negocio, junto con plazos y entregas claramente definidos, puede ayudar a sus partes interesadas a comprender el valor y la prioridad relativa de abordar la deuda técnica. Hacer el trabajo de forma coherente para conectar la deuda técnica con impactos de negocio no solo ayudará a sus partes interesadas a comprender mejor el trabajo que se debe realizar. También le ayudará a asegurarse de que está identificando y abordando la deuda técnica de formas que realmente benefician a los usuarios.

La lista de patrones y antipatrones a continuación muestra el aspecto adecuado (y deficiente) de la gestión de deudas técnicas para una organización de Salesforce.

Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle con deudas técnicas, consulte Herramientas relevantes para intencionado.

La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección.

✨ Descubra más patrones para la capacidad de mantenimiento en el Explorador de patrones y antipatrones.

En esencia, el concepto de legibilidad consiste en crear coherencia que facilita a las personas la comprensión de cómo funcionan las cosas. La construcción de sistemas legibles alinea los equipos de entrega y mantenimiento, y ayuda a las personas que no están familiarizadas con el sistema a comprender rápidamente cómo encajan las piezas. Significa que su equipo puede depender menos de personas individuales con Knowledge institucional o histórico para incorporar de forma efectiva proveedores o nuevos miembros del equipo. Significa que las personas cualificadas en un equipo pueden centrarse en la calidad y las ventajas de las opciones que se están realizando, porque la configuración y el código del sistema son fáciles de leer y comprender para los humanos. La capacidad de lectura puede acelerar los procesos de gobernanza y garantía de calidad, y ayudar los equipos a identificar mejor cuándo podrían estar creando personalizaciones redundantes. También puede potenciar las posibilidades de tener un sistema que se comporte de formas que sean reutilizables y comprobables.

Puede aumentar la legibilidad a través de estándares de diseño y documentación efectivos.

Los estándares de diseño proporcionan directrices para mantener todas las personalizaciones coherentes, incluso en las etapas más tempranas del desarrollo. Los estándares de diseño actúan como salvaguardas, manteniendo todos los equipos de entrega y mantenimiento trabajando en su sistema alineados sobre cómo abordar e implementar personalizaciones. La definición de estándares de diseño ayuda a potenciar la productividad de sus equipos de entrega y mantenimiento, facilita la realización de revisiones de código y arquitectura y proporciona una base para una mejor documentación.

Sin estándares de diseño, los equipos tienen más probabilidades de trabajar en silos. Sin la coherencia que proporcionan los estándares de diseño, los negocios se encontrarán en dificultades con:

• Vendedores y equipos de desarrollo que utilizan patrones y enfoques ad hoc entre soluciones, lo que podría introducir antipatrones y reducir la reutilización (consulte Separación de preocupaciones).
• Tiempo aumentado para resolver problemas de producción, y equipos de asistencia requeridos para incorporar nuevos miembros del equipo y ayudarles a comprender un conjunto dispar de patrones y enfoques.
• Mala colaboración entre equipos, redundancias en el trabajo entre equipos, tiempo perdido resolviendo conflictos y fallos descubiertos durante las pruebas de integración.
• Mayor frustración y mayores índices de rotación.

Un beneficio clave de los estándares de diseño se deriva de las pláticas y las decisiones que las partes interesadas deben tomar para crearlos. Específicamente, el proceso proporciona a sus prospectos de negocio y tecnología la oportunidad de alinearse en torno al aspecto óptimo del diseño para su negocio.

Incluya lo siguiente en sus estándares de diseño

• Convenciones de nomenclatura para metadatos de Salesforce. Defina un conjunto de convenciones para el nombre de cada personalización en un sistema. Las buenas convenciones de nomenclatura no solo aplican la coherencia entre los nombres de objetos, campos, códigos, flujos y otros elementos de su sistema. Las buenas convenciones de nomenclatura también ayudan a los equipos de desarrollo a utilizar nombres que transmiten información acerca del propósito y las funciones de lo que están creando. Como resultado, otras partes interesadas pueden comprender mejor una personalización concreta, solo viendo su nombre.
• Patrones de diseño aprobados y sus casos de uso. Establezca una biblioteca de Patrones y Explorador de antipatrones, junto con información clave acerca de cuándo (y cuándo no) utilizar cada patrón. La biblioteca podría incluir patrones de desencadenador Apex obligatorios o patrones de orquestación de flujos basándose en la capacidad de composición que desea en su sistema.
• Entorno de desarrollo y directrices sobre herramientas. Mantenga una lista clara de las herramientas que los equipos de desarrollo deben utilizar para su trabajo. Esto podría incluir idiomas y cadenas de herramientas aprobados para cualquiera que escriba código, o funciones declarativas que están (o no) aprobadas para el desarrollo de código bajo. Sus estándares podrían incluir una lista de sistemas de control de origen para la personalización y la documentación, así como pasos de registro/salida obligatorios. También pueden incluir una lista de entornos que se utilizarán para diferentes tipos de trabajo de desarrollo.

Junto con la definición de estos estándares, deberá decidir cómo y dónde mantenerlos y almacenarlos. Si los equipos de toda su compañía no pueden encontrar sus estándares de diseño (o ni siquiera saben que existen), no serán efectivos. Idealmente, sus estándares de diseño viven dentro del mismo sistema que su documentación (consulte la siguiente sección para obtener más información).

La lista de patrones y antipatrones a continuación muestra el aspecto de los estándares de diseño apropiados (y deficientes) para una organización de Salesforce. Puede utilizarlos para validar o mejorar sus estándares de diseño.

Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle a definir estándares de diseño, consulte Herramientas relevantes para intencionado.

La documentación explica qué, cómo y por qué de su sistema. Sin documentación significativa y coherente, los equipos pierden mucho tiempo intentando comprender el sistema tal cual es (y posiblemente malinterpretando funciones y personalizaciones).

Una buena documentación tarda tiempo en crearse. Aunque la mayoría de los equipos están de acuerdo en que la documentación es importante para proyectos de gran tamaño, puede ser un paso tentador omitir al realizar cambios rápidos como actualizaciones de configuración o pequeños ajustes en una automatización. No documentar los cambios que realiza en su sistema siempre es un antipatrón. Omitir la documentación puede ahorrar una pequeña cantidad de tiempo por adelantado, pero la cantidad de tiempo requerida para solucionar problemas de una organización que no está debidamente documentada cancelará con creces esos ahorros de tiempo. Incluya siempre tiempo suficiente para crear documentación en todas sus estimaciones, independientemente del nivel de esfuerzo requerido para las actualizaciones que está planificando realizar.

La falta de documentación clara puede provocar diversos problemas, entre ellos:

• Ciclos de desarrollo empleados en la reelaboración de implementaciones existentes
• Debates repetitivos que vuelven a visitar decisiones anteriores o que desconciertan su contenido
• Incorporación más larga para nuevos miembros del equipo o proveedores
• Excesiva dependencia de individuos con Knowledge institucional o histórico
• Arquitecturas redundantes para admitir las mismas funciones o funciones similares en todo el negocio
• Dificultad para comunicar el propósito y el valor de su solución a partes interesadas clave

Para soluciones de Salesforce, mantenga la documentación para:

• Descripciones generales de soluciones. Los diagramas le permiten a usted y a sus partes interesadas visualizar soluciones con varios niveles de detalle. El marco de trabajo de diagramas de Salesforce le ayuda a crear diagramas que muestran las funciones de negocio de soluciones, así como detalles de implementación técnica.
• Registros de decisiones. Mantenga un registro de las opciones consideradas, las compensaciones, la decisión final y el razonamiento en una ubicación central a la que todos los miembros del equipo puedan acceder para futuras referencias.
• Código. El formato del código en sí es una pieza clave de la documentación, y esto puede (y debe) alinearse con sus estándares de diseño. También querrá tener un registro de información clave y actualizarlo con cada modificación de un fragmento de código. Para todas las clases, desencadenadores y componentes, documente lo siguiente:
  • Quién redactó el código
  • Cuando se redactó el código
  • Lo que se supone que debe hacer el código
  • Dependencias clave
  • Todos los cambios
• Personalización declarativa. Para cada tipo de personalización que se puede realizar en los metadatos en su organización, Salesforce proporciona atributos integrados para que los equipos proporcionen información útil acerca del propósito y la intención de los metadatos. Como parte de sus estándares de diseño, incluya cómo utilizarán los equipos estas funciones integradas y cómo asignarán nombres a personalizaciones declarativas. Mantenga también un registro de información clave idéntica a la que utiliza para el código.

Desarrolle un conjunto de estándares de documentación para garantizar que todos los miembros del equipo actuales y futuros puedan interpretar documentos de la misma forma. (los estándares de diseño pueden ayudar con esto.) También es importante considerar cómo los usuarios podrán buscar documentación para encontrar secciones o términos relevantes. A medida que su sistema envejece y crece en complejidad, su documentación también crecerá. La utilidad de la información en su documentación estará directamente relacionada con la frecuencia, la rapidez y la facilidad con la que los usuarios pueden buscar y encontrar elementos relevantes.

La lista de patrones y antipatrones a continuación muestra el aspecto de la documentación adecuada (y deficiente) para una organización de Salesforce. Puede utilizarlos para validar o mejorar su estrategia de documentación.

Para obtener más información acerca de las herramientas de Salesforce para la documentación, consulte Herramientas relevantes para intencionado.

La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección.

✨ Descubra más patrones para la legibilidad en el Explorador de patrones y antipatrones.

Ayúdenos a mantener Salesforce Well-Architected relevante para usted; realice nuestra encuesta para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación.