[Serie] TechEd 2007- 3ra Jornada

 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

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

Una respuesta a [Serie] TechEd 2007- 3ra Jornada

  1. javier dijo:

    buenas. pues les comento mi experiencia con el system center de microsoft. lo instalamos en la oficina hace poco tiempo y nos ha dado buenisimos resultados. la ventaja que tiene es que desde el servidor manejas todo, entonces como es una gestión centralizada te ahorra mucho tiempo de trabajo. las actualizaciones del software o parches de seguridad las haces desde una sola terminal, además de que puedes automatizar las tareas típicas, además de que puedes monitorear todo el entorno de red y todas las aplicaciones y sistemas al mismo tiempo. hace inventarios completos de las aplicaciones y de dispositivos móviles, además de los backups que los hace super rápido maximizando el rendimiento del servidor. permite virtualizar la gestión del IT haciendo más facil para los usuarios tener un nuevas máquinas virtuales. bueno, la verdad está bastante robusto este paquetito, teníamos dudas de si ponerlo o no, instalamos la versión de prueba y nos encantó. suerte y felicidades por el foro

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