Un marco de arquitectura empresarial ( marco EA ) define cómo crear y utilizar una arquitectura empresarial . Un marco de arquitectura proporciona principios y prácticas para crear y utilizar la descripción de la arquitectura de un sistema. Estructura el pensamiento de los arquitectos dividiendo la descripción de la arquitectura en dominios, capas o vistas, y ofrece modelos (normalmente matrices y diagramas) para documentar cada vista. Esto permite tomar decisiones de diseño sistémico sobre todos los componentes del sistema y tomar decisiones a largo plazo en torno a nuevos requisitos de diseño, sostenibilidad y soporte. [2]
La arquitectura empresarial considera a la empresa como un sistema o sistema de sistemas grande y complejo . [3] Para gestionar la escala y la complejidad de este sistema, un marco arquitectónico proporciona herramientas y enfoques que ayudan a los arquitectos a abstraerse del nivel de detalle en el que trabajan los constructores, para enfocar las tareas de diseño empresarial y producir documentación valiosa de descripción de la arquitectura.
Los componentes de un marco de arquitectura proporcionan una guía estructurada que se divide en tres áreas principales: [4]
Los primeros rudimentos de la metodología de planificación por pasos actualmente defendida por The Open Group Architecture Framework (TOGAF) y otros marcos de EA se remontan al artículo de Marshall K. Evans y Lou R. Hague titulado "Master Plan for Information Systems". [7] publicado en 1962 en Harvard Business Review. [8]
Desde la década de 1970, las personas que trabajan en SI/TI han buscado maneras de involucrar a la gente de negocios –para permitir roles y procesos de negocios- e influir en la inversión en sistemas y tecnologías de información empresarial –con miras a los beneficios amplios y de largo plazo de la empresa. Muchos de los objetivos, principios, conceptos y métodos que ahora se emplean en los marcos de EA se establecieron en la década de 1980 y se pueden encontrar en los marcos de arquitectura de SI y TI publicados en esa década y la siguiente. [9]
En 1980, se promovió la Planificación de Sistemas de Negocios (BSP) de IBM como un método para analizar y diseñar la arquitectura de la información de una organización, con los siguientes objetivos:
En 1982, cuando trabajaba para IBM y BSP, John Zachman esbozó su marco para la "Arquitectura de sistemas de información" a nivel empresarial. Luego y en artículos posteriores, Zachman utilizó la palabra empresa como sinónimo de negocio. "Aunque muchas metodologías populares de planificación de sistemas de información, enfoques de diseño y diversas herramientas y técnicas no excluyen o no son inconsistentes con el análisis a nivel empresarial, pocos de ellos abordan o intentan definir arquitecturas empresariales explícitamente". [10] Sin embargo, en este artículo el término "Arquitectura Empresarial" se mencionó solo una vez sin ninguna definición específica y todos los trabajos posteriores de Zachman utilizaron el término "Arquitectura de Sistemas de Información". [11] [12]
En 1986, se desarrolló el marco de arquitectura PRISM como resultado de un proyecto de investigación patrocinado por un grupo de empresas, incluida IBM, que aparentemente fue el primer marco de EA publicado. [13]
En 1987, John Zachman, especialista en marketing de IBM, publicó el artículo A Framework for Information Systems Architecture . [11] El artículo proporciona un esquema de clasificación para artefactos que describen (en varios niveles de abstracción) el qué, cómo, dónde, quién, cuándo y por qué de los sistemas de información. Dado que IBM ya empleaba a BSP, Zachman no tenía necesidad de proporcionar un proceso de planificación. El documento no menciona la arquitectura empresarial.
En 1989, el Instituto Nacional de Estándares y Tecnología (NIST) publicó el Modelo de Arquitectura Empresarial NIST . [14] Este era un modelo de referencia de cinco capas que ilustra la interrelación de los dominios de negocios, sistemas de información y tecnología. Fue promovido dentro del gobierno federal de Estados Unidos. No era un marco de EA como lo vemos ahora, pero ayudó a establecer la noción de dividir EA en dominios o capas de arquitectura. El Modelo de Arquitectura Empresarial del NIST aparentemente fue la primera publicación que utilizó consistentemente el término "Arquitectura Empresarial". [13]
En 1990, el término "Arquitectura Empresarial" se definió formalmente por primera vez como una arquitectura que "define e interrelaciona datos, hardware, software y recursos de comunicaciones, así como la organización de soporte necesaria para mantener la estructura física general requerida por la empresa". arquitectura". [13] [15]
En 1992, un artículo de Zachman y Sowa [12] comenzaba así: "John Zachman introdujo un marco para la arquitectura de sistemas de información (ISA) que ha sido ampliamente adoptado por analistas de sistemas y diseñadores de bases de datos". El término arquitectura empresarial no apareció. El documento trataba sobre el uso del marco ISA para describir "... el sistema de información general y cómo se relaciona con la empresa y su entorno". La palabra empresa se utilizó como sinónimo de negocio.
En 1993, el libro Enterprise Architecture Planning (EAP) de Stephen Spewak definió un proceso para definir arquitecturas para el uso de información en apoyo del negocio y el plan para implementar esas arquitecturas. La misión empresarial es el principal impulsor. Luego los datos requeridos para cumplir la misión. Luego, las aplicaciones creadas para almacenar y proporcionar esos datos. Finalmente la tecnología para implementar las aplicaciones. La planificación de la arquitectura empresarial es un enfoque centrado en los datos para la planificación de la arquitectura. Un objetivo es mejorar la calidad de los datos, el acceso a los datos, la adaptabilidad a los requisitos cambiantes, la interoperabilidad y el intercambio de datos y la contención de costos. EAP tiene sus raíces en Business Systems Planning (BSP) de IBM . [13]
En 1994, Open Group seleccionó TAFIM del Departamento de Defensa de EE. UU. como base para el desarrollo de TOGAF, donde arquitectura significaba arquitectura de TI. TOGAF comenzó adoptando una visión estratégica y de toda la empresa, pero orientada a la tecnología. Surgió del deseo de racionalizar un complejo informático desordenado. Hasta la versión 7, TOGAF todavía se centraba en definir y utilizar un modelo de referencia técnica (o arquitectura básica) para definir los servicios de plataforma requeridos por las tecnologías que utiliza toda una empresa para respaldar las aplicaciones comerciales. [9]
En 1996, la Ley de Reforma de la Gestión de TI de EE. UU. , más comúnmente conocida como Ley Clinger-Cohen , ordenó repetidamente que la inversión de una agencia del gobierno federal de EE. UU. en TI debe asignarse a beneficios comerciales identificables. Además, responsabilizó al CIO de la agencia de "... desarrollar, mantener y facilitar la implementación de una arquitectura de TI sólida e integrada para la agencia ejecutiva".
En 1997, Zachman había cambiado el nombre y reorientado su marco ISA como marco EA; siguió siendo un esquema de clasificación de artefactos descriptivos, no un proceso para planificar sistemas o cambios en los sistemas.
En 1998, el Consejo Federal de CIO comenzó a desarrollar el Marco Federal de Arquitectura Empresarial (FEAF) de acuerdo con las prioridades enunciadas en Clinger-Cohen y lo publicó en 1999. FEAF fue un proceso muy parecido al ADM de TOGAF, en el que “el equipo de arquitectura genera un plan de secuenciación para la transición de sistemas, aplicaciones y prácticas comerciales asociadas basado en un análisis detallado de brechas [entre las arquitecturas de referencia y de destino]”.
En 2001, el consejo de Jefes de CIO de EE. UU. publicó una guía práctica para la arquitectura empresarial federal , que comienza así: “Una arquitectura empresarial (EA) establece la hoja de ruta de toda la Agencia para lograr la misión de una Agencia a través del desempeño óptimo de sus procesos comerciales centrales dentro de una plataforma de información eficiente. En ese momento, los procesos en TOGAF, FEAF, EAP y BSP estaban claramente relacionados.
En 2002/3, en su Enterprise Edition , TOGAF 8 cambió el enfoque de la capa de arquitectura tecnológica a las capas superiores de negocios, datos y aplicaciones. Introdujo el análisis estructurado, después de la ingeniería de tecnología de la información , que presenta, por ejemplo, asignaciones de unidades organizativas a funciones comerciales y entidades de datos a funciones comerciales. Hoy en día, las funciones empresariales suelen denominarse capacidades empresariales. Y muchos arquitectos empresariales consideran su función/jerarquía/mapa de capacidades empresariales como el artefacto fundamental de la arquitectura empresarial. Relacionan entidades de datos, casos de uso, aplicaciones y tecnologías con las funciones/capacidades.
En 2006, el popular libro Enterprise Architecture As Strategy [16] informó sobre los resultados del trabajo del Centro de Investigación de Sistemas de Información del MIT. Este libro enfatiza la necesidad de que los arquitectos empresariales se centren en los procesos comerciales centrales ("Las empresas sobresalen porque han [decidido] qué procesos deben ejecutar bien y han implementado los sistemas de TI para digitalizar esos procesos") y de involucrar a los gerentes comerciales. con los beneficios que podría proporcionar la integración y/o estandarización de procesos estratégicos entre organizaciones.
Un proyecto de investigación de 2008 para el desarrollo de certificados profesionales en arquitectura empresarial y de soluciones realizado por la British Computer Society (BCS) demostró que la arquitectura empresarial siempre ha sido inseparable de la arquitectura de sistemas de información, lo cual es natural, ya que los empresarios necesitan información para tomar decisiones y llevar a cabo llevar a cabo procesos de negocio. [9]
En 2011, el TOGAF 9.1. La especificación dice: "La planificación empresarial a nivel estratégico proporciona la dirección inicial a la arquitectura empresarial". [17] Normalmente, los principios comerciales, los objetivos comerciales y los impulsores estratégicos de la organización se definen en otra parte. [9] En otras palabras, la Arquitectura Empresarial no es una estrategia, planificación o metodología de gestión empresarial. Enterprise Architecture se esfuerza por alinear la tecnología de los sistemas de información empresarial con la estrategia, los objetivos y los impulsores del negocio determinados. La especificación TOGAF 9.1 aclaró que "una descripción completa de la arquitectura empresarial debe contener los cuatro dominios de la arquitectura (negocios, datos, aplicaciones, tecnología), pero las realidades de las limitaciones de recursos y tiempo a menudo significan que no hay suficiente tiempo, financiación o recursos". construir una descripción de arquitectura de arriba hacia abajo que incluya todos los cuatro dominios de arquitectura, incluso si el alcance de la empresa es [...] menor que la extensión total de la empresa en general". [18]
En 2013, TOGAF [19] es el marco de arquitectura más popular (a juzgar por los números de certificación publicados) y algunos suponen que define a EA. [9] Sin embargo, algunos todavía utilizan el término Arquitectura Empresarial como sinónimo de Arquitectura Empresarial, en lugar de cubrir los cuatro dominios de la arquitectura: negocios, datos, aplicaciones y tecnología.
Desde la Planificación de la Arquitectura Empresarial (EAP) de Stephen Spewak en 1993, y quizás antes, ha sido normal dividir la arquitectura empresarial en cuatro dominios arquitectónicos .
Tenga en cuenta que la arquitectura de aplicaciones tiene que ver con la elección y las relaciones entre aplicaciones en el portafolio de aplicaciones de la empresa, no con la arquitectura interna de una sola aplicación (que a menudo se denomina arquitectura de aplicaciones).
Muchos marcos de EA combinan dominios de datos y aplicaciones en una única capa de sistema de información (digitalizada), ubicada debajo del negocio (generalmente un sistema de actividad humana) y por encima de la tecnología (la infraestructura de TI de la plataforma ).
Durante muchos años, ha sido común considerar los dominios de la arquitectura como capas, con la idea de que cada capa contiene componentes que ejecutan procesos y ofrecen servicios a la capa superior. Esta forma de ver los dominios de la arquitectura fue evidente en TOGAF v1 (1996), que encapsuló la capa de componentes tecnológicos detrás de los servicios de plataforma definidos en el "Modelo de referencia técnica", muy de acuerdo con la filosofía de TAFIM y POSIX.
La visión de los dominios de la arquitectura como capas se puede presentar así:
Cada capa delega el trabajo a la capa inferior. En cada capa, los componentes, los procesos y los servicios pueden definirse en un nivel de grano grueso y descomponerse en componentes, procesos y servicios de grano más fino. El gráfico muestra una variación de este tema.
Además de los tres componentes principales del marco discutidos anteriormente.
Un marco de EA ideal debería incluir:
La mayoría de los marcos de EA modernos (por ejemplo, TOGAF, ASSIMPLER, EAF) incluyen la mayor parte de los anteriores. Zachman siempre se ha centrado en el asesoramiento sobre descripción de arquitectura.
Los dominios de aplicaciones y tecnología (que no deben confundirse con los dominios comerciales) se caracterizan por las capacidades y servicios del dominio. Las capacidades están respaldadas por los servicios. Los servicios de aplicaciones también se denominan arquitectura orientada a servicios (SOA). Los servicios técnicos suelen estar respaldados por productos de software.
La vista de datos comienza con las clases de datos que se pueden descomponer en sujetos de datos que se pueden descomponer aún más en entidades de datos. El tipo de modelo de datos básico que se utiliza con mayor frecuencia se llama merda (evaluación de diagramas maestros de relación entre entidades, consulte modelo entidad-relación ). La clase, el sujeto y la entidad forman una vista jerárquica de los datos. Las empresas pueden tener millones de instancias de entidades de datos.
El modelo tradicional de referencia de arquitectura empresarial ofrece una distinción clara entre los dominios de la arquitectura (negocio, información/datos, aplicación/integración y técnico/infraestructura). Estos dominios se pueden dividir en disciplinas de subdominio. En la imagen de la derecha se muestra un ejemplo del dominio y los subdominios de EA.
Muchos equipos de arquitectura empresarial están formados por personas con habilidades alineadas con los dominios de arquitectura empresarial y las disciplinas de subdominio. A continuación se muestran algunos ejemplos: arquitecto empresarial, arquitecto documental empresarial, arquitecto de aplicaciones empresariales, arquitecto de infraestructura empresarial, arquitecto de información empresarial, etc.
Un ejemplo de la lista de patrones de arquitectura de referencia en los dominios de arquitectura de información y aplicaciones está disponible en Patrón arquitectónico (informática) .
Un modelo de vista es un marco que define el conjunto de vistas o enfoques utilizados en el análisis de sistemas , el diseño de sistemas o la construcción de una arquitectura empresarial .
Desde principios de la década de 1990, ha habido una serie de esfuerzos para definir enfoques estándar para describir y analizar arquitecturas de sistemas. Muchos de los marcos de arquitectura empresarial recientes tienen algún tipo de conjunto de vistas definido, pero estos conjuntos no siempre se denominan modelos de vista .
Quizás el estándar más conocido en el campo de la arquitectura de software y la arquitectura de sistemas comenzó como IEEE 1471 , un estándar IEEE para describir la arquitectura de un sistema con uso intensivo de software aprobado en 2000.
En su última versión, el estándar está publicado como ISO/IEC/IEEE 42010:2011 . El estándar define un marco de arquitectura como convenciones, principios y prácticas para la descripción de arquitecturas establecidas dentro de un dominio específico de aplicación y/o comunidad de partes interesadas , y propone un marco de arquitectura que se especifica mediante:
Los marcos de arquitectura que cumplen con el estándar pueden incluir métodos, herramientas, definiciones y prácticas adicionales más allá de las especificadas.
Hoy en día existen innumerables frameworks de EA, muchos más que los que se muestran en la siguiente lista.
Marcos de arquitectura empresarial que se lanzan como código abierto :