Arquitectura Empresarial en el Contexto de BPM

3.1. Trasfondo histrico

El concepto de arquitectura en general se remonta hace mas de siete mil aos atrs si pensamos cuando se construyeron las pirmides egipcias. Uno de los tratados mas conocidos sobre arquitectura se remonta a la poca romana hace dos mil aos atrs: Marcus Vitruvius Maximus Pollio (80 - 10 aC) Mefini el concepto del arquitecto y la arquitectura de la siguiente forma: El arquitecto debe estar equipado con el conocimiento de muchas disciplinas V diferentes tipos de sabiduras, porque es por su juicio (su obra) que por las otras artes es juzgado. Su arte es la experticia 2 de la prctica y el conocimiento de la teora. La prctica es el regular y continuo ejercicio del arte en donde se modela la materia de acuerdo al diseo de un bosquejo. Por el otro lado, la teora es la habilidad de explicar, mostrar y demostrar los productos ejemplares, basndose en los principios de las proporciones3.
1 ver: http://ww\\\thelatinbraiy.com/\tmvius.htm]2Traduccin literal: hijo, nacimientos ver-

http://www.thelatinlibrary.com/vitruvius.htm: Caput Primum, [1] Architecti est scientia pluribus disciplinis et variis eruditionibus ornata, [cuius iudicio probantur omnia] quae ab ceteris artibus perficiuntur. Opera ea nascitur et fabrica et ratiocinatione. Fabrica est continuata ac trita usus meditatio. quae manibus perficitur e materia cuiuscumque generis opus est ad propositum deformationis. Ratiocinatio autem est. quae res fabricatas sollertiae ac rationis proportione demonstrare atque explicare potest.

71 Marcus Vitruvius describi su obra en 10 libros, llamados De architectura libri decem" los principios sobre arquitectura, entre estos: Estabilidad Empleabilidad Simetra Encanto, belleza Proporcin Haba que seguir estos principios de acuerdo a la misin de lo que haba que construir, es decir el arte de construir bien de acuerdo a estos principios. Estos principios prevalecen hasta el da de hoy, aunque debo de admitir que en ocasiones nos encontramos con obras modernas que no respetan algunos de estos principios. Por ejemplo me he encontrado con salones de eventos de mas de 500 metros

cuadrados que no tienen una altura mayor a 3 metros. Estos salones dan la sensacin de encierro, sobre todo cuando se encuentran cientos de personas en ellos. En este caso no se respeta las relacin de largo por ancho por altura; es decir los principios de proporcin y simetra.

3.2. Introduccin 3.2.1. Qu es una arquitectura?

Cuando escuchamos la palabra arquitectura por lo general pensamos en la estructura y en los planos de un edificio, pero en realidad el concepto de arquitectura est relacionada con cualquier tipo de obra, puentes, barcos, carreteras, monumentos y no solo construcciones fsicas sino tambin abstractas como organizaciones, aplicaciones y sistemas de software. La norma 1471-2000 del IEEE[Hilliardoo] define el trmino de arquitectura como: the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principies guiding its design and evolution, where: fundamental organization means essential, unifying concepts and principies system includes application, system, platform, system-of-systems, enterprise, productline,... environment is developmental, operational, programmatic, . . . context of the system Podemos resumir que el trmino arquitectura se refiere a un todo estructural. Se trata mas que el detalle de mostrar la relacin entre las partes en un entorno complejo. Se responde por consiguiente a la pregunta de por qu? se necesita una arquitectura: Los sistemas organizacionales son complejos y por lo general dinmicos, es decir estn sometidos al cambio de requerimientos, la mejora y la actualizacin.

3.2.2. Qu es una Arquitectura Empresarial (AE)?

Para entender qu es una arquitectura empresarial 4y para qu sirve? se va a usar el ejemplo de la construccin de un edificio. Antes de empezar a construir un edificio la empresa constructora requiere de todos los planos comenzando por los planos estructurales que define la estructura fundamental de la obra sobre los cuales se sustentan los fundamentos, pilares fundamentales, esttica y estabilidad del edificio. Luego por cada planta y por cada departamento existen planos que muestran la distribucin de los espacios. Adems, por cada instalacin como electricidad, gas, calefaccin, caeras de agua fra y caliente, desage, red hmeda, red seca, red de cableado de televisin y telfono, existen planos individuales. Todos estos planos tienen puntos de conexin: el edificio con sus proveedores externos, provisin de reas comunes, distribucin entre plantas y departamentos y finalmente por cada

departamento debe existir un plano por cada instalacin. Ahora formulamos la pregunta si usted como dueo de un departamento quiere agregar un interruptor de luz a la salida de la cocina al comedor, porque solo se puede prender y apagar a la entrada de la cocina que es por hall principal. Bueno, tendr que llamar a un electricista y lo primero que har es pedirle los planos para estudiarlos y hacerle una propuesta de un proyecto elctrico. Qu sucedera si los planos se perdieron o ya no existen? En trminos vulgares diramos hay que entrar a picar para ver por donde van los ductos!. Si esta situacin la comparamos con una organizacin o empresa y sta requiere realizar un cambio, en similitud al caso del edificio, podramos preguntar, donde estn los planos para estudiar que podemos aprovechar y donde impactan los cambios? Es aqu entonces, donde por general nos encontramos con una triste realidad: los planos no existen!, hay que entrar a picar!. En una organizacin entrar a picar significa realizar un ante-provecto y levantar toda la informacin necesaria para el estudio de factibilidad tcnica y econmica. Si tuviramos los planos empresariales podramos ahorrarnos gran parte del ante-provecto, en este sentido el anteproyecto reconstruye los planos y se puede pasar directamente a la etapa del estudio de factibilidad.
4ingls:

Enterprise Architecture (EA) Anlisis

sobre literatura relacionada

Si revisamos la literatura relacionada con el trmino Enterprise Architecture nos vamos a encontrar con cientos de libros, artculos, white papers, handbooks de conferencias, papers indexados, y tambin con algunos centros dedicados al tema5. Profesionales y acadmicos se han dedicado al tema con diferente intensidad desde 1987 cuando aparece el primer artculo publicado por John Zachman[Zachman87l en un journal de IBM, en el cual propone aplicar el concepto de arquitectura para la planificacin y alineamiento de proyectos de TI con la estrategia de la empresa. Schdnherr [Schonherro8]present un estudio en la conferencia internacional TEAR 6 en donde analiz mas de 126 publicaciones hasta el ao 2008 relacionadas con el trmino arquitectura empresarial (ver Figura 3.1). Del total de publicaciones el 56 % corresponden a contribuciones acadmicas, el resto se lo dividen empresas consultoras con 21 %, sector pblico 6 %, compaas de
5 http://www.enterprise-architecture.info http://www.opengroup.org/architecture/togaf/ http: //www.zachman.com http://wvvw.whitehouse.gov/omb/egov
URL revisadas el 23-01-12
6Trends

of Enterprise Architecture Research

TI 7 % y otros con 10 %. En este contexto es notable notar que el 36 % de estos artculos se concentran analizar buenas prcticas y conceptos para introducir AE en la organizaciones. Lo que asombra en el campo asociado a teora y praxis es de que a pesar de que la ciencia le ha dedicado muchos esfuerzos y recursos desde hace bastante tiempo atrs a la investigacin del concepto de arquitectura empresarial [SchnherroS, Bucklo9, Lankhorst09, WinterSchelpoS, Schekkermano4, Ross et al 06] entre otros, rara vez o en muy pocas ocasiones nos encontramos con un departamento de arquitectura empresarial en una empresa u organizacin. Por lo general podemos decir que el concepto ha sido adoptado con bastante xito para mapear y documentar las estructuras empresariales, principalmente los procesos de las organizaciones. Sin embargo ninguno de los autores estudiados ha podido responder porque hasta el momento no se le ha dado la suficiente importancia estratgica al tema en las empresas de utilizarlo como instrumento de planificacin, alineamiento y control de requerimientos de cambio y proyectos. Mas adelante retomaremos este tema.

199 4
.2%

200 8

200 5
8%

2004 17%

2003 16%

200 2 6%

Figura 3.1: Distribucin de artculos sobre Arquitectura Empresarial en el tiempo Fuente: [SchonherroS] Definiciones de arquitectura empresarial En el prrafo anterior vimos que la literatura sobre el arquitectura empresarial es abundante y se encuentran muchas definiciones al respecto, pero la mayora de ellas coinciden que una AE es un conjunto de modelos y sus relaciones que describe la empresa como una estructura coherente. Su principal funcionalidad es de proveer de un fundamento para lograr mayor agilidad y control en la gestin del cambio en las empresas. Veamos algunas de estas definiciones: Zachman[Zachmani2]: Enterprise Architecture is the total set of intersections between the Abstractions and the Perspectives that constitute the total set of descriptive representations relevant for describing an Enterprise. Schekkerman[Schekkermano4]: Enterprise Architecture is a complete expression of the enterprise; a master plan wich acts a collaboration forc between aspects of business planning such as goals, visions, strategies and governance principies.

Lankhorst et al [Lankhorstog]: Enterprise architecture: a coherent whole of principies, methods, and models that are used in the design and realisation of an enterprises organisational structure, business processes, information systems, and infrastructure. Si buscamos un denominador comn de todas estas definiciones podramos resumir: Una Arquitectura Empresarial es un conjunto de modelos que describe la empresa como una estructura coherente, documenta el estado actual de la organizacin, el estado deseado y la brecha entre ambos. Con el objetivo de abstraer y sintetizar la complejidad de un sistema organizacional es necesario distinguir y gestionar los niveles y vistas de la Arquitectura Empresarial por separado. Para lograr la separacin de las capas de Negocio, Integracin y Aplicaciones es necesario disear y construir una Arquitectura Empresarial que cumpla con los siguientes requisitos: Cada capa tiene sus objetos y lgica propios Cada capa debe gestionarse en forma separada pero en coherencia con las dems Este enfoque obedece a la tendencia actual de desbloquear las aplicaciones monolticas del pasado, modernizar e integrar a travs de nuevas componentes de servicios y de esta forma acelerar los procesos de negocio, que finalmente es uno de los objetivos principales que persigue BPM. Desde el punto de vista estructural una arquitectura empresarial es: un mapa del negocio y la organizacin, la descripcin de los objetivos del negocio, la descripcin de los procesos de la organizacin, la descripcin a nivel funcional de los servicios de la organizacin, la descripcin de las interfaces a nivel macro de los sistemas de la organizacin, la descripcin de los sistemas reales implementados y la descripcin de sus productos, servicios y sus mercados. En el MIT Center for Information Systems Research nos encontramos con una definicin de arquitectura empresarial que centra el foco de su atencin en definir la estrategia del modelo operacional del negocio en dos pilares fundamentales que se tienen que construir para lograr los objetivos de BPM, la estandarizacin va integracin de los procesos: [Ross et al 06]: Is the organization logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the companys operating model. The enterprise architecture provides a long- term view of a companys processes, systems, and technologies so that individual projects can build capabilities - not justfulfil immediate needs. Roos et al clasifica el tema de arquitectura empresarial como un instrumento de estrategia corporativa7. En general el concepto de arquitectura empresarial apoya muchas disciplinas de gestin como gestin de calidad, gestin de riesgo, auditora entre otras como veremos en la seccin 3.2.4 Areas de una AE. " De alguna forma podemos comparar un repositorio de una AE con una base de datos

corporativa de un ERP. El gran beneficio que tiene una base de datos corporativa de un ERP integrado, es de que el sistema de ERP que administra los datos de los recursos empresariales garantiza la integridad de los datos en un slo lugar, es decir libre de redundancia y sin anomalas. De la misma forma un repositorio integrado de una plataforma o herramienta de AE administra los datos de los modelos organizacionales y garantiza la integridad de estos en su solo lugar. Todas las reas de negocio pueden o mejor dicho deben recurrir a estos como fuente de informacin y deben mantener actualizados sus modelos de negocio.

3.2.3. Drivers y Objetivos de una AE

Zachman describi acertadamente las razones de por qu se justifica o hace necesario trabajar con un concepto de una arquitectura empresarial en una organizacin: 1. Levantar y construir los modelos: Si la empresa existe tambin existen los modelos Es necesario invertir en construir los modelos 2. La empresa es el sistema La suma de los procesos manuales y automatizados son la empresa 7[Ross et al 06]:
Enterprise Architecture as Strategy

AE no es un problema tcnico, es un problema empresarial 3. La realidad organizacional es la necesidad de estructuracin Todas las necesidades que requieren un buen funcionamiento de los procesos y sistemas son necesidades empresariales Nada es mgico: La excelencia se va construyendo paulatinamente. La tecnologa juega un rol importante en esto. Como visto anteriormente las organizaciones son sistemas complejos por lo que se da la necesidad de abstraccin, pero no es la nica razn que justifica el empleo o la existencia de una arquitectura empresarial. Existe una serie de drivers 8 tanto internos como externos que requieren de mando y control. La figura 3.2 muestra estos drivers que son impulsados al interior de la organizacin (drivers internos) o requerimientos que impactan desde afuera a la organizacin (drivers externos).

3-2: Drivers de una AE

^Utilizamos el trmino en ingls porque engloba una serie de significados en conjunto que son difciles de

traducir como, hilo conductor, motivador, gatillador, justificador, necesidad, etc..

Todos estos drivers los podemos administrar por medio de un repositorio integrado de una herramienta de AE. Veamos a continuacin el significado de cada uno de estos drivers. Necesidad de Abstraccin Como descrito anteriormente, si la empresa existe tambin existen los modelos, pero qu se entiende por un modelo y de qu nos sirve? El origen de la palabra modelo proviene del italiano modello y se refiere a una representacin simplificada de un objeto de la naturaleza. Como la realidad universal es para nosotros infinitamente compleja, para comprenderla se da la necesidad de abstraer y sintetizar el objeto de observacin. Las principales caractersticas de un modelo son: La representacin simplificada de un objeto real o abstracto Solo descrito hasta un cierto nivel de detalle Descrito para representar solo el aspecto de inters Descrito para cumplir un objetivo declarado Supongamos que queremos reconstruir un modelo de la torre Eiffel de Paris9en la escala 1:300, entonces tendra 30 cm de altura. Para los efectos de conocer y estudiar su tipo de

arquitectura sera suficiente. Adems se puede transportar y exponer en cualquier lugar. El mismo efecto se puede lograr con una arquitectura empresarial documentada en base a modelos. Todas las vistas que se requieren de una organizacin como estructura organizacional, mapas de procesos, productos y servicios, arquitectura de servicios de software, infraestructura de TI y otras, se pueden representar en modelos descriptivos. Al disponer con vistas abstradas y sintetizadas facilita la comunicacin y coordinacin con las personas encargadas de cada una de estas reas. Un modelo permite, facilita y habilita la coordinacin de proyectos que transcienden las diferentes capas de una organizacin. Una plataforma de arquitectura empresarial administra las versiones de estos modelos.

Estandarizacin
En otros rubros mas antiguos de la industria que la informtica tenemos el ejemplo de los beneficios que tiene la estandarizacin. En mecnica contamos con mas de 100 aos de normas de estandarizacin, en la medicina y en el rubros de telecomunicaciones no es diferente. Se puede imaginar el lector si en telecomunicaciones no existieran protocolos estandarizados de comunicacin? La consecuencia sera que los usuarios no
9Su

altura es de 309,63 m sin su antena

podran comunicarse de una compaa a otra, ni tampoco podran comunicarse con sistemas antiguos. La estandarizacin en el rubro de comunicaciones garantiza que un usuario con un Smartphone pueda comunicarse con un punto telefnico en Sibiria que data de hace mas de 50 aos atrs, es decir compatibilidad hacia abajo, por lo menos en lo que se refiere a la comunicacin de voz. Este ejemplo de estandarizacin no es evidente en los sistemas informticos. Los esfuerzos de estandarizacin no van mas all de diez aos en el rubro informtico, pero hubo un retraso de mas de 40 aos al respecto. Contar con un estndar en BPM y en TI facilita la comunicacin, la interoperabilidad, la independencia de plataformas tecnolgicas, la transparencia, la formacin de profesionales, la certificacin de habilidades, las reglas de modelado, la documentacin de modelos referenciales y por ende los costos de operacin y la agilidad de negocio. La arquitectura empresarial, si cuenta con un metamodelo que pueda rubros de telecomunicaciones no es diferente. Se puede imaginar el lector si en telecomunicaciones no existieran protocolos estandarizados de comunicacin? La consecuencia sera que los usuarios no
9Su

altura es de 309,63 m sin su antena

podran comunicarse de una compaa a otra, ni tampoco podran comunicarse con sistemas antiguos. La estandarizacin en el rubro de comunicaciones garantiza que un usuario con un Smartphone pueda comunicarse con un punto telefnico en Sibiria que

data de hace mas de 50 aos atrs, es decir compatibilidad hacia abajo, por lo menos en lo que se refiere a la comunicacin de voz. Este ejemplo de estandarizacin no es evidente en los sistemas informticos. Los esfuerzos de estandarizacin no van mas all de diez aos en el rubro informtico, pero hubo un retraso de mas de 40 aos al respecto. Contar con un estndar en BPM y en TI facilita la comunicacin, la interoperabilidad, la independencia de plataformas tecnolgicas, la transparencia, la formacin de profesionales, la certificacin de habilidades, las reglas de modelado, la documentacin de modelos referenciales y por ende los costos de operacin y la agilidad de negocio. La arquitectura empresarial, si cuenta con un metamodelo que pueda representar estos estndares, aporta a la integridad de los datos en los modelos que siguen los estndares. BPM Governance En la seccin 2.1.1 definimos BPM-Governance como un modelo de gestin corporativa orientada a procesos pero integrada con todas las capas de una organizacin, las fases del ciclo de gestin, la gestin del cambio de nuevos requerimientos, la estructura organizacional y todos los instrumentos de alineamiento de y entre las estructuras corporativas. BPM Governance abarca el alineamiento con todo el ciclo de gestin corporativa desde la planificacin y gestin estratgica, la definicin de planes de negocio, el ciclo presupuestario, la definicin de perfiles y cargos, la gestin en operaciones, apoyo tecnolgico hasta el alineamiento con el portafolio de proyectos corporativo. La pregunta clave que se da en este contexto es de como podemos cumplir con los requerimientos de integracin de modelos sin una plataforma que permita relacionarlos y mantener miles de relaciones de negocio10que se conocen y aplican en un repositorio integrado como ARIS. Otra pregunta clave es como mantener el control en la dinmica del cambio empresarial sin el apoyo de una plataforma que mantenga relacionados los objetos de un modelo con otro. Se agrava la situacin aun si incorporamos la dimensin del tiempo. La situacin actual de un modelo es una dimensin, pero cmo controlamos las n dimensiones que estn destinadas al cambio (futuro)? Si adems se considera que cada capa tiene su propio ciclo de vida y de que tienen que ser coordinadas con las otras en n dimensiones de tiempo, cmo mantenemos el control? Conocimiento experto puede ser una respuesta, pero aunque dudo que un experto pueda controlar todas las variables en su mente, queda por responder si la evolucin no tiende a estandarizar las buenas prcticas. La respuesta es evidentemente que s, nos guste o no nos guste! La
10La

plataforma ARIS ofrece mas de mil relaciones de negocio en su metamodelo

robtica es un ejemplo que reemplaza la mano de obra de un obrero o de un cirujano a una mquina. En algunos casos ha reemplazado completamente la mano de obra como en algunos pasos de la industria automotriz o en la minera y en otros casos el

robot apoya en forma mas precisa la mano del ser humano como en algunos casos de la ciruga. En el mbito de la arquitectura empresarial nos encontramos con el mismo fenmeno. Podemos mejorar la comunicacin, estandarizar la forma de documentacin, estandarizar los mecanismos de alineamiento, reducir la complejidad, llevar un control de versiones y de cambio3, mejorar la integridad de los datos y crear una base de conocimiento corporativo. Time to market Se entiende en marketing bajo time to market4 el tiempo que se requiere para introducir un nuevo producto o servicio (innovacin) al mercado desde que es concebido hasta que est disponible para la venta. Empresas que mantienen un rea de investigacin y desarrollo (I+D) cuentan con un proceso en la cadena de valor llamado Product Lifecvcle Management (PLM), entonces el time to market es el tiempo de ciclo del proceso PLM que se intenta constantemente reducir al mximo. Por lo general el PLM comienza con el estudio de mercado, demanda estudiada que se combina con ideas de innovacin. El I+D en el PLM est fuertemente anclado con el concepto de creacin de valor para el cliente. La figura 3.3 muestra el tpico ciclo del PLM. El ciclo de I+D en PLM no se inicia como antiguamente en forma independiente de las tendencias que muestran los mercados, sino que igual que un proceso de negocio, es impulsado por los clientes (estudio de mercado, evaluacin del CRM, encuestas, peticiones de clientes) y los productos nuevos estn dirigidos a satisfacer esta demanda, es decir de los clientes y para los clientes. Por lo general los productos nuevos se validan con algunos clientes escogidos antes de ser liberados5. Si el time to market de una innovacin de una empresa es significativamente menor que la de sus competidores, la empresa se posiciona como pionera logrando importantes ventajas competitivas: Mejor cobertura de mercado Curva de retorno de inversin mas rpido, debido que al principio se puede comercializar a precios mas altos Se convierte en referente; los dems en seguidores

3 Change Management)i2p0(jram0S traducirlo del ingls como tiempo de mercado, pero es inusual este trmino en la prctica 5ingls: proof of concept

I + D

Lneas de negocio

Ventas/ P reventa

Mercado / clientes

JFigura 3.3:

Product Lifecvcle Management (PLM)

De los clientes

La importancia que puede tener el time to market lo podemos analizar en el caso de la empresa Kodak, la cual fue lder en su tiempo en el mercado de fotografas en pelculas y no logr a tiempo la transicin a la fotografa digital.
Productos y servicios nuevos

La problemtica los aos 80 reemplazar por la

que se le present a Kodak comenz a fines de cuando la fotografa tradicional se comienza a digital,

siendo el giro principal de la compaa la produccin de pelculas. El cambio de tecnologa afect al core del negocio, es decir la pelcula es sustituible por otro medio para el mercado de las fotografas y mas tarde tambin para las pelculas. El problema para la compaa fue de que se saba que el mercado de las pelculas tradicionales tendera en cinco o diez aos a reducirse asintticamente hacia niveles tendientes a cero. Kodak por no reaccionar a tiempo perdi ao a ao el mercado y nunca logr recuperarse, a pesar de los esfuerzos tardos de desarrollar productos digitales. A Kodak el fallido time to market le cost su existencia, hoy es una compaa quebrada. Ahora bien, qu relacin tiene este driver tan importante con el concepto de arquitectura empresarial? La arquitectura empresarial puede contribuir en dos aspectos importantes a reducir los tiempos de ciclo del PLM: 1. Identificar los elementos que se pueden reaprovechar de las estructuras existentes 2. Evitar iteraciones en las etapas de planificacin y especificacin aprovechando la buena documentacin que entrega una base de modelos integrada de una arquitectura empresarial Si la empresa tiene documentado en un repositorio integrado sus procesos,Q

productos y servicios, mapa estratgico y objetivos de negocio, aplicaciones infraestructura de TI, entonces puede revisar en que componentes impacta el nuevo producto. Se ahorra el tiempo de levantar y validar toda esta informacin. Por otro lado muestra relaciones de negocio documentadas que fcilmente se olvidaran al levantar por primera vez la informacin requerida. Gestin de calidad El grado de xito de los proyectos se manifiesta finalmente en la calidad de los productos que se entregan al finalizar stos. Los modelos que se desarrollan en el marco de una arquitectura empresarial facilitan la comunicacin y el entendimiento comn sobre los requerimientos entre las capas de estrategia, negocio y tecnologa con los diferentes stakeholders. El empleo de los modelos de una AE conlleva a una mejora sustancial de los procesos de planificacin y permite detectar y evitar redundancias y aprovechar sinergias de otros proyectos en curso. Otros aspectos como cumplimiento de regulaciones, seguridad y mejor control se complementan positivamente con los atributos de calidad de productos y servicios. Drivers externos Drivers externos son aquellos factores que impactarfi desde afuera a la organizacin y esta no los puede influenciar, pero si debe responder a ellos. Los principales drivers externos que pueden ser apoyados eficientemente por una AE son: El frecuente cambio inducido por los efectos de la globalizacin Cumplimiento de regulaciones existentes o nuevas Relaciones con externos Fusiones y adquisiciones La Globalizacin Existe reconocidamente solo una constante en los mercados globales que es el cambio y ste es cada vez mas frecuente. Como se ha dicho en la introduccin a este libro, la globalizacin est demandando mayores exigencias, tanto a las empresas privadas como a las organizaciones pblicas, en su capacidad de reaccin frente a los cambios exigidos por el mercado. La empresa que pueda adaptarse mas rpido a los constantes cambios en el mercado, que son adems cada vez mas frecuentes, tendrn mayores ventajas competitivas que aquellas que no logran adaptarse al ritmo que la globalizacin lo exige14. Este es el desafo que reconocidamente en la literatura se responde con la necesidad de gestionar a travs de los procesos de negocio, pero BPM en si no ofrece ningn instrumento para administrar la complejidad del cambio frecuente. BPM se puede apoyar del concepto de administracin del cambio que ofrece una AE. El apoyo a la estandarizacin y la integracin de componentes es el fuerte de las arquitecturas empresariales. En este sentido BPM y AE se complementan como sal y agua. Cuando la sal se disuelve en

agua ante nuestros ojos, sta desaparece, pero existe y se puede volver a ella por medio de tcnicas de filtracin. As es tambin la relacin entre BPM y AE, podemos contemplar en forma agregada, generalizada o especializada, segn lo que se necesite, pero jams se pierde la relacin entre las partes. Cumplimiento de regulaciones Las regulaciones son el conjunto de procedimientos y reglas que adoptan las instituciones en el marco de polticas de negocio, sean estas de carcter legal, financiero contable, seguridad, arancelario, sanitarias, medio ambiente, u otros aspectos de inters no nombrados. En nuestro mundo cada vez mas poblado e integrado, las regulaciones son numerosas y aumentan en forma creciente. Una empresa global que exporta sus productos a todo el mundo debe cumplir con las regulaciones locales y globales. Para cumplir con ellas se les debe hacer seguimiento a cada una de ellas. El seguimiento de cumplimento de regulaciones se puede complementar perfectamente con el seguimiento de procesos de negocio, porque estn directamente relacionados. Para identificar en que etapas de un proceso de negocio influyen regulaciones, se pueden desarrollar vistas especializadas en una AE en la cual se relacionan las actividades de un proceso o un subproceso con las materias de regulacin. Si bien es cierto el seguimiento mismo del cumplimiento de regulaciones es tarea y responsabilidad de la capa de operaciones, la AE facilita en la etapa de planificacin y administracin del cambio identificar y mantener las relaciones necesarias. Relacin con externos En un mundo cada vez mas integrado es importante para las organizaciones de coordinar y disear las relaciones de negocio con su mundo externo en forma objetiva y formal. La estandarizacin y la integracin no solo tiende hacia el interior de una organizacin sino tambin al mundo externo. As nos encontramos con: Extensin de la cadena logstica, proveedores y clientes Alianzas tecnolgicas y comerciales 14Ver seccin 1.1 Informes peridicos con instituciones gremiales Informes peridicos con instituciones del estado Relaciones de outsourcing Relaciones con la comunidad6 Auditoras externas Integracin con bolsas de comercio (market place) Si consideramos que estos casos no son otra cosa que una relacin nter- procesos7,
Por ejemplo: los vecinos o habitantes de un lugar donde se instalar una planta productiva u otra empresa 7relacin entre procesos
6

se da la necesidad de modelar sus interfaces. El estndar de BPMN 2.0 cuenta un con diagrama especial llamado diagrama de coreografa para disear el flujo de mensajera con los participantes externos de un proceso de negocio. La AE se presta especialmente para documentar vistas individuales y relacionarlas con otras. Se evita redundancia, se facilita la comunicacin y prevalece la integridad. Fusiones y adquisiciones Si dos empresas se fusionan o una adquiere otra de un mismo rubro queda claro que tambin se deben fusionar y estandarizar los procesos de ambas compaas. Un desafo no menor que por lo general demora varios aos hasta que se logre. Migrar sistemas de informacin y armonizar procesos de negocio constituyen proyectos complejos y de alto riesgo. Nuevamente nos encontramos con el factor complejidad que para ser atendido y dominar los riesgos se requiere de una tcnica y un concepto que permita la abstraccin, la separacin de vistas, y sobre todo relacionar componentes. La fortaleza de un concepto de AE es justamente atender estos requerimientos recin nombrados. As debiera ser posible documentar los procesos y los sistemas de cada empresa por separado, desarrollar modelos referenciales y luego referenciar las componentes de cada empresa con los modelos referenciales. Estas vistas permiten planificar proyectos integrados que consideran dependencias lgicas y temporales.

3.2.4. reas de una arquitectura empresarial

Hasta el momento se trat la arquitectura empresarial en el contexto de BPM, pero el concepto de AE se puede concebir y aprovechar para integrar la planificacin de otras reas o disciplinas empresariales como lo muestra la figura 3.4.

Bajo BPO se entiende la externalizacin1Tde uno o mas procesos de negocio incluyendo el TI que los soporta. El BPO es el servicio mas completo que se pueda recibir como externalizacin porque incluye Data Center, Servicios de Comunicaciones, Application Management, Configuracin de los procesos a medida (workflow), Seguridad y mesa de ayuda. EL BPO constituye una relacin muy estrecha entre el cliente y el proveedor. Sus principales caractersticas son: Generalmente se trata de relaciones de largo plazo Integracin compleja entre proveedor y cliente Entrega del servicio es altamente dependiente de TI La entrega de servicio es repetitiva Es habitual que sea globalizada
17ingls:

Outsourcing

Empresas analistas estiman que el outsourcing de procesos es uno de los segmentos del mercado que tendr las mayores tasas de crecimiento. Las razones de este mercado con gran perspectiva de crecimiento son: El Outsourcing se justificaba antes con reduccin de costos

Para algunos procesos altamente estandarizados (Callcenter, reservas de hoteles, tarjetas de crdito) se pueden lograr servicios de alta calidad con mejores prcticas y seguridad transaccional Los proveedores globales pueden alcanzar un alto grado de especializacin y de excelencia en sus servicios Sin embargo no se debe confundir que con el BPO se externaliza la administracin de la solucin, no la operacin misma del negocio. La gestin del proceso es el core del negocio y debe seguir bajo control del dueo del negocio. Por consiguiente queda claro que el cliente de BPO se concentra en la gestin estratgica y en el diseo y rediseo de los procesos y comunica los requerimientos de adaptacin y cambio al proveedor de BPO. La pregunta clave es entonces qu instrumentos va a utilizar el cliente para especificar y documentar la lgica de negocio, definir los niveles de servicio lS, llevar a cabo los procesos de alineamiento y control de cambio? Una plataforma de AE se convierte en el instrumento predestinado para estos fines. Se pueden administrar en forma integrada todas las funcionalidades mencionadas anteriormente y sobre la misma plataforma se pueden gestionar los mecanismos de coordinacin con el proveedor. Gestin de calidad - riesgo - conocimiento - regulaciones - otras El principio de la mejora continua en la gestin de calidad est fuertemente relacionada con BPM. La gestin de calidad debiera orientarse a los procesos de negocio, porque la calidad de los procesos est directamente relacionada con la calidad de los productos y servicios. La calidad es una propiedad o un atributo de bien y el conjunto de propiedades definidas de forma que se puedan medir, representan al grado de calidad de un producto o servicio. La gestin de riesgo19 tiene como objetivo manejar la incertidumbre relativo a la ocurrencia de un suceso negativo (amenaza) que puede, si sucede, afectar, parar o destruir la marcha de un, varios o todos los procesos organizacionales. Por consiguiente la gestin de riesgo se centra primero en identificar y evaluar los posibles riesgos. Al igual que en calidad, el riesgo es una propiedad de una actividad o de un proceso completo relacionado con los productos y servicios destinados al cliente.
l8SLA:

Service Level Agreement1gjng]s. management

El propsito principal de la gestin de conocimiento es controlar la curva de aprendizaje de las personas en una organizacin. La gestin del conocimiento est muy relacionada con la gestin del cambio (cultural) en una organizacin. Las personas para cumplir con sus roles de gestores, requieren de diferentes materias de conocimiento. Por lo tanto para detectar la brecha del grado de conocimiento

requerido con el grado de conocimiento existente, se da la necesidad de levantar la estructura del conocimiento requerido y representarlo en modelos igual que en las otras disciplinas de gestin. En gestin de regulaciones habr que identificar cuales actividades o procesos estn sujetos al cumplimiento de regulaciones y cuales son las variables que deben monitorearse para lograr una trazabilidad que lleve el registro de cumplimiento de ellas. Si admitimos que los procesos de negocio representan en forma figurativa la columbra vertebral de una organizacin, entonces podemos relacionar cualquier mbito de gestin a los procesos de negocio, modelos que debieran de existir solo una vez (libre de redundancia). Cada rea de gestin debe recurrir como fuente y fundamento al mismo modelo de procesos y relacionar los objetos y atributos de sus modelos (calidad, riesgo, conocimiento, etc.) con el modelo central de procesos. Esto prcticamente no es posible sin una plataforma integrada con un repositorio comn. Justamente la funcionalidad principal de una plataforma de AE es la flexibilidad en la administracin de modelos y sus respectivas relaciones de negocio bajo un repositorio comn. Auditora Originalmente la auditora estaba limitada a la revisin de la contabilidad de una empresa o de una sociedad, realizada por auditores externos que dan fe pblica sobre la veracidad y exactitud sobre los registros contables y los estados financieros20. Sin embargo el concepto de auditora es empleado hoy en da como un proceso de control de gestin en diferentes mbitos21 como: Auditora informtica, proceso de control para determinar si un sistema de informacin mantiene la integridad de los datos, se cumplen los niveles de servicio, detectar fraudes, grados de vulnerabilidad y si se utilizan eficientemente los recursos. Auditora medioambiental, cumplimento de regulaciones medioambientales de una organizacin. Auditora jurdica, cumplimento de las clausulas de los contratos sujeta a penalidades, infracciones y garantas.
20Vase

definicin en el diccionario de la Real Academia Espaola (RAE) 2iSe denomina tambin auditora

interna

Auditora de innovacin, proceso de comparacin de la situacin actual con la innovacin esperada. Auditora presupuestaria y de operaciones (control de gestin), proceso que monitorea el cumplimiento del ciclo presupuestario y los objetivos de negocio. En general cualquier proceso de control interno de una organizacin es coercitiva y su

eficiencia puede evaluarse por medio de una auditora. Qu relacin puede tener la auditora interna con una AE? El auditor necesita una referencia para evaluar y medir si existen desviaciones de los objetivos de la auditora. Los modelos documentados en una AE presentan un excelente punto de partida para estos fines. El auditor puede verificar si las aplicaciones y procesos implementados en operaciones corresponden con los modelos validados por la direccin de la empresa. Recordemos que la auditora consiste en apoyar a los miembros de la empresa en el desempeo de sus actividades, objetivos que debieran estar documentados en una AE. Portafolio de proyectos Hoy en da es comn en las organizaciones desarrollar portafolios de proyectos para usarlos como medio de evaluacin. Sin embargo estos portafolios carecen de fundamento, si stos no consideran las mltiples dependencias que existen en y entre las capas de negocio, de integracin y tecnologas de informacin. Este hecho aumenta la complejidad si consideramos que existen tambin estados actuales y deseados en cada una de las capas y entre ellas[Hitpass-Richter93]. Sobre el conocimiento de la cadena de valor y tras haber identificado en un estudio las posibles oportunidades de uso estratgico de las tecnologas de la informacin, se planifica la implementacin procesos mejorados y nuevos servicios. La arquitectura empresarial documenta la descripcin de la cadena de valor y los procesos crticos sobre su base operativa. Sin esta base no existen fundamentos para el desarrollo de portafolios de proyectos que permitan mejorar y agilizar el proceso de decisiones organizacionales. La arquitectura empresarial debiera mostrar las dependencias naturales entre los modelos y las diferencias entre la situacin actual y la deseada. Por ejemplo un sistema, que suministra informacin a otro sistema, debera desarrollarse antes que los sistemas que dependen de esta informacin. Sin este conocimiento difcilmente podrn implementarse procesos de negocios integrados con los sistemas actuales y por consiguiente, tampoco podrn crearse nuevos servicios suficientemente integrados sobre la base de los sistemas existentes. ITIL22 ITIL es un modelo referencial de buenas prcticas para la gestin de servicios de tecnologas de la informacin en operaciones. ITIL describe procedimientos detallados de las actividades en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir como gua facilitadora que abarque toda infraestructura, traspaso de desarrollo a produccin y operaciones de TI.

En una AE se puede documentar el modelo especfico de ITIL adoptado a la organizacin de la misma forma de como se documentan los modelos referenciales de los procesos de negocio. El modelo de ITIL representado en la AE sirve como especificacin de implementacin, como manual de procedimiento, material de capacitacin, manual de referencia para auditoras y documentacin para el control de cambio de requerimientos.

3.4* Frameworks de Arquitectura Empresarial

Bajo un framework de AE se entiende un marco estructural que define los modelos, los tipos de objetos perteneciente a un modelo, las relaciones de negocio entre los tipos de objetos vas relaciones entre los modelos del marco para un rea de planificacin, especificacin y anlisis. Un framework de AE es por consiguiente un modelo de referencia pero estructural no procedural; define la estructura de un modelo, no los procesos. La primera propuesta de un framework de arquitectura empresarial lo desarroll Zachman en el ao 1987 [ZachmanSy], publicacin muy famosa en el IBM Systems Journal bajo el ttulo de A Framework for Information Systems Architecture. Si bien es cierto el propsito inicial de desarrollar un framework no estaba pensado para administrar un modelo integrado de arquitectura empresarial, es decir corporativa, como se concibe hoy en da, si mas bien por encargo de IBM de presentar un marco para alinear la estrategia de la empresa con las inversiones de TI. A pesar de que, como descrito anteriormente, el primer framework se present a mediados de los aos 80 no tuvo entrada la aplicacin de AE frameworks hasta una dcada despus. En el ao 1996 el Gobierno de EEUU promulg una ley para sus agencias federales, llamada Clinger-Cohen Act26, tambin llamada Information Technology Management Reform Act of 1996 que tiene por objetivo mejorar la gestin de los procesos de inversiones en proyectos de TI, basados en un framework de arquitectura empresarial27. Como consecuencia del Clinger-Cohen Act las agencias federales del gobierno norteamericano fueron exhortadas a implementar un enfoque holstico, apoyados por un framework de AE. El Gobierno Federal cre un consejo de directores de informtica (CIO Council) que se encarg de desarrollar un framework de AE para estos fines y que mas tarde se denomin FEAF (Federal Enterprise Architecture Framework)28. Este framework se utiliza hoy en da como modelo de referencia para las agencias estatales de EEUU y tambin est disponible para la industria privada (ver seccin 3.4.3). Tambin se desarrollaron otros frameworks en el area pblica:

TAFIM (Tecnical Architecture Framework for Information Management) encargado por el Ministerio de Defensa, DoDAF (Department of Defence), TEAF (Treasurv Architecture Framework) y otros no mencionados. A partir de mediados de los 90 el enfoque de arquitectura empresarial como instrumento pblico de mejor planificacin, alineamiento y control de gestin llama la atencin a la industria privada, la que a travs de diferentes iniciativas desarrollan sus propias
The "Information Technology Management Reform Act of 1996 is later renamed "Clinger- Cohen Act" for its co-sponsors, Rep. William Clinger, R-Pa., and Senator William Cohn, R- Maine. Fuente: http://en.wikipedia.org, revisado el 30-01-12
26

En el prefacio del CCA nos encontramos con la definicin y objetivos de una AE: CLINGERCOHEN ACT - PREFACE Section 5l25(d) of the Clinger-Cohen Act defines an information technology architecture as an integrated framework for evolving or maintaining existing IT and acquiring new IT to achieve the agencys strategic and information resources management goals. A complete IT architecture should consist of both logical and technical components. The logical architecture provides the high-level description of the agencys mission. functional requirements, information requirements, system components, and information flovvs among the components. The technical architecture defines the specific IT standards and rules that will be used to implement the logical architecture.
27 28Vease:

http: //www.whitehouse .gov/omb/e-gov/fea

propuestas de EA frameworks. La mas difundida de ellas es TOGAF (The Open Group Architecture Framework), desarrollada por un consorcio de empresas y profesionales de TI. Existe una abundante literatura tanto cientfica como profesional sobre EA frameworks, razn por la cual no se seguir profundizando en este trabajo el tema. El lector interesado puede consultar entre otros [Franke et al 09, Lankhorst09, MinolioS, Schekkerman04, Schekkermano, Takaakios], Los EA Frameworks no se pueden adoptar sin un estudio detallado de ellos y compararlos con la realidad organizacional de cada caso. Por esta razn muchas empresas se orientan en alguno de ellos, pero finalmente definen su propio marco estructural de arquitectura empresarial; resulta mas fcil que entender y adoptar estos compendios en detalle. Un estudio realizado en el ao 2007, revela que los frameworks mas utilizados en la prctica son el framework de Zachman (28 %), TOGAF (27 %) y FEA (8 %) de todas las encuestas realizadas a empresas[Schwarzero9] 29, razn por la cual vamos a presentar en forma muy resumida estos Frameworks. A pesar de que ARIS, no est nombrado en el estudio, lo vamos a presentar en el marco de este trabajo, porque es reconocidamente uno de los frameworks mas utilizados en Europa y empresas globales sobre todo aquellas que son usuarias de SAP.

3.4.1. Zachman
El framework de Zachman llamado The Zachman Framework" es un marco de trabajo para Enterprise Architecture (EA), creado y soportado por el instituto que lleva su nombre Zachman International3031. Este framework emplea modelos y vistas de los diferentes elementos que forman parte de la arquitectura empresarial, contemplando dos dimensiones: Perspectivas de participantes o modelos Preguntas esenciales a responder o puntos de vista El framework de Zachman sirve fundamentalmente para implementar una arquitectura empresarial en las compaas. Toda compaa, grande o pequea, necesita aplicar conceptos de arquitectura independientemente de sus caractersticas. Para implementar una AE, Zachman considera diferentes perfiles, roles y habilidades que deben participar en el proceso, e incide especialmente en los problemas de comunicacin y entendimiento existentes entre dichos perfiles.
29eitado en [Sehwarzer09]:Brown, Obitz, 2007, 2930http://zachmanin.tematonal.com3l^^gj^Qj.j^g^g gg

llam ZIFA: Zachman Institute for Framework Advancement

Zachman sostiene que cada sistema respondiendo alas siguientes preguntas:

32se

puede describir en forma completa

Qu? Los datos, sus relaciones y significados Cmo? Los procesos y funciones de la corporacin Dnde? La red, tecnologas, distribucin y localizacin de procesos, funciones y sistemas Quin? La gente que forma parte de la compaa, considerando aspectos como seguridad y roles hasta la organizacin de la compaa y los flujos de trabajo existentes Cundo? El tiempo, representando ciclos, estructuras de proceso, de control y eventos de negocio Por qu? Las motivaciones en los diferentes segmentos de la compaa: objetivos de negocio, planes estratgicos, diseo y especificacin de reglas, etc. Las perspectivas captan todos los modelos requeridos para el desarrollo de sistemas. Cada modelo est relacionado con un determinado perfil dentro de la compaa: Alcance: perfil Visionario o Planificador Negocio: perfil Propietario Sistema: perfil Diseador Tecnologa: perfil Constructor Representacin Detallada: perfil de ejecucin (Adjudicatario de Contrato) Configuracin de componentes: perfil Implementador Instancias funcionales de la empresa: perfil Trabajador

De las preguntas del negocio y las perspectivas de los participantes, Zachman desarroll una matriz, llamada The Zachman Framework. Lo que la matriz busca es ordenar la arquitectura y de que haya definiciones para cada uno de estos aspectos33. Al framework de Zachman se le reconocen los siguientes beneficios y ventajas: Es simple y fcil de entender
32 Para Zachman una organizacin tambin es un sistema33El autor slo tiene una licencia para USO

personal, y no est permitido publicarla. El lector interesado puede inscribirse en el sitio de http://zachmaninternational.com y bajar el framework con su propia licencia personal.

Contempla la Empresa como un todo Es independiente de herramientas y modelos Presupone que se requieren multimodelos para describir la organizacin desde sus diferentes perspectivas Entre las desventajas nos encontramos con los siguientes aspectos: El framework est muy orientado hacia TI, no cuenta con una perspectiva estratgica No incluye los procesos de alineamiento No cuenta con metamodelo Los modelos son independientes, no existe asociacin entre ellos El framework es slo descriptivo, no es posible reusar los modelos No incluye un proceso de anlisis

3.4.2. TOGAF Framework)

(The

Open

Group

Architecture

TOGAF son las siglas de The Open Group Architecture Framework y, por tanto, pertenece a The Open Group, un consorcio que est formado por empresas y profesionales del sector TI, con el objetivo de marcar directrices, independientes de fabricantes, en el mundo de la Arquitectura TI. Nacido a mediados de los 90, The Open Group ha trabajado de forma continua en la definicin y evolucin del framework. TOGAF a diferencia de otros frameworks cuenta con un marco estructural y una metodologa de procedimiento (ADM: Architecture Development Method) para la configuracin y el uso del framework. TOGAF esta compuesto de cuatro dimensiones: Arquitectura de Negocios (o de Procesos de Negocio), la cual define la estrategia de negocios, la gobernabilidad, la estructura y los procesos clave de la organizacin. Arquitectura de Aplicaciones, la cual provee un plano (blueprint, en ingls) para cada uno de los sistemas de aplicacin que se requiere implantar, las interacciones entre estos sistemas y sus relaciones con los procesos de negocio centrales de la organizacin. Arquitectura de Datos, la cual describe la estructura de los datos fsicos y lgicos de la

organizacin y los recursos de gestin de estos datos. Arquitectura Tecnolgica, la cual describe la estructura de hardware, software V redes requerida para dar soporte a la implantacin de las aplicaciones principales, de misin crtica, de la organizacin. Al framework de TOGAF se le reconocen los siguientes beneficios y ventajas: TOGAF es muy flexible y se adapta fcilmente a una organizacin TOGAF ofrece tambin un modelo de procedimiento llamado ADM (Architecture Development Method) Entre las desventajas nos encontramos con los siguientes aspectos: La arquitectura de negocio es dbil y no menciona los objetos y modelos a utilizarse La documentacin es muy abundante pero no siempre concreta, por lo que el usuario tiene que interpretar como usarla

3.4.3. FEA (Federal Enterprise Architecture)

Como fue descrito en la introduccin a los frameworks de AE, el Gobierno de EEUU promulg una ley en el ao 1996 para sus agencias federales, llamada Clinger-Cohen Act. Esta ley obliga a organizaciones estatales en EEUU a desarrollar y mantener una Arquitectura Empresarial (CIO Council, 2001). El objetivo principal del framework es lograr el desarrollo y mantencin de una plataforma de entendimiento comn en la integracin de procesos y sistemas de informacin entre las agencias estatales. La utilizacin del framework propone el uso de trminos comunes para la construccin de las arquitecturas de las diferentes instituciones pertenecientes al Gobierno. El objetivo es que cada segmento de la arquitectura pueda ser integrada dentro de una gran y nica arquitectura gubernamental. FEA [FEAo7]34se compone de varios modelos de referencias que crean una taxonoma y ontologa comn para la descripcin de los recursos TI, generando la arquitectura empresarial. Entre estos modelos se incluyen: Performance Reference Model
34 The Office of Management and Budgets (OMB) Office of E-Government (E-Gov) and Information

Technology (IT), with the support of the General Services Administration (GSA) and the Federal Chief Information Officers (CIO) Council, established the Federal Enterprise Architecture (FEA) Program which builds a comprehensive business-driven blueprint of the entire Federal government. The FEA Program Management Office (PMO), located within OMB's Office of E-Gov and IT, equips OMB and federal agencies with a common language and framework to describe and analyze IT investments, enhance collaboration and ultimately transform the Federal government. Fuente: FEA Consolidated Reference Model Document Versin 2.3, 2007, www.egov.gov., revisado 30-01-2012.

Business Reference Model Service Component Reference Model Data Reference Model Technical Reference Model

Entre las ventajas de poseer una FEA se encuentran: Organizar la informacin gubernamental a un nivel general de Gobierno Promover el intercambio de informacin entre los entes del Estado Apoyar a los entes gubernamentales en el desarrollo de sus arquitecturas Apoyar a las organizaciones gubernamentales a desarrollar sus procesos de inversin en TI Satisfacer a los clientes de Gobierno sus necesidades en mejor forma, en menos tiempo y con un menor costo Al framework de FEA se le reconocen los siguientes beneficios y ventajas: FEA ofrece un enfoque muy completo para la arquitectura de una organizacin Entrega en detalle una descripcin de las vistas y actividades que se necesitan para construir una AE FEA no impone metodologas de modelado por lo que es fcilmente adaptable a cualquier tipo de organizacin Entre las desventajas nos encontramos con los siguientes aspectos: La perspectiva estratgica es dbil y no menciona los objetos y modelos a utilizarse No cuenta con un metamodelo

3.4.4. ARIS (Architecture of Integrated Information Systems)

ARIS es un marco estructural desarrollado por Scheer[Scheer92] a principios de los aos 90, cuyo foco principal fue el desarrollo de una arquitectura que permitiera relacionar y describir procesos de negocio y sistemas de informacin en forma integrada. Para estos efectos Scheer presenta en su concepto estructural la descomposicin de modelos en niveles y vistas en el marco de una arquitectura llamada ARIS House, que distingue: Cinco Vistas Vista organizacional Vista de datos Vista funcional Vista de control Vista de productos y servicios35 Tres Niveles Implementacin Definicin de requerimientos Diseo y especificacin

La figura 3.8 muestra el esquema del ARIS House con sus cinco vistas y tres niveles. A diferencia de otros marcos metodolgicos, ARIS fue diseado desde un principio con un metamodelo documentado en [Scheer92, Scheer92-i] con un modelo de datos entidad-relacin (ERM). Este mismo metamodelo fue implementado en una herramienta de AE que lleva el mismo nombre de ARIS. El corazn de ARIS es una

tcnica para modelar procesos llamada EPC (Event driven Process Chains). EPC 36fue desarrollado en los aos 80 por Scheer en Alemania en el contexto de integrarlo en su concepto de una arquitectura de procesos de negocio y sistemas de informacin (ARIS). Scheer fue pionero en el sentido de descubrir la importancia que tienen los procesos para la gestin empresarial y el diseo de los sistemas de informacin. En ARIS son los procesos los elementos centrales (vista de control en el ARIS House) que se alinean con la estrategia corporativa y determinan el corte de los sistemas de informacin. Este concepto queda claro si se revisa la vista principal del metamodelo EPC 8 en el modelo de arquitectura de ARIS. La figura 3.9 muestra la vista del metamodelo EPC9 en la notacin EntidadRelacin: El tipo de objeto funcin10 es el elemento central de todo el metamodelo. funciones son las que transforman insumos en bienes de valor, formalmente inputs en
35 Esta vista fue agregada mas tarde3 Qese ]os aos 90 EPC se ha convertido en un cuasi estndar

industrial en los pases desarrollados.

8 La tcnica del EPC la trataremos con mayor profundidad en la seccin 6.338 metamodelo muestra

tambin objetos del modelo EPC extendido, razn por la cual lleva la letra e= extended para diferenciarlo del modelo esencial. 10Funcin es equivalente a una actividad en otras nataciones como en BPMN.

outputs. La funcin que puede ser en ARIS agregada (proceso o subproceso) o desagregada hasta su mximo nivel de descomposicin se puede relacionar con los principales objetos de las diferentes vistas de la arquitectura como lo indica el metamodelo eEPC. La funcin se relaciona por consiguiente con: Un cargo o rol organizacional es responsable de la ejecucin de la funcin. Un evento inicia una funcin y la funcin crea como resultado un nuevo evento, o nuevo estado del objeto de negocio. Una funcin apoya en algn grado directo o indirecto el cumplimiento de un objetivo de negocio. Una funcin apoya en forma intermedia o final la creacin de algn producto o servicio. Una funcin puede crear un documento. Una funcin utiliza en su proceso de transformacin datos que se agrupan conceptualmente en Datacluster.

Figura 3.9: Metamodelo eEPC de ARIS Una funcin es implementada o es utilizada por una aplicacin o sistema de informacin. Ha de considerarse que algunos de los tipos de objetos relacionados en este metamodelo no pertenecen a la vista EPC. As por ejemplo el tipo de objeto objetivo y producto o servicio son objetos de sus respectivas vistas, es decir del modelo de objetivos y del modelo de productos y servicios. En el metamodelo eEPC solo se muestran las relaciones de negocio que existen entre estos tipos de objetos. Cada objeto tiene su origen en su respectiva vista y debiera de existir solo una vez en el repositorio. Las relaciones de negocio definidas en el metamodelo permiten la integracin de los modelos segn la semntica definida, libre de redundancia. Para estos efectos la plataforma de ARIS pone a disposicin un tipo de diagrama llamado Function Allocation Diagram (FAD), en el cual a partir de una funcin seleccionada se pueden utilizar todo tipo de relaciones a objetos de diversos modelos para expresar la relacin que existe con la funcin del EPC. Por ejemplo se utiliza comnmente para relacionar una funcin de un proceso de negocio con un mdulo especfico del ERP de SAP y este mdulo a su vez con algn senador en el que corre. ARIS considera adems en su modelo de arquitectura las fases de modelamiento, expresado en tres niveles de cada una de las vistas disponibles: El punto de partida se representa en el primer nivel, la definicin de requerimientos o el problema de negocio a resolver. Este nivel permite expresar formalmente el requerimiento de negocio, es decir que sirva como especificacin para el diseo de un sistema de informacin.

El segundo nivel representa el diseo de modelos tcnicos pero an independiente de la tecnologa en que ser implementada. Entre el nivel de definicin de requerimientos y diseo tcnico existe un grado de bajo acoplamiento. El tercer nivel representa el diseo de implementacin en las componentes tecnolgicas de software y hardware seleccionadas. El framework de ARIS se puede utilizar de igual manera para planificar el desarrollo de software a medida o para la configuracin y adaptacin de software estndar. Con el tiempo se fue ampliando el concepto de arquitectura de ARIS. Se incluyeron funcionalidades de : Simulacin de procesos EPC Versionamiento y Change Management Repositorio abierto para incluir nuevos tipos de objetos y relaciones Reportes y estadsticas Posibilidad de representar otros marcos metodolgicos como IDEF, Zachman, City Planning; pero en forma restringida (comentario del autor) Interfaces a ERP (SAP) y una herramienta propia de minera de proceso (PPM: Process Perfomance Management) Nuevas componentes para integrar la planificacin estratgica (Strategv Platform) y los conceptos de control de gestin orientados a procesos (Controlling Platform). ARIS fue sin duda uno de los mejores conceptos de arquitectura empresarial orientado a procesos que se desarrollaron en los aos 90. El xito y la cobertura de mercado que logr lo demuestra y hasta hoy en da sigue liderando los cuadrantes de firmas analistas como Gartner y Forrester. Scheer vendi su participacin hace un tiempo atrs a Software AG, por lo que la empresa que el fund IDS Scheer, ya no es independiente de proveedores de BPMS o ERP s. Otro aspecto de no menor importancia es de que el fundamento se basa en el conocimiento y estndares de la dcada de los noventa y los conceptos cambiaron fuertemente a partir de la dcada del dos mil: De sistemas propietarios a estndares abiertos (XML,BPMN, SOA, etc..) De cliente servidor a aplicaciones web De infraestructura propia a servicios en la nube Si bien es cierto los fundamentos estructurales de ARIS son slidos, no es menos cierto que an el marco metodolgico y la plataforma tecnolgica no han sido adaptados a los nuevos conceptos, estndares y tendencias tecnolgicas. Entre ellos puedo enumerar: EPC no ha sido reemplazado por el estndar BPMN. La notacin BPMN fue incluida como un modelo adicional en ARIS, pero el core del metamodelo sigue siendo EPC.

La arquitectura sigue muv centrada en el proceso de desarrollo de procesos hacia la implementacin por medio de sistemas. La vistas estn descompuestas en los niveles del proceso de desarrollo (requerimientos, especificacin e implementacin). En una arquitectura empresarial moderna, los niveles del proceso de desarrollo son solo un aspecto de lo que se requiere para administrar un modelo de BPM Governance. La capa de SOA (Gobernabilidad de servicios) no se encuentra integrada en el metamodelo del repositorio de ARIS. Governance. La capa de SOA (Gobernabilidad de servicios) no se encuentra integrada en el metamodelo del repositorio de ARIS. Tecnolgicamente la arquitectura de software de ARIS an es cliente-servidor (con emulacin web). El concepto de arquitectura de ARIS, solo se ha implementado en su propia herramienta. El futuro de ARIS es incierto, habr que esperar como reaccionar su nuevo dueo"*0 respecto de los puntos enumerados recientemente. Dems est de considerar que las alianzas que haba creado IDS Scheer con Oracle, SAP y otros son actualmente competidores de Software AG.