Hablemos de agentes (III): arquitecturas reactivas, deliberativas e híbridas

Abordamos en este tercer artículo de la serie dedicada a los agentes, el tema de las arquitecturas de alto nivel de estos agentes.

Aunque, quizá, pueda parecer un tema algo abstracto y de alto nivel, personalmente me parece muy interesante, muy relevante y práctico, con aplicación real desde ya, y desde hace años, no ya en solo en la emergente Agentic AI, sino también en robótica.

Como en la mayor parte de los artículos de esta serie, me baso en buena medida en el libro  'Building Agentic AI systems' de Anjanava Biswas y Wrick Talukdar.

Como anuncia el título del post, vamos a revisar las tres grandes familias de arquitecturas:

• Arquitecturas reactivas
• Arquitecturas deliberativas
• Arquitecturas híbridas

Arquitecturas reactivas

Las arquitecturas reactivas se basan en un modelo estímulo-respuesta en que, ante un estímulo, el agente proporciona, de manera inmediata, una respuesta. No disponen de una base de conocimiento y se basan en reglas sencillas que hacen corresponder a cada estímulo la respuesta adecuada.

Sus características y sus ventajas, serían:

• Velocidad y capacidad de respuesta: Al acoplar directamente acciones a percepciones, sin una deliberación intermedia, consiguen muy buenos tiempos de respuesta.


• Robustez y tolerancia a fallos: Por su simplicidad, son resistentes al ruido o la información incompleta y poco dadas a fallos catastróficos, ya que unos componentes tienden a compensar a otros.


• Manejo de la incertidumbre: Se pueden adaptar directamente a estímulos cambiantes sin necesidad de disponer de un modelo del entorno o una base de conocimiento.


• Procesamiento paralelo y distribuido: Permiten, y con frecuencia así se hace, su implementación usando módulos reactivos paralelos. Esto habilita el tratamiento de tareas más complejas y proporciona escalabilidad y modularización.


• Emergencia de comportamientos complejos: A pesar de su simplicidad, los sistemas reactivos pueden presentar comportamientos emergentes complejos e inteligentes.

Este tipo de arquitecturas se utilizan en sistemas que deben funcionar en tiempo real donde la robustez y el tiempo de respuesta son fundamentales, como en sistemas de control, videojuegos o robótica, de la que luego hablaremos brevemente.

Por desgracia, también plantean algunas desventajas. Así, carecen de la capacidad de planificación a largo plazo. También presentan dificultades para tratar con tareas que necesitan de pensamiento abstracto y, además, su capacidad de aprendizaje a partir de la experiencia es muy limitada, lo que también coarta su capacidad para la adaptación en el tiempo.

 

Arquitecturas deliberativas

En las arquitecturas deliberativas se utilizan unas reglas explícitas de razonamiento basadas en unos conocimientos, una base de conocimiento, también explícita y habitualmente expresada mediante un lenguaje formal. Es la arquitectura propia de los sistemas simbólicos

Suelen seguir un ciclo percibir-planificar-actuar ('sense-plan-act') según el cual, primero se obtiene (percibe) información del entorno, luego se planifica la actuación con base a lo percibido y los conocimientos de la base de conocimientos y, finalmente, se ejecuta la acción. Los pasos serían:

• Percepción ('sensing'): El agente adquiere información de su entorno mediante sensores o mecanismos de entrada.


• Actualización del conocimiento: Con la información percibida, se actualiza la base de conocimiento, asegurando una adecuada y actualizada representación interna del entorno del agente.


• Planificación y razonamiento: A partir de la base de conocimiento y aplicando los algoritmos adecuados (algoritmos de búsqueda, inferencia lógica, etc), el agente aplica técnicas de razonamiento para obtener un plan de acción


• Ejecución del plan: El agente aplica las acciones definidas sobre el entorno, habitualmente modificándolo de alguna manera.

La principal ventaja de este tipo de arquitecturas es su capacidad para afrontar problemas complejos. También son capaces de enfrentarse a problemas con incertidumbre o ambigüedad usando técnicas como el razonamiento probabilista o la lógica difusa ('fuzzy logic').

Sin embargo, también adolecen de algunas debilidades. Quizá el mayor problema sea conseguir esa base de conocimiento en dominios en constante evolución o sobre temáticas difíciles de formalizar. Adicionalmente, son arquitecturas costosas computacionalmente.

 

Arquitecturas híbridas

Como ocurre en tantas cosas, para superar las limitaciones de modelos más o menos puros, se acude a modelos intermedios o híbridos. Y las arquitectura de agentes no son una excepción y también se plantean arquitectura híbridas que incluyen una capa  reactiva para las respuestas rápidas en tiempo real y una capa deliberativa para la planificación y el razonamiento de alto nivel.

En estas arquitecturas la interacción entre las dos capas es fundamental, proporcionando la capa reactiva información en tiempo real a la deliberativa, y aportando por su parte la capa deliberativa planes de alto nivel, restricciones, etc que matizan el comportamiento reactivo.

Para conseguir comportamientos complejos, estas arquitecturas aplican técnicas como:

• Descomposición de tareas: Los trabajos se descomponen en tareas realizadas por las capas. Así, las tareas de bajo nivel o críticas en el tiempo son realizadas por la capa reactiva mientras que las tareas de planificación y coordinación son gestionadas por la capa deliberativa.


• Selección multiplan: La capa deliberativa puede general planes múltiples y es la capa reactiva la que, en función de la situación del entorno, elige el más adecuado.


• Planificación con módulos externos: La capa deliberativa puede incorporar módulos externos para tareas complejas, como algoritmos de planificación, optimización de rutas o de asignación de recursos.


• Reflexión y refinamiento: la capa deliberativa también puede 'reflexionar' sobre los resultados obtenidos en los planes ya ejecutados, aprender de la experiencia y refinar su razonamiento.


• Planificación con memoria aumentada ('memory-augmented planning'): la capa deliberativa puede mantener una memoria de los planes pasados, las decisiones, los resultados, etc y apoyarse en ellos para futuros razonamientos o planificaciones.

En principio, estas arquitecturas híbridas ofrecen lo mejor de los dos mundos, pero no son tan sencillas de definir y desarrollar y actualmente es un campo en activa investigación.

El caso de la robótica

Ya hemos mencionado repetidas veces en este blog, incluso en esta serie de posts dedicados a los agentes, que una de las mejores formas de iniciar la definición de lo que es un robot, es partiendo de la idea de agente inteligente.

Y, en efecto, y como ya comentamos hace dos años en el post 'Sobre la arquitectura operativa de robots inteligentes', estas mismas arquitecturas se llevan aplicando en robótica desde hace un tiempo.

Especialmente, y en acciones docentes, suelo resaltar la importancia de la capa reactiva y los denominados comportamientos ('behaviors') que pueden conducir, a partir de una programación / configuración relativamente sencilla del robot, a comportamientos emergentes muy adaptados y en apariencia inteligentes.

El paralelismo neurológico-cognitivo

Y en ese mismo post nos hacíamos eco de algo que creo que es interesante y que quiero volver a traer a colación aquí, y es la inspiración y cierto paralelismo de estas arquitecturas con el funcionamiento de los seres vivos en general y el ser humano, el agente por excelencia, en particular.

Así, la capa reactiva se corresponde bastante bien con los comportamientos automáticos, especialmente los comportamientos reflejos del ser humano, mientras que la capa deliberativa 'mapea' bien con los procesos de razonamiento y decisión conscientes.

En cierto modo, podemos pensar que los seres humanos exhibimos una avanzada arquitectura híbrida.

Conclusiones

Vemos dos esquemas básicos de arquitectura, la reactiva y la deliberativa y una vía intermedia o, casi mejor, conjunta. 

Las arquitecturas reactivas, muy implementadas y exitosas, construyen comportamientos más o menos complejos a partir de simples pares estímulos respuesta. 

Por su parte, las deliberativas, más complejas y todavía con mucho desarrollo posible por delante, proporcionan planificación y razonamiento.

Como síntesis de ambas, tenemos las arquitecturas híbridas, bastante en investigación, y que proporcionan un valioso y no casual paralelismo con la actuación humana, y que, caso de conseguirse implementaciones avanzadas, podrían suponer un enorme salto cualitativo en sistemas cognitivos de todo tipo.

Artículos de este blog relacionados

• Hablemos de agentes (II): auto-gobierno, agencia y autonomía
• Hablemos de agentes (I): concepto, contexto y tres características esenciales

Subsistemas en la arquitectura de un robot inteligente

En el post anterior ya hablamos de arquitecturas de robots y entramos algo más en la arquitectura operativa o funcional.

En este artículo vamos a profundizar un poquitos más y ver algo más de la estructuración de las funcionalidades de un robot. 

Subsistemas

Damos ese paso que nos acerca más a lo técnico, hablando de subsistemas, es decir, grandes módulos o divisiones de un sistema, en este caso un robot, y donde vamos a ubicar los diferentes componentes o librerías que formen parte de su implementación.

De alguna forma, los subsistemas forman parte de la arquitectura operativa (pues la subdivisión es funcional), pero nos acerca ya a una arquitectura técnica, con la división de módulos hadrware y software.

Y seguimos también en este caso con la argumentación que hace Robin R. Murphy en su libro 'Introduction to AI robotics' y que, en este caso se apoya, a su vez, en una arquitectura que se propuso en 2003 para el caso de  vehículos móviles no tripulados usados por el ejército norteamericano: 'Technology Development for Army Unmanned Ground Vehicles', una estructuración en subsistemas que, a pesar de su origen, se puede extender casi a cualquier tipo de robot aunque se observará que hay varios elementos que tienen relación precisamente con la navegación y el movimiento.

Cinco subsistemas para robots

 Los cinco subsistemas que se proponen en ese documento y que Murphy acoge como propios, son:

• Planificación: Genera y monitoriza objetivos, acciones y asigna recursos. En el caso de robots móviles, como es el caso donde surgió esta arquitectura, además aporta la visión geoespacial asociada a los objetivos y acciones. Muchos de los algoritmos tradicionales de planificación y de asignación de recursos, se ubican en este subsistema  que concentra de alguna forma la parte nuclear de la función deliberativa.


• Navegación: Tiene sentido realmente en el caso de robots móviles, y se encarga de generar los caminos a seguir en el movimiento y asigna recursos para conseguir los movimientos necesarios. Suele incluir algoritmos de planificación de caminos del tipo A^*, D^* o SLAM ('Simultaneous Localization And Mapping').


• Cartografía: Actúa como un modelo del mundo que se representa como un mapa y que no deja de ser, como sugeríamos en un post anterior, una forma especializada de representación del conocimiento. Un subsistema que, de nuevo, tiene sentido en robots móviles autónomos y no tanto (o no en absoluto) en robots fijos como los brazos robóticos industriales.


• Esquema motor: Subsistema que incluye los módulos que gestionan motores y actuadores. Se suele considerar que incluye las funciones de carácter reactivo en que el robot, sin responder a ningún plan de alto nivel, reacciona a eventos o percepciones recibidas de sus sensores. Cuando hay función deliberativa, ésta se implementaría en el subsistema de planificación.


• Percepción: Incluye los algoritmos para el procesamiento de la información procedentes de los sensores (cámaras, sensores de distancia, de contacto, etc). También incluye cierta capacidad de elegir los sensores más adecuados de acuerdo con la acción en que estamos.

Como se puede apreciar, los subsistemas de navegación y cartografía tiene sentido en robots móviles autónomos. Se trata ésta de los robots móviles autónomos, de todas formas, de una categoría muy amplia, donde podemos encontrar robots industriales o de servicio para el transporte de materiales, los propios vehículos autónomos y, en cierto sentido, los drones autónomos así como también robots humanoides o zoomórficos con capacidad de movimiento autónomo e incluso en otros robots del tipo de robots aspiradora. 

Es decir, aunque algunos robots muy comunes como los de tipo de manipulador industrial que permanecen fijos no necesitarían de esos dos subsistemas, si son una capacidad suficientemente generalista como para considerar la presencia de la Navegación y Cartografía dentro de una especie de arquitectura de referencia.

Conclusión

Esta división en subsistemas supone un paso más en la estructuración de la funcionalidad de robots y su 'mapeo' a módulos software y sirve, por una parte, para poner orden en la implementación pero también, desde un punto de vista casi pedagógico, para conocer un poco más a los robots.

Sobre la arquitectura operativa de robots inteligentes

No pretende este artículo, a pesar de que el título pueda sugerir otra cosa, ser excesivamente técnico, sino más bien recoger un esquema que, aunque técnico, ayuda a entender mejor internamente los robots inteligentes, y lo que es más, dar forma también nuestro conocimiento sobre el propio ser humano y su estructuración cognitiva. 

Recojo, en el fondo, una propuesta arquitectural que hace Robin R. Murphy en su libro 'Introduction to AI robotics' y que, aunque creo que no es de aceptación universal, sí tiene mucho puntos en común con otros esquemas y arquitecturas.

Una arquitectura, representa de alguna manera un diseño técnico de alto nivel (a veces de muy alto nivel) y que, con frecuencia, se queda en una estructuración en bloques interrelacionados del elemento técnico, máquina, software o lo que sea, de que se trate.

Murphy concibe la arquitectura como una especie de plantilla, casi diría que unas buenas prácticas en el diseño, en este caso, de robots inteligentes.

Tipos de arquitecturas

Pero en realidad, tenemos más de un tipo de arquitectura. Así, la autora adopta en su descripción una tipología de arquitecturas propuesta por Alex Levis en 2001, a la sazón Chief Scientist de la fuerza aérea norteamericana y que es la siguiente:

• Arquitectura operativa: Una descripción funcional de alto nivel, que indica qué es lo que hace en este caso el robot pero no cómo lo hace. La autora indica que una arquitectura operativa debe indicar, de alguna forma, cómo las siete áreas de la inteligencia artificial que vimos en un post anterior, se enlazan para proporcionar la funcionalidad deseada.


• Arquitectura de sistemas: Describe la descomposición del sistema en subsistemas. Busca características propias de la ingeniería software como la modularidad o la extensibilidad.


• Arquitectura técnica: Describe los detalles de la implementación. Describe algoritmos e incluso lenguajes de programación.

Muchos lectores, especialmente los más avezados en sistemas y arquitectura de sistemas, notarán que esta tipología de arquitecturas no es, para nada, especialmente 'robótica' sino que vale para casi cualquier sistema. Y en el fondo me parece bueno y razonable que sea así. Al fin y al cabo, un robot no deja de ser un sistema, con su hardware y su software.

Tres capas en la arquitectura operativa

Centrándonos ya en la capa operativa, la autora nos explica la convergencia histórica, no ausente de fuerte debate previo, en una arquitectura que distingue entre una visión reactiva y otra deliberativa. Y, al final, suma una tercera visión para hablarnos de las siguientes tres capas, de una arquitectura operativa:

• Capa reactiva: Recoge comportamientos en que no existe una planificación. Es decir, el robot percibe un estímulo o una información del exterior mediante sus sensores y capacidades perceptivas y, simplemente, reacciona conforme tiene programado hacerlo.


• Capa deliberativa: En este caso, el robot si ejecuta planes. Dispone de un módulo planificador y de un modelo del mundo. Conforme a ese plan, la capa deliberativa instruye a la reactiva acerca de los comportamientos asociar a una percepción. En esta capa se generan planes, se seleccionan los recursos necesarios para ellos, se implementan y se monitoriza su ejecución.


• Capa interactiva: Esta capa permite la interacción de un robot con otros agentes, incluidos, claro, otros robots o los propios seres humanos. Es una capa algo peor entendida y objeto de más investigación y que, creo, nos lleva a campos como, por ejemplo, Human-Robot Interaction o  swarm robotics.

Las tres ofrecen muchos detalles y áreas de estudio. Tengo especial interés en mencionar alguna reflexión al respecto de la capa reactiva, pero eso lo dejaré para un próximo artículo.

La inspiración biológica

Y no quisiera dejar de destacar, la clara inspiración biológica que hay tras estas capas arquitecturales, algo que deja patente una vez más la fructífera interacción entre la inteligencia artificial y la robótica con otras disciplinas como la psicología o la neurociencia, y cómo las segundas (fisiología, psicología, neurociencia) inspiran modelos y arquitecturas en las áreas técnicas y cómo, a su vez, la inteligencia artificial y la robótica pueden servir como 'campo de pruebas' de conceptos psicológicos o neurocientíficos.

Así, y como la autora explicita, estas capas se relacionan con el comportamiento del ser humano. La propia autora aporta la siguiente figura para explicarlo:

Autora: Robin R. Murphy

La capa reactiva se relaciona con comportamientos reflejos que se producen en la espina dorsal o en las partes más primitivas e internas del cerebro humano. La capa deliberativa, por el contrario, refiere a la actividad cognitiva que tiene lugar en la corteza cerebral. La capa interactiva, finalmente, se refiere a comportamientos sociales, en muchos casos conscientes pero también tendría que ver con los movimientos de enjambres o manadas que observamos en animales, como bancos de peces o de estorninos.

Conclusión

Las arquitecturas, nos proporcionan un diseño de alto nivel pero también, especialmente si hablamos de una arquitectura funcional, operativa, un marco para la estructuración y entendimiento de una solución o de un fenómeno, que en este caso abarca tanto los procesos nerviosos y mentales de los seres humanos como de los robots inteligentes.

Un modelo de referencia para Internet de las Cosas

Hace más de dos años disertaba en este blog acerca de la utilidad de un modelo de referencia y llegaba a la conclusión de que eran ocho las cosas que nos aportaba un modelo de referencia:

• Ayuda al pensamiento


• Vencer el miedo al papel en blanco


• Coherencia


• Completitud


• Reutilización de conocimiento


• Prestigio / autoridad


• Estandarización


• Comunicación

Algunos los puntos, como la ayuda al pensamiento, recuerdan también la utilidad de un arquitectura que discutíamos también en el post anterior.

Pues bien, todos esos beneficios es razonable buscarlos en un área tecnológica emergente y de alto potencial como es Internet de las Cosas. Y en esa línea, ya hace un tiempo, concretamente en 2014, que Cisco se puso manos a la obra y propuso un modelo de referencia para Internet de las Cosas, un modelo de referencia que descubro leyendo el libro 'Internet of Things. Principles and Paradigms' editado por Rajkumat Vuyya y Amir Vahid Dastjerdi.

Ese modelo de referencia propone una estructura en capas no muy alejada en su filosofía del modelo de referencia ISO/OSI.

Estas son las capas y su significado:

• Nivel 1: Dispositivos físicos y controladores - incluye lo más físico, los dispositivos y un primer nivel de control, los controladores. Se admite que la diversidad en dispositivos va a ser muy alta.


• Nivel 2: Conectividad - concentra todas las comunicaciones, tanto la conectividad de los dispositivos como entre redes o en la interacción con el nivel 3


• Nivel 3: Computación en la frontera (o Fog computing) - del cual ya hablamos en un artículo anterior y que realiza un primer nivel de tratamiento de datos muy voluminosos haciendo cosas como evaluación, formateo, etc


• Nivel 4: Acumulación de datos (almacenamiento) - se encarga fundamentalmente del almacenamiento, de la transformación de unos datos en constante movimiento en los niveles inferiores a unos datos 'en reposo' en los siguientes niveles. En este nivel se decide, por ejemplo, si un dato debe ser persistido y en que medio.


• Nivel 5: Abstracción de datos - preparar los datos para ser tratados en niveles superiores como, por ejemplo, su adaptación a formatos de ERP, normalización, almacenamiento en un solo sitio mediante técnicas ETL, etc.


• Nivel 6: Aplicación - nivel en que se interpretan los datos. El modelo de referencia, como resulta bastante lógico por otra parte, no entra en el detalle de cómo debe ser este tratamiento ni cómo deben ser las aplicaciones.


• Nivel 7: Colaboración y procesos - donde se involucra ya a a personas y procesos y se aplican los conceptos de colaboración.

Quizá, lo que me resulta más llamativo del modelo, es su gran orientación a los datos, más que a la conectividad, aunque la incluya,o a las aplicaciones. Sin ser muy claramente mencionado, parece que el Big Data se encuentra latente en este modelo.

Sea como fuere, si este modelo propuesto por Cisco, nos ayuda a entender mejor en qué consiste Internet de las Cosas, ya habrá hecho una buena aportación conforme a una de las utilidades de un modelo de referencia: la captura, estructuración y comunicación del conocimiento,

¿Para qué vale una arquitectura?

No siempre se utiliza exactamente en el mismo sentido, pero la arquitectura referida a un sistema, una tecnología, un estándar o un tipo de soluciones, nos habla de las líneas maestras de un diseño, de los principales bloques y sus relaciones, de las tecnologías y los estándares empleados.

Es un diseño de alto nivel, un diseño cuya correcta consecución requiere probablemente de las mayores habilidades y conocimientos, y que se nutre y precisa de las más profundas y amplias experiencias.

Sin embargo, a veces ese carácter de alto nivel, esa engañosa simplicidad que algunas arquitecturas exhiben, puede hacer dudar de su valor, puede hacer parecer que apenas nos dicen nada...

¿Para qué vale una arquitectura?

Probablemente su mayor valor sea el marcar las principales líneas de diseño, el poner las bases de la solución, el dejar el camino expedito para el desarrollo de los detalles.

Pero las arquitecturas, especialmente cuando hablamos no de una solución concreta, sino de un estándar o tecnología más general, tienen también una función cognitiva: ordenan, estructuran y comunican el conocimiento. 

Así se reconoce en el libro 'Internet of Things. Principles and Paradigms' editado por Rajkumat Vuyya y Amir Vahid Dastjerdi cuando dice:

proposing an architecture is often the first step in consolidating knowledge in information and communication technologies

Y creo que, incluso si una arquitectura no añadiese más valor ni más diseño, que sí que lo hacen, sólo por este poder estructurador del conocimiento, ya serían, ya son valiosas, ya vale la pena su definición...

La perspectiva TOGAF (I): ¿Qué es una arquitectura?

El concepto de arquitectura, no cuando hablamos de edificios y construcción, sino cuando nos centramos en sistemas, modelos e IT, es un concepto ya antiguo.

Casi desde siempre la idea de arquitectura es esencial en el mundo de los sistemas informáticos. De manera vaga podríamos decir que la arquitectura define el diseño de alto nivel del sistema, la tecnología empleada y los componentes fundamentales.

Pero esta idea de arquitectura se ha extendido para la descripción de sistemas en sentido amplio, no solo informáticos y, en los últimos años, hablamos incluso de los modelos de empresa, la denominada arquitectura empresarial.

Pero ¿qué es, entonces un arquitectura?

Leyendo 'TOGAF 9 Foundation study guide' de Rachel Harrison me encuentro, primero, con la definición que de arquitectura se hace en la norma ISO/IEC 42010 Systems and software engineering — Architecture description. Es la siguiente:

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing ints design and evolution.

De esta descripción destaco la idea de que describe los componentes y sus interrelaciones. En cambio, echo en falta la ausencia de mención a la tecnología.

Sin embargo, lo que más me interesa en este post es ver qué tiene que decir The Open Group con su TOGAF al respecto.

Según nos explica Rachel Harrison, TOGAF no adopta directamente esta definición. Según se nos dice, TOGAF le aplica dos significados.

El primero:

A formal description of a system, or a detailed plan of the system at a component level to guide its implementation.

y el segundo:

The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

En las tres definiciones, la de ISO y las dos de TOGAF, se aprecia la importancia de la identificación de los componentes. En la segunda también se destaca la inter-relación entre esos componentes.

También es relevante la inclusión en el concepto de arquitectura las guías para el diseño y, sobre todo, la implementación y evolución.

Se observa, de nuevo, la desaparición de lo relativo a la tecnología, cosa que en el caso de TOGAF parece más normal, puesto que TOGAF se centra en una arquitectura empresarial, no una arquitectura de sistemas informáticos.

Creo que, tras ver las definiciones el concepto de arquitectura en TOGAF tiene tres elementos,

• Componentes
• Inter-relaciones entre esos componentes
• Guías de diseño, implementación y evolución.

Me interesa ver cómo se aplica esto cuando en lugar de hablar de arquitectura en general, lo hacemos de arquitectura empresarial en particular.

Me interesa...pero eso será objeto del siguiente post.

¿Para qué vale un modelo de referencia? Ocho buenas razones.

Cuando nos enfrentamos a un trabajo de análisis o de diseño, suelen surgir como ayuda un conjunto de modelos más o menos ordenado A esos modelos los denominaré de forma algo genérica 'modelos de referencia' aunque reciben otros muchos nombres como 'framework' o, simplemente, modelo.

¿Qué entiendo por un modelo de referencia?

Necesitaría más tiempo de reflexión y de contraste con literatura técnica o empresarial de todo tipo para extraer una definición 'perfecta', pero de forma bastante improvisada, podría definir un modelo de referencia como:

Una estructuración de carácter generalmente gráfico o semigráfico de un área de conocimiento que recoge y organiza de forma compacta los aspectos más relevantes de ese área de conocimiento.

Este tipo de modelos los encontramos en muchas disciplinas pero, por intentar aclarar algo la idea elegiré varios ejemplos del mundo de la tecnología y del management (los temas que predominan en este blog).

Modelos en capas ISO/OSI

Hace ya muchos años, el sector de las telecomunicaciones dispone y utiliza frecuentemente el modelo en capas ISO/OSI que estructura en siete niveles (capas) los diferentes servicios y protocolos de comunicación. Aunque no sigue estrictamente el modelo ISO/OSI, la torre de protocolos TCP/IP sí se adapta un modelo en capas bastante cercano. Así, TCP es un protocolo del nivel 4 e IP un protocolo de nivel 3. Los muy conocidos FTP o HTTP serían protocolos del nivel 7. 

En el mundo de las tecnologías de información, y muchas veces bajo el apelativo de arquitectura, se establecen otros muchos modelos. Pongamos por caso JEE que, inicialmente impulsado por la entonces Sun Microsystems, marca un modelo de referencia para las aplicaciones java empresariales.

Matriz Boston Consulting Group

En el mundo del análisis estratégico, es muy frecuente el uso de modelos muy sencillos como pueden ser el DAFO para analizar las Debilidades y Fortalezas de una compañía y las Amenzas y Oportunidades que la rodean en su mercado. Muy conocido también, por poner otro ejemplo es la matriz de la cartera de productos del Boston Consulting Group. Dentro de este campo del análisis estratégico podríamos considerar también un modelo de referencia, por ejemplo, la cadena de valor de Michael Porter.

Modelo de procesos eTOM (TMForum)

Si nos vamos a un mundo más cercano al análisis de procesos e incluso el mundo IT, nos encontramos modelos de arquitectura empresarial que organizan las funciones e información de una compañía. Un caso especial podría ser el propuesto por TeleManagement Forum para el sector de las telecomunicaciones con su mapa de procesos (eTOM), su mapa de información (SID) y su mapa de aplicaciones (TAM). En cierto modo, el modelo de procesos que propone ITIL podría ser considerado otro modelo de referencia.

Modelo procesos ITIL

En el mundo de la dirección de proyectos, el modelo de áreas de conocimiento y fases del PMI no deja de ser otro modelo de referencia. O, en el mundo del Business Analysis el modelo que propone IIBA.

Como estos podrían encontrarse muchísimos ejemplos en todo tipo de disciplinas, se podrían tener en cuenta muchas matizaciones y seguro que podríamos incluso establecer una tipología dentro de ellos..

Pero no es, en el fondo, ni la definición rigurosa ni la clasificación de los modelos de referencia lo que más me importa en este artículo, sino su utilidad.

Y me ha inspirado a pensarlo y escribirlo una frase extraída del libro 'The business analyst's survival guide' de LeAnn Simonson en que, hablando precisamente de business analysis, y poco antes de proponernos un 'framework' para gestionar problemas interpersonales, la autora nos habla de arquetipos y 'frameworks' y nos dice:

An archetype, framework, or model can be useful in organizing thoughts and actions.

Sí, creo que esa frase recoge una de las utilidades de un modelo de referencia: ayudar a pensar, organizar el pensamiento. Pero tras una breve reflexión, yo identifico ocho. Serían las siguientes:

• Ayuda al pensamiento: Un modelo de referencia, sobre todo, ayuda a pensar, a estructurar el conocimiento y el pensamiento en áreas que normalmente son o complejas o algo intangibles. Nos da estructura y un punto de partida.


• Vencer el miedo al papel en blanco: precisamente ese punto de partida es otra de sus utilidades. Como ya se nos proporciona un modelo, un esquema e incluso, una primera aproximación a nuestro problema, ayuda a vencer el miedo al papel en blanco, a dar el primer paso. Ese paso ya lo ha dado el modelo por nosotros.


• Coherencia: Los modelos de referencia, incluso los más sencillos, suelen estar muy bien pensados y debatidos. En ese sentido, suelen ser muy coherentes... y si los utilizamos correctamente nuestras conclusiones tiene más posibilidades de ser también coherentes.


• Completitud: por la misma razón, suelen ser modelos completos, que nos garantizan no olvidarnos de aspectos importantes. Esto es muy relevante especialmente en modelos complejos como una arquitectura tecnológica o una arquitectura empresarial.


• Reutilización de conocimiento: derivado del concepto de punto de partida, estamos reutilizando conocimiento de terceros, conocimiento que tras mucho trabajo se plasmó en el modelo de referencia. Nosotros partimos de un punto con mucho ya avanzado...y nos permite ir más allá.


• Prestigio / autoridad: habitualmente, aparte de estar muy trabajados, los modelos de referencia están respaldados o por un gurú, una persona de mucha autoridad en su campo (ej. Michael Porter) o bien por instituciones de prestigio (PMI, IIBA, OMG,...). Eso, por un lado, nos proporciona la tranquilidad de estar haciendo algo correcto y, también prestigia nuestro trabajo con la autoridad que se le supone al modelo.  


• Estandarización: Los modelos de referencia de más éxito se constituyen en estándares de facto o de iure (especialmente los tecnológicos). El utilizarlos nos permite una mayor facilidad de integración con otros modelos, documentos, productos, sistemas, etc. También proporciona una mayor base de personas formadas y suficientemente conocedoras del modelo.


• Comunicación: La estandarización conlleva también una homegeneización de conceptos, estructuras y vocabulario... y eso facilita la comunicación en el equipo y con terceros.

Quien conozca algunos de los modelos que he mencionado, seguramente entienda y aprecie las ventajas que he enumerado. Para quien resulte novedosa la idea, espero al menos haber 'picado' la curiosidad y el interés ante tan interesante concepto.

¿A algún lector se le ocurren otras razones?

Una nueva estrategia de procesamiento versus almacenamiento de datos

Un breve artículo, sólo para consignar una idea sobre arquitectura que expresan Eric A. Marks y Bob Lozano en su libro 'Executive's guide to cloud computing'.

Según estos autores, la evolución de la arquitectura hardware en la parte servidora de los sistemas había llevado en los años noventa a la creación de elementos especializados de almacenamiento de datos, separando por tanto, a nivel hardware, la información del procesamiento, la computación propiamente dicha si se prefiere, del almacenamiento de datos, implementado éste, típicamente, como soluciones de tipo RAID unidas mediante fibra a los servidores de procesamiento.

En cierto sentido, apunto yo, hasta las arquitecturas software cliente/servidor multinivel, por ejemplo J2EE, parecían reflejar y hasta favorecer a nivel lógico, aunque estrictamente no lo precisaran, esa separación de datos frente a procesamiento o lógica de aplicación.

Sin embargo, y de nuevo según los autores antes mencionados, hoy día esto comienza a no ser siempre la mejor solución.

¿Por qué?

Pues debido al problema del throughput que comentábamos en un artículo reciente y a las tendencias hacia el cloud computing.

Si pensamos en un entorno de cloud computing, en que las interacciones, en este caso entre la parte de procesamiento y la de almacenamiento de datos, se producen a través 'de la nube', en concreto, a través de los elementos de red que constituyen esa 'nube', y si pensamos que el ancho de banda de procesamiento es mucho mayor y crece muchísimo más rápido que el de la red, el problema se hace evidente: el acceso a los datos se convierte en un acuciante cuello de botella y un límite a la escalabilidad y al crecimiento.

¿La solución?

En lugar de separar elementos especializados, unos de procesamiento, y otros de almacenamiento, construir la capacidad de gestión de datos de la nube con base en pequeños módulos que agrupen tanto procesamiento como almacenamiento, y escalar con este tipo de módulos. En concreto, los autores, a modo de ejemplo, proponen un módulo o bloque, con estas características:

• procesadores: dos procesadores a 2,5 GHz
• disco: un drive de 2 Tb
• memoria: 4 Gb
• red: conexión gigE

Un curioso e interesante razonamiento...