Diseño de soluciones de arquitectura: el contexto es clave.

En el artículo anterior hicimos una descripción de la estructura que tendría un modelo de solución de arquitectura y cómo diseñar las vistas para describirlo.

En los próximos artículos vamos a ver en detalle cómo hacer un modelo de solución de arquitectura. Para ejemplificar esta serie de artículos, vamos a ayudar al responsable de una clínica a mejorar la gestión de turnos de trabajo de los médicos. En este artículo vamos a poner foco en la primera parte: el contexto.

Objetivos

Lo primero que necesitamos tener claro para realizar un modelo de solución son los objetivos del proyecto o iniciativa, para acotar y tener un punto de partida de la problemática que se quiere resolver.

En teoría, deberían estar claros cuando nos piden el diseño de la solución, pero la realidad es que no es lo normal.

Si el proyecto forma parte de una estrategia global con una arquitectura objetivo bien aterrizada y con los proyectos claramente alineados, ¡enhorabuena! Probablemente partirás de unos objetivos bien especificados y será mucho más sencillo orientar la solución.

Pocas veces me he encontrado con esta situación. Se suele partir de una descripción de alto nivel de los problemas o necesidades de negocio. O peor, puedes partir de una solución ya predefinida por el negocio y medio negociada con los stakeholders. En ese caso, rezaremos para que realmente esté bien orientada, porque gestionar los cambios que propongamos va a ser doloroso.

En cualquiera de los casos anteriores hay que pedir que definan correctamente los objetivos del proyecto, o analizar nosotros la información que nos proporcionen y realizar algunas sesiones con negocio y los owners del proyecto para acordarlos.

Sobre cómo definir objetivos no voy a entrar en detalle en el artículo. Ya hay mucho escrito sobre ello como en SMART o ¿Qué son los OKR?.

Veámoslo sobre el ejemplo:

En un primer contacto, el responsable de la clínica nos explica que actualmente cada equipo de médicos es responsable de organizar los turnos y guardias cada mes, considerando que todos los días son laborables para ellos. Para ello, realizan una planificación sobre un documento excel donde indican, para cada día del mes, las personas que van a estar trabajando en cada turno o guardia.

La problemática que tienen es que el equipo de médicos dedica mucho tiempo a conseguir hacer esa planificación porque necesitan negociar con cada uno las prioridades que tiene cada persona según sus necesidades privadas y deben resolver múltiples conflictos.

Utilizan adicionalmente una aplicación web donde cada médico indica para ese mes qué días prefiere hacer guardia y qué días prefiere librar mediante un sistema de puntos. Esto permite tener un punto de partida, pero suele haber coincidencia de las peticiones en los mejores y los peores días.
Necesita una solución que les permita diseñar la planificación mensual de forma eficiente y que permita reducir los conflictos entre los médicos.

En este caso, tenemos una descripción de su situación y del problema y, finalmente, la petición plantea en cierta manera el objetivo. Pero necesitamos concretar mejor el objetivo en cuanto al resultado que queremos conseguir.

¿Quiere algo que ayude a hacer más sencillo el proceso de planificación o que lo automatice completamente? ¿El foco del problema a resolver está en el tiempo de dedicación, en la antelación con la que necesitan publicar la planificación o en los conflictos? ¿Cómo vamos a medir ese objetivo? ¿Hay algún límite de tiempo a la vista en el que deba estar listo?

Debemos revisar este tipo de cuestiones con ellos y aterrizar mejor los objetivos. Después de ese trabajo, podemos conseguir unos objetivos similares a estos:

• Implementar una aplicación que calcule la planificación de los equipos de médicos de forma automática a partir de sus preferencias y las restricciones de su tipo de contrato. La aplicación completa no debe estar terminada en una fecha objetivo definida.
• Implementar una primera versión del algoritmo sin interfaz y a partir de unos datos de prueba con diferentes casuísticas que proporcionará el responsable de la clínica para final de mes.

Alcance

Tener los objetivos es el punto de partida, pero no suelen tener todo el detalle necesario para diseñar la solución de arquitectura. Necesitamos conocer los requisitos funcionales y no funcionales que debe y que no debe cumplir.

Para esto sí es interesante conocer las necesidades y problemas del negocio lo mejor especificadas posible con los detalles que son relevantes para el diseño de arquitectura.

En el artículo Diseño de soluciones de arquitectura. ¿Qué es y para qué sirve? describo algunas técnicas para ayudar a analizar la información que necesitamos, como clasificar la documentación, filtrar la información no relevante o preguntar a tope sobre un buen inventario de dudas.

Como ayuda para analizar y entender los requisitos podemos también realizar un glosario de términos, ya que hay palabras que en cada empresa tiene connotaciones o significados diferentes, y seguramente nos encontraremos con un montón de siglas y nombres propios que sólo se conocen en una empresa o contexto.

Otro aspecto importante a tener en cuenta es tratar de eliminar los prejuicios propios o ajenos que pueda haber sobre el proyecto o sus requisitos. Es común que en la cultura de la empresa o en nuestra experiencia haya ciertos prejuicios sobre determinadas formas de hacer las cosas, inercias establecidas y aceptadas, experiencias pasadas que fracasaron… que nos pueden condicionar a la hora de plantear soluciones.

Si conseguimos salir de los prejuicios, podremos ser capaces de proponer soluciones diferentes a las que se le podrían ocurrir a personas que llevan tiempo en la compañía, aprender nuevas formas de hacer las cosas o refutar alguna creencia propia que nos pudiera condicionar.

Otro foco de errores son las asunciones, que pueden ser sobre los requisitos, el conocimiento de las personas o la forma de trabajar de la compañía, por ejemplo. Hay cuestiones que nos pueden parecer muy básicas y damos por sentado que todo el mundo las conoce, o hay información que desconocemos pero que rellenamos con lo que creemos que es más probable.

Hacer asunciones puede ser una buena técnica para rellenar los huecos en la historia, pero debemos ser conscientes de ellas. Debemos tratar de identificar las asunciones que están implícitas en los requisitos o la solución, y confirmar la información con los responsables que tienen el conocimiento.

Por muy básico o probable que nos parezca, si hay un dato que no sepamos si es cierto o no, debemos contrastarlo.

Los requisitos funcionales relevantes para el diseño de arquitectura estarán relacionados con los pasos que requieren los procesos, ya sean manuales o automáticos, los roles de los usuarios, los datos clave relevantes para el procesamiento o las tomas de decisiones, las aplicaciones que utilizarían los usuarios o las funcionalidades principales que necesitan.

Los requisitos funcionales y no funcionales que tratan sobre la interfaz de las aplicaciones hay que mirarlos con cariño, porque tendrán muchos detalles a nivel de campos y diseño gráfico que probablemente no sean relevantes, pero pueden ocultar dificultades o decisiones técnicas sobre la tecnología de front necesaria para que sean viables.

Veamos los requisitos funcionales del ejemplo:

• La aplicación debe proporcionar a los médicos pantallas para gestionar los datos que necesite el cálculo de la planificación desde cualquier ubicación en cualquier momento.
• Los médicos deben proporcionar la misma información que actualmente proporcionan en la aplicación de preferencias de guardias.
• Se debe considerar para cada médico las restricciones que tienen según su tipo de contrato y su situación laboral con respecto a reducciones de jornada u otros condicionantes que afecten a su horario de trabajo.
• La aplicación debe calcular un borrador completo de la planificación de los equipos de médicos de forma automática a partir de un botón.
• La aplicación debe permitir realizar cambios manuales en la planificación por el responsable del equipo. La funcionalidad de cambios manuales debe indicar con alertas al usuario si la planificación modificada tiene defectos.
• El usuario que obtiene la planificación debe poder compartirla fácilmente mediante email.

Los requisitos no funcionales suelen ser los grandes olvidados al inicio de los proyectos y, realmente, son los más relevantes para nosotros. Nuestro mayor aporte de valor está en proporcionar al equipo de desarrollo una arquitectura que les permita ejecutar las funcionalidades en condiciones de calidad y facilitar su desarrollo y mantenimiento.

Que los requisitos no sean funcionales no quiere decir que no sean de negocio. Es muy relevante que las funcionalidades vayan fluidas, que sean estables, que no produzcan errores o que sean seguras para que tengan éxito desde un punto de vista de negocio. También es relevante tener en cuenta si estos requisitos no son importantes para el negocio para evitar hacer sobreingeniería.

Para poder tener en cuenta estos aspectos, desde el principio podemos hacer un cuestionario de requisitos no funcionales a revisar con negocio para que los incluyan en los requisitos iniciales. Pero este tipo de iniciativas no suelen tener éxito porque es difícil especificarlos sin una guía, parece algo burocrático y no se entiende completamente su relevancia.

Mi propuesta es que los requisitos no funcionales que nos interesan formen parte del diseño de la solución, integrados en cada una de las vistas, y los revisemos junto con el resto del contenido.

Esto va a ayudar a analizarlos mucho más sistemáticamente asociándolos a los casos de uso, en un lenguaje más de negocio en base a preguntas sobre los límites de los propios casos de uso.

Por ejemplo, podemos preguntar cuántos usuarios esperan que vaya tener la aplicación o, si la aplicación no funciona, cuánto tiempo puede pasar hasta que la empresa empiece a perder dinero, o qué alternativas podemos tener para sobrevivir mientras tanto.

En cuanto a los límites del alcance, hay que trabajarlos con el resto del equipo de desarrollo. Cómo definirlos dependerá en gran medida de cómo se vaya a gestionar el proyecto o el producto. En cuanto a lo que a la arquitectura respecta, los límites serán los que definamos para cumplir los objetivos y los detalles que necesitemos para proporcionar una solución completa y eficiente.

Estrategia global

En el caso de que el proyecto forme parte de una estrategia más global definida, no sólo partiremos de unos objetivos ya predefinidos, sino que también hay más elementos de contexto a tener en cuenta para ayudarnos a definir la solución.

Probablemente haya ya un diseño de arquitectura de alto nivel que plantee la arquitectura objetivo global que se quiere implementar y un roadmap de arquitectura que establezca los pasos a seguir para conseguirla. Dentro de ese roadmap nuestro proyecto será una pieza más de un puzzle mayor.

Muchas de las decisiones clave de arquitectura ya vendrán predefinidas y partiremos de una definición de alto nivel del diseño de la solución.

Podemos estar tentados de seguir a pies juntillas esta definición de entrada, pero creo que lo apropiado es hacer lo contrario: ponerla a prueba y contrastar que efectivamente es el mejor planteamiento ya que, cuando se ha diseñado, seguramente no se ha profundizado demasiado en los detalles o no ha habido tiempo para comprobar su viabilidad.

En el caso de que detectemos mejoras, propongámoslas, junto con los datos o experimentos que las sustenten, al equipo que diseña la arquitectura objetivo para acordar el diseño de alto nivel de inicio.

Como parte de ese roadmap, puede haber habido proyectos anteriores y seguramente habrá otros proyectos ejecutándose a la vez. Es importante conocerlos porque, en la solución que definamos, podemos tener dependencias que deben resolver otros proyectos y podemos encontrar sinergias en las que aunar esfuerzos.

Es posible también que haya otros proyectos que nos proporcionen estas dependencias y sinergias aunque no se hayan concebido conjuntamente en un mismo plan estratégico. En estos casos, deberíamos tener coordinación con los otros proyectos de cara a las tomas de decisiones comunes y para tener más fuerza en las negociaciones con los stakeholders comunes.

En nuestro ejemplo:

La iniciativa es puntual, pero sería interesante preguntar si existen otros proyectos similares o relacionados. Por ejemplo, en el área de RRHH del hospital podrían estar trabajando en algún proyecto que pudiera crear dependencias en el nuestro, facilitarlo con funcionalidades que nos vengan bien o incluso estar abordando los mismos objetivos, como puede pasar en empresas gestionadas en silos.

Marco de referencia

Si disponemos de un marco de referencia de la compañía, tendremos buena parte del trabajo de análisis hecho, ya que tendríamos un espacio de soluciones posibles mucho más acotado y habría ya ciertas decisiones predefinidas.

Como parte del marco de referencia, podemos disponer de múltiples guías:

• Principios de arquitectura. Nos orientarán en cuanto al enfoque del diseño y cómo tomar determinadas decisiones de forma genérica. Suelen ser abstractos, pero su aplicación se traducirá en poner el foco en la estrategia de la compañía y aplicar buenas prácticas que reportarán los beneficios a medio y largo plazo. Por ejemplo, minimizar la huella de carbono o poner al cliente en el centro de los procesos.
• Arquitectura de referencia. Es un diseño abstracto de la arquitectura ideal de la compañía, a todos los niveles. No es tan específica como la arquitectura objetivo, ya que esta se ciñe a unos plazos y necesidades concretas, pero permite entender cómo sería nuestra arquitectura una vez aplicados totalmente los principios de arquitectura y las decisiones estratégicas clave.
• Patrones de arquitectura. Son diseños de soluciones a problemas comunes que nos permitirán no reinventar la rueda. Por ejemplo, el patrón de arquitectura hexagonal para microservicios. Formarán parte de la arquitectura de referencia con un nivel mayor de detalle y tendrán guías sobre cuándo usarlos y cuándo no. De facto acabarán siendo como normas a seguir que evitarán no solo esfuerzos extra de análisis, sino también incoherencias entre equipos y discusiones.
• Mejores prácticas. Normas más específicas que los principios de arquitectura que serán aplicables directamente en los diseños que hagamos, pero que no podrían materializarse como patrones al no definirse para soluciones específicas. Como, por ejemplo, que los datos tengan un identificador único.

En nuestro ejemplo:

No existe una estrategia tecnológica, marco de referencia o directrices que debamos seguir para implantar soluciones informáticas en el hospital. En este caso, debemos ser cuidadosos en elegir bien las tecnologías a utilizar, o incluso sentar las bases de ese marco de referencia para facilitar el mantenimiento del entorno de aplicaciones.

Arquitectura actual

Casi todo lo que leo o escucho parece orientado a startups que crean un producto aislado desde 0. En el trabajo, lo que me encuentro son empresas que ya disponen de (más o menos avanzados o automatizados) unos sistemas informáticos que dan soporte o hacen funcionar el negocio.

La mayoría de los proyectos crean mejoras en las aplicaciones existentes y, cuando crean una aplicación nueva, no está aislada, sino que necesita integrarse en un ecosistema. Incluso en proyectos de transformación digital o de migración al cloud, difícilmente crearemos todo desde cero.

El impacto de la solución que diseñemos serán cambios en una arquitectura ya existente y debemos tener en cuenta toda la información relevante de la arquitectura actual de la que podamos disponer.

Comprender la arquitectura actual es muy relevante. Si vamos a realizar cambios sobre la arquitectura existente, necesitaremos saber qué procesos, funcionalidades, datos o componentes existen ya, tanto si es para reutilizarlos como para apoyarnos en ellos o evitar duplicidades, incoherencias, conflictos u otros impactos que causen problemas.

Los cambios pueden conllevar incrementos en los usuarios o datos a procesar que requieran redimensionar la infraestructura. O quizá la tecnología no soporte los cambios y haya que plantear no sólo un desarrollo nuevo, sino una migración de lo existente.

También habrá que considerar que la empresa tenga compromisos o acuerdos con determinados proveedores que nos van a condicionar las posibles tecnologías a utilizar.

Idealmente, la empresa dispondría de un repositorio de arquitectura bien actualizado que nos proporcione esa información. Idealmente. Con que hubiera algunos documentos actualizados que describan las aplicaciones principales, ya me daría por satisfecho. Aprovechemos lo que haya. Si podemos hacerlo, es mejor enlazar el contenido que replicarlo como parte del diseño.

Probablemente, tendremos que indagar con los demás equipos para conseguir la información que necesitemos y, para ello, lo mejor es que incluyamos el entendimiento de la arquitectura actual como parte del análisis de información que describimos en la sección de alcance mediante preguntas específicas de lo que necesitemos conocer.

Si vamos a describir la arquitectura existente desde el inicio, mi propuesta es utilizar el mismo esquema que haríamos para describir un diseño de solución de arquitectura. Y, si podemos utilizar un repositorio de arquitectura que permita relacionar y analizar la información y que podamos mantener actualizado, mejor.

Para nuestro proyecto:

A partir de la descripción del problema, podemos ver que ya existe una aplicación en la que los sanitarios registran sus preferencias de guardias. Podemos implementar los requisitos sobre esta aplicación ya existente.

Al preguntar sobre la información de los contratos, descubrimos que se gestionan en la aplicación de RRHH. Cada empleado tiene su contrato en vigor y cada contrato tiene una tipología, lo que nos facilitará determinar las restricciones de horario del trabajador según el tipo de contrato. Esta aplicación tiene una capa back con servicios que permite realizar consultas sobre los empleados y sus contratos, que actualmente sólo usa su frontal.

Restricciones: presupuesto, plazos, personas

Se suele decir que, en informática, todo es posible con suficiente tiempo y dinero, y creo que probablemente es verdad. Y también es verdad que son los recursos en los que nos encontramos los límites para el diseño de la solución.

Nuestro diseño tendrá que tener en cuenta las restricciones del proyecto y tendrá que ser viable en este contexto. Esta perspectiva nos va a ayudar a identificar si estamos haciendo sobreingeniería y que la solución sea realista.

Al aplicar estas restricciones nos encontraremos con problemas y debemos analizar en qué grado nos afectan:

• Si debemos plantear una solución que no cumpla determinados requisitos, funcionales o no funcionales, afectando al alcance del proyecto.
• Si debemos establecer un roadmap que cumpla parte de los requisitos en el plazo establecido y el resto de requisitos en un plazo posterior.
• Si planteamos una solución que sale de los estándares de la empresa para hacerla viable, por ejemplo, con productos no homologados o que no cumpla determinados patrones, contrayendo una deuda técnica. (Ojo de no confundir esto con hacer ñapas que puedan causar más problemas que beneficios o con gastar dinero en soluciones tácticas que luego hay que tirar).
• Levantar el problema si no hay una solución viable para cumplir con los objetivos con las restricciones planteadas.

También es posible cuestionar estas restricciones. Podemos justificar la necesidad de conseguir más presupuesto o tiempo para ejecutar el proyecto. ¿De verdad la fecha objetivo se debe a una necesidad real del negocio o es simplemente una fecha comprometida por algún director?

El momento de diseñar la arquitectura es propicio para valorar y discutir las restricciones del proyecto, ya que estamos en una fase temprana para tomar decisiones clave con poco coste y alto impacto.

El diseño de la solución y el análisis que nos ha conducido a su inviabilidad van a ser clave para explicar las razones y valorar las alternativas cuando se necesite negociar el presupuesto o los plazos con los sponsors y stakeholders.

Esto nos lleva a la siguiente restricción a tener en cuenta: las personas. Tanto la elaboración de la solución como las implicaciones que conlleva su diseño van a tener impacto también en la organización, que no solo son roles con una función, sino personas con su propia visión, conocimiento, preferencias, objetivos personales, ambiciones, posiciones políticas, influencia y egos…

La solución que propongamos debe ser aceptada por los stakeholders para que se lleve a cabo y, por muy bien que esté diseñada técnicamente, habrá que tener en cuenta también si está alineada con los intereses de las personas interesadas.

Por eso es importante que obtengamos del contexto la organización, cuáles son las personas que deben aceptar el diseño, cómo son sus relaciones formales e informales, quiénes tienen el poder de decisión y cómo les afecta nuestra propuesta.

Esta información será muy relevante para tenerla en cuenta en el diseño, para validarlo con estas personas y para negociar las decisiones cuando no haya consensos.

Para nuestro ejemplo:

No hay unas fechas exactas que restrinjan los plazos del proyecto, pero observamos que cada mes que pasan por este proceso es un pequeño infierno para todo el equipo, por lo que sería deseable proporcionar alguna ayuda en el próximo mes.

El presupuesto permitiría tener a un desarrollador de software durante 3 meses y un arquitecto de soluciones durante un mes completamente dedicados.

El hospital tiene un equipo de informáticos que dependen de la dirección médica, que son los que llevan el mantenimiento de las aplicaciones. Sería importante conocernos y entender cómo funciona la gestión informática del hospital, cómo suelen trabajar y cómo coordinar con ellos la implantación de la solución. Probablemente ellos se encarguen del mantenimiento de la aplicación, por lo que es importante su aceptación para el modelo de solución.

Resumen

En este artículo hemos repasado los aspectos del contexto de un proyecto que deberíamos tener en cuenta para orientar la solución lo mejor posible:

• Asegurar que los objetivos están especificados y son claros.
• Entender completamente los requisitos y estar alineados con el equipo en el alcance del proyecto.
• Tener en cuenta la estrategia de arquitectura y el marco de referencia, que añaden requisitos adicionales a la solución.
• Conocer la arquitectura actual en la que se debe integrar la solución.
• Conocer las restricciones de presupuesto y plazos para poder validar que la solución planteada las cumple y tener en cuenta los criterios y necesidades de los stakeholders.