La Arquitectura Empresarial (AE) es la práctica de estudiar, revisar, diseñar, planificar e implementar el análisis adecuado para ejecutar con éxito las estrategias de negocios. AE ayuda a las empresas a estructurar proyectos y políticas de TI para lograr los resultados empresariales deseados y mantenerse al tanto de las tendencias, y de las disrupciones de la industria utilizando principios y prácticas de arquitectura [1]
La AE se puede asimilar, metafóricamente, al Plan Regulador de una ciudad. El cual define como se irán desarrollando los barrios, calles, autopistas, parques, etc. junto con una normativa para su aplicación. De igual modo la AE es un plan para implementar las arquitecturas específicas: Negocio (Procesos), Datos, Aplicaciones (Sistemas), y Computacional (Tecnología) más sus respectivas Gobernanzas (Procedimientos que regulan la correcta aplicación de la AE).
El propósito de la AE es crear un mapa de los activos de TI, más un conjunto de principios de gobierno que impulsen una discusión continua sobre la estrategia de la empresa, y cómo se puede expresar ésta a través de TI. Hay muchos marcos sugeridos para desarrollar una AE. Sin embargo, la mayoría de los marcos contienen cuatro dominios básicos:
- Arquitectura Negocio: repositorio y documentación que describe los Procesos de Negocios de la empresa.
- Arquitectura de Datos: identifica las definiciones y dónde se guardan bloques importantes de información, como el registro de un cliente, y cómo se accede a ellos normalmente.
- Arquitectura Aplicaciones: un mapa de las relaciones de las aplicaciones de software entre sí. Contiene información “administrativa” de ellas, como ser: proveedor, cantidad de licencias, contratos asociados, versión instalada, más información que permita medir el TCO –Total Owner Cost [2].
- Arquitectura Computacional o Tecnológica: un plan para gestionar el desarrollo, estandarización, y crecimiento del hardware, sistemas de almacenamiento y redes. Más un repositorio con el detalle de cada uno de los activos computacionales y de redes que utiliza la empresa (sean de su propiedad o no).
Cualquier AE debe ser vista (diseñada, entregada y vendida internamente) como un producto entregable, algo que puede ser tocado y utilizado, no solo una conceptualización abstracta. En el contexto de TI, los usuarios y las partes interesadas deben percibir (ver) una arquitectura casi como otra aplicación de sistema de TI: debe tener entradas, salidas, funcionalidad, datos integrados, y procedimientos. Una conceptualización simple es difícil de ver en cuanto a su valor agregado. Se debe considerar la AE como un conjunto de «pautas del plan sobre cómo construir cosas, particularmente mostrando la relación de una entidad de TI con otra». El usuario / desarrollador corporativo debería percibir que la arquitectura es como cualquier otro artefacto estándar de la industria (excepto que esto se aplica internamente a una empresa en lugar de en toda la industria).
Por qué usarla
AE puede ofrecer soporte para rediseños y reorganizaciones, especialmente durante cambios organizativos, fusiones o adquisiciones importantes. También es útil para aportar más disciplina a la organización, al estandarizar y consolidar procesos para una mayor coherencia. El gráfico siguiente muestra como la AE es activada por eventos del negocio y del devenir de las tecnologías [3].
AE también se utiliza en el desarrollo de sistemas, la gestión, la toma de decisiones, y la gestión de riesgos de TI. También puede ayudar a los Procesos de Negocios de un área a ser más accesible para otras áreas.
Los mayores beneficios de contar con AE son:
- Permitir una colaboración más abierta entre TI y las unidades de negocio.
- Brindar a las empresas la capacidad de priorizar las inversiones.
- Facilitar la evaluación de la arquitectura existente frente a objetivos a largo plazo.
- Establecer procesos para evaluar y adquirir tecnología.
- Brindar una visión integral de la arquitectura de TI a todas las unidades de negocio distintas de TI.
- Proporcionar un marco de referencia para comparar resultados con otras organizaciones o estándares.
Quienes deben usarla
Básicamente, las empresas que hacen una combinación de las cinco situaciones comunes con el Área de TI se beneficiarían de AE. La lista de éstas va a continuación [4].
- Falta o escasa comunicación del negocio con TI: el equipo de TI se expresa en términos técnicos, mientras que el equipo de negocios no puede articular sus expectativas de TI. Este es un problema grave que hace que muchas empresas pierdan dinero.
- Islas de Sistemas: muchas empresas implementan proyectos de TI como sistemas independientes o «islas separadas» o “silos” que no se complementan, y ni siquiera pueden comunicarse entre sí. Por lo general, diferentes departamentos compran diferentes sistemas con diferentes aplicaciones, bases de datos, hardware e infraestructura.
- Atascado en modo de automatización: en los primeros días de la informática, alrededor de los años 80, el enfoque consistía en utilizar TI para automatizar ciertos procesos comerciales. Tal escenario estaba muy enfocado en la gestión de proyectos, lo que significa que el tiempo, los recursos y los presupuestos se fijaron en función de requisitos ampliamente definidos en las primeras etapas del ciclo de vida del desarrollo de software, sin considerar el periodo de uso posterior a los proyectos.
- TI y estrategias comerciales no alineadas. El papel del arquitecto empresarial es, fundamentalmente, establecer qué aplicaciones y tecnologías debe implementar una empresa para mantenerse competitiva. Como tal, el arquitecto debe comprender los objetivos de negocios de su empresa.
- TI visto como un centro de costos en lugar de una inversión para el ROI. El retorno de la inversión es difícil de medir cuando se trata de TI, que a menudo se considera como un costo de hacer negocios. Pero dado que la AE está diseñada para ayudar a las empresas a tomar decisiones para mejorar la productividad del negocio a través del uso eficaz y eficiente de TI, es posible verla como una inversión que genera un valor medible.
Marcos de Referencia
Según CompTIA, estas son las cuatro principales metodologías de Planificación de AE:
- El Marco Arquitectónico de Grupo Abierto (TOGAF): TOGAF proporciona principios para diseñar, planificar, implementar y gobernar la arquitectura de TI empresarial. El marco TOGAF ayuda a las empresas a crear un enfoque estandarizado para AE con un vocabulario común, estándares recomendados, métodos de cumplimiento, herramientas y software sugeridos y un método para definir las mejores prácticas. El marco TOGAF es muy popular como marco de arquitectura empresarial y, según The Open Group, ha sido adoptado por más del 80% de las empresas líderes del mundo.
- El Marco de Zachman: este marco lleva el nombre de uno de los fundadores originales de la AE, y es otra metodología popular de AE. Se entiende mejor como una «taxonomía», según CompTIA, y abarca seis puntos focales arquitectónicos y seis partes interesadas –stakeholders– principales para ayudar a estandarizar y definir los componentes y resultados de la arquitectura de TI.
- Marco Federal de Arquitectura Empresarial (FEAF): se introdujo en 1996 como respuesta a la ley Clinger-Cohen, que estableció mandatos para la efectividad de TI en las agencias federales. Está diseñado para el gobierno de EE. UU., pero también se puede aplicar a empresas privadas que quieran usar el marco.
- Gartner: Después de adquirir The Meta Group en 2005, Gartner estableció las mejores prácticas para AE y las adaptó a las prácticas generales de consultoría de la compañía. Si bien no es un marco individual, CompTIA lo reconoce como una metodología «práctica» que se centra en los resultados comerciales con «pocos pasos o componentes explícitos».
Hoja de Ruta – Roadmap
Una Hoja de Ruta de AE es un plan estratégico que comunica cómo los planes de TI de una empresa ayudarán a la organización a alcanzar sus objetivos de negocios.
La Hoja de Ruta puede ayudar a:
- Conseguir la participación de las partes interesadas: cuando los ejecutivos, gerentes, inversionistas o jefes de departamento solicitan ver el plan o la recomendación de un arquitecto empresarial para implementar un cambio de TI significativo, buscarán los beneficios generales que la organización debería esperar del plan.
- Una hoja de ruta es una herramienta versátil que le permite compartir los detalles correctos con cada audiencia: si se cuenta con una aplicación adecuada para la construcción de la Hoja de Ruta las partes interesadas que desean ver los planes de TI a un nivel más granular que el resumen visual, podrán profundizar en los detalles de cualquier tema o épica[1] en el Hoja de Ruta y ver plazos estimados, requisitos de recursos, presupuestos anticipados, interdependencias con otros elementos en la hoja de ruta, etc.
- Puede ayudar al equipo TI y de Procesos de Negocios a seguir la estrategia de la empresa y trabajar con las prioridades correctas: la planificación de TI refleja las mejores estimaciones del equipo en un momento dado. Pero durante la fase de ejecución de cualquier iniciativa de TI compleja, las cosas pueden y probablemente cambiarán. Tener un plan estratégicamente enfocado, una hoja de ruta de arquitectura empresarial, suele servir como un punto de referencia útil a lo largo de un proyecto que permite al equipo de TI asegurarse de que los ajustes que están considerando realizar sigan cumpliendo los objetivos principales del plan.
Cómo construir una Hoja de Ruta AE
El esquema siguiente se presenta a modo de ejemplo [5], nótese que esta metodología se puede ocupar para distintos tipos de iniciativas. Los pasos típicos son los que se indican en la figura siguiente:
PASO 1: Determinar su «Estado Actual» – As-Is.
Si desea desarrollar una Hoja de Ruta para una implementación AE, de TI, Procesos de Negocios (BPM), migración de tecnología u otra iniciativa importante de la empresa, primero debe tener una idea clara de cuál es la posición actual de su organización en relación con ese objetivo.
PASO 2: Definir su «Estado Deseado» – To-Be.
A continuación, desarrollar y escribir una descripción clara de cómo se verá la AE para considerar que su implementación es; es decir, cuál es el estado futuro deseado. Eso significa, por ejemplo, decidir en qué métricas enfocarse y qué mejoras se esperarán ver específicamente.
PASO 3: Hacer un Análisis de Brechas.
Ahora que se ha articulado claramente dónde está la empresa y hacia dónde quiere ir, se puede comenzar a identificar las áreas específicas que los equipos Procesos de Negocios y TI necesitarán mejorar para alcanzar el estado deseado. Es probable que estos elementos compongan los temas principales o las épicas en la hoja de ruta de la AE.
PASO 4: Priorizar los Elementos Accionables.
Revisar todas las acciones que se identificaron en el paso anterior y ordenarlas según la prioridad. Puede usarse cualquier tipo de modelos de priorización, pero a menudo se recurre al enfoque de costo versus beneficio.
PASO 5: Identificar la Mejor Secuencia.
En este punto, habrá que determinar los principales elementos accionables necesarios para completar la implementación de la arquitectura planificada, y habrán de ordenarse esos elementos clave en términos de su prioridad relativa.
PASO 6: Desarrollar y Publicar la Hoja de Ruta.
Finalmente, ahora estará esta disponible el material para convertir esos elementos bien pensados y secuenciados estratégicamente en los principales pasos de acción en una Hoja de Ruta de AE.
La figura siguiente es un ejemplo de Hoja de Ruta que he utilizado para proyectos de Procesos de Negocios. Donde los colores corresponden a cada tópico considerado, y la escala de tiempo es en Semestres (Sn). Este lo generé con PowerPoint, pero para poder hacer drill down en cada acción o elemento accionable (p. Ej.: Normas Modelamiento) se necesita ocupar una herramienta ad-hoc, que servirá para generar Hojas de Ruta para distintos tipos de proyectos: Arquitectura Empresarial, Estrategia TI, Desarrollo Producto, Plan de Marketing, etc.
Referencias
[3] http://www.ittoday.info/Articles/What_Is_Enterprise_Architecture.htm#.XfP8MZPYqqA
[4] https://www.atdsolution.com/enterprise-architecture/article/who-needs-enterprise-architecture/
[5] https://www.productplan.com/glossary/enterprise-architecture-roadmap/
[1] Épica: viene de las Metodologías Ágiles y se puede definir como una parte de un trabajo mayor que tienen un objetivo común. Considerar también como la generación de algo por versiones.