Arquitectura orientada a servicios en el contexto de la arquitectura empresarial Service oriented architecture in the enterprise architecture field Martin Dario Arango Serna’, Pt.D., Jesis Enrique Londoio Salazar’, M.Se. & Juliin Andrés Zapata Cortes! LQ. I. Ingenieria Industrial; Universidad ‘acional de Colombia Sede Medellin, 2. Comercio Electrénico; Grupo Bancolombia mdarango@unal.edu.co; jelondon@bancolombia.com; jazapat!@unal.edu.co Reciido para evisin 12 de mayo de 2010, sceptado 4 de junio de 2010, vetsén final 26 de junio de 2010 Resumen—Este articulo, muestra una forma de cémo las ‘organizaciones empresariales deben responder a los cambios del entorno, optimizande sus procesos de negocio, usando lus tecnologia de la informacion y las comunicaciones como factor slave para ser competitivas y flexible a lus cambios que afectan la actividad de neguclo, Deacuerdy a Microsoft Corporation [1["L.a Arquitectura Orientada 1 Servicios (SOA, Service Oriented Architecture) es una fllusufia de disefy que permite un mejor alineamiento de las Teenologias de Informactin con las necesidades de negocio, permitiendy a empleades, clientes y socios comerciales responder de forma més répida y adaptarse adecuadamente a las presiones del mercadu”. La Arquitectura SOA establece un marco de disefw para la integracién de diferentes software empresariales, para que desde sitios remotus sea posible ucceder a los miltiples serviclos que las empresas sfrecen. La forma mis habitual de implementarla es mediante Servicios Web, una tecnologia busada en estindares Independiente de la plataforma, con Ia que SOA puede dlescomponer aplicaciones monoliticas en un conjunto de servicios «© implementar esta funcionalidad en forma modular. Palabras Clave: Arquitecturn empresurial, Arquitecturn orientada al servicio, Tecnologias de informacién, procesos de negoctos, estrategin empresaria organizations should respond tu the environment changes by ‘uptimizing theirs business processes through information and ions technologies (ICT) as a key factor for achieving, ‘ompetiveness and flexibility toward such changes in the business activity. According tw Microsoft Corporation [1 * Service Oriented Architecture (SOA) isa design philosophic that allows achieving a Revista Avances en Sistemas ¢Informtica, VoL No.2, julio de 2010 ISSN 1657-76 better alignment between ICT and the business necesiies, letting company workers, customersand parmers to respond and adaptto the Imarket pressure in a faster and better way”. SOA creates 4 desiga framework for the different business suftware integration in order tw allow accessing to different services offered by companies from remote locations. The more common way of implementing SOA {s through web services, a standard-base und platform independent technolugy, whereby SOA can rot monolithic applications inty a service set and implementing this functionality ina modular way, Keywords: Enterprise architecture, Service oriented architecture, information technologies, business processes, business strategy. I concepto SOA, por sus siglas en inglés, Service Oriented Architecture (Arquitectura Orientada a Servicios). no es nuevo, pucs se viene mancjando desde los aos 80's del siglo XX y fue impulsado por las comunidades que dieron inicio al diseio de softwarea través de componentes, que en su momento fue denominado como la Programacién Orientada a Objetos, (OP), por sus siglas en inglés, Oriented Object Programming, [2]. En 1983, ln ISO (Internacional Standards Organization) adopts 1 modelo de referencia OSI (Open Systems Interconnect) como tuna referencia comin para cl desarrollo de esténdares de comunicaciones de datos [3]. Mientras la tecnologia y las, capacidades en cada capa del modclo OSI han cambiado6 Revista Avances en Sistemas Informiticn, Vol7 No, draméticamente a medida que avanza la tecnologia, la arquitectura en si permanece. Al hacer una corrclacién de este concepto respecto a la funcionalidad que debe prestar un servicio tecnolégico,en la medida que las interfaces orelaciones entre servicios permanezcan estables y soportadas con estindares de industria, los servicios. en si mismos, pueden ser cambiados ficilmente segin las necesidades que vayan demandando los requerimaientos del negocio. En la actualidad se utiliza el término“Arquitectura” a nivel de los sistemas de informacién para indicar que se dispone de una estrategia y modelo de orquestacién (coordinacién) de los diferentes componentes tecnoldgicos que soportan las, necesidades de negocio de una organizacién. De forma consecuente, a estes componentes se les da el nombre de Servicios Cualquier organizacién puede ser estructurada de acuerdo con tres niveles jerdrquicos: Estrategia, procesos y sistemas de informaciéa. En la estrategia, la organizacién define sus mercados, produetos/servicios, objetivos y metas; en otros términos, se ocupa de los fines que se propone conseguir, A. nivel de procesos, la empresa instrumenta las operaciones de negocio congruentes con los objetivos y metas estratégicas, ‘mediante su estructuracién en forma de procesos de negocio; su propésito, es proporcionar los medios operativos necesarios para alcanzar los fines delineados en la estrategia, Una empresa es una entidad compleja compuesta de personas, procesos ¥ tecnologia, que producen productos o servicios orientados a satisfacer las necesidades de los clientes 4], Para capturar la vision completa del sistema empresa en todas sus dimensiones y complejidad surge el concepto de Arquitectura Empresarial, La arquitectura empresarial identifica los componentes principales de la organizacién y su relacién para conseguir los objetivos del negocio. Acta como fuerza integradora entre aspectos de planificacién del negocio, aspectos de operacion de negocio y aspectos tecnoldgicos [5 Larazén para que SOA ha aleanzado el nivel de importancia y relevancia que tiene en la actualidad, se debe principalmente a las necesidades latentes que tienen las organizaciones de linear el modelo de negocio con los servicios teenolégicos, con el linico objetivo de ser mas competitivos y poder dar respuesta répida alas exigencias del mercado. La Arquitectura Orientada, «vicios corresponde a un estilo de arquitectura en el contexto de las teenologias de la informacion (TI), la planeacién y el diseRlo de un sistema de informacion de acuerdo con un conjunto de gulas y lineamientos, de manera {que soporte las capacidades actuales y futuras para las cuales fue diseRado [6], Desde un punto de vista téenico, SOA es un estilo de arquitectura cuyo objetivo principal es permitir una interaccién simple entre componentes de software que actiian reciprocamente [7 tendigndose como ‘Tradicionalmente, los modelos de gestién teenoldgica en una organizacion estin supeditados a los modelos de negocio. Bajo julio de 2010 ISSN 1657-7665, este enfogue, el disefto y construccién de las soluciones informéticas consiste en tomar el conjunto de requerimientos que define el negocio, ya partir de estos extraer un modelo de tecnologia que dé respuesta explicita a dichos requerimientos. Modelo de Modelo de Negoco "Tecnologia Figura 1. Male de ecologia como unreal del male de vege Bajo un modelo con estas caracteristicas, las dreas de TI no trabajan con el suficiente nivel de integracién com las areas de negocio, y si lo hacen, el resultado no se ve reflejado en la cfectividad de las soluciones y servicios que provee, lo que conlleva a la implementacién de servicios informéticos desarrolladosa la medida, poco flexibles yen muchas ocasiones poco pricticos, El nivel de alineacién entre los modelos de negocio y los modelos de yestién tecnologica, dificilmente se ogra, debido prineipalmente a que la brecha entre las dos perspectivas es bastante amplia. Mientras el modelo de negocio esti enfocado a generar soluciones eficientes dirigidas a satisfacer las necesidades de los clientes y los mercados, el modelo tecnoldgico no demuestra tener Ia misma capacidad de reaccién, cuando lo hace, no necesariamente cumple con las cexpectativas que espera el negocio [8]. Para tratar de resolver el problema planteado anteriormente, cs necesario que las areas de TI desarrollen una vision més abierta y estrechamente conectada con el negocio, asi como tuna nueva alternativa de pensamiento sobre la orientacién a servicios de los componentes tecnolégicos que proves. La adopeién de un modelo de arquitectura orientado 2 servicios proporciona los mecanismos que permiten definir contratos de pprestacién de servicios que aseguren que la capa de negocio ‘en una organizacién se encuentre alineada con la capa de TI [9], tal como se representa en la figura 2 Figura 2. Modelo de tecnologia soporado ea SOA come us resultado del modelo de egaci. A través de la SOA, los procesos de negocio se implementan mediante servicios que ejecutan cada una de las unidades de trabajo mencionadas. Cada servicio es auténomo © independiente del resto, el cual al no necesitar informacién de contexto, puede reutilizarse indistintamente en varios process.Arguitectura erentada a servicios en el contexte de la arguitecrura empresurial ~ Arango, Lendatio & Zapata ” La comunicacién con el resto de componentes se realiza por medio de su interfuz, que mientras no sea modificada, permite la mejora continua del servicio disminuyendo la necesidad de realizar prucbas continuas deregresién, En una organizacién orientada a procesos y servicios, las freas de negocio modelan y orquestan sus procesos desde un unto de vista légico, utilizando los servicios que provea el rea de TI. Los cambios en los requerimientos y necesidades del negocio se ubordan modificando parcialmente los procesos Y los servicios, o bien desarrollando algunos nuevos si fuera nnecesario, Como consecuencia, el tiempo de respuesta que el negocio puede dar frente a las exigencias del mercado decrece rotablemente frente a un escenario orientado al desarrollo de aplicaciones, mejorando la competitividad de la compafiia y disminuyendo los costos por cambios y mantenimiento que se presentan tanto a nivel de los procesas como de los servicios tecnolégicos. La relacién que existe entre una arquitectura orientada a servicios y la Arquitectura Empresarial (AB), presenta una alta similitud y superposicién en varios de los conceptos, procesos, actividades y resultados que se presentan en cada una de ellas, Adicionalmente, ambos modelos estin determinados por el direccionamiento que se hace a nivel dela organizacién (estrategia y planeacién y arguitectura de referencia); al mismo tiempo, ambos modslos manejan esquemas de yobernabilidad similares En el desarrollo de un modelo de AE, se parte de un estado actual dela arquitectura (linea base)_ademds, sive como insumo para conducir el planteamiento de las acciones y planes a desarrollar para Mevar la arquitectura aun estado més evolucionado acorde a las necesidades del negocio. Lo importante es que al conocer este estado, se dispone de informacién valiosa para definir el plan de accién para evolucionar a un nivel de arquitectura superior u objetivo donde se quiere Megar, al eual se le denomina “TO-BE” que significa ‘Estado deseado” El camino a ecorrer se vaa soportar en SOA como vehiculo de transformacign [10 El proceso para transitar de un estado actual hacia un estado deseado, se denomina “GAP” que significa “Brecha”. El Nivel de Madurez m Estado deseado m, Estado actual (asis) & fee Tiempo Figura 3, Bvolucidn e los esquemas de inegracion expresarial soportada es tas Tl {Tuentepoopia) cubrimiento de las brecha permite que se vaya realizando el acercamicnto hacia el modelo objetivo, el cual se puede representar en un plano de tiempo vs. el nivel de madurez que sevaaleanzando (Figura 3), A través de este articulo, ol lector podré incursionar en la conceptualizacién y terminologia que hay alrededor del tema de una arquitectura orientada a servicios, el papel que juega sobre cémo apoyar en la productividad y eficiencia de las organizaciones, los componentes tenicos que se utilizan y la forma en gue se integra con los frameworks de AE mii representatives de Ia industria, El conocimiento adquiride le posibilita disponer de informacion clara y precisa relacionada con el tema, lo que leva a permitir tener un mejor entendimiento para la adopcion de estas metodologias. 1, SOA: EL. NUEVO PARADIGMA EN LA CONSTRUCCION DE El concepto de integracién empresarial ha evolucionado a la ‘par de los cambios que se han venido dando a nivel teenol6gico y dela forma en que operan las empresas. (hm ca esa8 Revista Avances en Sistemas Informiticn, Vol7 No, En la figura 4, se observa como en el siglo pasado entre los afios 70°s y 80's era comiin utilizar la expresién “Integracién de Sistemas”, en la cual, gran parte de los procesos de la organizacion estaban supeditados a las funcionalidades y servicios tecnolégicos, Ios cuales, debido a la poca interoperabilidad existente y la poca estandarizacién de las tecnologias, se soportaba en los esquemas de integracién entre las aplicaciones bajo l intercambio de informacién através de interfaces u otros medios [11]. Al inicio de la dada de 1990, se comienza a dar un cambio en el modelo de integracién de las ‘cornunicaciones en tiempo rea, lo que permit hacer mis simples y ficientes los esquemas de inteyracion entre aplicaciones, En él transcurso de la misma década, surgen diferentes modelos que apoyan la integracién de aplicaciones en un tinico sistema, siendo la primera vez que diferentes médulos que soportan procesos verticales de una corganizacién, como es el caso de los sistemas ERP. También surgen Tos esquemas de integracién con sistemas externos a través de las tecnologias Web y el desarrollo de los negocios por internet. .s unifican en una misma aplicacion A partir de este periodo, se comienza a dar una ruptura en los esquemas de integracién existentes, en la cual se comienza a pasar deun modelo de integracién empresarial con enfogue en Tatecnologia, hacia un modelo de integracion con enfoque en el negocio, Desde comien70s del aio 2000, seafianzan losmodelos de integracién, debido al desarrollo del comercio ylos negocios clectrénicos, planteando retos ya no sélo de integracién, sino tambign de colaboracién entre Tos sistemas de informacién de diferentes actores (empresas, proveedores, clientes, ete). En Ios tiltimos aos, las empresas se han visto forzadas a tener un ‘mayor nivel de integracién entre los procesos de negocio y los servicios tecnolégicos, dando vide y visibilidad 2 conceptos que ya existian de tiempo atrés, pero que toman vigencia, como son la integracién de procesos y la orientacién a servicios, ‘Al incursionar en el tema de Ta integracién de servicios, se resalta como el modelo de una arquitectura orientada a servicios ayuda a los arguitectos y disefiadores a descubrir artefactos (componentes) en el nivel de abstraccién adecuado para satisficeryalinear las necesidades del negocio, Permitetamign aque las areas funcionales de la empresa a nivel estratéxico y de procesos participen activamente en Ins definiciones y discos, yast logtar una mejor trazabilidad y correlacién de los servicios {ue requiere el negocio respecto a los que le provee el rea de TI También proporciona una metoxologia yun marco de trabajo para documentar las capacidades del negocio y dar soporte & las actividades de integracién y consolidacién de los servicios de negocio. ‘Una Arquitectura SOA permite soportar servicios débilmente acoplados (servicios independientes de 1a plataforma subyacente y del lenguaje de progremacién) para posibilitar Ia flexibilidad en el negocio de uns manera interoperable © independiente de los componentes tecnologicos. Consta de un julio de 2010 ISSN 1657-7665, conjunto de servicios de negocio que soportan la realizacién de procesos de negocio de principio fin de una forma dinémica yyreutilizable, utilizando descripciones de servicios basadas en interfaces. Al utilizar SOA, se pueden descomponer los procesos y funcionalidades de la organizacién en partes reutilizable: ‘mangjables, que pueden ser disefladas, desarrolladas y .gestionadas de forma independiente como servicios. El modelo SOA es iterative, ya que permite que un servicio pueda estar compuesto de otras servicios de granularidad fina (servicios simples elementales, respecto dela légica que ejecutan). Cada serviciose desarrolla con la intencién de aportar valor al negocio, yasea en mayor omenor grado, Ningim servicio teenolégico que se.construys tiene sentido o valor sino esté orientado a satisfacer ‘una necesidad concrata del negocio [10, 11] Los componentes que conforman la red de servicios hacen disponibles sus recursos a otros de ellos que se encuentran en Ja misma red, bajo un esquema de servicios independientes a los que se tiene acceso de un modo estandarizado, Al contrario de las Arguitecturas Orientadas a Objetos, una arquitectura SOA esti compuesta por servicios de aplicacién débilmente acoplados y altamente operativos entre ellos, Para comunicarse centre si, estos servicios se basan en una definicién formal dela interfaz, independiente de la plataforma, del lenguaje de programacién 0 de la tecnologia subyacente, ocultando 0 cencapsulando las particularidades de la implementacién. Con esta arquitectura, se pretende que los componentes de software desarrollados sean reutilizables, ya que cada interfuz.se define siguiendo un estindar La Arquitectura Orientada a Servicios ¢s tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implantacion de los servicios que se construyen. Para que lun proyecto SOA tenga éxito, los arquitectos, disefiadores y desarrolladores de software deben carnbiar sus paradigmas en lo que respecta al disefio de componentes tecnolégicos, para comenzar a construir servicios comunes que puedan ser orquestados a través de una capa de intermediacion, denominada middleware, para la implementacién de los procesos denegocio. El desarrollo de sistemas basado.en SOA, requiere de un compromiso con este modelo en términos de planificacin, metodolouia, herramientas yla infraestructura requerida. Para poder alcanzar una Arguitectura Orientada a Servicios, tanto los procesos de negocio como los procesos de tecnologia deben estar integrados en un mismo flujo, esto es, deben diseftarse para que funcionen como una sola unidad, garantizando que cada capa tenga su independencia de la otra, sin que se vea afectada notablemente cuando se presenten cambios en alguna de ellas [13]. Loanterior es un acercamiento‘a lo que se podria decir que es tener definida una AE. Desde una perspectiva técnica, existen diferentes estindares de industria que han sido adoptados por SOA para efectos de facilitar la implementacion de servicio:Arguitectura erentada a servicios en el contexte de la arguitecrura empresurial ~ Arango, Lendatio & Zapata oT) Con respecto al disefto y modelado de procesos de negocio, se cuenta con estindares como BPEL (Business Pracess Execution Language), WS-Coordination (Web Servicies Coordination), los cuales proporcionan métodas de defin coordinacién y soporte para flujos de trabajo, procesos de negocio y aplicaciones distribuidas. Desde el punto de vista de implementacién tecnolégica, para Heffiner [4], la mayorfa de las definiciones de SOA identifican la utilizacién de servicios web a través de estdndares basados en SOAP (Simple Object Access Protocal), WSDL (Web Services Description Language), UDDI (Universal Description, Discovery and Integration), XML (Extensible Markup Language), HTTP (HyperText Transfer Protocal) y IMS Java Message Service), entre otros. Tambien es posible hacer implementaciones de SOA utilizando otro tipo de estindares y tecnologias que estin basadas en el concepto de servicios, sin que necesariamente sean consideradas servicios Web, por ejemplo: IMS Java Message Service) para la implementacidn de servicios soportados en colas de mensajeria, CORBA (Common Object Request Broker Architecture), entte otros 3.1. Los Servicios Cuando se define implementar soluciones de negocio bajo una orientacién de servicios, Ia cual se soporta en una arquitectura SOA, Ia palabra clave es Servicio [14, 15] Un servicio es una unidad de trabajo que se ejecuta por un provecdor del mismo para obtener un resultado final, el cual es requerido o utilizado por un consumidor. Tanto el proveedor como el consumidor del servicio son representados por agentes de software que se gjecutan al lado de cada actor que participa ena comunicacién [7] Los servicios corresponden a funciones de negocio que, cuando son invocadas, ejecutan una tares especifica, tal como consultar el saldo de un crédito, realizar un pedido, abrir una cuenta 0 hacer un registro en un sistema, radicar un reclamo, solicitar una cita, Si todos estos servicios, entre muchos otros, son comunes para casi todas las organizaciones, y que por lo general pueden ser adquiridos como paquetes de industria 0 ser construidos internamente, la diferencia o ventaja competitiva reside en la forma en que cada organizacién ensambla y reutiliza dichos servicios, ajustindolos a la estrategia y necesidades especifieas del negocio, ‘Algunas de las caracteristicas principales que incorpora la implementacién de un servicio, son las siguientes: + Un servicio expone una interface bien definida soportada on estndares, + Un servicio oculta los detalles relacionados con la implementacién del mismo. + La invocacién del servicio se hace mediante mecanismos basados en estindares abiertos de industria, + Un servicio puede ser de yramularidad gruese o yranularidad fina, Los de granularidad gruesa, exponen una funcidn de alto nivel de negocio, que a su ver. invoca a otros servicios internos que pueden ser de granularidad fina. Un servicio de granularidad fina es aquel que implementa una y solo una funcién muy espeetfica, *+ Un servicio es publicado por cl proveedor del mismo, para {que sca consumido por uno o més clientes (aplicaciones, flujos. procesos, etc). + Los servicios son desacoplados (modulares), auténomos « independiente. + Un servicio es routilizable al poder ser invocado por diferentes aplicaciones. 3.1.1. Componentes de un Servicio El planteamiento de una arquitectura SOA se basa en las interacciones que se establecen entre tres elementos principales el proveedor del servicio, el registro del servicioy el consumidor del servicio [17]. Las interacciones comprenden las operaciones de publicacién, biisqueda y enlace. En un escenario tipico, un proveedor de servicios crea y registra un componente o médulo de software que es accesible a través de la red de telecomunicaciones; esto se conoce como la implementacion del servicio, El proveedor de servicios define una descripeién de éste y lo publica en un registro de servicios (Directorio). El consumidor del servicio ejecuta una operacién de bisqueda para encontrar la deseripeién del servicio que requiere consumir, ‘ya sea que lo haga de forma local, o bien, desde el registro de ‘servicios al utilizar la descripeién para establecer un enlace y comunicacién con el proveedor e invocar o interactuar con la implementacién del mismo. En la figura 5 se ven reflejados los, componentes y las iteraciones que se dan entre los mismos. escatinieta | See eee 2D) comaain Figura 8. Componesie hisioot de un Servicio80 Revista Avances en Sistemas Informiticn, Vol7 No, En una Arquitectura Orientada a Servicios se cuenta con los siguientes componentes [17 Proveedor del Servicio: Desde la perspectiva de negocio corresponde al propictario del servicio, mientras que desde la perspectiva de arquitectura se relaciona con la plataforma tecnoldgica que aloja el servicio. Consumidor del Servicio: Desde una perspectiva del negocio sel sistema de informacién oplicacién que requiere satisfacer ciertas funciones empresariales, Desde la perspectiva de arquitectura es la aplicacién o componente que invoca o inicia ‘una interaccién con el servicio, Registro del Servicio: Corresponde a un catilogo de servicios donde se buscan las deseripeiones y donde los proveedores publican las descripciones. Los eonsumidores de servicios se coneetan al directorio 0 registro de servicios, obteniendo informacién de enlace en la descripeidn de los mismos. regecay "| “Sher \ tnd ta posta pools ct Senko 4 @)\ feniso ; sere “sien ponte Prowse) a carega respuesta Figuen 6. Molo de eps de revise (Adu de Shek [1)) peeena ee oop julio de 2010 ISSN 1657-7665, Desde una vista teenolégica, los componentes técnicos que permiten la implementacién de un servicio de negocio se encuentran representados en la figura 6 y se deseriben a continuacién (The SOA Glosary): + WSDL: Corresponde aun formato XML que se utiliza para escribir servicios Web, y describe la interfuz piblica a los + UDI: Corresponde al catilogo o directorio donde se registran los servicios Web. + SOAP: Es un protocolo estindar que define cémo dos objetos en diferentes procesos pueden comunicarse por ‘medio del intercambio de datos XML + ENDPOINT: Significa el punto en cl cual una eapacidad provista por un servicio es entregada al consumidor del ‘mismo. Tarnbign hace referencia a los puntos de partida como al destino final de un servicio que es invocado, | = cenoponn Figura 7. Componentes tenioos para La isplementacén de un servicio Figura &. Capas de uas anjatectucs SOA. (Adapade de: Arsasiani, 2004 4 Emig, 2008)Arguitectura erentada a servicios en el contexte de la arguitecrura empresurial ~ Arango, Lendatio & Zapata 81 3.1. Arquitectura de SOA Uno de los aspectos mis importantes que debe ser considerados en un arquitectura SOA, esté relacionado con la Independencia que debe existir entre cada una de las capas, de tal forma que sean flexibles ¢ independientes de los earbios ue se presentan en las capas subyacentes, Diferentes autores han planteado diversos esquemas para representar las capas de SOA. Para Emig at el[18], quien tora como base el modelo definido por Arsanjani [19] propone una arquitectura SOA, desde cl punto de vista de la base tecnolégica tiene las siguientes capas: capa de sistemas operacionales (compucsta por aplicaciones legacy y componentes de infraestructura). capa de servicios teenoléyicos (servicios que se derivan de los sistemas operacionales), capa de integracion. (composicién de servicios), capa de servicios de negocio (Gescripeién de Is interfaz y esquema de comunieacién del servicio), capa de procesos (permite realizar una orquestacién. que facilita coordinar y propiciar la interaccién de diferentes servicios) yla capa de presentacién (interaccién de Tos usuarios con los procesos) -este modelo no incluye dos capas adicionales que si son eubiertas por el modelo de Arsanj una capa de integracién (capacidades de integracién a tra de mecanismos de transformacién y cnrutamiento de informacion) y una capa de calidad o cumplimiento del servicio (monitoreo, gestién y mantenimiento). La siguiente representacién (figura 8), muestra un modelo que integra los enfoques planteados por ambos autores. La capa de componentes operacionales se refiere a los servicios teenolégicos existentes, llamados sistemas coperacionales [20], tambicn conocidos con el nombre de sistemas legacy: En esta capa sc cubren elementos de tipo tecnoldgico como son las aplicaciones tipo ERP (Enterprise Resource Planing), CRM (Customer relationship management), SCM (Supply Chain Management) y sistemas legados pre- existentes). Por lo general, los sistemas mencionados anteriormente han sido desarrollados bajo esqucmas tradicionales de programacién y usualmente no estin orientados a servicios. En los iltimos afos, se comicnzan a dar excepeiones respecto algunas aplicaciones nucvas que salen al mercado que incorporan varias Funcionalidades orientadas a servicios [11]; de igual forma, sistemas pre-existentes estin incorporando servicios en las nucvas versiones que liberan Enla capa de componentes empresariales se utiliza teenologia ¥¥ diseitos basados en contenedores y desarrollos basados en componentes [17]. Es la capa encargada de realizar la funcionalidad y mantenimiento de la calidad del servicio de cada uno de los que estin expuestos. Un contenedor se encarga de dirigir el intereambio de mensajes siguiendo un protocolo determinado, ademas de administrar el discfio yla posicién de los controles que ejecuta, La composicién de servicios se realiza a través de una capa de integracién, El término de composicién en este contexto denota la combinacién de servicios simples que producen un resultado gue sirve de entrada para otro servicio de granularidad sgruesa [15]. Los servicios corresponden a una estructura basada en componentes, en la cual, estos son definidos como un conjunto de componentes reutilizables, los cuales pueden "usarse para construir nuevos servicios més complejos, nuevas aplicaciones o integrar programas existents. Es en esta capa donde siempre se realiza la clisica integracion de aplicaciones (EAL: Enterprise Application Integration, pero ahora se aplican estindares para la descripcién del servicio (p.e. WSDL) y protocolas de comunicacién (p.e. SOAP). Es deanotar que en la parte superior de la capa de la arquitectura, se eneuentran los servicios de negocio, los cuales contienen menos cantidad de cédigo de software (0 aspectostécnicos) y mis caracteristicas ‘ycapacidades a nivel de definicin de procesos de negocio La capa de composicién de procesos de negocio se establece después de la capa de servicios, Esta define la composicién de ‘procesos de negocio a partir de los servicios. Generalmente, se utilizan herraraientas visuales de composicion de flujos para su disedo, La funcién de orquestacién permite que un proceso ‘primario controle la secuencia global e invoca a les servicios colaborativos. Para realizar esta actividad, el proceso contiene la ligica (secuencia, actividades, invocaciones y sesiones) para invocar otros servicios (Iamados colaboradores), para completa su trabajo deforma combinado [20], La coordinacién de procesos de negocio en un nivel superior, se denomina coreogratla, la cual define los protocolos de comunicacién entre los servicios de negocio, Bésicamente la coreogratla con respecto a la composicién de servicios es un mecanismo de disedo que pretende definir un comportamiento global de esta, partir de comportamigntos individuales que se relacionan por ‘medio del intercambio de informacién y que se rigen por eglas de comportamiento 21) La capa de presentacién corresponde al itimo peldato que precede a ka capa de procesos y permite interaccidn (integraciin) de las personas 0 usuarios con los procesos que requieren de su intervencion [2| La interaccion puede extenderse a acciones de tipo operacional relacionadas con el negocio, el inicio, actualizacién o finalizacién de un proceso ola entrada de datos, {que lo alimentan, Desde el punto de vista tecnolégico, estindares como, BPELAPeople (Business Process Execution Language for People ) y WSRP (Services for Remote Portlets) prometen cconvertirse en los estindares para er aplicados en esta capa [18) La capa de integracién se considera transversal a toda la arguitectura, pues no sélo es necesaria la integracién de servicios basados en componentes, ya que al evaluar los requerimientos de una arquitectura es necesario considerar que adicional ala integracin de aplicaciones tambign es requerida, la integracién a nivel de a interfaz de usuario, de conectividad de aplicaciones, de procesos y la integracién de informacién,82 Revista Avances en Sistema ete, La capa de integracién provee diferentes capacidades que permiten realizar dicha funcién, tales como: transformacin, enriquecimiento, enrutamient ineligente de mensajes. mapeo yyhomologacién, registro de servicios, conectvidad, seguridad modelado y ejecucién de procesos, ete. A nivel de las herramientas teenoldgicas que proveen estas funcionalidades se encuentra lo gue se denomina ESB, por sus siglas en inglés, Enterprise Service Bus (Bus de servicios empresariales). ‘Algunas definiciones para ESB son ls siguientes: Un ESB una arquitectura que explota los servicios y la mensajeria a nivel de cape intermedia, el enrutariento inteligente y la transformacign [10], Desde tra perspectiva, para Cullen atel, [22] e1 ESB es un modo simple de hacer integracién dentro de una arguitectura orientadaa servicios. Para nosotros. la defincién de ‘un ESB correspond all componente central que a nivel tecnolegico provee una solucién de interacién, através del cual se realizan todas las operaciones de intercambio de informacién entre diferentes aplicaciones y servicios. para lo cual se soporta en estindares de industria, ademas de proveer les ficionalidades ‘mencionadas anteriormente en la descripein de ls eapaciéades de lacapa de integracion de una arquitectura SOA. En la capade cumplimiento o calidad del servicio se dispone de las capacidades necesarias para monitorear, gestionar y ‘mantener las propiedades de calidad del servicio, tales como: trazabilidad, ejecucién, seguridad, ejecucién y disponibilidad. Se utilizan diferentes herramientas de software que permiten ‘monitorcar el estado de los servicios y de las aplicaciones que ccumplen con los estindares de SOA. Una variacién de la arquitectura desert anteriormente, se soporta en el hecho de cémo diversas fuentes hacen una division de la capa de servicios en dos eategorias [23] servicios de yrano sgrueso y servicios de yrano fino. Este tipo de clasifieacion es relativa'y no existen sisternas de medicigm claramente establecidos [24], Emig at el [18]propone una arquitectura donde separa los servicios en dos grupos: servicios corey servicios de negocio, La capa de servicios core (principales) permite la exposicién de servicios de aplicaciones legacy ya existentes (servicios de _granularidad fina) los cuales pueden ser compuestosa través de la capa de integracién para generar nuevos servicios més corientados al negocio y que podrian convertirse en servicios de granularidad fina. En contraste, la capa de servicios de negocio precede a la capa de integracién, permitiendo la orquestacién y coreografla de servicios simples en servicios de granularidad sgruesa, articulados a flujos de procesos que mangjan el mismo tipo de interface y protocolo de comunicacién. JON DE SOA POR ALGUNOS DE. Los FRAMEWORK DE ARQUITECTURA, Los frameworks de Aruitectura Empresarial han venido cevolucionando desde el mismo momento en que este concepto ¢ Inforntia, VoL? No.2, alo de 2010 ISSN 1657-7665 fue introducido al mercado en el ato 1987 con la publieacién de tun articulo de J. Zachman en el Diario IBM Systems, titulado ‘Un marco para la Arquitectura de Sistemas de Informacién."" (3) En el contexto de la arquitectura empresarial, un framework corresponde a los componentes especiales que actiian como base para la estructuracién y ensamble de componentes en construceiones més complejas [26]. Continuando en el mismo contexto, un framework de AE concierne a un enfoque pars el disefio, planificacién, implementacién y gobierno de una arquitectura empresarial. Para Togaf, un framework es un marco de trabajo de AE que provee la metodologia y ls instrumentos que ayudan a determinar en qué términos se define y documenta Iuarquitectura. Con la adopeién generalizada de SOA por parte de las wrandes empresas, a finales de 2005 Erl [20] los framework de AE ya jentes advirticron la necesidad de integrar a sus modelos este concepto, La Orientacién a Servicios (OS) es un estilo Arquitectonica, mis no una Arquitectura en s{ misma [10,25 Loanterior permite inferir que SOA no es un nuevo modelo de arquitectura empresarial, sino una variacién en la forma como (sta puede ser implementada. De los diferentes framework de AE utilizados a nivel de industria, los mas representativos, determinados por su nivel de madurez y de penetracidn en ef mercado (Schekkerman - IFEAD, 2008) son los siguientes: Federal Enterprise Architecture Framework -FEAF, The Open Group Architectural Framework TOGAF, Zachman Framewok ~ZACHMAN-, Extended Enterprise Architecture Framework -E24F, Department Of Defense Architecture Framwork -DoDAF Para el desarrollo de este capitulo, se taman como referencia los frameworks de arquitectura erpresarial EZAF, ZACHMAN yTOGAF, por ser los primeros en mapear SOA en los modelos {de AB, respectivamente, 4.1, Extended Enterprise Architecture Framework (EZAF) Este flamework esti compuesto por cuatro fila (dimensiones) y cinco columnas (niveles de abstraccién). En el nivel de abstraccién contextual del marco de referencia EZAF se considera la implementacin del concepto -SPA-, por sus siglas cn inglés Services Paradigm Adoption (Adopcién del paradigma de servicios). Laadopeién por parte de una empresa de un modelo oricntado a servicios debe estar soportada con base en la estrategia y objetivos que tenga establocides, y no porque sca un concepto 0 paradigma que esté de moda. Su incorporacién cn una organizacién debe ser vista como una estrategia a nivel corporativo, y no solamente como una capacidad tecnolégica, de tal forma que ésta se pucéa estructura en términos de servicios. Lo anterior exige un cambio dementalidad.y compromiso, tanto desde las lneasestratégeas (Gircetivas) como de las ércas operativas de la empresa (p.c,Arguitectura erentada a servicios en el contexte de la arguitecrura empresurial ~ Arango, Lendatio & Zapata 83 procesos y tecnologia). En E2AF, la aplicacién de SPA. comprende todos los cuadrantes resultantes dela interseccién de las cuatro dimensiones de arquitectura, con el nivel de abstraccién contextual. En los niveles de abstraccién ambiental y conceptual del rmarcode referencia se incorpora el eoncepto SOE, por sus sighs, en inglés Services Oriented Enterprise (Empresa Orientada a Servicios). Este cubre todos los cuadrantes de interseceién que se establecen con las cuatro dimensiones de la arquitectura, Cuando se habla de que una empresa esté orientada a servicios, sehace referencia a que es toda la organizacién y no solamente algunas dreas. Desde una perspectiva a nivel del modelo organizacional, SOE orienta y habilita el cambio organizacional desde una perspectiva estratégica, lo cual exige que a nivel de toda la cadena de mando y estructura organizacional se cuente con el compromiso de todas las reas y personas, para lograr la implementacién exitosa de esta clase de iniciativas. La decision de adoptar ¢ implementar SOA en una organizacién, no se hace de la noche a la maflana, se debe contar con un proceso claramente definide y adeeuado que vali las implicaciones a nivel del negocio, los procesos y las tecnologias disponibles, ademés del horizonte que la empresa quiere alcanzar adoptando una estrategia de orientacién a En el nivel de abstraccidn fisico, encontramos la representacién del coneepto de SOC, por sus siglas en inglés Services Oriented Computing (Computacién Orientada a servicios). Comprende dos cuadrantes resultantes de la interseccion entre las dimensiones de sistemas de informacion (aplicaciones) ¢ infraestructura teenoligica. Los servicios de computacién se ‘de las aplicaciones, ya s que estén orientadas a prestar servicios de negocio, 0 bien, porque ejecuten servicios completamente téenicos. Una variacion de la computacién orientada a servicios corresponde al concepto de SOI, por sus siglas en inglés Services Oriented Infrastructure (Infraestructura Orientads a Servicios), el eual se entra especificamente en los componentes tfenicos tales como: plataformas de procesamiento, bases de datos, recursos de almacenamiento, redes de telecomunicaciones, ete. EL objetivo dotris de este concepto consiste en implementar servicios tendientes2 reducir tanto los costos como la complejidad dela infraestructura de TI mediante la virtualizacin, reutiizacin y laasignacién dindmica de los recursos. Por dltimo, en el nivel de abstraccign de transformacién, se tiene la representacion el concepto de STP, por sus siglas en inglés Services Transition Plan (Plan de Transicion de Servicios). Este cubre todos los cuadrantes de interseccign que se establecen con las cuatro dimensiones de la arquitectu calizan a tra La clave para que se Ileve a feliz término el proceso de transicién de una empresa hacia un modelo basado en servicios, consiste en contar eon un punto de equilibrio entre la turbulencia, que radea el apogeo de SOA, con el desarrollo eimplementacién ddeun plan coherente que sirva como gufa para llevar ala ermpresa porun camino que seguramente va a contar con sus dificultades, de tipo tecnico, de resistencia al cambio y por los vaivenes a nivel de las tendencias de industria con relacién al tema. 4.2. The Open Group Architecture Framework (TOGAF) TOGAF es un estindar que nacié en 1995, desarrollado por The Open Group. y patrocinado por el Departamento de Defensa estadounidense a partir del Technical Architecture Framework for Information Management (TAFIM). Esti enfocado hacia la efinicién, implantacién y mantenimiento de un modelo de Arquitectura Empresarial. TOGAF es un marco de arquitectura xenérico que no es especifico a ninguna industria, estilo de arquitectura, geogratia o tecnologia (Bloomberg, & Schmelzer); ppor cl contario, es considerado como un marco de trabajo genérico para ol desarrollo de la arquitectura, [27] TOGA consta de cuatro componentes o partes principales: La fase preliminar ointroduecién, cl método de desarrollo dela arquitectura -ADM- (The Architecture Development Method), la taxonomia empresarial (The Enterprise Continuum) yl base de recursos (The Resource Base). La fase proliminar hace una introduccién a los conceptos y principios que rigen la arquitectura y al enfoque especifica de TOGAF, El método de desarrollo de la arquitectura ineluye cl desarrollo de eada una de las vistas © dominios de la arquitostura ‘Tambicn incorpora la descripeién de cada una de las fases para administrar y gestionar el plan de ejecucion (ver figura 10). La taxonomia empresarial cotresponde a un repositorio virtual de todos los activos de arquitectura disponibles en la organizacion, los cuales son utilizados en el proceso de construccién de la TOGAF aborda el desarrollo de la AE a pautir de cuatro niveles de abstraccién: Negocio, Sistemas de Informacién (compuesto por la Arg. de aplicaciones y la Arg. de informacion). ¢ Infraestructura tecnolégica, En el marco de referencia, estos niveles de abstraccién se reflejan en las fuses B, C yD del diayrama que representa a TOGAF (ver figura 10). El cielo de ‘vida que sigue TOGAF para el desarrollo de la arquitectura cubre nueve fases, una primera fase que es considerada como el punto inicial (preliminar introduccién), ylas acho siguientes, aque son las que permiten el desarrollo de todo el ciclo de vida de la arquitoctura. Adicionalments, incorpora una fase © proceso para la gestion de requerimientes, a la cual confluyen todas las, emis. A partir dela versign 9, TOGAF incorpora la implementacién de SOA a través de una extensién que hace al componente “método de desarrollo de la arquitectura -ADM-”. En la figura 11, se muestra la forma en que Togaf hace una representacion atifica de la incorporacién de SOA en su framework dery Revista Avances en Sistemas Informitiea, V7 No.2, jlio de 2010 ISSN 1657-7663, Framework y principios pepe ile ( A Argus deNegocie 2 \ oa 6 8 a ‘ é oreo \ 7 omen —eE—C -_ 2. Considerar visits Bes, teemnco . Sweet Figura 1 Framework de AE ~ TOGAK (Adipiads de TOGAR, (27)) arquitectura. En esencia, loque se plantea, esa incorporacion _gobernabilidad para la implementacién de SOA a través de las dealgunas definiciones y planteamicntos sobre el esquema de diferentes fases del ciclo de desarrollo de TOGAF [27] Direccionadores de Negocio a nvelempresaril, Vision, Requerimientos recess Neco feces cvs Reger e rive egress, Neg eane in NeppenCambis) Esra ers) Fiyara 11. Modelo SOA, gplicade al Feamewurk de AE ~ TOOAR. (Adapcada de Tupat, [27))Arguitectura erentada a servicios en el contexte de la arguitecrura empresurial ~ Arango, Lendatio & Zapata 85 Antes de comenzar el ciclo de desarrollo de la arquitectur, el modelo TOGAF incarpora un componente central y comin a todas fases Gestion de requerimientos-; través de egara que cada una de las demés fases fandamente su desarrollo ¢ implementacign en requerimientos de negocio vidos. El desarallo de cualquier iniciativa de arquitectura y servicios de negocio debe estar sustentado en dichos requerimientos. Fase preliminar: prepara ala organizacién para abordar el proceso de adopcién e implementacién de un modelo de AE soportado en TOGAF, se define los equipos de trabajo, los principios que rigen la aquitectura y los marcos y herramientas de trabajo requeridos. Fase A - Visin de arquitectura; se establece el aleance, las restricciones y expectativas sobre el desarrollo de un proyecto de arquitectura, Se hace un levantamiento de la visién, el contexto del negocio, los patrocinadores y participantes, los acuerdos de entendimaientos y las aprobaciones necesarias. ES fundamental para el éxito de un proyecto SOA que esta fase se considere como un instrumento para el desarrollo de la arquitectura. En las fases siguientes (B, C y D), se sigue un modelo de implementacion que es comiin para las tres, y que consiste en construir un modelo objetivo to-be) dela arquitectura,teniendo como base las brechas (gaps) que se identifican a partir de un modelo existente (as-is), Fase B - Arquitectura de negocio: se encarga de la descripeién de la estructura organizacional, de los procesos de negocio, los sistemas de planeacién y control, los mecanismos de gobierno, administracign de politicas y procedimientos nivel empresaril En esta fase se encuentra el punto neurdlgico que determina en gran medida el éxito en la adopeién de una iniciativa SOA, al incorporarse la implementacign de un modelo de negocio basado en servicios, convirtiéndose en el punto de partida que soporta, el resto del ciclo de vida en el proceso de desarrollo, construccién y puesta en produccidn de un servicio de negocio, En el contexto de SOA, en esta fase se realiza la deseripeién de los modelos de negocios y servicios, de procesos y datos de negocio, ademis de los modelos funcionales y geograficos. Fase C- Arquitectura de sistemas de informacién (aplicativa y de datos): 1a arquitectura de datos o informacién describe los actives logivos y fisicas de los datos como un activo de la empresa, yla administracion de los recursos de informacion, Lat arquitectura aplicativa incorpora soluciones que apoyan el negocio, basadas en las ca funcionale componentes ¥ comunes de las dreas de negocio, Fase D - Arquitectura tecnolégica: define la estrateyia y arquitectura a nivel de Ia infraestructura de TT que dan soporte al negocio. En SOA, en esta fase se determinan los servicios a nivel de la infraestructura tecnologica que soportan y habilitan los demés eslabones de la cadena de los niveles de abstraccién de Ia arquitectura. Los servicios que se proveen en esta capa, son por lo general de granularidad fina, yson provistos por las. plataformas tecnolégicas y diferentes sistemas core 0 legacy aque se ejecutan sobre éstas. Fase E - Oportunidades y soluciones: se evalian y seleccionan las opciones de implementacién de los proyectos ris importantes de los diferentes modelos identificados en la arquitectura objetivo para cada uno de los niveles de abstraceién, Fase F~ Plancar la migracién: se priorizan los proyectos a implementar, andlisis de costos, riesgos ¢ implicaciones y desarrollar el plan de mnigracién. La aplieacién de SOA a nivel prictico se hace realidad en esta fase. Fase G-Gobiermodeimplementacidn: sedefinen losrmecanismes « instrumentos que garanticen que el desarrollo de los proyectos, ‘sth corde con la arquitectura defini. El yobierno SOA pretends ddotar de los mecanismos de eontrol, proceses, provedimientos y ‘métodos probados en la prctica para garantizar el orden en las decisiones que se tomen en una iniciativa SOA. Fase H Administracin del cambio de la arquitectura:establecse procedimientos para gestionar el cambio dela nueva arquitectura, ademis de proveer un monitoreo continuo para asegurar que la ‘arquitectara responda de forma rpida yefectiva alas necesidades, dela empresa. través del SOA, laernpresa debe ir adelante de los, retos inherentes del cambio organizacional, mitigando los resgos « incluyendo prineipios avanzados de gestién de cambio en sus estrategias de disefo eimplementacién, 4.1. ElFramework ZACHMAN El framework de AE de Zachman es una matrix de artefactos aque permite dssribir le rquitectura dela empresa, cl cual est compuesto por svs fils (dimensiones o perspectivas) columnas (niveles de abstraccién), tal como se observa en la figura 12, Est framework fuel primerocn ser construide, por Joqual sea convertido cn la bas sobre la cual se han originago los demas frameworks de AE que cxsten on el mercado, La implementacién de un modelo de AE soportado en Zachman no exige que todo el modelo se debs implementar completamente y de una sola vez; de por si, esto es casi imposible debido a loamplio del modelo, Como tal, el framework. de AE Zachman no propone ningin modelo de integracion 0 adopeién de SOA. Algunos autores que han trabajado sobre el ‘tema plantean diferentes escenarios sobre la forma en que SOA puede ser cubierto desde Zachman. Para Chmelzer, por las caracteristicas de framework Zachman, es ms probable y fil que se contextualice SOA alrededor del marco de referencia, a que por el contrario, sea Zachman quien se adapte a las, particularidades de SOA, (aungue es completamente viable que se haya para nuevas versiones del framework), al igual que lo han hecho ya otros frameworks como E2AF y TOGAF.86 Revista Avances en Sistema Figura 12, Faumework de AE — Zachos [14,15] Enel framework Zachman, como se ve reflejado en la figura 13, Ia aplicacién de SOA comprende ocho cuadrantes, resultantes de la interseccién entre las dimensiones del modelo ‘empresarial (conceptual), modelo de sistemas (logico), modelo tecnologico (de implementacién), con los niveles de abstraccién de datos (;qué), funciones (ze6mo") y red (jdénde’). ¢ Inforntia, VoL? No.2, Fen [eral =] ES eaten ios as 4 fase [Bg Dae — Figura 13. Modelo SOA aplicado al Feacewurk de AE de AE — Zachanaa. [14,15 ¥. CONCLUSIONS La idea principal que se desea transmitir en este articulo est relacionada con la necesidad imperante de que las organizaciones vislumbren la importancia y den sus primeros pasos para Ia incorporacién en sus modelos operativos, de la adopeién de un enfoque de arquitectura orientada a servicios, © en su defecto, en un nivel més simple, la adopeién de una filosotia de orientacion a servicios en cualquiera de sus niveles, dde madurez. La importancia de que esto se haga, radica en la rnocesidad latente de disponer de mecanismos que le permitana Tnorganizacién affontar las exigencias de integracidn a nivel de procesos y componentes tecnolégices, los cuales, a través de servicios, le den respuesta efectiva a los retos y necesidades que demanda el negocio, La relevancia que viene tomado el alo de 2010 ISSN 1657-7665 tema no es una simple moda, es un paso més en Ia evolucién y cel desarrollo tecnolégico, del cual, las organizaciones que estin ala vanguardia y que reconocen la importancia de las TI para apalancar su crecimiento estén sacando el mayor provecho. Las necesidades que tienen las empresas de orientar sus procesos a través de un modelo de servicios, ha comenzado a trascender 2 la misma empresa, planteando retos de integracién nivel inter-empresarial,inter-organizacién, convirtigndose en tun estindar defacto requcrido para el intercambio de informmacién ylla gjecucién de transacciones. Bajo otro contexto, en toda organizacién es précticamente imposible disponer de un solo modelo de procesos, de un modelo nico de datos, de una plataforma nica de aplica yen muchos cases, de una plataforma tecnolégica unifieada a rnivel de manejadores de bases de datos, plataformas de procesamiento y protocolos de comunicaciones, Estas variables se convierten en un una razén de peso que deben motivar auna ‘organizacion a centr su modelo de operacién en una plataforma solida de integracién basada en servicios. Para la adopcin de un modelo SOA, no es necesario, ni mucho ‘menos obligatorio, que una empresa deba desechar los recursos tecnoldgicos de que dispone (p.e, aplicaciones, componentes de infraestructura de TI y estructuras existentes), Es ‘completamente viable eomenzar la implementacidn de un modelo orientado 2 servicios, utilizando los recursos y tecnologias cexistente, los cuales podrn ir evolucionado, y ser atualizados ‘a medida que se vayan viendo los beneficios de un esquema de integracién, Lo que si es muy importante y con cardcter de obligatorio, es disponer de un modelo de gobernabilidad que le permita a la organizacién avanzar en la construccién de ese ‘nuevo modelo operativo, ya que es la Unica forma de poner a conversar ya trabajar de forma mancomunada 2 las diferentes, ‘reas de la organizacin que intervienen o que de alyuns forma estén relacionadas con esta clase de iniciativas. Desde otra perspectiva, una iniciativa SOA que pretenda incorporar cambios radicales desde el comienzo y obtener resultados en el corto plazo a partir del momento que eomienza su implementacion, va a requerir de altas inyersiones, lo cual hhace que su viabilidad y sostenibilidad sea a largo plazo. Esto se debe a que se debe Considerar el ciclo de vida completo de los servicios en el transcurso del tiempo, desde su ereacién, incorporando los cambios o modificaciones hasta leyar a su climinacién, en caso de requerirse En la actualidad, todavia existen sistemas de informacién que se Soportan sobre aplicaciones construidas bajo estdndares de programacién que ya no son vigentes, en los cuales, todo cambio requerido por el negocio, exigia o exige (porque todavia es vigente) que se deban hacer cambios directamente en las aplicaciones a nivel de eédigo de software, teniendo que convivir con las dificultades, sobrecostos y riesgos gue ello conlleva, Desde la adopeién de SOA en diferentes empresas e industrias, en especial la del software, el modelo adoptado paraArguitectura erentada a servicios en el contexte de la el desarrollo de aplicaciones o la actualizacién de las ya existentes ha cambiado radicalmente, permitiendo que las, aplicaciones sean adaptables a las necesidades de las empresas gue las utilizan, lo cual se logra a través de modelo de parametrizacion, flujos de trabajo y orquestacién de procesos a través de flujos, entre otras técnicas. Este permite menor dependencia respecto al proveedor, responde a cambios de forma mas répida, incorpora nuevas funcionalidades de forma ‘auténoma, ripida y segura, sin tener que acudir a eambios en el software, Lo anterior se ve reflejado en una mayor agilidad y flexibilidad para elm presionando una evolucién en el rol de los gestores de sistemas de informacién en la organizacién, haciendo que se centren mis en las necesidades del negocio y menos en los aspectos ‘éenicos de las aplicaciones. Aunque el concepto de AE existe desde hace varios afos, ‘unade las posibles razones por las que no tiene un alto nivel de penetracién en las organizaciones, tiene que ver con la ppercepcién que tienen las dreas del negocio, de que ésta sélo promete beneficios tangiblesa nivel de eficiencia alas reas TI mis no necesariamente a otras dreas de la empresa, La importancia de la adopeién den modelo SOA, ala luz dela AE, es que el primero incorpora un concepto que hacia falta en la AE: los Servicios. SOA requiere de un modelo de gobierno y diferentes instrumentos que permitan operacionalizar su arquitectura, la cual se ve reflejada de forma tangible en los Servicios que se proveen a la organizacién. Los instrumentos rmencionados son provistos por el modelo de AE. [1] Microsoft Corporation, 2006. La Arquitectura Orientada a Servicios (SOA) de Microsoft aplicada al mando real, Disponible en ‘wwomicrosoft.com'sea, Ulime acceso. Julio de 2010, Asanjan, A; Ghosh, 8. Allam, A; Abdollah, Ganaparhy,S, and Holley K, 2004, SOMA: A method for developing serve oriented setutons, Web Service Jour, VoL 47, No. 3, pp. 377396 Larman, C2001. Applying UML und Patter - An Introduction to Object-Oriented Analysis and Design, 2nd Fad, Prentice Hall, New Jersey, USA Veradat, FB., 1996, Enterprise Modeling and Integration Principles und applications. [en linea). Chapmandellall. Londen. Acceso w tavds de: hip: www lipkart.com enterprse-modeling: integration-franceis-vernadat/0412605503 exw ptt previewbook [Consula: 20 Jul. 2009), Cuenca, LL., Ortiz, B., Ay Boza, G, A, 2005, Arquitectura de Empresa Vin General, Universidad Politcnicade Vaknea, Epa Present en el IX Congreso de Ingeniera de Organizacién Gin. Ambrose, and Morello, D, 2008, Designing the agile organization DDesign principles and practices. Gartner Group. 1D Number: 21-7532, He, 1, 2003. What is service-oriented architecture, [en linea Xmil.com., Acceso amavis de: http. wwxmLcom pubia ws.2003, (09'30’soahtml [Censulta: 5 May. 2009] [3s] Rolls J. W; Weil, P; Roberson, D.C, 2006, Enterprise Architeetane Is m1 arguitecrura empresaral ~ Arango, Londofio & Zapata 87 As Strategy Creating a Foundation for Business Execution, Harvard Business Schell Pres, Hanard Way, Beston, USA. [9 Wel? and Rolls, 1. W. 2005, ET Governance: How Top Performers Manage IF Decision Rights for Superior Results, Harvard Business Scholl, Hardvard Way, Boston, USA. [10] Schulte, R. W., 2007, The Enterprise Service Bus. [en inca]. Communication Backbone for SOA. Gariner RAS Core Research Note G00143223, Acceso a través de: http ‘www gartner.com DisplayDocument?id-S04645. [Consulta: 10 ‘Age, 2009), [11] Sehekkerman, J, 2006, Structuring the Enterprise around Services ‘The Differences between Hype, Hope and Realry?. White paper, IEEAD, Amersfoort, The Netherlands [12] Schekkerman, J, 2005. Trends Enterprise Architecture 2005 How are Organizations Progressing’. Institute For Enterprise Architecture Developments (IFEAD). Amersfvort, The Netherlands [13] Whittle, R. and Myrick, C. B., 2004, Enterprise Business ‘Architecture: The Formal Lonk between Strateg and Results, ‘Auerbach Poblicatons, New York, USA. [14] Hefner, R., 2007. Topic Overview: Service-Oriented Architecture Forrester Research, Inc, Cambridge, MA ~ USA. [15] Bloossberg, and Schsselzer, R., 2006. Service Orient or Be Doomed!: How Service Orientation Will Change Yeur Business John Wiley & Sons, Hoboken, New Jersey. [16] Bloomber, J. and Schmelzer, R, 2009, SOA and TOGAF: A ‘Good Fit?. [en linea]. Document ID: ZAPFLASH-2009421 Document Type: ZapFlash. Acceso a través de: bitp ‘www .zapthink,com report.html?id-ZAPFLASH-2009421 [Consuta: 23 Ago, 2009] [17] De Sote, A. Ry Feminde, E. C, 2006, Nuevas Tendencias ex Sistemas de Informacin: Procesos y Servicios. Universidad de Leén, Espana [18] Emig, C; Langer, Ks Krate, K. Link, $ Mmm, C. and Abeck, S., 2006. The SOA's Layers. White paper, Cooperation & Management, Universitat Katsrahe, Alemania, [19] Acsanjan, A; Borges, H. and Kemie, H., 2004, Service-oriented architecture, Web Service Jouroal, Vol 4. No. 9, pp. 34-38 [20] EA, 2005. Service Ontented Architesture: Concepts, Techsclogy and Design, Prentice Hall PTR, ISBN 0-13-185858.0, [21] Pelz, C, 2003, Web Services Orchestration and Choreography. Heewlet-Packatd Company. IEEE Computer Society (2003). Vel 36 #10. pp 46-52, | Culler, A. Heffner, R. and Leganaa, G, 2006, The Enterprise “Architecture Of SOA: Essential Action Items For The EA Group's Plans. Forrester Research, In, Cambridge, MA ~ USA. [23] Newcomer, E. and Lomow, G, 2004. Understanding SOAwith Web Services. Addison Wesley Profesional, ISBN 0-321-18085.0 [25] Sessions, R., 2007. A Comparison of the Top Four Enterpnse Architecture Metho-dologies. [en linea). ObjectWateh, Ine Newsletter Vol 13. Acceso a través de: hip: www: objectwateh. com white papers sm4EA [Consulta ! Oct, 2009] [26] Schetkerman,1., 2006. Enterprise Architecture Good Practices Guide: How to Manage the Enterprise Architectare Practice editorial Writer [271 TOGAF 9, The Open Group Architecture Framewerk (TOGAF), s.2, Stucture of the TOGAF. Document Number: GOY1 ISBN 978-90-8753.230-7.[en linea], Acceso a través deshrtp ‘www opengroup.org architecture togaf¥-doe arch. [Consults: 6 Nov, 2009}¢ Informitic, VoL? No.2, jalio de 2010 ISSN 1657-7663 88 Revista Avances en Sistema Universidad Nacional de Colombia Sede Medellin Facultad de Minas Escuela de Ingenieria de Sistemas Mision La misién de la Escuela de Ingenieria de Sistemas es fomentar y apoyar la generacién ola apropiacién de conocimiento, la innovacién y el desarrollo tecnolégico en el drea de Ingenieria de sistemas e informatica sobre una base cientifica, tecnolégica, ética y humanistica. Vision La formacién integral de profesionales desde el punto de vista cientifico, tecnolégico y social que les permita adoptar, aplicar e innovar conocimiento enel campo de los sistemas e informatica ensus diferentes aspectos, aportando con su organizacién, esiructuracién, gestion, planeacién, modelamiento, desarrollo, procesamiento, validacién, transferencia y comunicacién; para lograr un desempefio profesional, investigative y académico que contribuya al desarrollo social, econémico. cientificoy tecnolégico del pais. Escuela de Ingenieria de Sistemas Direccion Postal: Carrera 80 No. 65 - 223 Bloque MBA Facultad de Minas. Medellin - Colombia Tel: (574) 4255350 Fax: (574) 4255365 Email: esistema@unalmed.edu.co hitp://pisis.unalmed.edu.co/