Marco de arquitectura empresarial

Un marco de arquitectura empresarial (marco de arquitectura empresarial) 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émicas sobre todos los componentes del sistema y tomar decisiones a largo plazo sobre nuevos requisitos de diseño, sostenibilidad y soporte.

La arquitectura empresarial considera a la empresa como un sistema grande y complejo o un sistema de sistemas. 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:

• Descripción de la arquitectura: cómo documentar la empresa como un sistema, desde varios puntos de vista. Cada vista describe una rebanada de la arquitectura; incluye aquellas entidades y relaciones que abordan preocupaciones particulares de interés para determinados interesados; puede tomar la forma de una lista, una tabla, un diagrama, o un nivel superior de composición de tales.
• Métodos para diseñar arquitectura: procesos que siguen los arquitectos. Por lo general, un proceso de arquitectura empresarial global, compuesto de fases, se dividió en procesos de menor nivel compuestos por actividades más finas. Un proceso se define por sus objetivos, insumos, fases (pasos o actividades) y productos. Puede apoyarse en enfoques, técnicas, herramientas, principios, reglas y prácticas.
• Organización de arquitectos: orientación sobre la estructura del equipo y la gobernanza del equipo, incluidas las habilidades, la experiencia y la capacitación necesarias.

Los primeros rudimentos de la metodología de planificación por etapas que actualmente defienden The Open Group Architecture Framework (TOGAF) y otros marcos de arquitectura empresarial se remontan al artículo de Marshall K. Evans y Lou R. Hague titulado "Master Plan for Information Systems" (Plan maestro para sistemas de información), publicado en 1962 en Harvard Business Review.

Desde los años 70, quienes trabajan en el ámbito de los sistemas de información y las tecnologías de la información han buscado formas de involucrar a los empresarios (para habilitar funciones y procesos empresariales) e influir en la inversión en sistemas y tecnologías de información empresarial, con vistas a obtener beneficios amplios y a largo plazo para la empresa. Muchos de los objetivos, principios, conceptos y métodos que se emplean actualmente en los marcos de arquitectura de la información se establecieron en los años 80 y se pueden encontrar en los marcos de arquitectura de los sistemas de información y las tecnologías de la información publicados en esa década y en la siguiente.

En 1980, IBM promovió el Business Systems Planning (BSP) como método para analizar y diseñar la arquitectura de información de una organización, con los siguientes objetivos:

1. entender las cuestiones y oportunidades con las aplicaciones actuales y la arquitectura técnica;
2. desarrollar un futuro estado y camino de migración para la tecnología que apoye la empresa;
3. proporcionar a los ejecutivos de las empresas un marco de dirección y adopción de decisiones para los gastos de capital de TI;
4. proporcionar al sistema de información (IS) un plan de desarrollo.

En 1982, cuando trabajaba para IBM y con BSP, John Zachman describió su marco para la "Arquitectura de Sistemas de Información" a nivel empresarial. En ese momento y en artículos posteriores, Zachman utilizó la palabra "empresa" como sinónimo de negocio. "Aunque muchas metodologías de planificación de sistemas de información, enfoques de diseño y diversas herramientas y técnicas populares no excluyen ni son incompatibles con el análisis a nivel empresarial, pocos de ellos abordan o intentan definir explícitamente las arquitecturas empresariales". 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".

En 1986, se desarrolló el marco de arquitectura PRISM como resultado del proyecto de investigación patrocinado por un grupo de empresas, entre ellas IBM, que aparentemente fue el primer marco de arquitectura empresarial publicado.

En 1987, John Zachman, que era especialista en marketing de IBM, publicó el artículo A Framework for Information Systems Architecture. El artículo proporcionaba un esquema de clasificación de 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 BSP, Zachman no tenía necesidad de proporcionar un proceso de planificación. El artículo no mencionaba la arquitectura empresarial.

En 1989, el Instituto Nacional de Estándares y Tecnología (NIST) publicó el Modelo de Arquitectura Empresarial del NIST. Se trataba de un modelo de referencia de cinco capas que ilustraba la interrelación de los dominios de los negocios, los sistemas de información y la tecnología. Fue promovido dentro del gobierno federal de los Estados Unidos. No era un marco de arquitectura empresarial como lo vemos ahora, pero ayudó a establecer la noción de dividir la arquitectura empresarial en dominios o capas de arquitectura. El Modelo de Arquitectura Empresarial del NIST aparentemente fue la primera publicación que utilizó de manera consistente el término "Arquitectura Empresarial".

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 arquitectura".

En 1992, un artículo de Zachman y Sowa comenzaba así: "John Zachman presentó 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 artículo 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 circundante". La palabra empresa se utilizó como sinónimo de negocio.

En 1993, el libro de Stephen Spewak, Enterprise Architecture Planning (EAP), 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 impulsor principal. Luego, los datos necesarios para satisfacer la misión. Luego, las aplicaciones creadas para almacenar y proporcionar esos datos. Por último, la tecnología para implementar las aplicaciones. Enterprise Architecture Planning es un enfoque centrado en los datos para la planificación de la arquitectura. Uno de los objetivos es mejorar la calidad de los datos, el acceso a los datos, la adaptabilidad a los requisitos cambiantes, la interoperabilidad y el uso compartido de los datos y la contención de los costos. EAP tiene sus raíces en Business Systems Planning (BSP) de IBM.

En 1994, el Open Group seleccionó TAFIM del Departamento de Defensa de los Estados Unidos como base para el desarrollo de TOGAF, donde arquitectura significa 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 parque de TI desordenado. Hasta la versión 7, TOGAF todavía se centraba en definir y utilizar un modelo de referencia técnica (o arquitectura de base) para definir los servicios de plataforma requeridos de las tecnologías que utiliza una empresa entera para dar soporte a las aplicaciones comerciales.

En 1996, la Ley de Reforma de la Gestión de TI de los Estados Unidos, más conocida como la Ley Clinger-Cohen, ordenó en repetidas ocasiones que la inversión en TI de una agencia del gobierno federal de los Estados Unidos se relacionara con beneficios empresariales identificables. Además, hizo que el CIO de la agencia fuera responsable 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 renombrado y reorientado su marco ISA como un marco EA; seguía siendo un esquema de clasificación para 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, por sus siglas en inglés) de acuerdo con las prioridades enunciadas en Clinger-Cohen y lo publicó en 1999. El FEAF era 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 las brechas [entre las arquitecturas de referencia y las de destino]”.

En 2001, el Consejo de CIO de los EE. UU. publicó Una guía práctica para la arquitectura empresarial federal, que comienza diciendo: “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 de negocios centrales dentro de un entorno de tecnología de la información (TI) eficiente”. En ese momento, los procesos en TOGAF, FEAF, EAP y BSP estaban claramente relacionados.

En 2002/3, en su Edición Empresarial, TOGAF 8 cambió el enfoque de la capa de arquitectura tecnológica a las capas superiores de negocio, datos y aplicaciones. Introdujo el análisis estructurado, después de la ingeniería de tecnología de la información, que incluye, por ejemplo, asignaciones de unidades de organización a funciones de negocio y de entidades de datos a funciones de negocio. Hoy en día, las funciones de negocio se denominan a menudo capacidades de negocio. Y muchos arquitectos empresariales consideran su jerarquía/mapa de funciones/capacidades de negocio como el artefacto fundamental de la arquitectura empresarial. Relacionan las entidades de datos, los casos de uso, las aplicaciones y las tecnologías con las funciones/capacidades.

En 2006, el popular libro Enterprise Architecture As Strategy (Arquitectura empresarial como estrategia) publicó 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 empresariales 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 que los gerentes empresariales se comprometan con los beneficios que la integración y/o estandarización estratégica de procesos interorganizacionales podría proporcionar.

Un proyecto de investigación de 2008 para el desarrollo de certificados profesionales en arquitectura empresarial y de soluciones por parte de 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 procesos comerciales.

En 2011, la especificación TOGAF 9.1. dice: "La planificación empresarial a nivel de estrategia proporciona la dirección inicial para la arquitectura empresarial". Normalmente, los principios empresariales, los objetivos empresariales y los impulsores estratégicos de la organización se definen en otra parte. En otras palabras, la arquitectura empresarial no es una estrategia empresarial, una metodología de planificación o gestión. La arquitectura empresarial se esfuerza por alinear la tecnología de los sistemas de información empresarial con la estrategia, los objetivos y los impulsores empresariales 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 (empresa, datos, aplicación, tecnología), pero las realidades de las limitaciones de recursos y tiempo a menudo significan que no hay suficiente tiempo, financiación o recursos para construir una descripción de la arquitectura de arriba hacia abajo e integral que abarque los cuatro dominios de la arquitectura, incluso si el alcance empresarial es [...] menor que la extensión total de la empresa en general".

En 2013, TOGAF es el marco de arquitectura más popular (a juzgar por los números de certificación publicados) y algunos suponen que define la arquitectura empresarial. Sin embargo, algunos todavía usan 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.

• Arquitectura de negocios,
• Arquitectura de datos,
• Arquitectura de aplicaciones,
• Arquitectura tecnológica.

Tenga en cuenta que la arquitectura de aplicaciones tiene que ver con la elección de aplicaciones y las relaciones entre ellas en el portafolio de aplicaciones de la empresa, no con la arquitectura interna de una única aplicación (que a menudo se denomina arquitectura de aplicaciones).

Muchos marcos de EA combinan datos y dominios de aplicación en una única capa de sistema de información (digitalizada), ubicada debajo del negocio (normalmente un sistema de actividad humana) y 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 de tecnología 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 de la siguiente manera:

• Medio ambiente (las entidades externas y las actividades supervisaban, apoyaban o dirigían la empresa).
• Capa de Negocios (funciones empresariales que ofrecen servicios entre sí y a entidades externas).
• Capa de datos (Información comercial y otros datos almacenados valiosos)
• Capa del Sistema de Información (aplicaciones empresariales que ofrecen servicios de información entre sí y funciones empresariales)
• Technology Layer (generic hardware, red y aplicaciones de plataforma que ofrecen servicios de plataforma entre sí y aplicaciones empresariales).

Cada capa delega trabajo a la capa inferior. En cada capa, los componentes, los procesos y los servicios se pueden definir a un nivel de granularidad gruesa y descomponerse en componentes, procesos y servicios de granularidad más fina. El gráfico muestra una variación de este tema.

Además de los tres componentes principales del marco analizados anteriormente.

1. Descripción consejos: algún tipo de Arquitectura Artifacts Mapa o Mirador Biblioteca
2. Consejos del proceso: algún tipo de método de desarrollo de la arquitectura, con orientación de apoyo.
3. Consejo de organización: incluido un modelo de gobernanza de EA

Un marco de EA ideal debería incluir:

1. métricas de medición del valor empresarial
2. Modelo de iniciativa EA
3. Modelo de madurez EA
4. Modelo de comunicación empresarial

La mayoría de los frameworks de arquitectura empresarial modernos (por ejemplo, TOGAF, ASSIMPLER, EAF) incluyen la mayoría de los elementos anteriores. Zachman siempre se ha centrado en brindar asesoramiento sobre descripción de la arquitectura.

Los dominios de aplicación y tecnología (que no deben confundirse con los dominios empresariales) se caracterizan por las capacidades y los servicios del dominio. Las capacidades están respaldadas por los servicios. Los servicios de aplicación también se conocen en la 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 a su vez se pueden descomponer en entidades de datos. El tipo de modelo de datos básico que se utiliza con más frecuencia se denomina merda (evaluación de diagramas de relación de entidad maestra, consulte el modelo de relación de entidad). 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 pueden dividirse a su vez en subdisciplinas. En la imagen de la derecha se muestra un ejemplo del dominio y los subdominios de la arquitectura empresarial.

Muchos equipos de arquitectura empresarial están formados por personas con habilidades relacionadas con los dominios de la arquitectura empresarial y las disciplinas de los subdominios. A continuación, se ofrecen algunos ejemplos: arquitecto empresarial, arquitecto documental, arquitecto de aplicaciones, arquitecto de infraestructura, arquitecto de información, etc.

En el apartado Patrones arquitectónicos (informática) se puede encontrar un ejemplo de la lista de patrones de arquitectura de referencia en los dominios de la arquitectura de aplicaciones y de la información.

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 los años 90, se han hecho varios 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 definidas, pero estos conjuntos no siempre se denominan modelos de vista.

El estándar más conocido en el campo de la arquitectura de software y de sistemas nació 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, la norma se publicó como ISO/IEC/IEEE 42010:2011. La norma 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 que un marco de arquitectura se especifique mediante:

1. los interesados pertinentes en el ámbito,
2. los tipos de preocupaciones que surgen en ese ámbito,
3. arquitectura puntos de vista que enmarcan esas preocupaciones y
4. Normas de correspondencia que integran los puntos de vista citados antes.

Los marcos de arquitectura que se ajustan al estándar pueden incluir métodos, herramientas, definiciones y prácticas adicionales a las especificadas.

En la actualidad existen innumerables frameworks de EA, muchos más que los que se enumeran a continuación.

• ARCON – Una arquitectura de referencia para redes colaborativas – no centrada en una sola empresa sino en redes de empresas
• La arquitectura de referencia TCI de Cloud Security Alliance (Trusted Cloud Initiative).
• Arquitectura y Metodología de Referencia Empresarial Generalizada (GERAM)
• RM-ODP – el Modelo de Referencia de Procesamiento Distribuido Abierto (ITU-T Rec. X.901-X.904 TEN ISO/IEC 10746) define un marco de arquitectura empresarial para estructurar las especificaciones de los sistemas distribuidos abiertos.
• IDEAS Group – un esfuerzo de cuatro naciones para desarrollar una ontología común para la interoperabilidad de la arquitectura
• ISO 19439 Marco para la elaboración de modelos institucionales
• TOGAF – The Open Group Architecture Framework – un marco ampliamente utilizado que incluye un método de desarrollo arquitectónico y estándares para describir diversos tipos de arquitectura.

• AGATE – el Marco de Arquitectura Francia DGA
• DNDAF – el Marco de Arquitectura DND/CF (CAN)
• DoDAF – el Marco de Arquitectura del Departamento de Defensa de EE.UU.
• MODAF – el Marco de Arquitectura del Ministerio de Defensa del Reino Unido
• NAF – el Marco de Arquitectura de la OTAN

• European Space Agency Architectural Framework (ESAAF) - a framework for European space-based Systems of Systems
• IEDC Marco de Arquitectura Empresarial
• Marco Federal de Arquitectura Empresarial (FEAF) – un marco elaborado en 1999 por el Consejo Federal de CIO de los Estados Unidos para su uso dentro del Gobierno de los Estados Unidos (para no confundirse con la orientación de Arquitectura Empresarial Federal (FEA) de 2002 sobre clasificación y agrupación de inversiones en TI, emitida por la Oficina Federal de Gestión y Presupuesto de los Estados Unidos)
• Government Enterprise Architecture (GEA) – un marco común legislado para su uso por departamentos del Gobierno de Queensland
• Nederlandse Overheid Referentie Architectuur (NORA) – un marco de referencia del Gobierno holandés E-overheid NORA
• NIST Enterprise Architecture Modelo
• Treasury Enterprise Architecture Framework (TEAF) – un marco de tesorería, publicado por el Departamento del Tesoro de Estados Unidos en julio de 2000.
• Marco de Arquitectura Empresarial Colombiana - MRAE - Marco de Referencia de Arquitectura Empresarial Archivado 2021-05-10 en el Wayback Machine un marco para todas las Agencias Públicas Colombianas
• India Enterprise Architecture (IndEA) framework - IndEA es un marco de referencia del Gobierno de la India.

Marcos de arquitectura empresarial que se publican como código abierto:

• ArchiMate
• Lean Architecture Framework (LAF) es una colección de buenas prácticas gracias a las cuales el entorno IT responderá de forma sistemática y rápida a una situación de negocio cambiante manteniendo su forma consistente.
• MEGAF (Mega-modeling Architecture Framework) es una infraestructura para la realización de marcos de arquitectura que se ajustan a la definición de marco de arquitectura proporcionada en ISO/IEC/IEEE 42010.
• Praxeme, una metodología de empresa abierta, contiene un marco de arquitectura empresarial llamado la Topología del Sistema Empresarial (EST)
• TRAK – un marco general orientado a sistemas basado en MODAF 1.2 y publicado bajo GPL/GFDL.
• Sherwood Applied Business Security Architecture (SABSA) es un marco abierto y una metodología para Enterprise Security Architecture y Service Management, que se basa en el riesgo y se centra en integrar la seguridad en la gestión empresarial y de TI.

• ASSIMPLER Marco: un marco de arquitectura, basado en el trabajo de Mandar Vanarse en Wipro en 2002
• Avancier Methods (AM) Processes and documentation advice for enterprise and solution architects, supported by training and certification.
• Marco BRM (Build-Run-Manage) - un marco de arquitectura creado por Sanjeev "Sunny" Mishra durante sus primeros días en IBM en 2000.
• Capgemini Integrated Architecture Framework (IAF) – de la empresa Capgemini en 1993
• Dragon1 - Una arquitectura abierta de la empresa visual Método recientemente reconocido por The Open Group como Marco de Arquitectura
• DYA framework developed by Sogeti since 2004.
• Dynamic Enterprise Concepto de arquitectura empresarial basado en la tecnología Web 2.0
• Extended Enterprise Architecture Framework - from Institute For Enterprise Architecture Developments in 2003
• Marco EACOE [3] – un marco de Arquitectura Empresarial, como elaboración de la obra de John Zachman
• IBM Information FrameWork (IFW) – concebido por Roger Evernden en 1996
• Infomet - concebido por Pieter Viljoen en 1990
• Labnaf - Unified Framework for Driving Enterprise Transformations
• Pragmatic Enterprise Architecture Framework (PEAF) - parte de la Familia Pragmática de Marcos desarrollada por Kevin Lee Smith, Pragmatic EA, a partir de 2008
• Purdue Enterprise Arquitectura de referencia desarrollada por Theodore J. Williams en la Universidad Purdue principios de los años 1990.
• Risk- and Cost-Driven Architecture (RCDA), desarrollado por CGI desde 2015.
• SAP Enterprise Architecture Framework
• Marco de modelado orientado al servicio (SOMF), basado en el trabajo de Michael Bell
• Solution Architecting Mechanism (SAM) – Un marco de arquitectura coherente que consiste en un conjunto de módulos integrales.
• Marco Zachman – un marco de arquitectura, basado en el trabajo de John Zachman en IBM en el decenio de 1980

• Patrones de arquitectura (Equipo de referencia)
• EABOK (The Guide to the Enterprise Architecture Body of Knowledge)
• Arquitectura empresarial
• Artefactos de arquitectura empresarial
• Planificación de la arquitectura empresarial
• Ingeniería empresarial
• ISO/IEC/IEEE 42010
• Arquitectura de referencia

• Enterprise Architecture Marco: El destino del siglo (julio 2016)
• Comparación de los cuatro principales marcos de arquitectura empresarial (julio 2021)