Metamorfosis en la Arquitectura de Software

03/Nov/2015 Editorial , 1 Comentario

Hace no mucho participaba en una conversación sobre los nuevos modelos de desarrollo de software. Equipos ágiles y autosuficientes, con capacidad de decisión a la hora de crear y desplegar su software. Y una de las conclusiones a las que se llegó no dejó de despertar en mí cierto asombro, a la vez que perplejidad… “No hay arquitectura, cada uno desarrolla como cree que es correcto”.

¿Por qué hemos llegado a ese punto en el cual no se ve útil un modelo de arquitectura de software para una empresa? ¿Por qué hemos pasado de tener asentados modelos arquitecturales, en ciertas ocasiones megalómanos,  a negar la mayor?

Quizás echando la vista atrás y viendo la metamorfosis en los modelos de arquitectura de software podamos entender mejor este planteamiento. Este análisis nos debería permitir establecer las bases para lo que deben de ser los nuevos modelos arquitecturales.

Arquitectura: Una necesidad imperiosa

La acumulación de software que se empezaba a producir en los años 90 dentro de las grandes empresas derivó en la adopción de Arquitecturas de Software como modelos de organización y optimización de dichos desarrollos.

Eran años en los que nacieron frameworks, como TOGAF, que nos enseñaron a realizar una buena organización de la arquitectura, identificando de forma clara a los arquitectos de negocio, los arquitectos de datos (o información), arquitectos de aplicaciones y arquitectos de tecnología.

Dentro de los éxitos conseguidos por estos modelos arquitecturales iniciales podemos encontrar:

  • Una correcta organización y catalogación de los sistemas del software. Identificando la división entre las aplicaciones así como las relaciones entre ellas.
  • Aplicación de técnicas de modelado de aplicaciones y procesos de negocio. Resaltando la importancia del qué y no del cómo. Aunque ahora suene añejo, metodologías RUP, casos de uso,…
  • Definición de patrones de desarrollo de software y buenas prácticas de codificación. Aplicación de reglas en la búsqueda de una mejora en la calidad del software y la reducción de las deudas técnicas de los aplicativos.
  • Desarrollo de artefactos o frameworks estructurales de apoyo al negocio los cuales reducían las complejidades técnicas a los programadores.

Sobre-arquitecturización: La decadencia

Todo abuso genera un rechazo. El intentar prolongar modelos de software obsoletos basados en una sobre-arquitecturización de artefactos y procesos llevaron a un rechazo frontal por parte de los equipos de desarrollo y, en ciertos casos, de los mandos directivos.

La arquitectura paso de ser un facilitador a ofrecer un modelo de control, plagado de complicaciones e ineficiencias, que no hacía más que lastrar a los desarrollos del software, sobre coste incluido.

Dentro de las malas prácticas de esta época destacamos:

  • Creación de artefactos de desarrollo que recubrían piezas ya existentes (sobre-arquitecturización) y totalmente válidas para uso tal cual estaban.
  • Exceso de modelado de las aplicaciones. Intento de modelar cualquier paso del proceso de desarrollo, por muy insignificante que este fuese. Acompañado del error de aplicar técnicas de modelado UML a cualquier elemento y sobre cualquier tipo de proyecto.
  • No adaptación de los procesos de desarrollo, control y eficiencia a los nuevos tiempos y tecnologías. Anclaje radical en las tecnologías del pasado. Creencia del “esto ya lo hacía el host”.

Transformación Digital: La nueva arquitectura 

La nueva época de transformación digital en la que nos encontramos y el conjunto de cambios tecnológicos que conlleva pide a gritos un nuevo modelo de arquitectura que ayude a las organizaciones en dicho proceso.

Este tiene que ser un punto de inflexión para los modelos de Arquitectura del Software en los cuales se vuelva a demostrar la importancia y los beneficios que conlleva su adopción.

Las responsabilidades de esta nueva arquitectura deben de focalizarse en:

  • Entender y facilitar los nuevos paradigmas y tecnologías. Facilitando la adopción de los mismos por parte de los equipos de desarrollo. Analizar la necesidad de definir nuevos artefactos o frameworks de desarrollo.
  • Ser sponsor y valedor de los desarrollos de software basados en metodologías agile. Adoptar dicha metodología como base de la propia Arquitectura.
  • Redefinir los conceptos de modelado de aplicaciones con un enfoque basado en el Dato.
  • Ayudar a transformar el perfil del desarrollador, adecuándolo a las acuciantes necesidades tecnológicas actuales.

Conclusiones

No nos dejemos llevar por los errores del pasado, aprendamos de ellos y analicemos como debe de ser el nuevo modelo de arquitectura de software.

Adaptemos sus roles y mecanismos para poder utilizar a la arquitectura como punta de lanza en el nuevo modelo de transformación digital de las empresas.

Publicado en LinkedIn como Metamorfosis en la Arquitectura de Software.

Un comentario en “Metamorfosis en la Arquitectura de Software”

Víctor Cuervo

Humberto

realmente me sorprendio que ya existia ese concepto. Lo cual conlleva a poder tomar el concepto filosofico y transformarlo a la era del nacimiento de software como campo de arroz.
Gracias por tener la oportunidad de compartir este material

¿Algo que nos quieras comentar?

Déjanos tu comentario, no te preocupes que tu email no será publicado

*