Metrópolis y Gobierno de SOA - Willy .Net

Gobierno de SOA
Figura 5. Estratificación de los modelos
El punto a considerar acerca de esta evolución es que enfrenta
la oferta con la necesidad de administrar la complejidad creciente
(y la concurrencia) de la forma en que la cadena de valor se relaciona
al cliente. De ahí la importancia competitiva de SOA.
En la primera simetría, la empresa sólo necesita un modelo, ya
que la demanda puede deducirse de la oferta (o eso parece hasta
el momento!). Cuando se rompe esta simetría, se necesitan dos
modelos: uno para administrar la tecnología, y el otro para administrar
la empresa. ¿Cuántas veces un inversor de capital de riesgo
le ha enseñado esto a un novato en los negocios?
Si se realiza el potencial completo de una propuesta empresarial,
también debe romperse la segunda simetría (esto es algo
que toda persona que posee un Master en Administración de
Empresas debe aprender). Ahora, existen tres modelos: uno para
administrar la tecnología, uno para administrar la empresa, y uno
para administrar la solución de la empresa. Por lo tanto, en el
ejemplo del ferrocarril en el Cuadro 6, es necesario separar la
forma en la que se brinda el servicio debido a que no es posible
obtener niveles del servicio de salida para las compañías operativas
de ferrocarriles simplemente desde los requerimientos del
servicio de entrada de la infraestructura de los ferrocarriles (es
decir, al menos que se esté preparado para ofrecer el más alto
nivel de calidad bajo todos los conceptos).
¿Pero qué efecto surge al romper la tercera simetría? Lo que
CRM nos dice es que la "solución del mercado" es también una
relación con el cliente. Pero al romper la tercera simetría debemos
aprender que cada cliente incorpora la solución en un contexto
de uso que es diferente. Por lo tanto, en el cuidado de la
salud, esto no es más una cuestión de brindar determinados tratamientos
con la mejor relación costo-beneficio, sino también
brindar el tratamiento adecuado, en el momento adecuado dentro
del contexto de una condición de paciente que evoluciona -
como la tercera edad, por ejemplo!
De esta forma, en el caso farmacéutico, no se puede obtener el
conocimiento de la salida (lo que GPs y los farmacéuticos necesitan
saber respecto de la condición del paciente) desde el conocimiento
del lado de la entrada. Se necesitan al menos dos modelos
ya que no se pueden deducir los efectos del tratamiento simplemente
desde el conocimiento de las interacciones entre la
prescripción y la situación tal como se la presenta cuando se
prescribe -requiere un modelo de los efectos dinámicos de la
18
prescripción dentro de su contexto de uso.
Entonces, en general, romper las simetrías requiere de la separación
de seis diferentes niveles de modelos (ver Figura 5). A
pesar de esto, cada uno de los estratos puede contener diferentes
niveles dentro de el, la agilidad de la infraestructura dependerá
de la cantidad de variabilidad que permitan en la geometría de
cómo pueden componerse.
¿Qué es entonces lo que todo esto requiere del "arquitecto IT" a
favor de estas nuevas formas de dinámica. Nuestro argumento
más importante es que no existe un único nivel de granularidad.
Existe un dilema de oferta versus demanda al cual es necesario
que se remita un método orgánico (Véase Alexander) en el que
los niveles de estratificación en los cuales se realiza un cambio
deben siempre también remitirse a su impacto sobre los niveles
superiores e inferiores. Como resultado, se debe realizar un intercambio
entre dos tipos de presión a un nivel determinado de
estratificación, uno que estandarice y el otro que requiera mayor
diversidad. Esto impone un tipo diferente de demanda sobre la
función para la arquitectura.
Tal vez pensamos que la función de la arquitectura consiste en
emitir ciertos tipos de juicio (estructural) [8]. Vemos a la arquitectura
como algo que surge de un proceso en conjunto, que puede
(pero no debe) involucrar personas llamadas "arquitectos" en su
profesión. Tal vez consideramos a estas personas arquitectos profesionales,
a pesar de que en la ingeniería del software y de los
sistemas no existe un organismo que otorgue este estatus oficial
a la profesión. Estos juicios pertenecen a un régimen de diseño
asimétrico.
Podemos entonces separar los productos y procesos de la actividad
de la arquitectura de las responsabilidades profesionales
de los Arquitectos calificados de forma adecuada. Las propiedades
estructurales de una ciudad dependen del proceso complejo
en conjunto, en el cual los juicios profesionales de los arquitectos
se oponen a un gran número de intereses políticos y comerciales.
Los arquitectos profesionales rara vez dominan el diseño de
las ciudades, a pesar de que a veces ejercen cierta influencia.
Y tal vez observemos una situación similar dentro de IT. A pesar
de que existen numerosas personas en la industria IT que se llaman
a sí mismos "arquitectos", las propiedades estructurales de
los extensos sistemas IT por lo general dependen en gran medida
de las decisiones que se toman en otro lugar. Por ejemplo, el
grado de acoplamiento entre dos módulos puede tener un
impacto importante sobre la cohesión y la flexibilidad estructural
de un gran sistema, pero esto puede estar determinado por elecciones
de desarrollo de un nivel bastante bajo que ni siquiera
son visibles para los arquitectos del software.
En muchas organizaciones, los arquitectos del software pueden
ser desplazados y marginados por coaliciones de desarrolladores
y usuarios. Y en la medida en que las tercerizaciones aumentan,
la posición del arquitecto del software puede aún debilitarse -en
especial en aquellas instancias en las que las especificaciones
contractuales se centralizan en los requerimientos funcionales y
no detallan las propiedades estructurales; y en el caso que existan
mecanismos insuficientes para que los arquitectos verifiquen
las propiedades estructurales del software que se brinda. (Por
ejemplo, acoplamiento oculto que compromete la flexibilidad
prevista de un artefacto de software.)
Por lo tanto, el desafío para los arquitectos del software es permanecer
relacionados con el mundo SOA, un mundo de producción
y servicios distribuidos, prestando atención a los problemas
estructurales verdaderos que surgen en este mundo "en-demanda".
De lo contrario, no podrán contribuir con nada de valor para
el diseño y administración de los sistemas a pedido de los siste
• Journal 5 • www.microsoft.com /architecture