ARQUITECTURA EMPRESARIAL: UN NUEVO

ARQUITECTURA EMPRESARIAL: UN NUEVO RETO PARA LAS EMPRESAS DE HOY EVA JULIANA MAYA ORTIZ Profesionales de Proyectos CINTEL Resumen Una arquitectura empresarial permite describir todos los componentes de una organización como: procesos de negocio, sistemas, datos y tecnologías, así como las relaciones entre ellos y con el entorno, con el fin de que los procesos de negocio de la empresa sean soportados y facilitados por las Tecnologías de la Información y las Comunicaciones. Una arquitectura empresarial busca entonces que los procesos de negocio de una empresa sean más eficaces, efectivos y eficientes, con el fin de que la organización logre sus metas y fines de una forma óptima y responda de una forma apropiada ante los constantes cambios del mundo de hoy, lo cual por supuesto requiere esfuerzo, recursos y es un reto para las empresas actuales. Teniendo en cuenta la importancia del tema de arquitectura empresarial, en este artículo se plantea una definición de este interesante concepto, se describen en términos generales los frameworks de arquitectura empresarial más importantes actualmente. Además, se describen brevemente los lenguajes de modelado que se pueden utilizar para una arquitectura empresarial, se define una arquitectura de sistemas conocida como arquitectura orientada al servicio, y finalmente se incluye el tema de gobernabilidad que es fundamental tanto para SOA como para una arquitectura empresarial. Palabras Claves: arquitectura empresarial, procesos de negocio, framework, modelado, arquitectura orientada al servicio, gobernabilidad.

(Diciembre de 2010)

ARQUITECTURA EMPRESARIAL: UN NUEVO RETO PARA LAS EMPRESAS DE HOY

1

Contenido INTRODUCCIÓN ................................................................................................................. 3 1

DESARROLLO ............................................................................................................. 4 1.1 DEFINICIÓN .......................................................................................................... 4 1.2 FRAMEWORKS .................................................................................................... 5 1.2.1 TOGAF ............................................................................................................ 6 1.2.2 ZACHMAN ...................................................................................................... 7 1.2.3 DoDAF ............................................................................................................. 7 1.2.4 FEAF ................................................................................................................ 8 1.3 BPM ......................................................................................................................... 8 1.4 UML......................................................................................................................... 9 1.5 MDA ........................................................................................................................ 9 1.6 SOA ....................................................................................................................... 10 1.7 GOBERNABILIDAD ............................................................................................ 12 CONCLUSIONES .......................................................................................................... 13 BIBLIOGRAFÍA .............................................................................................................. 14


2

INTRODUCCIÓN Debido a la evolución de las organizaciones, a sus entornos cambiantes y al rápido desarrollo de la tecnología es necesario lograr que la infraestructura tecnológica de las empresas soporte y facilite sus procesos de negocio, con el fin de hacerlos más eficaces, efectivos y eficientes. Infortunadamente, el área de negocios y el área de tecnología en ocasiones parecen ser dos mundos separados condicionados o limitados por el otro. Podría decirse que existe una brecha entre estas dos áreas, la cual debe reducirse con el fin de que las empresas logren sus metas y fines de una forma óptima y respondan ante los constantes cambios del mundo de hoy. Teniendo en cuenta esto, surge el concepto de arquitectura empresarial, que busca describir todos los componentes de una organización, así como las relaciones entre ellos y con el entorno, por lo tanto se plantea como una solución para minimizar la situación mencionada anteriormente. Esta iniciativa requiere esfuerzo, recursos y es un reto para las empresas de hoy que deben buscar agilizar su operación diaria con el apoyo de las tecnologías de la información y las comunicaciones. Hoy en día, una empresa sin tecnología tiene una alta probabilidad de desaparecer pero esto no significa que la tecnología lo es todo, ella es solo un medio para que las organizaciones puedan lograr sus estrategias de negocio. Dada la gran importancia del tema de arquitectura empresarial, en este artículo se define este concepto, adicionalmente se describen en términos generales los frameworks más importantes actualmente que permiten documentar arquitecturas empresariales. Estos frameworks incluyen los aspectos más relevantes de las organizaciones como procesos de negocio, sistemas, aplicación o solución, tecnologías y datos. Adicionalmente, para el área de negocio y de sistemas se describen brevemente los lenguajes de modelado más importantes hasta el momento. También, se define una arquitectura de sistemas de gran importancia hoy en día, asociada con el tema de arquitectura empresarial, conocida como SOA y se establece su relación con Web Services. Finalmente, se incluye el tema de gobernabilidad que es fundamental tanto para SOA como para una arquitectura empresarial.


3

1 DESARROLLO 1.1 DEFINICIÓN Para comenzar, es preciso definir los términos empresa y arquitectura. En este contexto, una empresa es un grupo de departamentos u organizaciones que cuentan con recursos y que tienen un conjunto común de metas, fines y principios, por lo tanto una empresa puede ser toda una corporación, una división o un solo departamento dentro de una corporación, una agencia de gobierno, o una red de organizaciones distantes geográficamente. De otra parte, según el estándar American National Standards Institute/Institute of Electrical and Electronics Engineers (ANSI/IEEE) Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems, una arquitectura es “la organización fundamental de un sistema, que incorpora sus componentes, las relaciones entre ellos y con el entorno, y los principios que gobiernan su diseño y evolución”. Teniendo en cuenta esto, puede decirse que una arquitectura empresarial permite entender los distintos elementos que componen una empresa y cómo esos elementos se interrelacionan, por lo tanto una arquitectura empresarial puede considerarse como una colección de procesos de negocio, de sistemas o aplicaciones, de tecnologías y de datos que soportan las estrategias de negocio de una empresa. Por esta razón, una arquitectura empresarial captura información detallada acerca de estos cuatro dominios o áreas, realiza una descripción completa de la empresa desde diferentes perspectivas y logra una visión holística de la misma. Una arquitectura empresarial además puede compararse con un blueprint o plano que permite la ubicación óptima de los recursos de TI (Tecnologías de la Información), los cuales son el soporte de la función del negocio. Este plano puede compararse con el plano de una ciudad, que proporciona una vista de alto nivel de elementos como caminos, apartamentos, etc. (los cuales podrían corresponder con redes, aplicaciones, etc.) y de cómo esos elementos se relacionan entre sí. Según lo anterior, una arquitectura empresarial permite definir el entorno actual y/o deseado de una organización y el camino de transición entre ellos, lo cual ayuda a optimizar las interdependencias y las interrelaciones entre las operaciones de negocio de la empresa y las TI subyacentes que soportan esas operaciones. Sin una arquitectura empresarial completa y robusta se corre el riesgo de que las unidades de negocio de la empresa compren y construyan sistemas que ya existen, que son incompatibles y que son muy costosos de mantener e interfazar. El objetivo de una arquitectura empresarial es entonces crear un entorno de TI unificado, es decir sistemas de hardware y software estandarizados, que se enlacen con el negocio de la organización y con su estrategia. Es de aclarar que el término negocio no implica la consecución de ganancias sino que hace referencia


4

a la meta, fin u objetivo de una organización de cualquier tipo. Adicionalmente, arquitectura empresarial no solamente se refiere a la infraestructura y a los sistemas de TI de una organización, ya que ella establece el roadmap de la organización para cumplir su misión a través del desempeño óptimo de sus procesos de negocio dentro de un entorno de TI eficiente. De acuerdo con esto, una arquitectura empresarial tiene como meta contar con los recursos de TI necesarios para soportar una función o misión de negocio, promover estandarización y reuso de activos de TI existentes y compartir métodos comunes para la gestión de proyectos y el desarrollo de software a través de la organización. En otras palabras, el propósito de una arquitectura empresarial es crear un mapa de activos de TI y de procesos de negocio y un conjunto de principios de gobernabilidad que orienten sobre la estrategia de negocio y cómo ella puede ser expresada a través de TI. Por lo anterior, en teoría, una arquitectura empresarial hará a TI más barato, más estratégico y con mayor capacidad de respuesta. De otra parte, el entorno de una organización cambia constantemente y una arquitectura empresarial soporta y facilita ese cambio hasta el punto que podría decirse que sin ella los cambios pueden impactar enormemente a la organización. Una arquitectura empresarial permite que la infraestructura tecnológica y los sistemas de información puedan satisfacer las necesidades de la organización, apoyarla y contribuir a la efectividad y a la eficiencia de sus procesos, así como reducir la brecha que existe entre el negocio y el área de TI, que infortunadamente se han considerado dos mundos que no favorecen entre sí su trabajo, lo cual por lo tanto genera la operación lenta y de forma inapropiada de la organización. Finalmente, es de resaltar que la definición, desarrollo, implementación y mantenimiento de una arquitectura empresarial necesita un compromiso corporativo y una gestión formal, efectiva y continua. Actualmente es claro que un beneficio de una arquitectura empresarial es el soporte que brinda a la toma de decisiones en negocios cambiantes, debido a que una arquitectura empresarial reúne modelos de negocio y modelos técnicos que hacen posible seguir el impacto del cambio organizacional en los sistemas y viceversa.

1.2 FRAMEWORKS Un framework es un “lenguaje” para permitir la comunicación de los stakeholders de una arquitectura empresarial. También puede decirse que un framework es un método detallado, un conjunto de herramientas de soporte, que proporciona directrices sobre cómo describir o documentar arquitecturas, el cual generalmente no proporciona lineamientos sobre cómo construir o implementar una arquitectura específica o sobre cómo desarrollar o adquirir sistemas. A partir de lo anterior puede afirmarse que un framework de arquitectura empresarial proporciona un mecanismo para obtener arquitecturas de una manera


5

uniforme y consistente, de tal forma que las diferentes descripciones arquitecturales pueden ser comparadas y que las subarquitecturas de cada capa (negocio, aplicaciones, datos, tecnología) pueden ser integradas entre sí y con las de otras capas, incluso cuando las arquitecturas son desarrolladas por diferentes arquitectos. Existen diferentes frameworks para desarrollar una arquitectura empresarial pero la mayoría de ellos contienen cuatro dominios básicos: 1. Arquitectura de negocio: describe los procesos de negocio más importantes de la empresa. 2. Arquitectura de información: identifica en dónde se mantiene y cómo se accede información importante de la empresa que soporta el negocio. 3. Arquitectura de sistemas, de aplicación o solución: consiste en un mapa de las relaciones de sistemas o aplicaciones software que proporcionan las funciones requeridas por el negocio. 4. Arquitectura de tecnología de infraestructura: es un blueprint para el hardware, sistemas de almacenamiento, redes, etc., en otras palabras, es el ambiente de tecnología requerido por los sistemas de aplicación y por la información de la empresa. Los frameworks o modelos de arquitecturas empresariales que utilizan capas han demostrado ser útiles debido a que plantean divisiones de de una empresa que no se traslapan entre sí. Sin embargo, en este momento no existe un completo consenso en la industria sobre lo que debería ser un modelo arquitectural en capas, por lo tanto pueden ser utilizados varios modelos. Existen varios frameworks de arquitectura empresarial y seguramente con el paso del tiempo surgirán otros. El framework más utilizado hoy en día, según encuestas realizadas a la industria, es el Framework Zachman, seguido por los frameworks propios de las organizaciones desarrollados localmente, y por TOGAF y DoDTRM (Department of Defense Technical Reference Model) en el ámbito comercial. A continuación se realiza una breve descripción de los aspectos más relevantes de los frameworks de arquitectura empresarial más importantes actualmente. 1.2.1 TOGAF El Open Group ha desarrollado un framework arquitectural conocido como TOGAF (The Open Group Architecture Framework). El Open Group es un consorcio neutral al vendedor y neutral a la tecnología que busca lograr el acceso a información integrada, dentro y entre empresas, con base en estándares abiertos e interoperabilidad global. TOGAF divide la arquitectura empresarial en Arquitectura de Negocios, Arquitectura de Datos, Arquitectura de Aplicación y Arquitectura de Tecnología,


6

que coinciden con los cuatro dominios mencionados anteriormente. Además, define TOGAF ADM (Architecture Development Method), que es el corazón de TOGAF debido a que es una aproximación paso a paso para desarrollar una arquitectura empresarial; un Contendor Empresarial TOGAF, que es un repositorio virtual que incluye la Arquitectura Base TOGAF y el Modelo de Referencia de Infraestructura de Información Integrada; y Recursos TOGAF, que incluye la Base de Recursos TOGAF, un conjunto de herramientas y técnicas disponibles para utilizar TOGAF ADM, además información sobre la gobernabilidad de una arquitectura, sobre modelos de madurez de una arquitectura y un Framework de Habilidades de Arquitectura TOGAF. 1.2.2 ZACHMAN El framework Zachman para Arquitectura Empresarial o simplemente framework Zachman, es una framework ampliamente utilizado para desarrollar o documentar arquitecturas empresariales. Es un framework para definir y describir los sistemas empresariales complejos de hoy y fue desarrollado por John Zachman quien se basó en prácticas de arquitectura e ingeniería tradicionales. El framework es una estructura o plantilla bidimensional para clasificar y organizar los elementos de una empresa que son significativos tanto para la gestión de la empresa como para el desarrollo de sus sistemas de información. El eje vertical proporciona múltiples perspectivas de toda la arquitectura y el eje horizontal una clasificación de los diferentes artefactos de la misma. No hay directrices sobre el proceso de implementación de este framework, su énfasis está en asegurar que todos los aspectos de una empresa estén bien organizados y que tengan relaciones claras que aseguren un sistema completo sin importar el orden en el que se establezcan. El framework Zachman permite entender cualquier aspecto particular de un sistema en cualquier punto de su desarrollo y puede ser útil para tomar decisiones acerca de cambios o extensiones. El framework contiene seis filas y seis columnas que producen 36 celdas o aspectos. Las filas son: alcance/planeador, modelo de negocio/propietario, modelo de sistema/diseñador, modelo de tecnología/constructor, componentes/contratista, sistema trabajando. Las columnas son: quién, cuándo, por qué, qué, cómo, dónde. 1.2.3 DoDAF Debido a los requisitos relacionados con operaciones militares conjuntas multiservicios y multinacionales, el DoD (Department of Defense) detectó la necesidad de una formulación arquitectural estándar para asegurar que sus sistemas militares pudieran interoperar, entonces publicó el framework Arquitectural C4ISR (Command, Control, Communications,Computers,


7

Intelligence, Surveillance, and Reconnaissance) y posteriormente, con base en la experiencia en este framework, publicó el DoDAF (DoD Architecture Framework). La meta del DoDAF es lograr que las descripciones arquitecturales desarrolladas por diferentes comandos, servicios y agencias sean compatibles y que se interrelacionen, además que las vistas de las arquitecturas técnicas sean usables e integrables a través de los dominios organizacionales. 1.2.4 FEAF La meta de FEAF (Federal Enterprise Architecture Framework) es mejorar la interoperabilidad entre las agencias de gobierno de E.U. (Estados Unidos) mediante una arquitectura empresarial para todo el gobierno federal. Este framework es de aplicabilidad obligatoria y cubre todas las organizaciones del gobierno. FEAF es una colección de modelos de referencia interrelacionados, diseñados para facilitar la definición de las funciones de negocio, así como el análisis y la optimización de las operaciones de TI de las organizaciones federales. FEAF permite integrar las arquitecturas, organizar y compartir información de las diferentes organizaciones federales, las ayuda a desarrollar sus arquitecturas, a llevar a cabo en forma ágil sus procesos relacionados con TI y a mejorar sus prácticas de gestión de tecnologías. Una vez vistos los principales conceptos relacionados con arquitectura empresarial y sus frameworks, a continuación se realiza una breve descripción de métodos que contribuyen a obtener y describir la capa o arquitectura de negocio y la arquitectura de sistema, de aplicación o solución. BPM (Business Process Modeling), que incluye BPML (Business Process Modeling Language) y BPMN (Business Process Modeling Notation), pertenece a la Iniciativa BPM (BPMI.org) y es un estándar en el área de procesos de negocio, mientras que UML (Unified Modeling Language), originalmente de Rational Sofware, luego de IBM y ahora adoptado por el OMG (Object Management Group) como estándar, así como MDA (Model-Driven Architecture), también del OMG, son ampliamente utilizados para modelar sistemas de información.

1.3 BPM BPM típicamente tiene los siguientes objetivos: 1. Obtener conocimiento acerca de los procesos de negocio de la empresa. 2. Utilizar el conocimiento sobre los procesos de negocio en proyectos de reingeniería para optimizar una operación. 3. Facilitar los esfuerzos en toma de decisiones de la empresa. 4. Soportar la interoperabilidad de los procesos de negocio. ARQUITECTURA EMPRESARIAL: UN NUEVO RETO PARA LAS EMPRESAS DE HOY

8

BPML es un metalenguaje para el modelado de procesos de negocio, proporciona un modelo de ejecución abstracto de procesos de negocio con base en el concepto de una máquina de estados finitos transaccional. De otra parte BPMN, es la notación gráfica asociada a BPML, la cual está diseñada para ser comprendida por los usuarios del negocio, por sus analistas que crean los borradores iniciales de los procesos, por los desarrolladores técnicos responsables de implementar la tecnología que ejecuta esos procesos, por clientes y proveedores, y por la gente del negocio que gestiona y monitorea esos procesos. Adicionalmente, se han desarrollado lenguajes de ejecución en XML basados en Web Services para sistemas BPM, que proporcionan un mecanismo para la ejecución de procesos de negocio, como BPEL4WS (Business Process Execution Language for Web Services). Finalmente, BPQL (Business Process Query Language) define una interfaz estándar para sistemas BPM, que permite gestionar sistemas BPM, además consultar el estado y controlar la ejecución de las instancias de procesos de negocio.

1.4 UML UML es un lenguaje gráfico o visual que estandariza la representación del análisis y diseño orientado a objetos de sistemas, para lo cual posee varios tipos diagramas; es un lenguaje de modelado de propósito general que puede ser aplicado a cualquier tipo de aplicación, en cualquier tipo de plataforma de implementación. Es de mencionar que no todas sus capacidades de modelado son útiles en todas las aplicaciones, por esta razón se estructura modularmente, con el fin de permitir seleccionar solamente las partes del lenguaje que son necesarias. La ventaja de UML es que los modelos que se realizan permanecen estables incluso a pesar de los cambios tecnológicos que se presenten.

1.5 MDA MDA soporta el ciclo de vida de las aplicaciones, el cual incluye el análisis, diseño, implementación, despliegue, integración, mantenimiento, gestión y evolución de las aplicaciones. Con base en modelos UML, el desarrollo basado en MDA busca integrar aplicaciones a través de una empresa e integrar aplicaciones de una empresa con aplicaciones de otra. MDA es una arquitectura de TI completa que unifica el modelado de negocio y la implementación. Anteriormente, el modelado y el código de programación eran desarrollados en forma separada, por diferentes grupos de personas, lo que ocasionaba que los programadores consideraran a los modelos simplemente como guías o planes, no como requisitos de la empresa pero MDA cambió estos paradigmas. Sin embargo, esta aproximación puede ser más costosa y puede


9

tomar más tiempo para producir una aplicación final comparada con el desarrollo sin modelado. Finalmente, en la actualidad se suele relacionar muy estrechamente arquitectura empresarial con SOA (Service Oriented Architecture), por lo tanto a continuación se realiza una breve descripción de este último término.

1.6 SOA Las técnicas SOA son aplicables a la capa de sistema de una arquitectura empresarial como una alternativa de desarrollo de sistemas. SOA es una aproximación para diseñar software, es una arquitectura en la cual las aplicaciones son ensambladas a partir de componentes reutilizables llamados servicios. Un servicio es un bloque de construcción de software o una implementación que ejecuta una función de negocio a través de una interfaz, la cual es básicamente una descripción de cómo llamar el servicio desde otros programas. Esta interfaz es definida de una manera neutral, es decir independientemente de la plataforma hardware, del sistema operativo y del lenguaje de programación de implementación del servicio, por lo tanto permite que los servicios interactúen con otros sin conocer sus detalles técnicos, ya que toda la interacción se realiza a través de la interfaz, característica conocida como débil acoplamiento entre los servicios. El beneficio de un sistema débilmente acoplado es su habilidad y agilidad para responder ante los cambios en la estructura e implementación de cada servicio que conforma una aplicación. Según lo anterior, SOA es una arquitectura en la que las aplicaciones pueden ser compuestas con módulos de software discretos que tienen interfaces simples, los cuales son orquestados a través de un débil acoplamiento para ejecutar una función requerida. Debido a esto, esos componentes software o servicios pueden ser reutilizados, lo cual se constituye en el principal rasgo de esta arquitectura. SOA es una evolución de la arquitectura cliente/servidor y posee dos roles: un proveedor y un consumidor de servicio. Un módulo software puede desempeñar ambos roles, además para lograr una operación apropiada de esta arquitectura, es necesario que el módulo que solicita el servicio conozca qué procedimiento de invocación y qué entradas y salidas son requeridas por ese servicio en particular. En los sistemas basados en SOA, los servicios individuales pueden ser construidos con diseños orientados a objetos pero todo el diseño en SOA es orientado al servicio. Es de mencionar que la orientación al servicio hereda principios de paradigmas anteriores como el de orientación a objetos, ingeniería de software basado en componentes y procesamiento distribuido abierto. Finalmente, los servicios pueden ser utilizados como parte de otros servicios, los cuales se conocen como servicios compuestos.


10

SOA está surgiendo como el primer framework de integración en el entorno computacional heterogéneo y complejo de hoy, en el que existe la necesidad de crear y mejorar soluciones empresariales en corto tiempo para responder a entornos de negocio cambiantes. Esta arquitectura puede ayudar a las organizaciones a racionalizar sus procesos de tal forma que puede hacer al negocio más eficiente y puede permitir que se adapte a las necesidades cambiantes, lo cual genera el surgimiento del concepto de software-as-a service. SOA debe ser capaz de relacionar los procesos de negocio con los procesos técnicos de una empresa. Al permitir el reuso, SOA disminuye los costos de integración de largo plazo y permite obtener aplicaciones de negocio de una forma más rápida. Esta aproximación puede requerir más esfuerzo en el diseño y en la planeación cuando el paradigma es utilizado por primera vez pero en teoría permite a las organizaciones construir sistemas incrementalmente de forma más rápida y más barata en la medida en que el inventario de módulos reutilizables crece con el tiempo. SOA se puede implementar con tecnologías basadas en XML (Extensible Markup Language) y en Web Services. Es de aclarar que Web Services no son la única forma de implementar SOA, ya que las arquitecturas son independientes de tecnologías específicas, sin embargo se suelen utilizar Web Services debido a que estos servicios simplifican y estandarizan la interfaz y el mecanismo de invocación. La diferencia entre SOA y Web Services es la que existe entre un concepto y su implementación, ya que Web Services son una aproximación específica y práctica para la implementación de SOA. Web Services proporcionan la tecnología de respaldo para SOA.

Web Services proporcionan el mecanismo de invocación estándar definido por WSDL (Web Services Description Language), el protocolo de comunicaciones estándar SOAP (Simple Object Access Protocol) y el mecanismo que soporta la gestión de localización de Web Services conocido como UDDI (Universal Description, Discovery and Integration). Además, posee directrices específicas sobre cómo se realiza la mensajería entre servicios, generalmente a través de mensajes SOAP entregados sobre HTTP. Los servicios se pueden definir y describir Top-Down o Bottom-Up. El primer enfoque permite obtener una descomposición funcional que hace posible identificar la funcionalidad de negocio y los servicios de más bajo nivel. El segundo enfoque permite realizar el análisis de activos existentes que son candidatos para conformar componentes (modularización) y realizar la exposición del servicio. Se puede emplear cualquiera de los dos o los dos en paralelo. Es de mencionar que SOA hace imposiciones, requiere un cambio de mentalidad, ya que la lógica de negocios debe ser vista dentro de un contexto orientado al servicio. Los principios orientados a servicio en sí mismos no son complejos, sin embargo la aplicación de estos principios puede resultar en soluciones relativamente complejas e introducir nuevos requisitos de tecnología e infraestructura.


11

Para terminar, a continuación se describe en términos generales un tema de gran relevancia tanto para una arquitectura empresarial como para una arquitectura orientada al servicio, conocido como gobernabilidad.

1.7 GOBERNABILIDAD La gobernalibilidad se relaciona con la publicación de una arquitectura empresarial actual u objetivo, con el conjunto de estándares de la empresa, su equipo de trabajo y el roadmap con estrategias de migración, además con los mecanismos, el soporte y el compromiso de gestión para lograr la consistencia y el refuerzo de la arquitectura empresarial. La gobernabilidad es crítica y para lograrla son necesarios procesos institucionalizados, repetibles, que promuevan la alineación de TI y del negocio, además generalmente requiere cambios organizacionales, ya que necesita la colaboración de ejecutivos, de arquitectos empresariales y de los encargados de los programas software para definir aspectos de la arquitectura, sobre la automatización de procesos, componentes e integración. Específicamente, en el ámbito de los servicios, adoptar e implementar un estilo arquitectural orientado a servicios requiere gestionar estos servicios posteriormente; sin un plan bien definido para hacerlo, la continuidad de la empresa se ve comprometida. La gestión de servicios también determina la dependencia que los negocios y las organizaciones tienen en TI para adquirir y procesar los elementos que conforman esos servicios. Finalmente, hoy en día se avanza en el campo de la Integración Orientada al Servicio o SOI (Service Oriented Integration), en el cual el bus de servicios empresariales tiene una gran importancia ya que es un mecanismo para lograr la mediación, el enrutamiento y la transformación de invocaciones de servicio en forma independiente del proveedor del mismo, lo cual ayuda a superar muchos de los inconvenientes asociados con conexiones punto a punto.


12

CONCLUSIONES Una arquitectura empresarial es fundamental para lograr que TI efectivamente soporte y facilite los procesos de negocio de una organización, ya que permite alinear la estrategia de negocio con la infraestructura de comunicación y los servicios de información de una empresa. Es importante seleccionar un framework apropiado para lograr una descripción clara y completa de una arquitectura empresarial, que contribuya a que la organización cumpla sus fines y metas. Existen varios frameworks y uno de los más utilizados es el Framwork Zachman, el cual plantea una matriz bidimensional de 36 celdas para describir todos elementos de una empresa y sus relaciones. BPM es una alternativa para modelar procesos de negocios, es decir para describir la capa de negocio, mientras que UML y MDA son opciones para realizar el análisis y diseño de sistemas, es decir para describir la capa de aplicación, sistema o solución. Arquitectura empresarial no es equivalente SOA, ya que SOA es una arquitectura que puede ser una alternativa para una aplicación. Por su parte, SOA no es equivalente a Web Services, éstos son una opción para implementar SOA y no son la única forma de hacerlo pero sí son la más utilizada recientemente por sus ventajas. El tema de la gobernabilidad es fundamental, ya que una arquitectura sin directrices no proporcionaría los lineamientos necesarios para poder utilizarla, para mantenerla y lograr su evolución junto con el desarrollo de la empresa y de su entorno.


13

BIBLIOGRAFÍA Institute for Enterprise Architecture Developments. (octubre de 2010). EnterpriseArchitecture.info. Recuperado en octubre de 2010, de http://www.enterprisearchitecture.info/ Minoli, D. (2008). Enterprise Architecture a to Z - Frameworks, Business Process Modeling, SOA, and Infrastructure Technology. New York: Taylor & Francis Group. Villalobos, J. (2009). Estructuración de soluciones SOA a partir de una vsión de arquitectura empresarial. XXIX Salón de Informática - Desarrollo de aplicaciones orientadas a servicios: de la teoría a la práctica. Bogotá. Villalobos, J. (2010). Integración de sistemas de información usando SOA. Seminario SICC. Bogotá.


14


15

ARQUITECTURA EMPRESARIAL: UN NUEVO

Recommend Documents