¿Y qué pasa con la operación de un sistema en producción?

Me encuentro a menudo con la siguiente situación: se desarrolla desde cero un nuevo proyecto, la funcionalidad a implementar está más o menos clara, se implementa, se entrega y... comienzan los problemas porque hay una gran cantidad de requisitos no funcionales que no se han tenido en cuenta (y que el cliente no ha indicado, claro está).

No solo estoy hablando de las necesidades de escalabilidad, rendimiento, mantenibilidad y todo eso que se denominan los conductores arquitecturales de cualquier producto software medianamente complejo. Desarrollar un nuevo proyecto implica también implementar todas las características necesarias para mantenerlo en producción, con funcionalidad específica para comprobar que todo está funcionando correctamente y con la trazabilidad necesaria para detectar dónde y cómo surgen los problemas. 

Todo lo anterior es necesario pero no suficiente.

¿Qué hay de toda esa funcionalidad al margen de la que el usuario final ve y usa? Me refiero a todo lo relacionado con la operación del sistema, algo de más relevancia aún cuando el proyecto es ciertamente complejo o tiene una gran cantidad de características.

Imagina una plataforma web como pueda ser Hub de Libros (el proyecto en el que más he trabajado en el último año): los usuarios se registran, los autores también, se pueden añadir reseñas y valoraciones de libros, los autores pueden indicar sus obras, crear su propia web de autor, los usuarios pueden seleccionar sus géneros preferidos, pueden escribir artículos, contratar servicios y pagarlos, crear estanterías con colecciones de libros y un larguísimo etcétera.

Toda esa funcionalidad, que es la que percibe un usuario que usa la plataforma, requiere de mucha más funcionalidad que éste no ve para operar el sistema. Esto es, hace falta una segunda aplicación totalmente independiente que permita actividades como: bloquear un usuario, restaurar su contraseña, aprobar valoraciones, comprobar los registros de log, gestionar todo lo relacionado con detalles internos de la plataforma (gestión de tareas, rendimiento de las bases de datos, etc.), obtención de métricas, gestionar características como "el autor del día", obtener todos los correos de los usuarios para crear una campaña de mailing, enviar un mensaje a un grupo de usuarios determinados, eliminar un libro que un autor ha publicado por error y muchas otras cosas por el estilo.

Cuando se publica un nuevo proyecto y muchas de esas actividades de operación se tienen que realizar tocando los registros de una base de datos, entonces es que no se ha planteado el desarrollo de la herramienta de operación necesaria.

Por resumirlo de algún modo: proyecto complejo = requisitos funcionales + herramientas de mantenimiento y operación.

El sistema va creciendo, en usuarios, en accesos y, afortunadamente, todo va bien y comienza su monetización: el cliente final (el dueño del proyecto) entonces requiere de cierto tipo de informes (¿cuántos usuarios hay?, ¿cuántos accesos al día?, etc.), sobre todo si se ha concebido el proyecto desde un punto de vista lean y hacen falta muchas métricas para decidir qué dirección darle con el tiempo según los resultados que se van obteniendo.

Más y más funcionalidad... de operación, claro.

Sin ir más lejos, en Hub de Libros se pueden contratar gigs para la ejecución de servicios de publicación (revisión, maquetación, creación de los archivos pdfs/epub de un nuevo libro, entre otros). Lógicamente, hace falta gestionar correctamente los gigs para que se realicen correctamente y que el usuario obtenga finalmente lo que ha contratado. Al usar Stripe para los pagos, hace falta comprobar también aspectos económicos como que las liquidaciones de esta pasarela son correctas, entre otras características tan solo relacionada con la contratación de los servicios.

Para ello, el sistema de operación debe implementar toda esa funcionalidad para su gestión: administrar la notificación de un nuevo gig contratado, comprobar su pago, enviarle mensajes asociados al gig para que el usuario los lea y muchas otras cuestiones que cualquier visitante de la web no ve, pero que está por detrás del funcionamiento de la plataforma y que además es imprescindible.

Una vez leí el comentario (en mi opinión algo tan cándido como ingenuo) de alguien que se preguntaba cómo es que Netflix tenía cientos de desarrolladores contratados puesto que la "web" o la aplicación no parecía demasiado compleja... en fin. Apuesto a que gran parte de todo ese equipo se dedica a implementar todo lo necesario para operar el sistema y dar soporte a necesidades del resto del negocio, algo mucho más allá de lo que el cliente final ve de la plataforma cuando se suscribe a ella y la usa.

En un sistema más o menos complejo, es difícil trasladarle al cliente toda esta funcionalidad en la que ni había pensado, más aún cuando las características y necesidades relacionadas con la opernación suelen ser mayores que las que se ofrecen a los usuarios finales.

La implementación de una aplicación de operación es necesaria y vital para el éxito de un proyecto, y no siempre se piensa en ella.

En concreto, en Hub de Libros existe un segundo portal de operación totalmente independiente y descoplado de el de usuarios (admin.hubdelibros.com) que permite realizar todo este tipo de operaciones y cuyo esfuerzo de desarrollo, lo puedo asegurar, ha sido mayor que el portal que ven los visitantes cuando acceden a la web.

Implementar toda esa funcionalidad de operación en segundas aplicaciones implica tener en cuenta muchos aspectos de seguridad, al tiempo que ese otro sistema (o conjunto de aplicaciones), tiene que tener acceso a los mismos repositorios que el sistema final, y, seguramente, a parte de la funcionalidad de los componentes que la constituyen. Y esto no es trivial, sobre todo si se quiere tener un sistema coherente sin que se provoque esa dispersión de aplicaciones implementadas de forma independiente, algo más costoso de mantener en el medio plazo.

Esta es una de las razones por las que implementé el framework de nombre Mantra (que, en estos momentos precisamente, estoy documentando para liberarlo en GitHub): un framework que tiene en cuenta desde su base, entre muchísimas otras características, que un mismo componente pueda implementar funcionalidad final y también de operación, sin romper la consistencia del sistema y facilitando su mantenimiento.

Recuerda: la funcionalidad de operación de un sistema es tan importante como los requisitos funcionales que el cliente exige.