Consultoría y arquitectura tecnológica

Cuándo tiene sentido

Puede que tengas una aplicación que cuesta mantener, varias herramientas que no encajan o una idea cuyo desarrollo todavía no sabes cómo abordar. En una startup la duda puede ser qué arquitectura o qué proveedor elegir antes de contratar el desarrollo; en una pyme, contrastar una propuesta técnica antes de invertir, como segunda opinión. Trabajo a distancia, tanto si tu empresa está en la Región de Murcia como en otra comunidad.

Reviso el sistema disponible, las restricciones y los objetivos del encargo. La experiencia previa como CTO y en desarrollo me permite abordar tanto las decisiones de arquitectura como sus consecuencias durante la ejecución. Esa experiencia la aplico a una revisión o a una decisión concreta, con su entrega; la dirección tecnológica permanente de tu empresa queda fuera del encargo.

Revisión de arquitectura, segunda opinión y aplicaciones heredadas

• Revisión de arquitectura. Tienes una aplicación o un conjunto de herramientas que funcionan con dificultad y quieres saber por qué y qué cambiar primero. Reviso la estructura, los datos, las integraciones y la infraestructura y te entrego un diagnóstico con alternativas ordenadas por fases.
• Segunda opinión sobre una propuesta. Otro proveedor te ha presentado un presupuesto o un plan y quieres entenderlo antes de firmar. Leo el alcance, las exclusiones, los criterios de aceptación, la propiedad del código y el mantenimiento, y te paso las preguntas que yo le haría. Lo explico en qué reviso en una propuesta de software antes de que la firmes.
• Diagnóstico de una aplicación heredada. Alguien dejó un desarrollo a medias o sin documentar y tienes que decidir si continuar, corregir o rehacer. Compruebo si hay acceso al código y a las cuentas, si la aplicación se puede instalar desde cero y cómo guarda los datos, y separo lo que se puede conservar de lo que conviene sustituir.

Auditoría técnica antes de rehacer una aplicación

Cuando una aplicación falla a menudo o cada cambio tarda semanas, la tentación es rehacerla entera. Antes de tomar esa decisión hago una revisión técnica en este orden:

1. Uso real. Hablo con quien usa la aplicación y con quien la mantiene: qué falla, cuándo y qué tareas no pueden esperar.
2. Código y dependencias. Reviso cómo está organizado el código, qué versiones de lenguajes, librerías y servicios usa y cuáles han dejado de recibir actualizaciones de seguridad.
3. Datos. Miro el modelo de datos, su calidad y qué haría falta para migrarlos si se cambia de sistema.
4. Infraestructura y despliegue. Dónde se ejecuta, cómo se publica una versión nueva, qué copias de seguridad hay y a nombre de quién están las cuentas.
5. Alternativas. Comparo corregir por partes, sustituir una pieza o rehacer, con lo que supone cada camino en plazo, riesgo y mantenimiento.

Entrego un informe escrito con lo que funciona, lo que conviene corregir primero y una recomendación razonada sobre rehacer o no. Si la recomendación es rehacer, incluye qué conservar, cómo migrar los datos y una primera fase acotada. Esta revisión no es una auditoría de seguridad ni de cumplimiento normativo; si hace falta una, lo indico en el informe.

Cómo saber qué encargo necesitas

Si no sabes por dónde empezar, estas preguntas suelen aclararlo:

• ¿Tienes encima de la mesa una propuesta escrita de otro proveedor? Entonces basta con una segunda opinión sobre ese documento.
• ¿El problema aparece al usar una aplicación que ya existe, con lentitud, errores o datos que no cuadran? Empieza por un diagnóstico de ese sistema.
• ¿Nadie sabe ya cómo se instala o se publica lo que tienes? El primer paso es inventariar el código, las cuentas y la documentación.
• ¿Todavía no hay nada construido y dudas entre varias opciones? Una revisión de arquitectura previa compara alternativas antes de gastar en desarrollo.

En la primera conversación te digo cuál de estos encargos encaja con tu caso, o si no necesitas una consultoría.

Qué se revisa

• Arquitectura de software, aplicaciones, integraciones, bases de datos e infraestructura relacionadas con tu problema.
• Documentación, accesos, dependencias y condiciones de operación.
• Opciones para adaptar las herramientas actuales o desarrollar otras a medida.
• Riesgos técnicos y puntos que todavía habría que verificar.

La decisión no siempre es construir de nuevo

Si el problema aparece en una integración o en la calidad de los datos, sustituir toda una aplicación puede ser una respuesta desproporcionada. Distingo qué puede corregirse en el sistema actual, qué conviene probar primero y qué cambio obligaría a rehacer una parte. La comparación separa hechos comprobados, información que falta y costes que todavía no pueden estimarse con rigor.

Qué recibes al terminar la revisión

Puede ser un diagnóstico, un esquema de arquitectura, una comparación de alternativas y un plan de trabajo por fases. Acordamos qué documentos necesitas y hasta dónde llega la revisión antes de empezar.

La consultoría termina con su entrega. Puedes utilizarla para decidir internamente, encargar el desarrollo a otro proveedor o plantearme una fase posterior.

Si en tu empresa nadie se ocupa todavía de estas decisiones, también puedo dar formación a los fundadores o a la dirección en sesiones en directo por videoconferencia. Partimos de tu situación para ver cómo comparar alternativas de arquitectura, qué dependencias crea cada proveedor y qué puede quedarse fuera de una primera versión.

Qué necesito para valorar el trabajo

Una descripción del problema, qué herramientas utilizas y qué documentación o accesos puedes facilitar. Si falta información, lo reflejo en las conclusiones; una revisión limitada no se presenta como una auditoría exhaustiva de seguridad o cumplimiento.

Preguntas frecuentes