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