TechEd 2007: El Track de Arquitectura

 Hace  unos pocos meses atrás, con Simon hacíamos el llamado a propuestas para el track de Arquitectura de Software del próximo TechEd 2007 a realizarse en Orlando los primeros días de Junio. Teníamos después que seleccionar 20 (veinte) sesiones, y con Simon teníamos miedo de no recibir ni 18 propuestas. El año pasado Simon había hecho la convocatoria sólo -yo recién estaba "inmigrando" a Redmond- y había recibido cincuenta (50) propuestas. "Yo creo que podríamos igualar esa cifra" me decía con cierta incredulidad

Bueno. Se equivocó

No fueron cincuenta. Fueron ciento sesenta (160) respuestas al llamado!! En otras palabras, se más que triplicó el número de interesados!! Sólo me queda decir GRACIAS / MERCI / THANK YOU / GRAZIE y ojalá supiera decirlo también en hebreo, turco, indio, japonés y en los idiomas de todos los países que mandaron propuestas

Ahora, logicamente, después de la euforia inicial y disipados el frente de tormenta de no tener qué ofrecer durante el evento, vino la siguiente realidad: cómo elegir entre tantas propuestas las veinte a exponer? Si al menos se hubiera dado que más allá de la cantidad abrumadora sólo un diez, quince por ciento (10-15%) hubiese sido rescatable, listo. Pero no era el caso!! Todas las propuestas que leía me resultaban irresistibles!! No exagero: se me hacía agua la boca de poder contar con una gran mayoría de las propuestas recibidas. Pero sólo veinte slots, un garrón!!

Entonces lo discutimos internamente en la comisión seleccionadora y arribamos a los siguientes criterios:

  • Privilegiar, por sobre lo que a nosotros nos gustaría mostrarle al público, contenidos demandados por el perfil promedio de asistente -tomando como "promedio" el feedback recibido en años anteriores-
  • Para que te des una idea de ese perfil "promedio", si son arquitectos de soluciones, dedican una parte importante a escribir código; si son arquitectos de infraestructura, dedican una parte importante a operar y monitorear procesos, servidores, recursos de hardware, etc. Por consiguiente, presentaciones de un nivel 300 o 400, donde no sólo hay una introducción a modo de revisión de un concepto sino más bien ejemplos de código, demos ejecutables, etc, serán preferibles por sobre las de nivel 200 (lo que no dejó afuera a las propuestas de este nivel, sino que tuvieron que scorear por otras cualidades)
  • Privilegiar voces externas por sobre la palabra "oficial" de Microsoft. Esto generó mucha polémica interna y debate, ya que algunos defensores de poner más caras de Microsoft al frente sostenían que si el público iba era porque quería conocer información de primera fuente, secretos, mejores prácticas, etc. Los que, como en mi caso, apoyábamos darle prioridad a las caras externas, lo hacíamos confiando en que la gente allá afuera tiene la experiencia del mundo real, de proyectos concretos hoy implementados y en producción. Con cosas que pudieron haber salido bien y otras que no, y eso es lo importante: un buen balance entre lo que sí y lo que no de nuestra plataforma. Si, en cambio, quien presenta trabaja en los grupos de producto de la compañía, te ofrecerá otra presentación más de Contoso (una compañía hipotética que siempre es tomada de ejemplo para la demo empresarial que sea). El ejemplo de Contoso o Adventure Works le puede servir para entender un concepto a la gente que normalmente toma una decisión, pero esa gente no necesariamente es el tipo de público hands-on que te comentaba en los puntos anteriores. Este público quiere recibir contenidos que cuando vuelvan a sus trabajos se pueda aplicar en forma inmediata, tangible. Existe un área de Servicios en Microsoft que sí trabaja con clientes y partners en proyectos verídicos, del mundo real, de manera que sí tienen bastante para ofrecer y compartir (particularmente MCS, Microsoft Consulting Services). Y así lo pusimos en práctica: de los oradores de Microsoft, la mayoría son consultores que pasan más tiempo en las oficinas de los clientes -donde en muchos casos les asignan cuenta en dichas corporaciones- que en las oficinas de la propia subsidiaria de Microsoft para la que trabajan
  • Finalmente, acá vino la decisión más difícil que hubo que tomar, se decidió privilegiar aquellas propuestas de oradores con buena experiencia (probada) en eventos anteriores. Atención que no dije "con experiencia probada" sino "con buena experiencia probada". Es decir, no alcanzaba con decir "anteriormente me invitaron a hablar a las conferencias tal y tal" sino "me invitaron y acá están los números con que me calificaron". Fue jodido hacer esto porque fue el principal divisor de aguas. Lo cierto es que la idea era garantizar que los oradores que llevamos realmente van a deslumbrar al público

Te va a interesar saber finalmente quiénes fueron los elegidos. Tomá nota porque esta reunión de personalidades se ha visto pocas veces. Veamos:

 


Juval Löwy

Juval Löwy: fundador y presidente de IDesign, lleva escritos varios libros sobre .NET para arquitectos (a la derecha mi preferido: Programming .NET Components, 2ed, O’Reilly, 2005). Su último libro es sobre .NET 3.0: Windows Communication Foundation (WCF): Programming WCF Services (O’Reilly, 2007). Löwy también escribe regularmente para MSDN Magazine, la revista para desarrolladores avanzados sobre plataforma Microsoft
En TechEd 2007, Juval nos viene a hablar más de metodología que de tecnología. Con una propuesta original: adoptar conductas "orientadas a servicios" en los roles de proyectos de desarrollo de arquitecturas SOA


Ivar Jacobson

Ivar Jacobson: quizás nunca lo hayas sentido nombrar. Pero te suena conocido el logo que sale a la derecha? Esas tres letras… U, M y L… Te tocó hacer algo con esto en los últimos diez años? Ok, Jacobson es miembro del trío creador, no sólo de UML sino también de UP (Unified Processing o Proceso Unificado), la metodología de desarrollo de proyectos de software originalmente patentada por Rational y posteriormente adquirida por IBM
Contrariamente a lo que te puedas imaginar, Jacobson no viene con una lista de recetas tecnócratas para ocuparse nada más que de la burocracia de los métodos y olvidarse de todo lo demás. El hombre nos viene a contar qué, cómo y cuánto debemos tomar de cualquier metodología, para que la práctica de las mismas no se quede sólo en eso y concreten el objetivo (cuál era? Ah sí! Distribuir el software!)


Rocky Lhotka

Rockford Lhotka: padre de un framework bastante interesante y completo llamado CSLA.NET (sigla en inglés de Arquitectura Lógica Escalable Basada en Componentes), que dio lugar a una serie de libros sobre componentes de negocio distribuidos (ver derecha, Apress, 2006); "Rocky" es también un colaborador frecuente de MSDN Magazine
Lo que nos viene a ofrecer a TechEd 2007 no puede pasar desapercibido: una presentación sobre las encrucijadas más significativas que enfrenta la arquitectura hoy: donde calza Orientación a Objetos y donde Orientación a Servicios? Qué patrón de arquitectura elegir: Cliente/servidor, N-capas o SOA?


David Platt

David Platt: mi post anterior es su carta de presentación así que no me voy a extender mucho más acá acerca de él
Platt nos va a mostrar cómo el Composite UI Application Block de Patterns & Practices aplica eficientemente conceptos de Alta Cohesión y Bajo Acoplamiento, que son ingredientes sustanciales para lograr componentes altamente re-usables sin que por ello su evolución quede atada a sus "consumidores"
Platt también va a presentar, a través de una charla debate, el libro al que me referí en mi post anterior: Por qué el Software Apesta (Addison-Wesley, 2007)


Ted Neward

Ted Neward: autor de numerosos libros de arquitectura de aplicaciones Java Enterprise Edition y .NET, Ted fue además director del portal The Server Side .NET. También desde mediados del 2006, Ted escribe la columna Arquitectura Pragmática en el portal de Arquitectura MSDN
En esta ocasión nos va a mostrar con ejemplos prácticos cómo automatizar actividades repetitivas (y tediosas) de proyectos. También, en el track de Desarrolladores, va a ofrecer una sesión sobre interoperabilidad entre las plataformas Java Enterprise Edition y .NET


Ron Jacobs

Ron Jacobs: al fin apareció un empleado de Microsoft en el track de Arquitectura
Bueno, no es el único en realidad pero sin dudas el más famoso. Ron fue colaborador de Patterns and Practices por años, y desde allí nos brindó varios webcasts sobre la Enterprise Library y otros componentes que estos muchachos iban liberando
Pero Ron hace algo más de un año que se vino al equipo de Arquitectura y desarrolló una interesantísima faceta entrevistando arquitectos de software en una serie que bautizó ARCasts (podcasts de arquitectura). Desde allí entrevistó a personalidades como Martin Fowler y varias otras celebrities como los que te estoy nombrando acá (excepto Ron, claro) 
En TechEd 2007, en cambio, Ron deja el traje de periodista para volver a ponerse el traje de arquitecto. Nos va a hablar sobre el impacto que va a tener en las arquitecturas tradicionales .NET 2.0 la introducción de .NET 3.0. Sus patrones y mejores prácticas


David Chappell

David Chappell: consultor -en mi impresión- demasiado senior para el público que va a venir a TechEd 2007. Sin embargo me convencieron de incluirlo en la nómina dado que es un orador bastante hábil que va a saber adaptarse al tipo de público
En esta ocasión, Chappell nos va a hacer una revisión tecnológica de las tecnologías para manejo de identidades y credenciales de Microsoft (tema al que Chappell le viene dedicando bastante tiempo. Cuándo aplica Windows CardSpace? Cuando Active Directory Federation Services (ADFS)? Qué hay para decir de Identity Lifecycle Manager (ILM)? Hacen falta todas? Son mutuamente excluyentes? En otras palabras, no es una sesión técnica sobre un producto en particular sino una sesión sobre estrategias para manejo de Identidades orientada a Arquitectos


Rod Johnson

Rod Johnson: padre de Spring, el framework que hizo que Java Enterprise Edition deje de ser el cementerio de buenas intenciones pero en la práctica inconcretables que venía siendo
Spring tiene una versión .NET, que no es simplemente una portación del código de Java a C#, sino la portación de una filosofía de trabajo (consistente en simplificar las partes complejas de una plataforma para que sean fácilmente aprovechables por desarrolladores de skill modesto)
Inyección de Dependencias para poder lograr desacoplamiento mediante programación orientada a interfaces, habilitación de puntos de cortes, intercepciones y otros conceptos de programación orientada a aspectos (AOP) en .NET, y otros milagros que esta caja de Pandora que es Spring viene a traer, de la mano de Rod Johnson, quizás el arquitecto de software más pragmático

El track de Arquitectura se completa con muchas otras sesiones más y también charlas-debate con tiza y pizarrón. Te invito a que lo revises completo en esta dirección:

https://www.msteched.com/public/sessions.aspx (tenés que seleccionar la opción "Architecture" en la lista desplegable "Track")

Nos encontramos en Junio en Orlando?

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

6 respuestas a TechEd 2007: El Track de Arquitectura

  1. Alejandro dijo:

    ¡Qué gran evento Diego!  Es imperdonable perdérselo, no solo por la calidad de los expositores, sino por la importancia, la vigencia  y la profundidad de los temas que estos traen al debate.
    -Alejandro

  2. paulo dijo:

    En hebreo gracias se dice תורה (se pronuncia toda, con cierto énfasis en la a final), ahora pasando al tema del post, sería bueno que los expositores que quedaron fuera del track puedan presentar lo que tenían planeado como webcasts de los que habitualmente se realizan en Microsoft, es una idea nada mas, pero creo que puede ayudar que tanto las ganas como la experiencia de estas personas no se pierda y la puedan volcar a la comunidad.

  3. Diego dijo:

    Absoluto, Paulo. Mirá, lo de entrarlo como webcasts o incluso como artículos o de la forma que sea fue y sigue siendo algo que tengo en la cabeza. Yo le ofrecí a algunos esto mismo, aunque me cortaron el rostro -y no es para menos: encima que los dejo arafue los quiero hacer laburar para mí cuan cerdo capitalista burgués- Y es verdad que a ellos les aporta también el hecho de grabar un webcast y exponer pero, como bien algunos de ellos me dijeron: "más aporta si encima la presentaba en TechEd". En definitiva, me tomaron la propuesta más como un premio-consuelo de tontos que como algo serio donde todos ganamos
    Pero yo sigo opinando como vos y debo por ende seguir insistiendo
     
    Abrazo

  4. Verònica dijo:

    Que tal Diego agradeceré me ayude con una duda inmensa, y creo por lo que he leido tu tienes bastante experiencia.
    Actualmente la empresa en la que trabajo maneja un sistema multicapas (cliente-negocio-datos-DB) en V6, controlando la transaccionalidad por medio de COM+, es decir en la capa de negocio nosotros manejamo el ObjectContext a fin de invocar cada metodo de Datos que ejecutará una acción específica, a su vez la capa de datos invoca a una dll general por nosotros creada en donde se realiza la conexion a la DB y el exec propiamente de los Stores.
    En este momento nos encontramos en un proceso de migración de plataformas y se ha elegido VS2005 con DB SQL ó Oracle, el manejo de la transaccionalidad por lo q entiedo ahora debe realizarce atravez del System.Transacction, en donde veo hacen referencia a la TransactionScope, lo que no tenemos claro el grupo de desarrollo  que esta manejando este proyecto en q capa debería invocarse al TransactionScope, considerando q tambien ahora se esta diseñando una Dll que realiza los accesos a la base de datos.
    Es en la capa de Negocio?
    Debería crearse un Store Principal en donde se encuentre los q sean requeridos para una transacción X y a su vez la TransactionScope esta en la dll general q te indico?
     
    Agradeceré mucho tu ayuda, pues nos sacará de la nebulosa en que nos encontramos.
     
    Att
    Ma. Verónica Chávez.

  5. Diego dijo:

    Allo Vero,   no quiero ser más papista que el papa en este punto, por eso relativizá mi opinión a quién opina de afuera, sin estar inmerso en los detalles específicos de vuestra aplicación. Hasta donde veo por lo que me cuentas, en tu aplicación no hay otro back-end que el Oracle. Por esa razón, yo invocaría a la transacción en la capa de acceso a datos, y libero a la capa de negocio de tener que andar lidiando con esos detalles de bajo nivel   Es posible que, al confirmarse una operación de negocio, desde dicha capa se deba llamar reiteradamante a la capa de acceso a datos, para actualizar todas las entidades de negocio involucradas. Es quizás aquí donde a Uds les surja la duda, me equivoco?   A decir verdad, dado que en este caso la transacción global y atómica es de negocio, no me voy a rasgar las vestiduras yo si veo que el TransactionScope se abre allí   Si nos queremos poner rigurosos, podríamos poner un método en la capa de acceso a datos que reciba todo lo que hay que persistir y lo persista consecutivamente en una sóla transacción, de modo que la capa de negocio de nuevo pueda desligarse. Aunque si dicho método lo vas a crear sólo para complacerme de no "ensuciar" la capa de negocio con la System.Transaction, please, ensuciala tranquila y viví feliz -tratá siempre de no escribir líneas de código sólo por complacer a charlatanes-
       Finalmente, no sé si sabías, supongo que sí: las transacciones se pueden anidar. Eso quiere decir que mientras vos podrías iniciar la transacción a nivel del caso de uso en la capa de negocio, al mismo tiempo podrías abrir y cerrar transacción en la capa de acceso a datos para cada actividad granular (actualizar estado cuenta, guardar cabecera de orden de compra, guardar cada item de detalle de la orden de compra, etc). Tenés garantizado que por más que las transacciones interiores manden un COMMIT (método Complete() de TransactionScope), habiendo una transacción englobadora, el COMMIT se va a contener
       Sobre esto último tenés un buen artículo de Juval Löwy:http://msdn2.microsoft.com/en-us/library/ms973865.aspx (fijate en la sección Transaction Flow Management)
       Otro en MSDN Magazine en Septiembre pasadohttp://msdn.microsoft.com//msdnmag/issues/06/09/NETMatters/default.aspx
       Espero resuelva vuestra duda, boys

  6. Alberto dijo:

    Hola estimados, es bueno saber que somos cada ves los que utilizamos este framework en casos reales, te comento que he aperturado una comunidad (http://www.Codesol.org) que promueve software de fuente abierta y estamos desarrollado proyectos donde usamos CSLA .NET para la capa de negocios, te invitamos a participar.Saludos.BeyondNethttp://www.Codesol.org

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s