En el último newsletter de arquitectura (#13 quizá el número explique muchas cosas), los editores nos regalan su visión acerca de la manera de encarar la migración de arquitecturas OLTP a las “nuevas plataformas”.

(Nota: Si no tiene la newsletter, puede suscribirse enviando un mail a arnewssc@microsoft.com con el Asunto “suscribirme” aunque no sé si así puede obtener la copiar original del número 13)

Y digo nos regalan su visión porque en una enorme corporación como es Microsoft® siempre existen opiniones divergentes en temas no completamente técnicos como el que plantean, de hecho estoy seguro que existen muchas opiniones que respaldarán mi visión.

El artículo comienza con las causas por las cuales las empresas migran las plataformas a nuevas, un análisis rápido pero consistente sobre los motivos funcionales y técnicos que llevan a que las empresa inviertan en plataformas más modernas para sus aplicaciones transaccionales.

Y también plantea un hecho importante, que “se hace fundamental comprender en profundidad la arquitectura de la plataforma planteada” lo que también comparto hasta en la última de mis células, no es posible hacer una recomendación de plataforma sin conocer las implicancias de los productos/servicios que pueden verse involucrados en una solución.

Finalmente, y como si fuera una narración digna de un novelista latinoamericano, se refiere a la historia personal “el mes pasado estuvimos analizando y definiendo la arquitectura de un Switch Transaccional para entidades Financieras”.

Y se regocija con la fantástica idea de no recomendar Biztalk Server que era la inquietud del cliente para crear el Switch. Dice claramente “entendemos que la solución más eficiente pasa por implementar servicios .NET … Este es el camino que han seguido varios de nuestros clientes y socios”

Aquí entro yo, con mi humilde Biztalk en español a rebatir a los señores arquitectos del newsletter.

Para comenzar, quiero aclarar que no soy un fanático religioso de Biztalk J y que tampoco creo que una única solución cabe a todos los escenarios, quiero creer que en la recomendación al cliente primó el análisis del escenario concreto y realmente era mejor recomendar una solución implementada con servicios .NET antes que usar Biztalk Server y no estaba motivada para nada por la espuria necesidad de facturar más servicios de consultoría.

Pero lo que es equivocado del planteo de nuestros arquitectos, es la idea de que pueden extrapolar la solución de un cliente al resto de los escenarios.

Para empezar, deberían hacer un poco más de research, de hecho Microsoft tiene un caso de estudio de “switch transaccional para la industria financiera” que soporta 2 millones de transacciones al mes con un uptime del 99.92 (vea http://www.microsoft.com/southafrica/casestudies/elec_ecentric.mspx) y esto con Biztalk Server 2002, para una empresa que sigue funcionando todavía al día de hoy, por lo que asumo que aún es una solución exitosa (http://www.ecentricswitch.co.za)

Por otro lado, cuando extrapolan, enfocan el problema del switch con un análisis sesgado, donde la “ejecución directamente sobre el CLR” toma un rol importante.

No hay ninguna de las afirmaciones que hacen los arquitectos que justifiquen el uso preferido de una solución .NET pura con respecto a Biztalk.

En primer lugar, Biztalk es un producto .NET por lo cual de hecho ejecuta sobre el CLR aunque imagino que lo que querían implicar era que la performance bruta de los servicios podría ser mayor. Pero además el análisis olvida que los requerimientos de logging, tracing, monitoreo, conectividad y arquitectura básica de integración son capacidades que están presentes en Biztalk y en una arquitectura pura .NET hay que construirlos, ¿se imaginaron ya las capacidades de administración que necesitan construir para este tipo de aplicación?

Hoy día puedo generar instalaciones de Biztalk donde puedo soportar millones de transacciones en línea; la BM&F en Brasil y el Banco de Serbia en Europa son ejemplos de esto publicados por la propia Microsoft®.

¿Es válido sugerirle a un cliente que construya todos sus bloques de infraestructura cuando ya están construidos en un producto desarrollado y soportado por Microsoft®?

Yo creo que no, es exactamente el mensaje inverso al que damos con el Framework .NET.

Cuando sumamos todas las capacidades que necesito para crear un switch financiero robusto, hay solamente tres escenarios donde Biztalk Server no tiene cabida:

a)      Cuando el cliente es tan grande (y estoy hablando de muy grande) que justifica la creación de su propio framework de integración (es decir, tiene espalda para fabricar un Biztalk)

b)      Cuando el cliente es tan chico que no puede pagar Biztalk, y ahí verificaría si estoy en presencia de un “switch financiero” o algo que merecería otro nombre.

c)       Cuando los requerimientos de integración son homogéneos y dentro de la plataforma Microsoft, para un conjunto de mensajes y aplicaciones acotado y con tendencia a ser estables o a decrecer en cantidad de servicios y puntos de contacto.

Y admito prueba en contrario, puede haber otros casos que se me están escapando, pero Biztalk Server es el producto ideal para implementar un switch financiero robusto, escalable, administrable y disponible, prueba de ello son las compañías que ya lo han implementado, y otras compañías de la región que, mientras usted lee esto, lo están implementando. Si estaba pensando seguir el camino de nuestros arquitectos de la newsletter, lo invito a que lo piense nuevamente.