Buena gente,

Queríamos compartirles un par de fotos del evento del día de la fecha que tuvimos en UADE!

Fue una muy linda experiencia para nosotros, donde pudimos mostrar nuestro proyecto y recibir feedback! Además, fue un adelanto del Codecamp 2011!

Bueno, como les prometí, la nueva propuesta de UnC para el presente año!

A grandes rasgos, el objetivo del proyecto es:

Combinar tecnologías existentes, proyectos de investigación y novedades del .Net Framework 4.0 para desarrollar una nueva forma de escribir aplicaciones.

Pasaremos entonces a explicar punto por punto, de que se trata esta idea:

• Combinar Tecnologías Existentes: Utilizaremos conceptos como Deep Zoom, Windows Presentation Foundation y Domain Driven Design como base para nuestro desarrollo.

• Proyectos de Investigacion actuales: Dos proyectos, de distintas fuentes han sido relevados y estudiados en profundidad para tomar como base conceptual en este nuevo desarrallo. Como una imagen vale más que mil palabras y un video contiene aproximadamente 30 imagenes por segundo, decidimos utilizar 2 videos (casi 100 millones de palabras :P) que explican estos proyectos. A su vez, y para los interesados, incluímos los links con paginas oficiales y documentación.
• Microsoft Research CodeCanvas
• Video: http://www.youtube.com/watch?v=zXc9xxfRb8k
• Sitio Oficial:http://research.microsoft.com/en-us/projects/codecanvas/
• Documentación:http://research.microsoft.com/pubs/121031/CodeCanvas-ICSE10-NIER.pdf
• Richard Pawson: Naked Objects
• Video: http://www.nakedobjects.net/video/creating_a_new_application.shtml
• Sitio Oficial:http://nakedobjects.org/
• Documentación:http://nakedobjects.org/Pawson-Naked-Objects-thesis.pdf

• Novedades del Framework 4:  Como Entity Framework, MVC 2, Extensiones en Visual Studio 2010, DLR, PEX and Moles, nuevas características de C# y las nuevas Plantillas serán utilizadas en el proceso de investigación y desarrollo.

En resumen, la idea propuesta sera la implementación de un framework similar al citado Naked Objects, para .Net pero que a diferencia de los implementados en la actualidad, represente su interfaz a través de Deep Zoom, permitiendo una experiencia de usuario rica y fluída.

En futuras entregas: El primer prototipo de la interfaz en Sketchflow y mas detalles sobre el desarrollo de este proyecto!

Saludos!

Ignacio Raffa.

En esta segunda entrega, dividida en partes, veremos Que es un Verdadero Arquitecto de Software, que conocimiento deberíamos poseer como tales y por último cual es el camino que nos llevará a ese objetivo.

¿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.

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?

1.¿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.

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.

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

Es todo por hoy, en la próxima entrega veremos:

• Que es Un Arquitecto de Software
• Que conocimientos debería poseer
• Como es el camino hacia convertirnos en uno.

Saludos desde Argentina!

Ignacio Raffa

La Arquitectura de Software es probablemente el tópico más difícil de definir en el mundo del desarrollo actual. Mi idea es presentar, en entregas semanales, un curso introductorio a la Arquitectura de Software (en particular la Arquitectura de Aplicaciones y Soluciones) en este mismo blog, contando mi experiencia a través de casi 7 años de estudio en la materia.

Los objetivos de este pequeño “curso” serán entonces:

• Conocer Que es la Arquitectura de Software (y que NO ES)
• Poder diferenciar los distintos Tipos de Arquitectos
• Reconocer su aplicación en el mundo del Desarrollo
• Aprender que se necesita para ser un verdadero Arquitecto de Software
• Compartir material de lectura, y coordinar grupos de estudio.

Si el tiempo me lo permite, quisiera coordinar también (cada dos semanas) una sesión en vivo a través de Live Meeting y profundizar con los interesados estos temas, y otros que surjan durante el curso.

Un Saludo!

Ignacio Raffa (Argentina)

UADE net CELL – Arquitectos de Software de América Latina (ASL A)