En este artículo, se proporcionan pautas sobre cómo diseñar la arquitectura empresarial, en este caso con blockchain y otras tecnologías.
La arquitectura empresarial es un marco o modelo que describe la estructura y función de una empresa. Nos ayuda a analizar, diseñar, planificar, implementar y mantener componentes de arquitectura. Lo que definimos es una arquitectura lógica, no una arquitectura física. Esa es la arquitectura que describe lo que hacen los componentes, no cómo se implementan en la práctica.
Las arquitecturas pueden incluir diferentes tipos de componentes, como procesos de negocios, unidades de organización, personas, dispositivos, sistemas e infraestructura de TI. Normalmente, se centran en los sistemas y la infraestructura de soporte, asignados a un fondo que muestra las unidades de negocios o las capas lógicas.
Como ejemplo, a continuación se muestra la Arquitectura Empresarial de la Fundación OEL. La Fundación OEL es una organización sin fines de lucro que proporciona gobierno y recursos para el desarrollo del ecosistema de la cadena de bloques de Open Enterprise Logistics. La arquitectura muestra los componentes utilizados en la entrega de productos y servicios de logística a, o por, participantes del ecosistema.
¿Cómo vamos a diseñar una arquitectura empresarial que incluya la tecnología blockchain?
No hay una diferencia fundamental con el diseño de una arquitectura: una cadena de bloques es solo otro componente técnico. Sin embargo, hay algunos aspectos de la tecnología blockchain, como los contratos inteligentes, que deberían aparecer en la arquitectura como componentes.
Entonces, ¿cómo hacemos para diseñar la arquitectura empresarial en general?
No hay respuestas "correctas" o "incorrectas", aunque algunos enfoques son más útiles que otros. Recuerde que la arquitectura empresarial también es un ser vivo que cambiará y evolucionará con el tiempo.
Hay algunas pautas generales que son útiles en el diseño de arquitectura:
1. Mantenlo simple
2. Consulte los ejemplos de la industria y las mejores prácticas.
3. Comprender los desarrollos relevantes de la industria.
4. Definir un límite de arquitectura.
5. Decidir los principios de organización a utilizar
6. Rellenar la arquitectura con componentes relevantes.
7. Referencia cruzada de su arquitectura final con ejemplos de la industria
8. Revisar y basar la arquitectura.
En general, si algo no es simple, generalmente se debe a que la complejidad refleja uno o más factores como: análisis y diseño incompletos, trabajar con un nivel de detalle demasiado bajo o tratar de incluir demasiadas cosas en el modelo.
Tratar de utilizar completamente un estándar de arquitectura integral como el Marco de Arquitectura de Grupo Abierto (TOGAF) también puede ser inapropiado, excepto para organizaciones muy grandes.
La arquitectura empresarial puede diseñarse utilizando diferentes grados de complejidad. Algunas arquitecturas empresariales son muy complicadas y difíciles de entender, incluso por las personas que deben utilizarlas. Es mejor mantener la arquitectura tan simple como sea posible, sin perder información clave. Esto ayuda a las personas a comprender y utilizar la arquitectura y sus componentes.
Un diagrama de bloques es una buena base para una arquitectura simple. Esto nos permite ver los componentes principales y su amplia relación entre sí, sin describir en detalle su función o conexiones.
Hay muchos ejemplos de arquitecturas, con complejidad variable, diferentes enfoques y principios de organización, y con una gran cantidad de diferentes tipos de componentes.
A menudo no hay un marco o modelo de arquitectura estándar que pueda usarse como referencia. A falta de esto, debemos buscar ejemplos de arquitectura de los principales participantes de la industria o de académicos. Estos nos pueden mostrar cómo otros se han acercado al análisis y diseño de la arquitectura, y pueden servir de base para nuestra propia arquitectura.
A veces es fácil encontrar enfoques ampliamente diferentes, que pueden ser confusos.
Una técnica útil es buscar imágenes con las palabras clave adecuadas y tener una idea de qué modelos le atraen visualmente. Revísalos a un alto nivel, sin perderte en los detalles. Seleccione de cuatro a cinco que le parezcan particularmente relevantes para su posterior revisión y referencia.
Mira qué tienen en común y qué diferencias hay. ¿Qué se incluye en la arquitectura y qué no? Trate de pensar en los principios de organización utilizados en su construcción. ¿Qué componentes están listados? No se preocupe si no los comprende por completo o si contienen elementos que le parecen irrelevantes. Recuerde, no hay una respuesta “correcta” o “incorrecta”.
Para la arquitectura empresarial de la Fundación OEL utilizamos modelos de arquitectura de Ethereum, Ontology, CSCC / IBM, Tibco y participantes seleccionados de la industria como referencias.
Estamos en cualquier momento trabajando dentro del contexto de una industria y un conjunto de tecnologías que están cambiando continuamente. Esto puede hacer que los enfoques que se utilizaron incluso relativamente recientemente parezcan irrelevantes y desactualizados.
Tenemos que tratar de entender el estado actual de este contexto y también tratar de mirar hacia adelante e identificar posibles desarrollos futuros en la industria, la economía y las tecnologías. Esto es muy difícil de hacer. El mejor enfoque es tratar de identificar desarrollos amplios que serán relevantes.
Para una arquitectura basada en blockchain, estamos más en desventaja que lo habitual, dada la relativa inmadurez de la tecnología y el rápido ritmo de cambio.
Para la arquitectura empresarial de la Fundación OEL, identificamos cuatro categorías de desarrollo en el mercado y la tecnología que consideramos que son particularmente relevantes para el ecosistema de la Fundación OEL:
1. Modelos de negocios digitales
2. Desarrollo de la tecnología blockchain (especialmente el soporte de ecosistemas emergentes)
3. La convergencia de blockchain y las tecnologías de mensajería.
4. El creciente uso e importancia de los servicios basados en la nube, como Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) e Infrastructure-as-a-Service (IaaS).
Como cualquier sistema, necesitamos definir el límite del sistema para nuestra arquitectura, separando lo que está dentro del sistema y lo que está fuera del sistema.
A veces el límite no se dibuja en el lugar correcto. Es posible que veamos muchos actores externos y componentes de terceros (que no se utilizan para implementar la arquitectura directamente) en una arquitectura. Esto no nos ayuda a identificar los componentes internos esenciales que se utilizarán para la arquitectura.
Si es útil observar la relación de la arquitectura con su entorno, esto debe hacerse utilizando un entregable gráfico, como un diagrama de contexto. Esto está en un nivel más alto de abstracción que la arquitectura en sí.
Para la Arquitectura Empresarial de la Fundación OEL, usamos tecnología y estándares de terceros en la arquitectura, y también nos conectamos a partes y sistemas externos utilizando componentes de la arquitectura, como API, middleware de mensajería y componentes de integración entre cadenas. Podemos considerar que todas estas cosas están dentro de los límites de la arquitectura.
Los participantes del ecosistema, los sistemas o dispositivos externos, o los medios utilizados para integrarlos con la arquitectura están fuera del límite de la arquitectura.
El (los) principio (s) de organización nos ayuda a estructurar la arquitectura y forma una base para la asignación de componentes de arquitectura a diferentes partes de la arquitectura.
Hay varios enfoques que podemos tomar aquí, incluyendo uno o más de los siguientes:
1. Flujo de procesos de negocios de extremo a extremo.
2. Estructura de organización interna de la empresa (con o sin relaciones externas)
3. Un modelo de referencia estándar.
Podemos tratar de utilizar un flujo de procesos empresariales de extremo a extremo para organizar componentes, como pasar de un proveedor a un cliente. Los componentes de la arquitectura se organizan a lo largo del flujo del proceso implícito entre estas partes.
A menudo, la arquitectura refleja la estructura de organización interna, que está compuesta por funciones de organización (o Unidades de organización) como marketing, ventas, operaciones, finanzas, etc. Esto puede incluir o no conexiones con sistemas externos o partes.
Para la arquitectura empresarial de la Fundación OEL utilizamos una variación del modelo de interconexión de sistemas abiertos ISO (modelo OSI) como principio de organización. El modelo OSI es un modelo conceptual que describe las funciones de comunicación de un sistema de telecomunicaciones o de computación.
El modelo OSI usa siete capas, pero varias arquitecturas basadas en blockchain usan un modelo de tres capas. A veces, estos nombres tienen nombres diversos, pero generalmente comprenden una capa de Plataforma (o Aplicación), una capa de Protocolo y una capa de Red. El término "protocolo" puede ser confuso, ambiguo y abierto a la interpretación. Puede ser útil acordar qué significan estos términos, lo que ayuda a identificar los componentes que son relevantes en ese contexto.
Cuando tengamos la estructura general de la arquitectura, podemos decidir qué componentes debe contener la arquitectura y asignarlos a la parte relevante de la arquitectura.
Podemos usar componentes que identificamos en arquitecturas de referencia, así como componentes que pretendemos incorporar que reflejen los desarrollos tecnológicos conocidos o supuestos o los requisitos de los participantes del ecosistema.
Esto es muy específico de la industria e incluso de la organización, por lo que es difícil dar consejos generales.
Sin embargo, se deben aplicar dos principios generales:
1. Los componentes deben estar en general en el mismo nivel de resolución
2. Limita el número de componentes
No queremos que los componentes sean significativamente diferentes de otros en términos de tamaño. Esto suele ser evidente cuando un componente se llama algo así como "núcleo", lo que implica que puede estar en un nivel de resolución más alto que otros componentes, y puede ser necesario descomponerlo en partes lógicas.
Es útil utilizar una regla general sobre la cantidad de componentes que aparecen en la arquitectura. Para una organización multinacional grande y compleja, esto puede ser potencialmente difícil ya que puede haber cientos de aplicaciones separadas involucradas. Aunque pueden agruparse lógicamente en categorías de aplicaciones. Un enfoque común es utilizar siete componentes más o menos dos por capa, y no tener más de veinte componentes en toda la arquitectura.
Finalmente, puede revisar la arquitectura comparándola con los modelos de referencia que identificó inicialmente, usándolos para realizar una verificación cruzada de su arquitectura para verificar su integridad y consistencia.
Revise cada uno de los modelos de referencia con su arquitectura y vea si los componentes del modelo de referencia están presentes en su propia arquitectura. Si no lo están, pregunte por qué es eso y si necesitan ser incluidos. Si su arquitectura tiene componentes adicionales, pregunte si son necesarios y trate de entender por qué no están presentes en el modelo de referencia. Es posible que no sean relevantes para el contexto de ese modelo.
Esta es una buena comprobación de que su arquitectura tiene alguna relación con otros modelos que puede ver en uso en la práctica.
En este punto tienes un modelo de trabajo de tu arquitectura. Ahora puede distribuirlo para que lo revisen sus colegas y otras partes interesadas, e intente utilizarlo en la práctica. Probablemente encontrará que algunos cambios son necesarios, lo cual es normal. No tenga miedo de mover los componentes si piensa que no están en el lugar correcto, o de quitar o insertar nuevos componentes.
No olvide que la arquitectura empresarial es un ser vivo que cambiará con el tiempo y reflejará las necesidades cambiantes de la organización o los cambios externos en la industria o la tecnología.
El modelo de arquitectura empresarial ahora se puede colocar bajo el control de la versión y la responsabilidad de su mantenimiento continuo asignado a una función o parte relevante. En una organización grande, esto puede ser una función de arquitectura formal o un arquitecto individual. En organizaciones más pequeñas, la función puede ser asumida por uno o más individuos que generalmente son analistas de negocios o diseñadores de sistemas.
Esperamos que este artículo sea útil para proporcionarle algunos consejos sobre cómo abordar el trabajo de análisis y diseño para su propia arquitectura empresarial, y le deseamos buena suerte con esto.
Mark Nelson es el CTO de la Fundación OEL. Si desea obtener más información sobre la Fundación OEL, visite https://oel.foundation o contacte al autor directamente a [email protected]
También puedes unirte a la Fundación en Telegram.
