Published 17 years ago
(updated 13 years ago)
Con Procesos Bien Definidos
Cuando llega el momento de desarrollar la arquitectura de un sistema de software, es normal que surjan dudas como: ¿Por dónde empezar?, ¿qué documentos y diagramas hay que hacer? ¿cuáles hacemos primero y qué orden seguimos? y muchas de las veces incluso dudamos de ¿qué es la arquitectura de software?
En esta ocasión haremos un resumen del marco de trabajo para arquitecturas y en particular del método para desarrollar arquitecturas propuesto por The Open Group. Método que nos puede ayudar a responder las preguntas planteadas.
¿Qué es y para qué sirve la
arquitectura?
La arquitectura de un sistema de software nos ayuda a satisfacer los requisitos de calidad que debe cumplir un sistema de software permitiendo que la solución creada sea confiable, mantenible, estable, usable y todos los “able” que nos enseñan en la preparación académica acerca de este tema.
Otro hecho en la vida de un proyecto es que la única constante en el desarrollo del software es el cambio. Una buena arquitectura nos ayuda a realizar estos cambios con menos tiempo y esfuerzo, además de facilitar la implementación de una estrategia de re-uso.
El término arquitectura de software es uno de los más extensos y documentados, y me refiero a lo siguiente, si le preguntas ¿qué es arquitectura de software? a cinco desarrolladores, seguramente obtendrás cinco respuestas distintas, incluso el SEI (Software Engineering Institute) en su sitio en internet tiene una sección que recopila definiciones de arquitectura de software (www.sei.cmu.edu/
architecture/published_definitions.html).
Nos quedaremos con la siguiente definición de arquitectura de software, proveniente del libro Software Architecture in Practice: La arquitectura de software de un programa o sistema de cómputo es la estructura o estructuras del sistema, la cual incluye los elementos del software, las propiedades externamente visibles de esos elementos y las relaciones entre ellos.
Por elementos del software, debemos entender prácticamente todo lo que podamos representar en UML y aún más, clases, objetos, componentes, hardware, pantallas, requisitos, casos de uso, etc. Pero ¿cuáles son los pasos para describir y plantear las relaciones entre todos esos elementos? Es precisamente eso lo que veremos a continuación.
Madurez en la disciplina de
arquitectura de software
El desarrollo de software ha dejado de ser un arte y poco a poco se ha ido convirtiendo en una ingeniería, lo mismo ha sucedido con la disciplina de arquitectura de software, esta madurez es tangible por los siguientes elementos:
• Un cuerpo de conocimiento (Body of Knowledge, BOK) de arquitectura.
• Certificaciones como arquitecto de software.
• Modelo de procesos para desarrollar la arquitectura de software.
Aún falta trabajo por realizar, ya que actualmente contamos con varias iniciativas para formar un BOK de arquitectura, habría que unificar estas iniciativas para ganar aún más madurez. Lo mismo sucede con respecto a las
certificaciones como arquitecto de software, existen certificaciones de Microsoft, Sun e IBM solo por mencionar algunas. Esperemos que en el futuro veamos la unificación de todas las certificaciones existentes, pues sería un buen paso en beneficio de la comunidad de arquitectos de software.
Anteriormente no contábamos con un modelo de proceso para desarrollar la arquitectura de un sistema de software. Y en todo caso, algunos de estos pasos se llegan a contemplar en los modelos de procesos para desarrollo de software como el Proceso Unificado en el Marco de Trabajo para Soluciones de Microsoft (UP y MSF), Iconix, sólo por mencionar algunos.
La buena nueva es que ya existe un modelo de procesos creado específicamente para el desarrollo de arquitecturas de software, el cual complementa muy bien a los procesos de desarrollo de software existentes, como los antes mencionados.
Un marco de trabajo para
arquitectura
The Open Group es un consorcio de usuarios y fabricantes de la industria de TI que cuenta con varios foros, de los cuales el de arquitectura ha sido uno de los más activos, una de las conclusiones de este foro en 1994 fue que era necesario desarrollar un marco de trabajo para la arquitectura empresarial, resultando de esta iniciativa el Marco de Trabajo para Arquitecturas de The Open Group (TOG Architecture Framework, o TOGAF).
Aunque TOGAF no es el único marco de trabajo para la arquitectura de software. Algunos de los más relevantes al momento son:
• The Zachman Framework for Enterprise
Architecture.
• TOGAF.
• The Federal Enterprise Architecture (FEA).
• The Gartner Methodology.
Sin embargo estos marcos de trabajo tienen una estructura y enfoque distintos entre ellos. Al de Zachman se le conoce mas como una taxonomía, el de TOGAF se enfoca más en el proceso, el FEA es una arquitectura empresarial implementada y el de Gartner es la experiencia y conocimiento acumulada por algunos expertos para desarrollar buenas arquitecturas empresariales.
Dado el interés de la industria, en nuestra empresa hemos decidido seleccionar a
TOGAF como la opción para incrementar el catálogo de cursos al público. Además de ser la opción más madura al plantear un proceso para desarrollar la arquitectura.
TOGAF
Para TOGAF la arquitectura de TI empresarial no tiene que ver sólo con las aplicaciones de la organización. Pues, propone una arquitectura de TI que funcione para el negocio, es decir, que este alineada y apoye a las estrategias del negocio.
La arquitectura de TI empresarial considera las arquitecturas técnicas y de negocio, crea una visión estratégica y lleva esa visión hasta su implementación.
TOGAF tiene tres componentes principales para lograr lo anterior:
• Método para desarrollar la arquitectura.
• Enterprise continuum.
• Base de recursos de TOGAF.
El enterprise continuum es un repositorio virtual de patrones, modelos, descripciones de arquitectura y otros artefactos, que constituyen en si un marco de trabajo dentro del marco de trabajo de TOGAF, que sirve para clasificar tanto el material del repositorio como al resto de modelos relevantes y similares que existen en la industria.
La base de recursos es el conjunto de lineamientos, plantillas e información relacionada. El Método para desarrollar la arquitectura (Architecture Development Method, ADM) lo detallaremos en la siguiente sección.
TOGAF más que ayudarnos a describir una Arquitectura Orientada a Servicios (SOA por sus siglas en inglés) particular, nos ayudará a decidir si SOA es lo mejor para el proyecto.
La metodología de TOGAF ayuda al arquitecto a destilar el proyecto hasta el punto de tomar la decisión de si SOA es el estilo de arquitectura que nos ayudará a resolver mejor el problema original.
El método para desarrollar la arquitectura
El ADM de TOGAF es una especie de “CMMI para arquitectura”. Nos presenta un proceso iterativo con fases que se deben realizar para desarrollar la arquitectura, definiendo las entradas y salidas de cada fase pero sin indicarnos como hacer cada uno de los entregables.
Figura 1. Fases del ADM de TOGAF
La fase preliminar es el momento en el cual se inicia el proceso de adopción del ADM al interior de la organización, difundiendo los beneficios e involucrando a todos las personas necesarias.
• Fase A. Visión de la arquitectura, implica desarrollar una visión de la arquitectura definiendo el alcance y la estrategia para lograrla.
• Fase B. Arquitectura de negocio, se busca tener clara la arquitectura de negocio y sus metas para posteriormente poder alinear la TI al negocio.
• Fase C. La arquitectura de sistemas de información contempla las arquitecturas particulares para datos y aplicaciones.
• Fase D. La arquitectura tecnológica define la arquitectura integrada que se desarrollara en fases futuras.
• Fase E. La fase de oportunidades y soluciones permite determinar qué partes se comprarán, construirán o reutilizarán y cómo se implementará la arquitectura de la fase D.
• Fase F. El plan de migración sirve para priorizar los proyectos y desarrollar el plan de migración.
• Fase G. Control de la implementación es la ejecución de los proyectos para construir las soluciones de TI.
• Fase H. La administración del cambio de la arquitectura implica monitorear y evaluar los sistemas existentes para determinar cuándo iniciar un nuevo ciclo de ADM.
Conclusión
Contar con y conocer un proceso bien definido que nos indica paso por paso cómo se debe desarrollar la arquitectura empresarial es indispensable para un buen arquitecto. De otra forma no existe un consenso respecto a los documentos y diagramas que se deben tener para definir la arquitectura de un sistema de software. Sin embargo el ADM, como cualquier modelo de procesos, debe adoptarse gradualmente, sin intentar implementarlo de inmediato al 100% y en todos los proyectos
Cuando llega el momento de desarrollar la arquitectura de un sistema de software, es normal que surjan dudas como: ¿Por dónde empezar?, ¿qué documentos y diagramas hay que hacer? ¿cuáles hacemos primero y qué orden seguimos? y muchas de las veces incluso dudamos de ¿qué es la arquitectura de software?
En esta ocasión haremos un resumen del marco de trabajo para arquitecturas y en particular del método para desarrollar arquitecturas propuesto por The Open Group. Método que nos puede ayudar a responder las preguntas planteadas.
¿Qué es y para qué sirve la
arquitectura?
La arquitectura de un sistema de software nos ayuda a satisfacer los requisitos de calidad que debe cumplir un sistema de software permitiendo que la solución creada sea confiable, mantenible, estable, usable y todos los “able” que nos enseñan en la preparación académica acerca de este tema.
Otro hecho en la vida de un proyecto es que la única constante en el desarrollo del software es el cambio. Una buena arquitectura nos ayuda a realizar estos cambios con menos tiempo y esfuerzo, además de facilitar la implementación de una estrategia de re-uso.
El término arquitectura de software es uno de los más extensos y documentados, y me refiero a lo siguiente, si le preguntas ¿qué es arquitectura de software? a cinco desarrolladores, seguramente obtendrás cinco respuestas distintas, incluso el SEI (Software Engineering Institute) en su sitio en internet tiene una sección que recopila definiciones de arquitectura de software (www.sei.cmu.edu/
architecture/published_definitions.html).
Nos quedaremos con la siguiente definición de arquitectura de software, proveniente del libro Software Architecture in Practice: La arquitectura de software de un programa o sistema de cómputo es la estructura o estructuras del sistema, la cual incluye los elementos del software, las propiedades externamente visibles de esos elementos y las relaciones entre ellos.
Por elementos del software, debemos entender prácticamente todo lo que podamos representar en UML y aún más, clases, objetos, componentes, hardware, pantallas, requisitos, casos de uso, etc. Pero ¿cuáles son los pasos para describir y plantear las relaciones entre todos esos elementos? Es precisamente eso lo que veremos a continuación.
Madurez en la disciplina de
arquitectura de software
El desarrollo de software ha dejado de ser un arte y poco a poco se ha ido convirtiendo en una ingeniería, lo mismo ha sucedido con la disciplina de arquitectura de software, esta madurez es tangible por los siguientes elementos:
• Un cuerpo de conocimiento (Body of Knowledge, BOK) de arquitectura.
• Certificaciones como arquitecto de software.
• Modelo de procesos para desarrollar la arquitectura de software.
Aún falta trabajo por realizar, ya que actualmente contamos con varias iniciativas para formar un BOK de arquitectura, habría que unificar estas iniciativas para ganar aún más madurez. Lo mismo sucede con respecto a las
certificaciones como arquitecto de software, existen certificaciones de Microsoft, Sun e IBM solo por mencionar algunas. Esperemos que en el futuro veamos la unificación de todas las certificaciones existentes, pues sería un buen paso en beneficio de la comunidad de arquitectos de software.
Anteriormente no contábamos con un modelo de proceso para desarrollar la arquitectura de un sistema de software. Y en todo caso, algunos de estos pasos se llegan a contemplar en los modelos de procesos para desarrollo de software como el Proceso Unificado en el Marco de Trabajo para Soluciones de Microsoft (UP y MSF), Iconix, sólo por mencionar algunos.
La buena nueva es que ya existe un modelo de procesos creado específicamente para el desarrollo de arquitecturas de software, el cual complementa muy bien a los procesos de desarrollo de software existentes, como los antes mencionados.
Un marco de trabajo para
arquitectura
The Open Group es un consorcio de usuarios y fabricantes de la industria de TI que cuenta con varios foros, de los cuales el de arquitectura ha sido uno de los más activos, una de las conclusiones de este foro en 1994 fue que era necesario desarrollar un marco de trabajo para la arquitectura empresarial, resultando de esta iniciativa el Marco de Trabajo para Arquitecturas de The Open Group (TOG Architecture Framework, o TOGAF).
Aunque TOGAF no es el único marco de trabajo para la arquitectura de software. Algunos de los más relevantes al momento son:
• The Zachman Framework for Enterprise
Architecture.
• TOGAF.
• The Federal Enterprise Architecture (FEA).
• The Gartner Methodology.
Sin embargo estos marcos de trabajo tienen una estructura y enfoque distintos entre ellos. Al de Zachman se le conoce mas como una taxonomía, el de TOGAF se enfoca más en el proceso, el FEA es una arquitectura empresarial implementada y el de Gartner es la experiencia y conocimiento acumulada por algunos expertos para desarrollar buenas arquitecturas empresariales.
Dado el interés de la industria, en nuestra empresa hemos decidido seleccionar a
TOGAF como la opción para incrementar el catálogo de cursos al público. Además de ser la opción más madura al plantear un proceso para desarrollar la arquitectura.
TOGAF
Para TOGAF la arquitectura de TI empresarial no tiene que ver sólo con las aplicaciones de la organización. Pues, propone una arquitectura de TI que funcione para el negocio, es decir, que este alineada y apoye a las estrategias del negocio.
La arquitectura de TI empresarial considera las arquitecturas técnicas y de negocio, crea una visión estratégica y lleva esa visión hasta su implementación.
TOGAF tiene tres componentes principales para lograr lo anterior:
• Método para desarrollar la arquitectura.
• Enterprise continuum.
• Base de recursos de TOGAF.
El enterprise continuum es un repositorio virtual de patrones, modelos, descripciones de arquitectura y otros artefactos, que constituyen en si un marco de trabajo dentro del marco de trabajo de TOGAF, que sirve para clasificar tanto el material del repositorio como al resto de modelos relevantes y similares que existen en la industria.
La base de recursos es el conjunto de lineamientos, plantillas e información relacionada. El Método para desarrollar la arquitectura (Architecture Development Method, ADM) lo detallaremos en la siguiente sección.
TOGAF más que ayudarnos a describir una Arquitectura Orientada a Servicios (SOA por sus siglas en inglés) particular, nos ayudará a decidir si SOA es lo mejor para el proyecto.
La metodología de TOGAF ayuda al arquitecto a destilar el proyecto hasta el punto de tomar la decisión de si SOA es el estilo de arquitectura que nos ayudará a resolver mejor el problema original.
El método para desarrollar la arquitectura
El ADM de TOGAF es una especie de “CMMI para arquitectura”. Nos presenta un proceso iterativo con fases que se deben realizar para desarrollar la arquitectura, definiendo las entradas y salidas de cada fase pero sin indicarnos como hacer cada uno de los entregables.
Figura 1. Fases del ADM de TOGAF
La fase preliminar es el momento en el cual se inicia el proceso de adopción del ADM al interior de la organización, difundiendo los beneficios e involucrando a todos las personas necesarias.
• Fase A. Visión de la arquitectura, implica desarrollar una visión de la arquitectura definiendo el alcance y la estrategia para lograrla.
• Fase B. Arquitectura de negocio, se busca tener clara la arquitectura de negocio y sus metas para posteriormente poder alinear la TI al negocio.
• Fase C. La arquitectura de sistemas de información contempla las arquitecturas particulares para datos y aplicaciones.
• Fase D. La arquitectura tecnológica define la arquitectura integrada que se desarrollara en fases futuras.
• Fase E. La fase de oportunidades y soluciones permite determinar qué partes se comprarán, construirán o reutilizarán y cómo se implementará la arquitectura de la fase D.
• Fase F. El plan de migración sirve para priorizar los proyectos y desarrollar el plan de migración.
• Fase G. Control de la implementación es la ejecución de los proyectos para construir las soluciones de TI.
• Fase H. La administración del cambio de la arquitectura implica monitorear y evaluar los sistemas existentes para determinar cuándo iniciar un nuevo ciclo de ADM.
Conclusión
Contar con y conocer un proceso bien definido que nos indica paso por paso cómo se debe desarrollar la arquitectura empresarial es indispensable para un buen arquitecto. De otra forma no existe un consenso respecto a los documentos y diagramas que se deben tener para definir la arquitectura de un sistema de software. Sin embargo el ADM, como cualquier modelo de procesos, debe adoptarse gradualmente, sin intentar implementarlo de inmediato al 100% y en todos los proyectos
- Log in to post comments