La Arquitectura Empresarial y el Ingeniero de Sistemas

Los ingenieros de sistemas generalmente se concentran en el sistema que se está desarrollando actualmente, sin ocuparse mucho de la empresa que soporta dicho sistema. Este artículo explora los puntos de conexión que existen entre la arquitectura empresarial y la arquitectura de sistemas, y describe cómo la arquitectura empresarial beneficia y a la vez limita el desarrollo de sistemas. Su objetivo es ayudar a los ingenieros de sistemas a comprender mejor cómo sus esfuerzos en los proyectos que crean o modifican sistemas pueden verse limitados por, y pueden a su vez modificar la arquitectura de la empresa a la cual soportan dichos sistemas. En la empresa de hoy, impulsada por los negocios, existe una relación directa entre la capacidad de negocios de la empresa y la funcionalidad implementada en los proyectos.

El cambiante panorama del desarrollo de sistemas

Las empresas actuales están dejando de lado los sistemas separados que brindan funcionalidad aislada, para adoptar sistemas mucho más integrados en los cuales se potencian los servicios para ofrecer operaciones robustas y eficientes. Por lo tanto, los sistemas dentro de la empresa están más estrechamente integrados y los esfuerzos por modificarlos son más complejos. El ingeniero de sistemas que trabaja en un proyecto ya no se puede focalizar exclusivamente en el sistema que se está modificando, sino que también debe comprender cómo interactúa el sistema con otros sistemas dentro de la empresa.

La Figura 1 ofrece una descripción general de este cambio de foco. Anteriormente la arquitectura empresarial contaba con el soporte de sistemas separados independientes. Había un discreto distanciamiento entre la arquitectura empresarial y los ingenieros de sistemas, con sus problemas afines. Hoy en día el desarrollo de sistemas se basa mucho más en los negocios. Hay una fuerte necesidad de responsabilidad financiera de TI y los gastos en sistemas y éstos deben ajustarse a su beneficio comercial. Por ello, la alineación entre negocio y desarrollo es crucial. Hay una participación constante entre el arquitecto empresarial y el ingeniero de sistemas que conduce a una mayor alineación negocio/TI y colabora con la gobernabilidad técnica en todo el ciclo de vida, los arquitectos empresariales participan durante más tiempo y los ingenieros de sistemas se involucran antes. Por último, los servicios implementados soportan la obtención y el monitoreo de datos durante la operación. El análisis de este intercambio impulsa cambios futuros.

Figura 1: Alineación de arquitectura e ingeniería al inicio del ciclo de vida

Definiciones

Al hablar sobre sistemas en diferentes niveles es importante definir explícitamente términos que de otra manera serían ambiguos dada la diversidad de significados y usos existentes.

Empresa

Una definición de empresa es una organización de negocios i . La organización podría ser parte de una compañía, una compañía entera o incluso una participación en varias compañías. Para simplificar el tema, pensemos en una empresa como una compañía. Aunque hay una gran cantidad de maneras de analizar una empresa, con el fin de razonar acerca de la evolución de una empresa, es útil considerarla como un sistema a gran escala. Como todo sistema: a) tiene una razón de ser, ya que brinda ciertos valores a quienes se involucran en ella; b) posee una financiación que le permite operar; c) realiza algunas acciones, cumpliendo con una serie de requisitos; y d) está integrada por componentes, trabajadores y sistemas de menor nivel, que colaboran para que logre su funcionalidad. (A lo largo de este artículo, el término “componente” se utiliza para referirse a una parte del todo que colabora con otras partes.)

Arquitectura empresarial

Hay muchas definiciones para arquitectura empresarial. Por lo general, el término arquitectura empresarial aparece en mayúsculas como sustantivo propio (por ejemplo, la disciplina de la Arquitectura Empresarial), aunque, como usted podrá observar, nosotros no lo estamos usando de esta manera. Nos referimos a la arquitectura empresarial simplemente como la descripción de la arquitectura de la empresa en cuestión. La disciplina de la Arquitectura Empresarial aúna negocio, estrategia, proceso, método y componentes desde una cantidad de perspectivas diferentes. Estas perspectivas están definidas y varían según los diferentes enfoques dados a la Arquitectura Empresarial. Las Arquitecturas Empresariales son realizadas por Arquitectos Empresariales. Las responsabilidades de un Arquitecto Empresarial exceden el enfoque de este documento.

Por lo tanto el propósito de un arquitecto empresarial, según se define en este artículo, es describir los componentes de una empresa, sus relaciones, cómo colaboran e interactúan entre sí con el “mundo exterior”. Una arquitectura empresarial ofrece la orientación para implantar los componentes de la empresa. La implantación de los componentes produce un cambio en el estado de la empresa.

Sistema

Un sistema es un grupo de elementos que forman un todo unificado y cumplen un fin común ii . El fin común es la razón de ser del sistema. Uno o más involucrados reconoce/n la necesidad que satisface el sistema. Por lo tanto, el objetivo del sistema es satisfacer una serie de necesidades de los involucrados, es decir los requisitos del sistema. Estos requisitos incluyen qué funcionalidad se muestra y también cómo se muestra la funcionalidad dadas las cualidades requeridas y las limitaciones existentes (es decir requisitos no funcionales). El sistema satisface sus requisitos ejecutando un conjunto de acciones. Las acciones satisfacen las necesidades de los involucrados. Como el sistema es un grupo de elementos, las acciones del sistema son realmente ejecutadas mediante la colaboración de estos componentes.

Cabe destacar que los componentes pueden ser cualquier cosa: hardware, software o personas. Las personas que participan en un sistema como componentes colaboradores se llaman trabajadores. Algunos de los componentes en sí mismo, se pueden considerar sistemas en todo su derecho y generalmente se los llama subsistemas. Aunque en realidad los trabajadores también pueden considerarse sistemas, según lo descripto anteriormente, no los tratamos así, sino como objetos constitutivos ya que no nos incumbe aquí cómo colaboran sus partes internamente.

Ingeniero de Sistemas

El título de Ingeniero de Sistemas se ha aplicado a individuos que desarrollan cualquier actividad vinculada con la ingeniería de sistemas. Hemos observado “Ingenieros de Sistemas” responsables de todo, desde planeamiento, hasta obtención de requisitos, captura de arquitectura, integración y testeo. Muchas de sus actividades trascienden la disciplina tradicional de la Ingeniería de Sistemas. En este artículo, nos focalizamos en el rol del ingeniero de sistemas para garantizar que el resultado del esfuerzo de desarrollo se “ajustará” al resto de la empresa y operará de manera homogénea. Esencialmente, es responsabilidad del ingeniero de sistemas crear o actualizar la arquitectura del sistema, cumpliendo con todas las restricciones impuestas por la empresa en general.

Programa

Un programa es una iniciativa adoptada para cambar el estado de la empresa, para proporcionar alguna capacidad nueva o mejorada. Su propósito es mover a la empresa de su estado actual al estado futuro, modificando alguna parte de la empresa, agregando o modificando componentes de la empresa. Los programas se ejecutan mediante la implementación de uno o varios (normalmente varios) proyectos. Obsérvese que los programas pueden tener un alcance mucho menor que el de toda la empresa. Sin embargo, para simplificar el tema a tratar aquí, sólo expondremos los programas que impactan sobre toda la empresa.

Proyecto

Un proyecto es una actividad de desarrollo con un objetivo, inicio y fin específicos, focalizado en brindar algún resultado de valor mensurable que contribuya con una capacidad. Es común que un proyecto se focalice en la introducción de un sistema nuevo en la empresa, o la modificación de un sistema existente, aunque su alcance podría ser mayor o menor. Los proyectos tienen sus propios objetivos y presupuestos. Normalmente se combinan con otros proyectos formando parte de un programa (ver la Figura 2).

Figura 2: Cómo los programas y los proyectos afectan a la empresa

Descripción del nivel actual de la empresa

Ya sea documentada o no, toda empresa tiene una arquitectura integrada por componentes y sus relaciones y colaboraciones, a menudo capturadas en dibujos, diagramas, documentos, modelos, etc. Además de la arquitectura, la empresa tiene una serie de requisitos que debe cumplir. También hay pruebas para determinar cuan bien la empresa cumple con sus requisitos.

Nuevamente, ya sea documentado o no, toda empresa tiene sus requisitos y pruebas. Cuando se implementa una nueva edición de algún componente de la empresa, se realizará una determinada cantidad de pruebas para garantizar que el componente cumpla con sus requisitos. Esto incluye que no dañe cualquier funcionalidad de mayor nivel por la forma en que interactúa con otros componentes. Si estas pruebas detectan algún problema, éste debe rastrearse como defectos de la empresa hasta tanto se resuelva. (El problema podría ser el componente recientemente emitido o un comportamiento inesperado de algún componente interviniente.)

Por ello, observamos que estos artefactos, cuando existen y se combinan, forman una descripción completa de elementos clave de la situación actual de la empresa (ver la Figura 3):

*Requisitos (y sus impulsores, como motivación y objetivos)
*Arquitectura (incluyendo diseño e implementación)
*Pruebas
*Defectos

Figura 3: Artefactos actuales de la empresa

Los programas cambian a la empresa

Según lo definido anteriormente, el propósito de un programa es mover a la empresa del estado actual al estado futuro. Muchas veces esto incluye crear una serie de artefactos que describen el estado futuro. Sin embargo, si el estado actual está bien documentado, no es necesario volver a documentar las porciones de elementos (requisitos, arquitectura y pruebas) que no son modificadas por el programa. Sólo es necesario actualizar los artefactos actuales con los cambios establecidos por el programa. Estos cambios son deltas que se necesitan aplicar a los artefactos actuales para describir el estado futuro deseado.

En lugar de empezar desde cero, los artefactos del programa deberán describir los cambios del estado actual. Esto asume que se ha comprendido bien (capturado) el estado actual. Si esto no fuera así, no todo está perdido. Como de todas formas es necesario documentar el estado futuro, los artefactos creados pueden convertirse en artefactos actuales a nivel de la empresa después que se ha creado el programa.

Los programas pueden variar en cuanto a su alcance, desde modificar un aspecto de la empresa, a transformar todo el negocio de la misma. Por ello, es fácil exceder el alcance de un programa único para generar el conjunto completo de artefactos actuales para la empresa. En cambio, cada programa puede generar los artefactos para las porciones que modifica. Como muchos programas afectan varias áreas de la empresa, las brechas se eliminan. Este enfoque evita tener que esperar un conjunto completo de artefactos actuales antes de iniciar cualquier programa de cambio. Este enfoque puede avanzar hasta que las restantes brechas en los artefactos actuales de la empresa sean relativamente pequeñas y pueden resolverse mediante tareas separadas para cerrar directamente las brechas. Para obtener una representación completa y coherente de la empresa, todos los programas empresariales deben usar convenciones estándares para representar tanto los artefactos actuales, como los futuros (o por lo menos convertir sus artefactos de/a la convención estándar), y efectivamente deben comenzar a construir en base a los artefactos creados por los programas anteriores. De lo contrario, será muy difícil lograr la correlatividad entre los artefactos creados por diferentes programas y lograr una representación única coherente de la empresa. Además, los artefactos actuales se deben conservar como un repositorio único homogéneo. No es importante cómo se construye el repositorio, es decir si es un archivo único o una consolidación de bases de datos. Lo importante es que se conserve y se puede acceder a él como una representación consolidada coherente.

Si (o una vez que) los artefactos actuales de la empresa están disponibles, el programa deberá comenzar con estos artefactos y capturar los cambios que se necesitan implementar al programa. Esto incluye deltas de los requisitos, actualizaciones a la arquitectura y modificaciones en las pruebas acordes a los cambios de requisitos. Los deltas de los requisitos capturan los cambios deseados en el comportamiento esperado. Estos cambios deseados, aún cuando se informan inicialmente de manera informal o se perfeccionan más adelante, impulsan los deltas de la arquitectura. Tanto los deltas de requisitos, como los deltas de la arquitectura pueden impulsar cambios en el conjunto de pruebas.

Cuando se ejecuta el programa (es decir, sus proyectos son implantados), se pueden realizar las pruebas para verificar que los requisitos hayan sido cumplidos y para detectar cualquier defecto en la implantación, los requisitos, o las pruebas propiamente dichas. Normalmente cualquier defecto detectado se resolverá en el ámbito del programa. Sin embargo, algunos defectos no pueden resolverse en el ámbito del programa, y por lo tanto se convierten en defectos adicionales a nivel de la empresa.

Al finalizar el programa, la empresa está en el estado futuro definido por el programa. Como este es el nuevo estado actual para la empresa, es necesario actualizar los artefactos actuales a nivel de la empresa. Esto es sencillo porque el programa ya ha producido todos los cambios necesarios para los artefactos. La Figura 4 que muestra una ilustración del flujo de artefactos. (Obsérvese que, como es posible que varios programas se estén ejecutando simultáneamente, en este momento la empresa puede implantar cambios adicionales fuera del alcance del programa. Estos cambios adicionales se fusionarán en el estado actual de la empresa al finalizar dichos programas.)

Figura 4: Flujo de artefactos entre programa y nivel de la empresa

Los proyectos implementan el programa

Los programas definen un conjunto de cambios que crean o modifican alguna capacidad de extremo a extremo. Para lograr la capacidad nueva, normalmente es necesario crear sistemas nuevos o modificar varios sistemas existentes (quizás mediante la adquisición de una aplicación nueva o cambiando algún proceso). Es usual definir y ejecutar varios proyectos, uno por cada sistema afectado, para lograr todos los objetivos del programa.

Cada proyecto tiene un alcance específico que debe cumplir. Ese alcance está directamente relacionado con los cambios requeridos en la arquitectura para implantar la nueva capacidad. Es decir el programa define qué nueva funcionalidad se requiere de los sistemas afectados para implantar la capacidad, y cada proyecto implanta la nueva funcionalidad para su/s sistema/s. Aunque es posible que un proyecto implante cambios que soporten más de un programa, esto es mucho menos frecuente y por lo tanto no nos referiremos a ello en este documento.

Es más frecuenta que los requisitos a nivel del programa se implanten a través de varios sistemas. En estos casos, se crea un diseño a nivel del programa para mostrar cómo colaboran los sistemas. Este diseño asigna responsabilidades a cada uno de los sistemas involucrados. Las responsabilidades se ajustan a los roles que desempeñan en las colaboraciones. Este diseño satisface los deltas de los requisitos a nivel del programa. El resultado es un conjunto de requisitos que derivan de cada uno de los sistemas. No obstante, hay veces en las que un requisito a nivel del programa se implanta totalmente en un único sistema. En estos casos, el requisito a nivel del programa se asigna directamente a un único sistema. Ver la ilustración de la Figura 5 que muestra estas relaciones.

Figura 5: Flujo de requisitos del programa al proyecto

Pero, aquí nuevamente, al ejecutar el proyecto no necesitamos comenzar de cero excepto que el proyecto esté creando un sistema nuevo. Si el alcance del proyecto consiste en modificar un sistema existente, entonces el sistema tiene un estado actual. Tiene requisitos que cumplir, una arquitectura, pruebas que han sido realizadas y probablemente algunos defectos abiertos. Según lo descripto anteriormente para los artefactos actuales de la empresa, si estos artefactos no están disponibles, se pueden crear en base a una cantidad de proyectos. Como ocurre con los artefactos de la empresa, los artefactos de sistemas necesitan mantenerse en un repositorio y en un formato homogéneo para potenciarlos eficientemente.

Los artefactos de sistemas actuales, así como los artefactos de la empresa actuales, incluyen requisitos, arquitectura, pruebas y defectos existentes. Por lo tanto si un sistema tiene artefactos actuales existentes entonces en lugar de comenzar con una lista en blanco, el proyecto deberá crear sus artefactos futuros como cambios de los artefactos actuales. Así como el programa brinda actualizaciones de los artefactos de la empresa, el proyecto también ofrece actualizaciones de los artefactos de sistemas. Obsérvese la Figura 6 para consultar las relaciones existentes entre artefactos de sistemas actuales y artefactos de proyectos.

Figura 6: Flujo de artefactos entre el nivel del proyecto y el nivel del sistema

Unir todas las piezas

Lo descripto anteriormente brinda un flujo de extremo a extremo para la evolución de la empresa y de los sistemas, incluyendo sus artefactos actuales, a través de la ejecución de programas y proyectos. Hay que admitir que esta es una visión simplificada, que asume sólo un paso entre la empresa y sus sistemas. Por supuesto existe la posibilidad de que se produzcan pasos adicionales con los niveles intervinientes y sus artefactos. Sin embargo, se utiliza el mismo enfoque, el cual se puede aplicar homogéneamente a cada nivel de descomposición existente, con las decisiones apropiadas en cuanto a qué mecanismo (programa, subprograma, proyecto, subproyecto, etc.) actualizan estos niveles intervinientes. La Figura 7 muestra el flujo completo, de extremo a extremo, para esta visión simplificada.

Figura 7: Flujo de extremo a extremo de la empresa a los sistemas

Conclusión

Algunas organizaciones ya han desarrollado prácticas para administrar sus artefactos actuales para los niveles de empresa y sistemas y están cosechando los beneficios de potenciar estos artefactos. Otras recién están comenzando y avizoran beneficios futuros. Sin embargo, el objetivo y el enfoque son iguales en todos los casos. Para administrar eficientemente la evolución de la empresa, es necesario comprender sus requisitos y funcionalidad actuales y cómo logra esa funcionalidad (su arquitectura). Además es necesario comprender si su desempeño actual es el correcto en términos de pruebas y defectos existentes.

No es eficiente recrear estos artefactos en cada programa. En cambio las organizaciones desean reutilizar el conocimiento que poseen actualmente y desarrollar los artefactos como los desarrollos de la empresa. Por ello, la organización siempre tiene una visión precisa del estado actual, es capaz de planificar eficientemente la evolución de la empresa y reduce el esfuerzo total realizado, potenciando los artefactos en cada programa. Aún cuando sea poco práctico capturar un set completo de artefactos actuales para toda la empresa, las organizaciones obtienen beneficios al capturar los artefactos para una parte de la empresa, cuanto mayor sea esta parte, mayor será el beneficio.

Sin una visión precisa de la situación actual, cada programa debe: a) crear una representación del estado actual desde cero, examinando la empresa antes de avanzar con los trabajos del programa; b) intentar construir una representación del estado actual aplicando sucesivamente modificaciones implantadas por programas anteriores; o c) desistir del intento de representar el estado actual e intentar modificar una arquitectura desconocida, con la esperanza de que las modificaciones no produzcan consecuencias no deseadas. Hemos visto a las organizaciones intentar estas tres opciones, sólo para aprender dolorosamente que se necesita contar con una visión precisa del estado actual de la empresa para su correcto funcionamiento.

Es igualmente cierto que las organizaciones se benefician ampliamente con la reutilización de artefactos a nivel de los sistemas. Una empresa tiene muchos sistemas y por lo tanto los beneficios de la reutilización se multiplican por la cantidad de sistemas. La complejidad de muchos sistemas ha superado ampliamente la capacidad de cualquier individuo para mantenerlo completamente en su mente. Los artefactos que capturan los requisitos, la arquitectura, las pruebas y los defectos de un sistema constituyen una necesidad para la comunicación. Los beneficios de potenciar estos artefactos con cada proyecto nuevo incluyen: mayor homogeneidad, menos errores y menor esfuerzo general.

Hemos ilustrado cómo la arquitectura de la empresa brinda la base para su evolución mediante los programas. Los programas individuales y la organización toda se benefician al especificar el programa en términos de cambios del estado actual de la empresa. Estos cambios impulsan y restringen el trabajo realizado en los proyectos. Los proyectos desarrollan sistemas a partir de su estado actual, pero lo hacen sólo para cumplir con los requisitos asignados y derivados que provienen del programa. Para completar el ciclo, los proyectos y los programas deben aplicar sus cambios al sistema y a los artefactos de la empresa actuales, así podrán ser precisos cuando se produzcan modificaciones futuras.

fuente: http://www.ibm.com/developerworks/ssa/rational/library/edge/09/jun09/enterprisearchitecture/index.html

Acerca de arquitectura empresarial

Ingeniera de Sistemas de la Universidad Santiago de Cali, Proyecto de Investigación fomativa a cerca del Estado del Arte de las Arquitecturas Empresariales en la ciudad de Cali
Esta entrada fue publicada en Conceptos de EA, Procesos de Negocio y etiquetada . Guarda el enlace permanente.

Una respuesta a La Arquitectura Empresarial y el Ingeniero de Sistemas

  1. Jorge dijo:

    Saludos.
    Al parecer del significado de lo que Arquitectura Empresarial es en si, tomara mucho tiempo, las cosas llevan un largo camino o tal vez mas que como lo fue para John McCarthy la Inteligencia Artificial. En la EA hay tanto de mucho que todo es valioso y definir esto no es tan sencillo.
    Los invito a ver un corto articulo que encontré.
    http://www.information-management.com/news/enterprise-architecture-ERP-BI-SIM-10021528-1.html?pg=1

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s