Software Architecture
Explica cómo decidir entre construir, comprar o adoptar servicios según diferenciación, coste total, lock-in, riesgo, operación, datos y estrategia de salida.
Construir, comprar o adoptar open source es una decisión estratégica. La pregunta no es qué opción tiene más funcionalidades, sino cuál permite obtener la capacidad necesaria con un costo total, un riesgo y una dependencia aceptables.
Toda capacidad tecnológica consume atención del equipo durante su ciclo de vida.
necesidad
→ importancia estratégica
→ alternativas
→ costo total y riesgo
→ decisión
→ integración y operación
→ señales de revisión y salidaUna solución comprada todavía necesita integración, seguridad, observabilidad y gestión contractual. Una solución construida todavía necesita mantenimiento, soporte y evolución. Open source evita ciertas licencias, pero no elimina operación ni dependencia del proyecto.
Los equipos suelen comparar el costo inicial y omitir el costo de poseer la decisión.
Ejemplos:
La decisión debe considerar producto, negocio, técnica, operación y salida.
El equipo diseña y opera la capacidad.
Conviene cuando:
Costos:
Construir una primera versión no equivale a poseer una capacidad madura.
Un proveedor entrega la capacidad como servicio o producto.
Conviene cuando:
Costos:
Comprar no transfiere la responsabilidad de diseñar el comportamiento de la aplicación ante fallos del proveedor.
El software está disponible para inspección y operación propia o mediante una oferta administrada.
Conviene cuando:
Costos:
Open source no es sinónimo de gratis ni portable de manera automática.
Pregunta si la capacidad es parte de la ventaja del producto.
alta diferenciación + conocimiento propio
→ considerar build
baja diferenciación + mercado maduro
→ considerar buy
necesidad de control + estándar maduro
→ considerar open source / managed open sourceLa respuesta puede cambiar con el tiempo. Una startup puede comprar para validar y construir después si la capacidad se vuelve estratégica. También puede construir inicialmente y comprar cuando descubre que la operación no aporta diferenciación.
No compares solo tarifa contra salarios de desarrollo.
desarrollo
+ infraestructura
+ mantenimiento
+ seguridad
+ on-call
+ soporte
+ costo de oportunidadlicencia
+ consumo
+ integración
+ soporte premium
+ egress
+ migración
+ gestión contractualoperación
+ upgrades
+ conocimiento
+ soporte
+ incidentes
+ adaptaciónProyecta escenarios de crecimiento y no únicamente el volumen actual.
Evalúa:
Una lista de features no demuestra comportamiento bajo carga o fallo.
Pregunta:
Una certificación ayuda, pero no sustituye revisar el uso concreto dentro de la arquitectura.
El SLO del sistema completo no puede ser superior al de una dependencia crítica sin redundancia o degradación.
Existen varios tipos de lock-in.
Plazos, tarifas de salida y condiciones.
APIs, SDK, protocolos y despliegue.
Formato, volumen, egress y capacidad de exportación.
El modelo del producto adopta conceptos únicos del proveedor.
El equipo depende de dashboards, procesos y soporte específicos.
El conocimiento interno desaparece y todo cambio requiere al proveedor.
Un adapter reduce lock-in técnico, pero no elimina los demás.
Ejemplo de pagos:
interface PaymentPort {
authorize(input: AuthorizePayment): Promise<AuthorizationResult>;
capture(input: CapturePayment): Promise<CaptureResult>;
refund(input: RefundPayment): Promise<RefundResult>;
}El dominio usa conceptos propios. Un adapter traduce al proveedor.
Esto protege:
No garantiza que otro proveedor soporte exactamente autorizaciones, disputas, tokens y liquidación con la misma semántica. Las diferencias reales deben modelarse, no ocultarse detrás del mínimo común denominador.
No decidas solo con demos.
Construye un spike que pruebe:
Registra supuestos y resultados.
Una capacidad crítica necesita responsables legales, financieros y técnicos, no solo una decisión de ingeniería.
Control completo, pero exige:
Acelera capacidades maduras, pero introduce:
Comprar identidad, conservar en DomiSys:
El proveedor autentica; la aplicación conserva autoridad sobre qué puede hacer cada identidad.
Esta separación reduce lock-in semántico y evita delegar reglas del negocio.
Opciones:
Para etapa inicial, SQL puede ser suficiente. La señal de revisión puede ser:
Elegir SaaS desde el día uno puede acelerar relevancia, pero añade sincronización, costo y datos externos. La decisión debe responder a drivers actuales y conservar una ruta de evolución.
Antes de adoptar, define:
trigger: costo supera 8 % del ingreso del producto
acción: revisar alternativas y ejecutar benchmarkUna estrategia de salida no exige construir una implementación alternativa hoy. Exige no cerrar innecesariamente la puerta.
Después de elegir:
Una dependencia administrada sigue siendo parte de tu arquitectura.
Señales:
Actualiza el ADR y la estrategia.
El equipo gasta atención en una commodity y retrasa valor diferencial.
La integración y el dominio todavía necesitan diseño.
Ignora crecimiento, egress, soporte y migración.
Añade complejidad y oculta diferencias reales sin lograr portabilidad.
Los problemas aparecen en cuotas, errores y operación, no en la demo feliz.
La primera discusión ocurre cuando el costo o el incidente ya exige urgencia.
Nadie mantiene upgrades ni seguridad.
Antipatrones arquitectónicos frecuentes reúne síntomas recurrentes y muestra cómo diagnosticar sus causas antes de aplicar una solución superficial.