En la década de los 2000, desarrollábamos las aplicaciones en capas. Las famosas arquitecturas de 3 niveles. Teníamos la capa de presentación, la capa de cliente, transferencia de datos, las APIs, la lógica de negocios, el acceso a datos, y por último, las bases de datos. Manteníamos una separación estricta entre estas capas, a pesar de que cada nueva característica afectaba a todas. Los equipos de desarrollo de software y administración de sistemas estaban organizados en torno a estas capas: Frontend, backend, DBA.
El flujo de datos atravesaba por las distintas capas. La responsabilidad de cualquier cambio recaía en muchos equipos. Había que actualizar las interfaces entre los diferentes equipos con cada cambio en la aplicación. El desarrollo era lento y doloroso.
Y llegamos a 2019
Hoy en día, escribimos aplicaciones en capas. Hasta aquí nada nuevo, ¿entonces? Lo que ha cambiado es que cada unidad de negocio es compatible con un equipo de funciones. Ahora los equipos están respaldados por SaaS (software como un servicio) externo a la empresa. Los equipos son multifuncionales y compatibles con las plataformas, herramientas, y componentes de UI (interfaz de usuario).
En el pasado, el front-end, el back-end, las operaciones y los DBA estaban separados porque necesitaban diferentes habilidades. Ahora aceptamos que un equipo de software necesita todas las habilidades y capacidades para no depender de otros departamentos. Por tanto, agrupamos a los desarrolladores por responsabilidad: responsabilidad por el valor a nivel de negocio, no por actividades individuales.
Los equipos de soporte son capaces ahora de proporcionar piezas reutilizables y no dependientes de otros equipos en las que la coherencia es esencial: componentes de la interfaz de usuario y bibliotecas internas. Por tanto las interfaces entre equipos ahora cambian con menos frecuencia que los cambios de software. Las capas entrecruzan el flujo de valor.
DevOps
Desde esta nueva perspectiva los equipos de funciones, por tanto, deben hacer de todo. Pero esto era demasiado difícil para un equipo, por lo que ahora lo hacemos más fácil con nuevas herramientas y metodologías. Aquí es donde entran los equipos de Experiencia de Desarrollador (DevEx). También conocido como Productividad del Desarrollador, Plataforma y Herramientas, o Equipos de DevOps). Estos prestan su ayuda a los equipos de desarrollo, haciendo que su trabajo sea más fluido y eficiente. Ponen a disposición herramientas y su experiencia para ayudar a los desarrolladores a aprender y hacer lo necesario para cumplir con el propósito de cada equipo: Infraestructura de autoservicio, configuración fluida de visibilidad y control para software de producción…
Los servicios internos son compatibles y están soportados con servicios externos. Servicios gestionados como Kubernetes, bases de datos en cloud, gestión de colas, observabilidad, logging,… Podemos subcontratar estos componentes con servicios de profunda experiencia y especialización. Mientras los equipos de servicio interno como DevOps tengan el suficiente nivel de comprensión de los detalles, más suficiente sumado con el conocimiento del contexto específico de la compañía, pueden mediar entre lo que ofrece el mundo exterior y las características que necesitan los equipos.
Esto hace que el desarrollo sea más fluido y, por lo tanto, más rápido y seguro. A la vez que pueden centrarse en crear o actualizar aplicaciones más rápidamente sin tener que ser expertos en todas las librerías y desarrollos externos en los que se pueden apoyar.
Con la anterior arquitectura de capas, entregábamos datos al software. Ahora nos superponemos sirviendo valor a las personas y al negocio.
