Metrópolis y Gobierno de SOA - Willy .Net

Figura 5. Arquitectura sobre Creación de Valor con Métodos
Tradicionales
Desafíos de Arquitectura
Un desafío de arquitectura es una situación donde uno o más
factores restrictivos dificultan más satisfacer una o más expectativas
de valor. Para decirlo más sencillamente, un desafío de
arquitectura es un obstáculo o barrera que el sistema debe superar
para brindar valor. Esto es clave. Los obstáculos y expectativas
de valor son como el yin y el yang. Si los obstáculos no
están presentes, caen los valores, porque el resultado es fácil y
cualquiera puede lograrlo. El agua embotellada es una excepción
notable a esta regla.
Dentro de cualquier contexto, la identificación de desafíos de
arquitectura implica evaluar:
• ¿Qué factores restrictivos impactan en una o más expectativas
de valor?
• Si se observan impactos, ¿estos hacen que cumplir las expectativas
de valor sea más fácil (impacto positivo) o más difícil
(impacto negativo)?
• ¿Cuánto facilita o dificulta las cosas cada impacto? Es suficiente
en este caso la escala de bajo, medio o alto.
La Figura 3 describe algunos desafíos de arquitectura que ocurren
en un sistema de cumplimiento pre-comercial de gestión de
cartera. Un debate más profundo de los desafíos de arquitectura
y un estudio de situación se podrán encontrar en [4].
Los desafíos de arquitectura deben considerarse dentro de sus
propios contextos. Mientras es posible promediar curvas de utilidad
con contextos, no se puede hacer lo mismo con los impactos
de factores restrictivos sobre expectativas de valor. Por ejemplo,
en caso de un servidor de Internet que brinda páginas a usuarios
en dos contextos. Un contexto accede a información estática,
como documentos de referencia. Desean un tiempo de respuesta
entre 1 y 3 segundos. El otro contexto accede a información muy
dinámica, como puntaje de eventos deportivos en curso. Están
conformes con un tiempo de respuesta del rango entre 3 y 6
segundos.
Ambos contextos están sujetos a limitaciones de CPU, memo-
• Journal 5 • www.microsoft.com /architecture
Relación de la estrategia de
producto con la arquitectura
ria, disco y red. Sin embargo al aumentar los volúmenes de pedido
por un factor de 10 o 100 estos dos contextos se encontrarán
probablemente con obstáculos de escala muy diferentes. En un
caso de contenido dinámico, la sincronización de actualizaciones
y accesos se convierte en factor restrictivo bajo carga pesada.
Para el contenido estático, la carga pesada se puede superar
guardando en la memoria las páginas más leídas.
Existe un punto final que debería mencionarse sobre desafíos
de arquitectura y sistemas de contexto múltiple. En muchos
casos, parecería que un sistema simple es capaz de soportar diferentes
contextos. Sin embargo, los contextos de arquitectura que
surgen de cada contexto son una herramienta muy buena para
evaluar cuán compatibles son estos contextos entre sí. Cuando la
misma arquitectura se dirige a contextos incompatibles el resultado
nunca es que ambos estén satisfechos. O uno sufre a expensas
del otro, o ambos están comprometidos. Un ejemplo de esto
es la herramienta semiconductora que intenta soportar contextos
de producción e investigación con una arquitectura sola. Dados
los diferentes grupos de expectativas de valor (confiabilidad versus
flexibilidad), fuerzas opuestas (fab versus lab), y catalizadores
de cambio (producción versus experimentos) era improbable que
esta unión se pudiera salvar.
Estrategia de Arquitectura
Según lo descripto en anteriores secciones, para formular una
estrategia de arquitectura de un sistema se comienza por:
• Reconocer los contextos de valor adecuados y priorizarlos;
• Definir curvas de utilidad para expectativas de valor y priorizar
estas expectativas en cada contexto.
• Identificar y analizar fuerzas opuestas y catalizadores de cambio
en cada contexto.
• Detectar casos en que los factores restrictivos dificultan cumplir
con las expectativas de valor.
La Figura 2 ilustra este proceso. La lista previa de actividades
nos muestra la casilla de Desafíos de Arquitectura en la mitad del
diagrama. En este punto, trabajamos con una lista de desafíos de
arquitectura que se han reunido de todos los contextos. Cada
uno de estos desafíos representa un impacto de uno o más factores
restrictivos en uno o más expectativas de valor.
”Si la simplicidad fuera el único objetivo
con valor , todavía estaríamos todos caminando
o montando caballos para trasladarlos
de un lado al otro.”
Según muestra el diagrama, antes de empezar a tratar cada
desafío, necesitamos priorizarlos. Las siguientes observaciones
explican porqué:
• Cuanto antes se toma una decisión, es probable que se
puedan delimitar más cantidad de asuntos.
• Cuanto más tarde se toma una decisión, menos opciones
estarán disponibles.
Como resultado, solo tiene sentido reservar las primeras
decisiones de arquitectura como las que rendirán el mayor
valor.
Existen varios criterios a utilizar para priorizar los desafíos
de arquitectura. Recomendamos un equilibrio entre lo
siguiente:
37