Arquitectura de Software

aqui lo encontre  muy interesante

¿Qué es la Arquitectura de Software?

Este es quizás uno de los interrogantes más reiterados en el fuero interno de cada programador, desarrollador, líder de proyecto y hasta “pseudo-arquitecto” de Software en la actualidad.

Si bien el término se utiliza en la industria desde mediados de los años 90 (1992) y el concepto, sin ser llamado Arquitectura existía desde 1984, no fue sino hasta el año 2000 que se estandarizó (IEEE Std. 1471-2000) en la comunidad académica y profesional como lo conocemos en la actualidad.

Para evitar la simple “definición de manual” o un análisis exhaustivo de la historia de la Arquitectura de Software (AS de aquí en adelante), ensayaremos un estudio comprensivo de los términos, para entender de qué se trata el concepto general.

Visión Abstracta

La palabra Arquitectura, dentro del término de “Arquitectura de Software” denota el nivel de Abstracción de la disciplina (es decir, la capacidad de considerar un aspecto separado de los otros con los que se da en la realidad).

A diferencia de la Ingeniería de Software, que busca cubrir todo el proceso de desarrollo / ciclo de vida de un sistema, la AS busca representar todas las estructuras que componen a un sistema (incluyendo sus relaciones) y a su vez registrar todas las decisiones tomadas, respecto al Diseño Arquitectónico del mismo.

La Abstracción consiste en extraer las propiedades esenciales, o identificar los aspectos importantes, o examinar selectivamente ciertos aspectos de un problema, posponiendo o ignorando los detalles menos sustanciales, distractivos o irrelevantes

El Objetivo

El principal objetivo de la AS es proporcionar uno o varios modelos mentales (que pueden ser o no representados de forma gráfica) que permitan comprender el funcionamiento de un sistema, analizando los componentes (no necesariamente son de código) involucrados y sus relaciones.

La Definición

A efectos de este curso, tomaremos entonces una definición sencilla, que fue adoptada por Microsoft y otras empresas en el estándar antes mencionado.

La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución.

¿Qué NO ES la AS?

La Arquitectura de Software no es Diseño de Software. Si bien, existe una línea muy delgada entre los conceptos de Diseño de Software y Arquitectura de Software, es necesario establecer una diferencia fundamental entre ambas: el nivel de Abstracción.

La siguiente tabla, nos permite ver claras diferencias entre el Diseño y la Arquitectura en sí, a pesar de tener algunos puntos en común.

	Arquitectura	Diseño
Nivel de Abstracción	Alto (Componentes, Conectores)	Bajo (Clases, Módulos, Funciones)
Visión del Sistema	Macro (interacción con el entorno) Interna(organización de los componentes)	Interna, detallada (relación entre clases por ejemplo)
Áreas	Riesgos, Atributos de Calidad, Requerimientos No Funcionales, Decisiones de Diseño.	Solucionar problemas de Negocio, Requerimientos Funcionales, Complejidad del Dominio.
Documentos	Modelos Arquitectónicos, Documentación de las Decisiones, Documento de Análisis de Riesgos.	Diagramas de Clases, Diagramas de Secuencia, Otros diagramas UML.
Metodología	Proceso de Evaluación de Arquitectura, Análisis de Arquitectura, Diseño Basado en Atributos de Calidad.	Patrones de Diseño, Diseño Orientado a Objetos, Diseño Ágil, Diseño Basado en el Dominio.

2.¿Qué es un Arquitecto de Software?

El problema de la terminología

En la actualidad, existe un gran número de profesionales que, por decisión propia o bien por una simple tendencia de “moda” se dan a conocer con títulos como “Arquitecto Web” o “Arquitecto en .Net” e incluso “Arquitecto J2EE” y la lista continúa…

Podemos distinguir al menos cinco tipos de “Arquitectos de Software”:

• El “Arquitecto por Experiencia”: es una persona que luego de una gran cantidad de años trabajando, ha adquirido muchos conocimientos de un particular negocio o tecnología y decide que tiene suficiente experiencia para llamarse a sí mismo “Arquitecto”. Pero así como una enfermera no se convierte en cirujana tan solo con ejercer la enfermería durante 20 años, un desarrollador/programador/analista no se convierte en Arquitecto de Softwareúnicamente con años de experiencia.

• El “Arquitecto Certificado”: es alguien que ha conseguido una o más certificaciones (en próximas entregas hablaremos sobre cuáles son las certificaciones de AS en la actualidad) que pueden ser o no de Arquitectura, pero contienen el término “Arquitecto” o “Senior Developer” en algún lado. Esto equivale a decir, que uno logra convertirse en Cirujano luego de hacer 2 o 3 cursos sobre operaciones humanas. Como verán también es un concepto erróneo.

• El “Arquitecto por Contexto”: en muchas ocasiones, un desarrollador solo posee una extremada “Experiencia Relativa” dentro de su entorno o hábito de trabajo, y esto lo lleva a veces a auto-proclamarse como Arquitecto dentro de su empresa o grupo profesional. Siguiendo con la analogía, podemos decir que el mejor Pediatra en una hospital infantil NO es claramente un Cirujano calificado, a pesar de ser el mejor en su área, no posee los conocimientos para otra completamente distinta.

• El “Arquitecto Programador”: conocido también como el Programador que Diseña, es tal vez uno de los casos más comunes. Un Experto en algún lenguaje de programación (o tecnología) considera que es lo suficientemente capaz para resolver situaciones o proyectos y siente que su “titulo” de programador/diseñador de software no es “suficiente”, entonces decide llamarse a sí mismo “Arquitecto en XXXX” (reemplazar las XX por la tecnología favorita).

• El verdadero “Arquitecto de Software”: se caracteriza principalmente por no considerarse a sí mismo (ni mucho menos hacerse llamar) Arquitecto de Software. Conoce (y puede trabajar) con una amplia variedad de tecnologías, y nunca deja de lado la documentación “de causa” de un proyecto. Posee conocimientos tanto académicos como profesionales sobre el tema, y puede aplicar su criterio en cualquier escenario. Más adelante, en este curso, veremos las principales características de un verdadero Arquitecto de Software con más detalle.

Esta variedad lleva a una gran confusión, sobre todo para aquellos que desean iniciarse en el área y no tienen en claro cuáles son los pasos a seguir para lograr ser un Arquitecto de Software hecho y derecho. Como podemos convertirnos en Arquitectos sin un Modelo a Seguir? O peor aún, como saber cuál de todos los Modelos hay que seguir?

Si bien no existe una receta mágica para convertirnos, intentaremos definir las características principales que debe reunir un Arquitecto de Software para ser considerado como tal, sin depender de un entorno particular, certificación o tecnología específica.

Que es un verdadero Arquitecto de Software?

Luego de diferenciar correctamente los diversos “tipos de arquitectos” según la industria actual, y que consideramos, a efectos de este curso, un arquitecto real, pasaremos a comentar en detalle aquellas características que deben poseer, relacionando a su vez el mundo académico con el laboral.

Pararnos sobre Todas las Tecnologías

Poder distanciarnos de una o varias “tecnologías específicas” es uno de los principales desafíos a la hora de encarar la Arquitectura de Software de manera profesional.

Como han escrito varios autores (entre ellos, el maestro Joel Spolsky) la estrategia de las principales compañías que tienen el poder de marcar tendencia en el mundo del desarrollo es la llamada “Disparar y Avanzar” (Fire And Motion), cuyo sustento principal se basa en la premisa de liberar más productos al mercado del que éste puede recibir y no permitir así a que ninguna empresa, léase empresa de desarrollo (por mas buena que sea) llegue a seguir ese ritmo.
Los clientes buscan necesariamente la última tecnología y no suelen aceptar propuestas de trabajos nuevos con tecnologías “antiguas”, es decir que tengan más de un año o dos.
Por suerte (o por desgracia) el vértigo en el ritmo de evolución de las principales plataformas de desarrollo (Java y .Net) hace que sea muy difícil afianzar, crear y mantener Modelos Arquitectónicos con una tecnología específica, capaz de durar a modo de ejemplo 5 años.
Esto da como resultado varios “tipos” de empresas, de acuerdo a su relación con la o las tecnologías, entre los cuales podemos distinguir:

• Empresas que siguen la corriente: Son aquellas que pueden trabajar con una o varias plataformas en simultáneo. Poseen un nivel de actualización medio/bajo y por lo general un conocimiento “estable” sobre las tecnologías soportadas, en versiones hasta 2 años atrasadas. (ej. .Net Framework 2.0 / J2EE). Mantienen un nivel de estándares actualizados, pero no suelen cumplirlos en su totalidad. A su vez, suelen utilizar solo tecnologías ya estandarizadas y no en estados de prueba.

• Empresas que van contra la corriente: Aquellas empresas que se “estancan” en una tecnología (o versión específica de una tecnología) y no evolucionan con ella. Sus principales clientes pueden ser grandes corporaciones (con sistemas creados hace muchos años en alguna tecnología antigua) o bien poseen “productos” desarrollados y estables bajo dicha tecnología y no necesitan de la actualización constante (ej. Visual Basic 6 / Delphi). En relación a los estándares, suelen estar atrasados a los actuales, es decir, respetan todos los estándares de la época de la o las tecnologías en las cuales trabajan.

• Empresas de “nicho tecnológico”: Son empresas especializadas en una porción particular (a veces en un conjunto de componentes) de una tecnología. Suelen estar actualizadas siempre a la última versión de dichos módulos y hasta incluso adoptan nuevas características en pequeñas proporciones (ej. Silverlight 4 + WPF / HTML 5.0 + CSS 3.0). Suelen traspasar los estándares actuales, utilizando a veces tecnologías en estado experimental.

• Empresas “agnósticas”: Son aquellas que no dependen de una tecnología o plataforma particular. Poseen plena conciencia de la estructura del mercado (quien es cada jugador y que hace en relación a su tecnología) y su posición en el mismo. Recomienda y utiliza el conjunto de tecnologías adecuada para cada proyecto. Sobreponen los estándares a las tecnologías particulares, y fomentan la creación/uso de nuevos estándares de aceptación general.

Las bases académicas

En el mundo de la tecnología informática y sobre todo en el mundo del Desarrollo de Software, la brecha entre el plano académico (hablando estrictamente de la Educación Universitaria) y el plano laboral es de un tamaño considerable.
Por diversos motivos, entre los cuales se encuentra el avance vertiginoso de las tecnologías de desarrollo mencionado en el punto anterior, los contenidos de las universidades tampoco logran acompañar la demanda de profesionales calificados listos para insertarse al mercado laboral.
Para cubrir este vacío han surgido (y siguen surgiendo) las llamadas Certificaciones, con sus respectivos Centros de Capacitación, que tienen como objetivo enseñar y “certificar” conocimientos sobre una tecnología específica con un modelo pseudo-académico, es decir a través de instructores y expertos que son muchas veces representantes directos de las empresas.

A simple vista, la complementación entre academia y centros de capacitación puede resultar útil, pero esto no es tan así. Necesariamente un 90% de las certificaciones actuales, responden a fines económicos y se basan en algún tipo de tecnología específica.
La siguiente lista, es una pequeña muestra de las certificaciones disponibles en la actualidad y la o las empresas a las que responden.

Certificación	Tecnología	Empresa
SAP NetWeaver – ABAP Development Consultant	SAP/ABAP	SAP
CCNP | Cisco Certified Network Professional	Cisco	Cisco
MCTS: .Net Framework 3.5 ASP.NET + ADO.NET Applications	.Net	Microsoft
Oracle 11g DBA	Oracle	Oracle
Java Professional Developer	Java	Sun
Adobe Flash Creative Suite 4	Flash	Adobe
ITIL | Information Technology Library	ITIL	ITIL
Open Source & GNU/Linux Enterprise Expert	Linux	LPI (IBM, Novell y otras)
VMware vSphere 4: Install, Configure, Manage	vSphere	VMWare

Referencias de esta entrega

• El Rol de los Arquitectos de Software - Epidata Consulting. Online
• Introducción a la Arquitectura de Software – Carlos Billy Reynoso. Online
• Ingeniería de Software – Jorge Boria. Libro.

Nota: Las referencias bibliográficas de todo el curso se presentaran en la parte final, asi como una versión descargable del mismo en formato PDF junto con los ejemplos y aplicaciones utilizados.


En la proxima parte de esta Entrega veremos en detalle ¿Que Conocimientos deberia poseer como Arquitecto de Software?

Referencias de esta entrega

• Introducción a la Arquitectura de Software – Carlos Billy Reynoso. Online
• Ingenieria de Software, un enfóque practico, Roger Pressman. Libro
• Software Architect Bootcamp, Raphael Malveau. Libro
• Software Architecture in Practice 2nd ed, Len Bass. Libro