Jeronimo Palacios & Associates

Transformación digital

Software

Domain Driven Design: del Modelo al Diseño

Introducción

Este es el segundo artículo sobre las lecciones aprendidas aplicando Domain Driven Design en el equipo de desarrollo de Jerónimo Palacios & Associates. 

En la anterior entrada, te hablé sobre el mapeado del dominio en el modelo. En esta ocasión, te contaré cómo realizamos el segundo paso, la implementación del modelo en el diseño. 

Creando el diseño: ida y vuelta.  

Los técnicos estamos acostumbrados a transformar modelos en diseños. Formalicemos o no el modelo en un documento, cuando nos describen un problema, inmediatamente nos ponemos a pensar solución en código. Es nuestra forma de razonar. No podemos evitarlo. 

Una de los aprendizajes más difíciles e importantes para un técnico es oponerse a este instinto. Cuando estamos construyendo el modelo debemos evitar contaminarlo con detalles de diseño para que sea útil como herramienta de comunicación con negocio. Pero esto no significa que el modelo esté aislado del diseño. No es una entidad abstracta que esté por encima y domine al diseño. Todo lo contrario, el modelo debe ser realista e implementable. 

Es totalmente normal y esperable que, como consecuencia de su trabajo,  el equipo de desarrollo encuentre problemas en el modelo. Estos problemas pueden tener su origen en la implementación o errores en el modelado del dominio puestos de manifiesto en la práctica. Sea cual sea el caso, los cambios en el modelo se evalúan con negocio (Product Owner, Business Analyst) para garantizar su consistencia.

Este proceso de realimentación mejora el modelo y, sobre todo, proporciona transparencia a negocio sobre su implementación. El conocimiento de la realidad del código por parte de negocio les permite comprender las limitaciones de la solución. Este conocimiento “técnico” es tan importante para la evolución de la aplicación como el conocimiento del equipo de desarrollo sobre el dominio del negocio. Y, de nuevo, el modelo va a jugar un papel central en este intercambio de información.  

Formalización del Diseño

El diseño es propiedad del equipo de desarrollo y ellos deciden la mejor forma de reflejarlo. En  muchas ocasiones no es necesario un documento formal. La documentación de diseño es muy costosa de mantener. Tan pronto como pongo el punto y final en un documento de diseño, queda desactualizado. Las dudas sobre la veracidad de esta documentación nos lleva continuamente a acudir a los artefactos de implementación como origen inequívoco de la verdad del sistema. En muchas ocasiones, el esfuerzo no compensa y es mejor prescindir de documentación e ir directamente a la fuente. Somos técnicos, sabemos leer el código. 

Como te comentaba en la serie de entradas sobre diagnóstico de arquitectura , la documentación formalizada de diseño es útil para proporcionar una visión rápida y general sobre la solución. En caso de necesitarla, la documentación debe limitarse a los elementos más estables. Es decir,  los más difíciles de modificar.  

El  nivel de arquitectura (servicios, orquestación, despliegue y componentes) es muy costoso de refactorizar, por lo que suele ser bastante estable. Otro caso son las clases o funciones centrales en la red de dependencias. Son aquellas que reciben más dependencias entrantes y, por lo tanto, son más significativas para la aplicación. Son difíciles de modificar porque tienen un enorme impacto colateral. Ambas vistas del sistema son muy relevantes para su mantenimiento por lo que suelen estar en la documentación formalizada de diseño. 

Patrones DDD como piezas de diseño. 

DDD propone una serie de patrones bien conocidos para mapear el modelo en el diseño. Por ejemplo: Value Objects, Entities, Factories, etc. En general, las indicaciones sobre su aplicación son muy razonables y se corresponden con el uso conocido de estos patrones. Sin embargo, el catálogo de patrones me resulta un poco reducido y de alto nivel de abstracción. Para algunos casos de uso, hemos recurrido a patrones más especializados como: builder, command, interactors o presenter. 

En general, respecto a arquitectura y patrones, somos más de Robert C Martin que de Eric Evans. Particularmente, el modelo de capas en forma de cebolla que propone Uncle Bob, me resulta más natural. Con el dominio en el centro y diana de las dependencias del sistema, frente al apilado de capas sugerido en DDD.  En cualquier caso, hay una correspondencia clara entre los niveles de abstracción de uno y otro, por lo que no son incompatibles. En la siguiente figura tienes los niveles identificados en Clean Architecture (rojo) y las correspondencias en DDD (azul)

Relación entre capas descritas por Eric Evans en DDD y Robert C Martin en Clean Architecture

Tecnologías de Desarrollo

Como describo en el artículo sobre arquitecturas emergentes, debemos centrarnos en lo realmente importante, el dominio, y aplazar  al Last Responsible Moment la elección de herramientas concretas como frameworks y middleware.

Me gusta emplear una estrategia oportunista, recurriendo a las herramientas que mejor se adaptan al caso de uso. Pero, como todos, en JPA tenemos preferencias por las tecnologías que dominamos y con las que nos sentimos más cómodos. Algunos ejemplos son el paradigma orientado a objetos y los lenguajes con validación estática de tipos. 

Paradigma OO

La programación Orientada a Objetos es una forma natural y directa de implementar la mayoría de los modelos. De los atributos de la programación orientada a objetos: abstracción, polimorfismo, herencia y encapsulamiento; es ésta última la que más me gusta y la que, por tanto, echo más en falta cuando trabajo con otros tecnologías que no le dan soporte directo (como Javascript o Python). Ocultar elementos de la implementación nos hace posible exponer una interfaz clara para dependencias y es la mejor forma de limitar el impacto de los refactoring. 

Paradigma Funcional

El  funcional se aplica muy bien en las partes del modelo que tienen una naturaleza claramente matemática. Para eso se creó. En nuestra herramienta Metrics, toda la base de cálculo se ha implementado empleando patrones funcionales:  funciones de alto nivel, inmutabilidad y librerías de colecciones. 

Validación estática de tipos. 

Los lenguajes con validación estática de tipos me resultan más cómodos para desarrollar lógica compleja. Anticipar la detección de errores al tiempo de compilación me da mayor seguridad sobre la robustez del resultado. La estrategia Shift-Left DevOps dirige nuestras prácticas. Qué puede anticipar más los chequeos, a que sea el propio IDE quien me corrige errores mientras tecleo.  

Por otro lado, tengo menos memoria que Dory. Ir tecleando y que el IDE me sugiera los métodos de una clase o me autocomplete, me da la vida. 

Por último, los patrones de refactoring están mejor soportados en este tipo de lenguajes. Si habéis sufrido el refactoring en Javascript, os sugiero probar a disfrutar de la misma experiencia con Java. 

Conclusiones

Con este artículo completo mi primera entrada sobre la aplicación de Domain Driven Design en el equipo de desarrollo de JPA. Os he contado algunas prácticas y herramientas que empleamos en JPA para realizar la transformación del modelo al diseño y su implementación. 

No cierro el tema, todo lo contrario. Me encanta debatir sobre tecnología. Pon tus comentarios o escríbeme y encontremos juntos mejores soluciones. 

Domain Driven Design o Dominio, Dominio y Dominio

Introducción

Domain Driven Design (DDD) es una práctica de desarrollo de software que pone el acento en el Dominio del Negocio como faro del proyecto y en su Modelo como herramienta de comunicación entre negocio y tecnología. En el equipo de desarrollo de JPA empleamos Domain Driven Design  como referencia para afrontar proyectos de desarrollo de cierta complejidad. Fruto de nuestros errores pero, sobre todo, de responder a las preguntas honestas de unos compañeros y los dardos envenenados de otros, hemos ido refinando su aplicación. En este artículo te presento algunas conclusiones y prácticas que pueden facilitarte la aproximación a sus principios. 

Lo más importante es el Dominio. 

Parece de perogrullo ¿Verdad? Como técnico, lo que primero llamó mi atención de DDD fue el conjunto de patrones de diseño recomendados para implementar el modelo: Value Object, Entity, Service, Factory, Repository, etc. Los patrones son herramientas con larga tradición y consolidados en la industria (GOF , Martin Fowler, Eric Freeman, etc). Esta experiencia previa  me llevó a pensar que eran, precisamente estos patrones, la mayor contribución de DDD. Y me equivocaba. 

Lo realmente relevante del DDD es la machacona insistencia en el Dominio como fuente de verdad para el desarrollo de software. Hay que volver a él siempre que pienses que te estás desviando del camino correcto. Por ejemplo, cuando no estés seguro del valor de la funcionalidad que estás desarrollando o cuando sospeches que estás matando moscas a cañonazos (overengineering). Hay que aprender a tener el dominio siempre visible y poner en duda el valor de todo lo que no quepa en él.

“Poner en duda todo desarrollo que no esté contemplado por el dominio es la principal lección de Domain Driven Design”

¿Cómo concretamos el Dominio?

Mediante su modelo.  El modelo es un conjunto de artefactos (diagramas, documentos, prototipos, etc. ) que contiene una representación significativa del Dominio. Es un paso intermedio entre el dominio del negocio y el diseño tecnológico. El valor del modelo es doble: 

  1. Es el glosario del  Lenguaje Ubicuo (“Ubiquitous Language”) . Debe ser comprensible y significativo para negocio y tecnología. Todos los miembros del equipo (incluido negocio) emplean los términos del modelo en sus comunicaciones: Historias de Usuario, Casos de Uso, Features, Tareas, etc. 
  2. Son los cimientos y el espejo del diseño de software.  El equipo de desarrollo emplea el modelo para crear un diseño que lo implementa. Pero además, mantendrá sincronizado diseño y modelo a lo largo de toda la vida del proyecto. Todo cambio en el diseño deba ser validado contra el modelo. Si como consecuencia del desarrollo se considera que el modelo debe ser ajustado, los cambios se revisan con negocio y se llevan al lenguaje ubicuo. 

El punto 2 es el que requiere un mayor esfuerzo de adaptación y concentración cuando nos introducimos en DDD. Mantener sincronizado modelo y diseño es costoso. Es precisamente este coste, el que te lleva a valorar con mucho más cuidad los cambios en el desarrollo. El temido efecto: “pues ya que estoy…”. Pesar la contribución de valor de un cambio frente a su coste se convierte en un ejercicio continuo. 

Elaboración del Modelo

En DDD el modelo nacerá y evolucionará mediante dos fuerzas: negocio y desarrollo. Ambos puntos de vista deben estar implicados en su creación desde el comienzo. El equipo de desarrollo debe apreciar el modelo como un producto más de su trabajo, comprender cómo le ayuda a crear mejores soluciones y sentirse tan orgulloso de la calidad del modelo como de la del código. 

Delegar la creación o el mantenimiento del modelo a un analista externo al equipo, simplemente, no funciona. El equipo debe estar implicado en el esfuerzo cognitivo de análisis y modelado del dominio, sin intermediarios. Es la única forma de mantener un proceso ágil y garantizar la implicación del equipo en su mantenimiento. 

Herramientas de Modelado

Ya soy un veterano de esta industria. He pasado por procesos pesados como RUP. donde se recurre sistemáticamente a artefactos de modelado para comunicar entre etapas. Cuando trabajé  como business analyst o como diseñador, empleé extensivamente UML y BPMN. Posteriormente, con todo el movimiento Agile y especialmente XP, evité estas herramientas bajo el principio de que el código debía ser autoexplicativo. Como siempre, en el equilibrio se encuentra la virtud.

Las herramientas de modelado (UML entre otras) son muy útiles en la construcción de un marco significativo para todos los actores. El código, es mucho más difícil de entender por negocio. Incluso empleando frameworks específicamente adaptados para hacerlos más expresivos, como Domain Specific Languages. 

El código puede ser suficiente para el diseño. La organización en módulos y componentes, una estrategia consistente de asignación de responsabilidades, así como unas prácticas de nombrado uniformes, deben hacer evidente el diseño. 

Puedes apoyarte en herramientas de análisis de código que tienen muchos IDEs para crear diagramas con las entidades y dependencias presentes en el software. Esto facilita la comprensión del diseño y su validación contra el modelo. Los diagramas de análisis tienen la ventaja de ser efímeros, los creamos y los desechamos sin excesivo coste, por lo que no tenemos que gestionarlos. La ausencia de un documento de diseño evita que reemplace a la verdad reflejada por el código. 

Ten cuidado con UML. Es una herramienta muy versátil que permite introducir aspectos de implementación. El Modelo NUNCA debe contener detalles como herencia, encapsulamiento o tipos concretos. Y no lo digo porque el modelo deba ser agnóstico respecto a la tecnología de implementación (raramente buscamos eso en un proyecto), sino porque pierde su papel como paso intermedio al diseño. Recuerda,  es una abstracción empleada para comunicar con negocio y para guiar el desarrollo. 

Es un auténtico sufrimiento estar continuamente evitando escribir detalles de diseño en el modelo. Pero este es precisamente el objetivo de DDD. Forzar el uso por todos los interlocutores de un nivel de abstracción compatible con el lenguaje ubicuo. 

Gestión del Modelo

He trabajado con compañeros que prefieren crear los modelos a mano (con rotulador). El principal argumento es que reflejan la naturaleza siempre cambiante del negocio en un artefacto que está siempre “en construcción”

A míi me resulta farragoso. Si empleamos una pizarra, se borra accidentalmente. Si empleamos papel, rápidamente se llena de tachones y estamos más tiempo pasando a limpio que creando. En ambos casos, la información es difícil de compartir. 

Yo prefiero un formato digital. He empleado herramientas especializadas como Visual Paradigm, o ArgoUML. Conozco todo lo que me aportan y también todo lo que me sobra. Por eso, en muchas ocasiones, prefiero emplear una herramienta más ligera, tipo diagramas. Draw.io me funciona bien para proyectos pequeños y medianos. No obstante, siempre estoy revisando las herramientas disponibles. Si estás usando alguna que te vaya bien, por favor, ponlo en los comentarios. 

Conclusión: Vigila el Modelo

Domain Driven Design es una técnica que implica dos transformaciones, del negocio al modelo y del modelo al software

El modelo juega un papel central para asegurar la correspondencia entre el software y el negocio al que debe representar. El modelo debe estar siempre presente en la mente, en los ordenadores y en las pizarras de los equipos multidisciplinares. Buscamos una mentalidad de “Policía del Modelo” que persiga cualquier desviación de la consistencia de esta correspondencia. 

Este es el primero de una serie sobre lo que hemos aprendido aplicando DDD en Jerónimo Palacios y Asociados. En el próximo, bajaré a la transformación del modelo en diseño. Algunas soluciones propuestas por DDD que hemos empleado y otras que no. 

Imagenes :

Para saber más:

En nuestra formación DevOps profundizamos el papel de Domain Driven Design en la creación de soluciones desacopladas, fáciles de testar y de desplegar. Si te interesa saber más, rellena este formulario para que te podamos enviar información.

Arquitecturas Emergentes o como curar de espanto a tu jefe

Antecedentes

En el equipo de desarrollo de JPA tuvimos la suerte de iniciar un proyecto green-field para la gestión de métricas de equipos ágiles, JPA Metrics. El objetivo de este proyecto es llevar a una aplicación la experiencia adquirida en consultoría ágil sobre la aplicación de métricas. No pretendemos reemplazar las ventajas de contar in-situ con un gran profesional, pero sí que buscamos poder ayudar a más organizaciones en su transformación.

Cuando partes de cero tienes todas las decisiones frente a ti. Esto es genial, pero también abruma. No se si te pasa, pero a mi, tener un abanico tan grande de opciones, me puede bloquear. Como orgullosos ingenieros que somos, queremos tomar la mejor decisión para nuestro sistema. Queremos optimizar prestaciones por coste (con un presupuesto siempre muy limitado). Así que nos ponemos a analizar y a revisar. A sacar números (mis queridas hojas Excel) para ver qué nos conviene. Esto nos puede llevar a la tan temida “muerte por análisis”. 

¿Merece la pena este esfuerzo anticipado? Mi experiencia me dice que raramente. En los proyectos grandes, la bola de cristal no funciona. Vamos aprendiendo y adaptando sobre la marcha. 

François Truffaut decía en “La noche americana”, que el trabajo de un director de cine consiste en tomar decisiones. Mi experiencia en esta industria es similar. En muchas ocasiones, los compañeros se acercan a pedirme opinión sobre alternativas de diseño. Evalúo la información que me dan, elijo una opción y se van tan contentos. No saben que, muchas veces, las tomo al voleo. Cuando no hay criterios sólidos, es mejor probar algo que bloquearnos. Un mono con Eclipse y todo el tiempo del mundo hará el diseño perfecto. 

Así, la aproximación más práctica es apostar por diseños emergentes. Es decir, aplazar las decisiones hasta el último momento (Last Responsible Moment), cuando disponemos de más información y experiencia para fijarla. No especulamos. Aplicamos los hechos ya confirmados a mi hoja de excel y elegimos lo que salga. Esto es puro Lean Development (sin certificación, ni leches).

En el desarrollo con infraestructuras on-prem, el riesgo de esta aproximación es muy alto. Hay que comprar la infraestructura y no tenemos ni tiempo ni dinero para estar probando. Pero con la computación en la nube, y más concretamente, con los servicios de PaaS, esto cambia. Podemos tomarnos el lujo de desarrollar sobre una plataforma provisional, para ir, poco a poco ajustando las decisiones que la consolidan. 

Las plataformas flexibles nos permiten centrarnos en lo que realmente importa, la arquitectura del software. Mezclando a Robert C. Martin y a Jose Luis Cuerda:

La plataforma es contingente pero la arquitectura es necesaria.

Así, podemos elegir los componentes que más nos convengan, por precio, disponibilidad y conocimiento. Para luego ir reemplazándolos a medida que el proyecto avanza y tenemos requerimientos cualitativos concretos: disponibilidad, concurrencia, latencia, etc.

Esto puede dar un poco de miedito ¿Podremos cambiar la plataforma cuando tengamos decenas o cientos de miles de líneas de código? Para eso, tenemos que centrarnos en un diseño desacoplado, a nivel de lógica y (de nuevo) de plataforma. Algunas herramientas que me han resultado muy útiles son:

El Diseño Dirigido por Dominio

DDD nos ha funcionado muy bien a la hora de fragmentar el Dominio en bloques coherentes (Bounded Context) que se pudieran llevar a servicios independientes (microservices). También empleamos el catálogo básica de patrones DDD para el diseño de componentes: Entities, Value Objects, Aggregates, Services, Factories & Repositories. Extendemos este catálogo con patrones que nos ayudan a introducir desacoplamiento. No soy un friki de los patrones de software, pero si que son de gran ayuda a la hora de manejar el conocimiento sobre el diseño dentro del equipo. 

Clean Architecture

Todos los días le ponemos una vela al Tío Bob para que nos oriente en la aplicación de diseños circulares (como hexagonales, pero sin vértices). Clean Architecture es nuestro patrón para la división en capas de los microservicios. 

Test, test y más test 

Este es mi mantra. El desarrollo IT es muy complejo…, testea a tu entrada y a tu salida y ya lo tienes hecho. BDD para definir cambios SMART  y TDD como faro para el desarrollador. 

Continuous Refactoring

Si tienes una cobertura de test que te da seguridad, el refactoring te sale natural. Es evidente que cuanto mayor sea el nivel, más costoso. No es lo mismo hacer refactoring de un componente que hacerlo de un módulo o de un servicio completo. Pero siempre es más realista que agarrarse al diseño preestablecido por su coste hundido. 

Experiencia

Con arquitectura emergente, no quiero decir que contar en el equipo con experiencia no sea valioso. Todo lo contrario. Aunque partamos de una propuesta, no es lo mismo que el diseño esté basado en una práctica consolidada a que se improvise pintando cajas a lo loco. La experiencia en arquitectura de software nos va a evitar muchos ensayos y va a acelerar la evolución de la aplicación.

wtf

Las arquitecturas emergentes ponen nerviosos a los stakeholders

En JPA tenemos una reunión semanal donde todas las áreas dan visibilidad a su trabajo. Recuerdo que hace unos meses presenté los resultados de los test de carga, en nombre del equipo de desarrollo. Yo estaba muy orgulloso de que, por fin, hubiéramos conseguido complementar test funcionales con test automáticos sobre cualidades del sistema. La carga se generó sintéticamente (no teníamos usuarios reales)  para una concurrencia que me pareció representativa y realista con la plataforma que empleamos en esos momentos: un dyno hobby en Heroku XD. 

Al poco de terminar la reunión, Jerónimo me llamó. Quería hablar sobre las expectativas de la compañía para la aplicación y “sugerirme” algunas prácticas técnicas que nos podrían ayudar. Una luz roja se me encendió en la cabeza inmediatamente. 

Para ingenieros novatos. Que tu jefe te diga como hacer tu trabajo no es una señal de interés. ES QUE ESTÁ PREOCUPADO. 

Así que, a pesar de que ni de lejos era la intención de Jero, me planté en su casa con el portátil. 

Yo le dije. “Te voy a explicar las decisiones técnicas que hemos tomado para garantizar el futuro de la aplicación”. Y él, puso cara de,  “Ofús” :|

Abrí el IDE y le enseñé la arquitectura de la aplicación mediante la división del dominio en módulos, paquetes y componentes. Jero tiene conocimientos técnicos sobrados para entender el diseño. Pero, además, salta a la vista sin más que ver la organización del proyecto.

Revisamos el diseño RESTful del de backend y el uso de un cluster noSQL para proporcionar servicios escalables y efímeros.   

Le mostré, en la práctica, como aprovisionamos a demanda los entornos de desarrollo y test en los equipos de trabajo y los de integración en el proveedor de cloud. Corrí los test automáticos mientras nos tomábamos una cerveza. 

Le expliqué cómo evitamos las dependencias con proveedores: creando interfaces con la infraestructura y empleando contenedores. Hoy en día corremos sobre EKS y AKS y tardamos menos de una hora en tener la aplicación corriendo desde cero.

Revisamos las métricas de código en SonarCloud, la frecuencia de despliegue (varios por día), el tiempo de despliegue (<1h) y la tasa de errores por despliegue (<10%). Le hice una demo. Corregimos un error de UI mientras nos tomábamos otra cerveza. 

man pointing up
Photo by Alex Sheldon on Unsplash

Resultado

No me ha vuelto a llamar.

Bueno, si. Me pidió que le hiciera lo mismo a más gente (es un poco sádico). Y en ello estamos. Jero me ayudó a organizar los contenidos de una acción formativa sobre DevOps (ya disponible) y estoy preparando un taller práctico (picando código) que están sufriendo mis compañeros. Esperamos tenerlo listo en breve.

[Leer más…] acerca de Arquitecturas Emergentes o como curar de espanto a tu jefe

Hablemos de desarrollo de Software

Hace más de 15 años que monté mi primera empresa de Software. Por aquel entonces era un chaval que tenía más energía y curiosidad que conocimiento, y que junto con un par de socios decidió embarcarse en el mundo de la web. Hacía poco de la explosión de la burbuja .com y los congresos de webmaster todavía eran algo a lo que iba la gente.

Hoy las cosas han cambiado. La carrera programador, analista y jefe de proyecto que vino después ha dejado paso a una aceptación de que los proyectos están muertos y que la mentalidad de producto pesa en una generación que es digital-first. Las empresas necesitan cambiar el time-to-market. Para eso necesitamos cabezas pensantes, no monos ejecutores.

Esto ha provocado un cambio en el mercado del desarrollo de Software. Aproximadamente hace cuatro años empezaron a romperse los techos de cristal del mundo del desarrollo en España. Cuando nuevos productos irrumpen en un mercado dominado por las tarifas por hora, los mejores desarrolladores deciden abandonar el barco y mejorar sus condiciones económicas y laborales. Coincide con la etapa final de la web 2.0.

Dejé de programar profesionalmente hace más de 10 años, después de pelearme con Java y comenzar a amar Ruby on Rails, que introdujo conceptos que para mi eran completamente desconocidos, tales como el desarrollo ágil de Software, los tests continos, behaviour-driven development y gestión de la configuración con Puppet.

Durante estos últimos años dedicado a llevar agilidad a compañías, primero como Scrum Master, luego como Agile Coach y posteriormente como Professional Scrum Trainer, no he dejado de pensar en lo que disfrutaba desarrollando Software. Creo que es imposible quitarse la mentalidad de resolver problemas una vez que la tienes.

He tenido que aprender a lidiar y a explicar conceptos básicos como la necesidad de hacer tests o invertir en un stack de integración continua desde el punto de vista de negocio y no de desarrollo. Porque al final quien pone el dinero para que esas cosas ocurran son personas que, en la mayoría de las ocasiones, no tienen experiencia en desarrollo. Y eso está bien. Si Mahoma no va a la montaña, la montaña irá a Mahoma.

Hoy hace apenas dos años que trabajaba sólo y decidí hacer un llamamiento a gente que, pensando como yo, viniendo del mundo del Software, hubiera andado el camino hacia transformar organizaciones y no puedo más que alegrarme del éxito que ha tenido. Hoy nuestra facturación se mide en siete cifras y somos 16 compañeros. No parece que lo estamos haciendo mal.

Sin embargo, nunca he dejado de pensar en que lo que a mi me gusta es crear cosas. La transformación es una experiencia interesante y de un ámbito distinto. El problema del Software es que requiere de capital, paciencia y tiempo, sobre todo si quieres hacer las cosas distintas en un mercado que es más maduro que incipiente.

[fusion_gallery layout=”masonry” picture_size=”” columns=”” column_spacing=”” gallery_masonry_grid_ratio=”” gallery_masonry_width_double=”” hover_type=”” lightbox=”yes” lightbox_content=”” bordersize=”” bordercolor=”” border_radius=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=””][fusion_gallery_image image=”https://jeronimopalacios.com/wp-content/uploads/2019/10/CFD.png” image_id=”15240″ link=”” linktarget=”_self” /][fusion_gallery_image image=”https://jeronimopalacios.com/wp-content/uploads/2019/10/MTTR.png” image_id=”15241″ link=”” linktarget=”_self” /][fusion_gallery_image image=”https://jeronimopalacios.com/wp-content/uploads/2019/10/Historgram.png” image_id=”15243″ link=”” linktarget=”_self” /][fusion_gallery_image image=”https://jeronimopalacios.com/wp-content/uploads/2019/10/Unplanned-800×344.png” image_id=”15242|800″ link=”” linktarget=”_self” /][fusion_gallery_image image=”https://jeronimopalacios.com/wp-content/uploads/2019/10/Scatterplot-800×387.png” image_id=”15239|800″ link=”” linktarget=”_self” /][fusion_gallery_image image=”https://jeronimopalacios.com/wp-content/uploads/2019/10/JPA-Metrics-800×399.png” image_id=”15238|800″ link=”” linktarget=”_self” /][/fusion_gallery]

 

Con todo esto en mente, en Junio nos decidimos a abrir la tercera pata de JP&Associates, la del desarrollo de Software. Ha sido un lanzamiento de perfil bajo en donde nos hemos preocupado más de empezar a hacer que a contar. Estamos todavía incorporando compañeros y hemos desarrollado nuestro primer MVP: Metrics. Una aplicación para reportar métricas de delivery en equipos ágiles que ya estamos usando en cliente. Puedes pedirnos una invitación aquí.

Lo interesante no sólo es la aplicación, sino todo lo que hay detrás: Código limpio, testing, métricas de código y continuous delivery sobre contenedores para desplegar en cualquier plataforma en la nube, sobre un stack Java y React/Vue.

El futuro es incierto y queremos cambiar la forma de vender desarrollo de Software, desde proyectos cerrados hasta Sprints con incrementos de valor terminados y eso supone renegociar la forma de hacerlo con los clientes. Nuestra propuesta de valor de partida es clara: Ofrecer un equipo ágil completo capaz de entregar incrementos de valor y hacerlo a través de Sprints.

Estamos empezando a hablar con clientes que buscan nuevas formas de colaboración más centradas en el valor y menos en los contratos. Si piensas que tu o tu empresa pueden serlo, ponte en contacto con nosotros.

Diagnóstico de Arquitectura de Software Basado en Experto

 La Arquitectura de Software es central en la estrategia de las organizaciones que basan su negocio en el uso intensivo de la tecnología. Sus atributos de desplegabilidad y testabilidad son fundamentales para una organización que se plantee la evolución hacia DevOps, son el foco de un diagnóstico de arquitectura de software. Por otro lado, el State of DevOps Report  2018 señala como fundamental la adaptación de la arquitectura para estandarizarla y ajustarla a las necesidades de negocio. 

 Cuales son los elementos de la arquitectura de software a mejorar y cómo priorizar los cambios es el objeto fundamental del Diagnóstico de Arquitectura de Software. En publicaciones anteriores hablé sobre el valor de arquitectura y su diagnóstico, así como la metodología basada en escenarios de uso. En esta entrada te introduciré al diagnóstico basado en experto. 

Casos de Aplicación del Diagnóstico basado en Experto

En el anterior artículo sobre diagnóstico con escenarios de uso, vimos como retornaba un gran valor a la organización en forma de activos tangibles y cambios culturales. Como inconveniente, tiene un coste elevado en términos de tiempo y dedicación de personas claves para la organización. Esto hace que la aproximación basada en escenarios no siempre sea la mejor. 

En algunos contextos, cultura de empresa o situaciones especiales, se prefiere limitar el número de personas implicadas sobre el proceso. Otro caso, es que se desee obtener una visión rápida e independiente sobre las características fundamentales de la arquitectura. En estos casos, una aproximación basada en el trabajo de un experto externo puede resultar más conveniente en su relación conste-resultados. Algunos ejemplos que me he encontrado en mi carrera profesional son: 

  •     La evaluación de los activos IT de una compañía para su posible adquisición o como socios de negocio (ej, Due Diligence).
  •     Procesos de acreditación de cumplimiento de estándares o normativas reguladoras (ej, RGPD, implementación de receta electrónica).
  •     Reorganización del área tecnológica de la compañía (Ley de Conway). 
  •     Valoración del estado para un nuevo ejecutivo a cargo del área de IT. 

En general, las metodologías basadas en escenario son ideales para conducir un diagnóstico interno. La incorporación de de un facilitador externo, ayuda a consolidar esta práctica en la organización. Por el contrario, si lo que se necesita es un resultado rápido realizado por un asesor externo, la aproximación basada en experto parece más adecuada.

Herrameintas para el diagnóstico de arquitecturas de software

Proceso de Diagnóstico 

El asesor realiza el diagnóstico recabando la información disponible por la organización sobre la arquitectura y con reuniones limitadas a un conjunto muy reducido de expertos en negocio y tecnología. El propio patrocinador del estudio y un arquitecto suele ser suficiente.

A diferencia de la aproximación colaborativa planteada por la estrategia de escenarios, los atributos de la arquitectura no emergen como consecuencia del debate, sino que son identificados por el asesor y confirmados por la organización. En este sentido, distintos trabajos ponen de manifiesto que es más productivo, cuando se dispone de un stakeholder con dedicación limitada, afrontar el proceso con una dinámica de refinamiento. 

En este proceso, el asesor presenta su visión sobre los requerimientos funcionales y atributos cualitativos de la arquitectura para que el representante de la organización confirme su apreciación o plantee correcciones. Este proceso, suele ofrecer mejores resultados que la alternativa por la que el propio stakeholder los elabora. 

No obstante, el analista no puede limitarse a recabar la opinión de los representantes de la organización. En el diagnóstico experto es fundamental que el asesor contraste esta información con el análisis de los artefactos reales del sistema: código funcional y test, registro de incidencias, plataforma de despliegue, operaciones en producción, métricas, etc. Ésta es la auténtica verdad sobre el sistema, no la idealizada por sus creadores. 

El código no miente. Ahí está la verdad sobre la arquitectura

 En este contexto es especialmente importante la figura del promotor del diagnóstico, quien debe plantear un objetivo claro para el análisis,  con preguntas/dudas específicas a las que dar respuesta. Además, debe disponer de suficiente nivel ejecutivo en la organización para garantizar la disponibilidad de los expertos y el acceso a los recursos del sistema a evaluar. 

Por su parte, el analista debe disponer de una sólida experiencia en la tecnología y el negocio de la organización para poder llevar a cabo su labor de forma, principalmente, autónoma. La confianza del promotor en su nivel de conocimientos es clave para afrontar el proceso y que las conclusiones sean asumidas y extendidas a toda la organización.

Iteraciones y Alcance:

El proceso se basa en una o varias iteraciones en las que el asesor genera y refina con los expertos asignado. Su visión del contexto del negocio, la vista de la arquitectura, las decisiones arquitectónicas claves para el negocio y la realidad de su implementación. Todo ello, lleva a una enumeración de riesgos y fortalezas que constituirán la base del informe final para el patrocinador del estudio. 

La ausencia de una documentación mínima razonable, previa al inicio de los trabajos, puede desviar el foco. Hacer que la dedicación se desvíe hacia su elaboración, limitando las conclusiones ejecutivas del trabajo. En un primer contacto, debemos evaluar esta situación y revisar el alcance del proyecto con el promotor. Debemos asegurar que podemos afrontar el objetivo principal o bien, deben realizarse labores previas de preparación. 

El diagnóstico basado en conocimiento experto tiene un alcance más limitado que el elaborado con la técnica de escenarios de uso. Debido a la falta de contexto cualificado sobre el negocio y el sistema, las conclusiones están basadas en el juicio del asesor. Por ello, el foco debe reducirse a los grandes aspectos estructurales de la arquitectura de software. 

Así, el informe final puede resultar más superficial que los generados mediante trabajo colaborativo. No obstante, en contextos en los que se desea obtener un referencia independiente, cualificada y rápida para tomar una decisión ejecutiva, esta aproximación puede resultar la más efectiva. 

Conclusiones:

En esta ocasión, te he presentado el diagnóstico de Arquitectura de Software basado en experto externo, como contraste a la metodología basadas en Escenarios de Uso, ventajas e inconvenientes. Hemos visto el papel que juega el patrocinador del diagnóstico y la calificación del experto. También, hemos tratado la importancia de contrastar la visión de los desarrolladores con la realidad reflejada en el código. 

En mi próxima entrada sobre Arquitectura de Software, quiero analizar algunas herramientas para modelar las distintas visiones de la arquitectura. Como dice mi compañera Laura Jiménez, “los desarrolladores estáis todo el día dibujando cajitas”. Bueno, pues veremos esas “cajitas”. 

Mantente al día a través de nuestra Newsletter Susbribirse