Metrópolis y Gobierno de SOA - Willy .Net

Relación de la estrategia de
producto con la arquitectura
Importancia. ¿Cuán alta es la prioridad de las expectativas de
valor que se ven afectadas por el desafío? Si estas expectativas
de valor son específicas de algunos contextos, ¿cuál es la prioridad
relativa de estos contextos?
Magnitud. ¿Cuán grande es el impacto en las expectativas de
valor causado por factores restrictivos?
Consecuencia. ¿Cuántas opciones realistas parece haber?
¿Estas opciones tienen diferencias importantes en dificultad o
efectividad?
Aislamiento. ¿Cuán aislado está el impacto de las opciones más
realistas? Cuanto más divulgado esté el impacto, más peso tendrá
el factor.
Una vez priorizados los desafíos de arquitectura, se formulan
los enfoques para los de mayor prioridad. Mientras que las técnicas
como estilos y patrones de arquitectura [3] [8] pueden ayudar,
esta es un área donde la vasta experiencia en temas de problema-solución
es invaluable. Los enfoques eficaces a desafíos
importantes son resultado de un trabajo habilidoso, profundo, de
esfuerzo y meticuloso. Esto es verdad, independientemente de si
el problema tiene que ver con cirugía, gerencia ejecutiva o arquitectura
de software.
Al tratar cada desafío, su enfoque delimitará las soluciones
para otros desafíos, y a veces creará nuevos. Si las prioridades
de desafío de arquitectura son correctas, la mayoría de las limitaciones
posteriores serán adecuadas. Sin embargo, en algunos
casos el enfoque a un desafío de alta prioridad impactará negativamente
en varios desafíos de prioridad levemente menor. La
prioridad combinada de desafíos impactados compensará al desafío
de mayor prioridad. En este caso, es aconsejable respaldar y
formular un enfoque diferente al desafío original.
Levar anclas
Finalmente, una vez formulados los enfoques al conjunto de
desafíos de alta prioridad, se podrá expresar la estrategia de
arquitectura. El arquitecto analiza el conjunto de enfoques y considera
el conjunto de principios de guía en las siguientes áreas:
Organización. ¿Cómo se organiza el sistema en subsistemas y
componentes? ¿Cuál es la composición y responsabilidades de
cada uno? ¿Cómo se puede configurar el sistema en una red?
¿Qué tipos de usuarios y sistemas externos existen? ¿Dónde se
ubican y cómo se conectan?
Operación. ¿Cómo interactúan los componentes? ¿En qué casos
es sincrónica la comunicación? ¿En qué casos es asincrónica?
¿Cómo se coordinan las acciones de los componentes? ¿Cuándo
es aceptable configurar un componente o realizarle un diagnóstico?
¿Cómo se detectan errores, cómo se diagnostican y corrigen?
Variabilidad. ¿Cuáles funciones importantes del sistema se permiten
para variar de un entorno de configuración a otro? ¿Qué
opciones se soportan para cada función, y cuándo se puede
optar (por ejemplo, compilar, enlace, instalación, puesta en marcha,
o tiempo de funcionamiento)? ¿Qué dependencias existen
entre puntos de variación?
Evolución. ¿Cómo está diseñado el sistema para soportar el
cambio mientras mantiene su estabilidad? ¿Qué tipos específicos
de cambio importante se han anticipado, y cuales son las maneras
preferibles de tratarlos?
En resumen, la estrategia de arquitectura es el timón y la quilla
del barco, brindando dirección y estabilidad. Se espera que sea
una declaración breve y de alto nivel de la dirección que todos
los interesados deberán entender, y deberá ser relativamente
estable durante la vida útil del sistema.
La Figura 3 muestra cómo los Modelos de Valor y Estrategia de
38
Arquitectura se relacionan con los métodos de cascada y espiral.
Los Modelos de Valor y Estrategia de Arquitectura operan al primer
punto y a un mayor nivel que estos métodos. Cuando se
estudian los modelos de valor y se formula la estrategia de arquitectura,
brindan una gran base para especificar requerimientos y
definir una arquitectura más detallada. El modelo de valor conduce
los requerimientos, e influye en la definición de la arquitectura
al brindar información para realizar intercambios. La estrategia
de arquitectura brinda una más detallada definición de la arquitectura,
y un conjunto de requerimientos derivados necesarios
para superar los obstáculos conocidos.
Una analogía adecuada es ver a la estrategia de arquitectura
como planificación estratégica, y los modelos de valor como análisis
de mercado. En esta perspectiva, los requerimientos son
objetivos y políticas corporativas. La definición de arquitectura es
la organización comercial y el plan operativo, y los casos de uso
son equivalentes a procesos comerciales.
Pocas empresas establecen objetivos corporativos, estructura
organizativa, planes operativos, y procesos comerciales sin primero
tener una idea clara de su misión, mercados, competidores,
recursos y estrategia. Incluso menos empresas efectivas hacen
esto.
La Figura 4 muestra cómo los Modelos de Valor y Estrategia
de Arquitectura se relacionan con métodos ágiles.
PROGRAMACIÓN EXTREMA y SCRUM hacen concesiones
para una definición de arquitectura. SCRUM lo hace en forma
expresa, esperando que se defina la arquitectura en la primera
repetición de 4-5 semanas.
PROGRAMACIÓN EXTREMA lo hace en forma implícita. Uno
de los 12 principios clave de PROGRAMACIÓN EXTREMA se
llama System Metaphor (Metáfora de Sistema).
Este principio no se usa tan frecuentemente ni se entiende
tan bien como sus parientes famosos: Small Releases, Pair
Programming, Test Driven Development. En los comienzos de
PROGRAMACIÓN EXTREMA, el equipo que trabajaba en el
Chrysler Payroll System grande y complejo necesitaba una
buena forma de describir la gestión de flujo de trabajo a las
personas a cargo del desarrollo Chrysler.
Figura 6. Integración de Arquitectura sobre Creación de Valor
con Métodos Ágiles.
• Journal 5 • www.microsoft.com /architecture