Desde hace escasos años estoy empezando a ver una manera distinta de entender la ingeniería del software. Dejando atrás la época del desarrollo de aplicaciones monolíticas, lo que busca una empresa hoy en día son unas herramientas informáticas que se vuelvan versátiles en diferentes entornos y sean capaces de “evolucionar” por si mismas.
En mi paso por Telefónica I+D me di cuenta de la importancia que están cobrando la filosofía DevOps y las metodologías Agile a la hora de desarrollar una nueva industria del software. Mientras que el equipo de desarrollo se encarga de integrar modularmente las necesidades del producto, el de operaciones automatiza el ensamblaje y despliegue de los sistemas necesarios.
Al final lo que se obtiene es una capa extra de especialización, que reduce sustancialmente el tiempo y recursos necesarios, y permite iterar las ideas que surgen, implementarlas o desecharlas, con el mínimo impacto posible.
Y bajo este paradigma, tres principios acompañados de ejemplos recogidos en el último estudio de Accenture (EN) titulado ‘The future of applications: Three strategies for the high-velocity, software-driven business‘, el cual es pesado e incómodo de leer, pero altamente recomendable.
Modularidad
Actualmente, un desarrollo informático tiene que enfrentarse a un entorno por definición nocivo, tanto desde el punto de vista tecnológico (todas las herramientas, programas y sistemas que usamos tanto para el desarrollo como para el uso están expuestos a cambios periódicos que pueden dejar el desarrollo colgado) como expectativo (es muy raro que en una compañía exista un reparto económico fijo para X proyectos, al igual que tampoco se espera un ciclo de desarrollo estructurado y procedimental que no vaya ofreciendo diferentes feedbacks hasta el final).
Así, surge la necesidad de interferir en los componentes de software, que pasan de ser una sola caja con entradas y salidas a varias que gestionan los diferentes elementos del mismo. Se divide el trabajo, segmentando las necesidades de ese software e incluso externalizándolas, y esto permite que el día de mañana sea sencillo desacoplar uno o varios elementos que a priori se creían trascendentes y que quizás no han producido el beneficio esperable o no cumplen los requisitos de un nuevo entorno (como podría ser el IoT).
La reutilización de componentes, de nuevo, abarata los recursos necesarios (no solo económicos sino también técnicos), y esto en sí hace que toda la arquitectura mute para favorecer la reutilización, con desarrollos que son parametrizables tanto por el usuario como en tiempo de desarrollo.
Un paso más allá sería la arquitectura API, que se basa precisamente en generar una cultura de bloques computacionales que pueden ser aprovechados tanto internamente como externamente, y que nos lleva directos al siguiente punto.
Liquidez
Cuando la modularidad se vuelve una estandarización del sector, surge entonces un ecosistema rico en módulos que pueden servir para generar aún mayor enriquecimiento.
Lo veíamos precisamente con Uber, que basa su potencial en el trabajo colaborativo, y que gestiona sus herramientas tecnológicas bajo el principio de la liquidez.
Cuando Uber necesita implementar un nuevo servicio de chat en su sistema, no se pone a desarrollarlo de cero, sino que simplemente “engancha” los módulos que estime oportunos de su sistema a la arquitectura pre-desarrollada de proveedores cloud como Twilio, que son a su vez utilizados por otras empresas tan dispares como TripAdvisor o Starbucks.
Se genera una pasarela entre el software de la compañía y las APIs que Twilio ofrece a sus clientes, y en muy poco tiempo, Uber puede ofrecer a sus propios clientes un servicio de chat que estará continuamente actualizándose y mejorándose, y que no depende directamente de la compañía (aunque esta tenga control absoluto de lo que ocurre dentro de sus fronteras).
Y esto de por si abre las puertas a un paradigma mayor. Al hecho de que caminamos hacia un entorno de cajas distribuidas con funcionalidades específicas y muy experimentadas que una empresa puede ir uniendo para crear su propio sistema. El peso de desarrollo recae en la integración de los diferentes componentes, y no en los propios componentes, abaratando enormemente los gastos y replicando, gracias a Operaciones, estos sistemas en caso de que tengamos que cubrir necesidades o entornos nuevos.
Inteligencia
Sería la tercera y última pata de la cual me gustaría hablar, y es que además de modulable y líquida, la tecnología que nos rodea se vuelve por momentos inteligente.
Como bien sabe, aún estamos a las puertas. Vemos un futuro en el que ese análisis de grandes volúmenes de información podría, en efecto, facilitarnos muchísimo la vida. Hasta el punto de quizás quitarnos la necesidad de trabajar.
Pero hasta entonces, la inteligencia cumple un papel cada vez más trascendente: el de servir de soporte semi-automatizado o directamente automatizado en la evolución del software.
Analizando los datos que el propio software obtiene, y retroalimentando con el conocimiento adquirido el ciclo de vida de desarrollo de ese mismo software, lo que obtenemos es una herramienta capaz automatizar tareas rutinarias y ayudar por ahora al equipo de desarrollo simplificando la complejidad de un entorno modular y líquido. Y esto repercute en la efectividad del propio software.
Así, en el Google IO del otro día, pudimos ver cómo parte del discurso de la compañía giraba entorno a aprovechar el conocimiento que tiene de nosotros para adelantarse a nuestras necesidades. Spotify o Netflix lo hacen cuando su sistema inteligente de recomendación se vuelve cada vez más efectivo conforme más utilizamos la herramienta. Una suerte de contextualización que cada vez está más presente en la industria.
Y esto es solo el principio de lo que está por venir, cuando esa inteligencia pueda ser utilizada ya no solo para el apoyo en la toma de decisión y la automatización de despliegues, sino en la práctica para la delegación de la monitorización, gestión y administración del software (y quizás también de su desarrollo) bajo el control de agentes inteligentes.
La foto final es un entorno que se retroalimenta, que se vuelve cada vez más complejo, y que va alineado con las necesidades del cliente (ciclos de actualización cada vez más bajos) y de la empresa (optimización de recursos).
