Arquitectura de Software Empresarial & Servicios Financieros

La mayoría de las empresas hoy en día no poseen una arquitectura formal (Gartner, 2003). La solución no es otra super inversión que provoque un Big-Bang en la organización. Si en un proyecto no se ha definido una arquitectura de sistema confiable, flexible y escalable, simplemente éste no debe proceder.

La arquitectura juega un papel fundamental al permitir que una organización cumpla con sus objetivos de negocio. Arquitectura tiene un precio (el costo de su desarrollo, cuidado), pero vale la pena por sí mismo generosamente al permitir la organización para lograr sus los objetivos con el sistema y ampliar las capacidades del software. La arquitectura es un activo que tiene un valor tangible a la organización de desarrollo más allá del proyecto para el cual fue creado. La arquitectura estrictamente desde un punto de vista de la ingeniería de software aporta tanto a proyecto de desarrollo, además de que el valor devuelto a la empresa.

La arquitectura de software en década del 90' surgió como un subcampo de la ingeniería del software , cuando se hizo ampliamente reconocida la idea de que conseguir la arquitectura correcta era un elemento clave para la creación de un sistema de software que cumpliera con los requerimientos. Tras esto se siguió una serie vertiginosa de las propuestas de anotaciones, herramientas, técnicas y procesos para apoyar el diseño arquitectónico y de integrarlo con las prácticas de desarrollo de software existentes. Y, sin embargo, a pesar de la existencia de este cuerpo de conocimiento, en la arquitectura de software existen aún muchos casos en los que no se sigue una práctica estandarizada.

Parte de la razón de esto ha sido una especie de polarización de opiniones sobre el papel que la arquitectura debe jugar. Por un lado es una escuela de pensamiento que defiende la arquitectura centrada en el diseño, en la que la arquitectura juega un crucial y esencial papel durante el proceso de desarrollo de software. La gente en este campo han tendido arquitectura para centrarse en los diseños arquitectónicos detallados y completos y bien definidos hitos y normas explícitas para la documentación de la arquitectura. En el otro lado es una escuela de pensamiento que menos énfasis arquitectura, con el argumento de que surjan naturalmente, como un subproducto de un buen diseño.

Es obvio que para la clase de sistema. La gente en este campo han tendido a centrarse en la minimización de diseño de la arquitectura como una actividad separada de la aplicación, y en la reducción o la eliminación de documentación arquitectónica.

Claramente, ninguno de estos campos tiene derecho para todos los sistemas. De hecho, la pregunta que uno debe plantearse es: "¿Cuánto diseño arquitectónico se requiere para desarrollar un sistema dado? "

En el libro, George Fairbanks se propone una respuesta: "Sólo Arquitectura suficiente." En un primer momento a esto podría ser: "Bueno, duh!", Porque ¿quién querría demasiado o muy poco. Como tal, proporciona una manera refrescante y no dogmático de enfoque de software arquitectura - con un enorme valor práctico.

Fairbanks señala que el criterio básico para determinar la cantidad de la arquitectura es suficiente la reducción del riesgo. Donde hay poco riesgo en un diseño, la arquitectura poco es necesario. Pero cuando dura problemas de diseño del sistema surgen, la arquitectura es una herramienta con la un enorme potencial. En concreto, se centra en la reducción de riesgos de ingeniería se alinea los beneficios con los costos, asegurando que el diseño arquitectónico se utiliza en situaciones donde se requiera cumplir con ciertas expectativas.

Naturalmente, hay un montón de cuestiones secundarias para responder. ¿Qué riesgos son los mejores dirigida a la arquitectura de software? ¿Cómo se aplican los principios de diseño arquitectónico para resolver un problema de diseño? ¿Qué escribir acerca de su arquitectura compromisos para que los demás saben lo que son? ¿Cómo se puede ayudar a asegurar que compromisos arquitectónicos son respetados por los ejecutores de abajo?

REFERENCIAS:

Enterprise Software Architecture & Financial Services Industry – Future Trends, Challenges & Frameworks - MIT [Ahmad Shuja, 2003]
Software Architecture in Practice 2nd Edition - The SEI Series in Software Engineering
Just Enough Software Architecture - [Fairbanks, 2010]