► Aprenda la disciplina,

ejerza el arte y
contribuya con sus ideas en
www.ArchitectureJournal.net
Recursos que sirven de base

Estrategias para el Diseño

Llevar el Gobierno
a la Periferia
Uso de Mapas
Conceptuales en
Aplicaciones
Diseño e Implementación
de una Fábrica de
Software
Inteligencia Comercial
Orientada al Servicio

Planificación de
Arquitectura Técnica

Lenguaje de Arquitectura
de Software de Conducta
 Contenidos

Prólogo 1
Por Avindra Sehmi

Llevar el Gobierno a la Periferia 2

Por Philip Boxer y Richard Veryard
La Arquitectura Orientada al Servicio (SOA) ofrece a las empresas una nueva forma de lograr realizar sus
trabajos, pero SOA trae consigo problemas tradicionales de gobierno así como también desafíos. Descubra un
enfoque para las formas asimétricas de gobierno que se centralizan en la manera en la que las empresas
comprenden los riesgos.

Uso de Mapas Conceptuales en Aplicaciones 10

Por Kal Ahmed y Graham Moore
Los mapas conceptuales proporcionan un metamodelo para la representación de los modelos de conocimiento que
están integrados con otros sistemas. Vea cuáles son las áreas actuales y futuras de aplicación de mapas
conceptuales y conozca la forma de acceder a la información de los mapas conceptuales utilizando arquitecturas
de servicios Web.

Diseño e Implementación de una Fábrica de Software 18

Por Mauro Regio y Jack Greenfield
La industria del cuidado de la salud ofrece un entorno representativo para la interoperabilidad entre las
organizaciones. Analice brevemente el diseño e implementación de una fábrica de software que está basada en los
estándares del HL7 (Health Level 7) que también proporciona una visión para admitir la colaboración en las
diferentes industrias.

Inteligencia Comercial Orientada al Servicio 23

Por Sean Gordon, Robert Grigg, Michael Horne y Simon Thurman
La Inteligencia Comercial (BI) y la Orientación al Servicio (SO) son paradigmas arquitectónicos que se han
desarrollado en forma independiente y constituyen la sinergia del marco de la Inteligencia Comercial Orientada al
Servicio (SoBI). Descubra las similaridades y diferencias entre ellas que están niveladas por el marco
arquitectónico SoBI.

Planificación de Arquitectura Técnica 33

Por Waleed Nema
Los directores y el personal operativo conocen el valor de la planificación de la Arquitectura Técnica y sus méritos
para alinear IT con la empresa y los gastos y niveles del servicio de control. Obtenga un punto de vista respecto
de la forma en la que estos orientadores de la empresa pueden impactar al crear un plan táctico para una
arquitectura de infraestructura.

Lenguaje de Arquitectura de Software de Conducta 36

Por Behzad Karim
Un principio para definir la arquitectura es el diseño de estructura de software y la interacción de objetos antes de
la etapa de diseño detallado, y el diseño y aprobación de la arquitectura deben preceder cualquier proyecto de
construcción de software. Aprenda la forma en la que el Lenguaje de Arquitectura de Software de Conducta
unifica las definiciones de la Arquitectura de Software con la Implementación de Software.

►Recursos que sirven de base. www.architecturejournal.net

Fundador y Editor Jefe
Arvindra Sehmi
Microsoft Corporation

Consejo Editorial de Microsoft

Christopher Baldwin
Prólogo
Gianpaolo Carraro
Wilfried Grommen
Simon Guest
Richard Hughes
Neil Hutson
Eugenio Pace
Harry Pierson
Michael Platt
Philip Teale Estimado arquitecto:
Al principio deseaba publicar sólo seis ediciones del The Architecture
Editor Comercial Journal y obtener la evidencia necesaria para ayudar a decidir a Microsoft
Norman Guadagno
si valía la pena o no continuarlo. Los lectores regulares saben lo que ha
Microsoft Corporation
sucedido con The Architecture Journal; ha sido algo maravilloso para
Editor Comercial Asociado todos los que estamos involucrados, incluyendo nuestras súper estrellas –
Marty Collins los autores– ver que el interés y las suscripciones han aumentado de
Microsoft Corporation forma espectacular mes a mes en el mundo entero, tanto para el formato
impreso como para el formato digital. ¡Esto es fantástico!
Diseño, Impresión y Distribución: Ahora es tiempo de que le permitamos al equipo de profesionales de
Publicaciones Técnicas Fawcette
Micirosoft Corporate HQ que se encarguen de esta publicación y que la
Jeff Hadfield, VP de Publicación
Terrence O’Donnell, Editor Gerente
desarrollen más allá de mis sueños iniciales. Como un componente clave
Michael Hollister, VP de Arte y producción del programa de extensión bibliográfica sobre arquitectura de Microsoft,
Karen Koenen, Director de Circulación tiene 100 por ciento de sentido proporcionar mejores recursos a The
Brian Rogers, Director de Arte Architecture Journal en lo que respecta a personas y fondos, lo cual puedo
Kathleen Sweeney Cygnarowicz, manejar con mi equipo desde Europa. Para este fin, es un placer para mi
Gerente de Producción presentarles a Simon Guest, jefe de programa de grupo para el Equipo de
Estratégia de Arquitectura de Microsoft, como el nuevo Editor del The
Architecture Journal. Simon y su equipo poseen la visión y pasión
necesarias para esta publicación, y estoy seguro de que seguirán fieles a
La información contenida en la revista The Best of los cometidos originales del Journal como plataforma independiente para
the Microsoft Arquitecture Journal (“Journal”) se los libres pensadores y profesionales de la arquitectura IT.
brinda sólo con fines informativos. El material
publicado en el Journal no constituye la opinión o En esta edición contamos con una gran cantidad de artículos que van
asesoramiento de Microsoft y no debe basarse en desde el gobierno de SOA, modelado práctico de información utilizando
ningún tipo de material publicado en ella sin antes mapas conceptuales, fábricas de software para protocolos de colaboración
buscar asesoramiento independiente. Microsoft no
provee garantía o representación alguna respecto en la industria del cuidado de la salud, hasta una perspectiva orientada al
a la precisión o aptitud de los fines de cualquier servicio sobre la inteligencia comercial. También publicamos dos artículos
material del Journal y en ningún caso Microsoft cortos sobre la planificación técnica y el modelado de software. Varios de
acepta responsabilidad de ningún tipo, incluyendo
responsabilidad por culpa (excepto por daño contra estos artículos analizan las áreas de mis temas preferidos.
los derechos personales del individuo o Seguiré participando del The Architecture Journal y espero con ansiedad
fallecimiento), por cualquier tipo de daños o que Simon y su equipo desarrollen todo su potencial, y les deseo el mejor
perjuicios o pérdidas (incluyendo, sin limitación,
pérdida del negocio, rédito, ganancias o pérdida de los éxitos en esta tarea.
consiguiente) de cualquier índole o naturaleza que Quisiera agradecer a todos ustedes por el gran apoyo e incentivo que
resultare del uso del presente Journal. El Journal me han mostrado a mí en particular. Para los autores pioneros del The
puede contener imprecisiones técnicas y errores de
tipografía. El Journal se actualizará de vez en Architecture Journal no tengo más que mi profundo agradecimiento y
cuando y podrá otras veces estar desactualizado. respeto. Gracias.
Microsoft no acepta responsabilidad alguna por ¡Mis mejores deseos!
mantener la información de este Journal
actualizada ni por el incumplimiento del hecho.
Este Journal contiene material propuesto y creado
por terceros. Hasta el alcance máximo permitido Arvindra Sehmi
por la ley aplicable Microsoft excluye toda
responsabilidad por cualquier acto ilegal que
surgiera de un error, omisión o imprecisión en este
Journal y Microsoft no se responsabiliza del
material suministrado por terceros.

Todos los derechos del autor, marcas registradas y

cualquier otro tipo de propiedad intelectual del
material contenido en el Journal pertenecen y son
licencia exclusiva de Microsoft Corporation. Queda
totalmente prohibida la copia, reproducción,
transmisión, almacenamiento, adaptación o
modificación de la forma o contenido del presente
Journal sin previo consentimiento por escrito por
parte de Microsoft Corporation y los autores
individuales.

© 2005 Microsoft Corporation. Todos los derechos

reservados.

THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net

 Llevar el gobierno
a la periferia
Por Philip Boxer y Richard Veryard

Síntesis

Descubra los desafíos que enfrentan las formas
asimétricas de gobierno y un enfoque para tratar estos
puntos en particular con especial atención en la forma
en la que la empresa comprende los riesgos que surgen
de la relación con geometrías exógenas, además de los
riesgos más comunes asociados con la gestión de su
geometría endógena.
Existen en la industria de software dos visiones opuestas de
arquitectura orientada al servicio (SOA-Service Orientated
Architecture) las cuales podemos dividir en SOA 1.0 y SOA 2.0
(Ver Tabla 1). Nuestro enfoque para el gobierno se dirige a SOA
2.0. Una de las preguntas centrales que plantea Christopher
Alexander en su trabajo más reciente en cuatro tomos, La
Naturaleza del Orden, es cómo obtener el orden sin imponer una
planificación descendente (central) o por el contrario, cómo
permitir y fomentar una innovación ascendente sin perder el
orden (Ver “Recursos”). Alexander fomenta el concepto de
transformaciones que preservan la estructura y sostiene que
bajo ciertas condiciones, el orden a gran escala puede darse
desde un proceso evolutivo de pequeños pasos de incremento
gradual, siempre que cada paso preserve la estructura de forma
adecuada. No obstante, ¿Cómo (y en base a qué intereses)
podemos definir la estructura que se conserva y a qué nivel?
Es importante destacar que con este concepto de preservación
de la estructura, el liderazgo no realiza el diseño sino que
establece los parámetros en los cuales se puede dar el diseño
ordenado. Esta función es más un rol del gobierno. Para
responder la pregunta es necesario distinguir el gobierno de la
gestión.
Los análisis informales sobre el gobierno (gobierno IT en
general y gobierno SOA en particular) pueden con facilidad
difundirse hasta que parece que cubren todos los aspectos de la
gestión. Por lo tanto, ¿Dónde termina la gestión y dónde
comienza el gobierno?
Si se entiende por gestión lograr realizar las cosas, entonces
podemos comprender de mejor forma el gobierno como
dirección (tal como en un Comité Directivo). En el pasado, era
una práctica muy común para el desarrollo de grandes
proyectos/programas contar con comités directivos –por lo
general un comité para cada proyecto– que gobernaban cosas
como medios, ámbito, dirección y prioridades. El comité directivo
era el punto común de exposición de ideas cuyo responsable era
el jefe de proyecto. Éste debía mantener un equilibrio adecuado
entre los intereses del proyecto y los intereses de la
organización toda, así como también resolver los conflictos.
Sin embargo, existían muchos problemas con este enfoque.
En primer lugar, el comité directivo por lo general no se reunía
con frecuencia y a menudo sólo tenía una idea vaga respecto de
lo que sucedía. En segundo término, los comités directivos por lo
general no se comunicaban entre ellos. Tercero, existían varias
funciones IT importantes (como la arquitectura) y resultados
deseados (como productividad y reutilización) que no contaban
con un comité directivo. Por lo tanto, el enfoque del comité
directivo era incompleto, inconsistente y por lo general
producía resultados por debajo de lo óptimo.
Gobierno en tiempo real
Pasó la moda de los comités directivos, y varias grandes
organizaciones IT comenzaron a prestar atención explícita a los
asuntos del gobierno de SOA. En los casos en los que se
tercerizaban cantidades importantes de actividad IT, este
gobierno incluía asuntos de compra y relaciones con
proveedores claves.
Con SOA, contamos con un nuevo enfoque para lograr
realizar las cosas. También tenemos los problemas anteriores
de gobierno más algunos nuevos. Existe una gama compleja de
actividad orientada al servicio cada una de las cuales necesita
“CON SOA, CONTAMOS CON UN NUEVO ENFOQUE
PARA LOGRAR REALIZAR LAS COSAS. TAMBIÉN
TENEMOS LOS PROBLEMAS ANTERIORES DE
GOBIERNO MÁS ALGUNOS NUEVOS.”
ser coordinada de forma adecuada y alineada con los objetivos
de la empresa, y la escala de tiempo ha cambiado. En vez de
contar con comités directivos que se reúnen cada dos meses,
tenemos un gobierno en tiempo real, que abarca tanto el
gobierno del diseño así como también el gobierno del tiempo de
ejecución.
Sabemos que esto no puede reducirse simplemente a un
problema de gestión. Muchas organizaciones experimentan
dificultades al realizar SOA de manera adecuada, no a causa de
problemas técnicos, sino por la falta de un gobierno apropiado.
¿Cómo se financia el enfoque dual? ¿De qué forma se puede
gestionar el enfoque dual de manera tal que las metas del
servicio sean sistemáticas con las metas de la empresa y así
SOA pueda gestionarse de forma efectiva? Y ¿Qué sucede
cuando no concuerdan entre sí?
Necesitamos abandonar la idea de un comité sentado
alrededor de una mesa escuchando los informes de progreso y
emisiones de registros de los jefes de proyecto. Es necesario
aceptar la idea de que la dirección comprende la
responsabilidad de múltiples interesados y esta responsabilidad
está incluida en la noción de gobierno que es esencial al tratar
los asuntos de valor, valor para quién y valor para qué fin.
Estas son cuestiones básicamente éticas (en el más amplio
sentido de la palabra ética—la ciencia del valor). Por lo tanto,
mientras la gestión trata de lograr hacer las cosas, el gobierno
se asegura que las cosas correctas se realicen de la forma
correcta.

2 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL

 Gobierno

En una organización IT jerárquica en la que lo “correcto” se Tabla 1: Comparación SOA 1.0 y SOA 2.0
define en primer lugar, esta distinción puede no parecer
preocupar demasiado. No obstante, si pensamos en desarrollar SOA 1.0 SOA 2.0
un enfoque dual en el que existen tensiones necesarias entre las Orientado a la oferta Colaboración oferta-demanda
metas de la empresa y las necesidades del servicio, y mucho Procesamiento directo y completo Sistemas complejos de sistemas
menos un desarrollo distribuido/federado en el que estas Pensamiento dirigido único Composición en colaboración
Reutilización controlada Reutilización sin control
tensiones se reproducen a lo largo de múltiples entidades de
Endo-interoperabilidad (dentro de Exo-interoperabilidad
negocios, entonces esto es de gran importancia. Tan pronto una única empresa o sistemas en
como dos actividades paralelas (por ejemplo, creación del colaboración cerrados)
servicio y consumo del servicio) no rinden cuentas ante el Ahorro de costos Experiencia del usuario mejorada
mismo nivel superior de gerencia, el gobierno se torna una
Tabla 2: Armonización para la interdependencia
cuestión de negociación entre dos organizaciones separadas,
más que una simple resolución de gestión dentro de un único
Armonización Interdependencia
marco adecuado. “Los funcionarios del Pentágono “Hemos ido desde la armonización
Dicho de otra forma, la responsabilidad jerárquica depende de admiten que la táctica de Bush – de la capacidad conjunta hasta la
la transparencia vertical –de lo que se ve, es de lo que se lo colmar los cielos de municiones y interoperabilidad para en realidad
puede responsabilizar a uno. La transparencia vertical no implica provisiones– es también un riesgo. ínter depender donde nos hemos
transparencia horizontal, ¿De qué forma pueden los proveedores La misión humanitaria complicará vuelto más dependientes de la
en cierto grado la planificación de capacidad de cada uno de los
de servicios ser responsables de las necesidades del servicio y/u
una guerra. Lo que un General otros de darnos lo que
otras entidades de negocios? llama armonización –asegurarse necesitamos”.
El gobierno debe determinar la forma en la que los conflictos de que los aviones de guerra y los --Entrevista con el General
de interés entre las partes interesadas se representan y aviones de auxilio no se Shoomaker, CSA, octubre de
contienen en los intereses del todo. Dicho de otra forma, debe confundan entre ellos– es hoy en 2004.
crear una estructura dentro de la cual esta representación sea día uno de los principales focos de
las estrategias del Pentágono.
posible. Si comprendemos los intereses de los interesados para
“Tratar de luchar y tratar de
expresarlos como un valor desde puntos de vista en particular proporcionar alimentos al mismo
(en relación horizontal o vertical de acuerdo a lo que sucede), tiempo es algo nuevo para
entonces esta cuestión puede formularse en términos de una nosotros”, dijo un general de la
estructura dentro de la cual se distribuyen el beneficio, costos y Fuerza Aérea. “No estamos
riesgos entre estos intereses. Por ejemplo, el gobierno de SOA seguros con precisión de la forma
en la que se resolverá esto” –
proporciona normas básicas para realizar e imponer acuerdos de
“Enfrentando la Furia”, Time
interfaz. En el mundo real, sabemos que todos los contratos Magazine, octubre 2001.
están sujetos a ser incumplidos y renegociados en la medida en
la que los requerimientos y las condiciones cambian. Sin
puedan agruparse cuando sea necesario), sino que también
embargo, ¿Quién incurre en los riesgos de tales cambios?, y
debe asegurarse de que existan las condiciones de
¿Quién debe asumir los costos de los cambios? Si uno decide
transparencia dentro de la cual la atención sea posible.
que necesita cambiar la interfaz ¿está forzado a responder a
Crear estas condiciones de transparencia implica una
este cambio?, y en tal caso, ¿Con qué rapidez y quién asume los
separación previa de los intereses. Separar lo que necesita
gastos?
atención de los que puede (de forma segura) ser ignorado nos
lleva a un interés de gobierno clave: el gobierno de lo que
Estructurar la transparencia
puede ser ignorado que es previo al gobierno de conflictos de
Existe también un conflicto de interés entre el presente
intereses entre las cosas importantes. ¿Qué es lo que se puede
(adaptación a corto plazo) y el futuro (adaptación a largo plazo).
permitir ignorar? ¿Qué formas de ignorancia se exigen?
¿De qué forma se debe admitir la adaptabilidad? ¿De qué forma
Por ejemplo, SOA recibe nociones de transparencia de
deben las grandes soluciones complejas ser no sólo permitidas
trabajos previos sobre el procesamiento distribuido abierto. Se
sino también estimuladas para que evolucionen? y ¿De qué
puede utilizar un servicio sin conocer su ubicación; se puede
forma debe equilibrarse esta evolución con la necesidad de
utilizar información sin conocer la fuente (procedencia). Este
orden y viabilidad a corto plazo?
“no saber” es muy útil de alguna manera, pero peligroso en
Estas preguntas pueden formularse en dos niveles: primero al
otros aspectos. Esto implica que no es necesaria la
nivel de la gestión, donde se mantiene una serie de intercambios
transparencia horizontal.
y controles y segundo al nivel del gobierno, donde es necesario
SOA requiere acoplamiento escaso (y coordinación
formular preguntas respecto de la estructura dentro de la cual se
horizontal) no sólo entre los artefactos de software, sino
distribuyen regularmente los beneficios, costos y riesgos.
también entre las unidades de la organización que son
Dicho de otro modo, se trata de determinar la asignación o
responsables de estos artefactos. La estructura de la
distribución de tareas y responsabilidades y el proceso de
organización generalmente (a pesar de que no siempre) refleja
negociación entre ellos. En última instancia, es una cuestión de
la estructura de software. ¿Qué sucede cuando ya no podemos
cómo estructurar la transparencia: determinar quién puede
confiar más en que alguien está asumiendo este riesgo?
saber qué, cómo y cuándo respecto de realizar las cosas en
relación a quién. El gobierno confiere autoridad al crear
Interoperabilidad
responsabilidades con sus responsables asociados en base a la
Por lo general, se supone que el programa de SOA se trata del
experiencia profesional y el trabajo impulsado por la gestión (o
desacoplamiento. Se utilizan modelos de requerimientos para
más bien gestiones) requiriendo la creación de formas
orientar la disociación –la identificación de servicios por
adecuadas de transparencia.
separado que se pueden usar de forma independiente uno del
Uno de los principios claves para la gestión de la complejidad
otro cuando se utilizan. Estos servicios por separado son
en IT y en cualquier otro entorno es la separación de intereses.
entonces diseñados para su máxima reutilización, produciendo
La separación de intereses implica atención selectiva: Quién
economías de escala de bajo nivel al satisfacer un nivel
presta atención a qué. Existe aquí una importante función de
creciente de demanda de cualquier tipo del que fuera antes
gobierno. No sólo el gobierno debe asegurarse de que la
posible y economías de ámbito al satisfacer la demanda de una
atención sea completa (al menos en el sentido de que todo lo
mayor variedad de contextos.
importante sea tratado), efectiva (sin duplicación de la atención)
y relacionada (en el sentido de que los intereses

THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net 3

 Gobierno

Figura 1: Relación de la oferta con la demanda componentes integrantes de una fuerza –el llamado fuego no
hostil (en el que matamos nuestro propio lado por error) es con
claridad un asunto de vida o muerte. En nuestros términos, el
Interoperabiliad

fuego hostil es un ejemplo extremo de falla de interoperabilidad.

Exógeno QUIÉNES PORQUÉ
La armonización significa la organización de operaciones de
manera tal que se minimicen los potenciales de riesgo de este tipo
QUÉ CÓMO de conflicto, para que de este modo, actividades o unidades
Endógeno separadas puedan ser operadas de manera independiente y
asíncrona contribuyendo aún con la misión total.
Hacer que la Pero la armonización, por lo general, también implica un
Coordinación intercambio costoso. Se deben duplicar los recursos y las
cosas
del todo
funcionen operaciones conflictivas potenciales se inhiben de forma
deliberada. Las presiones por un uso más eficaz de los recursos,
fuerza a la especialización capaz de producir economías de escala
Coordinación y ámbito, que se combinan con misiones políticas y dinámicas
crecientes, a enfrentar cualquier contexto elegido de armonización
con niveles de interdependencia en aumento.
Figura 2: Relación de la oferta con la demanda para un La respuesta a este asunto, ya que las tecnologías de
ejemplo del cuidado de la salud comunicación y control se han vuelto más sofisticadas y
confiables, es aumentar el grado de coordinación posible entre los
componentes integrantes de una fuerza, y así permitir que las
PO RQ UÉ
Form a en la que la unidades y actividades se combinen de formas más efectivas, lo
Q U IÉN ES
Presentación de condición del paciente que es la motivación para los conflictos centrados en la red. Más
se desarrolla con el
síntom as paso del tiem po que depender de un plan previo basado en una armonización en
(Paciente/D r.)
Interoperabiliad

(Fundación de
Exógeno Atención Prim aria)

“EN CUALQUIER FORMA DE ARMONIZACIÓN SE

Endógeno
QUÉ
Proveedor
CÓ M O
G erencia Senior
ENCUENTRA IMPLÍCITO UN ENFOQUE PARA
del servicio (Fundación COORDINAR ACTIVIDADES ARMONIZADAS POR
(ortopedia) Hospitalaria)
MEDIO DE LA FORMA EN LA QUE INTEROPERARÁN”.

Hacer que la
cosas
C oordinación
del todo
funcionen
C oordinación
Claramente existen algunos sistemas que son excesivamente
rígidos y se beneficiarían con un grado mayor de flexibilidad de
forma tal que sus servicios componentes puedan utilizarse de
forma independiente como un todo. Sin embargo, esta rigidez es
sólo una parte de la historia. Mientras que algunos sistemas son
excesivamente rígidos, existen otros tantos que están
fragmentados de forma irremediable: para obtener un uso efectivo
de ellos, los servicios independientes deben funcionar juntos. Por
lo tanto, el potencial total de SOA surge de la descomposición y
recomposición.
Un tipo importante de disociación, según la ponen en práctica
los militares, es conocida como armonización. La armonización
implica tomar una misión completa y dividirla en misiones
integrantes que puedan realizarse independientemente una de la
otra, lo que produce una estructura jerárquica en la que la misión
de cualquier componente integrante debe depender de la forma en
que su misión se adecua a un gran todo que es definido por la
forma en la que la línea de mando ha impuesto la armonización.
La armonización se relaciona en particular con los efectos que crea
cualquier misión, y los efectos secundarios de estos efectos sobre
cualquier otra misión. Por lo tanto, la armonización no sólo
requiere la comprensión de cómo funcionan las cosas (es decir,
gestión) sino también la comprensión de la forma en la que
pueden lograrse efectos compuestos a partir de efectos
integrantes con el menor conflicto posible entre los componentes
integrantes y la mayor efectividad en la utilización de los recursos.
La armonización, por lo tanto, se refiere al desligamiento, pero
crucialmente se trata de la forma en la que se realiza este
desligamiento en relación con la misión general. (Ver Tabla 2)
Los militares toman con mucha seriedad los conflictos entre los
particular, la red permite que los comandantes coordinen de forma
dinámica las relaciones entre los componentes de una fuerza en la
medida en que los efectos compuestos que ellos necesitan
producir cambian. Es el uso de una red lo que posibilita llevar el
poder a la periferia de la fuerza donde se encuentra al enemigo.
Riesgos de interoperación
Las organizaciones comerciales y administrativas por lo general
intentan la armonización por medio de una jerarquía de gestión y
de una estructura de presupuestos contables asociados y centros
de costos que crean transparencia vertical coherente con la forma
de armonización. Este proceso es conocido por ser inflexible e
ineficaz, produciendo silos de actividad que son relativamente
resistentes a las demandas de las diferentes organizaciones. El
poder a la vanguardia (y, casi indiscutiblemente, las formas
avanzadas de SOA) no son compatibles con las estructuras
tradicionales de contabilidad de costos y presupuestarias.
La armonización nos lleva hacia una noción fácil de
interoperabilidad: X e Y son ínter operables si pueden funcionar en
forma conjunta sin interfaz mutua. Esta operación es el orientador
detrás del desligamiento de los programas de SOA, y esto sí
produce mejoras en las economías de escala y ámbito.
Existe también una noción positiva de interoperabilidad: X e Y
son interoperables si puede existir entre ellas alguna coordinación
activa. Esta noción nos hace ir más allá de la armonización per se,
y nos hace no sólo considerar las suposiciones respecto de la
composición implícita en la forma de armonización sino que
también nos lleva a considerar la forma en que pueden hacerse
explicitas y dinámicas por medio de la coordinación. Sin embargo,
esto es ahora una coordinación de red (horizontal) más que un
planeamiento descendente jerárquico, que plantea las mismas
preguntas de gobierno que hemos analizado anteriormente en la
relación entre el enfoque dual de perseguir los objetivos de la
empresa y el servicio.

4 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL

 Gobierno

Tabla 3: Modelo de relación del gobierno

Modelo Descripción
Comparación La demanda se define de forma tal que el contexto desde el cual proviene es ignorado, pero el servicio se coordina de una manera
(QUIÉNES-CÓMO) tal que le permite responder a una demanda en particular. Esta característica coincide con el esquema de “comparación” para el
paciente, quien busca la mejor solución ofrecida para su demanda. Para los proveedores, esta forma de gobierno les permite
minimizar su exposición a exo-riesgos limitando la definición de la demanda a la cual van a responder (requerimiento del usuario); a
pesar de que aún enfrentan los riesgos de integración dentro de la empresa.
Costo No sólo se define la demanda de forma tal que el contexto desde el cual proviene es ignorado, sino que la respuesta del servicio
(QUIÉNES-QUÉ) está también regida por procedimientos establecidos y no hay necesidad de un proceso de coordinación explícito. En este enfoque
de “costo”, tanto la naturaleza de las demandas como las respuestas a ellas se han estandarizado. Ahora se minimiza el riesgo de
integración para el proveedor y se proscriben los riesgos de tecnología e ingeniería.
Personalizar Una forma implícita de coordinación de cómo funcionan las cosas, por lo general en la forma de un régimen presupuestario
(PORQUÉ-QUÉ) particular, limita la manera en la que el servicio puede responder a la condición del paciente. Esta característica coincide con el
enfoque “personalizar” en el que el servicio se estandariza pero la forma en la que se proporciona en el contexto del paciente puede
variar (personalización masiva). Aquí el proveedor está nuevamente expuesto a los riesgos de integración, ya que crea más
variabilidad en la forma en la que funciona el servicio.
Destino Cada una de estas tres formas trata a la demanda como simétrica para una forma implícita o explícita de coordinación endógena.
(PORQUÉ-CÓMO) Sólo en el cuarto caso tenemos un gobierno asimétrico en el que las formas endógenas o exógenas de coordinación deben ser
alineadas entre ellas. Esta característica coincide con el enfoque “destino”, en el que el paciente concurre al lugar en el que puede
obtener un tratamiento exactamente alineado con la naturaleza de su condición. Es también sólo en este caso que el proveedor
asume los riesgos de exo-interoperabilidad de forma explícita.

Nos concentramos en particular en los riegos asociados a la
interoperabilidad, no sólo porque cualquier geometría determinada
es en particular una coordinación entre sus servicios integrantes,
sino también porque son los que surgen en la medida que uno
coordina a lo largo de sistemas y organizaciones. (Hemos estado
siguiendo con interés considerable los desarrollos recientes acerca
del Huracán Katrina, ya que algunos de los comentarios públicos
del FEMA [Federal Emergency Management Agency] exponen con
claridad dificultades al gestionar algunos de los riesgos de
interoperabilidad). ¿Cómo podríamos pensar acerca de la
naturaleza de estos riesgos?
La forma de gobierno aquí implica establecer los términos de
referencia dentro de los cuales la gerencia tiene la responsabilidad
de mantener la interoperabilidad. Los riesgos de la
interoperabilidad pueden clasificarse según su gravedad: en este
contexto esta clasificación significa el grado en el cual un
determinado riesgo pone en peligro la forma en la que deseamos
coordinar las cosas.
En cualquier forma de armonización se encuentra implícito un
enfoque para coordinar actividades armonizadas por medio de la
forma en la que interoperarán. Una visión simple de la
interoperabilidad es que presenta una forma de ignorancia
selectiva y deliberada: si uno presta atención a X, no necesita
prestar atención a Y. Por ejemplo, si se adopta este estándar
abierto, no es necesario preocuparse por cuál de estos efectos
secundarios estándar se podrán utilizar. Esta interoperación es una
forma de especialización (o separación de intereses) tal como se
describió con anterioridad, lo que posibilita esta ignorancia
selectiva. De esto se desprende una suposición respecto de lo que
X e Y significan para aquellos que tratan de utilizarlas para
producir un efecto combinado.
Figura 3: Ciclo del gobierno
Estandarización del modelo
de relación del contexto
Requiere un
gobierno asimétrico
Comparación Destino
Personalización
Estandarización del servicio bajo
del modelo de el modelo de la
coordinación de la oferta
oferta estandarizada
Costo Personalizar
Personalización del servicio
bajo el modelo de la oferta
estandarizada
Pensemos sobre la operabilidad de hojas de cálculos de gestión
en una gran organización. Cada gerente produce su propia hoja de
cálculos de forma idiosincrática para fundar un conjunto particular
de decisiones de gestión. A pesar de que todos importan algunos
datos desde la base de datos de la organización, han agregado en
su mayoría datos de alguna otra parte, y todos han formateado las
cosas de diferente forma. Un Gerente Senior, Joe, realiza una
presentación ante una reunión de directorio sobre una decisión
estratégica importante, fundando sus recomendaciones con
algunos gráficos realizados en Microsoft Excel que derivan de una
hoja de cálculos compleja, hecha a mano (y completamente sin
documentar). A los colegas de Joe les resulta imposible
comprender su hoja de cálculos, o importar su análisis en sus
propias hojas de cálculos para un estudio adicional, es más
probable que el sucesor de Joe construya su propia hoja de
cálculos que trate de utilizar la existente.
En este caso, la interoperabilidad falla en dos niveles. No sólo
falla en el nivel técnico de compartir la hoja de cálculos diseñada
como artefacto para el usuario, sino que también falla al nivel de
significado. El artefacto es una expresión de un marco de
significado que ha creado Joe que no puede ser compartido por los
colegas de Joe ni sus sucesores. Joe trata de coordinar la
información de manera tal que requiere que lo haga interoperativo
de nuevas formas (no estándar). Las mismas dificultades para los
gerentes que colaboran en decisiones estratégicas complejas
también reflejan su valor potencial al crear nuevas formas de
actuar.
Compartir el compromiso
¿Qué tiene que ver esto con la ignorancia? Se debe a lo mucho
que uno necesita saber acerca de Joe y su experiencia de gestión
(es decir, su marco del significado) para que su hoja de cálculos
tenga sentido. Cuanto más compleja es la hoja de cálculos, más se
vuelve casi una representación de Joe mismo y su forma de
prestar atención a ciertos detalles de gestión. Para utilizar la hoja
de cálculos, uno casi necesita ponerse en su piel, ver las cosas a
través de sus ojos. Si Joe tiene el poder suficiente dentro de la
organización, entonces puede imponer su experiencia de gestión
sobre sus colegas y hacer que ellos utilicen su hoja de cálculos,
pero esto, por lo general, implicaría problemas de
interoperabilidad en cualquier otro lugar cuando la información
comienza a ser utilizada de formas nuevas e imprevistas. Una hoja
de cálculos diseñada para su reutilización debe asumir algunos
niveles de conocimiento compartido entre el usuario y el autor.
Para obtener una coordinación entre X e Y, se debe ser capaz
con claridad de interoperar en un sentido técnico –Joe debe poder
enviarme su hoja de cálculos y yo debo tener instalado el sistema
correcto para poder ejecutarla. Pero esto no es suficiente.
Supongamos que tenemos P1 utilizando X y P2 utilizando Y. La
coordinación debe considerar los efectos no sólo de la forma en

THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net 5

 Gobierno
Figura 4: Estructura de la función
Cliente/usuario Orienta
Contexto del cliente
de la empresa
Obliga a Se anticipa a
Satisface
Arquitectura de la
Desarrollador SOA empresa
que X e Y interoperan, sino también la manera en que P1 y P2
afectan el significado de X e Y. Junto con la coordinación (o su
ausencia) se produce el riesgo de que el uso que P1 hace de X1 y
el que P2 hace de Y no produzcan el comportamiento conjunto
esperado. Podemos, por lo tanto, comprender los riesgos de
coordinación de la misma forma que comprendemos los desafíos
que enfrenta la forma de gobierno de un enfoque dual. Se crean
por medio de una falla para establecer un marco compartido de
significado dentro del cual actuar.
Con la composición dirigida (planificación central, autoridad de
diseño única), el problema del significado compartido e ignorancia
permitida se delega de forma vertical, pero la geometría
empresarial resultante debe ser endógena para las
interoperaciones de actividades bajo esa jerarquía. Por lo tanto, A
se descompone en (o compone de) B y C; y si existen riesgos
asociados con la interoperabilidad entre B y C, entonces estos
riesgos son asumidos por la persona en la jerarquía de diseño que
posee A. En una organización el requerimiento para la
transparencia vertical es, por lo tanto, ser capaz de hacer cumplir
este compromiso compartido para la coordinación vertical.
En cambio, la composición en conjunto (planificación a la
vanguardia entre múltiples autoridades de diseño) requiere que se
negocien los significados compartidos y las ignorancias permitidas,
y que la geometría empresarial resultante posea elementos
endógenos y exógenos que sean asumidos no todos para estar
bajo la misma jerarquía. Por lo tanto, la transparencia horizontal
significa ser capaz de determinar la forma en que todas las piezas
encajan juntas como un todo para que de esta manera se pueda
negociar un acuerdo sobre la forma de imponer una única
jerarquía, aunque temporaria, para los propósitos particulares de
colaboración, es decir, coordinación horizontal.
En última instancia, debe existir un compromiso compartido
para una única jerarquía, sin importar si se está siguiendo un
proceso descendente (disociación dirigida, analítica) o ascendente
(composición en conjunto, sintética) siempre que pueda existir un
compromiso compartido en último término para una jerarquía
única. La diferencia de los enfoques reside en si las jerarquías
resultantes son o no estáticas o dinámicas. Desde el punto de
vista de una empresa que proporciona servicios a sus clientes, la
personalización implicará estar de acuerdo con las jerarquías antes
de formar parte de una relación empresarial. Por el contrario, la
personalización dinámica implica que todos los procesos de
aceptación de jerarquías adecuadas deben ser parte de las
relaciones empresariales en curso.
Análisis de riesgo
Volvamos a la idea de Alexander del nivel en el cual podemos
preservar la estructura: debemos ser capaces de decidir qué
6 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL
cantidad de la geometría debe ser variable (sin determinar las
formas en las que los usuarios del servicio pueden personalizar de
forma dinámica sus usos), y qué debe ser determinado
(sobredeterminación de las formas de relaciones empresariales
que pueden ser admitidas). Mientras que las formas simétricas de
gobierno pueden imponer coordinación vertical, las formas
asimétricas de gobierno deben permitir la coordinación horizontal,
lo que genera nuevos problemas relativos a la forma de compartir
la verdad. Bajo la coordinación vertical, esto puede garantizarse
por medio de un contrato con el contexto superior, mientras que
bajo la coordinación horizontal esto se debe negociar. Este tema
presenta nuevos desafíos para el liderazgo distribuido bajo formas
asimétricas de gobierno (Ver “Recursos” por Huffington et al. y
Boxer y Eigen).
En estos términos podemos ver que la coordinación vertical es
dominante cuando el CÓMO es dominante, mientras que la
coordinación horizontal es dominante cuando el PORQUÉ es
dominante (Ver Figura 1). También podemos observar que
mientras el CÓMO permanece dominante, estamos exteriorizando
los riesgos exógenos.
Utilizamos métodos de análisis organizacional para distinguir los
riesgos de endo-interoperabilidad (que provienen de las fallas
dentro de la organización) de los tipos de riesgo de exo-
interoperabilidad (donde la fuente se encuentra fuera de la
organización). Estos riesgos de exo-interoperabilidad relacionan lo
que sucede cuando los sistemas y servicios del proveedor se
“EN QUÉ MOMENTO DEL CICLO DEBE ESTAR EL
NEGOCIO DEPENDERÁ DE LA FORMA EN QUE SE
ELIJA EQUILIBRAR LOS RIESGOS Y RECOMPENSAS”.
combinan con sistemas de terceras partes y servicios como parte
de una solución del usuario. Por lo tanto, el sistema del proveedor
puede no funcionar como se espera en el nuevo contexto, puede
no interoperar con otros sistemas tal como se desea, y el sistema
total de los sistemas puede no interactuar con el contexto de uso
del usuario tal como se espera. Pueden considerarse estos
resultados como errores de ejecución, de planificación y de
intención dentro del dominio del usuario.
Somos conscientes de las diversas técnicas analíticas para la
comprensión y gestión de los riesgos de endo-interoperabilidad.
No somos conscientes de las técnicas analíticas para la
comprensión y gestión de los riesgos de exo-interoperabilidad.
Esta situación no es sorprendente en un mundo que define su
empresa como una que promueve soluciones, pero en un mundo
orientado al servicio, estos riesgos comienzan a ser cada vez
mayores en la medida que los proveedores encuentran la atracción
de los usuarios emancipados (Ver Hagel y Brown en “Recursos”).
El cambio de un push a un pull no es sólo un problema de
adoptar nuevas formas de gobierno y coordinación horizontal.
También requiere que el proveedor adopte una mentalidad de
plataforma en la cual la plataforma no sea suya sino del usuario –
en el mejor de los casos están proporcionando una plataforma
sobre la cual los usuarios puedan resolver sus problemas. La
inhabilidad general para gestionar los riesgos de exo-
interoperabilidad no es sólo un problema muy importante, sino
que también es central para admitir una relación de interacción
entre el cliente y el servidor en la red. Varias de las organizaciones
de proveedores con las cuales hablamos aún niegan esto, pero
encontramos más organizaciones de usuarios que reconocen la
necesidad de que los proveedores adopten un enfoque sistemático
para gestionar sus riesgos de exo-interoperabilidad. Lo que está
en peligro es el antiguo estilo de compra de libre competencia que
supone que los requerimientos del usuario pueden separarse del
contexto de uso. En cambio, los usuarios están buscando un
enfoque de colaboración para gestionar encargados de riesgos a
cambio de la provisión de plataformas del servicio.

Oferta y demanda
La característica esencial de este modelo de plataforma es que
gestiona tanto el lado de la oferta (es decir, niveles de endo-
interoperabilidad) como el lado de la demanda (niveles de exo-
interoperabilidad). En estos términos, veremos que las cuatro
posiciones descriptas en “Metrópolis y Gobierno de SOA” (The
Architecture Journal, Vol. 1, Nº 2 – Ver “Recursos”) son cuatro
modelos diferentes de relaciones de gobierno entre los lados de la
oferta y la demanda, sólo uno de los cuales requiere un gobierno
asimétrico. Los otros tres utilizan variaciones de coordinación
vertical (Ver Tabla 3).
Si adoptamos un modelo de plataforma, entonces debemos
contar con las cuatro áreas que se describen en la Figura 2 en
relación con las otras de manera tal que sea alineada al POR QUÉ
–en términos de gobierno: la coordinación endógena impuesta por
la verdad (el CÓMO ) sobre el servicio debe estar alineada de
forma explícita a la forma particular de coordinación exógena
impuesta sobre la demanda del paciente por su condición (el POR
QUÉ).
El ciclo de gobierno muestra cómo dos tipos diferentes de
estandarización (diseñadas para reducir ciertos tipos de riesgo)
producen el efecto de dejar una empresa o sistema fuera del
gobierno asimétrico, mientras que dos tipos distintos de
personalización (que reintroduce ciertos tipo de riesgo) pueden
otorgar a la empresa o sistema el acceso a los beneficios
potenciales de relacionarse con la asimetría (Ver Figura 3).
¿Hasta qué punto son las recompensas acordes con los riesgos
en cada caso? Debemos ser capaces de comprender la manera en
la que estas formas diferentes de gobierno están presentes o
excluidas dentro de una organización de suministro en la medida
que cambia su relación con la demanda, en respuesta a la
competitividad cambiante y las circunstancias de la demanda. En
la Figura 3, las cuatro formas están ordenadas para mostrar el
ciclo analizado en nuestro artículo “Metrópolis y Gobierno de SOA”
(Ver “Recursos”). Este ciclo clarifica las transiciones entre cada
forma, dos de las cuales requieren estandarización y dos
personalización:
• El movimiento desde el destino hacia el producto implica reducir que necesitaban. El desafío, por lo tanto, era permitir que el
la exposición a los riesgos de integración exteriorizando los
riesgos exógenos.
• El movimiento desde el producto hacia el costo implica reducir
la exposición a riesgos de ingeniería y tecnología estandarizando para la Fundación de Atención Primaria iniciarse ya que no
el modelo empresarial.
• El movimiento desde el costo hacia la personalización implica
nuevamente aumentar la exposición a los riesgos de
integración, pero sólo los endógenos.
• Sólo el movimiento desde la personalización hacia el destino
enfrenta a la empresa con los riesgo de exo-interoperabilidad.
En qué momento del ciclo debe estar el negocio dependerá de la riesgos de interoperabilidad asociadas con cada uno de los
Tabla 4: Los cuatro roles del Workshop
THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net
Gobierno
forma en la que se elija equilibrar los riesgos y recompensas. Tal
como Prahalad y Ramaswamy sostienen en “El futuro de la
competencia” (Ver “Recursos”), en la medida que la demanda se
vuelve cada vez más asimétrica, también se vuelve cada vez más
crítica para que las empresas desarrollen modelos escalables que
puedan también funcionar en el cuadrante de destino. A partir de
la comprensión del ciclo completo que se muestra en la Figura 3,
puede decidirse qué formas de cambio son necesarias para
capturar las demandas y, por lo tanto, qué formas nuevas de
riesgo necesitan ser migradas en pos de los beneficios. Si bien se
conoce mucho sobre la forma de gestionar tres de las formas de
gobierno de este ciclo, las dificultades de ser capaz de admitir la
transición por la cuarta, representa uno de los obstáculos más
importantes para el crecimiento continuo de una empresa cuando
ésta se enfrenta con una asimetría de demanda creciente.
En el Workshop
Pasando a un ejemplo de un caso ortopédico, un clínico había sido
localizado dentro de la Fundación Hospitalaria para proporcionar su
propio servicio ortopédico (comparación), permitiendo que la
demanda sea estandarizada a simplemente esas formas de
demanda que surgen de los asesores. A través del tiempo, el
servicio en sí mismo y sus presupuestos fueron estandarizados
para alinearlos con estas formas de demanda (costo). Como
resultado, los médicos de cabecera debían enviar a los pacientes a
los asesores expertos, aún cuando no existía una necesidad real
de ver al asesor, sólo para obtener acceso al servicio. Como
consecuencia, cantidades limitadas de referencias eran permitidas
“LA ASIMETRÍA DE GOBIERNO EXPLICA MUCHAS DE
LAS DIFICULTADES QUE LAS PERSONAS HAN
EXPERIMENTADO CON SOA”.
de forma directa para el servicio en los casos en los que el
paciente era conocido porque ya había tenido una consulta previa
(personalizado). Sin embargo, la Fundación de Atención Primaria
era responsable de todos los pacientes en la captación de la
Fundación Hospitalaria y muchos de ellos no recibían el servicio
servicio admita estas necesidades de forma directa (destino). La
Fundación Hospitalaria se oponía a esta ayuda debido a la
necesidad de financiar este servicio de forma diferente, y era difícil
contaban con los medios apropiados para gestionar el equilibrio de
los costos y riesgos de este servicio. Es decir, se debían desarrollar
nuevas formas de gobierno asimétrico.
Para trabajar con estos temas dentro de una organización de
suministro, hemos desarrollado un proceso de workshop que
distingue cuatro grupos: azul, blanco, rojo y negro, y está
diseñado para desempaquetar y articular las diferentes formas de
7
 Gobierno
cuadrantes. El proceso del workshop se basa deliberadamente en
una metáfora militar, pero se ha adaptado para que lo utilicen las
organizaciones civiles/comerciales así como también las militares.
Los objetivos típicos del workshop son aprender de forma
conjunta la manera en que los roles funcionan en relación con
cada uno de los otros en una organización específica, en un
momento específico; descubrir el grado en el cual la organización
carece de capacidad respecto de los roles y comenzar a desarrollar
la capacidad; y obtener una imagen de la organización actual de la
demanda que enfrenta la organización.
Los usos posibles de este proceso de workshop proporcionan
una forma de acercamiento a la cantidad de problemas relativos al
impacto de las formas asimétricas de la demanda incluyendo:
estrategia empresarial, rediseño organizacional, diseño SOA,
gobierno SOA, análisis de seguridad y gobierno (Ver Figura 4).
En nuestro ejemplo, el grupo azul era el servicio, el blanco la
Fundación Hospitalaria, el rojo el paciente y su médico de
cabecera y el grupo negro era la Fundación de Atención Primaria
que actuaba por los intereses de los pacientes dentro de su
captación. La Tabla 4 muestra la forma en que estos grupos se
relacionan con los diferentes niveles y asimetrías. El workshop
funciona de la siguiente manera:
• Facilita el reconocimiento de la función ejercida por cada grupo,
y las formas de riesgo particulares que cada uno enfrenta.
• Comprensión de las consecuencias de la presencia/ausencia de
ciertos colores para el proceso de gobierno.
• Facilita las conversaciones entre los cuatro colores
comprendiendo al comprender el sistema como un todo y sus
interdependencias al gestionar riesgos.
• Utiliza esta comprensión para desarrollar estrategias para la
gestión de riesgos y coincide en base a lo que el blanco debe
determinar que es de su interés.
Recursos
Boxer Research Limited
www.asymmetricdesign.com
“Del push al pull: Modelos Emergentes para Recursos de
Incentivo,” John Hagel y John Seely Brown (Octubre 2005)
“Metrópolis y Gobierno de SOA,” The Architecture Journal 5,
Richard Veryard y Philip Boxer, Vol. 1, No. 2, (Microsoft
Corporation, 2005)
“Edición especial sobre Gobierno de SOA,” CBDI Journal
(Noviembre 2005)
“Llevar el poder a la periferia de la organización: rol como
práctica,” Philip Boxer y Carole Eigen, Simposio Anual de ISPSO,
2005, (2005)
El futuro de la competencia: Co-Crear valores únicos con los
clientes, C.K.
Prahalad y Vebkat Ramaswamy (Imprenta de la Escuela de
Negocios de Harvard, 2004)
La naturaleza del orden, Christopher Alexander (Centro para la
estructura del medioambiente, 2003)
El mundo es plano: Una breve historia del siglo veintiuno, Thomas
L. Friedman (Farrar, Straus y Giroux, 2005)
“¿Cuál es el costo emocional del liderazgo distribuido?” Trabajando
bajo la superficie: La vida emocional de las organizaciones
contemporáneas, Clare Huffington et al., Series clínicas Tavistock,
(H. Karnac Ltd., 2004)
8 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL
Grupo de trabajo
La atención del workshop se centra en última instancia sobre los
asuntos particulares que enfrenta el grupo blanco respecto de la
forma que ejerce el gobierno:
• El blanco limita la forma en que el azul se comporta en torno a
los intereses del blanco. Bajo estas condiciones de demanda
asimétrica, el blanco deberá elegir determinar la respuesta por
debajo de la demanda del azul y permitir el liderazgo distribuido
en la forma en que el azul responde al rojo dentro de su
contexto negro particular.
• El blanco por lo tanto debe comprender al negro para conceder
la subdeterminación adecuada al azul que le permita a éste
satisfacer al rojo.
• En estos términos, el gobierno simétrico del blanco se vuelve
asimétrico ya que éste trata de forma explícita las
consecuencias del negro para la forma en que el azul responde
al rojo.
En este caso el desafío consistía en hacer posible la asimetría de
gobierno de la relación entre el servicio y el paciente en la
captación de la Fundación de Atención Primaria, lo que a su vez
significaba crear transparencia horizontal: debía ser posible para el
clínico entregar un informe respecto de la forma en que alineaba
los tratamientos de los pacientes particulares para una naturaleza
en particular de la condición del paciente y sus resultados. De este
modo, la Fundación de Atención Primaria compraba tratamientos
de pacientes, más que cantidades determinadas de episodios de
tratamientos, lo que implicaba crear una plataforma que pudiera
admitir esta relación y cambiara los protocolos de adquisición para
reflejar de este modo el eje cambiado de la contabilidad. En el
artículo “Metrópolis y Gobierno de SOA” (Ver “Recursos”)
describimos en líneas generales la función que ejerce esta
plataforma en apoyo a una forma diferente de gobierno. En un
próximo artículo trataremos los desafíos analíticos implicados en el
diseño de esta plataforma para que sea alineada de forma
adecuada con una forma asimétrica de gobierno.
La asimetría del gobierno explica varias de las dificultades que
las personas han experimentado con SOA. Muchas organizaciones
tendrán demasiado que hacer a corto plazo, aún sin meterse en
éste área, pero estamos comenzando a ver organizaciones
dispuestas a tomar estos desafíos ya como parte de la empresa y
es para nosotros un placer ayudarlos.
Hasta el último período del siglo veinte se podía suponer que la
gran mayoría del tiempo invertido por una empresa sería en las
posiciones simétricas en el ciclo. Sólo la generación de nuevas
proposiciones empresariales necesitaba llevarse a cabo en el
cuadrante de destino. El desafío que presentó el siglo veintiuno es
que estas proposiciones se están revirtiendo, de manera tal, que a
pesar de que las posiciones simétricas continúan siendo
importantes al cosechar el valor de los componentes dentro de las
plataformas de los usuarios, el mayor valor se creará cada vez
más en la parte asimétrica del ciclo. Desarrollar una capacidad
asimétrica es, por lo tanto, de gran importancia para empresas
cada vez más competitivas en un mundo plano (Ver en “Recursos”
Friedman), en el que las actividades componentes se subcontratan
bajo la presión de la globalización, digitalización y la competencia
del lado de la oferta cada vez más intensa.
Sobre los autores
Philip Boxer es asesor de estrategia con sede en el Reino Unido.
Richard Veryard es escritor, asesor de gestión y analista de
tecnología con sede en Londres, Reino Unido.
 Uso de Mapas
Conceptuales en
Aplicaciones
Por Kal Ahmed y Graham Moore
Síntesis
Los mapas conceptuales proporcionan un metamodelo
bastante simple pero muy efectivo para la
representación de modelos de datos. En el artículo “Una
Introducción a los Mapas Conceptuales” (The
Architecture Journal, Nº5, 2005), presentamos la forma
en la que una combinación de mapas conceptuales y
modelos de diseño de arquitectura permiten a los
desarrolladores construir componentes reutilizables para
las aplicaciones. Ahora analizaremos brevemente
algunas de las áreas de aplicación actual y potencial
para los mapas conceptuales. Ya que los mapas
conceptuales se utilizan principalmente cuando se
integran con otros sistemas, también analizaremos el
acceso a la información de los mapas conceptuales
utilizando una variedad de arquitecturas de servicios de
red desde un RPC tradicional, interacción
cliente/servidor hasta modelos de distribución en los que
puede utilizarse tanto un modelo pull como un modelo
push para intercambiar actualizaciones en un mapa
conceptual.
El propósito principal de los mapas conceptuales es permitir la
expresión de un modelo de datos de dominio y disponer que este
modelo de datos se conecte con recursos relacionados. Dentro
de este amplio cometido podemos identificar diversas
aplicaciones comunes para los mapas conceptuales en una
empresa.
En la actualidad, la gran mayoría de las organizaciones son,
de algún modo, editores de recursos. Para algunas, la
información editorial es el negocio central y para la mayoría de
las otras organizaciones la información que publican es una
parte clave para la comunicación con sus clientes y asociados.
Los editores de información enfrentan varios problemas que
pueden tratarse con los mapas conceptuales.
Para un gran corpus, el buscador es por lo general, la única
forma para que los recién llegados encuentren lo que están
buscando. Tradicionalmente, la búsqueda estaba orientada por
palabras claves con contenido o por indexado de texto completo.
Los mapas conceptuales ofrecen la alternativa de indexar y
buscar por medio de nombres de temas, y luego utilizar las
ocurrencias de temas para presentar vínculos a todos los
contenidos relacionados a los temas encontrados en la
búsqueda. Cada tema en un mapa conceptual representa un
único concepto pero puede asignarse a nombres múltiples,
permitiendo que el mapa conceptual almacene nombres de uso
común y científico, errores ortográficos comunes o traducciones
para nombres de conceptos. Además, un mapa conceptual
también puede almacenar relaciones semánticas entre términos
que pueden dar forma a una búsqueda de diversas maneras:
1. Esta información semántica puede utilizarse para
proporcionar a los usuarios sugerencias de términos
10 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL
alternativos de búsqueda o aún para expandir de forma
transparente el término de búsqueda ingresado. Por
ejemplo, con las asociaciones adecuadas, un mapa
conceptual puede expandir un término de búsqueda tal
como “Georgian” en “Inglaterra Y Siglo XVII”.
2. La clasificación del tema o asociaciones de temas pueden
utilizarse para eliminar ambigüedades de conceptos
diferentes que aplican para el mismo término
(homónimos) basados en su contexto en el mapa
conceptual.
3. Una vez que se ha ejecutado una búsqueda que trae
múltiples recursos, pueden agruparse estos recursos de
acuerdo a su clasificación en el mapa conceptual,
permitiendo que los usuarios vean de forma más clara las
diferentes formas en las que se ha conformado su
búsqueda.
Beneficios para editores
Una ventaja clara para la optimización de la búsqueda es que
una utilidad de búsqueda que sólo consulta un mapa conceptual
es muchísimo más fácil de adaptar. Por ejemplo, si un sitio de
venta al por menor de productos eléctricos descubre que se ha
vuelto popular entre los clientes un nuevo término de búsqueda
“PVR” que se refiere a la búsqueda de grabadoras de video
para disco duro, el mapa conceptual que orienta la búsqueda
del sitio puede modificarse y agregar el término “PVR” al tema
“Grabadoras de video para disco duro”.
“LA DECISIÓN DE ARQUITECTURA CLAVE AL
IMPLEMENTAR LOS MAPAS CONCEPTUALES COMO
PARTE DE UNA SOLUCIÓN DE EDICIÓN ES LA
FORMA EN LA QUE EL SISTEMA DEL MAPA
CONCEPTUAL SE INTEGRA CON EL SISTEMA DE
GESTIÓN DEL CONTEXTO.”
El contenido relacionado con este tema no debería modificarse
en absoluto; la búsqueda del término “PVR” accederá ahora al
tema “Grabadoras de video para disco duro” y traerá recursos
relacionados.
Vincular la gestión. Una de las formas más importantes de
mantener al usuario en el sitio es presentar vínculos
relacionados que el usuario pueda seguir para encontrar más
información sobre un tema. Mantener estos vínculos de forma
manual es propenso a error y requiere el compromiso de
actualizar constantemente los vínculos o aceptar que los
contenidos más viejos tendrán los mismos vínculos que antes
para los contenidos relacionados. La naturaleza de los mapas
conceptuales como índice de recursos, permite que este tipo de
vínculos se gestione casi automáticamente.
Existen varios enfoques diferentes para presentar vínculos
relacionados utilizando mapas conceptuales, pero en esencia
todos consisten en pasar desde los recursos hasta los puntos
en el mapa conceptual donde se hace referencia a estos
recursos, y luego recorrer de alguna forma el mapa conceptual
para después extraer la lista de recursos a los que se hace
 Mapas conceptuales

referencia en el final del recorrido. Administrar los vínculos Figura 1: Muestra de la arquitectura de un sitio de Web
relacionados de esta forma dinámica posee la clara diferencia que orientado a mapas conceptuales
los vínculos relacionados están siempre actualizados; que la lista
de vínculos relacionados puede generarse en base a la indexación Usuarios de Internet
de los contenidos anteriores; y que la lógica para extraer los
Buscador Cliente rico
vínculos relacionados puede modificarse sin la necesidad de
modificar ni los recursos ni su indexación.
Admitir múltiples rutas para los contenidos. Tal como lo Creador del Servidor(es) de Internet
analizáramos en nuestro artículo anterior, los mapas conceptuales contenido Servidor Servidor
Herramientas de Web de Web Creador del
pueden utilizarse para modelar varios de las indexaciones de contenido
de creación de
contenidos tradicionales y para encontrar ayuda como por ejemplo Motor del
prototipos Herramientas de
clasificación facetada y jerárquica. De hecho, un único mapa mapa
clasificación
conceptual puede contener varios de estos índices. El uso creativo Herramientas conceptual
de los índices múltiples puede permitirle al usuario encontrar de edición
Herramientas
contenido desde varios puntos de entrada diferentes. Por ejemplo,
CMS de edición
en un sitio que publica análisis financieros, un usuario puede
encontrar un informe particular por medio de una profundización Servidores respaldados
de los sectores del mercado para una compañía y luego para el
informe o por región geográfica para un país relacionado a la
historia, o aún al recorrer temas personalizados que representan Figura 2: Muestra de la arquitectura para mapas
su propia cartera o intereses. conceptuales en Intranet
Servir al público múltiple. Los mapas conceptuales proporcionan
gran flexibilidad a aquellas organizaciones que necesitan brindar Usuarios de Intranet
acceso a diferentes niveles de usuarios. En la primera instancia, Conjunto de programas
Buscador
los conceptos pueden ser nombres determinados conocidos por de Microsoft Office
cada usuario. Por ejemplo, en un sitio que proporciona información
sobre drogas, el mapa conceptual podría proporcionar el nombre Servicios de
clínico de una droga para los médicos y la marca de la droga para Web Portal/servidor de
el paciente como nombres diferentes para el mismo tema. colaboración
Modelado de la información
Además, el mapa conceptual puede contener modelos de dominio
simplificados así como también completos que se combinan y Herramientas de
opcionalmente pueden coincidir. La característica principal de los creación de prototipos
Motor del
mapas conceptuales para soportar este requerimiento es el uso de Herramientas de mapa conceptual
un campo de aplicación para especificar el contexto en el que una edición
asociación determinada entre temas puede presentarse a un Servidor(es) Intranet
usuario.
contenido, existen dos enfoques posibles para la integración de la
Arquitecturas de aplicación información del mapa conceptual. En el primer enfoque, el sistema
La decisión de arquitectura clave al implementar los mapas de gestión del contenido (CMS) proporciona la estructura del sitio
conceptuales como parte de una solución de edición es la forma en y una o más regiones en la página dentro de las cuales se puede
la que el sistema del mapa conceptual se integra con el sistema de agregar información del mapa conceptual. En el segundo enfoque,
gestión del contexto. La integración debe considerarse desde dos se utiliza una parte del modelo de dominio del mapa conceptual
aspectos: integración de la indexación de los contenidos y creación para orientar el sitio.
de los contenidos y la publicación de la información del mapa El primer enfoque es el más apropiado para el CMS que posee
conceptual con el contenido. funciones sólidas de gestión del sitio o que utiliza una estructura
Mientras que la creación de un modelo de datos de dominio del sitio para implementar el acceso a los controles y otras
puede ser de competencia de un bibliotecario o un pequeño grupo funciones. Sin embargo, el último enfoque puede utilizarse para
de expertos de dominio, la solución de publicación debe admitir la crear una estructura del sitio flexible que pueda modificarse de
clasificación del contenido para que el modelo de dominio sea forma más fácil para considerar los cambios en la forma en la que
realizado por los responsables del contenido, ya sea autores o los índices del contenido se organizan. Además de estructurar el
editores del contenido. En el mejor de los casos, clasificar e contenido en el CMS, el motor del mapa conceptual puede
indexar el contenido en comparación con el mapa conceptual funcionar como un índice útil de todos los contenidos disponibles a
debería ser una parte requerida para la aprobación/creación del través del sitio Web. Este índice puede estar disponible para
ciclo de vida del contenido, con una revisión de la clasificación clientes ricos por medio de una interfaz de servicios Web como por
como parte del proceso editorial. Una aplicación bien diseñada ejemplo un lector RSS o un servicio de búsqueda en Microsoft
también deberá hacer uso de patrones como los que hemos Office (Ver Figura 1).
analizado en “Introducción a los Mapas Conceptuales” (Ver Los mapas conceptuales pueden admitir una aplicación de
“Recursos”). gestión de datos corporativa principalmente al proporcionar un
Los patrones permiten que un bibliotecario realice archivo que capture el modelo de datos de dominio. El
modificaciones en el modelo de dominio que reflejen los cambios metamodelo flexible que proporcionan los mapas conceptuales
en la estructura o foco del contenido sin requerir ninguna permite la introducción de nuevos tipos de conceptos y relaciones
modificación secundaria en los códigos de presentación o gestión. en el modelo de datos con el mínimo esfuerzo, posibilitando que el
Por ejemplo, los patrones para los esquemas de clasificación modelo de datos mantenga el ritmo de los cambios de la empresa.
facetada y jerárquica permiten la introducción de facetas de nueva Además de mantener el modelo de datos para el dominio, el
jerarquía o nueva clasificación en el mapa conceptual, así como mapa conceptual puede también utilizarse para indexar recursos
también que la capa de presentación los reconozca y exhiba en intranet. En este aspecto, el mapa conceptual proporciona
automáticamente. beneficios similares a los descriptos para la edición general de
La Figura 1 muestra una arquitectura por bloques simplificada recursos, pero con el desarrollo de sistemas de colaboración como
para un sitio de Web que utiliza un mapa conceptual. El mapa SharePoint, el grado de lo que puede estar disponible por medio
conceptual es administrado por un componente de búsqueda del de intranet está aumentando rápidamente. Estos sistemas
mapa conceptual que se completa con la información que el permiten que los usuarios puedan crear con más
arquitecto y el creador de contenidos generan. Al editar el

THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net 11

 Mapas conceptuales

Figura 3: Tres arquitecturas de integración de la utiliza una asociación. La segunda, es utilizando una ocurrencia
información de una empresa que indica directamente los elementos de contenido. El modelo
también puede utilizarse para levantar, dentro del mapa
(a) Push centralizado conceptual, relaciones importantes entre los elementos ajenos al
contenido que se encuentran fuera del contenido y así
Aplicación del
proporcionar un panorama general de las funciones de la
cliente
organización.
Por ejemplo, un proyecto puede tener varios participantes y
puede realizarse para un cliente en particular. Si se pone a los
Motor del mapa
conceptual
participantes y al cliente como temas en el modelo de dominio,
entonces será posible ubicar con rapidez otros proyectos para el
mismo cliente u obtener una lista de los productos con licencia
Push de datos
para ese cliente o encontrar los otros proyectos asignados a un
Sistema de datos 1 Sistema de datos 2 Sistema de datos 3 miembro del equipo.

Un mapa conceptual puede utilizarse como una base de datos

(b) Pull centralizado en sí misma. Una aplicación simple podría ser un portal en la red
Aplicación del cliente con una interfaz que permita a los usuarios crear sus propios
temas y asociaciones así como también explorar los temas y
asociaciones que han creado otros usuarios. Los usuarios podrían
Motor del mapa también agregar vínculos a recursos internos o externos como
conceptual ocurrencias, o la interfaz podría permitir que los usuarios creen o
carguen contenido en el portal mismo. De hecho, estas son todas
Pull de datos/respuesta funciones comunes de varias de las aplicaciones de edición de un
mapa conceptual genérico. Sin embargo, el mayor beneficio surge
Sistema de datos 1 Sistema de datos 2 Sistema de datos 3 cuando se integra el mapa conceptual en un

(c) Integración distribuida

Aplicación del “UNA VEZ QUE SE HAN CREADO LOS TEMAS Y
cliente AGRUPADO LOS CONTENIDOS, EL ASPECTO FINAL
PARA EL USO DE MAPAS CONCEPTUALES EN UN
Consulta/respuesta del
mapa conceptual ESCENARIO DE GESTIÓN DE DATOS CORPORATIVO
ES EL ACCESO A LA INFORMACIÓN DEL MAPA
Vista del mapa Vista del mapa Vista del mapa CONCEPTUAL.”
conceptual 1 conceptual 2 conceptual 3

sistema de colaboración que puede proporcionar gestión del

Sistema de datos 1 Sistema de datos 2 Sistema de datos 3 contenido, gestión del evento, foros de discusión y otras
funciones. Al igual que con la integración para la publicación de un
recurso, una implementación exitosa requiere que la funcionalidad
facilidad nuevos contenidos de intranet y que puedan compartir los
del mapa conceptual sea parte de la interacción normal con el
contenidos relacionados con un proyecto, pero este
sistema de colaboración.
compartimiento puede con rapidez llevar a una sobrecarga de la
intranet con contenido en el cual es difícil encontrar información
Categorizar los contenidos siempre será visto por los usuarios
relevante y es casi imposible que un nuevo visitante pueda
como una carga adicional. Esta carga puede reducirse si se utiliza
familiarizarse con él. Un índice del contenido de intranet basado en
un esquema orientado a la clasificación que minimice las
mapas conceptuales puede no sólo ayudar a que los usuarios con
decisiones que deben realizar los usuarios respecto de la
experiencia encuentren el contenido relevante sin importar su
clasificación de elementos, y también si se utiliza la topología del
ubicación, sino que también el mapa conceptual representa un
sistema de colaboración (Por ejemplo, todos los documentos que
modelo de dominio de alto nivel que puede ser útil para
se ubican en la carpeta “Proyecto X” se etiquetan
proporcionar a los nuevos visitantes un panorama general de las
automáticamente como que están relacionados al “Proyecto X”).
actividades de la organización.
Del otro lado de la ecuación, sólo una mínima cantidad de
clasificación puede generar rápidamente beneficios para los
Conexiones del contenido
usuarios si se juntan por otro lado los contenidos distintos y una
Una parte importante del problema para la gestión de datos
única persona que trabaje en la categorización de los contenidos
corporativo es que los usuarios deben trabajar con tareas que no
producidos por su proyecto o departamento, lo que puede producir
poseen una correlación uno-a-uno para un contenido. Por ejemplo,
una mejor base de datos para todos los usuarios. La naturaleza
un usuario puede trabajar en un caso o ser parte de un proyecto o
intrínsicamente flexible de la ontología basada en los mapas
de un equipo interfuncional o participar de una reunión. Todas
conceptuales hace mucho más fácil comenzar con un ámbito de
estas tareas pueden tener contenidos relacionados –notas del
trabajo limitado, centrado en lo esencial de la ontología, necesaria
caso, documentación del proyecto, minutas de la reunión y
para tratar los requerimientos de sólo ese proyecto o
demás– pero con frecuencia no poseen una identidad real en sí
departamento y luego escalar subsiguientemente en la medida que
mismas. Si bien pueden utilizarse palabras claves para conectar
el proyecto muestra un beneficio sobre la inversión.
los contenidos a estos conceptos, una simple palabra clave no le
dice nada al usuario acerca de lo que hace que el contenido sea
relevante para esta palabra clave, o respecto de las relaciones
Producir datos
entre las palabras claves.
Una vez que se han creado los temas y agrupado los contenidos,
Un mapa conceptual proporciona un modelo para definir como
el aspecto final para el uso de mapas conceptuales en un
temas los elementos ajenos al contenido, como por ejemplo
escenario de gestión de datos corporativo es el acceso a la
personas, proyectos y lugares. Una vez que se crean estos temas,
información del mapa conceptual. Este aspecto representa el
pueden conectarse con los elementos de contenido. Los mapas
punto en el que el mapa conceptual puede realmente destacarse.
conceptuales proporcionan dos formas de conexión a los
El mapa conceptual proporciona un modelo de dominio
contenidos. La primera es creando un segundo tema que
estructurado de alto nivel que se comunica con facilidad dentro de
representa el contenido y luego

12 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL


la interfaz del servicio de red, proporcionando un enorme potencial
para la integración dentro de las aplicaciones de escritorio. Por
ejemplo, recientemente hemos desarrollado un servicio Web que
implementa la interfaz del servicio de búsqueda de Microsoft Office
para proporcionar al usuario la posibilidad de buscar y consultar un
mapa conceptual desde Internet Explorer y sus aplicaciones Office.
La Figura 2 muestra una posible arquitectura para este tipo de
aplicaciones de base de datos. El diseñador de información
configura la taxonomía básica y los esquemas de clasificación para
la base de datos. Los usuarios entonces trabajan con el servidor
de colaboración y generan y extienden esta taxonomía a través de
un explorador o interfaces de cliente rico.
Similares posibilidades de integración están disponibles si se
utilizan etiquetas inteligentes e interfaces del servicio más
detalladas como las que se describirán más adelante. Estas
integraciones permiten que la información de un mapa conceptual
sea enviada directamente a la aplicación en la cuál son más útiles.
Además, el modelo de dominio para la gestión de la base de datos
interna puede también utilizarse como punto de partida para
integrar la información desde otros sistemas de la empresa tal
como lo explicaremos en breve.
Los mapas conceptuales se utilizan más frecuentemente como
un complemento para el CMS, lo cual no es de extrañarse, dado
los servicios que aportan en cuanto a contenido, organización,
indexado y búsqueda. No obstante, los mapas conceptuales
pueden también utilizarse como base para la integración de todo
tipo de fuentes de datos.
Servicio Web de un mapa conceptual simple
Si bien es posible que las aplicaciones generen datos del mapa
conceptual, el tipo de aplicaciones que pueden crear o consumir
esta fuente de datos es limitado. La idea del servicio de red es
ofrecer los mapas conceptuales a más aplicaciones sin tener en
cuenta si publican o consultan información. Además, un servicio
Web bien definido proporciona una valiosa concordancia para la
aplicación en la que interactúan los servicios de bases de datos.
El servicio Web que se presenta aquí está compuesto de un
pequeño conjunto de métodos genéricos para asegurar que pueda
utilizarse en una gran variedad de soluciones de mapas
conceptuales. Se describen brevemente los métodos del servicio
Web y se proporciona un comentario sobre su aplicabilidad y uso
pretendido. Esta interfaz la implementa Networked Planet’s Tepic
Map Web Service WSDL (Ver “Recursos”), quien también utiliza
dos métodos adicionales que permiten un acceso más directo a
cualquier jerarquía contenida en el mapa conceptual.
GetTopicMapNames()- Un sistema de mapa conceptual puede
almacenar y administrar varios mapas conceptuales. Esta
operación devuelve una lista de nombres de los mapas
conceptuales que se encuentran disponibles en ese momento.
Además, es posible tener este servicio agregado o actuar como un
agente sobre múltiples mapas conceptuales distribuidos. Este
método proporciona una forma de averiguar qué mapas
conceptuales están disponibles.
GetTopic(TopicMapName, TopicId)- Esta operación devuelve
una serialización de temas particulares desde los mapas
conceptuales nombrados. La serialización proporciona a quien
realiza el pedido, la información suficiente para que pueda recorrer
temas relacionados.
GetTopicTypes(TopicMapName)- Esta operación devuelve
una serialización de subgráficos de un mapa conceptual en el que
cada tema que sirve como tipo de uno o más temas en el mapa
conceptual particular está totalmente serializado.
GetTopicBySubjectIdentifier(TopicMapName, Identifier)-
Esta operación devuelve un subgráfico de un mapa conceptual en
particular, en el que el tema con el identificador particular como su
identificador del tema, está totalmente serializado.
THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net
Mapas conceptuales
La clave para integrar la información empresarial con el uso de
mapas conceptuales reside en definir una ontología central y luego
asignar información a esa ontología desde cada sistema de datos.
Por ejemplo, una ontología puede contener los conceptos de un
Cliente y una Orden, pero es el Sistema de Gestión de Relación
con el Cliente (CRM) el que contiene la información de las
llamadas del cliente a la mesa de ayuda y el sistema de registro de
órdenes el que contiene información acerca del estado de las
órdenes del cliente. Una forma para la integración de estos
sistemas basados en mapas conceptuales podría ser centralizada o
distribuida. Estas diferentes formas de integración se muestran en
la Figura 3.
En un sistema centralizado, cada sistema de datos proporciona
información a los mapas conceptuales acerca de las entidades que
administra. La información puede publicarse por medio de un push
del sistema de datos (Ver punto “a” en la Figura 3) o puede
actualizarse utilizando un pull desde la aplicación de gestión del
mapa conceptual central (Ver punto “b” en la Figura 3). Otras
aplicaciones pueden entonces consumir esta información
centralizada como temas, asociaciones y ocurrencia, limitando por
lo tanto a las aplicaciones del consumidor de la necesidad de
conocer las interfaces requeridas para la comunicación con cada
sistema externo. En estos sistemas, la duplicación de la
información debe tratarse con cuidado para asegurar que sea clara
en el lugar que se encuentra el original de cada elemento de
datos.
GetTopicByType(TopicMapName, TopicTypeId)- Esta
operación permite a los usuarios traer una lista de todos los temas
que son instancias de un tipo determinado. El valor de devolución
es un subgráfico del mapa conceptual con cada instancia del tema
totalmente serializada.
DeleteTopics(TopicMapName, TopicId[])- Esta operación
especifica el único identificador del tema de uno o más temas para
que sean eliminados desde un mapa conceptual en particular.
SaveTopic(TopicMapName, TopicMapFragment)- Esta
operación puede ser utilizada tanto para actualizar un tema
existente como para incorporar nuevos temas. La información del
mapa conceptual que está contenida en el parámetro del
TopicMapFragment actúa como la versión definitiva de temas y
asociaciones. Para reemplazar un tema o asociación existente,
esta estructura en el parámetro del TopicMapFragment debe llevar
el identificador único de la estructura que se reemplazará.
Cualquier tema o asociación en el parámetro del
TopicMapFragment que no lleve un único identificador se agrega
como información nueva al mapa conceptual.
Query(QueryName, QueryParams[])- El servicio Web no
permite la ejecución de consultas arbitrarias desde los mapas
conceptuales. Por el contrario, el administrador o desarrollador
puede configurar cualquier cantidad de consultas determinadas
que son accesibles a través del servicio Web API. Esta operación
invoca la consulta nombrada, incorporando parámetros que se
utilizan como reemplazos del valor directo en una cadena de
consultas. La estructura del XML devuelta por método depende de
la estructura de la tabla de resultados devuelta por la consulta.
La característica clave de esta interfaz es que está casi
completamente centrada en el tema. Todas las operaciones se
encuentran en los temas y devuelven temas o listas de temas. Al
utilizar las técnicas de serialización descriptas aquí, es posible
implementar este servicio Web utilizando un enfoque centrado en
el documento con datos XML que se procesa con facilidad si se
utilizan enlaces de datos XML o conjuntos de herramientas XPath.
13
 Mapas conceptuales
Figura 4: Arquitectura de agente de un mapa conceptual
Aplicación del cliente
Agente del mapa
conceptual
Motor del mapa Motor del mapa
conceptual A conceptual B
Figura 5: Ejemplo de una arquitectura de sindicación para
mapas conceptuales
Aplicación del cliente
4
Motor del mapa Motor del mapa
conceptual A conceptual B
1 3
Motor del mapa Motor del mapa
conceptual A conceptual B
2 acerca del mismo concepto y utilizar el identificador del concepto
servidor de cliente de
sindicación sindicación
En un sistema distribuido, cada sistema de datos posee un
componente de integración que expone una interfaz del mapa
conceptual, y los usuarios se ponen en contacto con el sistema por
medio de la interfaz (Ver parte “c” en la Figura 3). Nuevamente,
los consumidores sólo necesitan comprender una interfaz, pero en
este caso, las llamadas a la interfaz del mapa conceptual podrían
traducirse directamente en consultas y las actualizaciones desde el
sistema de información subyacente, lo que significa que no existe
duplicación de datos pero podría llevar a una tarea de integración
más demandante.
Identificación y URLs
Tanto en un sistema distribuido como en uno centralizado, es
necesario hacer un fuerte énfasis sobre la identificación de las
entidades que administra cada sistema. Es un asunto simple
asignar identificadores únicos a la entidad en un Identificador de
Recursos Uniforme (URI) como por ejemplo un número de cuenta
del cliente o un número de registro de órdenes para el tema que
representa una cuenta u orden, y con un poco de atención, los
identificadores pueden ser configurados de manera tal que exista
un algoritmo común para la conversión entre los URIs y los
identificadores específicos de la entidad.
El principal beneficio al utilizar un mapa conceptual para este
tipo de ejercicio de integración es la flexibilidad con la que permite
el modelado de datos integrados. Debido a que el modelo en un
mapa conceptual es simplemente de datos y no un esquema para
cualquier sistema subyacente, se pueden introducir nuevos tipos
de entidades sin la necesidad de alterar ninguna de las interfaces
existentes. Además, al representar entidades empresariales
centrales como temas en una ontología corporativa, se torna
mucho más clara la forma de producir e integrar datos desde los
sistemas de información empresarial en un sistema de gestión de
datos o aún, cuando sea adecuado, fuera de la Web.
Todas las aplicaciones que utilizan mapas conceptuales,
incluyendo todas las que presentamos anteriormente, requieren
algún método para acceder a la información del mapa conceptual.
La mayoría de las aplicaciones también requieren un
almacenamiento persistente para los datos del mapa conceptual y
una Interfaz de Programas de Aplicación (API) en proceso para
acceder y manipular estos datos, pero esto va
14 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL
más allá del alcance de este análisis. Lo que es más interesante
para el diseño de soluciones es la capacidad de acceder a la
información de los mapas conceptuales por medio de llamadas de
servicios Web. Los mapas conceptuales poseen diversas
propiedades que los hacen altamente favorables para el acceso por
medio de servicios Web. Analicémoslas brevemente.
Direccionabilidad de los temas. Se puede asignar a los temas
identificadores únicos en el servidor (o, si es necesario, únicos a
nivel global). La propiedad de direccionabilidad de los temas nos
permite construir aplicaciones de cliente que pueden registrar la
procedencia de la información del tema que consumen. La
capacidad de dirección de los temas también nos permite recorrer
información tipográfica o de asociación en la representación de un
tema. Por ejemplo, una consulta de un cliente puede recuperar el
tema A con una ocurrencia insertada por un tema T. Una segunda
consulta de un cliente puede recuperar toda la información para el
tema T. En la muestra del servicio Web descripto en la tabla bajo
el título “Servicio Web de un Mapa Conceptual Simple”, los temas
pueden ser recuperados por su identificador único utilizando el
método GetTopic().
Direccionabilidad del concepto. Los conceptos que representan
los temas pueden ser asignados por separado a identificadores
únicos, permitiendo realizar una consulta desde múltiples
servidores de información relacionada a un concepto específico. La
capacidad de dirección del concepto es la clave para soportar el
mantenimiento y creación distribuida de los mapas conceptuales y
las agregaciones subsiguientes de información en esos mapas.
Debido a que puede asignarse a un concepto (por ejemplo
Persona, Lugar, Fred Jones o Birmingham) su propio URI separado
del identificador del sistema del tema que representa ese
concepto, los sistemas múltiples pueden proporcionar información
como la clave utilizada en las agregaciones.
Por ejemplo, una consulta de un cliente puede devolver un tema
T con un identificador del asunto I. El cliente puede después
“LOS CONCEPTOS QUE REPRESENTAN LOS TEMAS
PUEDEN SER ASIGNADOS POR SEPARADO A
IDENTIFICADORES ÚNICOS, PERMITIENDO
REALIZAR UNA CONSULTA DESDE MÚLTIPLES
SERVIDORES DE INFORMACIÓN RELACIONADA A UN
CONCEPTO ESPECÍFICO”.
consultar un segundo servidor del mapa conceptual para cualquier
tema con el identificador del asunto I y de esta forma ampliar la
cantidad de información conocida acerca del concepto
representado por el identificador. La ventaja de la direccionabilidad
del concepto es que la aplicación del cliente no necesita conocer el
identificador específico del sistema del tema que posee el
identificador del asunto I. En la muestra del servicio Web, esta
forma de direccionabilidad es provista por el método
GetTopicBySubjectIdentifier() (Ver la Tabla bajo el título “Servicio
Web de un mapa conceptual simple”).
Temas literales de un documento. Los temas pueden convertirse
con facilidad como estructuras de información que utilizan
identificadores de temas únicos a nivel global o hipervínculos para
representar la relación entre ellos. En términos SOAP, esto
significa que podemos proporcionar una simple representación
literal de un documento de un tema. Si la metodología de los
servicios Web preferida es la Transferencia de Estado
Representacional (REST), es posible construir la representación de
un tema como un documento hipervinculado que se ha sido
enviado como respuesta a una consulta REST. En breve
describiremos el algoritmo para la producción de esta
representación.
Normas para la combinación estándar. Las normas de
combinación de los mapas conceptuales pueden utilizarse para
combinar información sobre un tema recibida desde múltiples
fuentes por separado en un único mapa conceptual en
funcionamiento. Para los consumidores de mapas conceptuales,
las normas de combinación permiten al consumidor utilizar la
direccionabilidad de un concepto para encontrar toda la
información relacionada a un

Figura 6: Serialización del subgráfico de un mapa
conceptual
(a) Serialización con magnitud = 0
Tema completamente
serializado
Tema parcialmente
serializado
Tema no serializado
(b) Serialización con magnitud = 1
Límite del subgráfico
serializado
concepto y después combinar esta información en un único tema
que se presenta en los niveles más altos de la aplicación. Esta
combinación permite que el cliente agregue información desde
múltiples fuentes de mapas conceptuales, y luego presente una
interfaz que muestre que toda esa información proviene de una
única fuente. Las normas de combinación también permiten que la
direccionabilidad del concepto sea tomada un paso más adelante
ya que permite que un mapa conceptual declare que dos
conceptos son equivalentes simplemente incluyendo la dirección
de cada concepto en un único tema.
Por ejemplo, un cliente puede consultar información relacionada
a un concepto que posee el identificador I, el mapa conceptual
devuelve un tema T que tiene los identificadores I e I’ como sus
identificadores del tema, lo que dice al cliente que la fuente
reafirma que el concepto identificado por I es el mismo que el
concepto identificado por I’. Si el cliente confía en la fuente para
que realice este tipo de afirmación, entonces procederá a consultar
cualquier tipo de información relacionada al concepto que posee el
identificador I’ y combinará esto con la información que ya ha
recibido para el concepto que posee el identificador I.
Los mapas conceptuales pueden utilizarse muy fácilmente con
casi cualquier arquitectura de acceso de un cliente. Analizaremos
tres arquitecturas comunes: arquitecturas: cliente/servidor,
agente y sindicación.
La más simple de las arquitecturas de acceso de mapas
conceptuales es la arquitectura cliente/servidor que hace uso de
una interfaz de servicio Web que expone operaciones para
explorar, consultar y actualizar el mapa conceptual. (Consultar la
tabla bajo el título “Servicio Web de un Mapa Conceptual Simple”
para ver la descripción de una posible interfaz que contiene sólo
ocho métodos). Ya que los mapas conceptuales se pueden publicar
con facilidad en forma seriada como XML, no tiene sentido utilizar
SOAP, REST o aún XML-RPC para implementar esta interfaz.
La arquitectura de agente interpone uno o más servidores
adicionales entre la(s) fuente(s) de la información del mapa
conceptual y los consumidores (Ver Figura 4). Un agente agrega
resultados desde diversos servidores realizando cualquier
combinación necesaria y respondiendo al cliente como si la
información hubiera venido desde un único mapa conceptual. Las
agregaciones realizadas por el agente pueden variar desde
simplemente distribuir una operación y agregar los resultados a
agregaciones más complejas en base a los indentificadores del
THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net
Mapas conceptuales
tema devueltos por las diversas fuentes de los mapas
conceptuales.
Arquitectura de sindicación
La arquitectura de sindicación utiliza REST para distribuir los
cambios en un modelo de mapa conceptual. El servidor que
mantiene el modelo simplemente escribe los cambios como
documentos de transacciones que contienen subgráficos de mapas
conceptuales serializados. Estos documentos de transacciones son
entonces levantados por los consumidores y aplicados a su caché
local del modelo. Las arquitecturas de sindicación funcionan
particularmente bien para la distribución de mapas conceptuales
ontológicos que son relativamente estables o para la distribución
de mapas conceptuales que indexan contenido publicado para un
programa regular (por ejemplo, la actualización de un sitio Web de
noticias). La serialización XML de subgráficos de mapas
conceptuales significa que esta arquitectura puede utilizar las
normas de serialización, como por ejemplo ATOM o RSS 2.0 para
distribuir la información de la transacción.
“EL MAPA CONCEPTUAL PROPORCIONA UN MODELO
DE DOMINIO ESTRUCTURADO DE ALTO NIVEL QUE
SE COMUNICA CON FACILIDAD DENTRO DE LA
INTERFAZ DEL SERVICIO DE RED,
PROPORCIONANDO UN ENORME POTENCIAL PARA
LA INTEGRACIÓN EN APLICACIONES DE
ESCRITORIO”.
La Figura 5 muestra un ejemplo de la forma en la que el
sistema de sindicación puede funcionar para mantener
sincronizados dos mapas conceptuales que manejan dos motores
diferentes.
1. Un cambio que se realiza en el motor A de un mapa
conceptual se escribe como un documento XML en el servidor
de sindicación. El servidor de sindicación realiza un suministro
de los documentos de transacciones recientes disponibles
para los clientes de sindicación.
2. Los clientes de sindicación verifican el suministro en el
servidor de sindicación y solicitan la(s) transacción(es) que
necesitan aplicar.
3. El cliente de sindicación procesa los documentos recibidos de
las transacciones desde el servidor de sindicación y aplica los
cambio en el motor B del mapa conceptual.
4. Los clientes interactúan con el mapa conceptual actualizado
en el motor B del mapa conceptual, que está ahora
actualizado con el último estado de datos del mapa
conceptual que se encuentra en el motor A del mapa
conceptual.
El paso 2 puede también realizarse por medio de un push de la
información de la transacción sindicada desde el servidor de
sindicación para el cliente; el mecanismo utilizado dependerá de
los requerimientos de la aplicación y de las utilidades provistas por
el mecanismo de sindicación utilizado.
Las aplicaciones que acceden a los mapas conceptuales, con
frecuencia requieren un conjunto de resultados que consiste de un
único tema (o una lista de temas) que coincide con una consulta.
Sin embargo, el modelo del mapa conceptual es básicamente un
modelo de un gráfico en el que los temas están conectados ya sea
por asociaciones o por medio de relaciones de clasificación, por lo
tanto al devolver un tema, es necesario que el servidor
proporcione algún contexto para el cliente. Esencialmente, se
requiere que un servidor extraiga un subgráfico desde el gráfico de
un mapa conceptual.
Serialización de los mapas conceptuales
En nuestra experiencia, la mejor forma de llevar a cabo la
serialización es comenzar con el concepto de dos tipos de
serialización de un tema. Una serialización completa presenta toda
15
 Mapas conceptuales
la información directamente conectada a un tema: sus tipos,
identificadores, nombres, ocurrencias, y todas las asociaciones en
las cuales participa. Una serialización parcial presenta un conjunto
mínimo de información que puede ser utilizada por el cliente.
Exactamente el tipo de información que está presente en una
serialización parcial puede variar de una implementación a otra,
para algunas implementaciones sólo un único indentificador del
tema puede ser suficiente, pero otras implementaciones pueden
requerir la presencia de todos los identificadores sobre un tema
más un nombre o ocurrencia del tema seleccionado de acuerdo a
algunos algoritmos. La guía principal para determinar lo que está
presente en un tema parcialmente serializado es que una
serialización parcial no debe contener ninguna referencia a otros
temas; de este modo, los temas parcialmente serializados forman
las hojas del subgráfico devuelto por una serialización
Con estas dos definiciones, la extracción de subgráficos es una
tarea relativamente simple. Para extraer un pequeño subgráfico
centrado en un tema, se debe realizar una serialización total de
ese tema. Para cada tema al que el tema totalmente serializado
hace referencia, se crea un enlace de serialización del tema, y se
reemplaza la referencia con una referencia para el enlace.
Subgráficos más grandes pueden ser extraídos al especificar un
parámetro que defina el número máximo de asociaciones a
recorrer. Cada tema que pueda ser obtenido al recorrer un número
de asociaciones hasta el parámetro desde el tema de inicio, debe
ser totalmente serializado, y todos los otros temas a los que se
hace referencia, deben ser serializados como enlaces. La Figura 6
muestra un ejemplo de la serialización de un subgráfico de un
mapa conceptual utilizando dos magnitudes diferentes de
subgráficos.
Recursos
“Mapas Conceptuales ISO/IEC 13250”, Segunda edición (2002)
www.y12.doe.gov/sgml/sc34/document/0322_files/iso13250-2nd-
edv2.pdf
“Tecnología de la Información ISO/IEC JTC1/SC34 — Descripción
del documento e idiomas de procesamiento”
www.isotopicmaps.org/sam/sam-xtm/
Networked Planet
Servicios Web para Mapas Conceptuales
www.networkedplanet.com/technology/webservices/intro.html
Servicios Web WSDL para Mapas Conceptuales
www.networkedplanet.com/2005/01/
webservices/tmservice/TMService.wsdl
“Artículo Técnico: Mapas Conceptuales en la Arquitectura de un
Sitio Web”, (Networked Planet Ltd., 2005)
www.networkedplanet.com/download/tm-website-architecture.pdf
Techquilla
“TMShare – Intercambio de un fragmento de un mapa conceptual
en una aplicación punto-a-punto”, Kal Ahmed
www.techquila.com/topicmapster.html
XTM TopicMaps.org
XML Topic Maps (XTM) 1.0
www.topicmaps.org/xtm/1.0/
16 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL
La parte “a” de la Figura 6 muestra que la serialización de un tema
A se realiza con una magnitud de 0, por lo tanto, sólo el tema A
está totalmente serializado. Sin embargo, para serializar las
asociaciones en las que participa el tema A, cada uno de los temas
B, C y D deben serializarse parcialmente. Se debe tener en cuenta
que el tema C posee una asociación para el tema D, pero debido a
que C está parcialmente serializado, esta asociación no es parte
del subgráfico serializado a pesar de que sus objetivos lo son. La
parte “b” en la Figura 6 muestra la serialización de un tema A con
una magnitud de 1. En esta serialización, el tema A y todos los
temas que pueden ser alcanzados al recorrer una asociación que
comienza desde el tema A (es decir, temas B, C y D) están todas
“EN NUESTRA EXPERIENCIA, LA MEJOR FORMA DE
LLEVAR A CABO LA SERIALIZACIÓN ES COMENZAR
CON EL CONCEPTO DE DOS TIPOS DE
SERIALIZACIÓN DE UN TEMA. UNA SERIALIZACIÓN
COMPLETA PRESENTA TODA LA INFORMACIÓN
DIRECTAMENTE CONECTADA A UN TEMA”.
totalmente serializadas. Para realizar la serialización total del tema
B, el tema E debe estar totalmente serializado, y para realizar la
serialización total del tema C, los temas F y G deben ser
serializados. El tema C está sólo conectado con temas que están
totalmente serializados, por lo tanto, no se necesita información
adicional para serializar la asociación en la cual participa.
Una vez que se ha identificado el subgráfico del mapa
conceptual que se desea extraer, todo lo que resta es serializar los
datos en este subgráfico como XML. A pesar de que las normas de
los mapas conceptuales definen una sintaxis de intercambio XML,
ésta es una sintaxis mejor adaptada para la creación e intercambio
de todos los temas y no proporciona ninguna sintaxis para la
distinción entre temas serializados parcial o totalmente. Por lo
tanto es necesario definir un esquema separado para la
serialización de los subgráficos de los mapas conceptuales. Al
diseñar nuestro propio esquema (www.networkedplanet.com/2005
/01/topicmap/data/TopicMapFragment.xsd) también nos dimos la
oportunidad de simplificar la sintaxis XML para eliminar utilidades
de conveniencia de creación, lo que resultó en un esquema que
puede ser procesado con más facilidad con herramientas de enlace
de datos XML y XSLT/XPath.
Sobre los autores
Kal Ahmed es cofundador de Networked Planet Limited
(www.networkedplanet.com), es desarrollador de herramientas de
mapas conceptuales y aplicaciones basadas en mapas
conceptuales para la plataforma .NET. Ha trabajado por diez años
en la gestión de información XML y SGML, tanto en el desarrollo de
software como en la asesoría, y en el Juego de Herramientas de
Código Abierto en Java para mapas conceptuales, TM4J, así como
también ha contribuido en el desarrollo de las normas ISO.
Graham Moore es cofundador de Networked Planet Limited y se
ha desempeñado durante ocho años en áreas de información,
contenido y gestión de datos como desarrollador, investigador y
asesor. Ha sido el CTO de STEP, vicepresidente de investigación y
desarrollo de empolis GmbH y Jefe Científico en Ontopia AS.
 Diseño e implementación
de una fábrica de
Software
Por Mauro Regio y Jack Greenfield

Síntesis

En esta arquitectura para la interoperabilidad
compartimos la experiencia obtenida en el diseño e
implementación de una fábrica de Software para un
sistema del cuidado de la salud basado en el estándar HL7
[Health Level Seven]. Analizamos la visión a largo plazo y
una prueba más focalizada del concepto en el desarrollo.
También definimos los desafíos con los cuales nos
encontramos en nuestro proyecto y las oportunidades
para ampliar el alcance de la arquitectura para las
diferentes industrias y por lo general, las oportunidades
para admitir una colaboración interempresarial.
El objetivo aquí es compartir la experiencia obtenida al diseñar e
implementar una fábrica de software basada en el HL7, un
estándar para la interoperabilidad de las organizaciones del
cuidado de la salud. Comenzamos el trabajo hace casi un año
atrás con las especificaciones de alto nivel de la fábrica,
produciendo una primera versión de la arquitectura de solución y
su sistema (Ver “Recursos”).
En esta etapa inicial, la fábrica apuntaba al diseño de puertos de
colaboración del HL7, que son sistemas diseñados para ser
implementados en la periferia de los sistemas IT de las
organizaciones del cuidado de la salud y le permiten a las
aplicaciones del cuidado de la salud colaborar conforme a los
protocolos técnicos y empresariales estandarizados en la versión 3
del HL7, utilizando un infraestructura de comunicación basada en
un servicio Web.
En la segunda etapa, implementamos una primera –más
focalizada– versión de la fábrica del HL7 especificada en la primera
etapa. El objetivo de esta versión es un subconjunto de las
capacidades de los puertos de colaboración del HL7 necesario para
permitir la comunicación entre las aplicaciones del cuidado de la
salud por medio de adaptadores del servicio Web, conforme a los
perfiles del servicio Web del HL7 (Ver “Recursos”).
El ámbito completo de la fábrica, tal como se ha especificado,
también incluía el desarrollo de adaptadores de integración de las
aplicaciones empresariales para conectar las aplicaciones
existentes con puertos de colaboración y la organización del

Figura 1: Contexto de producción de la fábrica del HL7

Hospital Laboratorio

Destino de la
fábrica de so
Puerto de colaboración

Puerto de colaboración

ftware
de los HL7

Sistema de Sistema de
información del colaboración información del
hospital laboratorio

Infraestructura de comunicación del servicio de

Web estandarizado

Contexto del sistema Contexto del sistema

de información del de información del
hospital laboratorio
Soporte V2 HL7 Direccionamiento

Soporte V3 HL7 Mensajería confiable

Soporte servicio Web Seguridad

Comunicación basada en el
archivo
Comunicación de la base
de datos

18 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL

 Fábrica de Software

Figura 2: Contexto de desarrollo de una fábrica para el HL7

Repositorio Entra a
Creación de la
Entra a Capacidades
de la V3 HL7 fábrica de de la Arquitectura
Especificaciones software HL7 plataforma de referencia
adicionales para la
solución
Produce Feedback
Perfiles de Patrones de
servicios de códigos
Web de la V3 HL7 Desarrollo del
Entra a puerto de
Conocimientos acerca de dominios Conocimientos acerca de dominios
colaboración
problemáticos de soluciones
HL7

Produce / Implementa
Plantillas Orientación
Herramientas
de código del proceso

Formulas / Secuencia de
DSLs Patrones Código fuente comandos de
Asistentes Componentes
prueba del tiempo de
Componentes Configuración
Modelos de ejecución
Marcos del tiempo de Modelos Otro del puerto de
rasgos
ejecución colaboración
Modelo de la Fábrica de Software HL7 Artefactos de los puertos de colaboración del HL7

intercambio de mensajes de la empresa realizando una interfaz del usuario o una capa de acceso a una base de datos, o
colaboración en particular en representación de las aplicaciones de tal vez toda una aplicación en un dominio empresarial como por
la línea del negocio que no han sido diseñadas para colaborar. ejemplo el cuidado de la salud o la seguridad nacional. La plantilla
Nuestra experiencia al diseñar y desarrollar la fábrica del HL7 hade la fábrica de software se organiza por medio de un modelo
sido valiosa desde dos perspectivas. Al crear la fábrica del HL7 nos llamado sistema de la fábrica de software. El sistema define uno o
encontramos con algunos desafíos para desarrollar su sistema, más puntos de vista que son relevantes para las partes
administrar su configuración, comprender la forma en que se interesadas en la producción de la solución de software deseada.
utilizarían lenguajes específicos de dominio y nivelar las Cada punto de vista define artefactos del ciclo de vida producidos
herramientas disponibles en ese momento en el contexto de o consumidos por los interesados, las actividades que ellos
desarrollo. realizan con estos artefactos y los bienes reutilizables disponibles
Al mismo tiempo, nos dimos cuenta que la delimitación de la para soportarlos al realizar estas actividades.
fábrica podía ampliarse desde la colaboración entre aplicaciones La metodología de la fábrica de software integra el Desarrollo
del cuidado de la salud basadas en el HL7 hacia una noción más Orientado por un Modelo (MDD), el Desarrollo Basado en el
genérica de colaboración entre las aplicaciones basadas en Componente (CBD) y las prácticas de desarrollo ágil, incluyendo el
especificaciones estándares (o compartidas). uso de patrones y lenguaje de patrones con modelos, marcos y
Por lo tanto, estamos actualmente en el proceso de herramientas (Ver “Recursos”).
generalización del sistema probado en la implementación inicial de Para nivelar los modelos de forma efectiva para las varias
la fábrica del HL7 para diseñar y construir lo que hemos llamado la formas de automatización, las fábricas de software hacen gran uso
fábrica de colaboración empresarial. de los lenguajes específicos de dominio (DSLs). La tecnología DSL
es mucho más nueva que varias de las otras tecnologías utilizadas
Fábricas de Software en las fábricas de software, y depende de familias de lenguajes
Las fábricas de Software utilizan conocimientos de dominio extensibles. Sin embargo, los marcos y herramientas de creación
específicos, arquitecturas de solución, herramientas y otros activos del DSL han estado en desarrollo por algún tiempo en los grupos
reutilizables para ayudar a sus usuarios a producir tipos académicos, y han comenzado a aparecer recientemente en forma
específicos de soluciones de software. Una fábrica de Software se comercial (Ver “Recursos”).
basa en tres puntos claves: un sistema para la fábrica de software, La fábrica del HL7 automatiza el desarrollo de los sistemas
una plantilla para la fábrica de software y un entorno de desarrollo llamados puertos de colaboración, que permiten la interoperación
extensible. entre sistemas en el dominio del cuidado de la salud. En especial,
La fábrica de software configura el entorno de desarrollo las soluciones producidas por la fábrica apuntan a:
extensible, como por ejemplo Eclipse, Borland Jbuilder o Microsoft
Visual Studio Team System (VSTS), utilizando un paquete de • Realizar las interacciones definidas por los estándares del HL7
instalables llamado plantilla de la fábrica de software o paquete de como intercambio de información que se lleva a cabo entre los
instrucciones. Si se configura de esta forma, el entorno de roles de una aplicación en respuesta a eventos que se
desarrollo se vuelve una utilidad especializada que acelera el desencadenan. Conjuntamente, estos intercambios admiten las
desarrollo de un tipo específico de solución de software, como una metas de la empresa de una caso de uso específico, como por
ejemplo realizar una observación de un laboratorio. La fábrica

THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net 19

 Fábrica de Software

Figura 3: Punto de vista de producción del sistema.
Ingeniería del sistema
Requisitos de Requerimientos
la empresa del sistema
Desarrollo del sistema
Diseño del
contrato de
software
Diseño del
sistema de la
empresa Desarrollo de Diseño del
la aplicación sistema
Ingeniería del
proyecto
automatiza la producción de un código que implementa estas
interacciones al buscar la información contenida en el Modelo de
Información de Referencia del HL7 [HL7 Reference Information
Model-HL7 RIM].
• Permite la colaboración empresarial aplicación-a-aplicación
expresada en base a estas interacciones sobre una
infraestructura de un servicio Web basado en estándares que
son compatibles con un subconjunto de perfiles del servicio Web
de la V3 del HL7, a saber, los temas básicos, de
direccionamiento, seguridad y mensajería confiable (Ver
“Recursos”).
• Permite la integración de aplicaciones nuevas o existentes que
no fueron diseñadas para: 1) la versión 3 del HL7; 2) para
cumplir con la colaboración empresarial; y 3) para comunicarse
sobre una infraestructura de un servicio Web.
Es importante comprender que la fábrica del HL7 forma dos
perspectivas diferentes: producción y desarrollo. En el contexto de
la producción, los productos finales de la fábrica son los puertos de
colaboración del HL7. Estos puertos permiten automáticamente
que las distintas aplicaciones del cuidado de la salud colaboren
detrás y a través de servidores de seguridad utilizando servicios
Web, siempre y cuando, al menos una de la aplicaciones que
participa en la colaboración empresarial implemente un puerto de
colaboración del HL7, las otras aplicaciones pueden participar a
través de otros medios, y todas las aplicaciones que participan en
la colaboración empresarial conformarán los estándares del HL7
para el intercambio de mensajes, ya sea de forma nativa o con la
ayuda de un puerto de colaboración del HL7.
La fábrica a través de un modelo
La Figura 1 muestra la colaboración empresarial entre el sistema
de un laboratorio y un hospital, en el que los puertos de
colaboración del HL7 se colocan en relación a los sistemas que
Figura 4: Punto de vista del diseño del contrato de software
Desarrollo de la Diseño del
aplicación sistema
Diseño del contrato de servicios de Web:
Diseño del contrato del Software
Diseño del
Diseño XSD contrato del
servicio Web
hostean las aplicaciones que interoperan. Observen que los
puertos de colaboración están hechos para ser altamente
configurables y permitir el despacho general, mientras que
también permiten la organización del flujo de mensajes complejos.
Por lo tanto, los puertos que se muestran en la Figura 1 están
configurados teniendo en cuenta tanto los detalles técnicos para
una determinada implementación y utilización según los niveles de
conformidad y definiciones de dominio del HL7.
En el contexto del desarrollo, el propósito de la fábrica de
Implementación
software es acelerar la especificación e implementación de puertos
del sistema
de colaboración. La fábrica combina los conocimientos acerca de
dominios problemáticos provistos por los perfiles del servicio Web
Operación y el modelo de información de referencia del HL7, con el
del sistema conocimiento de la tecnología de plataforma, arquitectura de
solución y el proceso de desarrollo suministrado por la
documentación de la plataforma y los desarrolladores de la fábrica
(Ver Figura 2).
Tal como lo sugiere la ilustración, este conocimiento se
empaqueta en numerosos bienes que forman en conjunto el
modelo de la fábrica. Dicho simplemente, el modelo de la fábrica
ofrece todo lo requerido para construir el puerto de colaboración
del HL7, incluyendo información de referencia y artefactos, como
por ejemplo sistemas de mensajes; herramientas, como
generadores de adaptadores; y orientación para el proceso. El
modelo de la fábrica debe instalarse en un Entorno de Desarrollo
Integrado (IDE), es decir, Microsoft Visual Studio 2005 Team
System, antes de que pueda utilizarse para producir e
implementar los puertos de colaboración del HL7. Tal como se
observó anteriormente, el propósito aquí es describir lo aprendido
al especificar, diseñar e implementar la fábrica del HL7. Hemos
agrupado la información en dos categorías. La primera clasifica las
lecciones aprendidas acerca de
“NECESITAMOS PROPORCIONAR ARQUITECTOS
EMPRESARIALES JUNTO CON LOS MODELOS Y
HERRAMIENTAS NECESARIAS PARA SOPORTAR EL
PROCESO DE ESPECIFICACIÓN”.
la creación de la fábrica y el uso en general; la segunda contiene
puntos de vista obtenidos respecto al dominio objetivo y con la
forma en que la fábrica puede ser generalizada para dirigirse a un
conjunto más amplio de dominios objetivo.
La creación y gestión del sistema de la fábrica fueron los
desafíos más significativos desde el comienzo del proyecto hasta
su finalización. Producir una versión inicial del sistema fue
relativamente fácil (Ver “Recursos”). Un enfoque basado en una
grilla podría ser utilizado eficazmente en esta etapa, organizar
puntos de vista relevantes en una matriz de dos dimensiones con
un nivel de abstracción sobre el eje vertical y la etapa del ciclo de
vida sobre el eje horizontal.
Sin embargo, nos dimos cuenta con rapidez que la matriz de
dos dimensiones era una representación bastante inadecuada del
sistema, en especial para la versión totalmente definida de la
fábrica porque: a) el sistema era multidimencional por naturaleza,
b) una representación de la matriz no captura las relaciones entre
puntos de vista no consecutivos, y c) los gráficos de los puntos de
vista eran de diferentes tipos y profundidades y se desplegaban en
gráficos subdivididos en diferentes tipos y profundidades.
No obstante, al trabajar con una representación amorfa del
sistema basada en un gráfico requería herramientas que no
estaban disponibles. Por lo tanto, implementamos el sistema de la
fábrica como un conjunto de proyecciones de los puntos de vista
relevantes en dos dimensiones. Cada una de estas proyecciones –
el gráfico por sí mismo– detalla un aspecto específico de la fábrica,
proyectándolo de forma eficaz desde un sistema multidimensional
Diseño del de la misma forma que un conjunto de registros es proyectado
protocolo del desde un almacén de datos multidimensional para formar una
servicio Web vista en dos dimensiones.

Infraestructura
Infraestructura
de la
de interacción
información

20 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL

 Fábrica de Software

Figura 5: Asistente de configuración de la selección del caso También consideramos bastante difícil decidir si debíamos
de uso proporcionar o no un lenguaje específico de dominio completo
(DSL) para la etapa de recopilación de requisitos de creación del
producto, en especial, dado que Microsoft ha publicado un
conjunto de herramientas DSL bajo el dominio de su iniciativa de
fábricas de software.
Sabíamos que un DSL completo no era estrictamente necesario
porque las especificaciones del caso de uso relevante ya estaban
disponibles para nosotros en el repositorio. Lo que realmente
necesitábamos era un asistente sofisticado que pudiera ayudar al
usuario a elegir casos de uso específicos (Ver Figura 5), roles de
aplicaciones, patrones de interacción del servicio (Ver Figura 6) y
otros elementos de datos estándares y a navegar a través del
repositorio.
También, la tecnología de diseño DSL de Microsoft era muy
inmadura cuando comenzamos el proyecto y el haberla adoptado,
hubiera agregado riesgos importantes. A pesar de que sabíamos
que estábamos perdiendo la oportunidad de ofrecer una
automatización más sofisticada y que la alternativa –una interfaz
del usuario basada en un asistente– no sería relevante fuera del
ámbito de la fábrica, decidimos no utilizar la tecnología DSL en
esta etapa del proyecto.
Dado que ahora contamos con una previsualización de la
tecnología de las herramientas DSL mucho más sólida y
consolidada, tal vez comencemos a experimentar con DSL en
versiones posteriores de la fábrica. También, aún si decidiéramos
crear otra interfaz del usuario basada en un asistente, muy
probablemente la diseñaríamos e implementaríamos utilizando las
herramientas DSL en vez de crearla desde el principio.
Por ejemplo, las Figuras 3 y 4 muestran dos ejemplos de puntos
Guidance Automation Toolkit (GAT), otra tecnología de apoyo
de vista, a saber, el punto de vista de desarrollo del sistema y un
bajo el dominio de la iniciativa de fábricas de software en
aspecto particular de él: el diseño del contrato de software –a un
Microsoft, ha probado ser bastante útil.
nivel de abstracción más bajo.
En pocas palabras, GAT es una extensión para el entorno de
desarrollo que facilita la creación de experiencias del usuario
Asignación de tareas
integradas y ricas en torno a bienes reutilizables como marcos,
Este enfoque nos permitió producir una versión del sistema de la
componentes y patrones. Los paquetes de programas de
fábrica que consideramos finalizado, es decir, especificaba de
orientación resultantes están compuestos de modelos, asistentes y
forma comprensiva todos los artefactos y herramientas requeridas
fórmulas que ayudan al usuario a construir soluciones en
en el modelo de la fábrica para producir los productos en la
consonancia con la orientación de arquitectura predefinida.
fábrica. Sin embargo, dejaba la verificación del sistema a cargo de
la inspección de las personas y no nos permitía utilizar el sistema
Ampliar el ámbito
como metadatos para orientar la experiencia del usuario dentro de
En nuestro proyecto, utilizamos GAT como el método para
IDE.
presentar y entregar el modelo de la fábrica. Proporcionaba un
La gestión de la configuración fue otro aspecto desafiante en el
modelo subyacente que era mucho más rico que el que ofrecía el
desarrollo de la fábrica, desde dos perspectivas.
entorno de la creación en sí mismo.
Primero, tuvimos que crear un sistema XLM de configuración,
Las fórmulas han sido provistas por actividades como la
que sería completo en lo que respecta a permitir la expresión de
creación de un adaptador de los servicios Web del HL7,
todas las combinaciones válidas de las características admitidas
y/o estrategias de implementación. El sistema XML fue artesanal y
se volvió con rapidez una carga de mantenimiento, ya que era
altamente susceptible a los cambios en el modelo y el sistema de Figura 6: Asistente de configuración del servicio de
la fábrica. Por otro lado, no contábamos con herramientas dentro especificación de los patrones de interacción
del entorno de desarrollo del objetivo para soportar la
configuración de una instancia específica de la fábrica o la
validación de esta configuración durante la creación del producto.
La especificación del proceso de desarrollo del producto fue
también un desafío en la creación de la fábrica. No teníamos forma
satisfactoria de expresar el proceso en el modelo de la fábrica y lo
que es más importante, no había manera de incluir el proceso
como una orientación de la perspectiva dentro del entorno del
desarrollo.
A pesar de que el entorno de creación del objetivo no admitía la
creación de tareas y la asignación de tareas a miembros del
equipo de desarrollo, tuvimos que confiar en documentos de
lenguaje natural para describir el proceso de creación porque aún
no habíamos determinado la forma de aplicar las características de
administración de las tareas al proceso de creación del producto
basado en la fábrica. En particular, no habíamos determinado aún
la forma de asociar las tareas con los bienes específicos ofrecidos
por el modelo de la fábrica, la forma de cargar las tareas desde el
modelo de la fábrica o la manera de configurar las tareas para un
producto específico.

THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net 21

 Fábrica de Software
ejecución del asistente de configuración, creación de contratos de
servicios Web, y automatización del proceso de creación del
código.
Desafortunadamente, la curva de aprendizaje del GAT es
bastante pronunciada. Sus opciones de flexibilidad y
personalización son limitadas y su integración con el IDE podría
haber sido mejor. No obstante, creemos que la adopción del GAT
fue una decisión clave que ayudó a asegurar el éxito del proyecto
y redujo significativamente el tiempo de creación de la fábrica.
A pesar de que desarrollamos la fábrica para permitir la
colaboración interempresarial entre aplicaciones del cuidado de la
salud, rápidamente fue evidente que podíamos aplicar esta fábrica
a escenarios similares en otras industrias. Nos damos cuenta que
el ámbito real de la fábrica debería ser la colaboración empresarial
en general, utilizando especificaciones estandarizadas o
predefinidas de interacciones, roles de aplicación, eventos, perfiles
de servicios Web y otros elementos de dominio, no simplemente la
colaboración empresarial en el contexto del HL7.
A posteriori, la razón por la cual inicialmente creamos esa
fábrica para el HL7 era que el estándar del HL7 ofrecía un conjunto
completo de elementos de dominio bien definidos y de fácil acceso.
Por supuesto, otras tantas organizaciones estándares, como
RosettaNet y UNCEFACT han realizado también un gran esfuerzo al
especificar elementos de dominio para que sean utilizados por
empresas que deseaban colaborar utilizando protocolos
estandarizados. Curiosamente, en lo que concierne a los
protocolos de colaboración y la información que intercambiaban,
estas normas son muy parecidas.
Por lo tanto, concluimos que hubiera sido posible no sólo crear
sistemas de colaboración basados en estándares para otras
industrias, sino también crear una fábrica de puertos de
colaboración que se pudiera personalizar utilizando las
Recursos
“Estrategia de una Fábrica de Software para las soluciones de la
versión 3 del HL7”, Mauro Regio, Jack Greenfield, y Bernie Thuman
(Junio de 2005)
Modelado específico de dominio con MetaEdit+
www.metacase.com
Health Level Seven
www.hl7.org
“Perfiles de servicios Web avanzados”, Roberto Ruggeri et al.
www.hl7.org/v3ballot/html/welcome/environment/
Instituto para los Sistemas Integrados de Software
“Computación Integrada con Modelos”
www.isis.vanderbilt.edu
MSDN
Visual Studio Team System Developer Center
Microsoft Enterprise Framework and Tools Group
“Herramientas de lenguaje específico de dominio (DSL)”
http://lab.msdn.microsoft.com/teamsystem/workshop/dsltools/
Microsoft Patterns and Practices Team
“Juego de Herramientas para la Automatización Orientada (GAT)”
http://lab.msdn.microsoft.com/teamsystem/workshop/gat/
Fábricas de Software: Reunir Aplicaciones con Patrones, Modelos,
Sistemas y Herramientas, Jack Greenfield et al. (Wiley, 2004)
“Implementación de Servicios Web para las Aplicaciones del HL7
para el Cuidado de la Salud– Implementación de la referencia del
perfil básico de los servicios Web”, Mauro Regio (Agosto de 2005)
22 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL
especificaciones de colaboración empresarial para otras industrias.
Por supuesto que existiría la necesidad de varios mecanismos de
importación, adaptadores y conversiones del modelo para trabajar
con los diferentes conceptos utilizados por las diferentes agencias
de normalización para describir la colaboración interempresarial.
Sin embargo, creemos que se podría utilizar una especificación
genérica para acortar estas diferencias por medio de la
configuración de una fábrica de colaboración empresarial genérica.
Al mismo tiempo, reconocemos que una fábrica más genérica
podría también ser bastante atractiva para los desarrolladores
corporativos que construyen sistemas de colaboración empresarial
dentro de servidores de seguridad, y para quienes desean un
método más formal para especificar e implementar esos sistemas
y garantizar una mejor alineación entre las metas de la empresa y
un portfolio de servicios IT resultantes. Sin embargo, en este caso
necesitamos proporcionar arquitectos empresariales junto con los
modelos y herramientas necesarias para soportar el proceso de
especificación.
Nos damos cuenta que nuestra fábrica debe admitir la
construcción de puertos de colaboración para las distintas
plataformas de tecnología. Sospechamos que esto podría lograrse
utilizando los patrones de implementación provistos con el modelo
de la fábrica para desasociar la especificación de los puertos de
colaboración desde los detalles de implementación específicos de
una plataforma.
Tomar el liderazgo
Nuestro plan es explotar la oportunidad aquí descripta para
generalizar la fábrica del HL7 y así formar una fábrica de
colaboración empresarial. Creemos que la mayor parte del trabajo
requerido para lograr esta generalización reside en las siguientes
áreas:
• Proporcionar modelos y herramientas para soportar las
especificaciones de las colaboraciones empresariales, definiendo
con claridad el sistema de información, los protocolos de
intercambio de mensajes/documentos empresariales, y
posiblemente las transacciones empresariales.
• Definir las asignaciones entre los criterios de la industria
relevantes y nuestro modelo interno de colaboración
empresarial, y posiblemente las herramientas para la
importación de los elementos de dominio que definen.
• Introducir otro nivel de configuración en la implementación de
los puertos de colaboración que permita a los usuarios de la
fábrica dirigirse a una variedad más amplia de plataformas de
tecnología.
Nuestra experiencia al desarrollar una fábrica para los puertos
de colaboración del HL7 ha demostrado que es necesario definir
mejores marcos, herramientas y procesos para especificar el
esquema de la fábrica, para administrar la configuración de la
fábrica de forma flexible y extensible y para comprender mejor
cómo y cuándo deben utilizarse los lenguajes específicos de
dominio. Al mismo tiempo, las implementaciones iniciales de los
mecanismos de extensión como el GAT y DSL han probado su
valor, llenando espacios significantes en la infraestructura de la
fábrica de software y apuntando a innovaciones futuras en el área.
Es nuestra intención continuar utilizando y mejorando estas
herramientas en la próxima versión de la fábrica del HL7, así como
también una versión interindustrial más generalizada llamada
fábrica de colaboración empresarial.
Sobre los autores
Mauro Regio es arquitecto de soluciones de la industria en la
división Developer and Partner Evangelism Architecture Strategy
Team de Microsoft, definiendo proyectos de integración
empresarial a gran escala y fábricas de software.
Jack Greenfield es arquitecto de software y herramientas para la
empresa, Microsoft.
Inteligencia Comercial
Orientada al Servicio
Por Sean Gordon, Robert Grigg, Michael Horne y Simon
Thurman
Síntesis
Este documento analiza las similaridades y diferencias
entre la Inteligencia Comercial (BI) y la Orientación al
Servicio (SO), dos paradigmas arquitectónicos que se han
desarrollado en forma independiente. Aquí definimos un
marco arquitectónico que marca las ventajas de BI y SO
mientras que define los principios de guía para asegurar
que no se incumpla con los principios fundamentales de
cada arquitectura componente.
El sustantivo sinergia significa la acción combinada de entidades
discretas o condiciones para que el efecto sea mayor que la suma
de sus efectos individuales. Inteligencia Comercial Orientada al
Servicio (SoBI) es la sinergia de los paradigmas Inteligencia
Comercial (BI) y Orientación al Servicio (SO), y describe patrones
y arquitectura para lograr esta sinergia, brindando un marco de
implementación de mejor práctica; la capacidad de integrar al
nivel de arquitectura más adecuado; el modelado de datos de un
proyecto BI dentro de la estrategia SO de dejar a los sistemas
origen en su lugar; y una implementación común para
transformaciones de datos y lógica de datos: datos a datos, datos
a servicio, servicio a datos, y servicio a servicio.
BI y SO son paradigmas amplios. Comencemos definiendo BI. El
almacenamiento de datos es una disciplina amplia que permite
reunir, consolidar, y almacenar datos para soporte de BI. Los
componentes de un almacenamiento satisfactorio de datos se
pueden resumir como recolección de datos, limpieza y
consolidación (Extracción, Transformación
Figura 1: Vistas de BI y SO
SO BI
BI visto como una recolección de
servicios
SO visto como fuentes de datos
Disciplinas para Coincidencia Disciplinas para
soporte de SO estructural soporte de BI
THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net
Figura 2: Vista BI de SO
BI SO
Fuente
de datos
SO visto como recolección de fuentes de datos Servicio
de datos
Eventos
Figura 3: Vista SO de BI
SO BI
Transformación
BI visto como recolección Servicios
de fuentes de datos
de datos
y Carga, o ETL) y almacenamiento de datos. BI es el envío de
información para soporte de necesidades de toma de decisiones
del negocio. Se puede describir como el proceso de mejora de
datos en información y luego en conocimiento.
Cada sistema BI tiene una meta específica, que se deriva de los
requisitos del negocio.
Para facilidad de lectura, el almacenamiento de datos y la
inteligencia comercial se consolidarán bajo la sigla BI en todo este
artículo.
SO es un medio de construir aplicaciones distribuidas; en su
aspecto más abstracto, el SO ve todo como un proveedor de
servicios; desde aplicaciones a empresas y mecanismos. Los
proveedores de servicios exponen las capacidades a través de
interfases. Estas interfases definen el contrato entre el llamador
del servicio y el servicio mismo. El consumidor de un servicio no se
preocupa por la manera de implementación del servicio, sólo por lo
que hace el servicio y por cómo convocarlo.
Los servicios mismos son los bloques de base de las
aplicaciones orientadas al servicio. Los servicios encapsulan los
aspectos fundamentales de la orientación al servicio, a saber, la
separación entre interfase e implementación. El SO es
fundamental para proveer agilidad comercial y la flexibilidad de IT
que prometen los servicios de Red. Estos beneficios se brindan no
sólo mediante la vista de arquitectura de servicios desde el punto
de vista de tecnología, o
23
 Arquitectura SoBI

adoptando protocolos de servicios de Red, sino también exigiendo Figura 4: SO como fuente de datos para BI
la creación de un ámbito orientado al servicio que se base en
principios fundamentales específicos.
BI ha funcionado durante años; sus prácticas están bien Mensajes/Transporte
establecidas, y las personas están a gusto con los conceptos
involucrados en brindar soluciones BI. Para muchos, BI es
simplemente la presentación de información en forma oportuna
Llamada de
servicio
5 1
mediante una sofisticada interfase de cliente. A aquellos que GetData Respuesta Llamada de
2 servicio Respuesta
participan en la provisión de soluciones BI, este aspecto de la GetData
solución integral de BI es la punta del iceberg. Debajo hay un 6
ejercicio enorme en mejora de calidad de datos e integración de Fachada del servicio
datos entre las dispares aplicaciones y sistemas corporativos y la Servicio comercial
consolidación de esos datos en el almacenamiento de datos. La
integración de datos es el costo mayor predominante en un Consulta
proyecto BI. 3 Respuesta 4
Convergencia de EAI y ETL
Hasta hace poco, SO había tenido pocas funciones o ninguna en el Inteligencia comercial
mundo de BI, en primer lugar porque el enfoque de SO parecía
trabajoso y muy complejo para una comunidad acostumbrada a
mover datos de cualquier volumen conectándose directamente a Figura 5: BI consumiendo eventos SO
un sistema fuente a nivel de base de datos. En BI, la integración
de datos se logra mediante el proceso ETL, que es la piedra
fundamental de toda solución BI, y las soluciones BI tienden a Mensajes/transporte
buscar la manera más directa y eficiente de lograrlo.
La integración de aplicaciones empresariales (EAI), como BI, se
implementa hace años. Es un problema comúnmente encontrado
Eventos suscriptos Eventos publicados
dentro de una empresa en la cual los sistemas se introdujeron o
crecieron en una forma orgánica. EAI mismo se puede definir
como compartir proceso y datos entre aplicaciones dentro de una
Eventos Agente de
empresa. Específicamente, cuando usamos el término EAI, nos recopilados almacenamiento
referimos a la integración de sistemas dentro de la empresa: por
ejemplo, integración de aplicaciones, datos y procesos. Servicio comercial
La integración aplicación-a-aplicación se refiere al intercambio Eventos
de datos y servicios entre aplicaciones dentro de la empresa. Almacenamiento
Notablemente, esta forma de integración se produce con de datos Cache
de
frecuencia entre aplicaciones que residen en diferentes eventos
plataformas de tecnología, basadas en arquitecturas que difieren.
EAI es generalmente difícil, y exige la conectividad entre
plataformas de tecnología heterogéneas; implica reglas y procesos las capacidades analíticas para guiar sus decisiones operativas:
comerciales complejos; implica procesos comerciales a largo plazo por ejemplo, para detectar una tarjeta de crédito supuestamente
donde las unidades lógicas de trabajo pueden abarcar días o robada en la caja en base a datos históricos extraídos para
semanas al moverse a través de los diferentes procesos dentro de patrones fraudulentos.
la organización; y generalmente lo impulsa la necesidad de Las organizaciones también se inclinan más a dejar abiertos
extender /mejorar un negocio y proceso existente automatizado o estos datos y que queden completamente disponibles para las
introduce un proceso comercial automatizado completamente demás partes de la organización, a una gama más amplia de
nuevo. usuarios y herramientas. Tradicionalmente, el acceso a la
Las soluciones a los problemas de EAI pueden implicar la información BI exigía acceso a un conjunto específico de
solución del problema de integración de la aplicación a un número herramientas de manejo de datos. En el ámbito actual de SO, la
de niveles arquitectónicos diferentes como datos, aplicaciones, meta debe ser abrir estos datos organizacionales a un público más
procesos, y demás. En esta forma, tanto ETL como SO pueden amplio y permitir que se dé a conocer el valor de los datos más
formar parte de una solución EAI. En muchas formas, SO perdió la ampliamente.
necesidad de encontrar soluciones comunes, abiertas e
interoperativas para el problema de EAI. Un espectro más amplio
El proceso ETL tradicional es un proceso por lotes enfocado en Al aumentar la variedad y número de fuentes de datos
la integración de datos durante el período inactivo comercial. En el considerados dentro del alcance para BI, también aumenta la
mercado conectado actual, los negocios no tienen momentos de complejidad potencial de la solución ETL requerida. Por ejemplo,
inactividad para que se produzca este proceso. El conjunto de los servicios de Red, RSS, y datos semi estructurados y no
datos corporativos tiene el potencial de aumentar estructurados son fuentes de datos que ahora se encuentran
significativamente a medida que las iniciativas como navegación dentro de la integración de datos, pero no se asocian
de usuarios, comercio electrónico y RFID se usan más, y ETL debe tradicionalmente con ETL. Con la adopción generalizada de
ser lo suficientemente flexible para emerger de sus raíces por lotes principios orientados al servicio y las tecnologías asociadas que lo
para brindar datos en base a los eventos. permiten, fue posible el acceso a una más amplia gama de
Dentro de una solución SO, estos eventos se rutean, consumen sistemas, dejando a disposición una gama más amplia de datos
e integran como parte de una arquitectura impulsada por eventos. comerciales.
BI perdió la incapacidad de los sistemas operativos para manejar Las organizaciones siguen con el escrutinio de economía de
eficientemente capacidades analíticas (agregados, tendencias, integración de datos con cada proyecto, afectando a los productos
excepciones, y demás), por lo tanto, se desarrollaron diferentes que seleccionan, lo que está causando un cambio en el panorama
sistemas BI para cumplir con esta necesidad. Este método artificial de integración de datos y un cambio relacionado en la
no se acepta más; los negocios de hoy parecen usar cada vez más funcionalidad

24 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL


provista por el software ETL o EAI. Los proveedores tienen que
aumentar la flexibilidad y funcionalidad ofrecida por sus
plataformas en respuesta a estos nuevos desafíos. El resultado
neto para el cliente es un conjunto de herramientas con un
conjunto cada vez más fusionado de funcionalidades.
Los usuarios familiarizados con el conjunto de productos
Microsoft no pueden no haber notado este patrón. BizTalk se
desarrolló en el EAI y el espacio negocio-a-negocio (B2B) pero
tiene aplicabilidad en algunos escenarios ETL. Servicios de
Transformación de Datos (DTS), herramienta ETL de Microsoft que
forma parte de la plataforma SQL Server 2000, creció de un
antecedente de ETL. No es coincidencia que la versión SQL Server
2005 de este producto haya tenido una re-arquitectura para
brindar soporte a un más amplio espectro de escenarios de
integración, y se le dio el nombre de Servicios de Integración para
enfatizar esto.
Aunque las arquitecturas orientadas al servicio (SOAs) y las
arquitecturas BI han evolucionado por separado e incluyen
tecnologías y disciplinas específicas para sus propios objetivos
arquitectónicos individuales, muchas de las tecnologías que
utilizan coinciden. Hay también una clara correspondencia entre
los conceptos utilizados, en el cual cada uno puede ver al otro en
sus propios términos. Hemos llamado a esto "vistas desde el otro
lado", y el diagrama de esto se puede ver en la Figura 1.
Trataremos cada escenario en detalle.
Desde la perspectiva de BI, es posible ver una aplicación SO
como una recolección de fuentes de datos y fuentes de eventos.
Hay dos modos principales en los cuales un servicio puede operar
como fuente de datos en un contexto de BI: servicio como
proveedor de datos a pedido y servicio como publicador de datos
que puedan ser de interés (Ver Figura 2). En ambos casos, los
tamaños de mensaje son pequeños. La solución para transferencia
de datos a gran escala y transformación será aún a través de
técnicas de importación de almacenamiento de datos como ETL.
Los mensajes tan físicamente grandes no son dominio normal del
SO.
Desde el punto de vista de SO, BI se puede ver como
recolección de servicios. Desde la perspectiva de SO, una fuente
de datos puede exponerse como servicio con la presentación de
una capa simple que reciba el pedido de servicio desde el ómnibus
de servicio y convoque la consulta adecuada. La fachada
transforma los resultados de la consulta (si es necesario) en
esquema de datos, y devuelve los resultados al llamador (Ver
Figura 3).
La arquitectura SoBI pone a disposición los datos BI en el
almacenamiento de datos como servicio para otras aplicaciones
dentro de la arquitectura. Esta disponibilidad brinda a las
aplicaciones una manera limpia de acceder a datos consolidados
para brindar soporte a los requisitos de BI. De esta manera, la
arquitectura BI se vuelve un componente integrado de la
arquitectura de aplicación SO. Note que habrá veces en que el tipo
de datos requerido por el sistema es puramente de naturaleza BI,
como exportación de
Figura 6: Tamaño del mensaje vs. Volumen del mensaje
SO
Volu
men
del
men
saje
je
nsa
l me
año de
Tam
SO de grano pequeño Importación de datos
o eventos en tiempo Servicios de grano medio
real de grano grande/ETL
THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net
Arquitectura SoBI
Tabla 1: Beneficios de SO y BI
Orientación al Servicio (SO) Inteligencia Comercial (BI)
El más adecuado para integración El más adecuado para integración
aplicación-a-aplicación y más datos-a-datos y capaz de
adecuado para eventos de bajo manejar grandes volúmenes de
volumen y alta frecuencia datos.
Brinda una plataforma operativa, Brinda un modelo combinado de
define rigurosamente formatos y datos de la empresa y brinda
estructuras de datos, y encapsula bases para decisiones
y abstrae funcionalidad. comerciales y capacidad de
consultar cualquier cosa de los
datos.
Soporta reutilización de Buenas herramientas y
componentes empresariales y mecanismos para transformar
permite cambios ágiles en datos.
procesos comerciales.
datos a gran escala. En estos casos el enfoque de interfase de
servicio no será adecuado.
Provisión de datos orientados al servicio
Desde la perspectiva BI, un servicio puede exponerse como
fuentes de datos con la introducción de una simple capa de
fachada que brinda una correspondencia entre la interfase BI y la
interfase expuesta por el servicio. La fachada transforma los
resultados de la llamada del esquema de datos usado en el bus de
servicio al formato de datos que espera la plataforma BI y
devuelve los resultados al llamador (Ver Figura 4).
Algunos servicios exponen la información mediante eventos que
se publican cuando se produce un cambio interesante en el
servicio. Otros servicios y aplicaciones dentro de la organización
pueden suscribirse a eventos publicados por los servicios. La
integración de servicios para publicar eventos en la plataforma BI
se logra mediante el uso de un agente que recolecta los eventos
suscriptos y periódicamente transfiere los mismos en conjunto a la
plataforma BI (Ver Figura 5).
Uno de los desafíos en el desarrollo de SoBI fue encontrar un
enfoque que impulsara las mayores fortalezas de cada arquitectura
e identificara el área donde la integración causara desafíos.
Veamos algunos de los desafíos principales inherentes a la
implementación de BI en forma SO. Estos desafíos generalmente
surgen por los requisitos específicos que cada arquitectura fue
desarrollada para tratar.
La Figura 6 muestra las diferencias en granularidad de datos
que separa los enfoques BI de SO. En los extremos tenemos
mensajes o eventos de grano pequeño, que están naturalmente en
el espacio de evento SO. Tales mensajes de grano pequeño no se
consumen rápida y eficientemente en una arquitectura BI sin usar
agentes de eventos para recolectar eventos e importarlos a un
almacén de datos en forma periódica. Los datos de grano grande,
importación a granel o movimiento de grandes cantidades de
datos, se maneja más eficientemente mediante las técnicas de
almacenamiento de datos como ETL. Los servicios en sistema SO
que exponen grandes cantidades de datos no son eficientes para
usar y casi no se implementan. En el medio tenemos los típicos
BI servicios de grano medio, que consumen datos suficientes para
cumplir con un requisito particular. Esta etapa intermedia es clave
para el valor agregado de SoBI.
Las aplicaciones orientadas al servicio muestran un
emparejamiento aproximado entre sus servicios constitutivos. Este
emparejamiento es uno de los principios fundamentales de SO y
soporta el desarrollo de aplicaciones ágiles/flexibles que pueden
adaptarse a los cambios comerciales. Ver tabla 1 para los
beneficios específicos de SO y BI.
Las soluciones BI están fuertemente emparejadas con las
fuentes de datos que alimentan el almacenamiento de datos y con
las aplicaciones que lo usan. BI ha evolucionado del ámbito
centrado en lotes donde se usa el ETL como medio para consumir
y consolidar directamente grandes cantidades de datos de sistema
de fuente sobre un programa conocido para población de almacén
de datos.
25
 Arquitectura SoBI
Figura 7: Marco del SoBI
SO exige que la interfase del mensaje y los formatos tanto del
mensaje entrante como de la eventual respuesta estén bien
definidos. Cuando se exponen los servicios que describen
capacidades comerciales las consultas a realizar dentro de una
aplicación SO se conocen con antelación. Sin embargo, existe
también un aspecto no conocido relacionado con exponer los
servicios que están agregados o implementados por otra
aplicación. BI se preocupa por la habilidad de permitir a las
aplicaciones consultar cualquier cosa del almacén de datos dentro
de los límites del modelo de datos del almacén. La consulta, o el
tamaño; contenido; y formato del resultado no se saben hasta que
no se haga la consulta.
Ventajas del SoBI
Un enfoque SO es más adecuado para exponer servicios que
engloben las capacidades comerciales o servicios que publiquen
eventos de interés para otros sistemas. BI brinda un ámbito
cerrado para satisfacer requisitos de información del negocio. BI
permite al consumidor de datos verlos en potencialmente muchas
formas nuevas y diferentes. Esta flexibilidad brinda la capacidad
de identificar tendencias y relaciones que pueden pasarse por alto.
Previamente presentamos las fortalezas principales de cada
paradigma, cada uno de los cuales se puede ver como tema
fundamental si se ve puramente desde la postura del otro
paradigma. Ahora revisaremos estos desafíos y veremos qué
beneficios puede traer el SoBI.
Funcionalidad de ETL almacenamiento superficial para SoBI
permite que eventos comerciales interesantes durante el proceso
ETL se publiquen como eventos. Consideremos algunos ejemplos.
Integridad referencial. SoBI puede brindar agregados de la
posición “ahora”. Por ejemplo, datos que no están en el sistema
fuente pueden agregarse en el almacén de datos como marcador
de posición para mantener la integridad de los datos de la base de
datos. Este marcador de posición puede producirse cuando
26 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL
sistemas fuente dispares brindan datos en momentos diferentes
(por ejemplo, valores transaccionales provistos antes de recibir la
información de referencia asociada). Estos datos se almacenarán
como datos privados de marcador de posición dentro del servicio
BI. Se puede enviar una notificación al sistema fuente para
asegurar que no haya ocurrido un error, y cuando los datos de
referencia estén disponibles el almacén de datos volverá a
aparecer conforme al sistema de registros.
Servicio de una validación. La funcionalidad requerida para
validación durante la etapa de ETL se puede exponer mediante el
marco SoBI para su uso dentro de otras partes del negocio.
Actualizaciones a tiempo. La ventaja clave para BI es que la
adopción de ETL de una perspectiva SO puede permitir
alimentaciones en tiempo real en el almacén de datos y por lo
tanto un almacenamiento de datos en tiempo real potencial.
Además, el mejor soporte para eventos e integración impulsada
por eventos puede brindar BI con un mecanismo mucho mejor
para invocar ETL que los métodos tradicionales, como
programación a tiempo o escaneo persistente de un directorio
conocido para un archivo indicador.
Esquema comercial común. Dentro de cualquier organización
puede haber múltiples sistemas que poseen información sobre las
mismas entidades y que poseen esta información en diferentes
formatos. Existen claras sinergias entre estos casos:
• Construir el modelo de datos lógico para un almacén de datos es
fundamental para cualquier iniciativa BI. El modelo de datos es
el producto final de los esfuerzos para consolidar los datos de
sistemas fuente dispares. La estructura de modelo de datos
impulsa la transformación que se produce como parte de la
población de almacén de datos y, por lo tanto, permite que el
almacén de datos brinde una sola versión de la verdad para
información de administración.

Tabla 2: Principios de SoBI
BI
Es… …la única versión de la verdad para datos BI
En el futuro… ...brindará acceso a servicios de datos,
soportará análisis especial, soportará informes
de administración pre elaborados, consolidará
datos de sistemas fuente dispares, y soportará
datos de referencia.
En el futuro no… …se convertirá en vertedero de todos los datos,
ni se convertirá en propietario de datos, ni será
la fuente de datos por defecto para otras
aplicaciones, ni soportará informe operativo.
• Para cualquier servicio de agregado de entidades dentro de un
diseño SO es importante para llegar a un acuerdo sobre
significados comunes para las entidades en las cuales operarán
los servicios. Este acuerdo se menciona como consolidación de
esquema y es el proceso de crear esquemas de datos master
que contengan un super set de información para describir a las
entidades en el sistema en detalle suficiente para que los
diferentes servicios puedan localizar los datos que necesiten.
Otro servicio de entidades que cumple con este enfoque es la
habilidad para exponer datos de referencia. Conforme a Easwaran
G. Nadhan, Principal, EDS, “Es claro a partir de la experiencia en el
número (relativamente bajo) de organizaciones que se cambiaron
drásticamente a SOAs que coordinar datos de referencia es el
primer paso obligado hacia la orientación al servicio”. (Ver
“Recursos”).
La realidad
Una versión de la verdad. Viendo la funcionalidad ofrecida por las
dos arquitecturas en forma integral, SoBI nos da la oportunidad de
consolidar datos BI y operativos sin la necesidad de mover
físicamente todos los datos operativos en plataformas BI, lo cual
es un enfoque común a brindar “una versión sola de la realidad”
en un proyecto BI. Al adoptar la elección arquitectónica más
adecuada, los datos operativos pueden dejarse en el lugar pero
seguir disponibles para el marco SoBI como un servicio, en caso
de que surja la necesidad de acceder a este o de verlo.
Por ejemplo, en un ámbito BI interesado en el análisis de
incidentes sanitarios o de seguridad, SoBI permitiría que los
detalles de hechos de cada incidente se pudieran mover al
almacén de datos, es decir, el hecho de que sucedió un incidente,
dónde sucedió, y la clasificación del mismo, lo cual permitiría que
se realicen todos los agregados y análisis adecuados según lo
esperado de la plataforma BI.
La ventaja de SoBI es que brinda un medio de acceder aún a los
detalles de la transacción en el sistema de registros (por ejemplo,
texto de libre formato que se adjunta al incidente, que describe las
circunstancias que rodean el evento en detalle). Este acceso
generalmente se llama “Capacitación” o “capacitación en detalle”
en BI, y para lograrlo todos los datos relevantes para el requisito
se mueven generalmente al almacén de datos.
De hecho, esto puede no estar permitido (como por ejemplo por
razones de protección de datos) o no es preferible (aumenta la
carga de ETL y los requisitos de almacenamiento del almacén de
datos para tener datos, el cual por definición, tiene naturaleza
operativa), y tiene el potencial de agregar presión en la plataforma
BI convirtiéndose en una fuente de hecho para todos los datos de
incidentes aunque nunca está actualizado.
Servicios comerciales. La combinación de autorización de BI en
tiempo real y la capacidad de dejar datos operativos en su lugar
nos da la oportunidad de construir un servicio excelente alrededor
del marco SoBI que no sería posible si trabajara dentro de una
sola arquitectura componente. Considere un sistema que detecte
fraudes minoristas. En BI tenemos las
THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net
Arquitectura SoBI
SO
…el enfoque arquitectónico para integración de aplicaciones
...brindará integración aplicación-a-aplicación, brindará
alimentaciones de algunos eventos al DW, describirá los
servicios brindados y mensajes enviados, cumplirá con los
requisitos operativos, y brindará los servicios de
infraestructura para todas las aplicaciones.
…se usará en todos los casos ni reemplazará importación de
datos
herramientas para construir un motor analítico capaz de extraer
las cantidades potencialmente altas de datos transaccionales para
patrones que resulten en una lista de tarjetas de crédito
sospechosas. La adopción de principios SO nos permite ofrecer un
servicio que brinde los detalles de las tarjetas de crédito en uso en
nuestro local cuando son robadas. LA arquitectura SoBI permite
que este servicio sea consumido por el componente BI de la
plataforma y lo analice en comparación con la lista conocida de
tarjetas sospechosas, y por lo tanto responda de inmediato si se
detectara una transacción potencialmente sospechosa.
Una nueva clase de servicios comerciales
Agregado de datos históricos y transaccionales como servicio.
Dado un servicio expuesto mediante el marco SoBI que ahora
puede agregar sin fallas datos transaccionales actuales y datos de
almacén históricos, se puede brindar soporte a una nueva clase de
servicios comerciales. Un ejemplo podría ser cambio lento de
dimensiones, que es donde un valor como el nombre de un cliente
cambia con el tiempo. Obviamente esta información está
disponible dentro del almacén de datos, así que si existe un
requisito para exponer un servicio de entidad que dé una simple
vista del cliente, se puede lograr esto de manera más fácil y
precisa.
Trae los patrones de abstracción de interfases a BI. La
capacidad de usar el patrón de abstracción de interfases en la
funcionalidad BI hace más accesibles a la funcionalidad y a los
datos para aplicaciones de líneas de negocios y brinda la capacidad
de exponer reglas comerciales complejas generalmente ocultas en
la capa ETL.
Limpieza y consolidación. Los datos cambiarán para fines de
consistencia e integridad. Cuando este cambio implique una
operación de correspondencia, esa correspondencia quedará
disponible para la arquitectura como un servicio. Cuando este
cambio implique corrección a los datos, los detalles de esa
Figura 8: Escala y flexibilidad ideales
Llamadas de
servicio Eventos
Servicios estratégicos
Fachada del
servicio
Aplicación de la Exportación de datos/ETL
Almacén de
empresa o fuente datos
de datos
27
 Arquitectura SoBI

corrección se otorgarán al sistema de registros mediante un Figura 9: recolección de eventos para integración
pedido de cambio al servicio propietario, es decir, el proceso de
ETL no puede cambiar los datos por no ser el propietario. A su vez,
Mensajes/transporte
este proceso obviamente mejora la calidad de los datos.
Obtener un sistema cruzado, vista consistente del producto.
Durante la etapa ETL los datos del mismo producto (o entidad)
pueden exigir transformación para que se pueda almacenar en Llamadas de
servicio Eventos
forma consistente. Al autorizar el acceso a los datos la
organización puede mostrar una sola vista común de un producto.
Correspondencias disponibles como servicio. Según lo que ya se
Servicios estratégicos
estableció, la correspondencia es un requisito fundamental dentro
Agente de
de la etapa ETL. El marco SoBI permite que se exponga la eventos de
funcionalidad de correspondencia como un servicio para otros usos almacén

dentro de la organización. Tales usos incluyen EAI y escenarios de Fachada de Eventos

servicios recolectados
referencia empresariales. Esta disponibilidad de este servicio
Aplicación
también puede usarse para promover lo mejor de las orientada al
transformaciones de clases. evento (datos casi
en tiempo real, Almacén de
Cálculos. El almacén de datos con frecuencia se usa para pero no es lo datos
mismo que datos Caché de
almacenar valores precalculados para soportar los requisitos de BI. P1 de series de eventos
tiempos)
Por ejemplo, los datos de ventas y pronóstico se pueden mantener
en diferentes sistemas físicos. La consolidación de datos de estos
sistemas en el almacén de datos nos permite calcular y almacenar
cifras reales versus previstas para soportar análisis e informes
más rendidores. La lógica comercial utilizada para definir tales
cálculos con frecuencia es interesante para otras partes del
negocio así que el cálculo para soportar esta invención de datos en Figura 10: Actualización de fuentes de datos no
el almacén de datos estará disponible para la arquitectura SoBI empresariales
como servicio.
Brinda un mapa de ruta para la integración. Se cree que uno de
los resultados para el marco de SoBI es una capacidad, a nivel de
arquitectura, de brindar un marco para futuros escenarios de
integración.
Datos no
Cumplimiento/Auditoría. La aplicación de marco SoBI exige estructurados
adherirse a un proceso formal de regulación. Los ejemplos
incluyen la identificación del sistema de registros o propietario de
datos operativos, y la definición de mensajes que describen los Aplicar estructura a
almacenamiento de
requisitos funcionales y datos. Dado que sólo el propietario de los datos
datos puede efectuar un cambio a los mismos, otros sistemas Datos no
estructurados
simplemente pueden solicitar el cambio, y la auditoría puede
llevarse a cabo en un solo punto.
Suma. Para brindar soporte a tiempos rápidos de respuesta, los
datos del almacén de datos se pre-suman con frecuencia. Por
ejemplo, el almacén de datos puede contener datos sobre ventas a Datos estructurados
un nivel de transacción individual, pero la mayoría de los informes
de administración podrán exigir ver los totales por mes. En este Proceso de transformación
caso, es rentable listar las (potencialmente millones de)
transacciones individuales hasta un nivel más adecuado para las
consultas conocidas y almacenar los resultados totales, evitando la Datos estructurados
necesidad de consultas conocidas para realizar la acción de suma
en el momento de la consulta. Cuando se creen tales sumas, Datos estructurados
estarán disponibles para la arquitectura como servicio.

Calidad de datos empresariales

La mayoría de las organizaciones soporta el tema de la
compatibilidad entre sus sistemas IT. Este tema es cada vez más
aparente cuando los fusionadores se producen. No hay razón por
en los mensajes de servicio y la definición de estos mismos
la cual los sistemas de empresas completamente distintas sean
mensajes mejora fuertemente la calidad de los datos de cualquier
consistentes, alineados o satisfagan un diseño unificado. Una
solución por la capacidad de evaluar automáticamente los
iniciativa BI tiene que tratar los problemas de sistemas dispares,
mensajes para que cumplan con el esquema de mensajes o
silos de datos e incompatibilidad de datos mediante iniciativas de
contrato que soporta un servicio.
calidad de datos. Si los usuarios del comercio finalmente no
Echemos un vistazo a un ejemplo de marco SoBI. Es importante
confían en la información que se les presenta, no usarán el
que el marco SoBI defina claramente y distinga entre los
sistema.
diferentes tipos de datos y los propietarios asociados de estos
Mejorar la calidad de los datos no es simplemente un proceso
datos, lo cual asegura la integridad al poderse modificar los datos
de arreglar problemas con elementos de datos individuales; se
sólo en un lugar. También permite que los datos se configuren
trata de diseñar un proceso comercial que mejore la
para su uso adecuado. La Figura 7 muestra la arquitectura de
administración y calidad de los datos como un recurso
datos de alto nivel para el marco SoBI. El fin de esta arquitectura
empresarial. En una aplicación SO los datos que brinda un servicio
es marcar cómo se manejarán los diferentes tipos de datos en la
son controlados mediante la encapsulación que hace ese servicio y
solución.
sólo se publican en una forma específica que coincide con el
Como podrá ver, los sistemas de registro están integrados en el
esquema de datos definido para el servicio.
almacén de datos mediante métodos ETL tradicionales, con
El acceso a los datos se logra mediante los mensajes que el
excepción de que los servicios de transformación normalmente
servicio publica. El servicio es sólo responsable de mantener la
contenidos dentro del proceso ETL se muestran para que los
integridad de los datos ya que es el único mecanismo que
servicios operativos los reutilicen. Esta reutilización permite que la
directamente manipula los datos. El esquema que define entidades

28 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL


Figura 11: Vistas sobre la Información
Migración conforme a la dirección
Llamadas de estratégica
servicio Eventos
Servicios tácticos
Adaptador del
servicio Documento de
oficina como vista
sobre datos
Caché
de
datos
Documento de
oficina como Importación
Almacén de
fuente principal datos
información sea integrada en el almacén de datos y se muestre
mediante fachadas de servicios en un esquema común ya que los
servicios de transformación son compartidos por ambos
mecanismos.
También se reconoce que no toda la información dentro del
almacén de datos se puede mostrar por medio de la interfase de
servicio y que puede haber una pequeña parte de los usuarios
dentro de la organización que necesitará acceso directo al almacén
de datos para llevar a cabo análisis complejo o especial. Echemos
un vistazo en mayor detalle a los factores que influyen en la
implementación exitosa del marco SoBI.
A un alto nivel, la guía de arquitectura para la aplicación de las
partes constitutivas de SoBI se puede resumir como lo muestra la
tabla 2. Los factores de éxito para el proyecto SoBI incluyen:
• Gobierno. Un proyecto SoBI no será exitoso si no tiene un
proceso de administración de cambios organizacionales asociado
en su lugar para brindarle soporte.
• Datos Empresariales y Estrategia SOA. SoBI se basa en la
existencia de un plan estratégico para aplicaciones SO dentro de datos dentro de esas fuentes tienen que consolidarse dentro del
la organización y en el reconocimiento de la importancia del
sistema de almacenamiento de datos de registro en
almacenamiento o aplicaciones de clase empresarial. Por
ejemplo, la organización no almacena el original de la
información comercial clave en planillas de cálculo.
• Informes de administración versus informes operativos. Se debe modelo de datos. Un enfoque incremental al diseño y construcción
delinear claramente entre los tipos de informe operativo y de
administración que serán necesarios dentro del marco SoBI.
SoBI será la versión única de la verdad para informes de
administración. Cubrirá los requisitos específicos del negocio
para BI. El almacén de datos de soporte contendrá sólo los datos registro a mantener en aplicaciones o almacenamientos
necesario para soportar estos requisitos.
• Propiedad de los datos. Aunque el almacén de datos contenga
los datos reunidos de múltiples fuentes y sistemas de datos,
desde el punto de vista orientado al servicio, el almacén de
datos no se deberá considerar como versión original o
almacenamiento por defecto para todos los requisitos de datos.
El propietario de estos datos sigue siendo el sistema de registro.
THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net
Arquitectura SoBI
Llamadas de
servicio Eventos
Servicios estratégicos
Fachada de
servicios
Aplicación
empresarial o
fuente de datos Exportación/
ETL
Almacén de
datos
Factores de éxito
Veamos estos factores de éxito en más detalle. El régimen es un
factor clave de éxito en el desarrollo de una solución orientada al
servicio. Es importante que una organización pueda controlar y
publicitar los servicios, formatos de mensaje, y estructuras que
soporta para evitar una proliferación descontrolada de servicios,
mensajes, y definiciones de entidades en el ámbito. Esto está
íntimamente relacionado con las actividades de definición de
esquemas y exige una administración activa por parte de un ente
regulador para asegurar que el sistema cumpla los principios
orientados al servicio.
La clave es encontrar el equilibrio en el nivel de regulación y
tener el suficiente control para brindar un marco para el desarrollo
satisfactorio y despliegue de servicios, pero no al grado de
paralizar la capacidad del sistema de responder ágilmente a las
necesidades del negocio.
En cualquier proyecto BI, la falta de claridad en el rol del
almacén de datos y el alcance de los datos a contener dentro de
este pueden causar problemas. En un diseño duradero, si el
alcance del almacén de datos no se administra, el ejercicio del
diseño crece al descubrirse las potenciales fuentes de datos y los
modelo de datos de almacén de datos.
El modelo de almacén de datos debe diseñarse para que sea
extensible y asegure que los datos de diferentes activos se puedan
añadir como un caso comercial puede hacerse para los datos. No
es práctico asumir que los datos de cada aplicación en el
panorama organizacional se pueden incluir en el diseño del primer
del almacén tendrá más posibilidades de éxito.
Para la estrategia de datos y SOA empresarial la aplicación
exitosa de SoBI se basa en la existencia de un plan estratégico
organizacional para aplicaciones SO y para sistema de datos de
empresariales. Cuando los sistemas y datos no tienen capacidad
de soporte de integración directa en el SOA propuesto por el
marco SoBI, se asume que el plan eventual de la empresa es
migrar estos sistemas y fuentes de datos a una plataforma que
soportaría este nivel de integración. Los ejemplos de tipos de
sistemas mencionados en este supuesto son sistemas que están
cargados y no pueden manejar la carga extra de servicios de
muestra y sistemas que no soportan
29
 Arquitectura SoBI
consultas online ni se basan en la exportación periódica de lotes.
Alguna de la información comercial crítica se mantiene en
almacenes o aplicaciones que no son los adecuados para datos de
este valor comercial, por ejemplo, las planillas de cálculo de
Microsoft Excel que tienen versiones originales de datos haciendo
de la planilla de cálculo el sistema de registro. Debe haber una
dirección estratégica para moverse hacia el punto donde están
tales datos en un almacén o aplicación empresarial y para que los
documentos se conviertan en vistas de estos datos en vez de
fuentes originales. La meta es moverse de documentos como
sistemas de registro a documentos como vistas de datos que están
en sistemas de registro.
Mantener la integridad
Se debe diferenciar claramente entre los tipos de reporte operativo
y de administración que serán necesarios dentro del marco SoBI.
La vista tradicional de almacén de datos como fuente única para
todas las necesidades de información corporativa no es válida
dentro del marco SoBI. El objetivo del marco SoBI es sostener el
principal de BI como "versión única de la verdad" pero también
mantener la integridad de los sistemas como propietarios de datos
corporativos.
Un informe operativo es probable que cumpla con uno de estos
criterios; exige acceso vivo a los datos, es necesario para
administración operativa del negocio (por ejemplo, información
sobre una transacción individual); no exige datos históricos para
comparaciones; y no exige datos resumidos (datos totales salvo el
total básico). Un informe de administración generalmente:
• Exige acceso a datos oportunos pero no inmediatos y
generalmente requiere que los datos resumidos se presenten
durante una franja horaria histórica pre determinada (por
ejemplo, comparaciones métricas mes sobre mes por activo).
• Presenta al usuario la capacidad de explorar los datos
presentados a voluntad para investigar rápidamente problemas
de rendimiento potenciales (por ejemplo, entrar a los datos) El
informe puede marcar áreas de fallas basadas en formateos
condicionales.
• Está definido para notificar sólo al usuario cuando se produce un
problema (informe de excepciones)
• Asiste en la previsión de rendimiento comercial.
• Asiste en las metas subyacentes de la persona y de la compañía
(por ejemplo, eficiencia de producción, aumento de ventas y
maximización de ganancia de producto).
Aunque el almacén de datos contenga los datos reunidos de
múltiples fuentes y sistemas de datos, desde el punto de vista
orientado al servicio, el almacén de datos no se debería considerar
como versión original. El propietario de estos datos sigue siendo el
sistema de registros.
SO discrimina claramente entre dos tipos diferentes de datos, a
saber, los datos que están dentro del servicio y los datos que el
servicio expone a las aplicaciones y otros servicios. Los datos
dentro son datos que el servicio utiliza para realizar operaciones
que brinda. Esta información es totalmente privada para el servicio
y nunca se expone en forma directa. Los datos fuera son datos
que son publicados por el servicio y utilizados para intercambiar
información y solicitudes con los clientes del servicio. Estos datos
se definen expresamente en términos de esquema organizacional.
La aplicación que es propietaria de los datos (también
mencionada como sistema de registro) es la responsable final de
30 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL
mantener sus propios datos; por lo tanto para permitir a las otras
aplicaciones solicitar cambios a los datos, la aplicación propietaria
tiene que exponer la funcionalidad de actualización de pedido
mediante su interfase de servicio. (Ver “Recursos” para más
información sobre estos dos tipos de datos).
Cuando se trabaja con integración de datos, SoBI es flexible
como para trabajar con estos casos de integración clave:
• Volúmenes de datos, que son transacciones simples especiales o
cargas de datos a granel de gran volumen.
• Integración con aplicaciones en paquetes de terceros y
esquemas de bases de datos exclusivas.
• Consolidación de bases de datos
• Integración de sistemas de legado, fuentes de datos
relacionales, no relacionales, estructuradas y semiestructuradas.
• Soporte para servicios de Red e integración con soporte
intermedio de mensajes.
Cuando se trabaja con BI, el SoBI apuntará a satisfacer varios
requisitos. Los negocios deben recolectar y sumar información de
fuentes dispares dentro de la organización y deben poder
compartir esta información en forma abierta con un diverso
patrimonio de aplicaciones en diferentes partes de la organización,
sin saber primero los detalles de cómo se consumirá la
información. Los negocios también deben aislar a los usuarios de
la estructura y formato subyacentes de datos, y en cambio deben
enfocarse en el significado comercial de los datos dentro de la
organización. Los consumidores de información se ocupan primero
de la semántica de los datos en vez de la sintaxis. Diferentes
partes del negocio deben poder compartir un lenguaje común
cuando se describan a sí mismos, y los negocios deben publicar los
datos más ampliamente dentro de la organización, diferenciando
entre publicación de datos y datos para análisis.
La publicación de piezas definidas de información como KPIs, o
métricas mediante mecanismos abiertos como servicios de Red,
permite a la información ser consumida fácilmente dentro de la
organización sin recurrir a aplicaciones especializadas. La
publicación de datos para análisis será igualmente parte clave de
los servicios provistos por el almacén de datos, pero esto tiende a
tener un target de público más limitado en la organización con
acceso a aplicaciones especializadas necesarias para análisis de
datos. Una de las metas de SoBI es permitir la publicación abierta
de información a un público más amplio de usuarios, y otros
servicios en la organización.
Patrones de integración SoBI
Otra meta para el marco SoBI es tomar un enfoque pragmático
hacia el trabajo con sistemas que no se pueden integrar
directamente en la arquitectura; por ejemplo, los que no pueden
soportar carga extra o los que no son escalables para soportar
integración directa.
Con esto en mente, el marco define un conjunto de escenarios
(o patrones) que describen categorías de sistemas fuente típicos
que los autores encontraron, junto con un enfoque de panorama
recomendado para integrar cada categoría del sistema. Se prevé
que esta recolección de patrones de integración evolucionará y
crecerá al integrar sistemas más diversos en la solución SoBI.
Estos patrones ayudan a tratar una de las prioridades clave
orientadas al servicio, a saber, la capacidad de soporte de
reemplazo de aplicaciones
 Arquitectura SoBI

Figura 12: Enfoque no adecuado de servicio-interfase

Llamadas de Migración conforme a dirección estratégica Llamadas de

servicio Eventos servicio Eventos

Servicios tácticos Servicios estratégicos

Adaptador de Fachada de
servicio
servicios
Aplicación
empresarial o
Exportación de fuente de datos Exportación de
Caché de datos/ETL datos/ETL
datos

Sistema no
escalable/ de carga Almacén de Almacén de
pesada datos datos

Figura 13: Reemplazo de implementación de BI

Llamadas de Llamadas de
servicio Eventos servicio Eventos

Servicios tácticos Servicios estratégicos

Fachada de
Adaptador de servicios y agregado servicio
Sistema(s) reemplazados por sistema
estratégico Aplicación
empresarial o
Caché fuente de datos
de
datos Sistema 3

Sistema 1 Sistema 2

con mínimo impacto en la empresa. El marco SoBI describe cómo
pueden abstraerse estos sistemas en una forma que asegura que
hay una mínima interrupción cuando los sistemas se reemplazan
finalmente.
Hemos enmarcado hasta ahora SoBI en términos de un
escenario ideal del mundo en el cual diversos sistemas de registro
puedan participar en la arquitectura SoBI en una forma orientada
al servicio. En un ámbito de un proyecto real, es probable que
haya un número de limitaciones que impacten en nuestra
capacidad de implementar SoBI puro. Hemos identificado varias
categorías de limitaciones que se tratarán a la brevedad, y por
ejemplo en cada caso identificamos un patrón, el cual, al usarse
junto con el principal de soBI de SOA empresarial y estrategia de
datos, asegura que la implementación del pragmático SoBI quede
dentro de los principios guía del marco SoBI.
Puro SoBI
Una situación ideal es aquella en la cual la aplicación es escalable
y flexible como para soportar la exposición de servicios y eventos
al bus de servicios, ya sea directamente o mediante una fachada
de servicios liviana (Ver Figura 8). Esta categoría de aplicación es
también capaz de soportar la exportación de datos al almacén de
datos, según se requiera.
Una limitación de tipo de sistema de fuente es el procesamiento
transaccional/en tiempo real. Algunas aplicaciones contendrán
información que es interesante desde una perspectiva de análisis y
desde una perspectiva en tiempo real. Tal aplicación puede
activarse al crear una fachada de servicio que exponga los
servicios de la aplicación a la organización, y que muestre eventos
cuando se producen cambios o actualizaciones “interesantes”. En
este caso, las

THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net 31

 Arquitectura SoBI
aplicaciones que estén interesadas en los eventos desde esta
aplicación podrán suscribirse a los eventos publicados. Los
suscriptores incluirán un agente de almacén de datos que
recolecte los eventos para integración con el almacén de datos
(Ver Figura 9).
Los sistemas no estructurados y semi estructurados son otra
limitación. En cualquier ámbito complejo hay probabilidad de que
haya un número de fuentes de datos que contengan información
que debe consumir una solución pero están en formatos no
estructurados o semi estructurados, como planillas de cálculo y
sistemas de administración de documentos. Con estos tipos de
sistemas es importante estructurar la información antes de
integración en almacén de datos, lo cual se logrará en una de
varias maneras. Una es aplicar la estructura al almacenamiento de
datos. Por ejemplo, la provisión de plantillas estructuradas y con
control de cambios para hojas de cálculo y documentos, para que
la información se pueda extraer con precisión y confiabilidad del
documento, implicará un cambio de proceso comercial. Otra
manera es imponer estructura sobre los datos leídos del
almacenamiento, lo cual es difícil porque se basa en supuestos
sobre semántica de la estructura existente
Recursos
“Datos Externos vs. Datos Internos" Microsoft Developer Network
(MSDN) Documento técnico, Pat Helland, Microsoft Corporation.
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnbda/html/dataoutsideinside.asp
“Lecciones Aprendidas de Almacenamiento de Datos: Tendencias
en Calidad de Datos”, Lou Agosta, Columna publicada en DM
Review Magazine (Febrero de 2005).
“Información como Servicio: Integración de Información Orientada
al Servicio”, Ronald Schmeizer, Zapthink.
www.zapthink.com/report.html?id=WP-0125
“Information Bridge Framework: Llevar SOA al Escritorio en
Aplicaciones de Oficina”, Ricard Roma i Dalfo, The Architecture Expectativa de Vida Corta
Journal 4, (Microsoft Corporation, 2004).
http://msdn.microsoft.com/architecture/default.aspx
?pull=/library/en-us/dnmaj/html/ibf-J4.asp
"Más de la mitad de los proyectos de almacén de datos perdidos”, significará el reemplazo de algunos de los sistemas de registro en
Robert Jaques, Gartner, (Febrero de 2005)
“Orientación al Servicio y su Rol en Su Estrategia de Sistemas proyecto BI. Por lo tanto, es vital definir un enfoque que soporte
Conectados” Un ensayo con un panorama de la visión de Microsoft estos sistemas en el ocaso de sus vidas y facilitar el proceso de
para orientación al servicio y arquitectura orientada al servicio en reemplazo cuando aparezca el sistema sucesor (Ver Figura 13).
computación empresarial. (Microsoft, 2005)
http://msdn.microsoft.com/architecture/soa/default.aspx?pull=
/library/en-us/dnbda/html/srorientwp.asp
"Arquitectura Orientada al Servicio: Consideraciones para
Sistemas Ágiles", Lawrence Wilkes y Richard Veryard, CBDI Sobre los autores
Forum, The Architecture Journal 2 (Microsoft, 2004)
http://msdn.microsoft.com/architecture/journal/default.aspx
?pull=/library/en-us/dnbmaj/html/aj2service.asp
de fuentes de datos y en base a que esto nunca cambie. Si se
sostiene este supuesto, la extracción programática se puede
lograr.
Asumimos que las fuentes de datos no empresariales
eventualmente se elevarán para soportar en forma más directa los
servicios que brindan (Ver Figura 10). Es importante cambiar
documentos de fuentes de información a vistas sobre la
información (Ver Figura 11).
Ahora veamos las limitaciones del sistema fuente. Para sistemas
de carga pesada habrá ocasiones en que habrá fuentes o sistemas
de datos que contengan datos que no se pueden interrogar en
tiempo real por limitaciones operativas o tecnológicas. Considere
estos ejemplos: un sistema muy utilizado puede no soportar el
agregado de una interfase de servicio que procese un nuevo
conjunto de consultas en forma frecuente; una fuente de
información que no soporta accesos concurrentes, como los datos
en una planilla de cálculo; y un acceso especial o en tiempo real a
datos dentro de un sistema de producción se considera un riesgo
para el funcionamiento eficaz día a día del sistema esencial de
negocios.
En estos casos la solución táctica es almacenar en memoria
caché los datos en un sistema que pueda luego brindar una
interfase definida y publicada a los datos o servicio. Este caché
permite a las aplicaciones y servicios tener acceso a la información
más actualizada posible mediante un servicio expuesto. Este
enfoque brinda un medio de escalar una fuente o aplicación de
datos para cumplir con los requisitos del negocio de manera que
dé una disociación clara entre los datos o aplicación y los servicios
brindados. Esta disociación es importante para el desarrollo futuro
cuando los datos o aplicaciones pueden moverse a una solución
más escalable y brindar el servicio directamente, o cuando la
aplicación se puede mejorar para que soporte al servicio
directamente. Una advertencia: habrá ocasiones en que el tipo de
datos que exigirá el sistema es puramente de naturaleza BI, como
la exportación de datos a gran escala. En estos casos el enfoque
interfase-servicio no será adecuado. (Ver Figura 12).
Asumimos que los sistemas con carga pesada eventualmente
mejorarán para soportar en forma más directa los servicios que
brindan.
Uno de los principios de SoBI es que la organización debe poner
en su lugar un plan estratégico para aplicaciones orientadas al
servicio y para sistemas de datos de registro a mantener en
almacenes o aplicaciones de la empresa. Este plan inevitablemente
el panorama existente, y en algunos casos hay probabilidad de
que estos sean reemplazados después de implementarse el
Este enfoque deberá producir una arquitectura que dé un equilibrio
entre permitir una fácil transición a nueva fuente de datos
mientras que no comprometa al equipo del proyecto a un gran
esfuerzo de desarrollo que finalmente sea desperdiciado.
Sean Gordon es arquitecto en estrategia de sistemas
empresariales de Microsoft y práctica de consultoría de
arquitectura, trabaja en la sede de la oficina en Escocia.

“Arquitectura Orientada al Servicio: Desafíos de Implementación” ,
Easwaran G. Hadhan, Principal, EDS The Architecture Journal 2,
(Microsoft 2004)
http://msdn.microsoft.com/architecture/journal/default.aspx?
pull=/library/en-us/dnmaj/html/aj2soaimpc.asp
Robert Grigg es consultor gerente y arquitecto empresarial en
Conchango, Reino Unido.
Michael Horne es consultor gerente y arquitecto de inteligencia
comercial en Conchango, Reino Unido.

Simon Thurman es evangelista arquitecto en el grupo de

desarrollo en Microsoft Developer Network, Reino Unido.

32 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL

Planificación de
Arquitectura Técnica
Por Waleed Nema
Síntesis
La necesidad de planificar la arquitectura técnica es bien
conocida por los directores, auditores y personal operativo
que viven una época de alta demanda y constante cambio
de la información. Los impulsores de los negocios para
esta necesidad incluyen la alineación de IT con el negocio
y el control de los niveles del servicios y los gastos. Este
análisis sintetiza la primera experiencia para la creación
de un plan de táctica de dos años de una infraestructura
de Arquitectura de Servidores para Windows (WSA) para
un departamento de operaciones informáticas. Se define
la arquitectura técnica además del alcance de los
resultados y los desafíos implicados.
La disciplina de planificación de arquitectura técnica sólo se ha
vuelto más popular en los últimos tiempos. Por lo tanto, no es muy debe alinearse IT. El equipo debe trabajar en conjunto con las
bien comprendida debido a la falta de experiencia, capacitación y
aún bibliografía especializada. La planificación de la arquitectura
técnica, cuando se realiza correctamente, trata de abrir todos los
aspectos de los entornos existentes y les asigna un estado
deseado consistente con el negocio. Tiende a crear una gran
variedad de preguntas y temas que nunca antes habían sido
planteados: algunos políticos, algunos comerciales y otros. En la
medida en que uno trata de clarificar la visión y el alcance de la
planificación de la arquitectura, puede encontrar dificultades
debido a la comprensión poco clara o a proyectos ocultos. También
se pueden encontrar dificultades debido a quién es uno o de dónde “SI SE ASUME QUE LA VISIÓN Y ALCANCE DE LA
proviene.
Si se asume que la visión y alcance de la planificación de la
arquitectura están acordadas con anterioridad, no existe garantía
alguna para la participación abierta, completa o interesada por
parte de los empleados operativos. Los beneficios de revelar
información deben superar el costo de la revelación de puntos
débiles y vulnerabilidades que sólo los empleados operativos
conocen. Una vez que se ha terminado la planificación del ciclo y
que se ha probado que la participación es recompensada por la
asignación de presupuestos y recursos, sólo entonces se puede
esperar más participación en los ciclos posteriores. Estando en
presencia de la primera de las desventajas, se debe hacer que los
directores transmitan el mensaje con fuerza y lo establezcan con
claridad. Para tener éxito, los directores deben definir con claridad del propietario también podrían pensarse como una norma para el
desde el comienzo los beneficios de la planificación de la
arquitectura.
Como ven, ya tienen su cuota de desafíos simplemente al
comenzar con el proceso de planificación de la arquitectura, más
los desafíos de mantener la participación de los empleados
operativos y los desafíos de obtener ayuda por parte de las
direcciones. Y si siguen el modelo de supervisar los planes de
acciones de seguimiento, tal como lo describiremos más adelante,
pueden parecer policías o auditores.
THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net
La única forma de que este esfuerzo sea exitoso es mostrar y
probar buenas intenciones. Las direcciones, que por lo general son
quienes dan las directivas para esta actividad, junto con el equipo
de arquitectura deben convencer a los empleados de que esta
actividad no trata de exponerlos sino de crear un entorno
operativo más efectivo y mejor que sirva de forma más óptima al
negocio. Al final, todos ganan, pero a expensas de aceptar los
cambios y dejar de lado las barreras y defensas.
Darle vida
Por sobre todo, los miembros de un equipo de arquitectura son
moderadores. Ellos deben trabajar con el personal operativo para
comprender el entorno existente. De hecho, el personal operativo
deben ser los arquitectos para el entorno existente porque
conocen las cosas mejor que nadie. El equipo de arquitectura debe
trabajar con los responsables de la planificación corporativa y del
negocio para crear la dirección y estrategia comercial con la cual
direcciones para comprender las tácticas y limitaciones y obtener
ayuda. También deben crear la perspectiva de la mejor práctica de
la industria que abarque el sistema, la tecnología, el proceso y las
personas. Es necesario que el equipo de trabajo reúna todo esto
en un plan factible y realista.
La arquitectura y la planificación, por lo general, dan un
panorama de un estado futuro que revela algún tipo de necesidad
o deseo. Si hablamos de una casa por ejemplo, un arquitecto
PLANIFICACIÓN DE LA ARQUITECTURA ESTÁN
ACORDADAS CON ANTERIORIDAD, NO EXISTE
GARANTÍA ALGUNA PARA LA PARTICIPACIÓN
ABIERTA, COMPLETA O INTERESADA POR PARTE DE
LOS EMPLEADOS OPERATIVOS.”
desarrolla un plan detallado que cumple las instrucciones del
propietario. Si hablamos de un modelo que se utilizará en una
comunidad en desarrollo, entonces estamos hablando de una
norma a seguir para mantener un presupuesto específico y un
panorama general. En este sentido, las instrucciones y requisitos
constructor. Para darle vida a un plano de arquitectura, se debe
diseñar y seguir un plano del proyecto de la construcción bastante
complejo. La belleza de la casa en el papel, no significa nada para
el propietario hasta que no la ve en la vida real.
Por lo tanto, tiene sentido pensar en la planificación de una
arquitectura como el proceso que traduce un conjunto de
instrucciones y requerimientos en normas que el constructor
33
 Plan De Arquitectura Técnica

puede implementar. Si el edificio ya existe, arquitectura significa

proyectar nuevos requerimientos y mejoras para la estructura Plan táctico para la arquitectura
existente.
El mundo técnico no ha aprendido demasiado de la industria de del servidor de Windows
la construcción bien establecida. Las funciones del propietario,
arquitecto, constructor e inspector son bien conocidas en el campo
Este esquema general es una tabla de contenidos parcial
de la construcción pero no lo son de igual modo en el campo
técnico, en particular la función del inspector. En la industria de la para el plan táctico de la arquitectura del servidor de
construcción, el constructor es casi siempre una entidad diferente Windows (WSA)
a la del arquitecto. El inspector podría también ser una entidad
independiente pero, con frecuencia, pertenece a la misma que el Introducción
arquitecto, quienes actúan en representación del propietario y Disciplinas
deben aprobar el trabajo del constructor. Servicios de hosting de Web
Nosotros, personas de técnica, necesitamos permitir y alentar a
Resumen ejecutivo
los arquitectos para que asuman el rol de inspección y supervisión
en la implementación de los planos de arquitectura. En IT, los Introducción
patrocinadores de los proyectos son con frecuencia los Antecedentes
propietarios. Orientadores del negocio
Objetivos
Alcance
“YA QUE LOS ARQUITECTOS REPRESENTAN Concepto de la solución
PATROCINADORES EJECUTIVOS EN ESTE MODELO, Arquitectura del servicio
ES NECESARIO QUE SEAN CONSCIENTES DEL CASO Optimización del MOF
DEL NEGOCIO E IDENTIFIQUEN LAS Modelo del servicio
RECOMENDACIONES DE LOS ELEMENTOS DE Ofertas del servicio
ACTUACIÓN Y ESTABLEZCAN PRIORIDADES Compromisos a nivel
CONFORME A ELLO.” operativo/servicio
Solicitud del servicio
Aseguramiento de calidad
Los arquitectos deberían actuar por sí mismos y asumir toda la
autoridad que sea necesaria. Con este cambio imprevisto, no sólo Modelo del equipo
la planificación de la arquitectura es responsable de producir Servicios de soporte
planos y normas, sino que también debe ser responsable de Arquitectura de tecnología
supervisar la implementación de los planos de arquitectura. General
Ya que los arquitectos representan patrocinadores ejecutivos en Estrategia de aplicación corporativa
este modelo, es necesario que sean conscientes del caso del Definiciones
negocio e identifiquen las recomendaciones de los elementos de
Zonas de confianza
actuación y establezcan prioridades conforme a ello. El
patrocinador ejecutivo es en última instancia, responsable por el Perfiles del hosting (patrones de
proceso de la arquitectura y su implementación exitosa. implementación)
Para resumir, la planificación de la arquitectura debe tratar Instrucciones de arquitectura
estos cinco aspectos: estandarización, avances, supervisión de la Modificación del MOF
implementación, prioridades orientadas al negocio y seguimiento Gestión de dependencias
de la gestión; y podemos definirlo de la siguiente manera: la Control de la producción
planificación de la arquitectura técnica es un proceso patrocinado
Operación del MOF
por una dirección ejecutiva que traduce las necesidades del
negocio existentes, los desafíos y deseos en un conjunto de Monitoreo
normas, planes y elementos de actuación a los que se les da Soporte del MOF
prioridad, que sugieren y supervisan los avances con vistas a una Gestión de problemas/incidentes
mejor experiencia del cliente y una excelencia operativa. Aislamiento del problema
Informe del error mejorado
Lo que es y lo que no es Optimización del MOF
La arquitectura técnica tiene como finalidad aumentar la capacidad
Estrategias de seguridad
y madurez del servicio. Se trata de modelos, estándares y
acciones (mejoras). Es la especificación de una solución de alto Estrategias de continuidad del
nivel pero no es una especificación de diseño. Las especificaciones negocio
de una solución son como establecer un presupuesto y el tamaño Recomendaciones para el plan de actuación
del lote del modelo de una casa en una comunidad en desarrollo Apéndice
en vez de tomar en cuenta las especificaciones de su diseño. Una Referencias
vez que se aprueban los proyectos de implementación y diseño del Diagramas
seguimiento son por lo general aplicados a servicios nuevos y
Otros servicios (archivar e imprimir, directorios,
mejoras de alta escala.
La arquitectura técnica no es simplemente un diagrama de Visio datos)
de configuraciones de un servidor de archivos. La arquitectura es, Vía del servidor
ya sea utilizar el espacio del nombre de un servidor de archivos de Productos consolidados
lógica (como por ejemplo Sistemas de Archivos Distribuidos); o Infraestructura
seguir un modelo de gestión distribuida o centralizada o bien Desarrollo
utilizar un modelo de hosting, compartido, de libre acceso para Políticas y procedimientos
bases de datos o sitios Web.

34 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL


Tabla 1: Muestra de las recomendaciones de un plan de actuación
Sección Prioridad/ Objetivo Recursos/
Plazo Técnica
Modelo del servicio
Prioridad A Dar a conocer el modelo de WHG
3.x
Q4 2005 hosting del proveedor del
servicio de Internet (ISP)
Monitoreo
Prioridad A Monitorear servidores/sitios Web WHG
Q2 2006 para tiempo de inactividad,
rendimiento y optimización
3.y
Control de la producción
Prioridad B Crear una herramienta para Asignación
3.z
Q4 2006 publicar un sitio Web consultoría
Estos tipos de decisiones tienen consecuencias trascendentes y por
lo tanto son decisiones al nivel de la arquitectura.
La arquitectura técnica trata por supuesto más sobre los
procesos. De hecho, es con frecuencia el proceso y no la
tecnología que puede componer o interrumpir un servicio. Los
procesos, por lo general, comprenden asuntos de personas que
sugieren ideologías políticas y a veces ¡Son los aspectos más
peligrosos de todos! Aún peor es cuando el sistema no cuenta con
verificaciones y balances para trabajar con estos asuntos.
La arquitectura técnica trata la medición. Las personas deben
sentir que la medición se crea para ayudarlos y no para
exponerlos. Las direcciones debe mostrar sus intenciones
claramente cristalinas para obtener la confianza y la aceptación
total del personal. Sólo entonces tenemos cualquier oportunidad
para trabajar. La dirección debe comunicar las razones de la
medición, que incluye la realización o la conciencia sobre cuánto
nos falta aún, mejoras para alcanzar los objetivos y una
estimación de lo que es requerido. Los directores deben evitar la
desilusión pública al realizar una manipulación positiva cuando se
realiza un informe como por ejemplo “una mejora en el porcentaje
en el último período” mientras aún se mantienen la información en
absoluta reserva interna hasta que se cierran los números para los
“LA ARQUITECTURA ES UN CICLO CONSTANTE TAL
COMO LO ASEGURAN VARIOS SISTEMAS COMO POR
EJEMPLO EL SISTEMA DE OPERACIONES DE
MICROSOFT, EL CICLO DE DEMING Y EL CICLO DE
GESTIÓN/COBIT”.
objetivos del Indicador de Rendimiento Clave (KPI). La dirección
debe probar sus buenas intenciones, ya sea al obtener los recursos
requeridos o al aceptar un progreso más lento y resultados menos
notables.
La arquitectura técnica se refiere a la automatización. Esta es la
clave para la efectividad, los procesos deterministas y la
estabilidad. La automatización le otorga al personal operativo más
tiempo para centrarse en el análisis y la optimización, que forman
la base para la optimización del servicio.
La arquitectura técnica también consiste en el monitoreo. La
única forma de estar en el control es observando de forma
constante el camino y las dimensiones. La arquitectura
proporciona una vía y se asegura de observar las dimensiones
correctas. También ayuda a crear un alerta y un sistema de
escalabilidad –posiblemente una reacción correctiva automatizada.
La arquitectura es un ciclo constante tal como lo aseguran
varios sistemas como por ejemplo el sistema de operaciones de
THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net
Plan De Arquitectura Técnica
Estimación Indicador del éxito
trabajo
Publicar el documento en SCL, OLC y los términos y
condiciones de solicitud del servicio nuevo.
Asignar la función de encargado de monitoreo a una persona
determinada quien será responsable de atender todos los
eventos de la terminal de monitoreo.
Explorar la funciones nuevas del MOM 2005, incluyendo IIS
Management Pack, Sitios Web y Servicios MP.
Permitir el escalamiento y la mensajería de texto para
errores muy importantes como por ejemplo inactividad del
servidor.
Realizar un contrato de desarrollo que construya
herramientas de publicación de un sitio Web tal como han
sido definidas en el prototipo existente.
Microsoft, el ciclo de Deming y el ciclo de gestión/COBIT. Es
básicamente una etapa de planificación seguida por operaciones
de monitoreo, cuyos aprendizajes introducen optimización y
mejoras en el nuevo ciclo.
Documentación del plan
La estructura principal del plan táctico de la arquitectura del
servidor de Windows (WSA) se encuentra en las disciplinas de las
áreas funcionales como por ejemplo servicios Web hosting,
servicios de directorios, y demás (Ver el esquema “Plan táctico
para la arquitectura del servidor de Windows”). La vía del servidor
se aplica a los cambios de tecnología específicos en el período
táctico. La última sección, productos consolidados, recoge todas
las recomendaciones del plan de actuación de las secciones y las
clasifica en tres áreas para colaborar con el proyecto de
seguimiento: infraestructura, desarrollo y políticas y
procedimientos.
La estructura principal de la arquitectura de cada servicio de
disciplina –servicios Web hosting, servicios de directorios y
demás– se encuentra en la sección del concepto de la solución que
está dividida en arquitecturas de tecnología y servicios que a su
vez se basan en el Marco Operativo de Microsoft (MOF). La
introducción incluye las secciones de antecedentes, orientadores
del negocio, objetivos y alcance, y sus objetivos establecidos,
como por ejemplo, el número de 9s para alta disponibilidad, entre
otros.
El resumen ejecutivo consta de un resumen de una página de
los beneficios actuales y futuros, metas y técnicas así como
también las recomendaciones más significativas del plan de
actuación.
Las recomendaciones del plan de actuación son con probabilidad
el resumen más importante de todas las especificaciones de la
solución y mediciones del éxito, ya que el personal operativo
establece prioridades y plazos e indican en la columna de
recursos/técnicas si pueden llevarlas a cabo por sí mismos o si
necesitan una subcontratación (Ver Tabla 1). Establecer la
planificación de la arquitectura como una disciplina y un rol ha sido
muy provechoso, aún antes de completar el primer ciclo táctico. Es
un placer ver la finalización del plan y el comienzo de la actuación.
Este resultado no se obtiene sin costos ni esfuerzos y depende de
todos los participantes del equipo de trabajo.
Sobre el Autor
Waleed Nema es líder de equipo para la planificación de
arquitectura técnica de Windows en el Departamento de
Operaciones Informáticas de Saudi ARAMCO. Waleed desea
agradecer a su dirección, personal operativo y equipo de
arquitectura por el gran éxito de este proyecto.
35
 Lenguaje de
Arquitectura de Software
de Conducta
Por Behzad Karim
Síntesis
La arquitectura de software es una palabra clave en estos
días para las personas de nuestra profesión. Parece que
todos desean descubrir el verdadero potencial de la
arquitectura de software y lo que puede aportarles. La
idea básica de la definición de arquitectura es el diseño de
estructura de software y la interacción de objetos antes de
la etapa de diseño detallado. Aunque se está sugiriendo la
definición seria de arquitectura sólo para proyectos
grandes, podría decirse que cualquier trabajo de
implementación o construcción de software debe estar
precedido por una etapa de diseño y aprobación de la
arquitectura. Conozca el BASL, un lenguaje que unifica la
definición de arquitectura de software con la
implementación de software (codificación).
Uno podría decir con razón que existen como mínimo una
docena de estándares y herramientas bien definidos que se
pueden utilizar para definir la arquitectura de software. Tenemos
estándares y herramientas para definir, comunicar, e incluso
generar plantillas para diseño de software. Algunas de estas
herramientas inclusive pueden funcionar bilateralmente, por un
código traductor a un modelo de arquitectura y viceversa. ¿Porqué
entonces hay una necesidad de otro lenguaje o modelo de
programación?
Aunque existen muchas maneras de definir la arquitectura de
software en términos de paquetes, componentes, y conectores (es
decir, la estructura de software), cuando llega el momento de
definir la conducta dinámica del software, no podemos brindar una
definición para estos, ni comunicarlos, ni siquiera diseñarlos
claramente. No obstante, la conducta dinámica del software es
realmente lo que hace nuestro software después de extenderse en
el ámbito de la producción.
Las técnicas más actuales, conocidas (y establecidas) utilizadas
para definición de arquitectura de software provienen de una era
en la cual la arquitectura de software todavía era un mito. Aunque
estas técnicas (y herramientas) realizan un excelente trabajo al
definir la estructura y componentes de sistemas de software, no
tienen la capacidad de englobar y definir la conducta del software
y diferentes interacciones con el ambiente contra la dimensión de
tiempo. Se podría decir que estas herramientas no eran para el
arquitecto de software, tanto como para el ingeniero de software.
La necesidad básica del arquitecto de definir la esencia de un
sistema de software en forma abstracta y de brindar la imagen de
36 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL
un sistema vivo sigue sin respuesta. O bien estamos
profundizando demasiado los detalles de implementación o
meramente estamos comunicando la superficie externa del
sistema. En ambos casos dejamos de lado el ingrediente
fundamental del software: los aspectos de conducta dinámica del
sistema. En demasiados proyectos el equipo de desarrollo
descubre estos aspectos del sistema en un diseño detallado o
etapa de codificación.
Enfrentar la realidad
Otro dilema es el espacio creciente entre el código y la
arquitectura original del sistema. Utilizamos herramientas y
lenguajes diferentes en el proceso de construcción de software. La
arquitectura de software utiliza una especie de lenguaje de
modelado mientras que la persona a cargo del desarrollo utiliza un
lenguaje de programación. Como resultado, especialmente
después de que el sistema se envía a producción, documentos,
diagramas y código se desincronizan. ¿Alguna vez tuvo que revisar
de nuevo un sistema que había diseñado en el pasado, sólo para
descubrir que la arquitectura no tenía similitud con el diseño
original?
Esta analogía es real para diagramas de clase, casos de uso, y
casos de evaluación. El problema usual con estos documentos es
que todos parecen volverse obsoletos después de que el software
pasa a producción. Estos problemas surgen por la falta de un
“EL RESULTADO FINAL DE NUESTRO TRABAJO NO ES
SOLAMENTE UN PRODUCTO O ARTÍCULO ESTÁTICO,
SINO UN ORGANISMO VIVO, CON RESPUESTA”
medio compartido o un punto de referencia singular para la
arquitectura y solución física. Lo ideal sería que la arquitectura y
códigos sean caras inseparables de una misma realidad: el sistema
de software.
La disciplina de ingeniería-software ha recorrido un largo
camino desde los primeros días de su existencia. A través de su
viaje, se han utilizado las ideas de otras profesiones de ingeniería.
Un factor fundamental que diferencia nuestra profesión de otros
campos de ingeniería es la naturaleza de nuestro trabajo, y más
específicamente, el resultado de nuestro trabajo. Comenzamos con
pensamientos, ideas, y visiones básicas y las desarrollamos para
convertirlas en realidad que pueda cambiar las vidas de millones.
El resultado final de nuestro trabajo no es solamente un producto
o artículo estático, sino un organismo vivo, que responda.
La ingeniería de software como disciplina continuará trabajando
con más complejidad en la construcción

de sistemas de software. Como si esto fuera poco, los usuarios de
estos sistemas exigirán sistemas más inteligentes, interfases más
simples, y funcionalidades más enriquecidas. Los constructores de
software necesitarán ocuparse de muchos detalles para cumplir
con los requisitos sofisticados del usuario. Aunque no se ha
probado estadísticamente, la experiencia demuestra que al
aumentar el alcance, tamaño y dependencias de los sistemas de
software, la complejidad aumenta exponencialmente. Es evidente
que la complejidad es un tema clave que nos gustaría que la
arquitectura de software pudiera tratar.
Existen muchos enfoques a la arquitectura de software
publicados por autores respetados en la disciplina. Aunque respeto
y disfruto todos los documentos de investigación publicados sobre
este tema, me gustaría reducir mi lista de puntos clave sobre
manejo de complejidad a sólo dos factores:
• El enfoque total en diseño de software. Este factor enfatiza un
enfoque integral en el diseño de arquitectura de software,
comenzando desde el sistema más importante (producto o gran
solución) y dividiéndolo en subsistemas que se pueden diseñar
en forma separada, y luego enfocando cada subsistema
iterativamente de manera similar para dividirlo en componentes
independientes.
• Descomposición o desglose del sistema. Este factor significa
diseñar componentes que estén emparejados aproximadamente
y tengan interfases claras e intuitivas. La condición previa para
construir componentes adecuados es tener una idea clara de la
conducta dinámica del sistema y subsistemas. Los componentes
deben tratar los requisitos funcionales del subsistema que los
rodea y al mismo tiempo encajar armónicamente con otros
componentes.
Estos requisitos impulsaron la investigación y la creación del
Lenguaje de Arquitectura de Software de Conducta (BSAL). El
objetivo principal de BSAL es:
• Brindar un modelo de implementación que pueda empezar a
nivel de arquitectura-sistema, permitiendo que el arquitecto
defina el sistema, subsistemas, estados y conducta dinámica del
sistema y todos sus subsistemas.
Figura 1: Fundamentos básicos de los sistemas
Sistema
-Inicial: Estado
-Final: Estado
1 1
* -Estado
Estado -Estado -Conducta
+Entrada() * *
+Salida()
THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net
BSAL
• Facilitar una plataforma unificada para definición de arquitectura
de software (estructura y conducta) e implementación de
software (codificación). BSAL tiene el objetivo de ser el lenguaje
común del arquitecto y la persona a cargo del desarrollo.
• Permitir que el diseño de arquitectura del sistema (incluyendo la
conducta) se cumpla en el nivel de implementación. Este
cumplimiento se puede lograr por la ayuda de ámbitos de
desarrollo interactivos (IDEs). La separación de roles y
mecanismos de autorización se pueden implementar claramente
en un ámbito de desarrollo BSAL.
• Utilizar una plataforma que pueda cambiarse y mejorarse
fácilmente por medio de aportes adicionales en el futuro (BSAL
está basado en el modelo OOD-OOP).
¿Por qué “Conducta”?
Para entender mejor la importancia de la conducta y porqué se
ha magnificado en la fase de diseño de arquitectura de BSAL,
consideremos una situación del mundo real. Se nos ha dado la
tarea de diseñar mejoras importantes al sistema de membresía de
un sitio Web integral negocio-a-consumidor (B2C). Para hacer la
situación más crítica, suponga que el sistema ha sido construido
por un par de empleados anteriores que actualmente no se
“UN ARQUITECTO EXPERIMENTADO BUSCARÍA
ENTENDER LA CONDUCTA DINÁMICA DEL SISTEMA
AL INTERACTUAR CON OTROS SISTEMAS Y AL
RESPONDER A LOS PEDIDOS DEL USUARIO, EN VEZ
DE CONSIDERAR CAMBIOS O NUEVAS FUNCIONES ”
encuentran disponibles para ayudarnos. Un sistema así
normalmente tendría características que faciliten la creación de
nuevos miembros, la actualización de datos de miembros,
manipulación de los derechos de miembros, autenticación y
autorización, y brindar carteras de miembros (tarjetas de crédito,
dirección, e información de facturas)
Como nuestro trabajo es ocuparnos de llevar a cabo
técnicamente una revisión importante del sistema principal de
membresía, nuestra primera prioridad sería tratar de entender
este sistema en su totalidad.
1
* -Conducta *
Conducta Mensaje
37
 BSAL
Por lo tanto, después de examinar la solución que funcione,
buscaríamos documentos y borradores sobre la arquitectura del
sistema. Suponiendo que tuvimos suerte de encontrar algunos
diagramas de clasificación podremos sentirnos aliviados al
principio. No obstante, con la investigación adicional y el análisis,
probablemente encontremos que los diagramas mismos están
incompletos y desactualizados. Al crecer la frustración, en nuestra
búsqueda de entendimiento de la arquitectura integral del sistema,
eventualmente llegaríamos a la conclusión de que sólo el código
puede revelar la arquitectura de este sistema. Tendríamos que
arremangarnos y comenzar a leer el código renglón por renglón. El
código siempre es la fuente definitiva de información que podrá
revelarnos (aunque no fácilmente) la arquitectura del sistema.
¿Qué parte de la información nos ayudaría más a visualizar y
entender un sistema de software? Aunque sería útil descubrir las
normas e interfases de interacción del sistema, obtener los
documentos de análisis comercial del sistema, tener los borradores
de diagrama de clasificación actualizados y obtener documentos de
requisitos y diseño técnico actualizados, que la persona original a
“BSAL FUSIONA LA ARQUITECTURA (ESTRUCTURA Y
CONDUCTA) Y EL CÓDIGO EJECUTABLE EN UNA
SOLA FUENTE”
cargo del desarrollo explique la conducta del sistema y explique
las condiciones de eventos y secuencia de cambios de estado del
sistema sería la elección más favorable.
Esta elección es favorable porque la conducta del software y los
cambios evento/estado son muy difíciles de captar sin la ayuda
directa de diseñadores previos del sistema. Aunque la falta de
información actualizada es una desventaja total en este caso,
confrontarse con demasiada información también puede llevar a
un desastre. Ambos extremos del espectro información-
disponibilidad son situaciones desfavorables.
Un arquitecto experimentado buscaría entender la conducta
dinámica del sistema al interactuar con otros sistemas y al
responder a los pedidos del usuario antes de considerar cambios o
nuevas funciones. En este caso particular, la conducta dinámica
del sistema estaría arraigada profundamente dentro de la
estructura física de la solución (el código fuente).
Es importante remarcar que los aspectos de conducta de un
sistema de software juegan un rol fundamental en la revelación de
su verdadera naturaleza, por lo cual BSAL comienza la definición
de un sistema de software delineando los subsistemas, estados, y
patrones de conducta.
Conozca BSAL
Conozcamos el simple y eficaz lenguaje para definir arquitectura
de software (y codificación). Aunque el BSAL es un lenguaje de
definición de arquitectura, es también un lenguaje de
programación. Aunque hay otros aspectos de la arquitectura de
software que podrían remarcarse, el foco en el BSAL estuvo en
brindar un modelo en general simplificado de definición de
arquitectura y al mismo tiempo facilitar un modelo de
programación flexible.
Considerando que los aspectos de conducta de sistemas de
software son los más importantes, BASL enfatiza la definición de
patrones de conducta en la fase de definición de arquitectura. De
hecho, sin definir los patrones de conducta del sistema no puede
usted proceder a implementar modelos más bajos en el sistema.
La sintaxis de lenguaje de programación de BSAL podría ser
cualquier lenguaje moderno de programación orientado al objeto.
38 www.architecturejournal.net - Journal 6 – THE ARCHITECTURE JOURNAL
Aunque los principios del lenguaje se pueden aplicar a cualquier
lenguaje moderno OOP (y por cierto espero ver esto en el futuro),
C#.NET se usó aquí para mostrar las ideas de BSAL debatidas.
Antes de proceder con lo siguiente, puede ser útil brindarle un
escenario de uso en base a la función para BSAL:
• El arquitecto de software utiliza el lenguaje para definir las
características importantes del sistema de software. A saber,
sistema, subsistema, estado, conducta, y objetos de mensaje
son los definidos por el arquitecto. Estos son definiciones de
componentes a alto nivel para cualquier solución de software.
• El ingeniero de software utiliza la salida directa del trabajo del
arquitecto (código fuente BSAL de alto nivel) como entrada a su
trabajo, brinda diseño detallado, y comienza implementando
estados, mensajes, componentes y clases dentro de
subsistemas.
• El ingeniero de pruebas utiliza el código fuente BSAL para
analizar conductas del sistema y crear escenarios de evaluación
en casillas escritas.
• El analista utiliza el código fuente BSAL para analizar el desglose
del sistema de alto nivel y las definiciones de componente y para
entender la conducta del sistema en vez de proponer mayores
mejoras al sistema.
BSAL está basado en el paradigma orientado al objeto. El
importante agregado de BSAL es el uso estándar y común de unos
bloques de construcción en la definición de software. Estos bloques
de construcción pueden por sí mismos crearse utilizando un
lenguaje OOP moderno. La norma básica del BSAL es que cada
parte del código debe estar dentro del objeto de un sistema. Un
objeto de sistema en sí puede encapsular sistemas más pequeños
o subsistemas. El objeto de sistema puede contener campos
(atributos), debe tener al menos dos objetos de estado, y puede
tener objetos de conducta y mensaje. El código ejecutable sólo
puede escribirse dentro de objetos de estado del sistema, lo cual
significa que el objeto del sistema (o del subsistema en este caso),
objeto de conducta y objetos de mensaje sólo definen la conducta
y estructura del sistema (la arquitectura). No obstante, casi todos
los códigos ejecutables del programador estarán dentro de objetos
de estado, lo que simplifica mucho la tarea de diseño de
arquitectura y lleva a la arquitectura hacia el código del
programador.
Desglose de los componentes
Los componentes de bajo nivel de BSAL se podrían implementar
en cualquier lenguaje moderno de programación orientado al
objeto como C#.NET, Java, o C++ (los detalles de estos
componentes no se encuentran dentro del alcance del presente).
La presentación de un modelo operativo completo de BSAL será
tema principal de un debate futuro. Los componentes básicos de
alto nivel del BSAL son sistema, estado, conducta y objetos de
mensaje. Estos son los objetos que los arquitectos del sistema
generalmente definen. Estos objetos estipulan y definen los límites
y bases elementales del sistema (Ver Figura 1).
El objeto del sistema es el componente más importante de
BSAL. Es el objeto el que engloba todos los demás componentes
del sistema. Puede diseminarse a través de múltiples archivos,
módulos y/o paquetes. Un sistema puede estar compuesto de uno
o más subsistemas. Un sistema puede englobar subsistemas,
estados, conductas, mensajes y campos y propiedades
personalizados. El sistema debe tener como mínimo dos estados, a
 BSAL
saber, estado inicial y estado final. Cuando se inicia el sistema, (
inmediatamente va al estado inicial. Cuando el sistema tiene señal //do some stuff
de apagado, va a estado final. Un sistema puede tener estados
personalizados ilimitados.
return O:
Un sistema tiene estado inicial y final; puede recibir mensajes )
(entrada al sistema); puede verificar estados de conducta para )
que pueda cambiar y administrar estados conforme a eso; puede
implementar patrones de conducta activando o finalizando El objeto de conducta es donde se definen los patrones de
estados; y puede enviar mensajes a otros sistemas (salida del conducta del sistema. la definición de conducta es el corazón de la
sistema). administración de estado de un sistema de software.
Generalmente, una definición de conducta contiene una o más

public class member: System “DEBIDO A QUE LOS PROBLEMAS DE TECNOLOGÍA

( DE INFORMACIÓN SIGUEN VOLVIÉNDOSE MÁS
protected State COMPLEJOS, LOS INGENIEROS DE SOFTWARE
createMember: NECESITAN LENGUAJES (Y MODELOS DE
public member( PROGRAMACIÓN) QUE PUEDAN OCULTAR Y
State istate. State ENGLOBAR MAYORES NIVELES DE DETALLE”
Fstate) : base(
llamadas de método relacionadas con las condiciones para
Istate. Fstate)
completar y/o activar ciertos estados del sistema. Las definiciones
( de conducta no deben contener ningún código ejecutable que no
) sean los resultantes del cambio de estado, de configurar un campo
) o atributo, o de enviar un mensaje a otros sistemas. Aquí el único
objetivo es definir la conducta del sistema bajo ciertas condiciones
El objeto de estado define una etapa que el sistema puede o circunstancias. Un objeto de conducta básicamente engloba
atravesar para realizar una tarea específica. Las definiciones de condiciones, cambios de atributos, envío de mensajes, y
estado organizan las unidades de trabajo en un cierto orden finalización y activación de estados.
lógico. Los estados implementan la primera funcionalidad del
sistema. Gracias a la profesión
Un objeto de estado tiene dos métodos obligatorios llamados Un objeto de mensaje engloba el flujo de información sincrónica y
entrada () y salida (). El método de entrada () es cuando el estado asincrónica entre diferentes sistemas. Un objeto de sistema sólo
se activa; la salida () es cuando el estado tiene señal de haber puede recibir objetos de mensaje que hayan sido definidos para
terminado. Un objeto de estado puede tener métodos esto. Una definición de mensaje generalmente contiene un ID de
personalizados ilimitados. mensaje, un encabezamiento de mensaje, y un cuerpo de
Un sistema puede cambiar de estado internamente o puede mensaje. La implementación subyacente de mensajes se puede
cambiar de estado en respuesta a una interacción externa con dejar al ambiente y marco específicos en uso. El patrón de
otros sistemas o ambientes. (Por ejemplo, recibir un mensaje de conducta del sistema se verifica o bien cuando el sistema recibe
otro sistema puede activar un cambio de estado en un sistema). El cualquier mensaje nuevo, o bien cuando cualquier estado dentro
lugar común donde cambia un estado se implementa dentro de un del sistema se está finalizando.
objeto de conducta o de otro método de salida () de estado. Debido a que los problemas de tecnología de la información
Un objeto de estado tiene un método de salida() y de entrada(), siguen volviéndose más complejos, los ingenieros de software
se puede activar mediante un objeto de conducta u otro objeto de necesitan lenguajes (y modelos de programación) que puedan
estado, puede completarse a sí mismo, debe verificar los objetos ocultar y englobar mayores niveles de detalle. Como ya hemos
de conducta relacionados con el cuando se completa, puede tener mencionado, la analogía de desarrollo OOP tradicional respaldada
propiedades y métodos personalizados y puede funcionar como un con notas de modelo de software puede ser restrictiva y a veces
cable separado de ejecución (estados paralelos): engorrosa. BSAL fusiona la arquitectura (estructura y conducta) y
el código ejecutable dentro de una sola fuente. Los arquitectos e
public class MyInitState: ingenieros de software necesitan comunicarse, compartir y
State construir ideas. Para tener soluciones mejoradas o alternativas
para sistemas vivos, necesitan obtener rápidamente la esencia de
( los sistemas de software. Poder entender rápidamente y en forma
public MyInitState( precisa un sistema de software es una gran ventaja. BSAL es una
string sn. Int sid) : respuesta posible a estas necesidades y, con suerte, un paso
base (sn.sid) positivo para abrir nuevos horizontes en el futuro de la profesión
( de ingeniería en software.
)
public override int entry() Sobre el Autor
( Behzad Karim (MCSD. NET, MCT) es gerente de proyectos de
//do some stuff software en TEPUM SIGMA Consulting and Development Center
return o: (www.sigma.net.tr) en Estambul, Turquía, donde lidera equipos de
desarrollo de software que presentan proyectos EAI. Behzad ha
) sido el encargado de desarrollo de software y arquitecto de
public override int exit() software desde hace casi 18 años. Contacte a Behzad en
bkarim@sigma.net.tr

THE ARCHITECTURE JOURNAL– Journal 6 – www.architecturejournal.net 39