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émicas 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 grande y complejo o un sistema de sistemas . [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 etapas que actualmente defienden 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, 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 roles 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 de largo plazo para la empresa. Muchos de los objetivos, principios, conceptos y métodos que se emplean actualmente en los marcos de arquitectura empresarial se establecieron en la década de 1980 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. [9]
En 1980, se promovió el Business Systems Planning (BSP) de IBM como un método para analizar y diseñar la arquitectura de información de una organización, con los siguientes objetivos:
En 1982, cuando trabajaba para IBM y con BSP, John Zachman esbozó su marco de trabajo 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 o no son incompatibles con el análisis a nivel empresarial, pocos de ellos abordan o intentan definir explícitamente las arquitecturas empresariales". [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 del proyecto de investigación patrocinado por un grupo de empresas, incluida IBM, que aparentemente fue el primer marco de arquitectura empresarial publicado. [13]
En 1987, John Zachman, especialista en marketing de IBM, publicó el artículo A Framework for Information Systems Architecture (Un marco para la arquitectura de sistemas de información ). [11] 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 . [14] Se trataba de un modelo de referencia de cinco capas que ilustraba la interrelación de los dominios empresariales, de sistemas de información y de tecnología. Fue promovido dentro del gobierno federal de los EE. UU. 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". [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 arquitectura". [13] [15]
En 1992, un artículo de Zachman y Sowa [12] 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 usaba 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. [13]
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 respaldar las aplicaciones comerciales. [9]
En 1996, la Ley de Reforma de la Gestión de TI de Estados Unidos , más conocida como la Ley Clinger-Cohen , ordenó reiteradamente que la inversión en TI de una agencia del gobierno federal de Estados Unidos debe estar relacionada 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 de Arquitectura Empresarial Federal (FEAF) de acuerdo con las prioridades enunciadas en Clinger-Cohen y lo publicó en 1999. 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 de destino]”.
En 2001, el Consejo de CIO jefe de Estados Unidos 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 Enterprise Edition , 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 que su jerarquía/mapa de funciones/capacidades de negocio es 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 [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 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 podría proporcionar la integración y/o estandarización estratégica de procesos interorganizacionales.
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) mostró que la arquitectura empresarial siempre ha sido inseparable de la arquitectura de sistemas de información, lo cual es natural, ya que la gente de negocios necesita información para tomar decisiones y llevar a cabo procesos comerciales. [9]
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". [17] Normalmente, los principios empresariales, los objetivos empresariales 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 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". [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 la arquitectura empresarial. [9] 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 de arquitectura .
Tenga en cuenta que la arquitectura de las aplicaciones tiene que ver con la elección y las relaciones entre las aplicaciones en la cartera 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 datos y dominios de aplicación en una única capa de sistema de información (digitalizada), ubicada debajo del negocio (generalmente 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 quedó en evidencia 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 acorde 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:
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 descomponerlos 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.
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ía de los elementos anteriores. Zachman siempre se ha centrado en brindar asesoramiento sobre descripción de 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 (empresa, información/datos, aplicación/integración y técnico/infraestructura). Estos dominios se pueden dividir en subdisciplinas de dominio. 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.
Un ejemplo de la lista de patrones de arquitectura de referencia en los dominios de arquitectura de aplicaciones y de información está disponible en Patrón arquitectónico (ciencias de la computació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 .
Quizás el estándar más conocido en el campo de la arquitectura de software y arquitectura de sistemas comenzó como IEEE 1471 , un estándar IEEE para describir la arquitectura de un sistema intensivo en software aprobado en 2000.
En su última versión, la norma se publica 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:
Los marcos de arquitectura que se ajustan al estándar pueden incluir métodos, herramientas, definiciones y prácticas adicionales a las especificadas.
Hoy en día existen innumerables frameworks EA, muchos más que los que aparecen en la siguiente lista.
Marcos de arquitectura empresarial que se publican como código abierto :