archivo

Archivo de la etiqueta: arquitectura del sistema de información

Una máxima en el desarrollo de software debe ser la búsqueda de la solución más simple que satisfaga las expectativas del usuario y con la menor deuda técnica posible.

La búsqueda de esa solución no es fácil ya que implica tener una importante capacidad de abstracción, una experiencia significativa en el desarrollo de sistemas de información para el tipo de cliente y proceso de negocio con el que se está trabajando y tener la capacidad de entender que el producto final no es para que lo utilicemos nosotros, sino para que lo utilicen un conjunto de usuarios y que por tanto, su opinión resulta muy importante y se tiene que materializar en las sucesivas iteraciones del producto a partir del feedback obtenido de los mismos.

Cuando olvidamos este propósito o ponemos por encima de él nuestro espíritu creativo es cuando se corre el riesgo de entrar en este antipatrón en el que el producto gana en complejidad en proporción directa al nivel de ego satisfecho por parte del arquitecto o analista orgánico que definen la arquitectura y el diseño del sistema de información.

En el antipatrón “los arquitectos no programan“, nos encontrábamos con que la organización consideraba que este tipo de perfil era lo suficientemente caro como para que participasen en el proceso de implementación del software, aunque sea como supervisores del trabajo que se está realizando o para resolver diferentes dudas que se encuentren los programadores en aspectos relacionados con el diseño o con la arquitectura.

Otra vertiente de ese antipatrón (que en muchos casos se produce de manera conjunta con la anterior) era el hecho de que los arquitectos prescindan o no den suficiente peso a la opinión de los analistas o programadores que van a tener que realizar el desarrollo.

Este antipatrón es una variante del anterior y se produce en alguna de las siguientes situaciones:

– El arquitecto aplica el antipatrón “arrojar al otro lado del muro“, es decir, ellos hacen lo que entienden que es su trabajo y después que sean los analistas y programadores los que se entiendan con el problema.

– Cuando se decide subcontratar el proceso de construcción, se envían las especificaciones y la arquitectura a utilizar y se vuelve a aplicar el antipatrón “arrojar al otro lado del muro”.

Ante un hecho o un problema lo más normal es que la percepción de cada observador sea diferente. En algunos casos serán solo matices, en otros la divergencia será mucho mayor.

Cuando vamos a desarrollar software lo que hacemos es realizar una abstracción de esa percepción que tenemos del mundo real. Para realizar esa abstracción, además de nuestros sentidos, nuestro conocimiento y nuestra experiencia intervendrán los usuarios y otros componentes del equipo de proyecto.

Mediante la abstracción se busca un consenso entre percepciones diferentes, priorizándose la visión del usuario porque al final serán ellos los que utilicen el sistema de información.

Pero la abstracción no solo se limita a aspectos funcionales, también se centra en aspectos técnicos del propio proceso de desarrollo. La arquitectura de un sistema de información no es más que la definición de un esqueleto que será rellenado con el código fuente de la aplicación o por terceros componentes en los que se delega funcionalidad. En esta abstracción entran en juego otros perfiles, aunque deben tener en cuenta las características del sistema que se abstrae desde el área funcional.

La abstracción puede entrar en todos los detalles que uno quiera pero realmente hasta que no se implementa una solución no se termina de poner forma a sus múltiples esquinas. En ocasiones se acertará a la primera, en la mayoría de los casos serán necesarias varias iteraciones para encontrar una solución que se considere satisfactoria.

La incertidumbre existente en el proceso de desarrollo de software ya de por sí es motivo suficiente para aportar por un enfoque ágil en los proyectos (al menos, en la mayoría de ellos), si a eso le sumamos la propia naturaleza de la transformación de percepciones heterogéneas de la realidad a un conjunto de líneas de código, encontramos otra justificación adicional a dicho enfoque.