Semana Visual Studio 2010 en Channel9

Camino a "Rosario"

Peter Provost cuenta para nosotros (arquitectos) que viene en Visual Studio 2010

 Aquellos que siguen  mi blog en inglés saben que el número del Journal a aparecer hacia fin de año (es decir, no el siguiente Journal sino el que sigue a éste) estará abocado a explorar técnicas de computación eco-friendly. Esto es, que no dañen al medio ambiente (o que lo hagan, cuando sea inevitable, en la menor medida posible)

Me está asesorando Lewis Curtis, arquitecto de infraestructura de Microsoft y una de las voces más activas en la búsqueda de iniciativas que permitan alinear más y más la tecnología a las necesidades de la sociedad -en todos sus estratos: social, empresarial, educativo, etc- con, al mismo tiempo, un mínimo impacto de daño en el ya desequilibrado equilibrio ecológico y que además, ya que estamos, permita reducir el consumo energético de todo el parque tecnológico, habida cuenta del encarecimiento en los costos que la generación de energía viene experimentando (que tarde o temprano se trasladan al consumo)

De visita por mi oficina, Lewis me tiró unas ideas interesantes acerca de la correcta manera de entender y abordar la "Computación Verde" (Green Computing). Sintetizo su enfoque aquí

• Físico. En esta perspectiva se estudian alternativas para mitigar el calor liberado por el uso intensivo de las unidades centrales de procesamiento (CPUs). La concentración creciente de CPUs en espacios físicos de dimensiones reducidas torna los centros de datos (datacenters) en verdaderos infiernos. Literalmente hablando. Aquí no son solamente los fabricantes de CPU (Intel, AMD, etc) quienes están batallando para lograr una mejor ecuación performance-per-watt (rendimiento por electricidad consumida) sino que existen algunos estudios que detallan la ideal posición física de las CPUs para que estén lo suficientemente separadas como para que el incremento de temperatura no se potencie pero a la vez lo suficientemente cerca como para maximizar el aprovechamiento del espacio físico
• Plataforma Operativa. Cuando se asignan procesos a servidores, se lo hace normalmente en función de la carga esperada de trabajo que estos procesos van a tener. El estudio de un consumo más eficiente de recursos dio lugar a dos tácticas: la optimización y la consolidación. La optimización del uso de la plataforma operativa se puede alcanzar de varias maneras, sea mediante la asignación correcta de recursos (CPUs, ancho de banda, etc) como por la detección de estado ocioso prolongado y consecuente hibernación, entre otras (esto, claro está, es también lograble desde el mismo hardware). La consolidación tiene que ver con la aglomeración de varios procesos en un mismo hardware, de modo de maximizar el uso de recursos
  Claro, acá puede impactar el hecho de que diferentes procesos pueden requerir una diferente plataforma operativa, lo que limita las chances de consolidación. Pero esto es mitigado gracias a los avances alcanzados en virtualización de plataformas, lo que ha permitido tirar viejo hardware, costoso de mantener, sin discontinuar las aplicaciones que en el mismo corrían -en muchos casos sistemas legados o legacy systems, los cuales hasta cierto punto pueden resultar tan caros de mantener como de migrar-
• Regulaciones. A nivel gubernamental los países están avanzando (?) en metas de reducción de niveles de dióxido de carbono (CO2), el principal responsable del efecto invernadero (greenhouse effect). A la corta o a la larga eso se va a trasladar a un sistema de premios y castigos en la calidad y cantidad de energía que las compañías -y a renglón seguido los hogares- consuman. Probablemente esto vaya ligado a excensiones o gravámenes impositivos
• La "Nube". Las aplicaciones hosteadas en la web misma, y con esto no me refiero a accesibles vía web ya que esto incluye a aplicaciones hosteables en un servidor hogareño, sino a aquellas aplicaciones cuyo "dueño" las recibe distribuidas como un servicio ("as a Service"), en lugar de hacerse responsable de su ubicación física y operación; decía que tales aplicaciones plantean desafíos tanto para el que las consume -quien no debe hacerse cargo del datacenter con lo cual acá tiene un significativo problema menos- como del que las provée, quien tiene ante sí la oportunidad de optimizar la granja de servidores, consolidando los clientes de tales aplicaciones SaaS (por Software as a Service o Software como Servicio). En la ecuación general, bajo este esquema de tiempo compartido (tiempo de ejecución, claro, o creíste que pusimos SaaS y nos rajamos todos de vacaciones... Zaas! ), el consumo de recursos y de energía es inferior al esperado por el esquema tradicional donde cada consumidor se hostea su aplicación en sus propios servidores (lo que se conoce como on premise delivery)
  Cuanto mayor sea la penetración del esquema "as a Service", mayor el ahorre global. Sin embargo, claro, pasar de la nada a este esquema no es fácil, sobre todo si se necesita que la parte hosteada en la nube interopere con lo que nos quede on premise. Qué de la atomicidad de las transacciones, qué del single sign-on (login único o SSO), qué de muchas otras tantas cosas como disponibilidad, tiempo de respuesta, etc
• Inteligencia Sustentable. Imaginate un tablero de control donde podés monitorear la energía consumida por tu plataforma respecto de la actividad real que cada una está haciendo. Imaginate que podés establecer umbrales de consumo, disparar alarmas. Imaginate que podés tirar estadísticas históricas de ese consumo a fin de determinar tendencias y consiguientemente predecir la demanda futura esperable. No hace falta imaginarse demasiado porque existen esos monitores. Scry, Cognos (adquirido por IBM) por mencionar algunos de ellos
• Código de Aplicación. Y llegamos al último, que a su vez engloba a todos los anteriores. En pocas palabras, no es cuestión de echarle la culpa de todo a la infraestructura, al soft de base e ilusionarse con la idea de que la solución pase nada más que por ahí. Por ejemplo, en nuestra apliación distribuida, dónde se conserva el estado de la sesión de cada usuario conectado? Es ese estado persistido al cabo de un tiempo en que el usuario no da señales de vida (y siempre antes de que expire su sesión), a fin de liberar la memoria para otras sesiones activas? Son los servicios state-less (una instancia única para todos) o stateful (una instancia individual por cada sesión que los consume)? Y qué hay para decir del ancho de banda? Se usa en forma eficiente? Qué significa "ancho de banda eficiente"? Enviar la menor cantidad posible de información en cada interacción o tratar de anticipar cierta información que el caso de uso pueda necesitar con una alta probabilidad? Y qué se puede decir del paralelismo en plataformas de más de un núcleo? Se saca tajada del procesamiento paralelo o el binario de la aplicación está pensado para el denominador común mono-núcleo? Podría seguirme extendiendo pero creo que con ésto queda demostrado que nosotros desarrolladores de soft no podemos hacernos los osos por muy ecológico que sea todo este tema

Bueno, la consigna es enviar propuestas de artículos para computación verde que tengan un enfoque práctico (es decir, más allá del mero mensaje de que ahorremos gas, apaguemos luces y no imprimamos mails si los podemos leer de la pantalla). El plazo de envío se extiende hasta el 10 de Septiembre. Más detalles para hacernos llegar tu propuesta, acá

 Dos años atrás,  cuando un artículo mío era publicado en una revista independiente de TI, un colega me dijo, "Vos deberías escribir para The Architecture Journal." No podía haber predicho que me iba a encontrar ahora escribiendo para esta revista en mi nuevo rol de editor. Le quiero agradecer a Simon Guest, por esta oportunidad y este enorme compromiso -durante su lapso, la cantidad de lectores se más que duplicó, pasando de 30 mil a más de 62 mil

En este número, te invitamos a pensar en la Arquitectura de Identidades de tu organización. El manejo de identidades está evolucionando hoy del escenario simple, aislado, al escenario federado, en una forma que te puede sorprender

Empezamos este decimosexto viaje con la introducción de Fernando Gebara Filho a los conceptos y estrategias en identidades, cómo han evolucionado y el camino por recorrer. Después, Jesús Rodríguez y Joe Klug examinan un surtido de estrategias para hacer de las identidades componentes de primera línea en el portfolio de aplicaciones federadas. Gerrit van der Geest y Carmen de Ruijter Korver consideran el desafío de establecer un entorno de confianza a nivel de aplicación ya que las identidades de usuario, en un mundo orientado a servicios, deben fluir desde el consumidor de un servicio hacia el prestador

Para el perfil de arquitecto de este número, lo atajamos a Kim Cameron, autor de "Las Leyes de la Identidad", cuyas ideas en identidades federadas están dando forma a la siguiente generación de tecnologías de identidad de Microsoft. (Algo gracioso pasó el día que visité a Kim para esta entrevista: me olvidé mi tarjeta de acceso por lo que necesité que Kim "certifique" mi identidad en la entrada)

Retomando nuestro paseo, Mario Szpuszta describe cómo el sistema de salud austríaco convirtió una crisis administrativa de provisioning en una clara oportunidad para crear una federación de identidades abierta. Luego Vittorio Bertocci explica cómo ciertos patrones de arquitectura nos ayudan a construir soluciones que consideran demandas (claims), de modo que cuando "la Nube" llegue a las compañías, el manejo de identidades no se va a ver necesariamente nublado

Finalmente, Mike Morley y Barry Lawrence revelan cómo sincronizaron identidades en varios sistemas y aplicaciones legadas (legacy applications) desde una consola administrativa individual a través de un framework de consolidación

Querido lector, quisiera ser el primero en darte la bienvenida a este número, y deseo que te sientas identificado con sus artículos. A disfrutarlo!

Diego Dagum

El próximo número del Architecture Journal se va a enfocar en Computación Distribuida

Nos estamos arrimando a un punto de inflexión con el hardware y las tecnologías de hoy donde lo que hace unos pocos años atrás era apenas una visión hoy se va haciendo realidad -desde distribuir aplicaciones a dispositivos microscópicos hasta datacenters del tamaño del estadio de Boca y aún más, que ofrecen correr aplicaciones en la nube

No importa qué tan chico o grande, la distribución y la concurrencia de servicios múltiples puede introducir un número de desafíos

El foco de esta edición es entender cuáles son esos desafíos y cómo superarlos

Si esto logra inspirarte lo suficiente como para querer llevar tus opiniones a los más de 60000 lectores que el Journal tiene (solamente contando la edición en inglés, sin considerar las otras tres traducciones), por favor averiguá más datos en mi blog en la lengua de William (foto)

"La optimización temprana es la causante de todos los males"

-Sir Charles Antony Richard Hoare, computador científico británico, después parafraseado por Donald Knuth en su libro El Arte de Programar Computadoras

Días atrás, mirando un documental sobre la vida del director de cine sudamericano Fabián Bielinsky, me llamó la atención algo que dijo en una entrevista. Decía que, cuando se filman escenas, usualmente pasa que una toma determinada no sale como el director inicialmente asumió que iba a ser. A veces esa escena se hace de vuelta hasta que el director consiga lo que quería, en tanto que en otras ocasiones se deja no más como salió, en la medida en que así como está queda bastante mejor que la idea original. Bielinsky concluía que el verdadero arte de hacer cine es saber decidir cuándo intentarlo de nuevo y cuando dejar lo que salió de entrada

Sorprendentemente, si así viene la mano con las películas, codificar componentes es muy parecido a filmar escenas. Siempre es posible encontrar una mejor solución a un algoritmo dado. Así que, con el sombrero de gerente en la cabeza, tenemos que decidir cuándo congelar una siempre posible mejora a efector del la carga GANTT, el presupuesto, las fechas de entrega y la satisfacción general del usuario, y cuándo ir por más

Y es acá donde enfrentamos la necesidad de refactorización: una serie de técnicas y mecanismos para mejorar la calidad -comprensibilidad, mantenibilidad, modularidad, extensibilidad, etc- de segmentos de código mediante la reformulación de sus sentencias en una forma en que la conducta general no cambie. En otras palabras, el comportamiento de los componentes afectados no debería variar como una consecuencia del proceso pero su calidad, y ojalá su vida útil, debería ser incrementada

La experiencia ha mostrado que algunas porciones de nuestro código van a ser, a la corta o a la larga, candidatas a refactorización, y las razones son varias:

• Del lado del usuario, los usuarios no están completamente seguros de la aplicación que quieren hasta que ven instalado y corriendo lo que ellos pidieron originalmente. No es chiste! Al principio empiezan requiriendo algo que tienen en la cabeza pero vagamente (y eso es natural: de ninguna manera los estoy acusando). Olvidarse situaciones especiales cuando nos describen un caso de uso es como tener caries: no digo que sea bueno pero sí que es algo normal. Un efecto secundario indeseable de este tira y afloja es que nuestro código podría empezar a perder cierto grado de cohesión; sus diversos módulos pueden empezar a acoplarse arriba de los niveles aceptables como consecuencia de cambios de último minuto debidos a presiones del time to market
• De nuestra perspectiva, la del desarrollo de software, nosotros no tenemos una idea cabal de a qué el código se va a parecer mientras estamos modelando. Al igual que los usuarios, nosotros también creémos que tenemos unas ideas impresionantes (o al menos buenas ideas al fin) hasta que tratemos de poner algunas de ellas en práctica. Equivocarse no es malo. Lo que es malo es obsecarse en cambiar de parecer sólo para evitar admitir que lo que habíamos considerado una gran idea no era, de hecho, tan fácil de implementar. Y acá de nuevo, cuando el tiempo agrega su presión, entregar un componente lo más rápido que podamos puede también dañar su calidad
• Del lado de la tecnología, finalmente, hay una presión invisible aunque algo omnipresente a acompañar las tendencias de la industria. Ejemplos típicos son las APIs evolucionadas de .NET o Java (AJAX, servicios web, etc) que tornan obsoletas a las versiones previas, o estrategias generales como Arquitectura Orientada a Servicios (SOA), Modelo-Vista-Controlador (MVC), Mapeo entre Objetos y Relaciones (O/R-M), etc. Una vez más, en la medida en que reaccionamos a estas tendencias nuestro código es sometido a cierta manipulación que, a medida que el tiempo pasa, puede erosionar su calidad

Mientras tanto, el mundo real nos muestra que esmerarnos en mejorar la calidad de nuestro código es algo que tendemos a hacer en forma innata. Las técnicas de refactorización no son sino el más alto grado de maduración de esos intentos espontáneos, reforzadas con algunas herramientas de soporte disponibles por ahí para garantizar el éxito del proceso

La buena noticia es que podemos aplicar refactorización localmente, al nivel de un componente o método, allí donde estemos aplicando cualquier otra modificación; o globalmente, a nivel de módulo o aplicación, asignándole rango de proyecto. Decidir la dosis correcta de refactorización dependerá de la brecha de calidad a cerrar, el tiempo restante, el presupuesto disponible (siempre será más fácil justificar la refactorización donde ya teníamos algo más que hacer que donde ninguna actualización había sido pedida aún), entre otros factores

A lo largo de este libro, el autor abordará tópicos de refactorización desde la visión de sus beneficios a las maneras actuales de ponerlo en práctica. Danijel Arsenovski ha estado involucrado en técnicas de refactorización, tanto en las plataformas .NET como Java, desde sus versiones más tempranas. Dio varias conferencias, charlas y talleres en esta materia, dirigiendo proyectos exitosos de refactorización en la industria bancaria

Como uno de los líderes en herramientas de desarrollo, Microsoft ha estado comprometido a distribuir los mejores recursos para la gente que día a día lidia con actividades de codificación y proyectos de software en su totalidad. Mediante su indiscutidamente ganador entorno integrado Visual Studio, Microsoft hace de la refactorización una facilidad out-of-box apenas a un click de distancia de tu código. A lo largo de las páginas de este libro, Danijel te mostrará cómo la refactorización puede ser practicada en Visual Basic tan fácil como hacer copy / paste o cualquier otra actividad de edición!

Me atrevo a decirte, estimado, que vas a encontrar en este libro una de las guías más probadas y fundamentales en estas técnicas. Que disfrutes este libro!

Diego Dagum
Evangelista Técnico, Microsoft Corp.
Kingsgate, Invierno de 2007

(Lo que acabás de leer es el prólogo que escribí para el libro de Danija "Professional Refactoring in Visual Basic" - Ediciones Wrox)

La palabra Crisis, escrita en Chino, comparte un
caracter con la palabra Oportunidad. No es así
por casualidad

 No  es un secreto para nadie que el mundo se encamina a una recesión impulsada, esta vez, no por Brasil o Asia o Rusia sino por la primera economía mundial. Si se frena la locomotora (nos guste o no, es la primera unidad del convoy), los vagones que eran arrastrados inevitablemente van a perder impulso (nuevamente, nos guste o no)

Curiosamente en medio de estas crisis es cuando, usando un poco de inteligencia, podemos ver el lado bueno en los cambios de contexto. Como la fábula del burro que iban a sacrificar y para eso habían hecho un foso, lo habían tirado al fondo y pensaban enterrarlo vivo: el burro logro salir del foso porque en la medida que la tierra que tiraban se iba asentando, hacía pie en ésta

En el artículo que te linkeo acá, Gartner predice que en la medida que el parate económico de la primer superpotencia (la única hoy, bah) el outsourcing (tercerización) de servicios de software va a aumentar en forma considerable. El que la venía mirando con cariño, se va a decidir en la medida en que necesite mantener sus servicios de software (si es posible, incrementarlos para -en la crisis de demanda- mejorar la calidad de su oferta). El que ya estaba tercerizando y conoce las ventajas en lo que a reducción de costos se refiere, probablemente quiera cerrar un cachito más la brecha. Y finalmente, el que hasta ahora no pensaba en tercerizar, si empieza a estar con el agua al cuello quizás al menos comience a explorar esta alternativa (algo es algo)

Gartner predice que India primero y China después van a ser los grandes polos de atracción de tercerizadores. Latinoamérica no sale mencionada, no en el informe de Gartner al que yo no tuve acceso, sino en la nota que lo destaca

De todas maneras, si la montaña no viene a Mahoma, habrá que ir a la mountain no más... A preparar esas brochures en inglés. Primer mundo: allá vamoooooosssssssss!!!!!!!

 Semanas  atrás liberamos la edición 15 del Architecture Journal (on line, revista en papel y reader). El tema de este trimestre es El Rol del Arquitecto, que es algo que siempre da que hablar. Más allá de cualquier tema que podamos cubrir de arquitectura de software (SOA, SaaS, O/R-M, etc) el éxito de un enfoque arquitectónico no lo va a dar por sí solo su diseño sino las habilidades del arquitecto en transmitir una idea en forma convincente, generar adhesión y lograr apoyos (tanto de arriba -léase guita- como de abajo -mano de obra leal que haga lo que los planos decían-)

Al fin y al cabo, como decía el dicho, de carne somos y eso vale tanto para los arquitectos como para los que tienen que lidiar con ellos en el día a día (jefes de proyecto, gerentes de TI, desarrolladores, operadores, DBAs, jefes de seguridad informática, etc)

Por esta razón hemos liberado un nuevo foro de discusión sobre el Rol del Arquitecto. La consigna del mismo no es debatir temas de arquitectura en general (onda "qué me conviene, ADO.NET o NHibernate?") -eso ya tiene su foro- sino lo que vendrían a ser nuestros soft skills como liderazgo, apertura intelectual, capacidad de aprendizaje y evolución, etc

Te recomiendo que afiles tus conocimientos de inglés y te pegues una vuelta. Se han armado unos debates bastante interesantes ("debe un arquitecto programar? cuánto?", "cómo lidiar con el jefe cuando nos fuerza a hacer la arquitectura contemplando cosas que nunca hubieramos elegido?", "por qué no se puede ser arquitecto apenas se sale de la facu?")

Y muchas otras

Oíme, haceme caso. No gastés guita en psicólogo y vení a discutir de estos temas al foro. Como es de esperar, minitas no va a haber pero en eso al menos no estabas mejor en el psicólogo

 
Parálisis de Diseño? Implementación Precoz? Consulte al Dr. Diegumoff

 Recibí  una consulta interesante de Jorge, un lector del blog, docente de la carrera de computación científica en la Universidad de Ciencias Informáticas (Cuba). Preferí -previa autorización de él- llevar el caso en forma abierta, de modo que todos puedan dar su visión al respecto

Estimado Jorge, el caso que se te planteó es de esas típicas discusiones donde todas las partes involucradas parecen tener algo de razón, lo que vuelve muy complicado de determinar quién está en errado y quién no

Es muy probable que si afirmamos que sólo al arquitecto le cabe definir la plataforma de desarrollo, los sistemas operativos sobre los que la solución va a correr, elegir el IDE, etc, estemos equivocados. No obstante, sería falso también decir que al arquitecto no le cabe ningún rol en las decisiones a tomar en esos primeros puntos de la lista

La mano es así: arquitectos los hay con distinto nivel jerárquico, esto basado en su background, antigüedad en la empresa donde trabajan, antigüedad en la industria del software, etc. Asimismo, tenemos arquitectos de soluciones (que son los que vienen de haber programado durante varios largos años) y arquitectos de infraestructura (aquellos a los que les tocó instalar y mantener servidores, redes, puestos clientes y periféricos durante un lapso no menor)

Es muy raro -aunque no imposible- que te topes con alguien que la tenga clara en desarrollo y a la vez la tenga clara en infraestructura. Cuando te digo "tenerla clara en ambas cosas" no me refiero a saber Java y ser capaz de instalar Linux, sino a ser capaz de diseñar soluciones que corran en una plataforma definida por ellos y que la cosa escale así de repente todos los usuarios se decidieron a dar enter al mismo tiempo

Seguramente que lo que dijo el profe pueda parecer exagerado si se lo vamos a asignar, dado un proyecto x de misión crítica, a una sola persona aunque lo probable es que sean definiciones a resolver entre dos o quizás más. Lo que sí me atrevo a asegurar es que varias de estas personas van a ostentar el rol de arquitecto (o arquitecto jefe, que es más bien un arquitecto que no participa en un proyecto dado sino que toma decisiones que afectan a todos los proyectos de la organización). Lo más probable es que estos arquitectos sean, algunos "de soluciones" (desarrollo) y otros "de infraestructura"

Si tengo que contar por mi caso personal (yo soy arquitecto de soluciones), hubo proyectos a los que me sumé y ciertas decisiones ya habían sido tomadas (S.O., Lenguaje de Programación, etc) y otras que aún quedaban "por tomar". Para aquellas que aún estaban pendientes, como te contaba, no es que me tiraban toda la responsabilidad de la decisión a mí solo, sino que yo integraba un comité junto con otras personas

La mayoría de las veces, tal como tú lo sugieres, tuve voz pero no voto. Es decir, podía dar mi opinión pero la decisión quedaba en manos de alguien con "poder de compra", sobre todo en aquellos casos en que la decisión implicase adoptar un producto con un modelo de licenciamiento lucrativo (que haya que pagar para poder usarlo, bah). Debo confesar acá que me frustraba que a veces mi opinión fuese ignorada (me carcomía la duda de para qué me convocaban a esos comités si luego iban a hacer lo que les pareciera. Pero, en fin, volviendo al punto y como cierre, no es que me tocara toda la responsabilidad a mí pero sí al menos una participación en la maduración de las ideas y los rumbos a tomar

Sin duda alguna que, no obstante, el grueso del proyecto lo iba a dedicar a "Estilos y Patrones Arquitectónicos", el último punto que mencionó el profe y con el que sí estuviste de acuerdo

Saludos por la tierra del Ron

 Los  manuales suelen hablar de dos enfoques para abordar diseño de aplicaciones: el top-down (o "desde la cima hacia abajo") y el bottom-up (o "desde el fondo hacia arriba"). Ambos enfoques son complementarios, no alternativos. Es decir, están pensados para ser ambos aplicados en un proyecto, no son dos tendencias antagónicas como ocasionalmente pueda verselo presentado. Veamoslo más en detalle

• Top-down es el enfoque "políticamente correcto" en el sentido que parte de premisas puramente organizacionales (o para no hacerme tanto el delicado, "necesidades de negocio", bah; quise probar otra cosa porque siempre digo "business needs" y ya suena un poco cacofónico pero al fin y al cabo, es eso). Se basa en un principio caro a las ciencias de la computación que es el de "divide y reinarás" ("divide and conquer" en la bibliografía en inglés), donde se parte de un contexto macro que ciclicamente será descompuesto en sus partes constituyentes, éstas últimas en sus propias partes constituyentes y así sucesivamente hasta llegar a ciertos límites donde el proceso de introspección se detiene porque se ha logrado un modelo con cierto nivel de atomicidad tal que se pretende satisfacer con componentes ya disponibles (sean propios o de terceros, ya no es necesario "reinventing the wheel" o reinventar la rueda. Es justamente llegados a este borde que el siguiente enfoque entra en juego
• Bottom-up gana presencia una vez que los átomos consituyentes de las diversas capas de componentes han sido determinados. Entonces se sigue por asignar tecnologías (componentes, plataformas) como una forma de comenzar a desenmarañar la espiral de componentes en que el modelo ha derivado. Y digo "comenzar" a resolver debido al readiness de los componentes atómicos (qué tan listos para usar vienen). Normalmente va a ser aún menester el cumplimiento de tres etapas con los mismos:
  • Construcción (building), para aquellos componentes planeados durante el top-down pero aún no disponibles
  • Configuración (customization), de los grados de libertad que el componente habilita para permitir adaptarse a un grado amplio de necesidades de modo de pelear hasta donde se pueda la batalla por la reusabilidad. Esta etapa transcurre especialmente durante el periodo de desarrollo en el ciclo de vida (software development life cycle o SDLC)
  • Afinamiento (tuning), especialmente durante el período de implementación -aunque empieza tímidamente al principio, desde la planificación de capacidad (o capacity planning) cuando se presupuesta la carga que la solución pueda llegar a alcanzar. Desde luego que ninguna de estas dos etapa se enmarca estrictamente en una fase del ciclo de vida sino que tienen fases donde logran más protagonismo. Podría darse, como una consecuencia del tuning, que se termine revisando la customización o la misma construcción de los componentes

Para los puristas metodológicos, esa secuencia de enfoques (top-down y bottom-up) era condición necesaria y suficiente para decir alea jacta est (o la suerte está echada, como cuando Julio César desafió la autoridad del senado romano cruzando el río Rubicón pese a las advertencias de que no siga avanzando, aunque algunos historiadores dicen que pronunció alea jacta est queriendo significar la jalea está hecha -al parecer a este Julio le tiraban los dulces-). Estaba contando que para algunas personas, esta forma de trabajo garantiza el éxito. Pero en la última década se comenzó a sospechar de que ya no. O, al menos, no necesariamente. A continuación voy a tratar de explicar cuáles son los vicios derivados, y a mostrar y explicar cuál es la alternativa que ha venido emergiendo victoriosa

En principio el esquema planteado por estos dos enfoques ha venido asociado durante décadas a ciclos de vida en cascada (waterfall). Esto es, una vez finalizada una etapa del ciclo de vida, ya no se volvería a ella hasta el final del proyecto (inflexibilidad de por sí arriesgadísima, como desde luego la experiencia se encargó de mostrar). Permiso aquí: no es que los promotores de top-down/bottom-up impusieran waterfall sino que el timeframe en que top-down y bottom-up fueron moneda corriente coincidió con la edad de oro del waterfall. Y es que si bien estos dos enfoques se pueden aplicar a un proceso ágil, la dinámica geeky impartida por este último (un diseño medio a mano alzada y a programar de una ) tornaría las sucesiones top-down/bottom-up algo toscas
Como fuera, la reputación de los procesos en cascada hoy viene (de la boca para afuera) de capa caída. En la práctica, luego de décadas de cascadas, torrentes y cataratas, la corriente del waterfall todavía sigue tirando (es muy dificil romper esa cultura, sobre todo en las áreas gerenciales en que quieren ver una carta GANTT previsible -que a su vez deben presentar al directorio, si es por ellos, con que funque da lo mismo-)

El esquema dual top-down/bottom-up también tuvo y tiene dificultades en hacer congeniar dos mundos: el de los líderes de TI y sus reportes. Generalmente son los líderes de TI o los líderes de los proyectos los que se encargan de la etapa top-down, en tanto que los developers y operadores (a veces conocidos como profesionales de TI o IT Pros) suelen llevar a cabo el bottom-up

Se suele dar algo curioso con los arquitectos, que ya venía contando el mes pasado en mi post "Reglas del Juego". Dependiendo de la vereda en la que estén parados (si la del negocio mirando a la tecnología o si viceversa), tendrán una tendencia a participar en la etapa top-down o en la bottom-up respectivamente Yo puedo decir que hoy estoy marcadamente tirado más al momentum del top-down (o, dicho en otras palabras, cuando llega el momento de programar me borro ). En cambio, en mis tiempos como arquitecto Java EE -por aquellos días J2EE- me acuerdo que aunque creyera ser business-oriented, era eminentemente bottom-up: no podía dejar de ver los sistemas en términos de APIs (APIs a las que dedicaba días y noches enteras en entender hasta el más mínimo detalle de sus capacidades ). Esto obviamente me desenfocaba a menudo la lente con la que debía mirar (y entender) el espacio del problema Con todo, y a modo de conclusión, debo decir que un arquitecto debe participar tanto en la descomposición top-down como en las decisiones a tomar durante la fase bottom-up. Más allá de cuáles sean sus fuertes o qué le tire más, debe hacer el esfuerzo por desarrollar el otro hemisferio

Esto que me pasó y me sigue pasando, suele pasar en general y si le tengo que asignar un nombre, debería éste ser "la brecha entre top-down y bottom-up" ("top-down/bottom-up gap", suena lindo, no? )

Figurativamente hablando, es como si ambos enfoques fuesen las dos secciones de un puente levadizo. No hace falta convencer a nadie de que sin una de esas secciones no habrá forma de cruzar el puente que lleve desde el espacio del problema hacia el de la solución. Pero aún estándo presentes, puede darse el caso de que las secciones no logran unirse. He aquí el famoso gap o brecha entre los dos enfoques Algunas vez Jotapé se refirió a esto en un post recomendable. Él aborda el caso en que top-down no baja lo suficiente pero no es ciencia oculta imaginarse la otra cara del problema: un bottom-up demasiado centrado en sí mismo que no honra las necesidades por las cuales tuvo su raison d'être (merde! )

Como consecuencia de estos malestares, y quizás acompañando la caída en cáscada de los ciclos de vida waterfall, un nuevo enfoque unificado ha emergido: Middle-Out ("del centro hacia afuera"). Middle-Out implica dar lugar a la experiencia que nos supimos ganar en tantos años de industria (por ende, si sos un recién llegado, no digo que no debas aplicar este enfoque pero quizás no vas a tener el suficiente marco de referencia), de manera tal que no vamos a partir desde el confín más sui generis del espacio del problema sino que vamos a mezclar un cachito de lo que conocemos del problema con lo que la tecnología ya avisora como solución (patrones de arquitectura, de diseño, productos de mercado -sobre todo los que la organización ya adquirió y por ende ahora hay que amortizar si no queremos aparecer una mañana leyendo los clasificados de demanda de laburo )

Middle-Out se para justo en esa mitad donde las dos secciones del puente se juntan, y avanza hacia sus extremos opuestos. Por eso mismo es fundamental lo que te decía de "la cancha" que es necesario tener para aplicar este enfoque: dónde está exactamente ese punto de unión? Sólo los que ya cruzaron varias veces estos puentes pueden saberlo con precisión

Se descrée que haya sido Middle-Out el que provocó, como consecuencia, procesos de desarrollos ágiles. Más bien se considera que el enfoque Middle-Out es una consecuencia de estos. Lo cierto es que caminan muy de la mano. El esquema iterativo e incremental de los procesos ágiles es el que permite, sea cual fuere el punto intermedio de partida, converger hacia las salidas (un EXIT total )

Lo que le da a Middle-Out fortaleza para ganar adhesión en los estratos más altos de la gerencia es, a esta altura del partido, la percepción de que el espacio del problema no sólo no es -como regla general- del todo conocido por quienes definen la necesidad (las gerencias operativas y administrativas de la organización) sino que incluso aquello que si conocen puede cambiar de acuerdo a los vaivenes empresariales (impuestos reactivamente ante movidas de la competencia o proactivamente hacia nuevas oportunidades a encarar)

Middle-Out es, en realidad, algo que innatamente hacemos en las restantes cosas de la vida. Cuando tus amigos te proponen hacer un asado el finde les preguntás "quién lleva el vino?" siendo que no hubo un análisis desde el principio respecto de si los comensales toman alcohol, qué hacer en caso de que llueva, etc) y no hay nadie que esté, desde lo más abstracto, pensando en costo/beneficio de organizar un asado, etc

De todas maneras, no tengas dudas de eso, no es que Middle-Out debe a partir de ahora ser el enfoque único y que la dupla top-down/bottom-up pasan a mejor vida. Todavía existen escenarios donde estos enfoques van a prevalecer y en cambio Middle-Out va a quedar descolocado. Te menciono algunos, a modo de cierre del post

• El proyecto tecnológico comienza desde un análisis ya realizado en forma completa o casi completa por consultores. El qué de la solución (o el espacio del problema, si se quiere) ya se tiene claro y es posible que no cambie demasiado. Sólo resta completar con el bottom-up si bien es cierto que, en lo que respecta a nosotros, estamos empezando por el medio (pero no vamos a avanzar hacia arriba )
• Imaginate ahora un escenario similar al anterior pero donde además, antes de irse, los consultores esbozaron como parte de sus conclusiones una propuesta de implementación (tipo "orquestación Biztalk disparando contra el Oracle en un CICS, además de la base SQL local") que fue aprobada por el comité ejecutivo del proyecto. Entonces te dan ahora la batuta a vos como arquitecto y... al menos la infraestructura ya no la vas a tener que definir porque alguien se encargó de pensar (no importa si bien o mal, la cosa es que ya lo hizo y le creyeron!! ). Te restará entonces definir la solución a montar en dicha infraestructura. Es por un lado limitado pero por el otro desestresante el no tener que decidir sobre absolutamente todo, creéme
• Otro caso más que no sería Middle-Out puro (aunque se le asemeja bastante) es el caso en que no hay aún una etapa top-down concretada... pero sí gran parte de la bottom-up!! Que cómo es eso me preguntás? La organización, luego de un excelente desempeño de labia de vendedores o consultores de una empresa externa, adquieren determinada infraestructura y definen que todo nuevo proyecto la va a usar (por los beneficios que dicho producto aporta), en tanto que viejos proyectos legados se irán migrando conforme se pueda a dicha plataforma. Como te contaba, no llega a ser un Middle-Out 100% aunque podríamos decir que en tanto que no toda la infraestructura esté definida, empieza a tomar forma de
  • Esto en verdad va a depender porque todavía la gerencia te podría indicar que, más allá de que parte del bottom-up ya esté prefijado, a vos te toca partir desde el top-down y no desde el medio. Si ése es el caso, no sería Middle-Out ni puro ni impuro: es top-down/bottom-up a la vieja usanza

Estimados, ha sido un placer y me despido hasta la próxima

 Hay  un nuevo llamado para propuestas para el Journal de Arquitectura (#16). Como esa publicación es en idioma inglés, prefiero directamente referenciar al aviso en la lengua de Shakespeare

http://blogs.msdn.com/diegumzone/archive/2008/04/05/microsoft-architecture-journal-issue-16-call-for-papers.aspx

Anyway, si te querés enterar antes que nadie de los futuros llamados, suscribite a este feed: http://www.microsoft.com/feeds/msdn/en-us/arcjournal/rss/rssCallForPapers.xml

 Es  un hecho que hoy en día los equipos con dos procesadores son un estándar, y opcionalmente los hay de cuatro o más CPUs. Normalmente dos procesadores es la norma hoy en equipos cliente o "de escritorio" en tanto que más es norma para equipos servidores

En estos casos se suele dar que las primeras aplicaciones que sacan provecho de estos avances son las de nivel más bajo como el sistema operativo o procesos servidores como el RDBMS (la base de datos, bah), etc

En una segunda oleada estos beneficios pasan a ser dejados a disposición del público masivo, como ya pasara con los procesadores gráficos que al principio quedaban accesibles sólo a través de APIs especiales como DirectX y hoy cualquier mamerto con Windows Presentation Foundation pueden hacer aplicaciones que la gente diga "wow!" (lo de "cualquier mamerto" va por mí: el Architecture Journal Reader, canejo jah!)

Que al comienzo las APIs sean realmente complejas obedece a dos razones:

• No están sus creadores lo suficientemente maduros en su entendimiento de las mismas como para poder ponerlo en términos más simples (para ello en realidad deben usarlas intensivamente de modo de extraer de esa experiencia las mejores prácticas), y
• Como corolario de lo anterior, en cierto modo la idea es privar al público masivo de un acceso irrestricto hasta tanto no se vean formas de encapsular esos mejores usos en APIs que eviten provocar un malestar generalizado con estos avances

Pero lógicamente, ya va llegando el momento y por ende la idea es poder brindar a las plataformas de desarrollo actuales de estas herramientas que allanen la curva de aprendizaje

Asistimos en estos días a una carrera en el segmento de las plataformas administradas (tanto Java como .NET) para cumplimentar este objetivo. Para hacer honor al tema del post, Paralelismo y Concurrencia, voy a enlistar lo que .NET y Java están armando al respecto en forma paralela y concurrente (jeh, soy un piola yo... )

Será hasta la próxima

 Una  de las principales razones por las que ha venido siendo tan dificil definir qué es un arquitecto es por la falta de acuerdo en cuanto a lo que un arquitecto debe hacer. Cómo distintas perspectivas le asignan a dicho rol distintas responsabilidades, por consiguiente el rol en sí mismo pasa a ser diferente según la perspectiva de donde se lo evalúe

Esto me empezó a dar vueltas en la cabeza estos últimos meses, ya que con Simon estuvimos trabajando fuerte en el número 15 del Journal de Arquitectura, próximo a aparecer (*). El tema de este decimoquinto número es, justamente, el Rol del Arquitecto

Como siempre hubo un call for papers (que tuvo lugar durante el pasado mes de Enero), y varias propuestas fueron recibidas, de las que escogimos unas siete u ocho. De estas seleccionadas fueron luego llegando los primeros borradores, por lo que puedo decir que me he pasado el trimestre que va terminando dando vueltas cuan pollo al spiedo alrededor del bendito rol que nos toca jugar

Y lo que puedo anticipar de la edición que estás por recibir es que, como era de esperar, varios artículos se parecen entre sí en el sentido que hablan de un personaje con el que nos identificamos; pero al mismo tiempo discrepan entre sí, porque le atribuyen responsabilidades o conductas que nos puedan sonar cuestionables

Entonces pensé que, como siempre, el origen de las divergencias se remonta a la clásica subdivisión del perfil de arquitecto en

• Arquitecto Empresarial (o Estratégico)
• Arquitecto de Desarrollo (o Soluciones)
• Arquitecto de Infraestructura

Yo asumo que esta subdivisión ya la manejás de taquito, pero si ése no es el caso, leéte este artículo de Simon que lo cuenta bastante claro

La clasificación no está mala y, sobretodo, no es algo que un solo vendor impuso sino que hay no sólo un consenso en la industria: el framework de arquitectura conocido como TOGAF (The Open Group Architecture Framework) considera cuatro Dominios de Arquitectura (Architecture Domains). Estos son, a saber:

• Arquitectura de Negocios (Business Architecture), mapeable al rol del Arquitecto Empresarial
• Arquitectura de Datos (Data Architecture), asociable -digamos- 65% al arquitecto de Infraestructura, 35% al de Soluciones
• Arquitectura de Aplicaciones (Applications Architecture), claramente terreno del Arquitecto de Desarrollo, y
• Arquitectura Tecnológica (Tecnology Architecture), la infraestructura propiamente tal

Pero no termina acá, también la IEEE a finales de los '90 dio forma a su especificación IEEE 1471 (forma corta de referirse a Práctica Recomendada para la Descripción Arquitectónica de Sistemas de Software Intensivo), un estándar tanto ANSI como ISO. Esta especificación define Puntos de Vista (Viewpoints) nuevamente asignables a los roles antes descriptos

Y sin embargo...

Esta taxonomía está bien para organizar información relacionada con estos -tomando prestado de TOGAF- dominios de arquitectura antes descriptos. Pero no tengo claro que en la práctica necesariamente se dé que haya, en una misma organización, arquitectos cubriendo estos roles. No estoy diciendo que esté bien que sea así o que esté mal, sino que en la medida en que estos roles van madurando, las organizaciones ya venían lidiando a su modo con las necesidades a cubrir. Como resultado, tenemos que

• Una misma persona cubre algunas actividades de uno o más roles, pero no todas las actividades que a ese rol le suelen asignar hoy los estándares
• Un dado proyecto en una determinada organización puede requerir cierto nivel de cumplimiento con la definición de una arquitectura, pero a un nivel de detalle que puede resultar escaso según las normas de otra organización
• Distintas organizaciones, partiendo de la base de que tienen distinto tamaño y diferente presupuesto de TI, lidian con distinto headcount (cargos a cubrir disponibles). Como resultado, las tareas de arquitectura a realizar se van a asignar al personal disponible (nuevamente conduciendo a que la relación entre roles y personas termine siendo cualquiera a cualquiera en lugar de 1:1, 1:n, m:n, etc

Me siento lejos de la postura de decir que si en la práctica las cosas se dan así, es porque algo esté saliendo mal. Me ha tocado trabajar en proyectos donde ciertas decisiones que afectan a la arquitectura estaban ya tomadas (por ejemplo, plataforma J2EE contra base de datos Oracle sobre ambiente Linux, etc). Siendo esas la