En  el suplemento de Tecnología del diario argentino La Nación salió esta semana una nota relacionada con el Foro de Arquitectura para la Región Cono Sur (esto es, Chile, Bolivia, Paraguay, Argentina y Uruguay) realizado en Colonia los días 14 y 15 de Junio

No se trató de una cobertura de todo el evento en realidad, sino del keynote brindado por Edu Mangarelli (el chief, el primer jefe que tuve en Microsoft -de hecho él me contrató- y quien posteriormente me relacionó con mi jefe actual) junto con Ezequiel Glinsky (mi seguro jefe si me quedaba como architect evangelist en Chile ya que Edu pasó a ser country manager de Microsoft Uruguay -yo le había empezado a decir chief por joder y resultó en serio!- y Eze tomó su lugar como gerente de Arquitectura para la región)  

El chief (Edu Mangarelli) en acción, desplegando una de sus virtudes más reconocibles: hablar en público
(Edu recibió tiempo atrás el premio a la excelencia académica por su trayectoria docente en la ORT Uruguaya).
Detrás, Ezequiel Glinsky espera atento la ocasión de demostrar lo suyo

La nota incluye un reportaje a Eduardo y Ezequiel, y está bastante bien siendo que ese suple de Tecnología en realidad está escrito para un público no experto en desarrollo de software (sino, más bien, consumidor de software). A la nota la sigue, fiel al estilo del diario de habilitar comentarios de lectores, una batahola de antimicrosoftistas alegando que, con la nota, Microsoft intenta adueñarse de la autoría de conceptos como Service-Oriented Architecture (SOA), que omite dar cabida al Software Libre, que quiere monopolizarlo todo, que le pagó al diario por el espacio de publicidad disfrazada de artículo, etc

En fin, palo porque bogas, palo porque no bogas. Me acuerdo de clientes que visitaba y me decían "el otro día en el diario salió una nota del nuevo iXxxx de la empresa Axxle. Cuándo Microsoft va a tener algo así?". Pero cuando, como en esta nota, Microsoft sale en los diarios teniendo algo, resulta que es porque robó ideas, garpó el espacio, etc

Y, como siempre, no faltó la acusación principal que se le hace al gigante del software: pretender percibir dinero a cambio del software que desarrolla. Sólo quiero decir a aquellos que, para levantar el índice acusador, deben demostrar antes que ellos no perciben salario alguno por el trabajo que realicen (si no somos todos piolas )

 Bueno  estimados, esto va llegando a su fin. A aquellos que hayan venido leyendo la serie desde la Jornada Inaugural (o incluso el Preludio) les quiero dar las infinitas gracias de tener tanto interés y paciencia en seguir mi prosa verborrágica no excenta de detalles innecesarios cuando no inoportunos

El día, en lo que al track de Arquitectura se refiere, lo abrieron el consultor de Microsoft Jezz Santos y el finlandés Edward Bakker con una sesión acerca del estado del arte en Software Factories (término acuñado por el arquitecto Jack Greenfield que hace referencia a herramientas extensibles para generar código en lenguajes genéricos como C#, Visual Basic .NET, Java o cualquier otro, mediante Lenguajes Específicos de Dominio -Domain-Specific Languages o DSLs- y/o herramientas gráficas). Algo ya había comentado al respecto en la 2da Jornada
En la sesión, Santos y Bakker contrastaron la definición original de Greenfield, respecto de lo que una Software Factory es, con la definición más ajustada a Visual Studio que el comité de Patterns and Practices elaboró ultimamente. La razón de este giro se debe a que Greenfield enunció su definición allá por el año 2004, como una visión de lo que Visual Studio o lo que se usase para desarrollar software debía brindar para acelerar el proceso y liberarlo de complejidad. En cambio, Patterns and Practices ha venido trabajando desde la liberación de Visual Studio 2005 (esto es, desde Noviembre de dicho año) en la creación de software factories específicas para aplicaciones web, servicios web, aplicaciones de escritorio y aplicaciones móviles. Por consiguiente la definición de P&P está actualizada a términos concretos que Visual Studio hoy permite poner en práctica (lo de Greenfield era algo más abstracto). Veamoslas

"Una Fábrica de Software es una línea de montaje (de software) que configura herramientas extensibles, procesos y contenidos usando una plantilla de fábrica de software basada en un esquema de fábrica de software para automatizar el desarrollo y mantenimiento de las variantes de un producto arquetípico mediante la adaptación, ensamblado y configuración de componentes basados en frameworks"
(Jack Greenfield, Keith Short, "Software Factories:
Ensamblando Aplicaciones con Patrones, Modelos,
Frameworks y Herramientas", John Wiley & Sons, 2004)

"Una Fábrica de Software es una colección estructurada de elementos de software relacionados. Cuando una fábrica de software es instalada en un entorno de desarrollo, ayuda a los arquitectos y a los desarrolladores -en una forma predecible y eficiente- a crear instancias de tipos específicos de aplicaciones con una alta calidad"
(Equipo de Patterns & Practices de Microsoft)

Como se puede apreciar, la segunda definición sugiere la idea de lo que podemos encontrar en las Software Factories hoy: casos concretos para desarrollar aplicaciones de escritorio, servicios web, aplicaciones móviles y aplicaciones web. Hace poquito contaba que estos ejemplos concretos de fábricas de software sirven para lograr, con pocas horas/hombre involucradas, resultados impensables si ellas no fueran utilizadas. Esto no quiere decir que sea imposible desarrollar esos tipos de aplicaciones con Windows Forms/Windows Presentation Foundation (WPF), ASMX/Web Services Enhancements (WSE)/Windows Communications Foundation (WCF), .NET Compact Framework y ASP.NET/ASP.NET AJAX respectivamente. Sólo que, para lograr resultados de la robustez que las software factories son capaces de brindar, hacerlo a manopla toma más tiempo

Como contrapartida, el aprender a dominar estas software factories (sus wizards, entender los assets que despliegan, etc) lleva su tiempo. El que se toma ese tiempo y las domina, golazo. Pero el que tiene que empezar un proyecto con plazos acotados, no quisiera comprometerme con lo que voy a decir pero quizás sea más útil ir derecho con lo que se sabía del framework .NET. En cambio, hacer la inversión de aprenderlas como parte de una estrategia a largo plazo de desarrollo de aplicaciones empresariales, vale sobradamente la pena

Volvamos a Santos y Bakker, a su presentación. La misma no estaba enfocada en las, hasta ahora, cuatro fábricas de software de Patterns & Practices sino que iba hacia algo más ambicioso: qué se necesita y qué hay que tener en cuenta para construir tu propia software factory! Hace pocos días yo establecía la distinción entre software factories horizontales: aquellas que sirven para robustecer el desarrollo de aplicaciones varios dominios específicos (por ejemplo, banca, manufacturas, entretenimientos, etc). Pero yo los otros días ponía un ejemplo de un lenguaje específico del dominio de la Odontología. En dicho lenguaje las comandos primitivos tenían que ver con PACIENTE, DIENTE, COBERTURA (médica), etc. De modo que los programadores en ese lenguaje ni piensen en ADO.NET, en WPF, etc, sino que se concentren en el dominio de la aplicación odontológica que hay que crear. Tener una fábrica de software que nos habilite esto implicaría tener una fábrica de software vertical, ya que no serviría para otros dominios (como banca, seguros, comercio, defensa, etc) que el de la odontología

Santos y Bakker intentaron responder a la pregunta tiene sentido desarrollar ese tipo de fábricas? Y la respuesta, aunque sensata, decepcionó a más de uno (que luego lo reflejó en las encuestas): hacelo si pensás luego construir cinco o más aplicaciones basadas en esa software factory. Es decir, create una fábrica de software si pensás con ella desarrollar software a escala. La verdad? No me suena para nada descabellado ese concepto. Es más, me parece súper honesto de parte de los autores. Normalmente se hubiera esperado un "dale para adelante no más que te va a ir fenómeno. Vos haceme caso y usá esto que vas a ser Gardel". En cambio, no. Primó la sensatez y en el espíritu de Santos y Bakker el mensaje fue "con esto no vas a ganar seguramente en el corto plazo"

Que es la misma historia que pasa con los frameworks y la reusabilidad, no? Si tenés que hacer en estos meses una aplicación, y querés construir un framework para reusar componentes y alivianar así el desarrollo grueso, dale que va. Pero ponele una expectativa correcta a ese framework, para saber asimismo cuánta energía deberías invertir en él: es para reusar componentes en esa misma aplicación? O, en cambio, es para reusar componentes incluso en una futura aplicación? En este último caso, tu framework ya pasaría a ser parte de una estrategia a escala. Por supuesto que, sea nada más que para la aplicación inicial para la que es construido o para el futuro, ambas alternativas son válidas. Pero no hay que dejar de tener en cuenta que si es para una sola aplicación, el retorno de la inversión de dicho framework va a ser menor y por lo tanto la inversión en sí no debería ser excesiva (quiero decir, que hacer el framework no te vaya a terminar costando lo mismo o incluso más que haber hecho el proyecto sin él)

Bakker y Santos están hablando de esto mismo, de una manera muy honesta y abierta. Del mismo modo, agregan, es menester contar con un entendimiento acabadísimo del dominio para el cual se está por hacer la fábrica de software, y fundamentalmente contar con la gente adecuada, esto es, que tenga el perfil necesario para desarrollarla. Por último, hace falta tiempo!

Al respecto de esto último ellos sugieren que desarrollar la software factory demanda entre dos y tres veces el tiempo que demandaría generar una instancia del producto que la software factory construye. Es decir, por ejemplo, si tomásemos esto al pie de la letra, quiere decir que desarrollar la Mobile Software Factory demandó entre dos y tres veces lo que hubiera llevado construir una ventana de aplicación móvil como la que esta fábrica de software produce. El retorno de la inversión (return of investment o ROI) llega al construir la tercera o quinta ventana de aplicación móvil con esta facilidad (ellos dicen que lo mismo valdría para cualquier software factory que te construyas. Es decir, si te construís una software factory que produce elementos XYZ, al generar el tercer, cuarto o quinto elemento XYZ con la software factory estarías recuperando la guita que te costó hacer tanto esa software factory como los tres a cinco XYZ que ya lograste generar). Ojo al piojo, pues

Una conclusión personal, no es que la hayan dicho Santos y Bakker sino que yo la digo, es que crear fábricas de software puede ser adecuadísimo para empresas cuyo core business (negocio principal) es desarrollar software. Es decir, empresas que comercializan software, empresas cuyos ingresos se basan en la venta de software. Como construir ese software tiene un costo, y las software factories en el largo plazo alivianan ese costo, suena razonable crear fábricas de software para mejorar las utilidades. En cambio, siempre en mi opinión personal (esto no fue ni insinuado por los autores), si la empresa se dedica a un rubro diferente (es una compañía de seguros, etc)... construir su propia fábrica de software puede ser algo realmente costoso. Por supuesto que, yendo al caso concreto, habría que cuantificar esto que digo y ver si vale la pena o no

Bueno, nuevamente volviendo a la sesión de estos dos amigos, destacaron las herramientas que existen hoy para generar fábricas de software. Acá entramos en una maraña de acrónimos (GAX, GAT, DSL, SDM, etc) que se han ido sedimentanto con el tiempo cuan capas geológicas unas sobre otras, y que aunque te parezca que sos el único que no sabe el por qué o para qué de cada una yo te aseguro que son varios los carlitos que las andan repitiendo todo el tiempo sin saber para qué catzo sirven. Yo traté de hacer un poco de geología acá, y llegué a la conclusión de que

• Un Guidance Package (o Paquete de Guías) es un conjunto de plantillas (de lo que quieras: de un XML, de una ventana Windows, de un componente, ..., es cualquier cosa no terminada pero que sirve de molde para que la termines como te quede mejor), asistentes (wizards, ventanas que te permiten, a través de pestañas secuenciales llenar un formulario con info que te va a crear cosas a medida -cosas tales como archivos XML, ventanas, componentes, etc) y recetas (es decir, un chm u hipertexto equivalente con info piola como how-to's, consideraciones de plataforma y otras recomendaciones). Las fábricas de software se implementan, por lo tanto, con estos paquetes de guías. Entendiendo esto creo que no te va a costar nada ahora entender lo que sigue
• Guidance Automation Extensions (Extensiones de Automatización de Guías o GAX) es un entorno de ejecución (runtime environment) de Guidance Packages para Visual Studio 2005. En otras palabras, lo vas a necesitar desde el vamos sea que quieras ejecutar una fábrica de software de algún tercero, como las de Patterns & Practices o que quieras ejecutar la tuya propia
• Guidance Automation Toolkit (Set de Herramientas de Automatización de Guías, o GAT) es una paquete de guías para construir, a su vez, paquetes de guías que implementen Fábricas de Software. No es un requisito instalar GAT para ejecutar una software factory, aunque sí GAX
• Domain-Specific Language (Lenguaje Específico de Dominio o DSL) es un concepto general que hace referencia a un lenguaje diferente a los lenguajes de propósito general como C# o Visual Basic. El dominio, como decía en el caso de las fábricas de software verticales, puede ser un tipo de industria dado, el reglamento de un juego de aventuras o de autos, fútbol, etc, un editor musical, lo que se nos ocurra. Hasta acá, no hay nada que sea inherente a Microsoft: el concepto de DSL anduvo dando vueltas allá afuera rato ha
• Domain-Specific Language Tools (Herramientas para Lenguajes Específicos de Dominio) es un conjunto de utilidades disponibles dentro del SDK de Visual Studio que permiten implementar DSLs en una forma muy potente:
  • Mediante un diseñador gráfico es posible definir modelos de dominio
  • Mediante un archivo de configuración XML se puede definir un diseñador gráfico que va a permitir modelar visualmente elementos que la fábrica de software deba construir, del mismo modo que el editor de clases actual de Visual Studio permite crear el esqueleto de clases, o el editor de workflows de Windows Workflow Foundation (WF) permite crear flujos
  • Mediante plantillas de texto se puede instruir a Visual Studio para que convierta la definición gráfica (basada en el modelo de dominio) a código en un lenguaje de propósito general, que finalmente se compilará para producir código ejecutable
  • Con todo esto listo, los desarrolladores ya pueden trabajar visualmente en modelos gráficos que del resto se encarga la herramienta
• Para una discusión efectiva de dónde encaja mejor GAT y donde DSL Toolkit, sugiero leer lo que Mauro Regio junto con Víctor García Aprea (de Clarius Consulting, un partner que tiene mucho que ver con la infraestructura de soporte a las fábricas de software) tienen para decir al respecto

Santos y Bakker mostraron demos de estas herramientas en acción pero admitieron que están aún a medio camino, no del todo integradas entre sí. Aún así bosquejaron cómo el proceso de creación de una Fábrica de Software debiera ser, generalizando una solución particular en una primera implementación de referencia, la cual debería servir de molde para una plantilla de solución desde la cual crear la primera versión de la fábrica, usando luego esta última para generar productos que sirvan para refinar el modelo que permita bosquejar una nueva plantilla de solución, y así seguir iterando

Los muchachos finalmente comentaron el roadmap para el futuro inmediato de las fábricas de software, y todos los esfuerzos no sólo de Microsoft sino de otros jugadores de la industria -como los argentinos de Clarius con su Software Factory Toolkit-, el VSIPFactory (una fábrica de software para crear extensiones a Visual Studio; VSIP viene de Visual Studio Industry Partners, o sea socios de la industria que crean extensiones específicas de Visual Studio), o el DSL Editor. Esto dio cierto panorama de que la forma de desarrollar fábricas de software, o al menos las herramientas que se utilizan a tal fin, se encontrarían en vías de cambio

Definitivamente, lo desalentador al respecto de las SF es ver que están de momento completamente fuera del roadmap de Visual Studio. Al menos Visual Studio 2008 (hasta hace poco conocido por "Orcas") no hace mención de incorporar nada de esto by default (hago tan temeraria afirmación en el hecho de que el white paper sobre VS 2008, aparecido a mediados de Abril, habla de LINQ, de ADO.NET vNext, etc... pero ni una sola mención de DSLs, de GAT, ni mucho menos de SF). Lo poco que se menciona oficialmente de la versión siguiente a Visual Studio 2008 (de momento conocida como "Rosario") tampoco hace mención a soporte para crear o ejecutar fábricas de software. Debo concluir que el soporte para construir fábricas de software seguirá estándo disponible por separado en la forma de extensiones? Siendo que todo esto viene dando vueltas desde el 2004, que tres años más tarde el asunto todavía siga en veremos no me da la sensación de que haya una firme decisión de ir para aquel lado. Por caso, no le tomó tanto al Updater Application Block convertirse en ClickOnce

Hay, más bien, un apoyo, pero no un encolumnamiento detrás de las fábricas de software como un paradigma estratégico. Sería un error concluir, entonces, que Microsoft le bajó el pulgar: la Enterprise Library de Patterns and Practices también ha estado dando vueltas por un tiempo largo ya y tampoco pasó a ser parte constituyente de .NET. Sin embargo, va a haber EntLib para rato y lo mismo creo que las software factories van a seguir ocupando cierto espacio en el "cosmos" de .NET

Los amigos Santos y Bakker se despidieron, luego de dar su mensaje honesto y franco de qué es lo que está pasando y qué no está pasando con las fábricas de software, dejando cierta sensación de "esto debe estar buenísimo como idea... pero viene muy verde". La misma sensación que teníamos hacia fines del 2004, cuando Andrés Aguiar nos vino a visitar a Santiago de Chile y nos brindó una sesión sobre Fábricas de Software en un Architect Forum

Personalmente creo que la pelota quedó picando claramente en la cancha de las empresas que fabrican software. Presiento que ellos, los que fabrican soft como actividad primordial, le van a sacar más jugo que nadie a estos Guidance Packages

A la salida de esta sesión comenzaba mi último tiempo en el stand del Equipo de Arquitectura. Lo más relevante que tengo para destacar fue un muchacho que me preguntó por las tecnologías para interfaz de usuario que se están viniendo, pero principalmente cierta inquietud entre ASP.NET AJAX y Silverlight, ya que ambas caen dentro del rango de las tecnologías web. Aunque parezca que la cosa pasa por optar por una u otra, en realidad son tecnologías complementarias y, llegado el caso, ambas podrían estar presentes

La fortaleza de AJAX pasa más por su habilidad de poder pegarse un pique hasta el servidor (gracias al objeto XMLHttpRequest) y traer cierto XML que luego, vía JavaScript pueda servir para actualizar partes de la página sin necesidad de cargar la página nuevamente (porque esto último no sólo consumía más ancho de banda: además introducía el compromiso de salvar cierto estado de la sesión, sea del lado del servidor -lo que podría atentar contra la escalabilidad-, sea del lado del cliente -mediante cookies que podrían no estar habilitadas- o añadiendo el estado como parte del requerimiento HTTP, que no sólo decanta en un consumo mayor de ancho de banda sino que además es un modelo de programación más complejo -aunque ASP.NET libera al desarrollador de esa plomería-). Este beneficio que AJAX trae redunda en la experiencia de usuario porque el navegador parece actuar de una manera más ágil a los requerimientos del usuario. No obstante, en términos reales, los controles que ASP.NET AJAX ofrece al desarrollador son controles que, en última instancia, se renderizan mediante el soporte básico HTML que los browsers poséen. Por lo tanto, cuando un navegador entre a un sitio desarrollado con ASP.NET AJAX, no va a requerir instalar nada adicional para poder aprovechar sus ventajas (en la medida en que su JavaScript tenga disponible XMLHttpRequest) ya que las bibliotecas de lado cliente de ASP.NET AJAX se descargarán automáticamente al estar vinculadas mediante el comando HTML <SCRIPT>

Por el lado de Silverlight, la fortaleza viene dada en sus capacidades gráficas, que exceden las que los navegadores traen por defecto (basadas en HTML). Pero, justamente, para poder ir más allá que el default cada navegador deberá instalar un plug-in que le permita expandir esas capacidades (similar al plug-in para ejecutar applets de Java o animaciones Flash). El runtime de Silverlight que se carga en el navegador tiene una mini CLR (common language runtime, el motor de ejecución de .NET) embebida, capaz de cargar ensamblados y ejecutarlos. Este dato no es menor, porque si necesitamos llamar a un servicio web podemos usar el mecanismo de proxeo que .NET habilita per se, sin necesidad de usar el XMLHttpRequest de AJAX. La tecnología de visualización que Silverlight utiliza está basada en XAML (eXtensible Application Markup Language), el mismo de Windows Presentation Foundation (WPF) que se basa en vectores y permite, especialmente, dividir labores entre diseñadores de interfaz de usuario y desarrolladores de software (que son los que van a ponerle conducta a la interfaz que los diseñadores -valga la redundancia- diseñen). También, Silverlight permite embeber multimedia en las páginas

Claramente que Silverlight puede vivir sin AJAX y no al revés. Pero como contrapartida, AJAX no necesita de ningún plug-in para correr por lo que, si no es un requisito diseñar una interfaz de usuario con características extra a las que provéen por defecto los navegadores, ASP.NET AJAX es una respuesta más que óptima. Escenarios típicos de esto son aplicaciones cuyos usuarios son externos a la organización (clientes, socios, proveedores, etc) que tal vez rechazarán instalar Silverlight sólo por correr nuestra aplicación (nada más pensá lo invadido que te sentís cuando un sitio web te dice que le habilites las cookies o le levantes la restricción de ventanas pop-up). Silverlight, en cambio, se me asemeja como más realista en escenarios de intranets y extranets cuando los usuarios son empleados de una organización y usan una infraestructura que la organización les da y administra por ellos. Hay que ver qué va a pasar si algún día Silverlight está tan desplegado como hoy lo está Adobe Flash (que a la fecha en que entré en este link, http://www.adobe.com/products/player_census/flashplayer/, indicaba que estaba en el 98.7 de los desktops)

Te voy anticipando dos problemas que ya se van empezando a sentir, tanto con AJAX como con Silverlight:

• Bookmarks: al usuario de la aplicación le da lo mismo si lo que está viendo en la ventana del browser es ASP.NET con AJAX o sin, Java Server Faces, Struts, Silverlight o lo que sea. Lo cierto es que, mientras va ejecutando la aplicación puede pasar que llega a un estado que quisiera conservar para futuras referencias. Por ejemplo: ve la leyenda "Aéreo confirmado con el código #236734GHAY29" y más allá de imprimir esa página, quiere bookmarkearla para poder volver inmediatamente a ella. Si estábamos trabajando con ASP.NET convencional, existía una manera de poder hacer que la página sea bookmarkeable mediante la adecuada generación de una URL que contenga los parámetros que siempre nos permitan volver a generar a generarla (en este caso con el código de reserva alcanzaría)
  Pero si veníamos haciendolo con AJAX o Silverlight donde la URL es la de la última página que se cargó completamente hasta que empezamos a darle al XMLHttpRequest o a Silverlight respectivamente, la cosa se va a poner más difusa para el usuario porque el bookmark lo va a hacer volver al inicio
• El botón de Volver (back button). Suponete que, sea con AJAX o con Silverlight, el usuario selecciona un barrio de una lista y la aplicación le despliega las pelis que están dando en cines de ese barrio. Suponete entonces que no hay ninguna que le interese y que quiera probar con un barrio vecino. Tiene la chance de pulsar un link en la página que dice "cargar otro barrio" pero en cambio prefiere, porque suele no fallarle y está acostumbrado, apretar el botón de volver para pasar al estado anterior donde tenía que elegir barrio y ninguna peli aún poblaba la lista. Bueno, como diría Pepe Biondi, patapúfete: va a volver a la página previa a la última página que cargo completa

No tengo ni idea sobre workarounds para estos problemas pero doy fe que proximamente los habrá en blogs, portales, etc

En el durante, y ya cerrando el evento, Jeff Loucks brindó una sesión de Infraestructura acerca de cómo hacerle tuning al servidor Small Business Server 2003 para optimizarlo para aplicaciones típicas en entornos de 25, 50 y 75 usuarios. Loucks mostró cómo simular carga al Exchange mediante LoadSim, una herramienta parametrizable que simula que los usuarios están a full con el servidor de correo; lo mismo con Microsoft Dynamics CRM 3.0. También mostró cómo DiskPar, una utilidad que realinea los sectores de un disco puede ayudar a mejorar el rendimiento general. Mostró el clásico PerfMon que permite loguear el registro de actividades (tipicamente la actividad de los discos, el uso de la memoria y la CPU, la base de datos, etc). Del mismo modo mostró como simular -siempre con el fin de calibrar el sistema- transferencias de archivos masivas en el sistema

Loucks mostró resultados de los benchmarks logrados luego de muestrear distintas configuraciones y explicó las conclusiones de los mismos

Estimadísimos, esto ha sido todo. Esta semana me sirvió una barbaridad. El contacto con los clientes sin duda alguna que es fundamental -sirve no sólo para reconocer aquellas áreas de la arquitectura de software que uno debe reforzar porque se está quedando lisa y llanamente ignorante al respecto: también sirve para cuestionarse lo que uno crée que sabe y ser capaz de juntar todo para poder elaborar nuevas conclusiones-

Al track, en sentido estricto, le fue bien. Respecto del año pasado se ha crecido no sólo en satisfacción sino también en asistencia a las sesiones. No obstante, hemos quedado lejos de otros tracks que han exhibido mejores resultados. Ahora me toca elaborar el post-mortem para determinar los puntos a mejorar en futuras ediciones (si es que me dejan seguir haciendo esto )

Abrazo y gracias por leerme!!

 El  Jueves mi día comenzó al frente de la estación de demos, donde ya las preguntas se empezaban a repetir (obvio, preguntando gente diferente, claro). La más destacable es la de un caballero que se me acercó algo preocupado ya que me decía que los modelos de arquitectura que varias sesiones muestran parecen chocar entre si, lo que le daba la idea de que no hay una única forma de parar una arquitectura, sino que contextos diferentes parecían tener enfoques particulares

Eso obviamente le generaba cierta inseguridad de tomar el camino equivocado, por lo que me preguntó "vos qué harías?" (juah! Número equivocado...)

No, fuera de broma. Lo que le respondí es lo que realmente yo empecé a hacer hace ya varios años, cuando entendí que el paradigma orientado a objetos es mejor en aplicaciones monóliticas y ya no tan bueno en aplicaciones multicapa, principalmente cuando las capas están en procesos diferentes (posiblemente de servidores físicos también diferentes)

La razón? Que al separar las capas lo que se busca es ganar cierta independencia, pudiendo mantenerlas por equipos diferentes y con ciclos de vida ocasionalmente coordinados, aunque no necesariamente (lo que permite ganar agilidad y responder más rápidamente a ciertos cambios de negocio)

En cambio, al compartir clases entre las capas (con conducta, propiedades que los caracterizan a lo largo de toda la aplicación) la cosa se empieza a salir un tanto de cauce ya que cualquier clase que se es alterada implica puede impactar en todo el resto (no necesariamente cierto aunque con gran probabilidad)

El asunto entonces pasaría por exponer servicios entre las distintas capas (suena a guitarreada pero la realidad terminó por imponer eso porque, se acepte o no, funcionó). Y mensajes deberían viajar entre las mismas, llevando objetos de transferencia de datos (data transfer objects, o DTOs), disponibles a lo largo de todo el caso de uso (quizás reusables entre unos pocos casos de uso, pero no ilusionarse con compartirlos a lo largo de toda la aplicación)

Los servicios expuestos hacia afuera, internamente son llevados a cabo por clases que modelan procesos de negocio (casos de uso, basicamente hablando)

Los mismos no deberían guardar estado, sino que trabajan sobre el estado del/los DTOs que hayan recibido en cada método (o servicio, si es que los llamaron de afuera)

El hecho de que no guarden estado habilita a escalar la granja de servidores para cada capa sin mayor impacto en el código

Es claro que el único caso en que se va a sentir impacto a ambas márgenes (capas, tiers, etc) es cuando el DTO a traficar deba llevar más datos. Pero siendo que el DTO debería estar limitado al caso de uso, eso ocurriría cuando la necesidad la tenga el caso de uso, con lo cual es más que súper razonable cambiar el mensaje de intercambio

Ese por qué no se veía tan obvio, o al menos a mí no me gustaba, cuando el cambio se produjo en un caso de uso diferente pero termina impactando en todos los casos de uso perejiles que andaban compartiendo lo innecesario

Poooorrrrrrrrrrrrrrrrrr lo menos, así, lo veo... yo. Más info al respecto he publicado alguna vez y hace tiempo acá

Después estuve charlando un poco con un MVP muy particular, Jeffrey Palermo, acerca de lo complejo que es organizar eventos y que encima estos salgan a la altura de las expectativas de quienes pagaron por asistir... y de quienes cobramos también. Jeffrey, puedo dar fe, conoce del tema. El suele organizar unas fiestas muy tradicionales hoy, conocidas como Party with Palermo. El muchacho tira la casa por la ventana sin oblar un sólo níquel ni -del mismo modo- ganar metálico alguno a cambio. Cómo hace? Llama a editorial Wrox, a Apress!, a O'Reilly, a los productores AMD, MaxStore, Microsoft, y otros. A todos les hace aportar para la causa. A cambio, claro, de espacios de publicidad y el derecho a poner algún que otro stand con promotoras, etc. Qué tul, el amigo? Yo lamentablemente me perdí la que organizó para este TechEd (ver fotos) porque fue el Domingo 3 cuando los amigos de United me tenían en el Maelström

En paralelo a todo esto, el amigo David Platt estuvo dando una presentación magistral -la que fue muy bien recibida en las encuestas- sobre la Arquitectura del Composite UI Application Block (CAB UI) y el posterior Smart Client Software Factory (SCSF) que lo incorporó como parte constituyente. La charla más que nada se enfocó a mostrar ejemplos concretos de bajo acoplamiento presentes en estas dos tecnologías sea para manejo de eventos, para la exposición de una interfaz de usuario (UI) compartida entre varias partes (conocidas como smartparts), para la disponibilidad de servicios que desde cualquier parte de la aplicación se pueden consumir y, por supuesto, para la configuración de todo lo anterior (sea vía XML, una base de datos remota, un servicio web inclusive). Cool

Entonces llegó el turno de Scott Jamison, un arquitecto de Microsoft responsable de las aplicaciones basadas en Office, que resultó la revelación del track. Las claves del éxito de Jamison estuvieron dadas en el hecho de que abordó el problema por donde se lo debe abordar: las necesidades del negocio primero. En esta ocasión, Scott mencionó la necesidad de consolidar información de distintas fuentes (de manera que SOA pague por lo que fue) de manera de poner esas conclusiones no ya a la mano de gerentes sino de empleados en general. Información fácil de atajar para reaccionar con agilidad a los ritmos del negocio
Y entonces encaró el problema como un arquitecto lo debe hacer, enunciando diversos posibles caminos y marcando de cada uno sus pros y contras. Entonces llega a uno de los puntos tabú de las aplicaciones empresariales: comprar versus construir. O "alivianar la carga y eficientizar la fuerza tecnológica para favorecer el negocio" versus "darle la chance a los empleados del área de tecnología de que hagan lo que más les gusta: contruir absolutamente todo (incluyendo las herramientas que sirven para contruir)". Jamison se volvó consistentemente por la primera opción, y destacó que la posibilidad de exponer funcionalidades desperdigadas en la forma de servicios web, habilita al consumo de los mismos desde componentes construidos para ensamblar Aplicaciones Compuestas, trazando entonces un paralelo entre las mismas y los servicios que ellas consumen
Luego mostró cómo las distintas aplicaciones que integran 2007 Office System sirven como contenedores de componentes que consuman servicios web (o XML plano) para agregar otros tipos de valores, y lo sencillo que es construir componentes para estos contenedores de la plataforma. Y así calló en la cuenta de que Sharepoint Server encaja prolijamente en una nueva capa entre la de presentación y la de negocio: la capa de Productividad. La necesidad de la misma se funda en el hecho de que una capa de negocio tal como la conocemos aborda sólo aspectos funcionales de la aplicación que la contiene. Pero si a nivel empresarial tenemos varias de estas aplicaciones, las capas de negocio de las mismas están -en el mejor de los casos- débilmente conectadas, lo que hace que los usuarios deban usar más de una aplicación para satisfacer necesidades cruzadas (a veces, aunque no frecuente, en un mismo caso de uso)
Así llegó una caracterización del Sharepoint, como plataforma escalable que permite exponer documentos como componentes que vinculan varias aplicaciones y que extender el alcance toma cortos tiempos de desarrollo ya que sólo se trata de construir puentes: no funcionalidades completas. Sharepoint provée per se no sólo administración de contenido (content management o CM) y colaboración sino también Inteligencia de negocios (business intelligence o BI) y principalmente capacidades de búsqueda (searching capabilities), entre otras características out-of-box
Jamison destacó cómo eso es aplicable en forma de patrones. De diseño, sí, pero de negocio esta vez, de manera de componer aplicaciones con piezas (funcionalidades en la forma de servicios, datos en la forma de XML, etc) que encajen en estos patrones y ofreció ejemplos claros y concretos de ello. En cada uno de ellos, al final, mostraba el clásico diagrama de arquitectura en capas (presentación, negocio, datos y ahora también productividad), mostrando cómo 2007 Office System encajaba, para en dicho patrón. Por supuesto, no eran ejemplos de Powerpoint sino que Scott tenía demos ya construidas que analizó en vivo
Al final de su sesión se dedicó a firmar ejemplares del libro "Essential Sharepoint 2007 - Delivering High-Impact Collaboration", que escribió con Mauro Cardarelli y Susan Hanley (Addison-Wesley, 2007). Aunque su sesión, por el tema que abordaba, no convocó masivamente, el público que asistió marcó en las encuestas un alto grado de satisfacción (8.29 de 9). Necesito más scottjamisons para este tipo de eventos

Entonces tocó el turno de David Clark, un arquitecto de infraestructura que, al igual que Jamison, trabaja para Microsoft (y al igual que los restantes presentadores de Microsoft, siendo Jamison la excepción que confirma la regla, no le va tan bien como a los oradores no Microsoft -algo que ya habíamos previsto al armar la agenda, privilegiando a los no Microsoft; la expectativa que se genera es diferente cuando el speaker pertenece a Microsoft, ya que deja de importar cómo se llama sino que para quién trabaja pasa a ser lo más relevante y por ende se espera algo que realmente provoque un sacudón; cuando el orador es independiente, es decir, no trabaja ni para Microsoft ni para ningun otro de los grandes jugadores, lo que menos importa es para quién trabaja-
Clark habló de Zero-Touch Provisioning (ZTP), un mecanismo para configurar desde cuentas, hasta workstations, servidores, servicios, software en general e incluso hardware (no sólo notebooks o PCs, también PDAs, impresoras, etc), con una mínima intervención humana (posiblemente nula), delegando las acciones en políticas (policies), scripting y otras facilidades otorgadas por Windows Server
El resultado neto implica una ganancia en seguridad y eficiencia (casos típicos, cuando un empleado deja la organización y hay que revocar todos los derechos de acceso a aplicaciones en múltiples sistemas, etc). Una arquitectura completa dentro de la plataforma Windows le da cabida a Biztalk Server (que va a ejecutar el workflow de actividades),  a Active Directory (donde los permisos van a quedar almacenados) a MIIS (Microsoft Identity Integration Server, cuya versión compatible con Windows Server 2008 pasará a llamarse Identity Lifecycle Manager), quien se va a encargar de interfacear con sistemas externos, a Sharepoint Services (útil para la capa de presentación integrada) y, por supuesto, a .NET (el vehículo que transforma estímulos en comandos); también habló del roadmap de ZTP, el rol que va a jugar PowerShell (el mecanismo de scripting que sustituye a Visual Basic Script), el rol de .NET 3.0, de Windows Server 2008...
En fin, me encantó a mí -personalmente hablando- la sesión, sus contenidos, sus demos, la forma en que se estructuró, sus porqués...
... pero el público le dio la espalda. La ley de Murphy para los oradores que pertenecen a Microsoft se volvió a cumplir acá
Clark explicó definiciones para novatos, mostró workflows de cierta complejidad, contó cómo todo el arco de la infraestructura Windows se tensa para lanzar la flecha del aprovisionamiento lo más lejos posible (la metáfora es mía)... Qué querés que te diga: cuando esta sesión esté disponible, vela por favor. Te va a sorprender, te va -por supuesto- a gustar, y te va a instruir de cómo tu organización puede ganar en seguridad, eficiencia y productividad en lo que a infrastructure deployment (despliegue de infraestructura: hardware y software de base) se refiere

Durante la tarde, Beat Schwegler (un arquitecto de Microsoft Suiza que manejó la agenda del track de Arquitectura para el TechEd Europe 2006 en Barcelona y logró el primer puesto! ) nos dedicó una sesión sobre cómo lograr googlear, dentro de nuestra organización, datos contenidos en nuestras aplicaciones. Una forma más de ver Inteligencia de Negocios (Business Intelligence o BI). Beat, en realidad, estableció las diferencias entre googlear en la web y googlear en la empresa. En la web cada server es un nodo (node) y un link en una página web es una conexión entre nodos, por lo que el problema de clasificar la información de la web pasa a ser un problema de matemática discreta. En la empresa, en cambio, la info está no sólo en nuestras propias aplicaciones (on shore) sino que puede estar en sistemas externos (off shore). Además, según cada quién, los usuarios buscadores no somos todos iguales: según que el que busque sea un empleado del front desk o uno del back office, la info debería agruparse y rankearse en forma diferente (y seguramente las experiencias de usuario pueden llegar a diferir de acuerdo al contexto de trabajo -usuarios en la calle con dispositivos móviles, usuarios en la oficina en un puesto fijo, etc-). Hay que lidiar no necesariamente con páginas web sino con datos que a veces están estructurados (bases de datos), semi estructurados (archivos XML) o no estructurados (documentos, mails, planillas de cálculo, etc)
Entonces, ya en el plano de las propuestas, Beat mencionó "la" plataforma para aplicaciones empresariales que habilita búsquedas libres para información no sólo en bases de datos sino también detrás de servicios web o archivos propietarios, incluyendo la posibilidad de definir señaladores (bookmarks). Mostró asimismo la arquitectura de tal plataforma (con servidores de consultas directamente accesibles por los servidores de aplicación, pero a la vez dependientes de los servidores de indexado sobre las fuentes de los datos)
Y lógico, cuando dijo el nombre de la misma, 2007 Office System, en seguida salió a atajarse del rechazo que les genera a algunos la sola mención de Sharepoint como contenedor de aplicaciones web, ya que consideran que Sharepoint provée una interfaz de usuario muy fría (y -presumen- poco configurable). Al respecto Beat mostró, y yo te invito (desafío en realidad) a que la veas vos también, la aplicación que Hed Kandi -sello discográfico inglés especializado en música house- creó sobre Sharepoint más ASP.NET webparts: http://beta.hedkandi.com/ (posta, eh? Esta versión actual maneja la multimedia en el browser todavía con Adobe Flash, pero ya se proyectan hacer uso de Silverlight en un futuro cercano). Esta aplicación, mientras tanto, hace uso de los workflows de contenido que Sharepoint habilita crear, así como también de sus mecanismos de búsqueda, sus Business Data Catalogs (BDCs, un mecanismo que permite pluguear información de fuentes externas -las que comentaba antes- de modo que Sharepoint pueda operar sobre ella), la interfaz de usuario extensible vía webparts ASP.NET, el formato de datos OpenXML y la seguridad que provée la plataforma
Beat mostró los mecanismos de indexado sobre BDCs para facilitar las posteriores búsquedas de información, y las consiguientes estrategias de llamada al búscador (sea por una URL con parámetros HTTP GET, sea por suscripción a un RSS de búsqueda -o sea, un RSS que va agregando los posibles resultados que la búsqueda arrojaría a lo largo de la vida de la suscripción-, sea mediante la invocación de un servicio web -mecanismo adecuado cuando "quien" va a buscar es un proceso y no una persona)
Mi opinión personal? Aquellos que vean la oportunidad en construir aplicaciones que habiliten búsquedas sobre su información, van a comenzar a hacer que la montaña empiece a ir sola hacia Mahoma

La jornada se cerró con Mark Pollack y Rod Johnson (project manager de la versión .NET del framework Spring y padre de dicho framework, respectivamente). En su sesión -de la cual debo admitir, yo tenía gran expectativa- comentaron acerca de lo complejo que resulta desarrollar aplicaciones sobre las plataformas básicas como Java EE o .NET, la necesidad de contar con frameworks que levanten el nivel de abstracción y habiliten montar aplicaciones sobre ellos, mediante extensiones basadas en objetos planos (esto es, no casados con ninguna API o plataforma), de modo de acelerar los tiempos de desarrollo, mejorar las condiciones para un testing unitario de cada uno de sus componentes, etc
Así destacaron las cualidades aportadas por Spring.NET, para configuración de aplicaciones (con características propias de un contenedor liviano -o lightweight container- ya que permite tomar sólo lo mínimo indispensable y nada más, no es una solución todo-o-nada ni obliga a extender APIs propias que inutilizarán la inversión si el framework un buen día es reemplazado
También, mostraron cómo Spring.NET habilita AOP (Programación Orientada a Aspectos -Aspect-Oriented Programming-), un modelo liviano de programación para acceso a datos, a servicios middleware como ser colas de mensajería, a ASP.NET e incluso a frameworks open source como NHibernate, etc
Si bien es absolutamente cierto que Spring.NET no es una mera portación del Spring de Java (un estándar de facto en dicha plataforma), quedó la sensación de que "programar en Spring .NET" si se parecía mucho al entorno de programación de Spring Java: escasa o nula integración con Visual Studio u otro IDE, con lo cual Spring.NET no se vio tan atractivo frente a otros frameworks como los que provée Patterns and Practices, integrados a Visual Studio en la forma de Sofware Factories, etc. El público reclamó por eso en el momento de las preguntas, y ante la respuesta vacilante y dubitativa de los oradores, hicieron valer cierto descontento en las evaluaciones

De ahí me fui a la festichola del evento, y a la cucha

 YAGNI,  You Ain't Gonna Need It (No es algo que vayas a necesitar). El día de hoy estuvo dominado por ese acrónimo que es una recomendación a los que desarrollan, directa o indirectamente, software para que no estén aplicando tecnologías, productos o prácticas sólo porque se convencieron de que es eso o el caos (sea porque leyeron un paper muy convincente, porque los visitó uno de estos evangelizadores de alguna empresa de tecnología, sea porque lo leyeron en el suplemento de tecnología de algún diario de circulación nacional -que, sin desmerecerlos, es como si yo me pusiera a opinar de política, del horóscopo o de espectáculos-, sea porque tienen la sensación de que tarde o temprano toda la industria va a estar aplicando eso)

YAGNI es "pará la moto". No es que lo que te estén ofreciendo no sirve o sea una chantada, sino que tenés que dimensionar realmente el problema que ese producto o tecnología viene a resolver. Y a posteriori tenés que asegurarte de que vos realmente tenés ese problema y que en tu lista de prioridades de problemas a resolver está por los primeros puestos

Es muy loco pero en la jornada de hoy, este debate apareció en forma recurrente. Vamos a los hechos

La jornada comenzó con una sesión de Christoph Schittko, arquitecto alemán actualmente trabajando en Microsoft USA (que no es Microsoft Corp sino la subsidiaria de Microsoft que atiende a los clientes del gran país del Norte). Fue una típica sesión de arquitectura en el sentido que abordó una de las actividades más amadas y odiadas a la vez por los arquitectos: tomar decisiones de diseño. En esta ocasión en particular, decisiones para combinar en la dosis justa una serie de tecnologías que Microsoft ha venido lanzando y que, a simple vista, parecen lo mismo. Esto claramente introduce confusión para los arquitectos que no entienden la jugada y a la vez temen que eso los lleve a meter la gamba al elegir incorrectamente

Las tecnologías en cuestión son el orquestador de procesos Biztalk Server, la API Windows Workflow Foundation y el servidor de espacios colaborativos Sharepoint Server, que también permite definir flujos -y para eso viene con un editor ad hoc-. Parecen iguales, pero no son, y de eso se encargó de aclarar Christoph. Mientras que Biztalk está pensado para orquestaciones formales entre procesos de distinta naturaleza (.NET y no .NET, como puede ser SAP, sistemas legados, mainframes, etc), los que a la vez requieren de monitoreos de actividad -tanto a nivel de negocio como de sistema, y cierta inteligencia de negocios asociada, Workflow Foundation se plantea como una alternativa light, mucho más flexible (o sea, sí, menos rígida) pero a la vez menos pretenciosa (chau monitoreo, conversación heterogénea -excepto que ambas puntas hablen un dialecto neutral como WS-*, algo no siempre disponible-, etc) y a la vez, con Workflow Foundation es posible que tengas que meter algo más de código. Biztalk es pesadito en ejecución, otra cosa a tener en cuenta

Por último, Sharepoint es cierto que habilita workflows, pero poco que ver con los workflows que comentaba en el párrafo anterior. Estas orquestaciones no son entre procesos sino entre personas, y por lo tanto suelen ser más flexibles (menos formales, menos determinísticas, con dedazos onda "aprobalo, aunque no sea lo usual para estos casos, porque es para el cliente Fulano que viene de parte de Mengano"). Normalmente, aunque no es mandatorio, los workflows humanos suelen girar en torno a documentos y por ende Sharepoint usa documentos como estado de la ejecución de sus instancias de workflows

Por supuesto, esto no quiere decir que las tres tecnologías se anulen entre sí sino que, incluso en un mismo caso de uso, podrían complementarse (imaginate el caso de un workflow centrado en documentos que es iniciado via Sharepoint pero a la vez dispara actividades de Workflow Foundation que terminan, en una de sus etapas, generando eventos que gatillen un workflow de Biztalk que involucre acceso a procesos de terceros -el CRM de la compañía, el sistema contable, etc-)

La siguiente sesión a cargo de Kerrie Meyler y Cameron Fuller, fue acerca de prácticas y tecnologías para monitoreo de soluciones mediante el flamante System Center Operations Manager 2007. Esto tiene mucho que ver con Modelado de Salud (Health Modeling), un post que vengo debiendo de hace rato y que es la parte de una serie en sistemas de misión crítica que abrí en enero (consistía en tres posts, pero llegué a escribir sólo el primero y vendo arrojando timeout desde entonces). Los muchachos abrieron la sesión explicando la metodología para planear la arquitectura de monitoreo. Aunque nunca te hayas dedicado a estos temas de infraestructura, te anticipo que no dista mucho de los métodos que hayas aplicado para desarrollar: una etapa de assessment (o de evaluación del escenario), un prediseño, una prueba de concepto, un plan de trabajo, un piloto, etc. Y como siempre: el negocio manda. Si no hay una necesidad de negocio detrás -como podría ser, en este caso, tener los sistemas en línea funcionando porque operar el negocio en forma manual impacta negativamente en la productividad (y por lo tanto en el revenue)- difícil que el chancho chifle

Después comentaron los componentes de System Center Operations Manager 2007, sus agentes de recolección de eventos, sus reportes, su integración con los procesos a monitorear (mediante algo llamado paquetes de administración o management packs), etc. También comentaron topologías de deployment de los servidores. Me pareció completa en cuanto a mentoring. Si no sabías nada de todo esto, creo que te llevaste algo sustancial. Pero el público enterró literalmente a los speakers de feedback negativo. La crítica generalizada fue que la presentación fue súper básica (una hora y cuarto para terminar escuchando cosas que en cualquier folleto de MOM están sobradamente destacadas)

Algo que deberé tener en cuenta si es que me vuelven a designar al frente del track de Arquitectura el año que viene (si es que sigo acá y no me rajaron antes, huelga decirlo)

Entonces nuevamente se me hizo la hora de pararme al frente del stand del Equipo de Arquitectura, y éstas fueron las inquietudes más destacadas que me plantearon quienes se acercaron:

• "Dame razones por las cuales habría que adoptar la Enterprise Library" me disparó un arquitecto -debo aclarar que comparto el stand con el comité de Patterns and Practices y la consigna con ellos es cubrirnos mutuamente si es que el otro no está presente. La Enterprise Library es de ellos en realidad
  Cuestión que acá tenemos un ejemplo de YAGNI. La Enterprise Library es un conjunto de frameworks que tienen como propósito proveer funcionalidades no presentes en la versión de la plataforma .NET a la que pertenecen, o eventualmente extender o simplificar algunas de sus APIs (por ejemplo, el Data Access Application Block significa el uso de ADO.NET)
  Hay que usarla o no? era la pregunta. Analicemos juntos tu escenario: tenés que empezar una aplicación desde 0 (cero)? Querés ahorrarte la construcción de piezas que probablemente vayas a necesitar (para caching, manejo de excepciones y/u otras funcionalidades que suelen estar presentes). Si tal es tu caso, esto te puede llegar a servir para evitarte escribir esa lógica vos (y mantenerla posteriormente, claro)
  En cambio, es posible que ya tengas una aplicación construída y también que -o bien te descargaste frameworks para evitarte hacer esta lógica vos, o bien te la terminaste escribiendo, o posiblemente un mix de ambas-. Si te está funcionando lo que hiciste, es más difícil de justificar el decir "migrate a la Enterprise Library". Todavía, aún si lo que hiciste te funciona pero no lo querés mantener a futuro, es posible que te sirva migrar para subirte a este framework que evoluciona a la par de la plataforma .NET (incluso a veces le marca el destino, como pasó con el Updater Application Block que posteriormente fue absorbido por .NET al ofrecer ClickOnce)
  De todas maneras, esto último es relativo: la Enterprise Library no necesariamente conserva la compatibilidad con versiones previas, basandose en la premisa de que trata de sacar el máximo provecho de la versión objetivo de .NET para la que está dirigida, y si eso implica renegar del pasado... arrivederci
  Pero definitivamente, una aplicación .NET que no usa la Enterprise Library es tan válida como todas las aplicaciones .NET que sí la aplican
• "Hablando del soporte de la Enterprise Library, cuál es su roadmap?" me preguntó otro asistente al evento que había estado escuchando mi speech anterior. El comité de Patterns and Practices es muy organizado en ese sentido, y dispuso en una página cuáles van a ser sus próximas entregas. Respecto de la EntLib, en mayo pasado liberaron la versión 3.1 y no habría, según dicen en esa página, nuevos releases durante el resto del año
• "Y la EntLib versión 3.0, qué agrega de novedoso respecto de la 2.0?" Lo más destacable, aunque no lo único, el Validator Application Block que (sea mediante configuración, mediante atributos o directamente en código) habilita la agregación de reglas de validación de componentes y sus propiedades; y el Policy Injection Application Block que permite, también mediante configuración o mediante atributos, interceptar llamadas a métodos para ejecutar (a priori y/o a posteriori) código adicional que podría eventualmente cambiar el curso de los acontecimientos

   
  Interceptando invocaciones mediante el Policy Injection Application Block

• "Y el soporte de la Enterprise Library? Cuál es el compromiso de Microsoft para con la misma?" (Qué buena pregunta, Mario) Es importante leer siempre el Acuerdo de Licencia de Usuario Final (End-User License Agreement o EULA), tanto de la Enterprise Library como de cualquier producto (sea comercial o de uso libre). El de la EntLib, particularmente, está haciendo click acá, y es conciso y al grano. Expresa de movida que si no estás de acuerdo en todo o en parte, que desistas de usarlo y quedamos amigos. Si lo usás, el producto se ofrece tal como es y Microsoft se deslinda de la responsabilidad. Alguna vez comenté esto en Chile y se me vino la audiencia encima diciendo que cómo podía ser, que lo de Microsoft era poco serio, irresponsable, etc. Entonces pregunté quiénes usaban Firefox de browser. Algunos levantaron la mano. Entrá acá (es el acuerdo de uso de Mozilla) y decime qué quiere decir el artículo 6. Después pregunté quiénes ejecutaban aplicaciones Java usando la JVM de Sun (entrá acá y contame, de nuevo, qué te está dando a entender Sun con su artículo 6). Lo mismo para Linux y gran parte del Open Source que goza de una muy buena -y merecida- reputación y sin embargo el buena onda que te lo está ofreciendo gratis -como en este caso Microsoft con su EntLib- no se hace cargo del uso que vayas a darle
• "Queremos migrar aplicaciones VB6 a .NET: deberíamos ir a Windows Forms o a Windows Presentation Foundation?" Otra vez YAGNI, no? Es tu necesidad de negocio la que te lleva a migrar? Es que el soporte extendido de Microsoft para con VB6 ya terminó? Qué expertise tenés en WinForms respecto de WPF? Si las aplicaciones que estás planeando están pensadas para Windows Vista y apuntando al largo plazo, las acciones de WPF suben. Si sólo estás migrando por mantenerte en una plataforma soportada y te sentís más familiarizado con Windows Forms que con WPF, a la par que el usuario te está pidiendo nuevas funcionalidades de negocio a las que vas a tener que dedicarle tiempo, andá olvidandote de WPF por el momento
• "Existe algún tipo de certificación de Arquitectura?" Sí: el programa MCA
• "Tenemos que hacer aplicaciones pensadas para estaciones que eventualmente van a estar un período desconectadas de la red y sin embargo deben seguir operando... alguna idea, herramienta, técnica?" Echar un vistazo al Smart Client Software Factory y al Mobile Client Software Factory, que abordan la problemática de la desconexión ocasional y posterior sincronización de operaciones cuando la conexión se reestablece. También, la Enterprise Library ofrece el Caching Application Block, que te puede almacenar esa info del servidor que vas a necesitar disponible durante la desconexión (códigos de provincia o departamentos, etc). Ayer un cliente me decía "de todas maneras, hay que asegurarse que todo lo que se almacene localmente para forwardear luego esté encriptado: no sea cosa que te roben la notebook y terminen accediendo a info confidencial que vos ni siquiera llegaste a sincronizar y -por consiguiente- vas a tener que dar por perdida". Sabias palabras. Excepto que las Software Factories que te mencioné antes ya se hagan cargo de tal detalle, el Cryptography Application Block puede aplicar bien acá
  No obstante, uno de los clientes me preguntaba "y qué garantiza que, cuando la conexión vuelve, la sincronización se realice efectivamente?" No supe la respuesta dado que no probé efectivamente estas software factories. En el caso de que no provean nada, habrá que implementar mecanismos de notificación de las transacciones realizadas (sea un log de eventos, sea una ventana de operaciones aún pendientes, etc)
• "Me gustó todo esto que ví de Agilidad, cómo empezar a investigar el tema?" Hará un par de meses respondimos a esa pregunta con esta página. Y llegó en ese mismo momento Peter Provost, nuestro gurú en temas de Desarrollo Ágil, a hacerse cargo de la situación. Peter le hizo unas cuantas preguntas al cliente respecto de su contexto para asegurarse de que fuera que quería aplicar procesos ágiles sólo porque está copado (YAGNI, de nuevo)
• "Todos estos contenidos son una masa, re interesantes, pero debo admitir que más aprendo, más me complico porque hoy me lleva 3 horas hacer algo que antes me llevaba 1, ya que antes no pensaba tanto las cosas y ejecutaba más rápido". Qué punto, no? Admito que a mí también me ha pasado esto más de una vez hasta que terminé de entender que por muy políticamente correcta que parezca una nueva técnica, producto o tecnología... YAGNI. Mirá si me habré ensartado, eh? Enterprise JavaBeans y otras APIs Java, y lo mismo me tocó con el stack de Microsoft. No quiero decir con esto que nunca haya que innovar, sino que más allá del deber que tenemos de mantenernos siempre informados de los avances en esta ciencia, aplicar todo esto debe estar sujeto a una oportunidad real y concreta (sea de mejorar la productividad o de abaratar costos, mejorar la automatización, o una mezcla de todo eso)
• "Hemos aplicado SOA en nuestra organización con unos resultados tremendos, tan notables que ahora mi jefe quiere que tres aplicaciones VB6 -que serán obsoletas pero andan que son un reloj suizo las tres- sean incorporadas a la federación de aplicaciones. Yo me resisto porque nos va a costar un Perú y, la verdad, no hay una necesidad real de subirlas a la federación". Si no hay una necesidad concreta, eso no habla muy bien del jefe que está ignorando el principio de YAGNI. Ahora, si el día de mañana esas aplicaciones, esos silos, necesitan compartir funcionalidades (porque consuman o porque provean) con el resto de la federación, no hace falta migrarlas. Basta con agregar una capa de integración usando como superficie de contacto nada más que los servicios que se deben consumir y los que se deben brindar (para lo cual se podría usar el SOAP Toolkit). El resto queda dentro de la frontera de la aplicación y por ende es independiente de la federación. Por consiguiente no debería migrarse, excepto que haya otras razones como ser el poder beneficiarse del código administrado de .NET, etc. No son razones menores, sin duda, pero el tema es "con qué presupuesto cuentan para encarar la migración, qué esfuerzo les va a llevar, qué otros proyectos tienen en carpeta, qué prioridad tiene éste respecto de los otros", etc

Durante la tarde se repitieron dos sesiones: la de Patrones de Diseño de Bases de Datos del lunes (a cargo de Stephen Forte) y la de Juval Löwy de ayer, respecto de aplicar técnicas de orientación a servicios sobre el proceso mismo de desarrollo de aplicaciones SOA

La jornada la cerró un totem de la Ingeniería de Software: el sueco Ivar Jacobson. Jacobson es uno de los papás de UML y también de RUP. Bueno... al respecto dijo "es cierto que yo creé RUP con lo cuál RUP es mi bebé. Es cierto también que luego RUP creció por las suyas, no? Y bien, como sabrán, los niños al crecer necesitan de algunas... correcciones". El público estalló en carcajadas

Lo cierto es que Jacobson explicó las razones por las que descrée hoy de sus trabajos previos. Y ojo, asumiendo la responsabilidad. Pero a la vez justificándose de que lo que ofrecieron en aquellos años (que hoy es usado ampliamente), fue lo mejor, lo más evolucionado que pudieron ofrecer en ese momento. Pero que hoy, luego de haberlo aplicado y haber visto cómo otros lo aplicaron y extendieron, Jacobson está en condiciones de evolucionar todo esto nuevamente

No es muy distinto a Microsoft, fijate: qué fue de la vida de COM? Qué de MTS? Y de FoxPro? El DOS? Todo tuvo su momento y su lugar

Jacobson dice y predice que en el futuro no va a haber más metodologías prescriptivas como lo fueron UP, procesos estilo CMMI o procesos ágiles estilo XP, SCRUM y otros. En cambio, lo que va a haber es una paleta de prácticas. Las prácticas van a venir primero y las metodologías van a ser meras colecciones de prácticas que las organizaciones van a escoger de la paleta

Si la pensás un poco, Jacobson no sólo puede tener razón en lo que dice que va a pasar en el futuro: de hecho tiene razón en que eso fue lo que ha venido pasando!!! Yo conozco un montón de organizaciones que dicen que aplican UP, o XP o CMMI pero en realidad lo que tienen es una versión personalizada de esas metodologías y procesos. Por ejemplo, son muchísimos los casos de equipos de trabajo que me han tocado conocer que aplican TDD (test-driven development) y dicen "estamos rigiendonos por la metodología eXtreme Programming". Minga! A dónde está el pair programming, a dónde el planning game? Puedo ver las User Stories? Puedo revisar las CRC?

Es claro que cuando vamos a aplicar una metodología, hacemos lo mejor que podemos con la misma, pero siempre dentro del sentido común. Jacobson no sólo es conciente de esto: también es conciente de que la mayoría de la gente que compró los libros que escribió... no los leyó!! El mismo confesó: "al dejar Rational, la compañía que yo mismo co-fundé y de la que finalmente terminé siendo un empleado, abrí mi consultora Ivar Jacobson Consulting. Para qué? Ya que los que compraban mi libro no lo leían, les ofrecía ahora consultoría para terminar de explicarles qué era lo que el libro decía". De nuevo, carcajadas y aplausos en toda la sala

Jacobson explicó entonces que en los últimos años creó un nuevo proceso llamado EssUP (por Essential UP, detalles en su portal http://www.ivarjacobson.com) pero no es un rebranding de UP ni de RUP. Es de veras un proceso basado en ocho prácticas que él mismo te propone "andá adoptándolas de a una: nunca las adoptes sólo porque yo te dije que había que hacerlo". YAGNI otra vez!!

Y el viejo nos sorprendió a todos: abrió Visual Studio Team System y nos mostró cómo lo extendió para que sea tu herramienta EssUP. Y era tal cual! Visual Studio te permitía crear tu proceso basado en EssUP como vos quieras. Esto es, podías ya tomar alguna de las ocho prácticas, podías editarlas y modificarlas para adaptarlas a tu contexto, podías agregar prácticas meramente tuyas... lo que quieras

Jacobson nos contó que si programás en Eclipse, tiene hecho también el plugin para dicho IDE. Las ocho prácticas de las que te comenté se basan en lo mejor de RUP, lo mejor de CMMI y lo mejor de los procesos ágiles

Cuando terminó fueron (fuimos) varios los que nos acercamos para sacarnos una foto al lado de él. Más tarde fue a revisar las evaluaciones a los oradores en lo que va del TechEd. Jacobson viene liderando cómodo, seguido por Juval Löwy, David Chappell y Rocky Lhotka

Vamos a ver qué pasa mañana cuando Rod Johnson salga a la cancha

A propósito de mañana, es posible que no postée la jornada dado que tenemos la partuza del TechEd y creo que vuelvo tarde. En tal caso nos reencontremos el viernes

 Jornada  de luxe la de hoy, como pocas, combinando no sólo personalidades sino también haciendo un juego variado entre contenidos de Infraestructura y de Desarrollo. Como habrás notado, en la columna derecha del blog puse el keynote de Bob Muglia de ayer, que ya está publicado. Lo voy a dejar ahí hasta el miércoles de la semana que viene

Algo que está funcionando muy bien, ya que me garcaron y me dieron nada más que 20 (veinte) slots, es que eso ha permitido que no haya sesiones de arquitectura que se solapen. Vamos YA a los hechos

• Rushabh Mehta dio el puntapié inicial a primera hora de la mañana, con una sesión sobre Consideraciones de Diseño para ETL (Extracción, Transformación y Carga de datos para el armado de Warehouses de información utilizables en Inteligencia de Negocios -Business Intelligence o BI-). Comenzó revisando los problemas frecuentes que se presentan cuando tenemos varias fuentes de datos, quizás algunas de ellas no confiables (ojo al piojo: en el momento de la carga vos no sabés que tenían info fasula; te vas a apiolar más adelante cuando llegues a conclusiones que no se las crée ni el ratón Miguelito) y por ende te llevan a meter la gamba. El speaker parece que del tema conocía, porque complicó más la cosa planteando escenarios donde tenés más de un proceso de carga. Es más, tenés un workflow de procesos de carga con lo que, si algo entra mal, andá a darte cuenta después de la transformación
  El amigo después delineó las etapas de una carga de datos efectiva, que contemple puntos de control a los que podamos ser capaces de volver en forma retroactiva. Me gustó realmente el orador porque presentaba alternativas para todo, sujetas -claro- a condiciones. Cómo y cuándo encarar rollback automático, cómo y cuándo no va a quedar otra que hacerlo artesanalmente (seh: a manopla)
• Después pasó al frente uno de los platos fuertes que trajimos a este evento: Juval Löwy. La propuesta que nos planteó ahora que te lo cuente vas a pensar que debe haber salido de joda anoche y se le habrá ido la mano con el chupi. Pero creéme que tenía un dejo de coherencia. Juval comenzó planteando realidades que se presentan en los proyectos basados en Arquitecturas Orientadas a Servicios, destacando los riesgos que este tipo de proyectos presenta (justificando los mismos en que la aplicación se basa en servicios distribuidos). Entonces reveló su receta para que este tipo de proyectos llegue a buen puerto. Para ello abordó primero la problemática del armado del equipo de proyecto, cuántos arquitectos y de qué perfiles según el tamaño del mismo; también cómo repartir los servicios entre los desarrolladores que van a tener que construirlos; cómo ir integrando luego las piezas a medida que son completadas; cómo testear los servicios y cómo estimar el costo del proyecto basado en los servicios que hay que construir
  Juval terminó con una discusión interesantísima respecto de la conducta que puedan presentar tanto el esfuerzo del equipo (o sea, el trabajo invertido, las horas/hombre en otras palabras) como el progreso del proyecto (el porcentaje completado) respecto del plan inicial
  Simplemente mirá esta presentación cuando esté disponible (me voy a encargar de anunciar tanto en el blog como en el portal de arquitectura cuando las sesiones del TechEd estén liztaylor)

Al finalizar esas dos sesiones empezaba mi turno al frente de la estación para demos en el stand del Equipo de Arquitectura. Las dudas que los que se me acercaron me han planteado fueron, a grandes rasgos, tres:

• Cómo entender de Arquitectura aunque uno no vaya a jugar el rol de Arquitecto. El que me hacía la pregunta era el CTO (Chief Technology Officer) de una compañía dedicada a la Salud que necesitaba entender el idioma de los arquitectos que lo asesoraban. En otras palabras, quería saber cómo manejar los conceptos, cómo saber por dónde pasa la cosa, de qué se está discutiendo hoy
  Me dio pie a mostrar el portal y explicar cómo está organizada la información en el mismo, recorriendo en un pantallazo los pilares de una arquitectura distribuida, y también tópicos especiales que están en la agenda tecnológica de hoy. También, los sitios que creamos para verticales industriales y las formas de estar sintonizado con el contenido (las suscripciones RSS) y especialmente algo que te va a venir al pelo: el mapa del contenido
  
  

  
  Hacé click en esta imagen para probarlo Esta aplicación requiere la extensión de Internet Explorer que te habilita a ejecutar applets Windows Presentation Foundation (WPF) embebido (extensión xbap, no estoy muy seguro y no quiero hablar al cohete pero me parece que si no la tenés instalada te va a promptear para ver si aceptás descargarla). Concretamente este mapa te ofrece tres vistas de la información: por tópicos (llamalo SOA, Experiencia de Usuario, Software as a Service, Software Factories, etc), por autores que hayan contribuido a un dado tópico o por contenido de un tópico (esto es, los artículos, webcasts, etc). Al pasar por encima de un nodo, te ofrece un menú contextual que ofrece cosas relacionadas con ese nodo (por ejemplo, lanzar el artículo o video, o bien ver que otros artículos escribieron sus autores, etc)
  Es una forma novedosa de encontrar información fuertemente relacionada, que el portal no te puede ofrecer ya que la info está clasificada desde lo más nuevo a lo más antiguo (es decir, el orden viene prefijado de antemano). Los créditos a Simon Guest
  Echale un vistazo porque creo que te vas a familiarizar rápido ya que esa aplicación usa directamente la base de conocimiento por la que clasificamos el contenido, y tiene categorías que aún no llegaron a tener página propia en el portal (como pueden ser Web 2.0, Misión Crítica, Transacciones y varias otras)

• Otra de las consultas que me hicieron fue referida a información sobre Software Factories. No lo que en América Latina entendemos por, sino lo que Microsoft definió con ese nombre: herramientas alrededor de un lenguaje específico de dominio -o sea, no genéricos como C# o Java- que permitirían esconder todo contacto con APIs, restingiendo toda la gramática a elementos de un dominio de alto nivel. Por ejemplo, imaginate un lenguaje especifico para odontólogos que te permita -entre otras cosas- revisar radiografías digitalizadas de la boca de un paciente, a través de un lenguaje con primitivas tales como
  
      SELECCIONAR PACIENTE GONZALEZ
      MOSTRAR SEGUNDO MOLAR INFERIOR IZQUIERDO
      ROTAR 90 GRADOS SENTIDO HORARIO
  
  y que todo eso después se compile a componentes C# que a través de Windows Communication Foundation y DirectX terminen de cocinar el estofado
  Claro: sin Software Factories podríamos haber logrado lo mismo encapsulando la complejidad de WCF, DirectX y la API que fuera mediante el desarrollo de componentes, de modo de lograr algo como
  
      Paciente paciente = PacienteDAO.Seleccionar(Gonzalez);
      UIAgent.Show(paciente.GetDiente(Diente.SEGUNDO_MOLAR_INFERIOR_IZQUIERDO);
      UIAgent.Rotate(90, CLOCKWISE);
  
  Es decir, en lugar de introducir la complejidad de un nuevo lenguaje, introduzco la complejidad de una nueva API. De hecho, esta última solución parece mejor porque sigo teniendo el resto del framework .NET disponible (en verdad, incluso WCF y DirectX si se me canta usarlo de todas formas). En cambio, con el lenguaje específico de dominio me perdería la mayoría de las cosas que poséen los lenguajes .NET como podrían ser las caracterísitcas de la orientación a objetos, acceso a -justamente- todas esas APIs que quedaron encapsuladas
  Sin embargo, justamente eso es lo que se pretendía: crear un lenguaje que realmente limite by design el uso que se hace de la plataforma .NET, que lo aleje definitivamente del alcance de los programadores de lógica de dominio
  Esto sugiere un modelo de trabajo similar a una línea de montaje de una manufacturera: los operarios son especialistas en determinada parte del proceso de construcción, pero el trabajo conjunto y secuencial de todos acaba logrando los productos terminados. De ahí la denominación de Fábricas de Software
  Para conocer más en detalle de este punto, el portal ofrece unas páginas especificamente dedicadas a este tópico, así como también el año pasado salió un número del Architecture Journal enfocado en Software Factories
• La última pregunta significativa que me tocó responder fue acerca de guías para versionar, desplegar y monitorear servicios, lo que me permitió referenciar al trabajo que Mark Baciak está realizando con un proyecto cuyo code name es Alchemy, y que trata de una infraestructura que soporte aplicaciones orientadas a servicios, el ciclo de vida de estos últimos (su control de cambios), y que a la vez permita automatizar su administración y monitoreo a fin de prevenir el incumplimiento de los parámetros de nivel de servicio acordados

En el durante me crucé me vinieron a visitar ciertas personalidades, que nombro por orden de aparición: Leandro Olivestro (Q4Tech, un experto en aplicaciones móviles que nos ha permitido generar varios casos de uso en Sudamérica), Daniel Cazzulino (Clarius Consulting, otro grosso que lleva escrito varios libros sobre desarrollo web para Wrox y Apress, además colaboró con la flamante versión 3.0 de la Enterprise Library), Neil Roodyn (un gurú de procesos de desarrollo ágil), Arvindra Sehmi (director de arquitectura de software de Microsoft Europa), David Platt (te había comentado sobre él ayer)  y otros

En el interín y al terminar mi participación en el stand del Equipo de Arquitectura, hubo más sesiones del track que vale la pena comentar:

• David Chappell abordó el stack de productos de Microsoft para Manejo de Identidades. Tras una breve introducción al tema y a sus conceptos básicos (qué es una identidad, qué un token, etc), comentó las estrategias disponibles para verificar identidades tanto dentro de dominios específicos como a través de internet destacando las facilidades ofrecidas por Active Directory, Windows Cardspace, AD Federated Services, Identity Lifecycle Manager, etc. Finalmente dedicó unos minutos a mecanismos de autorización basados en AzMan
  No sólo viene siendo, hasta ahora, nuestra presentación mejor rankeada sino que de todo el evento, considerando otros tracks que el de Arquitectura, está entre las 10 presentaciones mejor evaluadas
• Rockford Lhotka hizo un balance de las técnicas que desde hace unas décadas han venido dominando la escena (Orientación a Objetos, Arquitecturas Cliente/Servidor, Arquitecturas en Capas, Orientación a Servicios, Workflows) y aunque apeló a ironías al justificar que estas técnicas surgen porque tanto Microsoft como su competencia necesitan seguir vendiendo, después aclaró que se trataba de una broma y que la realidad es que las Ciencias de la Computación van resolviendo problemas en base a las necesidades de la industria, y en la medida que esos problemas aún dejan cabos sueltos, nuevas técnicas llegan atrás para cubrirlos
  Lhotka mostró ejemplos de arquitecturas que combinaban lo mejor de cada técnica, demostrando así que las mismas complementan sus enfoques, no los contrastan ni contraponen
  La sesión fue súper bien recibida por el público que dejó su marca en los comentarios
• Y finalmente, cerrando la jornada, Caroll Moon, arquitecto del Centro de Excelencia en Operaciones de TI, brindó un pantallazo acerca de MOF, Microsoft Operations Frameworl, una metodología para Control de Cambios, Operaciones y Monitoreo de aplicaciones que permite lograr alta disponibilidad de los sistemas de misión crítica. Explicó la relación de MOF con ITIL, el rol de Microsoft en el comité que mantiene ITIL, las certificaciones disponibles, las herramientas del stack de System Center que sirven para planificación de la capacidad (capacity planning), el monitoreo, las alarmas, escalaciones, así como también las best practices de todo eso
  Comentó un caso de estudio interno, basado en Exchange Server con una base de 100 mil usuarios. Gracias a MOF, el uptime (tiempo en que el servicio Exchange está disponible), es superior al 99.99% anual

Estimados, esto fue todo por hoy

 Bob Muglia,  vicepresidente de Servidores y Herramientas de Microsoft, abrió el evento con un clip que grabó junto al Dr. Emmett Brown (el científico de Volver al Futuro caracterizado por Christopher Lloyd)

En el mismo, el profesor lo hacía volver a los años 2001 y 2003 para que revise los mensajes que Microsoft había estado anticipando en aquellos años y así se inspire para contar hoy los resultados y plantear "cómo sigue"

Como era de esperarse, una vez que "vuelven al futuro" (o sea, a ahora), entran al recinto en el clásico De Lorean de la saga (que, como era de la década del 80, tenía una diskettera por donde se cargaba el software que permitía viajar en el tiempo)

Muglia realizó un pantallazo del presente y futuro de la plataforma, tanto para desarrolladores como para IT Pros. No faltaron, por supuesto, demos de todo. Se vieron videos en Silverlight (el plug in cross browser que se plantea como competidor de Adobe Flash), novedades administrativas de SQL Server 2008, System Center Operations Manager 2007, Windows Server 2008, Biztalk Server 2006 R2, Windows Live, Office Business Applications y, como era de esperar, Visual Studio 2008. A decir verdad, y esto creo es el mensaje más importante, señores, hay .NET para rato. .NET es y seguirá siendo la forma de extender la plataforma básica de Microsoft (no hablo del sistema operativo solamente sino también extender documentos Office, portales Sharepoint, flujos de Biztalk, etc)

Nota: el keynote de Muglia está disponible para ver on demand haciendo click acá
Dura 90 minutos incluyendo la payasada de Volver al Futuro  

Todos estos avances que la plataforma viene realizando (me he referido sólo a la versión 3.0 en Marzo pasado, pero se vienen varios nuevos!!) no son meros esfuerzos aislados sino que siguen una trama argumental que va siendo definida por la plataforma completa

Pero todavía más importante que lo anterior es el hecho de que, si tenés que meter código, éste va a ser muy poco!! La plataforma de por sí está demasiado integrada. Quiero decir, es muy sencillo agregar valor con sólo juntar pocos componentes (una base de datos SQL con Sharepoint, o con Excel Services, eso luego adjuntarlo en forma automática a un correo electrónico, etc). No te voy a exagerar diciendo "no metés ni una línea de código". Te digo la justa, simplemente: es poco lo que tenés que codificar para puentear info entre dos aplicaciones

Obvio, uno me puede decir "y pero yo si no programo me aburro". Creéme que no vas a tener tiempo de aburrirte cuando veas que la facilidad con la que vas a obtener resultados que antes ni te hubieras planteado de sólo imaginarte lo que ibas a tener que codificar. Esto es algo que a mí, justamente, me viene pasando mucho ultimamente: veo los avances de la plataforma de Microsoft y se me abre mucho el bocho de cosas que podría hacer (digo, que de haber estado disponibles años atrás seguramente hubiera hecho). Ese es el punto. Empezás a encadenar cosas para agregar valor de la sola unión de las partes y ya no querés parar

Para un reporte ampliado del keynote de Muglia, te recomiendo éste que publicó .NET Development el mismo día: click acá

Bueno, volviendo a la expo, después que terminó el keynote me tocó cumplir con una de mis responsabilidades principales de este evento: mostrarles a los attendees (asistentes a la conferencia) en una estación para demos las cosas que estamos haciendo en el team, y a la vez -claro-, escuchar sus inquietudes para ver si lo que hacemos realmente es relevante o estamos en otra página que el field

Haciendo un resumen de lo que lo más interesante -o al menos, que más me llamó la atención a mí-, las inquietudes principales pasan mucho por ver cómo enlazar la Infraestructura con el portfolio de soluciones (hechas en casa o de terceros)

Esto me dio pie para mostrarles, en nuestro portal MSDN Architecture, como hemos venido ultimamente agregando información de Technet (IT Pros) a la par que el contenido puramente para desarrolladores. Porque yo tengo tan claro como el que más, vengo del field, quiero decir, no nací ayer: en las organizaciones no es que cualquiera haga cualquier cosa pero sí es claro que eso de "yo soy desarrollador y vos sos IT Pro" no es tan tajante

A mí me tocó ser jefe de proyecto, por decir, Java y terminar instalando el korn shell de Linux porque algún instalador de Red Hat lo requería. Y cuando terminaba tenía que seguir programando en Java, siendo que era el jefe del proyecto (claro, no full time pero más de una vez hacía yo las pruebas de concepto -todo o parte- para decidir si seguir adelante con un dado framework o buscar otro o darle a mano nosotros)

Justamente por eso es que me dí el gusto de poder mostrar que todo aquello relevante para arquitectos (sean de infraestructura o de soluciones) se está incluyendo en el portal. En lo que va del año hemos venido incorporado 840 nuevas piezas que ya están disponibles y accesibles desde las distintas páginas del portal. De las mismas un 60% no tiene ni un mes de antigüedad cuando empieza a estar disponible (a decir verdad, vas a notar que el feed RSS publica las cosas más relevantes que Microsoft liberó la semana anterior)

He recibido -y quiero agradecer por ello- varias felicitaciones por la arquitectura de la información del portal (es decir, la forma en que la navegación está organizada). Pero eso, claro está, de la gente que sabe del portal y lo usa. En cambio como punto en contra debo decir que no fueron pocos los arquitectos de plataforma Microsoft que desconocían de su existencia. Evidentemente tenemos que marketinear mejor esto

En cuanto a personalidades, he conocido por fin en persona a Dave Platt (el del post de Abril sobre su libro "Por qué el Software Apesta") -le mostré el dichoso post y me pidió que le traduzca el comentario de Matías Iácono: se copó y me dijo que le gustaría viajar a Argentina y presentar el libro allá, aunque por ahora anda con la agenda completa-

Vamos a las sesiones del track:

• Ron Jacobs pasó revista a los ejes por donde se ha venido debatiendo estos últimos años la Arquitectura de Software; lo que funciona y lo que no; cómo el clásico patrón de arquitectura Modelo-Vista-Controlador ha evolucionado en el actual Modelo-Vista-Presentador (con los por qués del cambio); las verdades sobre el desarrollo ágil y las prácticas que han venido funcionando; las conductas que conviene evitar (como YAGNI o "You aren't going to need it", en referencia a pararle la mano a los carlitos que quieren meter funcionalidades y otros chirimbolos por si acaso, comiendose innecesariamente horas del proyecto en algo superfluo); y las conductas que sí vale la pena adoptar (las clásicas, no? Test-Driven Development, Mocking, etc)
• Después de comer, Brian Noyes (IDesign), presentó una sesión acerca de ClickOnce para arquitectos. Es decir, capacidades que ClickOnce posée que quizás no son tan de dominio público y no se aprovechan al tener que hacer roll out en las workstations de las nuevas versiones de las aplicaciones. Brian es de los arquitectos que escriben código y se la bancan, así que hizo demos de todo. Incluyó aspectos de seguridad para que ningún piola se haga pasar por la entidad que generó los binaries y nos meta caballos de troya en versiones alteradas de la aplicación, etc
  También anticipó las novedades de ClickOnce en Visual Studio 2008, como por ejemplo el soporte a Firefox. Destacó las similitudes y diferencias de distribución de aplicaciones Windows Forms y Windows Presentation Foundation, etc
  Para quien tenga interés, Brian escribió un libro sobre todo esto (detalles acá). Sala llena y un público que participó muchísimo
• Tom Fuller (consultor senior de SOA) se mandó una presentación impresionante, muy madura, de los sí y los no de construir servicios. Arrancó por blanquear que el mensaje de reusabilidad con el que la bandera de SOA ha venido siendo agitada es un poco irreal dado que se dice de antemano y sin considerar el contexto que las organizaciones tienen. Con esta premisa, entonces, siguió adelante explicando formas de mitigar los problemas frecuentes que complican la reusabilidad de servicios. Y no se quedó en eso: cubrió también modelado de contratos (entre consumidor y proveedor de un servicio); explicó por qué WS-* aunque sea complejo es importante y no reemplazable por POX (el XML llano de la vieja guardia); manejo de excepciones adecuado, según que la pelota deba picar en el proveedor o el consumidor del servicio (concepto que debería ser reusado para manejo de excepciones en general, aunque no sean distribuidas); correlación de mensajes; autonomía de servicios; granularidad; procesado masivo (para evitar una conversación charlatana -chatty- entre las partes) y el consiguiente manejo de las unidades de trabajo; también un tema fundamental como lo es la arquitectura de servicios (es decir, su agrupación en módulos, agregación de servicios de menor nivel, etc); tolerancia a fallos... Ufff...
  Imperdible!!! Bueno, tanto ésta como todas las presentaciones del track de Arquitectura van a publicarse pronto
• Finalmente Stephen Forte nos dedicó una sesión de diseño de bases de datos, pensando en escalabilidad y mantenibilidad de los mismos. Atención: no hablo de patrones de diseño para acceso a datos. Eran patrones de diseño, sí, pero para diseñar aquellas tablas altamente transaccionales, también para aquellas dimensiones que cambian lentamente, y por último patrones de diseño para warehouses. También se la jugó y presentó un par de patrones más para alta disponibilidad de la información y para escalabilidad mediante el particionado horizontal (o sea, agrupar las filas de una tabla lógica en varias tablas físicas o particiones) y vertical (o, en otras palabras, dividir la info según columnas cohesivas que dependen de la misma clave principal)
  A pesar de haber presentado en último lugar y siendo que el primer día todos arrastran un poco de jet lag... la gente prendida a full y Stephen fue el orador mejor evaluado hasta ahora

Estimados, hablando de jet lag me voy a apoliyar y esto sigue mañana. Por supuesto que estos posts van a ir siendo reeditados para enprolijarlos, agregar más links a la data, alguna que otra foto, etc

Como decía Victor Sueiro, esto recién empieza

 El  pasado sábado partí hacia Orlando al TechEd 2007, la conferencia técnica para desarrolladores y profesionales de TI de Microsoft, por lo tanto y por el resto de esta semana quedan suspendidos boletines (debería haber salido el extraoficial #4), la serie Enterprise 2.0 (tranqui, va a seguir, sólo que me gusta generar intriga) y unos cuantos postizos que tengo ahí atragantados

Voy a estar transmitiendo diariamente la crónica de lo que aconteció en el track de Arquitectura. El viaje desde Redmond hasta Orlando, aunque todo quede en Estados Unidos, es complicadísimo (y eso de que "en el primer mundo estas cosas no pasan" acá parece no correr: mi vuelo se demoró 11 horas y tuve que ir a dormir a un hotel -porque era vuelo nocturno así que imaginate-, el de Simon se canceló directamente y sin previo aviso por lo que se perdió la primera jornada completa y a Lisa le perdieron la valija; aclaro que los tres viajamos en vuelos de compañías gringas diferentes, por si alguno crée que viajamos por Aerolíneas, Austral o LAPA). Particularmente mi vuelo se sacudió de lo lindo y se metía en cada nube con pinta de pocos amigos (de esas que van pasando de gris plata a negro azabache) que en un dado momento me recordó a ese cuento de Poe, Descenso al Maelström, que va en un barco a la deriva sin entender cómo llegó hasta allá, hasta que se da cuenta que los pasajeros del barco son puros fiambres, fantasmas

Y él, cae en la cuenta, también

Dibujo original de Harry Clarke, ilustrador de los cuentos
de Edgar Alan Poe, para el relato Descenso al Maelström

Pero bueno, por suerte hemos llegado finalmente, hemos dormido pocas horas pero estamos acá. Lo que sí, aviso de antemano: si en uno de estos travelcitos el avión... en fin... bueno, nada: digo que si pasa algo este blog se va a tener que discontinuar

Habrá Wi-Fi en el Cielo?

(Este post salió definitivamente con estilo Agus Goñi)