-= 2 Años de DiegumZone =- Anuario 2006/2007 Para Coleccionar

 *** REGALO ANIVERSARIO: El DVD de Patterns & Practices 2007 con Todas las Software Factories, Guías de Arquitectura, Labos, Videos y Más!! ***

 Amigazos,  a Uds que léen siempre lo que tengo para decir, a aquellos que incluso se suscribieron a mi RSS para no perderse ni un post -incluso los que son más de ocio que de Arquitectura-, aquellos que he ido conociendo por sus comentarios sobre mis posts y que me encantaría tener la chance de conocer personalmente (tengo fé de que va a pasar), a los que me hicieron preguntas adicionales (y con eso me hicieron sentir importante por un rato)…

A todos Uds gracias. El pasado 11 de Agosto (el sábado último) cerramos el segundo año de este blog que, si bien está lejos de ser lo que me gustaría que sea si tuviera más tiempo para dedicarle, sí puedo anticipar que tiene cuerda para rato

A modo de balance voy a destacar los posts más salientes de cada mes

Agosto 2006

Abrí el juego con una crítica a las arquitecturas demasiado by the book (de manual) con Un Viejo Antipatrón: "Too Much Architecture" (Demasiada Arquitectura) y los dolores de cabeza (o más abajo) que eso trae después en la práctica. Ni siquiera una vez que las cosas están en producción, incluso mucho antes (ya que quizás ni lleguen a ser puestas en producción)

Septiembre

A raiz de cierta confusión que se percibió en el foro de arquitectura MSDN (y que, en rigor de verdad, no yo sino el amigo Arnon Rotem Gal Oz se encargó de señalar) me dispuse, en Layers vs. Tiers: la Parábola de Shemp y Curly, a señalar similitudes y diferencias entre las arquitecturas en 3 capas (3-layered), 3 partes (3-tier) y la legendaria Modelo-Vista-Controlador (Model-View-Controller, hoy al parecer evolucionada en Modelo-Vista-Presentador)

Octubre

Respondiendo a un pedido del Ale Pacheco (también conocido como Pacachú, el arquitecto de Microsoft Chile), armé una pequeña presentación sobre Office Business Applications (OBAs, aplicaciones empresariales usando Office como columna vertebral) que desde Redmond se vio en directo en un Foro de Arquitectura en Santiago de Chile. Como consecuencia y para que no se perdiera, generé el post Office Business Applications (OBA): Office Agranda su Oficina

Noviembre

Julio, un gerente de tecnología con el que había trabajado años ha (en mis tiempos de Javero viejo) me planteaba algunas dudas acerca de si esto de que la orientación a objetos permite alcanzar reusabilidad era cierto o no, porque a él, según me comentaba, la probabilidad de reusar código en los proyectos de su gerencia era puro bluf. El tema me dejó pensando, revisé mi propio background en proyectos para ver situaciones comunes que se presentaban a la hora de definir código que se quisiera reusar, y lo que finalmente terminaba pasando. Lo plasmé en La Reusabilidad en Crisis

Diciembre

Como derivado de discusiones en foros acerca de si comprar tecnología de base o hacerla uno, y ese tonto mito de que lo que se hace por uno tiene costo 0 (cero) como si esas horas/hombre las pagase Antifaz, el tío de Anteojito, escribí Otro Viejo Antipatrón: Repudio de la Infraestructura (Infrastructure Repudiation)

Enero 2007

El nuevo año me motivó a sacar la cabeza un cacho del agua y ponerme a estudiar mecanismos alternativos de razonamiento para los problemas de siempre. Los resultados de este análisis los compartí en un par de posts, el primero dentro del hemisferio "Algo de Ocio" del blog, ya que no habían menciones explícitas a TI. Se trata de Pensamiento Lateral: Creatividad para Salirse del Montón. Semanas más tarde corrí esas ideas al hemisferio azul en Cómo Juega el Pensamiento Lateral en la Arquitectura de Software

Febrero

Con algunos compañeros del equipo, y espontáneamente, Mandy nos entrevistó en Los del Equipo de Arquitectura de Microsoft nos Hicimos la Película para que demos nuestra visión del rol de arquitecto de software. Me parece que el señor Michael Platt, lord de la ingeniería de software, la rompió

Marzo

Retomando una discusión que había iniciado durante el primer año de ZonaDiegum acerca del desajuste por impedancia entre Objetos y Tablas Relacionales, destaqué en Mapeo de Objetos y Tablas Relacionales (O/R-M). Lo Que a Mí me Sirvió qué cosas me salvaron a mí de no perderme en esa ciénaga que, yo considero, está constituída por herramientas aparentemente poderosas conocidas "mapeadores entre objetos y (tablas) relacionales" (object/relational mappers). La polémica sigue

Abril

En Estos Programadores que No Cazan Una…, hice mi crítica (en el buen sentido) sobre el libro "Por Qué el Software Apesta" (Why Software Sucks) de David Platt. Dos meses más tarde tuve el gusto de estrechar su mano en el TechEd de Orlando (la conferencia top de desarrollo de software sobre plataforma Microsoft)

Mayo

Terriblemente influenciado por cierta literatura que había llegado a mis manos sobre, por un lado, tecnologías asociadas a Web 2.0, pero principalmente sobre las oportunidades de crear un nuevo tipo de valor, enlazando empresas en una forma que ni SOA se hubiera esperado, con consumidores que a su vez ayudan a generar un efecto red que potencia los resultados en beneficio de todas las partes, inicié la saga Enterprise 2.0: Web 2.0 Y A Cobrar

Junio

Durante el TechEd de Orlando me tocó, por un lado, ser chairman del track de Arquitectura y por el otro, cubrir en determinados horarios un panel de discusión sobre temas diversos relacionados con eso. La verdad que la experiencia me resultó enriquecedora y meritoria de ser compartida. Por esta razón dediqué un post a cada día de esa semana (el primero es TechEd 2007- 1ra Jornada, los subsiguientes están directamente vinculados)

Julio

En Enterprise 2.0: Parte 3- Que No se Retove el Usuario, promediando la serie iniciada en Mayo, destaco cómo ciertos avances en tecnologías web hoy nos ayudan a ganar mayor reacción y practicidad para que quien la use no la sufra. Fue mi primer acercamiento a Experiencia de Usuario desde un enfoque de Arquitectura de Software (no de un diseñador de interfaces de usuario, dominio en el que me sentiría más torpe e impreciso que Leonardo pintando a la Gioconda con guantes de box)

Mientras escribo esto me quedo pensando en lo que contaba de esa semana en que estuve en Orlando, durante el TechEd, y no me puedo borrar charlas con algunos arquitectos que me decían "todo esto me parece muy cool, pero por darle pelota me pasa que lo que antes hubiera hecho en una hora -seguramente sin buscar que sea reusable, compatible con el futuro, modular, componentizable, etc- ahora me lleva no menos de tres y me queda una sensación incómoda de si no estaba mejor cuando hacía cosas que seguramente no me iban a servir para siempre, pero que en lapsos breves estaban andando"

Qué amarga conclusión si se comprobase que todo esto para lo único que sirve es para convertir soft barato y presuntamente berreta (habría que confirmar esto último, ya que no necesariamente) en soft que promete mucho pero no concreta tanto, y cuesta valores saladitos (recursos humanos escasos o no siempre a la altura de los últimos avances; horas / hombre que, baratas o no tanto, finalmente terminan siendo muchas más que las presupuestadas)

Estará yendo todo el mundo a SOA, realmente? O SOA es algo que genera curiosidad, todos quieren leer algo sobre, pero pocos están firmemente decididos a ir para aquel lado? Y los que fueron a SOA, habrán encontrado una bolsa con moneditas al final del arco iris? Tendrán arco iris, o todavía están esperando que aparezca cuando pare la tormenta eléctrica, granizo incluído, que amenaza con enterrar el datacenter?

La verdad es que SOA, como todas las restantes tendencias son resultados evolutivos de intentos anteriores que por alguna razón fracasaron. SOA no es más que una respuesta desacoplada al CORBA de los ’90

Y REST, qué es? Es una salida elegante y liviana a escenarios donde las complejas extensiones WS-* de los servicios web no sean necesarias

Algunas nuevas tecnologías llegan a ponerle la tapa al cajón de los intentos anteriores, en tanto que otras vienen sólo a complementar (a sumarse a) soluciones aportando una dosis de sencillez allí donde no hacía falta poner toda la carne a la parrilla

 

Qué pasos debe dar un arquitecto para aconsejar determinada tecnología? Preliminarmente, mantenerse informado de las tendencias actuales (sin tomar todo al pié de la letra, sólo estar alerta)

Posteriormente organizar una Prueba de Concepto (Proof of Concept, o PoC) para aquellas tecnologías que considere que verdaderamente van a permitir mejorar el soporte del área de tecnología a los objetivos del negocio (tanto por el aseguramiento del revenue como por la reducción de costos). La PoC es un primer filtro a las tecnologías testeadas, que le deberían permitir al arquitecto hacerse una idea de hasta dónde esta aparente solución no podría ser un nuevo foco de complejidad

Si la PoC resultase exitosa el arquitecto puede aconsejar al líder del proyecto (eventualmente a la gerencia de tecnología) de invertir más en esa tecnología para una posible adopción (sea en un dado proyecto o sea a nivel estratégico en un portfolio más amplio de aplicaciones). La aceptación por parte del líder de proyecto y/o de la gerencia dependerá en qué tan hábiles seamos en mostrar que estas tendencias realmente van alineadas con objetivos de la organización. Va a ser difícil, si no, que nos suelten un mango (pasa que nadie se quiere quemar después, viste? Entendé eso primero y se te va a hacer la vida mucho más fácil)

Si hay luz verde, se abre una etapa donde se debería capacitar tanto a desarrolladores como a profesionales de TI (infraestructura) en las tecnologías a aplicar, así como eventualmente contratar profesionales ya entrenados en las mismas (y, de ser posible, "estrenados" también: con experiencia)

Personalmente creo que el arquitecto no debería competir con los desarrolladores senior a ver quién la tiene más clara en las nuevas APIs. Suele pasar esto en aquellas personas de carácter inseguro de sí mismas que temen verse desplazados por aquellos que dominan mejor las nuevas tecnologías, como si la visión de negocio detrás de las mismas -se las domine o no- no le importase a la gerencia. En cambio, el arquitecto debería aprovechar el training en las nuevas tecnologías para, con la ayuda de los desarrolladores senior, definir frameworks (componentes, generadores de código, etc) que permitan esconder la complejidad inherente de las nuevas tecnologías, de manera de adoptarla en una forma commoditizada. En castellano, esto significa poder montar un framework de componentes y herramientas que permitan hacer uso de APIs nuevas, complejas, por parte de desarrolladores de nivel intermedio -que quizás, con suerte, ni sepan que lo que están desarrollando termina haciendo uso de estas nuevas tecnologías-. En suma, el arquitecto juega acá un rol primordial en bajar todo lo que se pueda el costo de adopción 

 

Balas de plata, ya lo había dicho Frederick Brooks Jr, no hay ni va a haber: aún siguiendo las tendencias más noveles, de las que haya casos de estudio exitosísimos por todos lados, nada nos garantiza que a nosotros nos deba ir bien también. La clave es no dejar de lado las reales motivaciones, en términos de resultados de la organización, de subirse a nuevas tendencias. El arquitecto que pasa demasiado tiempo con la vista baja mirando las tecnologías, y no la levanta cada tanto para mirar lo que la organización demanda es como el tenista que no mantiene en todo momento la vista en la pelota

 

Y con esto dicho se inaugura DiegumZone Año III Birthday cake

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

3 respuestas a -= 2 Años de DiegumZone =- Anuario 2006/2007 Para Coleccionar

  1. Borja dijo:

    Felicitaciones Diego por estos dos años de entretenimiento  y culturilla tecnologica, se agradece sobre todo la forma llana y facil de expresar y plantear los temas

  2. Pablo dijo:

    Felicitaciones por los 2 años!
    Esperemos poder llevar a la practica eso de "conocer personalmente", seguramente asado mediante, a aquellos que alguna vez intercambiamos algun comentario o opinion acerca de los contenidos de este util y entretenido Blog.
     
    Saludos desde Cordoba – Argentina.-

  3. Diego dijo:

    Cuento con ello, Pablito!! 

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