Donde Manda Jefe No Manda Arquitecto

 Hay  ocasiones en que, como arquitectos que somos, quisieramos tener la voluntad de elegir cómo concretar cada componente de la arquitectura que planeamos. Pero en cambio tenemos que aceptar decisiones ya tomadas de antemano, que en algunos casos no compartimos

Cómo lidiar con esas situaciones? Cómo, sobre todo, cuando sentimos que, de decidir ir por ese camino, el proyecto va a enfrentar serios riesgos -o bien durante el desarrollo, con demoras debido a complejidad procedural, o bien cuando esté en ejecución, por ejemplo en bajo rendimiento (performance)-?
Espero en este post explicar, mediante experiencias personales y de amigos cercanos, contar cómo me parece adecuado transitar estas situaciones
Hace tiempo atrás un arquitecto amigo me contactó para pedirme que lo ayude a encontrar argumentos para acceder a una base de datos vía JDBC, la API de programación para bases de datos de Java, en lugar de acceder a los datos como le exigían que lo haga: a través de la plataforma de mensajería transaccional BEA Tuxedo
 
Sobra aclarar que de entrada me excusé de tener que proveer argumentos "anti" un producto de la competencia: el hecho de que yo trabajara para quien lo hacía en seguida iba a teñir de duda cualquier argumento, por certero que pueda ser. En otras palabras, era parte interesada. No me podía meter
Pero en cambio, como en mis tiempos de arquitecto en terreno (el field, como se lo llama), había tenido que lidiar con situaciones similares, quería ayudar a mi amigo a descubrir lo malo y lo bueno de estas situaciones, para al menos asumir realidades difíciles de digerir
Entonces le pregunté qué lo hacía rechazar la posibilidad de entrar a los datos vía Tuxedo. Y me dió un par de argumentos. El primero discutible, el segundo más aceptable. Veamos:

  • "Entrar vía Tuxedo en lugar de hacerlo directamente va a afectar negativamente el rendimiento". A ver: seguro que el rendimiento va a ser menor. Ahora, que sea menor implica necesariamente que sea "mal" rendimiento? Analicemos antes que ofrece Tuxedo a cambio, que sirva para justificar pasar por él, recogiendo esos beneficios en el camino

    Como no soy un "Tuxedo evangelist", no voy a gastar mucha tinta destacando sus virtudes aunque al menos te paso un link donde las mismas están resumidas haciendo click acá

    Lo que quiero sacar como conclusión es, si el rendimiento al que tuviesemos que apuntar debiera ser siempre el mayor posible, más vale agarremos ya los manuales de Assembler

    Por qué nos enredamos en cambio con la lentitud del código interpretado de la Java Virtual Machine (JVM) o el equivalente Common Language Runtime (CLR) de .NET? Lo hacemos porque, alguien tiene ganas de volver a reservar y devolver memoria? Lidiar con punteros? Equivocarse apuntando mal? Interpretar mal un tipo de dato y que ni el compilador ni la aplicación ejecutándose se percaten y lo avisen? Acceder fuera del espacio de direcciones asignado? Arriesgarse a que le accedan desde un espacio ajeno al propio?

    La máquina virtual se encarga de controlar todo eso para nosotros, permitiendonos así implementar aplicaciones en tiempos (horas/hombre) impensables décadas atrás. La dolorosa, sí, viene por el lado de la ejecución, que será más lenta que lo que podría haber sido de haber codificado todo en Assembler o directamente código de máquina (alternativa que quizás ni hubiesemos terminado, a no ser de contar con una legión de desarrolladores)

    Para cerrar este punto, sí, es más lento, pero a cambio de lo que me dá, quizás me convenga bancarme esa lentitud. No sea tanto, después de todo, comparado con lo que recibimos

  • El segundo argumento establecía "Ir por Tuxedo implica una mayor complejidad, dado que para el desarrollador promedio es menos conocido que JDBC. Además es más acoplado al producto mientras que JDBC es abierto y permite el día de mañana cambiar entre diferentes bases de datos". Hmmmm… Comme ci, comme ça (en francés, "massomeno…")

    Vamos por partes, querido Tupac: la API de programación para BEA Tuxedo se llama BEA Jolt de la cual hay una buena introducción disponible haciendo click aquí. Sin necesidad de leerla entera, nada más mirarla por arriba, tiene más o menos los componentes esperados: conectores, requerimientos, respuestas (admito que no la usé para tener una experiencia real). Permite una definición de servicios que se guarda en un repositorio, en forma similar que una base de datos permite definir tablas, índices o procedimientos almacenados. Digo, no me voy a rasgar las vestiduras por aprender un concepto análogo a otro que ya conocía

    Respecto del acoplamiento, si con BEA Jolt nos acoplamos a Tuxedo, con JDBC nos acoplamos a que sólo una base de datos pueda ser lo que esté más allá. En otras palabras, si queremos tirar hipótesis fatalistas, qué si mañana deciden no tener una base de datos como back-end sino una aplicación provista por un tercero? Por qué siempre la lógica es que si hoy tenemos Oracle mañana pueda haber IBM DB/2? Si hoy tenemos SQL Server, mañana pueda haber Oracle, y así?

    Honestamente, hablando de clientes finales (no de empresas que desarrollan software, sino de empresas que tienen sistemas pero su core business es otro -financieras, telcos, manufactureras, etc-) cuántas veces te tocó vivir una migración de base de datos? Es de veras un peligro tan latente, tan probable? Qué pasa si pasa? Es decir, ya sé, hay que reescribir cierta lógica de manipulación de datos pero, qué pasa si hay que reescribirla? Siempre los procesos de migración tienen un costo, no seamos ilusos: lo van a tener

    He visto a desarrolladores JDBC programar comandos con solamente ANSI SQL, sin procedimientos almacenados (stored procedures) sólo para evitar vendor lock-in. Pero lo que no notaban es que estaban dejando de aprovechar características valiosísimas provistas por las bases de datos, potentísimas en términos de escalabilidad y rendimiento, sólo por no quedar clavado a ese motor de base de datos en particular (decisión de cambio que, en realidad, no se tomaba sino cada ciertos años, y con reservas, ya que cambiar implicaba tirar una inversión ya hecha y a la vez realizar una nueva!)

    En síntesis, aún programar en una API más conocida como JDBC, si lo que se pretende es indepencia del back-end, se puede llegar a resignar tanto que puede menguar los beneficios originales de un motor de base de datos en particular

    Un mínimo de dependencia no es tan grave, por lo menos yo lo veo aceptable mientras se esté sacando tajada de lo que hay más allá. Las aplicaciones, por muy desacopladas que sean, mueren por su propia vida útil. Yo no he visto aplicación que dure más de 5 años. Quiero decir, perdón: sí que las ví. Pero a lo que voy es que a partir del quinto año se hace evidente que querer prolongarla es arrastrar una mochila muy pesada. Suele pasar que la industria evolucionó tanto en técnicas como en herramientas, y persistir en el camino en el que se está implica desechar los últimos avances

    Lo quiero simbolizar con esta metáfora: tanto Japón como China fabrican productos electrónicos. Mientras que los japoneses son más caros, son también de una calidad superior y suelen durar varios años sin causarle al propietario -generalmente- mayores transtornos. La experiencia de usar productos electrónicos japoneses es tan buena, que normalmente no compramos una versión nueva y mejorada durante varios años porque la que ya teníamos, no sólo salió carita sino que además… anda así que hay que amortizarla!

    La electrónica China es de una calidad inferior (lo que se nota ya desde el exterior de sus productos) aunque tampoco es una pésima calidad. Es claramente peor pero en el corto plazo es aceptable. Los productos chinos se estropean más rápido y claramente hay que cambiarlos con mayor frecuencia. A cambio, atención, son definitivamente más baratos que los japoneses. Con lo cual es una filosofía de consumo diferente: pagás menos, más frecuentemente, pero permanentemente estás renovando

    Entonces el juego, en Arquitectura de Software, consiste en elegir astutamente cuándo regirse por el modelo japonés de consumo y cuándo por el chino

Obvio, todo esto a mi amigo lo perturbaba. Él quería verme tirar basura contra productos de la competencia ya que en ese momento lo necesitaba. A cambio me veía ponerme en la postura de abogado del diablo y salir a defender a su cliente
En realidad, lo que yo le propuse que haga fue que les plantée por escrito sus puntos de vista respecto de no entrar directo por JDBC a la base de datos, de modo que el día de mañana pueda estar cubierto a posibles reclamos de bajo rendimiento en ejecución, acoplamiento, etc (ideal que presente benchmarks comparativos para no hablar al gas, no?). Que les plantée también sus previsiones respecto del impacto que pueda tener en los tiempos de desarrollo el ir contra un producto no tan conocido (tanto por su API como configuración, etc)
A cambio, que pida -de ser posible por escrito- una justificación de la razón de "ir por Tuxedo" a la base de datos
Normalmente esas decisiones que llegan "de arriba" obedecen a apuestas estratégicas. En este caso podría ser la posibilidad de querer montar un bus de servicios empresarial que permita monitorear y controlar la actividad en tiempo real. Esa es una ventaja que Tuxedo provée, que de insistir en ir vía JDBC habrá que implementarla a mano. Y es carita! Por eso decía antes que hay que ser inteligente respecto de cuándo se quiera consumir productos japoneses y cuándo chinos


Yo también sufrí transtornos parecidos en el pasado:
 
  • Era un apóstol del eXtreme Programming (XP), metodología que me había traído notables resultados. Pero lo quise aplicar en una organización que si bien era chica, con muchos contactos cara a cara (lo que a XP le viene como anillo al dedo) tenía una cultura organizacional que no permitía la informalidad inherente a XP. Por ejemplo, yo podía estar discutiendo algunas user stories con un usuario en su oficina, con papel y birome (bolígrafo, en argentino). Luego quería usar esas conclusiones como documentación oficial del proyecto. Cuando el directorio me pidió ver la documentación y pelé los mamarrachos… tuve que urgentemente dejar de usar XP, cambiandolo por un mecanismo más formal (y burocrático). En tanto que mi credibilidad se vio seriamente afectada por tamaña intentona subersiva de romper algo tan valioso como el status quo (eso que nadie entiende por qué es así pero menos se atreve a plantearlo )
  • Entraba a una base de datos con Hibernate, ahorrando enormes tiempos de desarrollo en una capa de acceso a datos (tiempo que luego perdía inevitablemente escribiendo los xml de mapeos y decidiendo por eager loading o lazzy, sin ponerme de acuerdo nunca). Pero la cultura de la compañía era que a la base de datos sí o sí se entraba para invocar procedimientos almacenados (que a ese entonces el Hibernate no consumía, sino que generaba, on the fly, sentencias SQL que se compilaban al entrar a la base de datos cada vez). Y no hubo tu tía. Me lo hicieron dejar de usar (o de lo contrario me dejaban de usar ellos a mí)
Lidiar con las "órdenes de arriba" es duro, pero no es el apocalipsis. Son decisiones corporativas que aunque duelan, hay que amoldarse. No sin antes un debate previo a ver si es posible flexibilizar, pero estar preparado para la derrota. Y demostrar que uno es capaz de ganar el partido lo mismo
Esta entrada fue publicada en Software Management. Guarda el enlace permanente.

2 respuestas a Donde Manda Jefe No Manda Arquitecto

  1. Ariel dijo:

    Hola Diego,
     
    gracias por tus comentarios, me han sido de mucha utilidad. Trabajo en una empresa muy grande y me he encontrado con casi todas las situaciones que has comentado.
     
    Yo, al igual que tu, adicto al mate y viviendo lejos de la tierra materna. Si aún estas por Madrid, cuando quieras yo pago las cañas.
    Un abrazo,
     
    Ariel
     

  2. Diego dijo:

    Para decirlo en el idioma de la madre patria, "Venga! Hasta logo…"  😀
     
    Con un poco de suerte en unos meses vuelvo por "Madriz"

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