Construir, comprar o integrar: documentá la decisión de software

Decidí si construir, comprar o integrar software comparando el trabajo que tu equipo asumiría en cada opción. Una lista de funciones no alcanza. También importa quién mantiene las reglas, resuelve las fallas y recupera los datos cuando cambian las necesidades.

Documentá la decisión mientras los supuestos están claros. Dentro de seis meses, explicar brevemente por qué se eligió una opción servirá más que una hoja llena de puntajes sin contexto.

Compará la misma capacidad de negocio

Definí el flujo requerido antes de evaluar productos. Separá condiciones obligatorias de preferencias: permisos, eventos de integración, idiomas, exportación de datos y tiempos de indisponibilidad aceptables necesitan respuestas explícitas.

Construir da control, pero deja la entrega y operación continua a cargo del equipo. Comprar puede resolver un proceso estándar, aunque requiere configuración, migración y gestión del proveedor. Integrar combina sistemas y agrega una frontera que alguien debe operar. Las opciones se superponen: comprar el núcleo y desarrollar una extensión acotada merece evaluarse por separado.

No contés una promesa de la hoja de ruta del proveedor como capacidad disponible. Registrala como una dependencia, con responsable y alternativa si no llega.

Escribí una decisión que se pueda cuestionar

La guía de AWS sobre registros de decisiones de arquitectura incluye contexto, decisión y consecuencias como contenido mínimo. Usá esa estructura y agregá la evidencia necesaria para volver a evaluar la elección.

Campo	Qué registrar
Problema	Trabajo y usuarios que necesitan la solución
Restricciones	Requisitos que pueden descartar una opción
Candidatos	Desarrollo, proveedores y combinaciones realistas
Responsabilidad	Quién cambia reglas y atiende fallas
Evidencia	Pruebas, límites documentados y supuestos pendientes
Motivo de revisión	Cambio concreto que invalidaría el razonamiento

Compará estimaciones con el mismo alcance y supuestos visibles. No enfrentés la suscripción únicamente al desarrollo inicial. Incluí migración, mantenimiento de integraciones, soporte y eventual reemplazo, sin presentar esas aproximaciones como pronósticos exactos.

Ejemplo hipotético: una herramienta de operaciones

Un equipo bilingüe debe elegir un sistema para asignar trabajo. Un proveedor resuelve las asignaciones habituales, pero no representa su regla de aprobación. Un desarrollo completo la resolvería, aunque también exigiría reconstruir funciones comunes de planificación.

El equipo considera una tercera opción: comprar la planificación y construir un servicio pequeño de aprobaciones. En la prueba hipotética verifica identificadores estables de asignación, eventos y una API capaz de aplicar el estado aprobado.

Si alguien puede saltarse la aprobación desde la interfaz del proveedor, la integración incumple el flujo obligatorio aunque sincronice datos correctamente. El registro debe decirlo. Conectar una API no demuestra que el proceso combinado funcione.

La decisión también necesita una persona que pueda aceptar las limitaciones. Ingeniería puede describir el comportamiento; la jefatura del proceso debe confirmar si el trabajo resultante sigue siendo válido.

Probá la salida antes de aprobar

Pedí una exportación real y revisá relaciones, adjuntos e identificadores necesarios para migrar. Probá un cambio de permisos y una interrupción de la integración. Definí quién resuelve desacuerdos entre sistemas sin asumir que uno siempre tiene razón.

Elegí una prueba pequeña capaz de descartar la opción preferida. En el ejemplo, verificá primero la aprobación, antes de pulir paneles. Llevá el registro a la planificación de software a la medida para que el alcance responda al trabajo que conviene asumir, sin dar por hecho que todo deba construirse.