Arquitectura de software.

Hay decisiones técnicas que duran mucho más que el proyecto que las originó. La base de datos que se eligió en una tarde, el servicio que se partió «para escalar» y la cola que nadie recuerda por qué está ahí siguen cobrando años después. Este servicio existe para tomar esas decisiones con calma y con alguien que ya vio cómo terminan.

CosaSeria revisa, diseña y acompaña arquitecturas de software para equipos que tienen un sistema en producción y una decisión pendiente que les da miedo tomar mal. El trabajo empieza por el problema y la organización que lo opera. La tecnología llega después, y a veces resulta que ya la tienes.

Problemas que atiende

• Un sistema que creció sin plan y hoy nadie se atreve a tocar: cada cambio rompe algo en otro lado.
• Una migración pendiente (de monolito a servicios, de un proveedor de nube a otro, de una base de datos a otra) donde equivocarse cuesta un trimestre.
• Fronteras borrosas entre módulos, con datos compartidos por todos y responsabilidad de nadie.
• Dos alternativas técnicas sobre la mesa, cada una con un defensor, y ninguna forma objetiva de decidir.
• Deuda técnica convertida en modelo operativo: el equipo pasa más tiempo rodeando el sistema que mejorándolo.

Cuándo conviene

• Antes de una decisión difícil de revertir: partir un sistema, cambiar de plataforma, reescribir un componente central.
• Cuando el equipo tiene criterio pero le falta alguien que ya haya operado un sistema parecido a escala.
• Cuando la arquitectura actual empieza a doler y no está claro si el problema es de diseño, de operación o de organización.
• Cuando se necesita una segunda opinión independiente antes de comprometer presupuesto.

Cómo trabajamos

1. Entender el problema. Lectura del sistema tal como está: código, despliegues, incidentes, métricas y, sobre todo, conversaciones con quienes lo operan. Un diagrama bonito no sustituye saber qué se rompe los martes.
2. Nombrar las restricciones. Equipo disponible, plazo, presupuesto, cumplimiento, dependencias que no se pueden mover. Las restricciones definen la solución tanto como el problema.
3. Proponer opciones con costos. Dos o tres caminos viables, cada uno con lo que compra, lo que paga y qué pasa si no se hace nada. La opción «no cambiar la arquitectura» siempre está en la lista.
4. Decidir y documentar. La decisión queda escrita con su razonamiento, para que dentro de dos años alguien pueda saber por qué se tomó y si las condiciones siguen vigentes.
5. Acompañar la implementación. Revisión de diseño y de código durante los primeros pasos, que es donde una buena decisión se puede echar a perder.

Qué entregamos

• Diagnóstico escrito del sistema actual: qué funciona, qué duele y por qué.
• Propuesta de arquitectura con alternativas evaluadas y la recomendación justificada.
• Registros de decisión (ADR o equivalente) para las decisiones importantes.
• Plan de transición por etapas, con los puntos donde se puede detener sin dejar el sistema a medias.
• Sesiones de revisión con el equipo durante la implementación.

Sobre los resultados. No se prometen porcentajes ni plazos antes de entender el problema. Los números se publican cuando se puede decir exactamente qué miden, en qué periodo y quién los verificó.

Evidencia relacionada

La postura del estudio sobre este tema está escrita en la nota Microservicios: cuándo no: qué compras al partir un sistema, qué pagas a cambio y bajo qué condiciones verificables conviene hacerlo.

El fundador ha trabajado en arquitectura, backend y sistemas distribuidos en Google, Microsoft, Amazon y HP, incluyendo posiciones senior y Principal Engineering. Ese trabajo fue como empleado de esas empresas y se describe, con sus límites, en la página de Trabajo.

Preguntas frecuentes

¿Hacen solo el diagnóstico o también construyen?

Ambas cosas, según lo que haga falta. Hay proyectos donde el equipo del cliente implementa y el estudio revisa; hay otros donde CosaSeria construye la parte crítica. Lo que el estudio evita es entregar un documento y desaparecer.

¿Qué pasa si la recomendación es no cambiar nada?

Se dice. Una parte importante del valor de una revisión de arquitectura es evitar una migración innecesaria. Si el sistema actual aguanta lo que viene, el entregable es ese diagnóstico y las señales que indicarían que llegó el momento de revisarlo otra vez.

¿Trabajan con el stack que ya tenemos?

Sí. La arquitectura se decide alrededor del problema, del equipo y de lo que ya opera. Cambiar de lenguaje o de plataforma es una decisión más, con su costo, y rara vez es la primera que conviene tomar.

¿Recomiendan microservicios?

Cuando hay evidencia de que varios equipos se bloquean entre sí al desplegar, o cuando una parte del sistema tiene un perfil de escala o de riesgo genuinamente distinto. En los demás casos, casi siempre hay un camino intermedio más barato: fronteras claras dentro de un solo despliegue.

---

Otros servicios. Escalabilidad y sistemas distribuidos · Software a medida · Inteligencia artificial · Technical advisory.