Lenguajes, frameworks, bases de datos, servicios cloud, modelos de inteligencia artificial: la oferta de tecnologías crece cada año y cada elección tiene consecuencias que duran mucho tiempo. Un stack (el conjunto de tecnologías con el que se construye una aplicación) bien elegido acompaña a un producto durante años; uno mal elegido se paga en mantenimiento, seguridad y costes.
En nuestros proyectos trabajamos con más de 60 tecnologías, pero no tenemos un stack que sirva para todo. Decidimos caso por caso, siguiendo diez criterios que hacemos explícitos, para que también el cliente pueda ver por qué se ha preferido un camino a otro.
Partir del problema
1. Requisitos del proyecto
El primer criterio es el más obvio y también el más olvidado: qué debe hacer el sistema, para cuántos usuarios, con qué exigencias de tiempos de respuesta, disponibilidad y duración. Un sistema de gestión que seguirá en uso diez años tiene necesidades distintas de un prototipo que hay que enseñar el mes que viene. Por eso, antes de hablar de tecnologías, ponemos por escrito la carga prevista, las integraciones, las exigencias de seguridad y dónde deben residir los datos.
2. Compatibilidad e integración
Una tecnología nueva tiene que convivir con lo que ya existe: sistemas de acceso, bases de datos, infraestructura, herramientas de informes. En el ERP Atac para Ernst & Young los microservicios se despliegan en contenedores Docker sobre un sistema on-premise proporcionado por el cliente; en el ERP Hera para Atos la aplicación funciona en Microsoft Azure, usa Azure Active Directory (hoy Microsoft Entra ID) para el acceso y Power BI para los informes.
Seguridad y costes
3. Seguridad
Miramos el historial de vulnerabilidades de un proyecto, la rapidez con que se corrigen, las actualizaciones de seguridad previstas para las versiones que usaremos y el soporte de estándares como OAuth2 y OpenID Connect. Una librería abandonada es un riesgo, aunque hoy funcione. Para los datos sensibles valoramos también dónde se guardan y qué garantías ofrece el proveedor.
4. Costes
El coste no es solo la licencia. Cuenta el coste total: infraestructura, horas de desarrollo, formación y, sobre todo, mantenimiento a lo largo de los años. Un servicio gestionado cuesta más por uso, pero a menudo cuesta menos que operar por cuenta propia un sistema equivalente. Y una herramienta gratuita pero poco extendida puede salir cara cuando hay que encontrar o formar a quien la conozca.
Las personas: productividad, comunidad, experiencia
5. Facilidad de uso y productividad
Documentación clara, herramientas de desarrollo maduras, pruebas fáciles de escribir: todo lo que ayuda al equipo a trabajar más rápido y con menos errores, hoy y cuando otra persona tenga que retomar el código.
6. Soporte y comunidad
Una comunidad amplia significa respuestas a los problemas, librerías listas para usar y profesionales disponibles en el mercado. También cuentan un calendario de versiones público, versiones con soporte a largo plazo y, cuando hace falta, el soporte comercial de una empresa.
7. Experiencia del equipo
Una tecnología que el equipo conoce bien reduce riesgos y plazos. No es un motivo para no aprender nunca nada nuevo, pero hay que sopesarla: la curva de aprendizaje tiene un coste, y conviene tenerlo en cuenta antes de empezar.
Mirar hacia delante y comprobar
8. Tendencias del sector
Seguimos hacia dónde va el mercado para no apostar por una tecnología en declive, pero no adoptamos una novedad solo porque se hable de ella. Una tecnología muy reciente puede cambiar deprisa; en esos casos se lo decimos al cliente y prevemos una salida. En la IA generativa, por ejemplo, modelos y herramientas cambian en pocos meses: por eso es prudente mantener el modelo detrás de una interfaz de la aplicación, para poder sustituirlo sin reescribirla.
9. Pruebas y proof of concept
Cuando una duda es importante, la comprobamos con una POC (proof of concept, un pequeño prototipo que demuestra que una solución funciona de verdad): unos pocos días sobre un caso real valen más que muchas reuniones. Medimos rendimiento, facilidad de integración y calidad del resultado: dos bases de datos o dos modelos de lenguaje, por ejemplo, se comparan con los mismos datos y las mismas preguntas.
10. Estrategia empresarial
Por último, la tecnología tiene que encajar en la estrategia del cliente: los proveedores cloud con los que ya tiene acuerdos, las competencias internas que quiere desarrollar, la libertad de cambiar de proveedor en el futuro, las exigencias normativas sobre los datos.
Los compromisos, en la práctica
Los diez criterios rara vez apuntan todos en la misma dirección. Algunos casos típicos:
- Sistemas empresariales de larga duración: frameworks maduros como Spring Boot para el back-end y Angular para el front-end ofrecen estructura, convenciones compartidas y versiones planificadas; piden más preparación al principio, que se amortiza en años de mantenimiento.
- Proyectos piloto que hay que validar pronto: herramientas más ligeras y servicios gestionados permiten llegar antes a los usuarios, aceptando que algunas partes habrá que revisarlas si el piloto funciona.
- Inteligencia artificial: el ecosistema Python, con librerías como PyTorch, scikit-learn, Hugging Face y LangChain, es hoy la referencia, mientras que la integración con los sistemas de la empresa puede seguir en Java o TypeScript.
- Construir o usar un servicio: el pipeline de vídeo de Artika se basa en servicios gestionados de AWS, como Amazon Transcribe para los subtítulos automáticos y Amazon Rekognition para la moderación de vídeos, en lugar de componentes desarrollados y operados por cuenta propia.
Si tienes que poner en marcha un proyecto o renovar un sistema existente y quieres saber qué stack te conviene, podemos valorar juntos las opciones con estos criterios, incluso empezando por una POC. Contáctanos y lo hablamos.
