Otro Viejo Antipatrón: Repudio de la Infraestructura (Infrastructure Repudiation)

(El primer capítulo de esta serie de Antipatrones -Antipatterns– se llama "Demasiada Arquitectura" está disponible acá: http://diegumzone.spaces.live.com/blog/cns!1AD5096D63670065!367.entry)

 Pareciera  ser que, dado que el flamante rol de arquitecto de soluciones se ha consolidado y que los arquitectos de soluciones suelen ser desarrolladores senior plusquamperfectos (o sea, más que perfectos), un nuevo vicio se viene manifestando en las organizaciones y en empresas que desarrollan software: Fobia a la Infraestructura de Software de Base

La situación es la siguiente: se presenta una desafío tecnológico a resolver para poder implementar, sobre su solución, funcionalidades facilitadoras para el negocio. Existen, entonces, dos caminos para superar el desafío

 
  • Alternativa A: Echar mano a alguna pieza de infraestructura, un servidor de base de datos o de integración, una cola de mensajería, etc. Ya lista, madurada por la o las compañías que se dedican a comercializar ese tipo de productos. Para poder aplicarla, por ende, hay que pagar una licencia de uso del producto
  • Alternativa B: Ahorrarse el pago de la licencia al vendor de plataforma (no sin ahorrar acusaciones de usurero, buitre y chupasangre al mismo), desarrollando puertas adentro todos los componentes necesarios, agnósticos de toda plataforma comercial. Atención a este punto porque es importantísimo: por componentes necesarios se suele entender los componentes básicos necesarios para resolver el desafío. Y nada más que esos porque el objetivo es que los desarrolladores se dediquen a contruir… lógica de negocio (cierto, no?)

Se suele caer en el error de concepto de que la alternativa B es la más barata ya que descarta pagar por licencias de productos comerciales. Quiero mostrar acá (mostrar aunque no demostrar dado que no tengo números) que hay costos ocultos de desarrollar por uno mismo piezas de infraestructura

Normalmente las personas en la organización que deciden desarrollar estas piezas de bajo nivel o nivel intermedio, son empleados por tiempo indeterminado o empleados contratados directamente o a través de un tercero duranto el lapso de duración del proyecto. Los sueldos de estas personas salen, en última instancia, de las arcas de la compañía que lanzó el proyecto como un facilitador de su negocio

Las horas/hombre invertidas en desarrollar piezas de infraestructura son horas/hombre no invertidas en desarrollar las funcionalidades facilitadoras del negocio. Acá, nuevamente, se suele caer en el concepto de que las piezas de bajo nivel o nivel intermedio, en tanto que son requisito para poder desarrollar encima lógica de negocio, son ellas mismas facilitadoras de negocio. No voy a negar que sin ellas en el medio o al fondo de todo, la estructura final carecería de cimientos. Pero quiero establecer mi definición

"En tanto sean de propósito general, y reusables en más de un contexto u organización, son facilitadores indirectos que pueden conseguirse en el mercado"

Entonces, esas horas/hombre desinvertidas en el desarrollo de facilitadores directos, posterga la disponibilidad de la solución funcional que el negocio requería (sea para eficientizar sus canales, abaratar sus costos, tener mayor control para predecir tendencias y tomar decisiones, o una mezcla de todo ello)

El postergar la disponibilidad de la solución le hace perder dinero a la organización y acá nuevamente se suele incurrir en el error de que mientras la organización tenga balances favorables, no es que se pierda dinero sino que "se lo deja de ganar". Flor de consuelo de tontos: la misión empresarial de las organizaciones comerciales es ganar dinero. De hecho se incentiva a los empleados a contribuir maximizando las utilidades, mediante el pago de un bono por cumplimiento de objetivos

Pero hasta acá sólo le vimos un lado "no tan malo" respecto de dejar de ganar. Veamos ahora donde definitivamente la empresa empieza a perder: la sustitución de un producto o solución provisto por un tercero, mediante un desarrollo interno tiene secuelas a corto, mediano y largo plazo

A corto plazo, porque mantiene a varios profesionales de TI ocupados en la definición y el diseño y el desarrollo de esa pieza practicamente a tiempo completo. Y es una lástima que gasten cabeza en esto, tan poco que ver con el negocio al que la organización se dedica, siendo que terceros ya han analizado el problema y sintetizado estas soluciones comerciales erróneamente calificadas de excusa para sacarnos plata (como si las licencias las pagaran los empleados)

A mediano plazo, porque cuando se comience a desarrollar masivamente lógica de negocio sobre la pieza desarrollada internamente, surgirán necesidades de tuning (sintonía fina) que implicarán retrabajos (querés apostar? Si estoy escribiendo esto es porque el error que estoy criticando ya lo cometí y ví a otros cometerlo). Es en este estadío donde empiezan a surgir cortocircuitos entre los que defendieron a ultranza el desarrollo local, y aquellos que eran indiferentes en tanto lo que les den les simplifique la implementación de lógica de negocio. El principal motivo de fricción entre ambos grupos tiene que ver con las limitaciones que el "producto casero" impone, sea porque no se previeron algunas casuísticas, algunas necesidades extra, etc, y ahora sí ya no hay tiempo de enderezar el rumbo ni mucho menos de cambiarlo. Como consecuencia, algo remotamente, algunos defensores de la primera hora se van a permitir dudar de si fue acertado haberse embarcado en esta alternativa. Durante la puesta en producción surgirán necesidades de performance y escalabilidad que, quizás por falta de experiencia en desarrollos de soluciones similares, quizás por errores de estimación de stress -o directamente ausencia total de estimación- se pasaron por alto. En este estadío, los que aún no se habían cuestionado la decisión del desarrollo interno, ahora sí van a permitirse dudar. En cambio, los que habían empezado a dudar en el estadío anterior, a esta altura ya van a estar absolutamente convencidos de la embarrada. No van a faltar acá los picos de stress y las situaciones límites. Tampoco aquellos arquitectos que amaguen renunciar al no resistir la presión del grupo "resultadista" en términos del negocio. En realidad, este grupo querría echarlo pero a esta altura ya no puede: se habrá logrado independencia de IBM, Microsoft, Oracle, SAP, BEA, y los restantes grandes vendors. Pero se depende fuertemente del equipo que desarrolla infraestructura propia porque repudia la de los que la comercializan. Insisto: ven en ese acto de ganar plata una inmoralidad como si ellos trabajaran gratis

Finalmente, optar por desarrollar internamente la infraestructura tiene consecuencias a largo plazo por aquello que decía párrafos atrás respecto de que se suele acotar la lista de "componentes necesarios a desarrollar" por componentes básicos para ejecutar las transacciones en línea, obviandose todo aquello que tenga que ver con monitoreo y análisis. En concreto, se pone el énfasis en el procesamiento en línea transaccional (on line transaction processing u OLTP) y no en el procesamiento analítico en línea (on line analitical processing u OLAP). Cuando estas necesidades se hagan evidentes, último estadío que voy a mencionar, ya a nadie le va a quedar dudas de que el Frankestein que parieron amenaza con matar a todos los doctores Frankestein que defendieron el experimento. Y digo Frankestein para simbolizar la característica de engendro: como a largo plazo van a ir surgiendo necesidades no previstas ni remotamente en la primera ola, y como ya el negocio no va a poder seguir dilatando ese status de "dejar de ganar", la evolución de la pieza interna tenderá a ser desordenada, despojada ya de todo ese romanticismo inicial con bríos de independencia. A decir verdad, ya esa pasión inicial se va a ver perdida y realmente va a dar todo lo mismo. Me vienen a la memoria varios ejemplos que no me atrevo a mencionar porque si lo léen colegas míos van a saber que estoy hablando de ellos

Lo que sí, te invito de vuelta a que pienses, a lo largo de los meses, años, el dinero total que la organización va a haber destinado al desarrollo de esta infraestructura, cruzado con los pobres resultados que normalmente terminan recibiendo a cambio. Decime si no era más barato pagarle a los usureros por algo que funcione y que de veras los ponga en la senda de desarrollos "para el negocio"

Acá el secreto pasa por ser desarrollistamente concreto: cuántas más líneas de código desarrolles, más líneas de código quedan bajo tu responsabilidad. Algunos ven esto como un factor de status: si tenés una gran responsabilidad en las líneas de código, sos más grosso. Yo lo veo a la inversa: si tus espaldas tienen que sostener más líneas de código que las mías, vos te vas a ir a casa después que yo, por lo cual vas a tener menos tiempo libre para vos y por ende vas a ser también más medio pelo que yo. El mantenimiento de grandes cantidades de líneas de código es una mochila muy pesada que le va a hacer perder agilidad a la organización. Dicho en otros términos: pensabas que le ibas a ahorrar dinero a tu organización pero se lo vas a hacer perder, y vos mismo -que te va a tocar arrastrar la mochila- vas a estar pagando en gran medida por ese error

Conclusión y ejemplo

Esta crítica que acabo de hacer no es universalmente válida, aplicable a todos los casos. Quiero distinguir escenarios de alcance

  • Grandes cuentas, organizaciones de más de quinientos empleados, quizás con presencia multinacional. Zapatero a tus zapatos: a poner el énfasis fuertemente en el negocio. La tecnología debe ser definitivamente un habilitador crítico del negocio. Cuando digo crítico, digo que los sistemas deben ser de misión crítica: si fallan las capacidades de negocio de la organización puede verse seriamente afectadas. Para ello deben ser monitoreables (medibles, controlables), deben ser capaces de disparar alarmas o escalaciones de eventos ante situaciones anómalas (tanto del punto de vista técnico como del punto de vista del negocio y la relación con los clientes, proveedores o socios comerciales). Definitivamente estas empresas no se tienen que calentar por hacer la heroica ellos mismos
  • Pequeñas y medianas empresas. En la medida en que sus sistemas no sean de misión crítica, esto es, que puedan seguir operando manualmente en caso de no tener disponibles las aplicaciones pro-negocio, se pueden dar el lujo de hacer experimentos. No, mentira, no tienen tal margen: de dónde salen los recursos para pagar la epopeya si no de un negocio que ya por definición es chico? Las empresas chicas, como las grandes, para ser ágiles deberían apelar a soluciones lo más lista para usar posibles. El que se crea que hacerlo uno mismo ahorra plata, que vuelva a leer este post desde el principio
  • Empresas independientes que desarrollan software (independent software vendors o ISVs). Acá es donde suele perder gravedad la línea argumental que planteé a lo largo de este post. Veamos casos y casos:
    • El ISV está desarrollando un producto que desea colocar en varios clientes. Lo está construyendo para un cliente en particular, que fue quien se lo encargó, pero sabe que hay una necesidad de mercado respecto de la solución que está desarrollando y quiere plantearse como jugador de nicho (niche player) allí. Es probable que, en ese caso, el resultado deba ser agnóstico de la infraestructura, ya que los potenciales clientes pueden tener inversiones ya realizadas en infraestructura que no quieran desaprovechar. Esto puede ser relativamente cierto, pero no absolutamente cierto. Habrá clientes que no querrán volver a pagar por algo en lo que ya invirtieron, pero habrá quienes admitirán que la inversión la hicieron por algo específico, y está ajustada (tailored) a eso, por lo que dicha infraestructura no soportaría más carga y estarían dispuestos a invertir nuevamente en infraestructura similar mientras la solución se pueda aplicar inmediatamente
    • ISVs con un prestigio ya ganado, incuestionable al menos en alguna solución específica. En este caso, el ISV tiene algunos grados de libertad para ofrecer su solución con cierta plataforma base como premisa, o eventualmente cobrar por una adaptación. Claro, puede hacerlo si usa inteligentemente su prestigio y experiencia en implementación de su solución como factor de negociación. Esto no quiere decir que siempre vaya a salirse con la suya: una cosa es venderle la solución a la ferretería de la esquina y otra a la acería multinacional. El cliente grande va a ir a la mesa de negociación con sus espadas, y el partner con las suyas. Quién ganará? Aquel que más se pueda dar el lujo de vivir sin el otro. El otro, si le interesa el deal, deberá ir al pié para ganarlo. Incluso la gran multinacional del acero, para retomar el ejemplo que esbocé recién, podría llegar a aceptar reinvertir si el ISV tiene una solución lista que la acería necesita implementar ya para conservar agilidad en su core business

Cierre: la Arrogancia es un pecado capital, incluso si sos agnóstico . Termino con un ejemplo que se dio hace poco en el Foro de Arquitectura de Microsoft. Un arquitecto pregunta allí si había estrategias para implementar mecanismos donde las aplicaciones clientes de un sistema cliente servidor se enterasen automáticamente de cambios en registros maestros. En sus propias palabras, decía lo siguiente

"Cuando algún dato maestro es insertado por algunos clientes, debe estar disponible para todos los clientes y la aplicación servidora al mismo tiempo, y si otro cliente tiene ya abierto el formulario maestro, debe ser inmediatamente actualizado cuando otros clientes inserten registros en el maestro"

Diligentemente, más allá de las otras respuestas que mis colegas iban enviando, le paso información de la característica de suscripción a una consulta que ofrece SQL Server 2005, que permite recibir una notificación cuando el resultado de esa consulta cambie. La idea entonces, era que los clientes se suscribiesen a la consulta de los datos maestros sensibles, de manera tal que la base de datos les notifique ni bien se inserte un registro nuevo

Quien me hizo la pregunta se mostró interesado en la alternativa, pero me respondió en cambio

"Muchas gracias. Funciona

Pero qué pasa si quiero usar otra base de datos como MySql, Oracle, etc (…) Mi plan es darle la funcionalidad al cliente de que pueda elegir cualquier base de datos (…)"

Allí se prendió un arquitecto que respeto mucho, el israelita Arnon Rotem Gal Oz (que lleva escritas varias columnas de opinión en Dr. Dobb’s Journal), diciendole algo muy en línea con este post

"Si querés algo más genérico tendrías que hacer cierto laburo extra

(…)"

Arnon le puso un ejemplo posible con Windows Communication Foundation, pero quién abrió el thread respondió

"Pero tengo que usar nada más VB.NET o C#. Hay una forma de hacer la misma tarea en C# o VB.NET?"

Mirá acá como el pantano del que te hablé durante este post se va haciendo evidente. El tipo quería arreglarla programando. Fijate qué fácil iba pisando el palito de querer meter a garfio una solución casera, desaprovechando la capacidad lista para usar de SQL Server 2005, por no quedar anclado (vendor lock-in) a ese producto. Entonces intervine y le volví a contestar, para concientizarlo del Vietnam en el que se podría llegar a meter por querer salir adelante en esos casos por sus propios medios, desaprovechando lo que ya hay a mano. Te invito a que releas el thread acá: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=972163&SiteID=1

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

2 respuestas a Otro Viejo Antipatrón: Repudio de la Infraestructura (Infrastructure Repudiation)

  1. Pablo dijo:

    Muy bueno el post. Muy claro y concreto.
     
    Mas de una vez me he encontrado frente a escenarios como los citados y realmente esta bueno tratar de aplicar diferentes puntos de vista para intentar encontrar la solución que mejor aplique en cada caso (la cual no necesariamente suele ser "la mas barata" o "mas simple" a primera vista).
     
    Me tome la libertad de recomendarlo en mi propio blog.

  2. Diego dijo:

    Grande Pablo, felicitaciones a vos también por tu blog y aguante el software cordobés   ;-D
     
    PD: espero, eso sí, q no seas de Belgrano. Boca un sufrimiento… :’-o

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