Arquitectura de Sistemas

M.B.A. Ing. Luis H. Vidal V.

lvidal@uach.cl

Aprendizajes/Desempeños esperados

• 1.1 Comprende el concepto de Arquitectura de Sistemas e identifica los principales conceptos asociados.

• La mayor parte de las empresas modernas comienzan asubdividir las antiguas unidades de sistemas en dos gruposde trabajo bien diferenciados: (a) aquellos que se encargande la infraestructura y (b) los que comienzan a denominarsearquitectos de sistemas.

Introducción

Introducción

(a) aquellos que se encargan de la infraestructura.

Introducción

(b) los que comienzan a denominarse arquitectos de sistemas.

¿Qué entendemos por arquitectura en relación a un proyecto informático?

• Entendemos por arquitectura en un proyecto informático ala disposición conjunta y ordenada de elementos software yhardware para cumplir una determinada función.

• No es difícil de comprender que si mezclamos arquitecturasdistintas e inconsistentes sin ningún tipo de orden oplanificación el proyecto se puede convertir fácilmente eningobernable, tanto o más cuanto mayor sea la envergaduradel mismo.

Introducción.

• La mayoría de las organizaciones suelen favorecer (de formaplanificada o no) unas configuraciones concretas.

• La arquitectura de cada empresa debería describir estasconfiguraciones y el entorno que facilite crear nuevasfuncionalidades que encajen en ella, incluyendo directivas,componentes de software reutilizables, herramientas, etc.

Introducción

• Para facilitar que las nuevas funcionalidades de que dotemosa nuestra arquitectura sean consistentes con el sistemaactual y las posibles modificaciones futuras de este,necesitamos conocer dicha arquitectura, pero es mucho masimportante conocer la arquitectura operativa yorganizacional de la empresa.

Introducción

• Una distinción importante es la que existe entre laarquitectura de una simple aplicación (micro arquitectura)y la que existe entre y a través de las distintas aplicaciones(macro arquitectura).

• No hace falta decir que esta última es la mas compleja eimportante.

Introducción

Preguntas del capítulo

• En relación a sus sistemas tecnológicos (arquitecturas), ¿cómo se divide el trabajo en la mayoría de la empresas modernas?.

• ¿Qué entendemos por arquitectura en relación a un proyecto informático?

• Indique al menos 3 ejemplos de configuraciones concretas que empresas empleen en sus desarrollos tecnológicos.

• Describa un ejemplo de directiva de desarrollo de software empleada en empresas.

• Indique diferencias entre microarquitectura y macroarquitectura, contextualice con un ejemplo.

¿Cuál es el papel de la arquitectura en una organización?

• Imaginemos que nuestra organización consta de cuatrocapas.

I. La capa superior está formada por las actividades propias de laorganización en si misma.

II. Debajo se encontrarían las aplicaciones informáticas quesoportan y facilitan esas actividades.

III. Por debajo de las aplicaciones se encuentra la arquitectura quefacilita que estas se desarrollen y ejecuten.

IV. En último lugar, yace la infraestructura como el hardware o lasredes físicas.

La arquitectura en una organización.

• Esta subdivisión en cuatro capas nos facilita determinar elpapel que desempeña la arquitectura dentro de unaorganización.

• Cada capa actúa como cliente de la capa inferior a ella ycomo servidor de la capa superior.

• Los arquitectos no deberían malgastar su tiempo en temasrelacionados con la infraestructura, tales como el sistemaoperativo o los dispositivos de interconexión de redes.

La arquitectura en una organización.

• La mejor forma de separar la arquitectura de lainfraestructura es tener en mente el esquema de cuatrocapas antes mencionado: la infraestructura debe de darsoporte a la arquitectura.

• Mezclar erróneamente conceptos de una y otra capa es unerror muy común en muchas organizaciones.

La arquitectura en una organización.

• Un error en el que no debe de caer un arquitecto desistemas es ser demasiado preceptivo.

• Introducir demasiadas normas que creen una excesivarigidez provocará problemas en el desarrollo de aplicaciones.

La arquitectura en una organización.

• Un buen arquitecto de sistemas debe de tener siempre enmente que su principal finalidad es permitir la creación deaplicaciones, facilitando la creatividad y la innovación de loscreadores de las mismas.

La arquitectura en una organización.

• La arquitectura de sistemas en los tiempos en los que sóloexistían los mainframes era muy sencilla: existía un lugarpara cada cosa y cada cosa tenía su lugar adecuado.

• Con el paso de los años y siempre en busca de una mayorflexibilidad se han ido introduciendo estructuras cada vezmas y mas complejas: arquitectura cliente / servidor,arquitectura a tres capas, data warehouses, objetosdistribuidos, arquitecturas webs y más.

La arquitectura en una organización.

• Un buen arquitecto debería de empezar por recordar que sutrabajo es hacer la vida mas fácil a los desarrolladores, y noal revés...

La arquitectura en una organización.

• Existe otra idea que subyace tras todos los enfoques, laespecialización: dividir los problemas en sus partesconstituyentes y resolverlas separadamente con equipos deespecialistas centrados en un área única.

• La especialización deja dos puntos sin respuesta: (a) comodividir los sistemas para que puedan ser definidosseparadamente y (b) como unirlos posteriormente paraformar un todo homogéneo. Estos son los principales retosde la arquitectura de sistemas.

La arquitectura en una organización.

Preguntas del capítulo

• ¿Cuál es el papel de la arquitectura en una organización?

• Describa las 4 capas propuestas para describir la arquitectura de una organización.

• ¿Cuál es la mejor forma de separar la arquitectura de la infraestructura en una organización?.

• ¿Qué significa y que efectos conlleva que un arquitecto de sistemas sea demasiado preceptivo?.

• ¿Cuáles son los principales retos de la arquitectura de sistemas?.

Pero, y desde el punto de vista de la empresa u organización ¿qué características debería de

reunir la arquitectura de sistemas?

• Si la mejora en los procesos y aplicaciones redunda en un mejor rendimiento de la empresa, y si para mejorar las aplicaciones necesitamos mejorar los sistemas, entonces la arquitectura de sistemas debería de ser el vehículo de desarrollo de ambos.

• En la práctica la arquitectura de los sistemas actuales constituyen, en muchos casos, grandes obstáculos para los dos.

Arquitectura Evolutiva

• A principios de los años 90, la arquitectura de sistemas noiba mas allá de una mera planificación.

• Definimos una arquitectura objetivo e ideamos unaestrategia y una planificación para completarla dentro deunos determinados plazos de tiempo.

Arquitectura Evolutiva

• La principal ventaja de este enfoque es que la hacecomprensible a los ejecutivos, pues es similar a la forma enque tienen en dirigir sus negocios.

• El principal inconveniente es que no funciona. Comienzadefiniendo una arquitectura objetivo y esto es un error.

Arquitectura Evolutiva

• El único objetivo que debe de tener en mente el arquitectode sistemas es el de la organización para la que trabaja, si notarde o temprano entrara en conflicto con el.

• La arquitectura del sistema debe de ser lo suficientementeflexible como para acomodarse a los cambios de objetivos dela organización. Esta es la clave principal para asegurar sulongevidad.

Arquitectura Evolutiva

• La segunda clave a tener en cuenta es la que nosproporciona la mejor forma de medir la bondad de unaarquitectura: la forma en que sustenta a las aplicaciones quesustentan a la organización.

• La mejor forma de verlo es estudiar, dada una nuevafuncionalidad necesaria para nuestra empresa, como laarquitectura del sistema facilita su desarrollo e integracióncon el resto de las aplicaciones.

Arquitectura Evolutiva

• Los elementos claves que debe de cumplir nuestraarquitectura para facilitar el desarrollo de nuevasaplicaciones son: (a)tener unas directivas claramentedefinidas pero no rígidas en exceso ni dictatoriales en cuantoal uso de determinadas tecnologías o fabricantes,(b)favorecer el uso de aplicaciones que posean unafuncionalidad base y sean personalizables por el usuario y(c)facilitar el uso y desarrollo de componentes y plug-ins yaplicaciones que los admiten.

Arquitectura Evolutiva

• Este enfoque nos permite en la mayoría de los casosencontrar la forma mas rápida y sencilla de desarrollar unanueva funcionalidad para nuestro sistema en los casos en losque lo mas importante es tener una aplicación que nos hagalo que queremos y no tener la mejor aplicación que haga loque queremos.

• Hoy en día, en la práctica, esta es la solución quenecesitamos en la mayoría de los casos. Estos son losprincipios del enfoque que se conoce como evolutivo.

Arquitectura Evolutiva

• El modelo evolutivo, en el cual la arquitectura del sistema vaadaptándose paso a paso, cada uno de ellos basado en losanteriores y siendo el mejor de todos los posibles quepodemos dar en cada momento y no siguiendo un planmaestro tiene un poderoso antecedente, este es la evoluciónnatural. Esta posee dos elementos cruciales: (a)un métodode producir variantes (la reproducción) y (b)un método deelegir la mejor entre estas (la supervivencia de los masfuertes).

Arquitectura Evolutiva

• Los métodos evolutivos son también muy populares en eldesarrollo de software a medida, debido principalmente aque las aplicaciones suelen construirse mediante una seriede pasos consecutivos y no de una sola vez, reduciendo asíconsiderablemente el riesgo de fallos y el costo dedesarrollo.

• Estrictamente hablando, en este caso el termino evoluciónno está bien usado puesto que no existe ni variación niselección. Un termino mas adecuado sería desarrolloincremental.

Arquitectura Evolutiva

• Al igual que en la evolución natural, las variantes en elmundo de la informática son abundantes y sólo los sistemasmas abiertos sobreviven.

• Es fundamental crear un entorno que propicie la tecno-diversidad en la arquitectura de sistemas.

Arquitectura Evolutiva

• Una excepción a esta teoría la constituyen, en si mismos, losmainframes, los cuales han resistido mas de lo que se podíaesperar a pesar, incluso, de la epidemia del año 2000.

• El problema es como crear un entorno que faciliten la tecno-diversidad, donde las arquitecturas preestablecidassobrevivan donde sea necesario pero sin bloquear el paso delos nuevos esquemas.

Arquitectura Evolutiva

Preguntas del capítulo

• Cómo se trataba la arquitectura de sistemas en los años 90 y cuál era suprincipal error.

• Cuál es el objetivo de tener una arquitectura de sistemas flexible.

• Cuál es la mejor forma de medir la bondad de una arquitectura.

• Identifique los elementos claves que debe de cumplir una arquitecturapara facilitar el desarrollo de nuevas aplicaciones.

• Cuales son los principios del enfoque evolutivo (en relación a laarquitectura de sistemas).

• Describa un ejemplo de tecno-diversidad y su impacto en unaorganización.

• Indique la diferencia entre desarrollo evolutivo y desarrollo incremental.

Las organizaciones con arquitecturas evolutivas poseen ciertos rasgos en común:

Arquitectura Evolutiva – Características.

(1) Prefieren las directivas a los estándares. Los estándaresreales son minimalistas y usualmente ‘de hecho’ comoWindows.

• Las directivas pueden pasarse por alto si existe una razón losuficientemente buena.

Arquitectura Evolutiva – Características.

• La mayoría de las organizaciones mantienen demasiadosestándares motivados por la reducción de costos (porejemplo, mantienen UNIX en el back-end para minimizar elcosto de reeducación) pero fallan al ignorar el costo quesupone forzar a determinadas aplicaciones que necesitanrealmente tomar una línea diferente.

• La flexibilidad es una necesidad fundamental en laarquitectura de los sistemas modernos.

Arquitectura Evolutiva – Características.

(2) Usan tecnología orientada a componentes.

• La historia de la informática describe un viaje inexorablehacia la especialización.

• Los componentes nos traen, por fin, la flexibilidad yposibilidad de reutilización del software que la orientación aobjetos nos prometía desde hace tiempo

Arquitectura Evolutiva – Características.

(3) Juzgan la arquitectura del sistema desde el punto de vista del usuario.

(4) Invierten en infraestructura. Ahorrar gastos en hardware o comunicaciones es, a menudo, un falso ahorro: un efecto de los días en que estas cosas eran caras. Ahorrar dinero ahora nos costará mucho mas dinero mas adelante.

Arquitectura Evolutiva – Características.

(5) Reflejan la arquitectura de su organización en la arquitectura del sistema.

• Por ejemplo, organizaciones centralizadas necesitan un sistema centralizado mientras que organizaciones descentralizadas se adaptan mejor a sistemas distribuidos. Esto es una directiva mas que una regla.

Arquitectura Evolutiva – Características.

(6) A la hora de elegir entre distintas aplicaciones toman comoprincipales criterios la facilidad de uso y el impacto en elnegocio.

(7) Eliminan los proyectos fallidos o débiles rápidamente. Cadapeseta invertida en un proyecto débil o fallido es un dineromalgastado dos veces: aprende la lección, evitarecriminaciones y corrige el problema.

Arquitectura Evolutiva – Características.

(8) Valoran el capital intelectual. El principal activo de undepartamento de arquitectura de sistemas son sus personas ylos procedimientos que ellos conocen o han desarrollado.

(9) Evitan innovaciones.

Arquitectura Evolutiva – Características.

• Estos puntos no pretenden ser una línea de actuación para beneficiarnos de una arquitectura evolutiva.

• Son una lista de observaciones procedente de organizaciones que manejan arquitecturas de estas características [1].

Arquitectura Evolutiva – Características.

Preguntas del capítulo

• Desarrolle un mapa mental con los 9 tipos de rasgos en común que presentan las arquitecturas evolutivas, asocie conceptos relevantes y relacione al menos un ejemplo para cada una, si algún rasgo no se vio con un ejemplo en clase, realice un proceso de búsqueda en Internet y/o bibliografía entregada como parte de la asignatura y complete su mapa.

• Dos décadas después de comenzar a andar elcamino, por fin tenemos la tecnología suficiente paracrear y ensamblar componentes que otras ramas dela ingeniería disfrutan desde hace mucho tiempo…

Próxima clase.

La Revolución de los Componentes

• Fuente:

[1] http://www.morales-vazquez.com/pdfs/arquitectura.pdf