Documentos de Académico
Documentos de Profesional
Documentos de Cultura
ejerza el arte y
contribuya con sus ideas en
www.ArchitectureJournal.net
Recursos que sirven de base
Planificación de
Arquitectura Técnica
Lenguaje de Arquitectura
de Software de Conducta
Contenidos
Prólogo 1
Por Avindra Sehmi
Síntesis
Descubra los desafíos que enfrentan las formas general no se comunicaban entre ellos. Tercero, existían varias
asimétricas de gobierno y un enfoque para tratar estos funciones IT importantes (como la arquitectura) y resultados
deseados (como productividad y reutilización) que no contaban
puntos en particular con especial atención en la forma con un comité directivo. Por lo tanto, el enfoque del comité
en la que la empresa comprende los riesgos que surgen directivo era incompleto, inconsistente y por lo general
de la relación con geometrías exógenas, además de los producía resultados por debajo de lo óptimo.
riesgos más comunes asociados con la gestión de su
geometría endógena. Gobierno en tiempo real
Pasó la moda de los comités directivos, y varias grandes
Existen en la industria de software dos visiones opuestas de organizaciones IT comenzaron a prestar atención explícita a los
arquitectura orientada al servicio (SOA-Service Orientated asuntos del gobierno de SOA. En los casos en los que se
Architecture) las cuales podemos dividir en SOA 1.0 y SOA 2.0 tercerizaban cantidades importantes de actividad IT, este
(Ver Tabla 1). Nuestro enfoque para el gobierno se dirige a SOA gobierno incluía asuntos de compra y relaciones con
2.0. Una de las preguntas centrales que plantea Christopher proveedores claves.
Alexander en su trabajo más reciente en cuatro tomos, La Con SOA, contamos con un nuevo enfoque para lograr
Naturaleza del Orden, es cómo obtener el orden sin imponer una realizar las cosas. También tenemos los problemas anteriores
planificación descendente (central) o por el contrario, cómo de gobierno más algunos nuevos. Existe una gama compleja de
permitir y fomentar una innovación ascendente sin perder el actividad orientada al servicio cada una de las cuales necesita
orden (Ver “Recursos”). Alexander fomenta el concepto de
transformaciones que preservan la estructura y sostiene que “CON SOA, CONTAMOS CON UN NUEVO ENFOQUE
bajo ciertas condiciones, el orden a gran escala puede darse PARA LOGRAR REALIZAR LAS COSAS. TAMBIÉN
desde un proceso evolutivo de pequeños pasos de incremento TENEMOS LOS PROBLEMAS ANTERIORES DE
gradual, siempre que cada paso preserve la estructura de forma GOBIERNO MÁS ALGUNOS NUEVOS.”
adecuada. No obstante, ¿Cómo (y en base a qué intereses)
podemos definir la estructura que se conserva y a qué nivel?
ser coordinada de forma adecuada y alineada con los objetivos
Es importante destacar que con este concepto de preservación
de la empresa, y la escala de tiempo ha cambiado. En vez de
de la estructura, el liderazgo no realiza el diseño sino que
contar con comités directivos que se reúnen cada dos meses,
establece los parámetros en los cuales se puede dar el diseño
tenemos un gobierno en tiempo real, que abarca tanto el
ordenado. Esta función es más un rol del gobierno. Para
gobierno del diseño así como también el gobierno del tiempo de
responder la pregunta es necesario distinguir el gobierno de la
ejecución.
gestión.
Sabemos que esto no puede reducirse simplemente a un
Los análisis informales sobre el gobierno (gobierno IT en
problema de gestión. Muchas organizaciones experimentan
general y gobierno SOA en particular) pueden con facilidad
dificultades al realizar SOA de manera adecuada, no a causa de
difundirse hasta que parece que cubren todos los aspectos de la
problemas técnicos, sino por la falta de un gobierno apropiado.
gestión. Por lo tanto, ¿Dónde termina la gestión y dónde
¿Cómo se financia el enfoque dual? ¿De qué forma se puede
comienza el gobierno?
gestionar el enfoque dual de manera tal que las metas del
Si se entiende por gestión lograr realizar las cosas, entonces
servicio sean sistemáticas con las metas de la empresa y así
podemos comprender de mejor forma el gobierno como
SOA pueda gestionarse de forma efectiva? Y ¿Qué sucede
dirección (tal como en un Comité Directivo). En el pasado, era
cuando no concuerdan entre sí?
una práctica muy común para el desarrollo de grandes
Necesitamos abandonar la idea de un comité sentado
proyectos/programas contar con comités directivos –por lo
alrededor de una mesa escuchando los informes de progreso y
general un comité para cada proyecto– que gobernaban cosas
emisiones de registros de los jefes de proyecto. Es necesario
como medios, ámbito, dirección y prioridades. El comité directivo
aceptar la idea de que la dirección comprende la
era el punto común de exposición de ideas cuyo responsable era
responsabilidad de múltiples interesados y esta responsabilidad
el jefe de proyecto. Éste debía mantener un equilibrio adecuado
está incluida en la noción de gobierno que es esencial al tratar
entre los intereses del proyecto y los intereses de la
los asuntos de valor, valor para quién y valor para qué fin.
organización toda, así como también resolver los conflictos.
Estas son cuestiones básicamente éticas (en el más amplio
Sin embargo, existían muchos problemas con este enfoque.
sentido de la palabra ética—la ciencia del valor). Por lo tanto,
En primer lugar, el comité directivo por lo general no se reunía
mientras la gestión trata de lograr hacer las cosas, el gobierno
con frecuencia y a menudo sólo tenía una idea vaga respecto de
se asegura que las cosas correctas se realicen de la forma
lo que sucedía. En segundo término, los comités directivos por lo
correcta.
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
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
(Fundación de
Exógeno Atención Prim aria)
Hacer que la
cosas
C oordinación particular, la red permite que los comandantes coordinen de forma
del todo
funcionen dinámica las relaciones entre los componentes de una fuerza en la
medida en que los efectos compuestos que ellos necesitan
C oordinación 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.
Claramente existen algunos sistemas que son excesivamente
rígidos y se beneficiarían con un grado mayor de flexibilidad de Riesgos de interoperación
forma tal que sus servicios componentes puedan utilizarse de Las organizaciones comerciales y administrativas por lo general
forma independiente como un todo. Sin embargo, esta rigidez es intentan la armonización por medio de una jerarquía de gestión y
sólo una parte de la historia. Mientras que algunos sistemas son de una estructura de presupuestos contables asociados y centros
excesivamente rígidos, existen otros tantos que están de costos que crean transparencia vertical coherente con la forma
fragmentados de forma irremediable: para obtener un uso efectivo de armonización. Este proceso es conocido por ser inflexible e
de ellos, los servicios independientes deben funcionar juntos. Por ineficaz, produciendo silos de actividad que son relativamente
lo tanto, el potencial total de SOA surge de la descomposición y resistentes a las demandas de las diferentes organizaciones. El
recomposición. poder a la vanguardia (y, casi indiscutiblemente, las formas
Un tipo importante de disociación, según la ponen en práctica avanzadas de SOA) no son compatibles con las estructuras
los militares, es conocida como armonización. La armonización tradicionales de contabilidad de costos y presupuestarias.
implica tomar una misión completa y dividirla en misiones La armonización nos lleva hacia una noción fácil de
integrantes que puedan realizarse independientemente una de la interoperabilidad: X e Y son ínter operables si pueden funcionar en
otra, lo que produce una estructura jerárquica en la que la misión forma conjunta sin interfaz mutua. Esta operación es el orientador
de cualquier componente integrante debe depender de la forma en detrás del desligamiento de los programas de SOA, y esto sí
que su misión se adecua a un gran todo que es definido por la produce mejoras en las economías de escala y ámbito.
forma en la que la línea de mando ha impuesto la armonización. Existe también una noción positiva de interoperabilidad: X e Y
La armonización se relaciona en particular con los efectos que crea son interoperables si puede existir entre ellas alguna coordinación
cualquier misión, y los efectos secundarios de estos efectos sobre activa. Esta noción nos hace ir más allá de la armonización per se,
cualquier otra misión. Por lo tanto, la armonización no sólo y nos hace no sólo considerar las suposiciones respecto de la
requiere la comprensión de cómo funcionan las cosas (es decir, composición implícita en la forma de armonización sino que
gestión) sino también la comprensión de la forma en la que también nos lleva a considerar la forma en que pueden hacerse
pueden lograrse efectos compuestos a partir de efectos explicitas y dinámicas por medio de la coordinación. Sin embargo,
integrantes con el menor conflicto posible entre los componentes esto es ahora una coordinación de red (horizontal) más que un
integrantes y la mayor efectividad en la utilización de los recursos. planeamiento descendente jerárquico, que plantea las mismas
La armonización, por lo tanto, se refiere al desligamiento, pero preguntas de gobierno que hemos analizado anteriormente en la
crucialmente se trata de la forma en la que se realiza este relación entre el enfoque dual de perseguir los objetivos de la
desligamiento en relación con la misión general. (Ver Tabla 2) empresa y el servicio.
Los militares toman con mucha seriedad los conflictos entre los
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 Pensemos sobre la operabilidad de hojas de cálculos de gestión
interoperabilidad, no sólo porque cualquier geometría determinada en una gran organización. Cada gerente produce su propia hoja de
es en particular una coordinación entre sus servicios integrantes, cálculos de forma idiosincrática para fundar un conjunto particular
sino también porque son los que surgen en la medida que uno de decisiones de gestión. A pesar de que todos importan algunos
coordina a lo largo de sistemas y organizaciones. (Hemos estado datos desde la base de datos de la organización, han agregado en
siguiendo con interés considerable los desarrollos recientes acerca su mayoría datos de alguna otra parte, y todos han formateado las
del Huracán Katrina, ya que algunos de los comentarios públicos cosas de diferente forma. Un Gerente Senior, Joe, realiza una
del FEMA [Federal Emergency Management Agency] exponen con presentación ante una reunión de directorio sobre una decisión
claridad dificultades al gestionar algunos de los riesgos de estratégica importante, fundando sus recomendaciones con
interoperabilidad). ¿Cómo podríamos pensar acerca de la algunos gráficos realizados en Microsoft Excel que derivan de una
naturaleza de estos riesgos? hoja de cálculos compleja, hecha a mano (y completamente sin
La forma de gobierno aquí implica establecer los términos de documentar). A los colegas de Joe les resulta imposible
referencia dentro de los cuales la gerencia tiene la responsabilidad comprender su hoja de cálculos, o importar su análisis en sus
de mantener la interoperabilidad. Los riesgos de la propias hojas de cálculos para un estudio adicional, es más
interoperabilidad pueden clasificarse según su gravedad: en este probable que el sucesor de Joe construya su propia hoja de
contexto esta clasificación significa el grado en el cual un cálculos que trate de utilizar la existente.
determinado riesgo pone en peligro la forma en la que deseamos En este caso, la interoperabilidad falla en dos niveles. No sólo
coordinar las cosas. falla en el nivel técnico de compartir la hoja de cálculos diseñada
En cualquier forma de armonización se encuentra implícito un como artefacto para el usuario, sino que también falla al nivel de
enfoque para coordinar actividades armonizadas por medio de la significado. El artefacto es una expresión de un marco de
forma en la que interoperarán. Una visión simple de la significado que ha creado Joe que no puede ser compartido por los
interoperabilidad es que presenta una forma de ignorancia colegas de Joe ni sus sucesores. Joe trata de coordinar la
selectiva y deliberada: si uno presta atención a X, no necesita información de manera tal que requiere que lo haga interoperativo
prestar atención a Y. Por ejemplo, si se adopta este estándar de nuevas formas (no estándar). Las mismas dificultades para los
abierto, no es necesario preocuparse por cuál de estos efectos gerentes que colaboran en decisiones estratégicas complejas
secundarios estándar se podrán utilizar. Esta interoperación es una también reflejan su valor potencial al crear nuevas formas de
forma de especialización (o separación de intereses) tal como se actuar.
describió con anterioridad, lo que posibilita esta ignorancia
selectiva. De esto se desprende una suposición respecto de lo que Compartir el compromiso
X e Y significan para aquellos que tratan de utilizarlas para ¿Qué tiene que ver esto con la ignorancia? Se debe a lo mucho
producir un efecto combinado. 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
Figura 3: Ciclo del gobierno vuelve casi una representación de Joe mismo y su forma de
Estandarización del modelo prestar atención a ciertos detalles de gestión. Para utilizar la hoja
de relación del contexto de cálculos, uno casi necesita ponerse en su piel, ver las cosas a
Requiere un través de sus ojos. Si Joe tiene el poder suficiente dentro de la
gobierno asimétrico organización, entonces puede imponer su experiencia de gestión
Comparación Destino
sobre sus colegas y hacer que ellos utilicen su hoja de cálculos,
pero esto, por lo general, implicaría problemas de
Personalización interoperabilidad en cualquier otro lugar cuando la información
Estandarización del servicio bajo comienza a ser utilizada de formas nuevas e imprevistas. Una hoja
del modelo de el modelo de la de cálculos diseñada para su reutilización debe asumir algunos
coordinación de la oferta niveles de conocimiento compartido entre el usuario y el autor.
oferta estandarizada
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
Costo Personalizar 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
Personalización del servicio coordinación debe considerar los efectos no sólo de la forma en
bajo el modelo de la oferta
estandarizada
Figura 4: Estructura de la función 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
Cliente/usuario Orienta
Contexto del cliente que pueden ser admitidas). Mientras que las formas simétricas de
de la empresa 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
Obliga a Se anticipa a
Satisface 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
Arquitectura de la
Desarrollador SOA empresa 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
que X e Y interoperan, sino también la manera en que P1 y P2 dominante (Ver Figura 1). También podemos observar que
afectan el significado de X e Y. Junto con la coordinación (o su mientras el CÓMO permanece dominante, estamos exteriorizando
ausencia) se produce el riesgo de que el uso que P1 hace de X1 y los riesgos exógenos.
el que P2 hace de Y no produzcan el comportamiento conjunto Utilizamos métodos de análisis organizacional para distinguir los
esperado. Podemos, por lo tanto, comprender los riesgos de riesgos de endo-interoperabilidad (que provienen de las fallas
coordinación de la misma forma que comprendemos los desafíos dentro de la organización) de los tipos de riesgo de exo-
que enfrenta la forma de gobierno de un enfoque dual. Se crean interoperabilidad (donde la fuente se encuentra fuera de la
por medio de una falla para establecer un marco compartido de organización). Estos riesgos de exo-interoperabilidad relacionan lo
significado dentro del cual actuar. que sucede cuando los sistemas y servicios del proveedor se
Con la composición dirigida (planificación central, autoridad de
diseño única), el problema del significado compartido e ignorancia “EN QUÉ MOMENTO DEL CICLO DEBE ESTAR EL
permitida se delega de forma vertical, pero la geometría NEGOCIO DEPENDERÁ DE LA FORMA EN QUE SE
empresarial resultante debe ser endógena para las
ELIJA EQUILIBRAR LOS RIESGOS Y RECOMPENSAS”.
interoperaciones de actividades bajo esa jerarquía. Por lo tanto, A
se descompone en (o compone de) B y C; y si existen riesgos
combinan con sistemas de terceras partes y servicios como parte
asociados con la interoperabilidad entre B y C, entonces estos
de una solución del usuario. Por lo tanto, el sistema del proveedor
riesgos son asumidos por la persona en la jerarquía de diseño que
puede no funcionar como se espera en el nuevo contexto, puede
posee A. En una organización el requerimiento para la
no interoperar con otros sistemas tal como se desea, y el sistema
transparencia vertical es, por lo tanto, ser capaz de hacer cumplir
total de los sistemas puede no interactuar con el contexto de uso
este compromiso compartido para la coordinación vertical.
del usuario tal como se espera. Pueden considerarse estos
En cambio, la composición en conjunto (planificación a la
resultados como errores de ejecución, de planificación y de
vanguardia entre múltiples autoridades de diseño) requiere que se
intención dentro del dominio del usuario.
negocien los significados compartidos y las ignorancias permitidas,
Somos conscientes de las diversas técnicas analíticas para la
y que la geometría empresarial resultante posea elementos
comprensión y gestión de los riesgos de endo-interoperabilidad.
endógenos y exógenos que sean asumidos no todos para estar
No somos conscientes de las técnicas analíticas para la
bajo la misma jerarquía. Por lo tanto, la transparencia horizontal
comprensión y gestión de los riesgos de exo-interoperabilidad.
significa ser capaz de determinar la forma en que todas las piezas
Esta situación no es sorprendente en un mundo que define su
encajan juntas como un todo para que de esta manera se pueda
empresa como una que promueve soluciones, pero en un mundo
negociar un acuerdo sobre la forma de imponer una única
orientado al servicio, estos riesgos comienzan a ser cada vez
jerarquía, aunque temporaria, para los propósitos particulares de
mayores en la medida que los proveedores encuentran la atracción
colaboración, es decir, coordinación horizontal.
de los usuarios emancipados (Ver Hagel y Brown en “Recursos”).
En última instancia, debe existir un compromiso compartido
El cambio de un push a un pull no es sólo un problema de
para una única jerarquía, sin importar si se está siguiendo un
adoptar nuevas formas de gobierno y coordinación horizontal.
proceso descendente (disociación dirigida, analítica) o ascendente
También requiere que el proveedor adopte una mentalidad de
(composición en conjunto, sintética) siempre que pueda existir un
plataforma en la cual la plataforma no sea suya sino del usuario –
compromiso compartido en último término para una jerarquía
en el mejor de los casos están proporcionando una plataforma
única. La diferencia de los enfoques reside en si las jerarquías
sobre la cual los usuarios puedan resolver sus problemas. La
resultantes son o no estáticas o dinámicas. Desde el punto de
inhabilidad general para gestionar los riesgos de exo-
vista de una empresa que proporciona servicios a sus clientes, la
interoperabilidad no es sólo un problema muy importante, sino
personalización implicará estar de acuerdo con las jerarquías antes
que también es central para admitir una relación de interacción
de formar parte de una relación empresarial. Por el contrario, la
entre el cliente y el servidor en la red. Varias de las organizaciones
personalización dinámica implica que todos los procesos de
de proveedores con las cuales hablamos aún niegan esto, pero
aceptación de jerarquías adecuadas deben ser parte de las
encontramos más organizaciones de usuarios que reconocen la
relaciones empresariales en curso.
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
Análisis de riesgo
supone que los requerimientos del usuario pueden separarse del
Volvamos a la idea de Alexander del nivel en el cual podemos
contexto de uso. En cambio, los usuarios están buscando un
preservar la estructura: debemos ser capaces de decidir qué
enfoque de colaboración para gestionar encargados de riesgos a
cambio de la provisión de plataformas del servicio.
Síntesis
alternativos de búsqueda o aún para expandir de forma
Los mapas conceptuales proporcionan un metamodelo
transparente el término de búsqueda ingresado. Por
bastante simple pero muy efectivo para la ejemplo, con las asociaciones adecuadas, un mapa
representación de modelos de datos. En el artículo “Una conceptual puede expandir un término de búsqueda tal
Introducción a los Mapas Conceptuales” (The como “Georgian” en “Inglaterra Y Siglo XVII”.
Architecture Journal, Nº5, 2005), presentamos la forma 2. La clasificación del tema o asociaciones de temas pueden
en la que una combinación de mapas conceptuales y utilizarse para eliminar ambigüedades de conceptos
modelos de diseño de arquitectura permiten a los diferentes que aplican para el mismo término
(homónimos) basados en su contexto en el mapa
desarrolladores construir componentes reutilizables para
conceptual.
las aplicaciones. Ahora analizaremos brevemente 3. Una vez que se ha ejecutado una búsqueda que trae
algunas de las áreas de aplicación actual y potencial múltiples recursos, pueden agruparse estos recursos de
para los mapas conceptuales. Ya que los mapas acuerdo a su clasificación en el mapa conceptual,
conceptuales se utilizan principalmente cuando se permitiendo que los usuarios vean de forma más clara las
integran con otros sistemas, también analizaremos el diferentes formas en las que se ha conformado su
acceso a la información de los mapas conceptuales búsqueda.
utilizando una variedad de arquitecturas de servicios de
Beneficios para editores
red desde un RPC tradicional, interacción Una ventaja clara para la optimización de la búsqueda es que
cliente/servidor hasta modelos de distribución en los que una utilidad de búsqueda que sólo consulta un mapa conceptual
puede utilizarse tanto un modelo pull como un modelo es muchísimo más fácil de adaptar. Por ejemplo, si un sitio de
push para intercambiar actualizaciones en un mapa venta al por menor de productos eléctricos descubre que se ha
conceptual. vuelto popular entre los clientes un nuevo término de búsqueda
“PVR” que se refiere a la búsqueda de grabadoras de video
El propósito principal de los mapas conceptuales es permitir la para disco duro, el mapa conceptual que orienta la búsqueda
expresión de un modelo de datos de dominio y disponer que este del sitio puede modificarse y agregar el término “PVR” al tema
modelo de datos se conecte con recursos relacionados. Dentro “Grabadoras de video para disco duro”.
de este amplio cometido podemos identificar diversas
aplicaciones comunes para los mapas conceptuales en una “LA DECISIÓN DE ARQUITECTURA CLAVE AL
empresa. IMPLEMENTAR LOS MAPAS CONCEPTUALES COMO
En la actualidad, la gran mayoría de las organizaciones son, PARTE DE UNA SOLUCIÓN DE EDICIÓN ES LA
de algún modo, editores de recursos. Para algunas, la FORMA EN LA QUE EL SISTEMA DEL MAPA
información editorial es el negocio central y para la mayoría de
las otras organizaciones la información que publican es una
CONCEPTUAL SE INTEGRA CON EL SISTEMA DE
parte clave para la comunicación con sus clientes y asociados. GESTIÓN DEL CONTEXTO.”
Los editores de información enfrentan varios problemas que
pueden tratarse con los mapas conceptuales. El contenido relacionado con este tema no debería modificarse
Para un gran corpus, el buscador es por lo general, la única en absoluto; la búsqueda del término “PVR” accederá ahora al
forma para que los recién llegados encuentren lo que están tema “Grabadoras de video para disco duro” y traerá recursos
buscando. Tradicionalmente, la búsqueda estaba orientada por relacionados.
palabras claves con contenido o por indexado de texto completo. Vincular la gestión. Una de las formas más importantes de
Los mapas conceptuales ofrecen la alternativa de indexar y mantener al usuario en el sitio es presentar vínculos
buscar por medio de nombres de temas, y luego utilizar las relacionados que el usuario pueda seguir para encontrar más
ocurrencias de temas para presentar vínculos a todos los información sobre un tema. Mantener estos vínculos de forma
contenidos relacionados a los temas encontrados en la manual es propenso a error y requiere el compromiso de
búsqueda. Cada tema en un mapa conceptual representa un actualizar constantemente los vínculos o aceptar que los
único concepto pero puede asignarse a nombres múltiples, contenidos más viejos tendrán los mismos vínculos que antes
permitiendo que el mapa conceptual almacene nombres de uso para los contenidos relacionados. La naturaleza de los mapas
común y científico, errores ortográficos comunes o traducciones conceptuales como índice de recursos, permite que este tipo de
para nombres de conceptos. Además, un mapa conceptual vínculos se gestione casi automáticamente.
también puede almacenar relaciones semánticas entre términos Existen varios enfoques diferentes para presentar vínculos
que pueden dar forma a una búsqueda de diversas maneras: relacionados utilizando mapas conceptuales, pero en esencia
todos consisten en pasar desde los recursos hasta los puntos
1. Esta información semántica puede utilizarse para en el mapa conceptual donde se hace referencia a estos
proporcionar a los usuarios sugerencias de términos recursos, y luego recorrer de alguna forma el mapa conceptual
para después extraer la lista de recursos a los que se hace
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
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.
Figura 4: Arquitectura de agente de un mapa conceptual 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
Aplicación del cliente 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.
Agente del mapa Direccionabilidad de los temas. Se puede asignar a los temas
conceptual 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
Motor del mapa Motor del mapa capacidad de dirección de los temas también nos permite recorrer
conceptual A conceptual B 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
Figura 5: Ejemplo de una arquitectura de sindicación para tema T. En la muestra del servicio Web descripto en la tabla bajo
mapas conceptuales el título “Servicio Web de un Mapa Conceptual Simple”, los temas
pueden ser recuperados por su identificador único utilizando el
Aplicación del cliente método GetTopic().
Direccionabilidad del concepto. Los conceptos que representan
los temas pueden ser asignados por separado a identificadores
4
únicos, permitiendo realizar una consulta desde múltiples
servidores de información relacionada a un concepto específico. La
Motor del mapa Motor del mapa capacidad de dirección del concepto es la clave para soportar el
conceptual A conceptual B mantenimiento y creación distribuida de los mapas conceptuales y
las agregaciones subsiguientes de información en esos mapas.
1 3 Debido a que puede asignarse a un concepto (por ejemplo
Persona, Lugar, Fred Jones o Birmingham) su propio URI separado
Motor del mapa Motor del mapa del identificador del sistema del tema que representa ese
conceptual A conceptual B concepto, los sistemas múltiples pueden proporcionar información
2 acerca del mismo concepto y utilizar el identificador del concepto
servidor de cliente de
sindicación sindicació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
En un sistema distribuido, cada sistema de datos posee un
componente de integración que expone una interfaz del mapa “LOS CONCEPTOS QUE REPRESENTAN LOS TEMAS
conceptual, y los usuarios se ponen en contacto con el sistema por PUEDEN SER ASIGNADOS POR SEPARADO A
medio de la interfaz (Ver parte “c” en la Figura 3). Nuevamente,
IDENTIFICADORES ÚNICOS, PERMITIENDO
los consumidores sólo necesitan comprender una interfaz, pero en
este caso, las llamadas a la interfaz del mapa conceptual podrían REALIZAR UNA CONSULTA DESDE MÚLTIPLES
traducirse directamente en consultas y las actualizaciones desde el SERVIDORES DE INFORMACIÓN RELACIONADA A UN
sistema de información subyacente, lo que significa que no existe CONCEPTO ESPECÍFICO”.
duplicación de datos pero podría llevar a una tarea de integración
más demandante. consultar un segundo servidor del mapa conceptual para cualquier
tema con el identificador del asunto I y de esta forma ampliar la
Identificación y URLs cantidad de información conocida acerca del concepto
Tanto en un sistema distribuido como en uno centralizado, es representado por el identificador. La ventaja de la direccionabilidad
necesario hacer un fuerte énfasis sobre la identificación de las del concepto es que la aplicación del cliente no necesita conocer el
entidades que administra cada sistema. Es un asunto simple identificador específico del sistema del tema que posee el
asignar identificadores únicos a la entidad en un Identificador de identificador del asunto I. En la muestra del servicio Web, esta
Recursos Uniforme (URI) como por ejemplo un número de cuenta forma de direccionabilidad es provista por el método
del cliente o un número de registro de órdenes para el tema que GetTopicBySubjectIdentifier() (Ver la Tabla bajo el título “Servicio
representa una cuenta u orden, y con un poco de atención, los Web de un mapa conceptual simple”).
identificadores pueden ser configurados de manera tal que exista Temas literales de un documento. Los temas pueden convertirse
un algoritmo común para la conversión entre los URIs y los con facilidad como estructuras de información que utilizan
identificadores específicos de la entidad. identificadores de temas únicos a nivel global o hipervínculos para
El principal beneficio al utilizar un mapa conceptual para este representar la relación entre ellos. En términos SOAP, esto
tipo de ejercicio de integración es la flexibilidad con la que permite significa que podemos proporcionar una simple representación
el modelado de datos integrados. Debido a que el modelo en un literal de un documento de un tema. Si la metodología de los
mapa conceptual es simplemente de datos y no un esquema para servicios Web preferida es la Transferencia de Estado
cualquier sistema subyacente, se pueden introducir nuevos tipos Representacional (REST), es posible construir la representación de
de entidades sin la necesidad de alterar ninguna de las interfaces un tema como un documento hipervinculado que se ha sido
existentes. Además, al representar entidades empresariales enviado como respuesta a una consulta REST. En breve
centrales como temas en una ontología corporativa, se torna describiremos el algoritmo para la producción de esta
mucho más clara la forma de producir e integrar datos desde los representación.
sistemas de información empresarial en un sistema de gestión de Normas para la combinación estándar. Las normas de
datos o aún, cuando sea adecuado, fuera de la Web. combinación de los mapas conceptuales pueden utilizarse para
Todas las aplicaciones que utilizan mapas conceptuales, combinar información sobre un tema recibida desde múltiples
incluyendo todas las que presentamos anteriormente, requieren fuentes por separado en un único mapa conceptual en
algún método para acceder a la información del mapa conceptual. funcionamiento. Para los consumidores de mapas conceptuales,
La mayoría de las aplicaciones también requieren un las normas de combinación permiten al consumidor utilizar la
almacenamiento persistente para los datos del mapa conceptual y direccionabilidad de un concepto para encontrar toda la
una Interfaz de Programas de Aplicación (API) en proceso para información relacionada a un
acceder y manipular estos datos, pero esto va
Figura 6: Serialización del subgráfico de un mapa tema devueltos por las diversas fuentes de los mapas
conceptual conceptuales.
Síntesis
En esta arquitectura para la interoperabilidad 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
compartimos la experiencia obtenida en el diseño e implementados en la periferia de los sistemas IT de las
implementación de una fábrica de Software para un organizaciones del cuidado de la salud y le permiten a las
sistema del cuidado de la salud basado en el estándar HL7 aplicaciones del cuidado de la salud colaborar conforme a los
[Health Level Seven]. Analizamos la visión a largo plazo y protocolos técnicos y empresariales estandarizados en la versión 3
una prueba más focalizada del concepto en el desarrollo. del HL7, utilizando un infraestructura de comunicación basada en
También definimos los desafíos con los cuales nos un servicio Web.
encontramos en nuestro proyecto y las oportunidades En la segunda etapa, implementamos una primera –más
focalizada– versión de la fábrica del HL7 especificada en la primera
para ampliar el alcance de la arquitectura para las etapa. El objetivo de esta versión es un subconjunto de las
diferentes industrias y por lo general, las oportunidades capacidades de los puertos de colaboración del HL7 necesario para
para admitir una colaboración interempresarial. permitir la comunicación entre las aplicaciones del cuidado de la
salud por medio de adaptadores del servicio Web, conforme a los
El objetivo aquí es compartir la experiencia obtenida al diseñar e perfiles del servicio Web del HL7 (Ver “Recursos”).
implementar una fábrica de software basada en el HL7, un El ámbito completo de la fábrica, tal como se ha especificado,
estándar para la interoperabilidad de las organizaciones del también incluía el desarrollo de adaptadores de integración de las
cuidado de la salud. Comenzamos el trabajo hace casi un año aplicaciones empresariales para conectar las aplicaciones
atrás con las especificaciones de alto nivel de la fábrica, existentes con puertos de colaboración y la organización del
produciendo una primera versión de la arquitectura de solución y
su sistema (Ver “Recursos”).
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
Comunicación basada en el
archivo
Comunicación de la base
de datos
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
Figura 3: Punto de vista de producción del sistema. hostean las aplicaciones que interoperan. Observen que los
puertos de colaboración están hechos para ser altamente
Ingeniería del sistema configurables y permitir el despacho general, mientras que
también permiten la organización del flujo de mensajes complejos.
Requisitos de Requerimientos Por lo tanto, los puertos que se muestran en la Figura 1 están
la empresa del sistema
configurados teniendo en cuenta tanto los detalles técnicos para
una determinada implementación y utilización según los niveles de
Desarrollo del sistema
conformidad y definiciones de dominio del HL7.
En el contexto del desarrollo, el propósito de la fábrica de
Diseño del Implementación
contrato de
software es acelerar la especificación e implementación de puertos
del sistema
software de colaboración. La fábrica combina los conocimientos acerca de
Diseño del
sistema de la
dominios problemáticos provistos por los perfiles del servicio Web
empresa Desarrollo de Diseño del Operación y el modelo de información de referencia del HL7, con el
la aplicación sistema 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).
Ingeniería del Tal como lo sugiere la ilustración, este conocimiento se
proyecto 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
automatiza la producción de un código que implementa estas
por ejemplo sistemas de mensajes; herramientas, como
interacciones al buscar la información contenida en el Modelo de
generadores de adaptadores; y orientación para el proceso. El
Información de Referencia del HL7 [HL7 Reference Information
modelo de la fábrica debe instalarse en un Entorno de Desarrollo
Model-HL7 RIM].
Integrado (IDE), es decir, Microsoft Visual Studio 2005 Team
• Permite la colaboración empresarial aplicación-a-aplicación System, antes de que pueda utilizarse para producir e
expresada en base a estas interacciones sobre una implementar los puertos de colaboración del HL7. Tal como se
infraestructura de un servicio Web basado en estándares que observó anteriormente, el propósito aquí es describir lo aprendido
son compatibles con un subconjunto de perfiles del servicio Web al especificar, diseñar e implementar la fábrica del HL7. Hemos
de la V3 del HL7, a saber, los temas básicos, de agrupado la información en dos categorías. La primera clasifica las
direccionamiento, seguridad y mensajería confiable (Ver lecciones aprendidas acerca de
“Recursos”).
• Permite la integración de aplicaciones nuevas o existentes que “NECESITAMOS PROPORCIONAR ARQUITECTOS
no fueron diseñadas para: 1) la versión 3 del HL7; 2) para EMPRESARIALES JUNTO CON LOS MODELOS Y
cumplir con la colaboración empresarial; y 3) para comunicarse HERRAMIENTAS NECESARIAS PARA SOPORTAR EL
sobre una infraestructura de un servicio Web. PROCESO DE ESPECIFICACIÓN”.
Es importante comprender que la fábrica del HL7 forma dos la creación de la fábrica y el uso en general; la segunda contiene
perspectivas diferentes: producción y desarrollo. En el contexto de puntos de vista obtenidos respecto al dominio objetivo y con la
la producción, los productos finales de la fábrica son los puertos de forma en que la fábrica puede ser generalizada para dirigirse a un
colaboración del HL7. Estos puertos permiten automáticamente conjunto más amplio de dominios objetivo.
que las distintas aplicaciones del cuidado de la salud colaboren La creación y gestión del sistema de la fábrica fueron los
detrás y a través de servidores de seguridad utilizando servicios desafíos más significativos desde el comienzo del proyecto hasta
Web, siempre y cuando, al menos una de la aplicaciones que su finalización. Producir una versión inicial del sistema fue
participa en la colaboración empresarial implemente un puerto de relativamente fácil (Ver “Recursos”). Un enfoque basado en una
colaboración del HL7, las otras aplicaciones pueden participar a grilla podría ser utilizado eficazmente en esta etapa, organizar
través de otros medios, y todas las aplicaciones que participan en puntos de vista relevantes en una matriz de dos dimensiones con
la colaboración empresarial conformarán los estándares del HL7 un nivel de abstracción sobre el eje vertical y la etapa del ciclo de
para el intercambio de mensajes, ya sea de forma nativa o con la vida sobre el eje horizontal.
ayuda de un puerto de colaboración del HL7. Sin embargo, nos dimos cuenta con rapidez que la matriz de
dos dimensiones era una representación bastante inadecuada del
La fábrica a través de un modelo sistema, en especial para la versión totalmente definida de la
La Figura 1 muestra la colaboración empresarial entre el sistema fábrica porque: a) el sistema era multidimencional por naturaleza,
de un laboratorio y un hospital, en el que los puertos de b) una representación de la matriz no captura las relaciones entre
colaboración del HL7 se colocan en relación a los sistemas que 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.
Figura 4: Punto de vista del diseño del contrato de software No obstante, al trabajar con una representación amorfa del
sistema basada en un gráfico requería herramientas que no
Desarrollo de la Diseño del estaban disponibles. Por lo tanto, implementamos el sistema de la
aplicación sistema fábrica como un conjunto de proyecciones de los puntos de vista
relevantes en dos dimensiones. Cada una de estas proyecciones –
Diseño del contrato de servicios de Web: el gráfico por sí mismo– detalla un aspecto específico de la fábrica,
Diseño del contrato del Software proyectándolo de forma eficaz desde un sistema multidimensional
Diseño del Diseño del de la misma forma que un conjunto de registros es proyectado
Diseño XSD contrato del protocolo del desde un almacén de datos multidimensional para formar una
servicio Web servicio Web vista en dos dimensiones.
Infraestructura
Infraestructura
de la
de interacción
información
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.
Modelado específico de dominio con MetaEdit+ • Definir las asignaciones entre los criterios de la industria
www.metacase.com relevantes y nuestro modelo interno de colaboración
empresarial, y posiblemente las herramientas para la
Health Level Seven importación de los elementos de dominio que definen.
www.hl7.org • Introducir otro nivel de configuración en la implementación de
los puertos de colaboración que permita a los usuarios de la
“Perfiles de servicios Web avanzados”, Roberto Ruggeri et al. fábrica dirigirse a una variedad más amplia de plataformas de
www.hl7.org/v3ballot/html/welcome/environment/ tecnología.
Instituto para los Sistemas Integrados de Software Nuestra experiencia al desarrollar una fábrica para los puertos
“Computación Integrada con Modelos” de colaboración del HL7 ha demostrado que es necesario definir
www.isis.vanderbilt.edu mejores marcos, herramientas y procesos para especificar el
esquema de la fábrica, para administrar la configuración de la
MSDN fábrica de forma flexible y extensible y para comprender mejor
Visual Studio Team System Developer Center cómo y cuándo deben utilizarse los lenguajes específicos de
Microsoft Enterprise Framework and Tools Group dominio. Al mismo tiempo, las implementaciones iniciales de los
“Herramientas de lenguaje específico de dominio (DSL)” mecanismos de extensión como el GAT y DSL han probado su
http://lab.msdn.microsoft.com/teamsystem/workshop/dsltools/ valor, llenando espacios significantes en la infraestructura de la
fábrica de software y apuntando a innovaciones futuras en el área.
Microsoft Patterns and Practices Team Es nuestra intención continuar utilizando y mejorando estas
“Juego de Herramientas para la Automatización Orientada (GAT)” herramientas en la próxima versión de la fábrica del HL7, así como
http://lab.msdn.microsoft.com/teamsystem/workshop/gat/ también una versión interindustrial más generalizada llamada
fábrica de colaboración empresarial.
Fábricas de Software: Reunir Aplicaciones con Patrones, Modelos,
Sistemas y Herramientas, Jack Greenfield et al. (Wiley, 2004)
Sobre los autores
“Implementación de Servicios Web para las Aplicaciones del HL7 Mauro Regio es arquitecto de soluciones de la industria en la
para el Cuidado de la Salud– Implementación de la referencia del división Developer and Partner Evangelism Architecture Strategy
perfil básico de los servicios Web”, Mauro Regio (Agosto de 2005) 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.
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
provista por el software ETL o EAI. Los proveedores tienen que Tabla 1: Beneficios de SO y BI
aumentar la flexibilidad y funcionalidad ofrecida por sus Orientación al Servicio (SO) Inteligencia Comercial (BI)
plataformas en respuesta a estos nuevos desafíos. El resultado El más adecuado para integración El más adecuado para integración
neto para el cliente es un conjunto de herramientas con un aplicación-a-aplicación y más datos-a-datos y capaz de
conjunto cada vez más fusionado de funcionalidades. adecuado para eventos de bajo manejar grandes volúmenes de
Los usuarios familiarizados con el conjunto de productos volumen y alta frecuencia datos.
Microsoft no pueden no haber notado este patrón. BizTalk se
desarrolló en el EAI y el espacio negocio-a-negocio (B2B) pero Brinda una plataforma operativa, Brinda un modelo combinado de
define rigurosamente formatos y datos de la empresa y brinda
tiene aplicabilidad en algunos escenarios ETL. Servicios de
estructuras de datos, y encapsula bases para decisiones
Transformación de Datos (DTS), herramienta ETL de Microsoft que
y abstrae funcionalidad. comerciales y capacidad de
forma parte de la plataforma SQL Server 2000, creció de un consultar cualquier cosa de los
antecedente de ETL. No es coincidencia que la versión SQL Server datos.
2005 de este producto haya tenido una re-arquitectura para
brindar soporte a un más amplio espectro de escenarios de Soporta reutilización de Buenas herramientas y
integración, y se le dio el nombre de Servicios de Integración para componentes empresariales y mecanismos para transformar
enfatizar esto. permite cambios ágiles en datos.
Aunque las arquitecturas orientadas al servicio (SOAs) y las procesos comerciales.
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 datos a gran escala. En estos casos el enfoque de interfase de
utilizan coinciden. Hay también una clara correspondencia entre servicio no será adecuado.
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 Provisión de datos orientados al servicio
lado", y el diagrama de esto se puede ver en la Figura 1. Desde la perspectiva BI, un servicio puede exponerse como
Trataremos cada escenario en detalle. fuentes de datos con la introducción de una simple capa de
Desde la perspectiva de BI, es posible ver una aplicación SO fachada que brinda una correspondencia entre la interfase BI y la
como una recolección de fuentes de datos y fuentes de eventos. interfase expuesta por el servicio. La fachada transforma los
Hay dos modos principales en los cuales un servicio puede operar resultados de la llamada del esquema de datos usado en el bus de
como fuente de datos en un contexto de BI: servicio como servicio al formato de datos que espera la plataforma BI y
proveedor de datos a pedido y servicio como publicador de datos devuelve los resultados al llamador (Ver Figura 4).
que puedan ser de interés (Ver Figura 2). En ambos casos, los Algunos servicios exponen la información mediante eventos que
tamaños de mensaje son pequeños. La solución para transferencia se publican cuando se produce un cambio interesante en el
de datos a gran escala y transformación será aún a través de servicio. Otros servicios y aplicaciones dentro de la organización
técnicas de importación de almacenamiento de datos como ETL. pueden suscribirse a eventos publicados por los servicios. La
Los mensajes tan físicamente grandes no son dominio normal del integración de servicios para publicar eventos en la plataforma BI
SO. se logra mediante el uso de un agente que recolecta los eventos
Desde el punto de vista de SO, BI se puede ver como suscriptos y periódicamente transfiere los mismos en conjunto a la
recolección de servicios. Desde la perspectiva de SO, una fuente plataforma BI (Ver Figura 5).
de datos puede exponerse como servicio con la presentación de Uno de los desafíos en el desarrollo de SoBI fue encontrar un
una capa simple que reciba el pedido de servicio desde el ómnibus enfoque que impulsara las mayores fortalezas de cada arquitectura
de servicio y convoque la consulta adecuada. La fachada e identificara el área donde la integración causara desafíos.
transforma los resultados de la consulta (si es necesario) en Veamos algunos de los desafíos principales inherentes a la
esquema de datos, y devuelve los resultados al llamador (Ver implementación de BI en forma SO. Estos desafíos generalmente
Figura 3). surgen por los requisitos específicos que cada arquitectura fue
La arquitectura SoBI pone a disposición los datos BI en el desarrollada para tratar.
almacenamiento de datos como servicio para otras aplicaciones La Figura 6 muestra las diferencias en granularidad de datos
dentro de la arquitectura. Esta disponibilidad brinda a las que separa los enfoques BI de SO. En los extremos tenemos
aplicaciones una manera limpia de acceder a datos consolidados mensajes o eventos de grano pequeño, que están naturalmente en
para brindar soporte a los requisitos de BI. De esta manera, la el espacio de evento SO. Tales mensajes de grano pequeño no se
arquitectura BI se vuelve un componente integrado de la consumen rápida y eficientemente en una arquitectura BI sin usar
arquitectura de aplicación SO. Note que habrá veces en que el tipo agentes de eventos para recolectar eventos e importarlos a un
de datos requerido por el sistema es puramente de naturaleza BI, almacén de datos en forma periódica. Los datos de grano grande,
como exportación de importación a granel o movimiento de grandes cantidades de
datos, se maneja más eficientemente mediante las técnicas de
Figura 6: Tamaño del mensaje vs. Volumen del mensaje 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
SO BI servicios de grano medio, que consumen datos suficientes para
Volu cumplir con un requisito particular. Esta etapa intermedia es clave
men para el valor agregado de SoBI.
del
men
saje Las aplicaciones orientadas al servicio muestran un
emparejamiento aproximado entre sus servicios constitutivos. Este
emparejamiento es uno de los principios fundamentales de SO y
je soporta el desarrollo de aplicaciones ágiles/flexibles que pueden
nsa
l me adaptarse a los cambios comerciales. Ver tabla 1 para los
año de
Tam 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
SO de grano pequeño Importación de datos
o eventos en tiempo Servicios de grano medio y consolidar directamente grandes cantidades de datos de sistema
real de grano grande/ETL
de fuente sobre un programa conocido para población de almacén
de datos.
SO exige que la interfase del mensaje y los formatos tanto del sistemas fuente dispares brindan datos en momentos diferentes
mensaje entrante como de la eventual respuesta estén bien (por ejemplo, valores transaccionales provistos antes de recibir la
definidos. Cuando se exponen los servicios que describen información de referencia asociada). Estos datos se almacenarán
capacidades comerciales las consultas a realizar dentro de una como datos privados de marcador de posición dentro del servicio
aplicación SO se conocen con antelación. Sin embargo, existe BI. Se puede enviar una notificación al sistema fuente para
también un aspecto no conocido relacionado con exponer los asegurar que no haya ocurrido un error, y cuando los datos de
servicios que están agregados o implementados por otra referencia estén disponibles el almacén de datos volverá a
aplicación. BI se preocupa por la habilidad de permitir a las aparecer conforme al sistema de registros.
aplicaciones consultar cualquier cosa del almacén de datos dentro Servicio de una validación. La funcionalidad requerida para
de los límites del modelo de datos del almacén. La consulta, o el validación durante la etapa de ETL se puede exponer mediante el
tamaño; contenido; y formato del resultado no se saben hasta que marco SoBI para su uso dentro de otras partes del negocio.
no se haga la consulta. Actualizaciones a tiempo. La ventaja clave para BI es que la
adopción de ETL de una perspectiva SO puede permitir
Ventajas del SoBI alimentaciones en tiempo real en el almacén de datos y por lo
Un enfoque SO es más adecuado para exponer servicios que tanto un almacenamiento de datos en tiempo real potencial.
engloben las capacidades comerciales o servicios que publiquen Además, el mejor soporte para eventos e integración impulsada
eventos de interés para otros sistemas. BI brinda un ámbito por eventos puede brindar BI con un mecanismo mucho mejor
cerrado para satisfacer requisitos de información del negocio. BI para invocar ETL que los métodos tradicionales, como
permite al consumidor de datos verlos en potencialmente muchas programación a tiempo o escaneo persistente de un directorio
formas nuevas y diferentes. Esta flexibilidad brinda la capacidad conocido para un archivo indicador.
de identificar tendencias y relaciones que pueden pasarse por alto. Esquema comercial común. Dentro de cualquier organización
Previamente presentamos las fortalezas principales de cada puede haber múltiples sistemas que poseen información sobre las
paradigma, cada uno de los cuales se puede ver como tema mismas entidades y que poseen esta información en diferentes
fundamental si se ve puramente desde la postura del otro formatos. Existen claras sinergias entre estos casos:
paradigma. Ahora revisaremos estos desafíos y veremos qué
beneficios puede traer el SoBI. • Construir el modelo de datos lógico para un almacén de datos es
Funcionalidad de ETL almacenamiento superficial para SoBI fundamental para cualquier iniciativa BI. El modelo de datos es
permite que eventos comerciales interesantes durante el proceso el producto final de los esfuerzos para consolidar los datos de
ETL se publiquen como eventos. Consideremos algunos ejemplos. sistemas fuente dispares. La estructura de modelo de datos
Integridad referencial. SoBI puede brindar agregados de la impulsa la transformación que se produce como parte de la
posición “ahora”. Por ejemplo, datos que no están en el sistema población de almacén de datos y, por lo tanto, permite que el
fuente pueden agregarse en el almacén de datos como marcador almacén de datos brinde una sola versión de la verdad para
de posición para mantener la integridad de los datos de la base de información de administración.
datos. Este marcador de posición puede producirse cuando
BI SO
Es… …la única versión de la verdad para datos BI …el enfoque arquitectónico para integración de aplicaciones
En el futuro no… …se convertirá en vertedero de todos los datos, …se usará en todos los casos ni reemplazará importación de
ni se convertirá en propietario de datos, ni será datos
la fuente de datos por defecto para otras
aplicaciones, ni soportará informe operativo.
• Para cualquier servicio de agregado de entidades dentro de un herramientas para construir un motor analítico capaz de extraer
diseño SO es importante para llegar a un acuerdo sobre las cantidades potencialmente altas de datos transaccionales para
significados comunes para las entidades en las cuales operarán patrones que resulten en una lista de tarjetas de crédito
los servicios. Este acuerdo se menciona como consolidación de sospechosas. La adopción de principios SO nos permite ofrecer un
esquema y es el proceso de crear esquemas de datos master servicio que brinde los detalles de las tarjetas de crédito en uso en
que contengan un super set de información para describir a las nuestro local cuando son robadas. LA arquitectura SoBI permite
entidades en el sistema en detalle suficiente para que los que este servicio sea consumido por el componente BI de la
diferentes servicios puedan localizar los datos que necesiten. plataforma y lo analice en comparación con la lista conocida de
tarjetas sospechosas, y por lo tanto responda de inmediato si se
Otro servicio de entidades que cumple con este enfoque es la detectara una transacción potencialmente sospechosa.
habilidad para exponer datos de referencia. Conforme a Easwaran
G. Nadhan, Principal, EDS, “Es claro a partir de la experiencia en el Una nueva clase de servicios comerciales
número (relativamente bajo) de organizaciones que se cambiaron Agregado de datos históricos y transaccionales como servicio.
drásticamente a SOAs que coordinar datos de referencia es el Dado un servicio expuesto mediante el marco SoBI que ahora
primer paso obligado hacia la orientación al servicio”. (Ver puede agregar sin fallas datos transaccionales actuales y datos de
“Recursos”). almacén históricos, se puede brindar soporte a una nueva clase de
servicios comerciales. Un ejemplo podría ser cambio lento de
La realidad dimensiones, que es donde un valor como el nombre de un cliente
Una versión de la verdad. Viendo la funcionalidad ofrecida por las cambia con el tiempo. Obviamente esta información está
dos arquitecturas en forma integral, SoBI nos da la oportunidad de disponible dentro del almacén de datos, así que si existe un
consolidar datos BI y operativos sin la necesidad de mover requisito para exponer un servicio de entidad que dé una simple
físicamente todos los datos operativos en plataformas BI, lo cual vista del cliente, se puede lograr esto de manera más fácil y
es un enfoque común a brindar “una versión sola de la realidad” precisa.
en un proyecto BI. Al adoptar la elección arquitectónica más Trae los patrones de abstracción de interfases a BI. La
adecuada, los datos operativos pueden dejarse en el lugar pero capacidad de usar el patrón de abstracción de interfases en la
seguir disponibles para el marco SoBI como un servicio, en caso funcionalidad BI hace más accesibles a la funcionalidad y a los
de que surja la necesidad de acceder a este o de verlo. datos para aplicaciones de líneas de negocios y brinda la capacidad
Por ejemplo, en un ámbito BI interesado en el análisis de de exponer reglas comerciales complejas generalmente ocultas en
incidentes sanitarios o de seguridad, SoBI permitiría que los la capa ETL.
detalles de hechos de cada incidente se pudieran mover al Limpieza y consolidación. Los datos cambiarán para fines de
almacén de datos, es decir, el hecho de que sucedió un incidente, consistencia e integridad. Cuando este cambio implique una
dónde sucedió, y la clasificación del mismo, lo cual permitiría que operación de correspondencia, esa correspondencia quedará
se realicen todos los agregados y análisis adecuados según lo disponible para la arquitectura como un servicio. Cuando este
esperado de la plataforma BI. cambio implique corrección a los datos, los detalles de esa
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 Figura 8: Escala y flexibilidad ideales
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 Llamadas de
servicio Eventos
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 Servicios estratégicos
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 Fachada del
incidentes aunque nunca está actualizado. servicio
Servicios comerciales. La combinación de autorización de BI en Aplicación de la Exportación de datos/ETL
Almacén de
tiempo real y la capacidad de dejar datos operativos en su lugar empresa o fuente datos
de datos
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
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
Fachada de
Adaptador del servicios
servicio Documento de
oficina como vista
sobre datos Aplicación
empresarial o
fuente de datos Exportación/
ETL
Caché
de
datos
Documento de
oficina como Importación
Almacén de Almacén de
fuente principal datos datos
consultas online ni se basan en la exportación periódica de lotes. mantener sus propios datos; por lo tanto para permitir a las otras
Alguna de la información comercial crítica se mantiene en aplicaciones solicitar cambios a los datos, la aplicación propietaria
almacenes o aplicaciones que no son los adecuados para datos de tiene que exponer la funcionalidad de actualización de pedido
este valor comercial, por ejemplo, las planillas de cálculo de mediante su interfase de servicio. (Ver “Recursos” para más
Microsoft Excel que tienen versiones originales de datos haciendo información sobre estos dos tipos de datos).
de la planilla de cálculo el sistema de registro. Debe haber una Cuando se trabaja con integración de datos, SoBI es flexible
dirección estratégica para moverse hacia el punto donde están como para trabajar con estos casos de integración clave:
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 • Volúmenes de datos, que son transacciones simples especiales o
fuentes originales. La meta es moverse de documentos como cargas de datos a granel de gran volumen.
sistemas de registro a documentos como vistas de datos que están
en sistemas de registro. • Integración con aplicaciones en paquetes de terceros y
esquemas de bases de datos exclusivas.
Mantener la integridad • Consolidación de bases de datos
Se debe diferenciar claramente entre los tipos de reporte operativo
y de administración que serán necesarios dentro del marco SoBI.
• Integración de sistemas de legado, fuentes de datos
relacionales, no relacionales, estructuradas y semiestructuradas.
La vista tradicional de almacén de datos como fuente única para
todas las necesidades de información corporativa no es válida • Soporte para servicios de Red e integración con soporte
dentro del marco SoBI. El objetivo del marco SoBI es sostener el intermedio de mensajes.
principal de BI como "versión única de la verdad" pero también
mantener la integridad de los sistemas como propietarios de datos Cuando se trabaja con BI, el SoBI apuntará a satisfacer varios
corporativos. requisitos. Los negocios deben recolectar y sumar información de
Un informe operativo es probable que cumpla con uno de estos fuentes dispares dentro de la organización y deben poder
criterios; exige acceso vivo a los datos, es necesario para compartir esta información en forma abierta con un diverso
administración operativa del negocio (por ejemplo, información patrimonio de aplicaciones en diferentes partes de la organización,
sobre una transacción individual); no exige datos históricos para sin saber primero los detalles de cómo se consumirá la
comparaciones; y no exige datos resumidos (datos totales salvo el información. Los negocios también deben aislar a los usuarios de
total básico). Un informe de administración generalmente: 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
• Exige acceso a datos oportunos pero no inmediatos y de la semántica de los datos en vez de la sintaxis. Diferentes
generalmente requiere que los datos resumidos se presenten
partes del negocio deben poder compartir un lenguaje común
durante una franja horaria histórica pre determinada (por
cuando se describan a sí mismos, y los negocios deben publicar los
ejemplo, comparaciones métricas mes sobre mes por activo).
datos más ampliamente dentro de la organización, diferenciando
• Presenta al usuario la capacidad de explorar los datos entre publicación de datos y datos para análisis.
presentados a voluntad para investigar rápidamente problemas La publicación de piezas definidas de información como KPIs, o
de rendimiento potenciales (por ejemplo, entrar a los datos) El métricas mediante mecanismos abiertos como servicios de Red,
informe puede marcar áreas de fallas basadas en formateos permite a la información ser consumida fácilmente dentro de la
condicionales. organización sin recurrir a aplicaciones especializadas. La
• Está definido para notificar sólo al usuario cuando se produce un publicación de datos para análisis será igualmente parte clave de
problema (informe de excepciones) 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
• Asiste en la previsión de rendimiento comercial. acceso a aplicaciones especializadas necesarias para análisis de
• Asiste en las metas subyacentes de la persona y de la compañía datos. Una de las metas de SoBI es permitir la publicación abierta
(por ejemplo, eficiencia de producción, aumento de ventas y de información a un público más amplio de usuarios, y otros
maximización de ganancia de producto). servicios en la organización.
Aunque el almacén de datos contenga los datos reunidos de Patrones de integración SoBI
múltiples fuentes y sistemas de datos, desde el punto de vista Otra meta para el marco SoBI es tomar un enfoque pragmático
orientado al servicio, el almacén de datos no se debería considerar hacia el trabajo con sistemas que no se pueden integrar
como versión original. El propietario de estos datos sigue siendo el directamente en la arquitectura; por ejemplo, los que no pueden
sistema de registros. soportar carga extra o los que no son escalables para soportar
SO discrimina claramente entre dos tipos diferentes de datos, a integración directa.
saber, los datos que están dentro del servicio y los datos que el Con esto en mente, el marco define un conjunto de escenarios
servicio expone a las aplicaciones y otros servicios. Los datos (o patrones) que describen categorías de sistemas fuente típicos
dentro son datos que el servicio utiliza para realizar operaciones que los autores encontraron, junto con un enfoque de panorama
que brinda. Esta información es totalmente privada para el servicio recomendado para integrar cada categoría del sistema. Se prevé
y nunca se expone en forma directa. Los datos fuera son datos que esta recolección de patrones de integración evolucionará y
que son publicados por el servicio y utilizados para intercambiar crecerá al integrar sistemas más diversos en la solución SoBI.
información y solicitudes con los clientes del servicio. Estos datos Estos patrones ayudan a tratar una de las prioridades clave
se definen expresamente en términos de esquema organizacional. orientadas al servicio, a saber, la capacidad de soporte de
La aplicación que es propietaria de los datos (también reemplazo de aplicaciones
mencionada como sistema de registro) es la responsable final de
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
Llamadas de Llamadas de
servicio Eventos servicio Eventos
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 Puro SoBI
pueden abstraerse estos sistemas en una forma que asegura que Una situación ideal es aquella en la cual la aplicación es escalable
hay una mínima interrupción cuando los sistemas se reemplazan y flexible como para soportar la exposición de servicios y eventos
finalmente. al bus de servicios, ya sea directamente o mediante una fachada
Hemos enmarcado hasta ahora SoBI en términos de un de servicios liviana (Ver Figura 8). Esta categoría de aplicación es
escenario ideal del mundo en el cual diversos sistemas de registro también capaz de soportar la exportación de datos al almacén de
puedan participar en la arquitectura SoBI en una forma orientada datos, según se requiera.
al servicio. En un ámbito de un proyecto real, es probable que Una limitación de tipo de sistema de fuente es el procesamiento
haya un número de limitaciones que impacten en nuestra transaccional/en tiempo real. Algunas aplicaciones contendrán
capacidad de implementar SoBI puro. Hemos identificado varias información que es interesante desde una perspectiva de análisis y
categorías de limitaciones que se tratarán a la brevedad, y por desde una perspectiva en tiempo real. Tal aplicación puede
ejemplo en cada caso identificamos un patrón, el cual, al usarse activarse al crear una fachada de servicio que exponga los
junto con el principal de soBI de SOA empresarial y estrategia de servicios de la aplicación a la organización, y que muestre eventos
datos, asegura que la implementación del pragmático SoBI quede cuando se producen cambios o actualizaciones “interesantes”. En
dentro de los principios guía del marco SoBI. este caso, las
“Arquitectura Orientada al Servicio: Desafíos de Implementación” , Robert Grigg es consultor gerente y arquitecto empresarial en
Easwaran G. Hadhan, Principal, EDS The Architecture Journal 2, Conchango, Reino Unido.
(Microsoft 2004)
http://msdn.microsoft.com/architecture/journal/default.aspx? Michael Horne es consultor gerente y arquitecto de inteligencia
pull=/library/en-us/dnmaj/html/aj2soaimpc.asp comercial en Conchango, Reino Unido.
Síntesis
La única forma de que este esfuerzo sea exitoso es mostrar y
La necesidad de planificar la arquitectura técnica es bien probar buenas intenciones. Las direcciones, que por lo general son
conocida por los directores, auditores y personal operativo quienes dan las directivas para esta actividad, junto con el equipo
que viven una época de alta demanda y constante cambio de arquitectura deben convencer a los empleados de que esta
de la información. Los impulsores de los negocios para actividad no trata de exponerlos sino de crear un entorno
esta necesidad incluyen la alineación de IT con el negocio operativo más efectivo y mejor que sirva de forma más óptima al
y el control de los niveles del servicios y los gastos. Este negocio. Al final, todos ganan, pero a expensas de aceptar los
análisis sintetiza la primera experiencia para la creación cambios y dejar de lado las barreras y defensas.
de un plan de táctica de dos años de una infraestructura Darle vida
de Arquitectura de Servidores para Windows (WSA) para Por sobre todo, los miembros de un equipo de arquitectura son
un departamento de operaciones informáticas. Se define moderadores. Ellos deben trabajar con el personal operativo para
la arquitectura técnica además del alcance de los comprender el entorno existente. De hecho, el personal operativo
resultados y los desafíos implicados. 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
La disciplina de planificación de arquitectura técnica sólo se ha negocio para crear la dirección y estrategia comercial con la cual
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 direcciones para comprender las tácticas y limitaciones y obtener
aún bibliografía especializada. La planificación de la arquitectura ayuda. También deben crear la perspectiva de la mejor práctica de
técnica, cuando se realiza correctamente, trata de abrir todos los la industria que abarque el sistema, la tecnología, el proceso y las
aspectos de los entornos existentes y les asigna un estado personas. Es necesario que el equipo de trabajo reúna todo esto
deseado consistente con el negocio. Tiende a crear una gran en un plan factible y realista.
variedad de preguntas y temas que nunca antes habían sido La arquitectura y la planificación, por lo general, dan un
planteados: algunos políticos, algunos comerciales y otros. En la panorama de un estado futuro que revela algún tipo de necesidad
medida en que uno trata de clarificar la visión y el alcance de la o deseo. Si hablamos de una casa por ejemplo, un arquitecto
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. PLANIFICACIÓN DE LA ARQUITECTURA ESTÁN
Si se asume que la visión y alcance de la planificación de la ACORDADAS CON ANTERIORIDAD, NO EXISTE
arquitectura están acordadas con anterioridad, no existe garantía GARANTÍA ALGUNA PARA LA PARTICIPACIÓN
alguna para la participación abierta, completa o interesada por
parte de los empleados operativos. Los beneficios de revelar
ABIERTA, COMPLETA O INTERESADA POR PARTE DE
información deben superar el costo de la revelación de puntos LOS EMPLEADOS OPERATIVOS.”
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 desarrolla un plan detallado que cumple las instrucciones del
asignación de presupuestos y recursos, sólo entonces se puede propietario. Si hablamos de un modelo que se utilizará en una
esperar más participación en los ciclos posteriores. Estando en comunidad en desarrollo, entonces estamos hablando de una
presencia de la primera de las desventajas, se debe hacer que los norma a seguir para mantener un presupuesto específico y un
directores transmitan el mensaje con fuerza y lo establezcan con panorama general. En este sentido, las instrucciones y requisitos
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 constructor. Para darle vida a un plano de arquitectura, se debe
arquitectura. diseñar y seguir un plano del proyecto de la construcción bastante
Como ven, ya tienen su cuota de desafíos simplemente al complejo. La belleza de la casa en el papel, no significa nada para
comenzar con el proceso de planificación de la arquitectura, más el propietario hasta que no la ve en la vida real.
los desafíos de mantener la participación de los empleados Por lo tanto, tiene sentido pensar en la planificación de una
operativos y los desafíos de obtener ayuda por parte de las arquitectura como el proceso que traduce un conjunto de
direcciones. Y si siguen el modelo de supervisar los planes de instrucciones y requerimientos en normas que el constructor
acciones de seguimiento, tal como lo describiremos más adelante,
pueden parecer policías o auditores.
Estos tipos de decisiones tienen consecuencias trascendentes y por Microsoft, el ciclo de Deming y el ciclo de gestión/COBIT. Es
lo tanto son decisiones al nivel de la arquitectura. básicamente una etapa de planificación seguida por operaciones
La arquitectura técnica trata por supuesto más sobre los de monitoreo, cuyos aprendizajes introducen optimización y
procesos. De hecho, es con frecuencia el proceso y no la mejoras en el nuevo ciclo.
tecnología que puede componer o interrumpir un servicio. Los
procesos, por lo general, comprenden asuntos de personas que Documentación del plan
sugieren ideologías políticas y a veces ¡Son los aspectos más La estructura principal del plan táctico de la arquitectura del
peligrosos de todos! Aún peor es cuando el sistema no cuenta con servidor de Windows (WSA) se encuentra en las disciplinas de las
verificaciones y balances para trabajar con estos asuntos. áreas funcionales como por ejemplo servicios Web hosting,
La arquitectura técnica trata la medición. Las personas deben servicios de directorios, y demás (Ver el esquema “Plan táctico
sentir que la medición se crea para ayudarlos y no para para la arquitectura del servidor de Windows”). La vía del servidor
exponerlos. Las direcciones debe mostrar sus intenciones se aplica a los cambios de tecnología específicos en el período
claramente cristalinas para obtener la confianza y la aceptación táctico. La última sección, productos consolidados, recoge todas
total del personal. Sólo entonces tenemos cualquier oportunidad las recomendaciones del plan de actuación de las secciones y las
para trabajar. La dirección debe comunicar las razones de la clasifica en tres áreas para colaborar con el proyecto de
medición, que incluye la realización o la conciencia sobre cuánto seguimiento: infraestructura, desarrollo y políticas y
nos falta aún, mejoras para alcanzar los objetivos y una procedimientos.
estimación de lo que es requerido. Los directores deben evitar la La estructura principal de la arquitectura de cada servicio de
desilusión pública al realizar una manipulación positiva cuando se disciplina –servicios Web hosting, servicios de directorios y
realiza un informe como por ejemplo “una mejora en el porcentaje demás– se encuentra en la sección del concepto de la solución que
en el último período” mientras aún se mantienen la información en está dividida en arquitecturas de tecnología y servicios que a su
absoluta reserva interna hasta que se cierran los números para los vez se basan en el Marco Operativo de Microsoft (MOF). La
introducción incluye las secciones de antecedentes, orientadores
“LA ARQUITECTURA ES UN CICLO CONSTANTE TAL del negocio, objetivos y alcance, y sus objetivos establecidos,
COMO LO ASEGURAN VARIOS SISTEMAS COMO POR como por ejemplo, el número de 9s para alta disponibilidad, entre
EJEMPLO EL SISTEMA DE OPERACIONES DE otros.
El resumen ejecutivo consta de un resumen de una página de
MICROSOFT, EL CICLO DE DEMING Y EL CICLO DE los beneficios actuales y futuros, metas y técnicas así como
GESTIÓN/COBIT”. también las recomendaciones más significativas del plan de
actuación.
objetivos del Indicador de Rendimiento Clave (KPI). La dirección Las recomendaciones del plan de actuación son con probabilidad
debe probar sus buenas intenciones, ya sea al obtener los recursos el resumen más importante de todas las especificaciones de la
requeridos o al aceptar un progreso más lento y resultados menos solución y mediciones del éxito, ya que el personal operativo
notables. establece prioridades y plazos e indican en la columna de
La arquitectura técnica se refiere a la automatización. Esta es la recursos/técnicas si pueden llevarlas a cabo por sí mismos o si
clave para la efectividad, los procesos deterministas y la necesitan una subcontratación (Ver Tabla 1). Establecer la
estabilidad. La automatización le otorga al personal operativo más planificación de la arquitectura como una disciplina y un rol ha sido
tiempo para centrarse en el análisis y la optimización, que forman muy provechoso, aún antes de completar el primer ciclo táctico. Es
la base para la optimización del servicio. un placer ver la finalización del plan y el comienzo de la actuación.
La arquitectura técnica también consiste en el monitoreo. La Este resultado no se obtiene sin costos ni esfuerzos y depende de
única forma de estar en el control es observando de forma todos los participantes del equipo de trabajo.
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 Sobre el Autor
escalabilidad –posiblemente una reacción correctiva automatizada. Waleed Nema es líder de equipo para la planificación de
La arquitectura es un ciclo constante tal como lo aseguran arquitectura técnica de Windows en el Departamento de
varios sistemas como por ejemplo el sistema de operaciones 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.
Síntesis
La arquitectura de software es una palabra clave en estos un sistema vivo sigue sin respuesta. O bien estamos
profundizando demasiado los detalles de implementación o
días para las personas de nuestra profesión. Parece que meramente estamos comunicando la superficie externa del
todos desean descubrir el verdadero potencial de la sistema. En ambos casos dejamos de lado el ingrediente
arquitectura de software y lo que puede aportarles. La fundamental del software: los aspectos de conducta dinámica del
idea básica de la definición de arquitectura es el diseño de sistema. En demasiados proyectos el equipo de desarrollo
estructura de software y la interacción de objetos antes de descubre estos aspectos del sistema en un diseño detallado o
la etapa de diseño detallado. Aunque se está sugiriendo la etapa de codificación.
definición seria de arquitectura sólo para proyectos
Enfrentar la realidad
grandes, podría decirse que cualquier trabajo de Otro dilema es el espacio creciente entre el código y la
implementación o construcción de software debe estar arquitectura original del sistema. Utilizamos herramientas y
precedido por una etapa de diseño y aprobación de la lenguajes diferentes en el proceso de construcción de software. La
arquitectura. Conozca el BASL, un lenguaje que unifica la arquitectura de software utiliza una especie de lenguaje de
definición de arquitectura de software con la modelado mientras que la persona a cargo del desarrollo utiliza un
implementación de software (codificación). 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
Uno podría decir con razón que existen como mínimo una
de nuevo un sistema que había diseñado en el pasado, sólo para
docena de estándares y herramientas bien definidos que se
descubrir que la arquitectura no tenía similitud con el diseño
pueden utilizar para definir la arquitectura de software. Tenemos
original?
estándares y herramientas para definir, comunicar, e incluso
Esta analogía es real para diagramas de clase, casos de uso, y
generar plantillas para diseño de software. Algunas de estas
casos de evaluación. El problema usual con estos documentos es
herramientas inclusive pueden funcionar bilateralmente, por un
que todos parecen volverse obsoletos después de que el software
código traductor a un modelo de arquitectura y viceversa. ¿Porqué
pasa a producción. Estos problemas surgen por la falta de un
entonces hay una necesidad de otro lenguaje o modelo de
programación?
Aunque existen muchas maneras de definir la arquitectura de
“EL RESULTADO FINAL DE NUESTRO TRABAJO NO ES
software en términos de paquetes, componentes, y conectores (es SOLAMENTE UN PRODUCTO O ARTÍCULO ESTÁTICO,
decir, la estructura de software), cuando llega el momento de SINO UN ORGANISMO VIVO, CON RESPUESTA”
definir la conducta dinámica del software, no podemos brindar una
definición para estos, ni comunicarlos, ni siquiera diseñarlos medio compartido o un punto de referencia singular para la
claramente. No obstante, la conducta dinámica del software es arquitectura y solución física. Lo ideal sería que la arquitectura y
realmente lo que hace nuestro software después de extenderse en códigos sean caras inseparables de una misma realidad: el sistema
el ámbito de la producción. de software.
Las técnicas más actuales, conocidas (y establecidas) utilizadas La disciplina de ingeniería-software ha recorrido un largo
para definición de arquitectura de software provienen de una era camino desde los primeros días de su existencia. A través de su
en la cual la arquitectura de software todavía era un mito. Aunque viaje, se han utilizado las ideas de otras profesiones de ingeniería.
estas técnicas (y herramientas) realizan un excelente trabajo al Un factor fundamental que diferencia nuestra profesión de otros
definir la estructura y componentes de sistemas de software, no campos de ingeniería es la naturaleza de nuestro trabajo, y más
tienen la capacidad de englobar y definir la conducta del software específicamente, el resultado de nuestro trabajo. Comenzamos con
y diferentes interacciones con el ambiente contra la dimensión de pensamientos, ideas, y visiones básicas y las desarrollamos para
tiempo. Se podría decir que estas herramientas no eran para el convertirlas en realidad que pueda cambiar las vidas de millones.
arquitecto de software, tanto como para el ingeniero de software. El resultado final de nuestro trabajo no es solamente un producto
La necesidad básica del arquitecto de definir la esencia de un o artículo estático, sino un organismo vivo, que responda.
sistema de software en forma abstracta y de brindar la imagen de La ingeniería de software como disciplina continuará trabajando
con más complejidad en la construcción
Sistema
-Inicial: Estado
-Final: Estado
1 1 1
* -Estado * -Conducta *
+Entrada() * *
+Salida()