Funciones de Aptitud (Fitness Functions)

Cuando creamos una arquitectura, lo hacemos con un propósito, y muchas (o todas) las veces pensamos que la arquitectura que estamos ideando antes de iniciar el desarrollo es la que va a cumplir el propósito, que puede ser asegurarse del rendimiento, auditabilidad, escalabilidad, mantenibilidad, etc. (los llamados requerimientos no funciones)

El hecho es que muy pocas veces (o nunca) en realidad verificamos que el propósito de la arquitectura ideada se esté cumpliendo. Así mismo cuando nos encontramos desarrollando las aplicaciones y evolucionando la arquitectura (todas las arquitecturas evolucionan), no sabemos en realidad si el desarrollo de una solución está “respetando” o preservando la arquitectura o los principios de arquitectura, y nos damos cuenta cuando ya es muy tarde.

Parte de los conceptos de una arquitectura evolutiva son las funciones de aptitud (fitness functions) que en esencia, tratan de hacer verificables las características principales de arquitectura que guían una solución de manera constante e incremental.

Es así que cuando estamos diseñando una arquitectura nos preocupamos de que la solución sea escalable o mantenible (bonitas palabras), pero que significa que sea escalable, que tenga “buen” rendimiento o que sea mantenible, justamente es aquí donde entran las fitness functions, buscando hacer más objetivas estas características mediante mecanismos de verificación constantes.

Por ejemplo: si decimos que una arquitectura busca que la solución tenga “buen” rendimiento, entonces necesitamos crear una(s) función de aptitud que defina que significa “buen rendimiento”, creando un mecanismo de control que verifique en cada nueva versión de la aplicación que las operaciones o transacciones más importantes no tomen más de medio segundo en ser ejecutadas; esta función de aptitud puede ser ejecutada en el proceso de integración o entrega continua antes de liberar un nueva versión a producción.

Si buscamos que sea mantenible y entendemos que una de los aspectos para que la solución sea mantenible es crear una arquitectura en capas dónde buscamos que solo existan dependencias en una dirección (figura 1), entonces debemos crear una función de aptitud que verifique las dependencias entre paquetes sean solamente las que hemos definido (figura 2).

Captura de pantalla 2018-02-27 a la(s) 15.41.53

figura 1 –  Arquitectura en Capas

Captura de pantalla 2018-02-27 a la(s) 15.57.12

figura 2 – Función de aptitud que analiza dependencia entre capas

Dado que cuando estamos construyendo arquitecturas evolutivas buscamos soportar un cambio incremental y guiado a lo largo de múltiples dimensiones, es importante saber hacia donde estamos guiando el cambio y es aquí donde las funciones de aptitud juegan un papel principal, ya que son controles que nos permiten identificar si las características principales de arquitectura se están preservando al mismo tiempo que la arquitectura evoluciona, o en otras palabras: Las funciones de aptitud nos permiten identificar si la arquitectura está evolucionando hacia donde queremos que evolucione.


Anticorruption Layers

That panic moment when the decision of changing the application X which our systems depend on is made.

When we build systems, most of the times those systems depend on or need external or third party applications. The moment when one of these external applications need to be changed or an updated is needed is when the problems don’t stop.

The biggest problem most of the time is not the new application or the new version doesn’t have the same features than the older one (in fact they tend to have cooler features or more of them), the problem is that our system is invaded with dependencies of the external application; the problem is that our domain is corrupted by an external domain.

Screen Shot 2016-06-29 at 3.59.57 PM

For instance, we have a system (green boxes) that manages, besides other features, files and documents, so it has been decided to use a file repository like Alfresco or FileNet (yellow box). Alfresco (or any other tool) provides libraries or API’s that are used by our system to make the integration. In this point our system/domain has an external dependency along multiple components, and that’s why we say our domain is corrupted because the external domain is allocated everywhere. The moment we will decide to switch the the yellow box by a red one we will need to seek every single dependency in our domain and make the change for the new one.

We can avoid this problem introducing an Anticorruption Layer (a term coined in the book DDD) that allows us to isolate the external or third-party dependencies, whether these are tools, systems, libraries, different domains, etc..

Screen Shot 2016-06-29 at 4.14.17 PM

The idea is to build a layer between our domain and the external dependency. This layer is the responsible to do the transformations in both ways; it means, transform the components of our domain into components that the external tool can understands, and vice versa. This way we can isolate the dependency in one single place, so our domain (green boxes) is focus on solving the problem, and any change in the external dependency won’t affect substantially our system behavior.

Conway’s Law in Software Architecture

In 1967 M. Conway enunciated a phrase at the end of his publication How do committees invent?. This phrase was made popular by Fred Brooks on his book The Mythical Man-Month with the name of Conway’s Law.

“… organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” M. Conway – 1967.

Although this is not a scientific law, it is a valid proposition for many environments, and we can perceive it in our workplace or in other companies that develop software.

The organizational structure of a company will reflect in the systems produced by this organization; if there is an invoicing department, there will be an invoicing system for sure, if there is a notifications area, a system called NOTSYS (with such a cool name) will exist, the finance department will have a FINSYS, and so on, and the systems will integrate with each other in the same way the organization departments communicate.

This law also plays a role at the construction time of every of these systems, because the architecture of these products will reflect the communication structure of the teams that are part of that process.

Due to this fact, if the technology department is organized around technical capabilities, with a work group focused on the user interface, other group to the database, other to the infrastructure, other to the process management, another to the implementation of business logic on the server side (figure 1) the architecture of the resulting systems (figure 2) will be very similar to these communication structures.

Technical organization of teams
figure 1 – Technical organization of teams
Architecture driven by technical capabilities
figure 2 – Architecture driven by technical capabilities

Systems are dynamic, there will always be changes, and these are often caused by changes to the business definitions; if an organizational structure is driven by technical capabilities, every change in the business definitions will require work from all the technical areas of the organization, budget and time assignment, etc. This is one of the reasons why some organizations try to group requirements to “optimize” time and resources, lengthening the development process until all the necessary work can be “justified”, which leads to the business insatisfaction towards the technology department.

In the other hand, we can find organizations that favour multidisciplinary or cross-functional teams formed by different roles and guided by the business capabilities (figure 3) where changes produced by new business definitions are executed from begin to end by just one team avoiding processes overhead, producing different, and often more distributed, architectures (figure 4) with greater evolution capacity.

Organization of teams driven by business capabilities
figure 3 – Organization of teams driven by business capabilities
Arquitectura guiada por el negocio
figure 4 – Business Driven Architecture

In the end, software is the product of an intellectual and collaborative process that will reflect the ideas of the people involved in this process and the communication structures between teams, as we have seen. Due to this, we should take in account this law at the time when we are structuring teams depending on what we want to achieve.

Translated from the original in Spanish. Thanks for the translation Carlos Oquendo @andres19_05

Business Value

We have talked a lot about that our software should add value to the business, actually is one of the principles in agile methodologies, and I think is a good principle because our software should be part of the effort to achieve something bigger.

But What does business value mean? Is it possible to measure it? if so, What is the importance of this?

What is it?

We can say business value is a covered need or satisfied expectation of the business, when I say business, I mean stakeholders.

So this concept will depend of the stakeholders, and their needs, the more stakeholders, the more the perspectives of what the business value is.

It will depend on the the business area you are working on: for instance, if your goal is replacing a legacy licensed system maybe the business value will be determined in terms of the money invested vs the money you used to pay for the licenses; if you are talking about a business area that prevents doing illegal things, the business value could be  accomplishment of regulations; if you are involved in automating processes in government institutions the business value could be  satisfaction of the citizens when they use the systems or accomplishing the policies or regulations; even in the same business area, people could have more than one perspective of what the business value means.

Is it possible to measure it?

Yes it is, however is either complex or subjective, and here is the challenge, make the subjective points of view into tangible explicit concepts and deal with complexity to make it visible and understandable.

Before to start measuring something or at least trying to measure, we need to define it, since this definition is complex. We can not create a single concept, we need to define a model of the business value.

Defining the business value model.

A model is an abstraction that lets us represent something in an understandable way.

In order to simplify the reality, we make models to convey our understanding of things, but not only to understand, models always have a purpose and in most cases this purpose is to make decisions.

Identify the relevant stakeholders (decision makers):

In order to know what a covered need or a satisfied expectation is, we need to identify first who are the people who can define this.

There are a lot of interested people involved in an application construction, however it doesn’t mean that all of them are relevant for the project, it will depend on the project we are working on, not because someone uses the system it means that is our relevant stakeholder, we should clarify who are them, because only they can certainly know what are the goals that are required to achieve.

Identify goals:

Once we have identified the relevant stakeholders we can know which are the goals of the project, these goals can’t be subjective, should be described without ambiguities, and should be defined in a way that we can measure them.

Define the values:

It is important to know what are the values which will drive the project if it is the profit, policy or regulation accomplishments, the internal/external user satisfaction, the customer satisfaction, etc. we will need this in order to know if the work we are doing will deliver value or not.

Prioritize the values:

Defining which value is more important than other would let us decide the work we should start in case we have more than one important thing to solve at the “same time”

Identify metrics:

We need to agree on a way to measure the achievement of the goals through the values, choosing tangible metrics, and defining a way to collect those metrics; this way we will know how much value we are adding to the business and if the effort done is enough, if it is effective, this will let us change directions and make decisions..

For example the goal is pay less for the functionalities that a licensed application has, so we can identify the profit as the value and the metric is the money we are going to spend building a new system vs the money we used to paid for licenses.

Business value is not just a metric, is a model that will let us to identify what are our priorities, taking decisions based on the information, knowing what are the goals and the drivers.

Is it important to know what is our business value model?

Once the business value model is defined we have a way a to prioritize the requirements, we can know which should be the first system or functionality we should start on.

Otherwise, how do we certainly know if the effort we are doing is adding any value to the business? How the business could make decisions to continue or stop the project, or adding/reducing resources or members in the team, etc.?

When do we need to define the business value model?

When the project starts, to not work in the air without a north, to avoid doing effort that the company doesn’t need, making of our work a meaningless thing, to know what are our priorities and with which requirements we need to start.

Why is it important to measure the business value?

We need to know the business value we are adding and compare with the effort that it costs to produce it, with this relationship we could now if our work is efficient, if you should keep doing effort in certain aspects.

Look up the trends

It is important have metrics in regular bases, as in software we should study the story of numbers rather than the number itself (at least when the value is not determined in terms of money), if we look the trends we can certainly know when the relationship value/cost is decreasing. E.g. The business value is in terms of customer satisfaction (we are assuming that we have a way to measure it) we can have metrics about the relationship business value/cost every iteration, and lets say that in 10 iterations the value of the relationship oscillates between 35-40, suddenly in iterations 11, 12, and 13 the value begun to decrease to 25, 20, 15, so we can say that our effort is inefficient and we have to make some decisions.

Do we need to estimate the business value in our story cards?

I think is better ask ourselves how to identify stories that deliver business values, since we have a model with prioritized values the stories we create should be aligned with that model.

Trabajando en Squads

“Divide y Vencerás”

Trabajar en un equipo grande implica desafíos, más aún cuando dicho equipo es distribuido, desafíos en el hecho de conservar prácticas ágiles y que estas aporten valor y no sean ejecutadas solamente porque así lo dice el manual; parte importante de ser un equipo ágil, es no solo ser reactivos a situaciones inesperadas sino también es estar inmiscuido en un proceso de mejora continua, en el que se puede evidenciar escenarios, que aunque no sean problemáticos a simple vista y formen parte de la rutina de trabajo, no son los más adecuados para ciertas condiciones.


Evidenciamos que en un equipo de alrededor 20 personas, en el que se trata de cubrir las necesidades de varias aristas del negocio, existen aspectos que no favorecen el evolucionar dentro de un proceso de mejora continua, por lo que luego de un tiempo y hacer hincapié en las ideas propuestas, se decidió dividir al equipo en grupos más pequeños llamados squads.

Porqué hacerlo

  • El trabajar en un grupo tan grande dificulta la colaboración y comunicación entre los miembros, las ideas de mejora se pueden desvanecer, o tardar demasiado en probarlas, llegar a consensos no es lo más fácil y rápido.
  • Al tener varias aristas del negocio, se comienzan a formar grupos que no siempre siguen una línea clara.
  • La coordinación se centraliza y no da mucho campo de acción ni espacio a la auto organización del equipo.
  • Cuando tu equipo es grande y tienes diferentes perspectivas de negocio, es fácil perder el panorama general y empezar a concentrarse en los detalles perdiendo de vista objetivos por parte del negocio.
  • “Si funciona no lo toques”. Así como en el código, podemos evidenciar este fenómeno también en el proceso; si las cosas funcionan de cierta manera, ¿no existe la necesidad de cambiarlo? no es verdad; siempre puede ser mejor. El proceso en  el que veníamos trabajando ya llevaba así por largo tiempo y prácticas que en un inicio tenían mucho sentido y agregaban valor, después de un tiempo no.
  • Prácticas como el stand up diario  pueden carecer de significado, al ser un equipo grande donde ciertas personas están enfocadas en un tema y otras en otro, muchas veces los detalles diarios carecen de importancia para los demás miembros.

Como lo implementamos

Formar los equipos

Se formaron tres equipos con un promedio de 6 integrantes, buscando equilibrar la carga entre miembros del cliente y consultores; guiados por líneas del negocio en las cuales nos podamos enfocar el menos en el mediano plazo.

Objetivos Claros

Cada squad debe tener una meta clara que no sea a muy corto plazo; es importante trabajar juntos en un objetivo en común y que todos los miembros estén conscientes a todo momento de lo que se busca alcanzar.

squadsAnalistas del negocio

Si estamos buscando agregar valor al negocio, es imprescindible contar con al menos un experto en cada squad que pueda dar directrices claras de lo que se está esperando alcanzar; al tener tres analistas en el equipo, lo primero que se hizo fue que cada uno sea parte de un squad, sin embargo hemos evidenciado que ellos pueden participar activamente en más de un squad durante un mismo periodo de tiempo.

Kick off de la meta planteada

Antes de iniciar la ejecución y desarrollo, existe una sesión de análisis con todos los miembros del squad dónde el analista de negocio explica claramente que es lo que se quiere lograr y para qué; de esta forma todos están claros antes de dar inicio.

Squad Amigos

Al iniciar con una tarjeta lo que hacíamos anteriormente es hacer una sesión denominada 3 amigos, donde intervenía el analista de negocio, el desarrollador y el tester; al dividir al equipo en squads, viendo que somos relativamente pocos en cada uno, decidimos probar haciendo está sesión entre todos los miembros en lugar de solo 3. Esto fue fruto de la auto organización de un squad que realizó la prueba y luego fue adoptada por los demás.


Se busca que que la etapa de QA se la haga dentro del mismo squad, sin embargo hemos evidenciado que ciertos cambios que son de interés y conocimiento de todo el equipo, pueden ser revisados por otros squads.


  • Internos

Al finalizar cada día se realiza un standup entre los miembros de los squads, esté es el standup tradicional, donde cada miembro o pair habla de lo que ha hecho, lo que piensa hacer, los problemas que ha tenido, etc. Los standups son agendados a diferentes horas al final del día ya que existen personas como los BA´s que pueden estar en más de un squad.

  • Externos

Al inicio de cada día todo el equipo de trabajo se reúne y una persona de cada squad informa de manera general como va el squad en su búsqueda de alcanzar la meta, no comparte detalles, identifica si hay algo relevante que compartir al grupo como problemas o soluciones transversales a todo el equipo, esto ha causado que en lugar de sesiones de 20 a 30 minutos se reduzca a 5 o 10 como máximo.

Rotación y Pairing

  • Interno

El haber dividido en squads nos ha posibilitado ejecutar prácticas como pairing con el cliente más a menudo de lo que se hacía antes; es importante mantener la rotación entre los miembros del squad.

  • Entre squads

Hemos iniciado la rotación entre squads: luego de terminar la meta establecida un integrante de un squad puede ir a otro sin debilitarlo.


  • Internas

Realizamos retrospectivas entre los miembros del squad donde interviene también la persona que funge como Iteration Manager, que se convierte en un veedor del proceso en todos los squads y es quien puede generar un feedback mucho más rápido acerca de lo que ha funcionado o no en otros squads.

  • Externas

El Iteration Manager facilita la sesión cada fin de periodo, donde expone estadísticas e información relevante a todo el equipo de trabajo, es este el espacio donde se puede también discutir temas transversales, comunes y donde se puede compartir las conclusiones de la gestión de cada squad.


El paso final de la gestión de entrega a producción sigue siendo centralizada, con resultados positivos.

Conclusiones y Ventajas:

  • Independencia en la organización: Equipos auto organizados con libertad de acción.
  • Llegar a acuerdos es más fácil y rápido
  • Retroalimentación más eficiente y rápida
  • Podemos probar prácticas en solo un squad para ver resultados y poder extrapolarlos al resto si funcionan o desecharlas sin causar demasiado impacto en el equipo.

Hemos visto luego de casi cinco meses de trabajar en squads, que los resultados son positivos, y perfectibles sin lugar a dudas, lo importante está en aprender de los errores y potenciar los aciertos, ya que esto no termina, es un camino de diario aprender y mejorar.