Enterprise Architecture Training - Día 3

Este día, el tema con el que nos deleito Mike fue Arquitectura de aplicación y tecnológica.
Sigue un resumen de lo que vimos:
Arquitectura vs Estilos Arquitectónicos
Una arquitectura
Abarca las decisiones significantes acerca de:

• La organización de los sistemas
• La selección de los elementos estructurales que forman un sistema y sus interfaces, junto con el comportamiento que especifica la colaboración entre estos componentes
• La composición de estos elementos dentro de sistemas prograsivamente grandes
• Los estilos arquitectonicos que guían esta organización, estos elementos y sus interfaces, sus colaboraciones, y su composición.
  

Un estilo arquitectónico

• Es un conjunto de principios, elementos, patrones, y restricciones diseñadas para llegar a un conjunto de requerimientos específicos, dentro de un alcance especifico
• Un estilo puede ser pensado como un conjunto de restricciones sobre una arquitectura - restricciones sobre los tipos de componentes y sus patrones de interacción - y estas restricciones definen un conjunto o familias de arquitecturas que las satisfacen.
• Proveen las "reglas de compromiso" a cumplir cuando se realiza una arquitectura.

Ejemplos de estilos arquitectonicos
Dió algunos ejemplos de estilos arquitectónicos, como:

• cliente servidor,
  
• 3-tier,
  
• n-tier,
• Message Queue (un punto importante aca fue su aclaración de que JMS no es un estandar, sino que un API). Respuesta a una discusión que tenemos muchas veces :)
• MOM
• SOA (en detalle en el día 4)

Colaboración
Definió a la colaboración como: "El proceso recursivo en el que dos o mas personas o empresas trabajan juntas para alcanzar un conjunto de objetivos mediante compartir conocimiento, aprendizaje, y creando consenso"

La arquitectura básica de colaboración esta compuesta por:

• Elementos de colaboración: Herramientas que facilitan utilizan facilidades de comunicación para dar soporte a la colaboración. Ejemplo: Manejo de Documentos, Wiki, blogs, Redes Sociales.
• Elementos de comunicación: Dan soporte a los elementos de colaboración, y se realizar sobre capacidades otorgadas por elementos de infraestructura. Ejemplos: Instant Message, Mail, Voice Mail, Video.
• Elementos de infraestructura: Otorga facilidades básicas a los elementos de comunicación. Ejemplos: Redes, Mobilidad, Presencia, Identidad, Seguridad, Politicas

Patrones
Muy buena forma de demostrar para que sirve un patrón:
Supongamos que somos un jugador de ajedrez, queriendo convertirse en un maestro:

• Primero, debemos aprender las reglas del juego, nombre de las piezas, movimientos legales, etc.
• Luego, aprendemos los principios del juego: Valor de ciertas piezas, valor de ciertos cuadrados centrales, poder de un ataque, etc.
• Finalmente, aprenden los distintos estilos de juego - las tretas y estrategias que utilizaron los pasados maestros
• En otras palabras, se aprenden los patrones desarrollados y usados por los maestros

Haciendo la analogía con el software:

• Primero uno aprende las reglas. Los algoritmos, estructuras de datos, y los lenguajes de programación. Podemos escribir programas, pero dificilmente serán buenos
• Después, uno aprende los principios del diseño de software. Programación estructurada, programación modular, oop. Aprendemos la importancia de la cohesión y acoplamiento, el ocultamiento de la información y el manejo de la dependencia.
• Pero no podremos decir que somos buenos programando, sin antes estudiar los diseños o soluciones de los maestros. Estas soluciones, o patrones, deben ser entendidos, memorizados, e interiorizados, para aplicarlos de manera natural.

Buenas prácticas

• Un buen software es escrito adheriendo a los principios fundamentales: encapsulamiento, interfaces bien definidas - no solo se aplica a web services, se aclara-, estándares, bajo acoplamiento, alta cohesión.
• Los patrones permiten utilizar la sabiduría de otros para incrementar el recurso mas valioso que tenemos en el desarrollo: tiempo

Tipos de patrones

• Patrones de negocio: Identifica la interacción enre los usuarios, el negocio, y los datos. Se usan para crear aplicaciones de negocios simples. Ej: Self-service, collaboration
• Patrones arquitecturales: Expresa la organización estructural fundamental de los sistemas, dando sus principales subsistemas, y la relación entre estos. Ej: Layers, Proactor, MicroKernel
• Patrones de análisis: Describe la estructura y workflow de sistemas y aplicaciones in dominios específicos. Ej: Party, Contract
• Patrones de diseño: Captura los roles estáticos y dinámicos y las relaciones entre componentes que solucionan problemas que ocurren repetidamente. Ej: Active Object, Bridge.
• Idiomas: Describe estilos y convenciones para un lenguaje en particular. Ej: Scoped locking

Arquitectura aplicativa
Describe como se deben crear las aplicaciones. Incluye:

• Como utilizar la arquitectura técnica
• Elementos fundamentales de producción
• Patrones de construcción comunes
• Modelo de usuario
• Frameworks de aplicación
• Como configurar y manejar aplicaciones

Arquitectura conceptual
Este tipo de arquitectura pone al proyecto en un contexto: Contexto de la empresa, LOB, o tecnológico.
Muestra los datos fundamentales acerca de la arquitectura del proyecto (principales componentes, interacción entre estos), y la integración del sistemas con otros componentes o sistemas externos.
Define los conceptos, no técnicas.

Arquitectura técnica
Define la forma en que se debe organizar y administrar el hardware donde corren las aplicaciones, y de que forma se deben administrar, monitorear, e implementar las aplicaciones en estos entornos, para poder llegar a cumplir con los requerimientos de la arquitectura aplicativa, sin desperdiciar recursos.
Se ocupan de los atributos de calidad de performance, disponibilidad, capacidad. Es importante hacer un capacity planning, para lo que es necesario que tengan relación o conocimiento de la arquitectura de negocio.

Esto es todo por hoy. Falta la ultima clase, SOA...