DMO Schema Designer Agent.
Diseñar un DMO deja de ser semanas de spreadsheets entre arquitectos y product managers.
Agente custom de Agentforce que toma un business requirement y lo decompone en entidades, sugiere campos, relaciones, identity resolution targets, naming convention y partitioning strategy. Genera la definición exportable como YAML y la entrega como PR en GitHub. Coopera con el Data Mapping Agent OOTB pero parte de business needs en lugar de fuentes existentes.
¿Qué hace el DMO Schema Designer Agent?
Es un agente custom desarrollado sobre Agentforce que opera como copiloto del Data Architect. Toma un business requirement expresado en lenguaje natural, lo decompone en entidades, mapea contra el catálogo de DMOs existentes para evitar duplicación, sugiere campos y tipos consistentes con las naming conventions del cliente, define relaciones y identity resolution targets y propone una partitioning strategy adecuada al volumen esperado. La salida es un schema-as-code en YAML que se entrega como PR en GitHub para que el arquitecto revise, ajuste y apruebe antes del deploy a Data Cloud.
Cómo funciona paso a paso
Del business requirement al PR mergeable. 6 pasos diseñados para mantener al arquitecto en el loop sin que pierda tiempo en tareas mecánicas.
Business requirement
Un product manager o un data steward describe la necesidad en lenguaje natural. El agente puede recibirla en Slack, en un ticket de Jira o en una sesión interactiva en Lightning.
Decomposición en entidades
Requirement Decomposer identifica las entidades candidatas, sus atributos y las cardinalidades de las relaciones. Si el dominio coincide con un vertical conocido (retail, banca, telco), parte de un template como base.
Propose DMO
proposeDMO genera la primera versión del schema: nombre del DMO, lista de campos con tipos, primary key, relaciones con DMOs existentes, identity resolution targets sugeridos y partitioning strategy.
Validación contra best practices
validateAgainstBestPractices corre el naming linter, valida tipos y formatos, chequea conflictos con DMOs existentes y verifica que el schema cumple con la governance documentada del cliente.
PR con schema-as-code
exportYAML genera el archivo YAML, abre el PR en el repositorio configurado y dispara el pipeline de validación. El Data Architect revisa, comenta, ajusta y eventualmente aprueba.
Deploy
Una vez mergeado el PR, deployDMO publica el DMO a Data Cloud y actualiza el catálogo. El agente registra la decisión final en su memoria para alimentar futuros diseños similares.
Ejemplo de interacción
[Slack canal #data-architecture, mensaje del agente]
[PR abierto en GitHub]
Arquitectura del agente
Topics, Actions, Hydrators, Effectors, Channels, DMOs, Trust Layer y Memory.
Topics
Dominios de razonamiento
- Requirement Decomposer
- Field Suggester
- Relation Mapper
- Identity Target Selector
- Naming Linter
- Partition Strategy Recommender
Actions y Channels
Lo que ejecuta y dónde comunica
- proposeDMO · validateAgainstBestPractices
- exportYAML · simulateLoad
- deployDMO · deprecateDMO
- GitHub
- Slack vía MCP · Lightning
Hydrators y DMOs
Fuentes de contexto
- Existing DMO catalog
- Business glossary
- Source schemas
- Prior DMO designs
- Vertical templates retail
- Vertical templates banca
- Vertical templates telco
Effectors, Trust Layer y Memory
Escrituras, guardrails y aprendizaje
- Write DMO definition
- GitHub PR con schema-as-code
- Update catálogo de DMOs
- Audit trail completo
- Aprobación humana antes del deploy
- Memory de decisiones previas del data team
Implementación en 5 fases
El driver crítico es la madurez del business glossary y la convención de naming. Timing típico: 8 a 12 semanas.
Discovery y revisión del catálogo de DMOs
Inventariamos los DMOs vigentes, el business glossary y las naming conventions. Identificamos verticales relevantes y patterns reutilizables. Validamos la governance actual de approval de DMOs en producción.
Setup del repositorio schema-as-code
Configuramos el repo Git con la estructura de DMOs en YAML, los pipelines de validación (formato, naming, conflictos) y la integración con Data Cloud para el deploy. Definimos branching strategy y reviewers por dominio.
Agent build e integración con GitHub
Construimos Topics y Actions en Agent Builder, conectamos GitHub vía MCP y cargamos los templates verticales. Definimos el flujo de comunicación en Slack y Lightning para los pedidos de los product managers.
Pilot con dominios acotados
Arrancamos con dos o tres dominios donde haya backlog de DMOs pendientes. Cada PR generado por el agente se revisa con el Data Architect dueño del dominio. Calibramos el naming linter, los templates y el partitioning recommender.
Go-live y mejora continua
Cutover. Monitoreamos time-to-DMO, % de approval sin override, reuso de patterns, cobertura del glossary y consistency en naming. La memoria del agente se enriquece con cada PR mergeado.
Equipo típico de implementación
Requisitos para arrancar
Lo que conviene tener listo antes del go-live.
Datos mínimos
- Business glossary versionado
- Naming conventions documentadas
- Source catalog accesible
- Catálogo de DMOs vigente exportable
Licencias
- Salesforce Data Cloud
- Agentforce Platform
- GitHub Enterprise o equivalente
- Industry Cloud según vertical (FSC, RIC, MIC) si aplica
Integraciones
- GitHub vía MCP con permisos de PR
- Slack vía MCP para canales de data architecture
- Lightning para sesiones interactivas
- Email transaccional para notificaciones
Org readiness
- Governance de approval de DMOs definida
- Ownership por dominio asignado
- Repo Git con CI/CD para schema-as-code
- Política de manejo de PII en DMOs documentada
Qué se busca optimizar
Lo que el agente busca mejorar — los rangos exactos dependen del baseline de cada compañía.
No prometemos cifras atribuidas a casos. Detallamos las dimensiones que el DMO Schema Designer Agent ataca y la dirección esperada del cambio.
Time-to-DMO
De semanas de iteración entre product manager y arquitecto a días con un primer borrador validado automáticamente contra best practices.
Consistency en naming y tipos
Cada DMO propuesto pasa por el linter antes del PR. La proporción de inconsistencias detectadas en review baja a medida que el catálogo crece.
% de DMOs aprobados sin override
Métrica de calidad de la propuesta: cuánto del schema sugerido se acepta sin que el arquitecto necesite reescribirlo en el PR.
Reuso de patterns por vertical
Los templates de retail, banca y telco aceleran el primer borrador. La cobertura de patterns reutilizados se mide y se expande con cada nuevo DMO mergeado.
Cobertura del business glossary
% de campos del DMO propuesto que están vinculados a un término del glossary. Cuanta más cobertura, mejor la trazabilidad y la governance.
Tasa de validación automática
% de chequeos de best practices que pasan sin intervención humana en el primer commit del PR. Es proxy de la madurez del agente y del repo.
Qué considerar al implementar
Cinco prácticas que aceleran el time-to-value y sostienen la confianza del equipo de arquitectura.
Business glossary maduro
El agente necesita un glossary estable para vincular cada campo a un término de negocio. Conviene invertir en su mantenimiento antes de escalar el agente a múltiples dominios.
Naming convention documentada
El linter aplica reglas explícitas. Si la convención está en la cabeza de los arquitectos pero no escrita, conviene formalizarla como primer paso del proyecto.
Ownership por dominio
Cada DMO necesita un dueño claro. El PR del agente se rutea al reviewer correcto según el dominio. Sin ownership, el PR queda sin avanzar y el time-to-DMO se degrada.
Governance de approval para producción
El PR es el gate. Conviene definir cuántos approvers se requieren, qué chequeos de CI son obligatorios y cómo se manejan los DMOs que tocan PII o que son productivos para activaciones críticas.
Repositorio schema-as-code con CI/CD
El repo es el contrato. Conviene tener pipelines automáticos que validen formato, naming y conflictos antes de que el reviewer humano abra el PR. Eso acelera la revisión y libera tiempo del arquitecto.
Preguntas frecuentes
No. El agente hace el primer borrador y la validación automática contra best practices. El Data Architect revisa el PR, decide trade-offs y aprueba. El tiempo del arquitecto se libera de tareas mecánicas para enfocarse en decisiones de diseño que requieren contexto de negocio.
Sí. Para DMOs con muchas relaciones o campos derivados, el agente decompone el requirement por iteraciones y propone un design en fases. Cada iteración queda como PR independiente para que el arquitecto pueda revisar y mergear de forma incremental.
Vía MCP. Abre PR con el archivo YAML del DMO, dispara el pipeline de validación (formato, naming, conflictos con DMOs existentes) y solo el merge final ejecuta el deploy a Data Cloud. El agente nunca pushea directamente a main.
Sin límite técnico. El agente puede atender requirements concurrentes y dejar PRs independientes. La governance del approval es del cliente: cuántos reviewers, qué chequeos son obligatorios y qué dominios tienen prioridad.
Sí. El catálogo de DMOs estándar de Financial, Retail y Manufacturing Cloud está cargado como base. El agente sugiere extender DMOs estándar antes de crear custom cuando aplica, lo que reduce duplicación y mantiene compatibilidad con el resto del Industry Cloud.
Marca los campos sensibles desde la propuesta, sugiere policies de masking que coordinan con el PII Redaction Agent y deja explícito en el RFC qué controles requiere el DMO antes del deploy. El reviewer humano aprueba o ajusta antes del merge.
Tu backlog de DMOs ya está. Solo falta un agente que arme el primer borrador.
Hablá con un Data Architect de Solu. Revisamos tu glossary, tu naming convention y proyectamos el lift en time-to-DMO para tu operación.