¿Reactivos o proactivos con la nueva tecnología?

Cuando se trabaja desde la consultoría a empresas uno debe tener claro la actitud que se debe de tener ante la tecnología emergente y como reaccionar ante ella de cara a lo que se ofrecerá a nuestros clientes, es probable que si nuestro cliente es un banco y aun siguen anclados al COBOL no haya muchos incentivos para proponer cambios y nuevas tecnologías core según que áreas (*), pero si el rubro de clientes apunta a los mal llamados proyectos “llave en mano” o “time and materials” en que se espera colaboración el escenario puede ser muy diferente, y el modo de proceder tiene que ser acorde a el.

Un error demasiado frecuente es dejar que sean las necesidades inmediatas de nuestros clientes las que condicionen la adopción tecnológica en una consultoría, como consecuencia los fichajes se hacen basados en si el desarrollador tiene los skills de los proyectos que se están haciendo en este momento, lo cual permite ir dentro de la ruta segura… por un tiempo, aunque puede generar situaciones extremas en las que por querer atender a un “cliente importante” se realicen fichajes de emergencia, o un aprendizaje a marchas forzadas, sin garantía de que luego de que ese proyecto acabe habrá nuevo uso de esa tecnología, pero bueno… lo importante es que se consiguió llegar a ese cliente (**). Otra situación común es que ante un potencial proyecto nuevo se este preguntando al equipo existente “¿alguien sabe xxx?” lo cual denota una falta de mapeo sobre los skills del equipo, pero eso es otra cosa.

El caso opuesto se da cuando alguien se emociona por una tecnología que se vio en Internet, y no se vio la curva de adopción, por lo que uno puede terminar casi sin soporte en Internet pues eres uno de los pocos que usa la tecnología, paso con lenguajes e IDEs en los 90s y ahora pasa con frameworks de JavaScript.

Entonces ¿que hacer? La respuesta esta tal vez en el medio, pero de una manera proactiva, no dejar de mirar los avances tecnológicos, en lugar de estar pendientes de lo que usa el cliente, apuntar a lo que la tecnología actual y emergente puede hacer por solucionar sus problemas y sus necesidades de crecimiento, investigar y hacer pilotos aun antes de que haya clientes que pidan algo (eso evita que el requerimiento o el boom nos coja desprevenidos) y como decia Eduard no pretender dominar todo y por ende aspirar a todos los clientes.

Adicionalmente, una “ventaja” de no estar en USA es que hasta cierto punto se puede sacar partido del retraso en adopción tecnológica, pues da tiempo para ver por donde se están consolidando las tendencias y ser novedosos (con algo seguro) de cara a lo que se le puede ofrecer al cliente.

¿Que opinan? ¿Reactivos o proactivos?

(*) A pesar de tener el core en COBOL muchas organizaciones han desarrollado productos con nuevas tecnología que llaman a ese backend, así que por ahí pueden salir las innovaciones a proponer.

(**) si a veces se esta en esa tesitura es necesario dedicar buen tiempo al estudio de lo nuevo, y no pretender que todos los desarrollos son similares ni con igual riesgo.

No todo tiene igual riesgo

Mucho se habla de gestión de riesgos, ya sea en metodologías ágiles como en, cof cof, waterfall, y claro, mucho se colocan tablas y con una mayor o menor pericia se indican los impactos y probabilidades respectivas, hasta ahí “lo normal”.

Lo usual es que por lo usual los criterios de experiencia que se toman están basados en el tipo de proyecto: ERP, almacén, web o desktop o también en el grado de complejidad del negocio, estado de las relaciones con el cliente, primera vez, time to market etc, nada fuera de lo habitual.

El problema es que muchas veces la visión “de negocio” logra opacar al criterio técnico en un factor muy importante: no todas las tecnologías tienen igual riesgo, y no, no me refiero al hecho de que por ejemplo un consultor de SAP cobre mas que un diseñador gráfico (llevándolo a extremos), sino que las diversas tecnologías tienen diferentes niveles de disponibilidad de recursos de aprendizaje, lo cual quieras que no, impacta en las previsiones que se requieren tomar para un proyecto.

En algunos casos es evidente que hay muchos mas recursos (ojo, en este blog nunca hablamos de personas como “recursos”, ¿ok?) para SQL Server y Oracle que para Informix o Sybase, por lo cual el tiempo en que un equipo puede llegar a ser productivo en un proyecto con estas dos tecnologías “raras” es mayor, pero mal que bien se puede solventar con la experiencia previa en otros motores de base de datos, así que tenemos un riesgo ligeramente mayor, pero justificable.

Visto a este contexto debemos pasar a un diferente tipo de escenario, los frameworks o soluciones “listas para usar”, productos que se espera que puedan ser usados directamente por un usuario final, “casi” sin necesidad de desarrollo, pero claro eventualmente terminan pidiendose personalizaciones y como la aplicación tiene una API en un lenguaje “conocido” como PHP, C# o Java pues se empieza el desarrollo tomando los mismo criterios que cualquier otro proyecto a medida y .. ahi empiezan los problemas.

En concreto estas aplicaciones (concretamente los CMS que son con los que he tenido experiencia) presentan dos problemas que los hacen “bestias” diferentes a cualquier desarrollo a medida:

  1. Esfuerzo extra para configurar los entornos, tanto de desarrollo, como de producción, en el caso de SharePoint por ejemplo era muy complicado, tan así que no se podía trabajar contra un servidor compartido sino que cada desarrollador debía de tener una Maquina Virtual para tener un entorno de trabajo, todo lo cual involucraba un esfuerzo que no era trivial.
  2. Cambio de paradigma respecto a como desarrollar y/o depurar, pues aquí no eres tu desarrollando una aplicación, estas intentando construir algo sobre los cimientos que alguien mas hizo, y que le puso reglas que pueden ser no usuales (y sobre todo contraintuitivas), pero necesarias para que el producto funcione, lo cual deriva en una necesidad de conocimiento (y tiempo de aprendizaje) mas allá de cuan experto uno crea ser en el lenguaje en cuestión.

Queda claro que estos dos factores tienen alta probabilidad de incidir sobre el tiempo que le puede tomar al equipo implementar la solución, por lo que seria un grave error asumir proyecciones sin tomar en cuenta el esfuerzo extra mencionado, si, es difícil acometer estas cosas que nos dejan productos como Magnolia, Vignette, o SharePoint, pero al final son retos técnicos que terminan siendo superados, a menos claro que la dirección asuma que “.net es .net” y no tome en cuenta detalles como estos en sus proyecciones, ahora que si a estas dos cosas, se le suma la poca experiencia local, o poca documentación actualizada en foros, asumimos grandes riesgos que no podemos dejar de informar de antemano, y créanme, en el caso de CMS (salvo que tengas miembros del equipo que actúen como pilares del resto) siempre pasa algo de lo mencionado, por lo que debemos estar alertas, regresando al titulo de este post, no todo tiene igual riesgo (técnico).

La eterna búsqueda de lo que agrega valor a los proyectos

Hay lecciones que uno las recuerda como si hubieran sido ayer, y esta si bien ocurrió hace como 18 años, la tengo siempre en mente cuando surge algo nuevo, pero… empecemos desde el principio.

Era una clase de Lenguajes de Programación 1, la dicto el profesor Alejandro Muñoz (un Ing. Civil con bastante pasión por los temas de informática) y el tema que tocaba era C++, para ese entonces ya habíamos aprendido Pascal (algunos laboratorios habían sido bien largos), Fundamentos de Programación y algunas cosas muy interesantes en Algoritmos y Estructura de Datos, pues bien, la primera sesión no se trato de explicarnos que incorporaba C++ sobre su antecesor C (el cual habíamos visto en la primera parte del curso), sino para plantearnos como surge la Programación Orientada a Objetos, como una respuesta a la Creciente Complejidad del Software, el cómo los programas tenían cada vez mas y mas líneas de código, por lo cual la Programación Estructurada ya había tocado su techo, siendo la OOP la respuesta al ser una nueva forma de ordenar los proyectos, así como para enfocar el código hacia entidades mas cercanas al mundo real.

Y claro, aun faltaban pocos años para que el boom de Internet nos cogiera por sorpresa, pero ahí nos quedamos con esa idea, la OOP como respuesta a todo, pero por otro lado vemos la aparición de Visual Basic y su enfoque RAD, en el cual (¡oh herejía) la OOP brillaba por su ausencia, pero aun asi permitió el desarrollo rápido de soluciones que si las hacias en C++ hubiera sido recontra complejo, claro que luego a alguien se le ocurrió una buena idea: mezclar el RAD de Visual Basic con el orden de la OOP y surgió Delphi, y asi hemos visto una sucesión de nuevas respuestas (nuevos retos, recuerden), como comente hace un tiempo , pero quien lo expone mejor es Esteban:
La primera aplicación que hice en mi vida profesional, fue una típica intranet para una empresa. Todo el código y acceso a la base de datos, se ejecutaba en archivos ASP.
Luego me dijeron que está mal acceder directamente a las tablas de la base de datos desde el código, por lo tanto implemente store procedures para cada uno de los accesos a la base.
Luego me dijeron que está mal mezclar lógica de negocio y de presentación en el mismo archivo…..
…..pasé de tener un simple archivo ASP (o ASPX, o JSP) a tener que crear un archivo HTML, una clase model, una clase controller, una clase repository de acceso a datos con su respectiva interface, una clase service que maneje la lógica de negocio con su respectiva interface, una clase para test unitarios, otra clase para test de integración, aprender a utilizar (como mínimo y básico) un framework MVC, ORM, de Unit Testing, Mocking, de inyección de Dependencias y de autenticación.
Todo para mejorar la productividad y velocidad en el desarrollo de aplicaciones. Todo para que el “desarrollador no pierda tiempo en programar aspectos secundarios de la aplicación y se concentre en lo mas importante, que es la lógica de negocio.”.
No se ustedes, pero a mi este ciclo de evolución del desarrollo de software me parece que esta muy alejado de la palabra “productividad”.

Efectivamente, esos han sido los vaivenes y trends por los que hemos pasado los desarrolladores en los últimos 15 años, es que efectivamente una vez que nos terminaron de convencer acerca de la OOP, eso no fue suficiente, tocaba programar basado “en componentes” y de ahí todo lo que cuenta Estaban en su post.

Y si, si bien esa historia puede ser descorazonadora para quienes producimos software debemos recordar algo:
• Siempre se nos pedirá mas y mas funcionalidades, y mas funcionalidades significan mas líneas de código, osea mayor complejidad.
• El entorno donde correrá tu aplicación cambiara, no tiene sentido pensar en tu web como la antigua aplicación de facturas hecha en Fox, porque ahí entran diversos factores que por mas que la funcionalidad sea “similar” a lo que ya había, cambian totalmente la forma en que la tendrás que desplegar y por ende estructurar el proyecto, baste mencionar el tema de seguridad y todas las consideraciones de zona militarizada que eso conlleva.
• Es impredecible saber con que interactuaran nuestras aplicaciones en el futuro, pero está claro que aun a la clásica aplicación de facturación se le puede pedir integración con Google Maps para que te ayude a ubicar la dirección del cliente.
• No puedes estar seguro de cuánto tiempo vivirá tu aplicación, pero alguien tendrá que mantenerla, por lo que hay que tener consideración con el que le toque hacerlo.

Llegados a este punto debemos reconocer algo, muchas de estas modas, surgieron para afrontar los retos que iban surgiendo progresivamente ante problemas que antes no había, o que terminaron volviéndose mas repetitivos terminandose al final conceptos ya asumidos “por defecto”: OOP, Web, BD relacionales, SOA, etc; ahora bien, eso no quita que hubo muchas soluciones para necesidades inventadas, por lo que pasaron sin pena ni gloria (¿alguien recuerda los “behaviours” en IExplorer 5?).

Ahora bien, el problema que debemos afrontar es saber cuándo seguir o no una tendencia (ya me paso a mí con LINQ 2 SQL, pero pese a ello era claro que los ORM habían venido para quedarse) y sobre todo si esta aporta real valor a nuestra solución, ya exprese mis dudas respecto a los nuevos patrones de diseño, pero de nuevo Esteban nos ofrece su visión de porque algunas cosas se terminan imponiendo (sin necesidad): Assumptions Driven Development. Es que es así, implementamos por inercia cierta arquitectura (de moda) sin tener en cuenta cual es el escenario real para la cual esta tiene sentido, o porque esperamos que cierta condición se cumplirá en el futuro y para ello “hay que estar preparados”, y como bien se apunta en el articulo esas condiciones nunca terminan de cumplirse pero en el camino ya hemos agregado complejidad innecesaria a nuestro proyecto.

No es sencillo, la verdad, pero como dije al final algunas cosas vinieron para quedarse: OOP, aplicaciones distribuidas, nuevas interfaces de usuario mas ricas, interconectividad, y ante ello no queda sino tener la suficiente cabeza fría de saber si la novedad que estamos queriendo implementar en nuestro proyecto agrega valor o no al producto a ser entregado, si los retrasos y complejidad añadidos son superados por las ventajas futuras (a veces puede que no ), la cosa es no temer a la respuesta de un análisis hecho a conciencia.

Por ejemplo, estoy convencido que ciertas capas de las aplicaciones pueden beneficiarse muchísimo del uso de pruebas unitarias, componentes algorítmicos puros, formulas matemáticas, financieras, su determinismo es tan alto que una prueba unitaria de veras se luciría para probar el código, pero de ahí a querer una cobertura del 100% o plantearse el TDD como panacea para mejorar la calidad de los programas… me lo tomo con pinzas, a riesgo de que me llaman hereje indicando que he “missed the point”.

Ojo, nótese que prudencia no es pasividad ni conformismo, pues de lo contrario estaríamos como las empresas que siguen usando mainframes.

Si, es complicado, pero es mejor tener las cosas claras y no renunciar al análisis para saber separar la paja del trigo.

Mentores ¿dentro o fuera del proyecto?

La verdad es que no habia pensado en el tema, a pesar de tener una posición clara sobre ello, hasta que hoy en la mañana vi unos twitts que remitian a este twitt: “¿Debería ser el jefe de proyecto tu mentor? ¿Q figura es la q debería acompañarte en tu desarrollo profesional?”, lo cual me llevo a pensar en dos experiencias personales respecto a la figura del mentor…

Hace unos años di un cambio profesional, y con ello fue introducido a la figura de Career Manager, un profesional de rango mas avanzado en la organización, el cual debería ayudarte a identificar tus puntos de mejora para seguir avanzando, realizar la evaluación de desempeño (preguntándole a tus jefes, pues ojo a esto, el CM, salvo excepciones, no puede estar en el mismo proyecto que el supervisado), a la vez que proveerte de información de como se esta moviendo la organización, ademas de ser una figura informal de “abogado” en las relaciones con tus superiores.

Lógicamente que todo esto forma parte de un proceso mas o menos burocrático dentro de las organizaciones, pero que en el fondo tiene mucho sentido, pues gracias a mi primer CM pude aprender diversos detalles de la cultura de la organización, y conseguir apoyo para los planes de formación y sobre todo algo que siempre recordare, el como intercedió por mi cuando un responsable de proyecto quiso hacer una jugada con la imputación de horas.

Durante ese tiempo, también tuve ocasión de trabajar con colegas en las que su mentor era precisamente el Jefe de Proyecto, lo cual me intrigo haciéndome conversar informalmente con ellos a fin de saber que opinaban de la figura, sacando la conclusión de que si bien en este modelo el mentor, al ser tu jefe, tiene la información de “primera mano” sobre tu desempeño, no permite generar la suficiente confianza como para que haya una relación fluida en la que el mentorado pueda confiar totalmente sobre los problemas directos de la marcha del proyecto.

Tuve ocasión de comprobar eso directamente, pues al final se me designo sucesivamente como CM de dos programadores junior, así que ante el reto trate de ganarme la confianza de mi mentorado, explicándole lo que había visto en la organización, el enfoque de hacer las cosas y lo que se esperaba de nosotros, calculo que debí darle suficiente confianza, pues un día me llama prácticamente desesperado ¿qué había pasado? un analista se retiraba a otro modulo de su proyecto, dejandole a él parte de sus responsabilidades técnicas, lo cual le asustaba pues eran temas que solo había visto ligeramente, y claro, le asustaba decirle eso a su jefe de proyecto, por lo que luego de tranquilizarlo procedí llamar tanto al responsable de los CM como a su jefe para saber lo que había pasado, la cosa era sencilla, eran necesidades de negocio, estaban alerta de que era un reto, así que no habría tanta presión en un primer momento mientras se adecuara; así que con esa información me toco transmitirle un mensaje tranquilizador, lo cual funciono pues unos meses despues, cuando me toco proceder a la evaluación, me confeso que no era tan fiero el león como se lo pintaba.

Así que por esta experiencia directa, creo que un mentor o CM no debería (salvo coyunturas) ser directamente el jefe del mentorado, siempre queda un conjunto de cosas en la cual se necesita cierta confianza que tal vez no se pueda tener dentro del propio proyecto. Dicho esto, soy consciente de que cuando se avanza en la pirámide no hay tanto margen para asignar responsables que no sean los jefes directos, pero es algo que se debería procurar en la medida de lo posible.

Cuando el cliente nos ofrece el camino del crecimiento y … lo rechazamos

Hace 10 años me encontraba trabajando en uno de los CPIs (Centro Proveedor de Internet) surgidos al amparo del lanzamiento que hubo de Unired como un medio para tumbarse al entonces operador principal (tema de otro post) en el Peru. Como todo eso de Internet era nuevo mis labores incluian el ser Webmaster, dar soporte telefonico, ayudar en la supervision de los servidores (sin cuarto frio!!!) y eventualmente apoyar a los vendedores cuando tocaba visitar a algún cliente que requería mayor detalle técnico para convencerle de la compra de nuestros servicios que incluian:

  • Diseño de paginas web
  • Hosting y eventualmente housing
  • Configuracion de FTPs
  • Cuentas dial-up para conexion a Internet
  • Cuentas de correo usando POP3, (¿Webmail? que es eso?)

Recuerdo que en una de esas uno de los vendedores nos pidió a Percy (un compañero PUCP que habia entrado junto conmigo a practicar en ese CPI) y a mi a que le acompañáramos para ver a un potencial cliente, pues se veía bien interesante aunque el no tenia muy claro sus requerimientos. Fuimos al local del cliente ubicado en la Av. Pardo, donde explicando resulto que la situación del cliente era esta: ellos editaban una revista sectorial con muchos datos sobre las actividades (vinculadas a los procesos de negocios del rubro) que se iban a realizar en los siguientes meses, así que este cliente pensaba que la Web seria un mecanismo útil para que sus suscriptores pudieran ver los listados de actividades mediante criterios de búsqueda de acuerdo a sus necesidades, dando de esta manera un valor agregado en el servicio que proveía.

Esto que ahora suena como una tarea simple (consultas sin transacciones) en su momento era novedoso, no existían aun las aplicaciones web, los CGIs se usaban esencialmente como contadores y con suerte para rotar publicidad, pero aun así ese cliente tenia la visión de lo que se podía hacer al generar dinamicamente contenido personalizado, Percy y yo lo vimos entonces como una gran oportunidad asi que con el coordinador del área tratamos de empezar a estimar los recursos a utilizar y las posibles herramientas (Intrabuilder, Cold Fusion y los IDC de Microsoft surgieron como opciones), para toparnos con lo que nos dijo el Gerente: “No, no somos una empresa de desarrollo”, seguidamente nos propuso que trataramos de venderle el hacerle muchas paginas y tratar de volcar su contenido pero de manera estática.

Fuimos donde el cliente (ya muy desmotivados) y como es lógico, al cliente no le interesaba ese parche, ya tenia claro lo que necesitaba (cosa rara) y no iba a aceptar pulpo como animal de compañía.

¿Qué ocurría?, que esta pequeña empresa se sentía muy segura en tanto lo que hacia como proveedor de instalaciones de red, y entonces el nuevo rubro de negocio que era vender conectividad y paginas web, así que creía que no había que mirar mas allá en cuanto a ofrecer valor agregado a sus potenciales clientes. Que paso al final? que la empresa dejo el rubro de Internet, regreso al tema de instalaciones de red y vendió su negocio de CPI (con usuarios y todo) a Terra cuando esta empresa surgió (y de esta manera arrancar ya “grande”).

Siempre tengo esto como un ejemplo de oportunidad perdida para despegar en un mercado que esta emergiendo, ¿se habrán percatado ellos de lo que se le paso por las manos?

Joder con el puto AJAX de los cojones!!

Como decia un profesor en el IE “mis muertos los cuento frios”, asi que recien ahora puedo contar algo de mi experiencia profesional reciente, que espero que sea de utilidad para el que le interese la gestion del desarrollo de software.

Con todos estos años de practica, algunas cosas se te quedan claras en base a las experiencias pasadas y tratas de aplicarlas en la medida de lo posible, lamentablemente a veces no se esta en la posicion de aplicarlas y este fue el caso.

Como decia, algunas cosas se te quedan claras y con fundamento, en este caso tenia claro que avanzado un proyecto no es conveniente meter una tecnologia nueva salvo que: Estuviera focalizada en un sector con poca interaccion con el resto de la aplicacion, o que estuviera claro que fuera completamente compatible y/o evolutiva de la tecnologia empleandose en ese momento.

Pareceria una politica simple y razonable de seguir, pero quienes estan en informatica sabran que estas dos palabras no estan precisamente a la orden del dia en la gestion de proyectos, aunque debo reconocer que he tenido jefes que sin tenido la habilidad suficiente como para llevar razonablemente el proyecto y los intereses de los stakeholders.

Se trataba de una aplicacion Web para uso interno, donde como consecuencia del alto numero de datos a ingresar eran frecuentes las idas y vueltas al servidor, ocasionando un efecto de parpadeo o “pantallazo” que era incomodo para algunos usuarios. Sin ir al detalle tecnico (conocido para quienes conocen esta tecnologia) sabran que este efecto es consecuencia del modelo que trajo ASP.NET el cual es necesario para brindarnos una facilidad de desarrollo que habiamos perdido cuando se paso de la Programacion Visual (con VB, Delphi o PowerBuilder) a desarrollar para la Web (quien ha programado CGIs, ASP Clasico o PHP3 sabe de lo que hablo).

Lamentablemente las quejas salieron cuando la estructura de la aplicacion estaba completada en un 80%, asi que poco se podia hacer (yo proponia aumentar la capacidad de procesamiento del servidor), hasta que alguien planteo la posibilidad de usar lo que recientemente se ha dado por denominar AJAX (aunque las tecnologias base han estado disponibles desde hace tiempo) para solucionar el problema y claro …. se dio el visto bueno a dicha propuesta.

Como ya he comentado la aplicacion ya habia avanzado bastante pero aun faltaban ajustes finales, por lo que se inicio un desarrollo paralelo, por un lado se trataba de replicar en AJAX la funcionalidad existente, y por otro lado se continuaba el refinamiento en la tecnologia actual hasta llegar a un punto de convergencia para integrar las modificaciones hechas en paralelo (las cuales tenian que apuntarse con sumo cuidado).

Cuando correspondio a que se manipulara mis modulos recien cai en la cruda realidad, trabajar con AJAX (al menos en la version que se utilizo) involucraba un paso atras en lo que habiamos ganado en funcionalidad de desarrollo con ASP.NET (si quieres la explicacion marciana ve al final del articulo) siendo mucho mas complicado depurar la aplicacion obligandote a mantener un doble juego de variables y de logica de la pantalla, ya que como la tecnologia se inyecto estando la aplicacion avanzada no hubo alternativa, siendo otra la situacion si se hubiera tenido un desarrollo en AJAX puro desde el principio o con modelo ASP.NET como lo teniamos.

La desesperacion para tratar de ajustar y que vuelvan a funcionar cosas que YA ESTABAN BIEN nos llevo en algunos momentos a decir la frase que titula este post, porque de veras…. era desesperante que cosas sencillas como asignar u obtener el valor de un control de una variable fuera algo complicadisimo.

En honor a la verdad debo decir que el proyecto salio adelante y ya esta en produccion, pero no dejo de pensar que los dos meses (como minimo) que se agregaron al proyecto multiplicado por el coste de 2 recursos (igualmente como minimo) hubiera podido alcanzar para la adquisicion de un mejor servidor, sin el inconveniente de la poca mantenibilidad que adquirio el proyecto.

En resumidas cuentas con ASP.NET uno se acostumbra a manipular directamente los valores de los diversos controles que estan en la pantalla, con AJAX tareas simples como requerian la regeneracion de un XML con el conjunto de valores de los controles, siendo necesario implementar funciones (mas complejas) para recuperar los valores utilizados pues los valores que usa por defecto ASP.NET se vuelven completamente inutiles, mas aun: como en este caso teniamos logica duplicada en ciertos momentos debia hacerse una multiple verificacion para saber que conjunto de variables estaba informado, so pena de que la aplicacion fallara.

Futura fusion del Banco Wiese y el Sudamericano …. y?

Al despertar veo los titulares y me entero de que el ScotiaBank comprara el Banco Wiese Sudameris (BWS), noticia que usualmente seria solo el cierre de una cadena de anuncios, marchas y contramarchas, pero que ahora incorpora el hecho de que esta adquisicion incluye una fusion a mediano plazo entre el Banco Sudamericano (cuyo accionista fundamental es precisamente el ScotiaBank).

Quedan pendientes muchos temas, plazos de la fusion, el destino de los empleados (otra ola de despidos en ciernes como cuando lo del BSCH??), el pago del aval que emitio el Estado Peruano, los nuevos dueños dan unas breves pistas sobre estas cuestiones, pero no mencionan un tema que es de mi particular interes: la integracion de sistemas.

Es sabido que cada organizacion (y mas una del tamaño de un banco) en el conjunto de los años ha desarrollado e invertido en una arquitectura y conjunto de plataformas para dar soporte a sus operaciones, dependiendo de cuan innovadora o conservadora sea esta organizacion cada paso se medira con ciertos criterios, atendiendo entre otras cosas a criterios de compatibilidad con las plataformas anteriores y particularmente en el caso de un banco a no afectar las operaciones de la organizacion.

Hay ocasiones en las que una organizacion decide (o la falta de soporte decide por ella) que sus plataformas legadas no son convenientes para servir de apoyo a los nuevos retos que tendra que afrontar, decidiendo la migracion a alguna nueva arquitectura; tradicionalmente han sido los bancos y empresas afines las mas “reacias” a tomar esos riesgos, medida comprensible en parte por la criticidad de sus operacion y por otra parte por la presion ejercida por los proveedores (interesados en no perder la respectiva cuenta). Consecuencia de lo anterior es que la introduccion de nuevas tecnologias se hace de manera evolutiva y por capas, asi que por mas que veamos que un banco tiene unos super terminales en sus oficinas y una modernisima aplicacion web es mas que probable que lo que este dando soporte a esa operaciones sea un mainframe….. modernizado y todo pero que no deja de ser tecnologia de mas de 20 años.

Recuerdo particularmente que a mediados de los 90, un profesor mio de Ingenieria de Software nos decia a proposito de la apertura de nuevos bancos en el Peru que esto era “una oportunidad para que un banco empiece desde el principio utilizando tecnologia actual”, ingenuo de mi lo crei por unos años hasta que converse con una amiga que trabajo dando servicio a algunos de estos bancos quien me conto que la realidad era otra: como varios de estos bancos eran de origen extranjero lo que se hizo basicamente fue copiar la arquitectura de las matrices a la hora de establecer los nuevos bancos peruanos, y ya se imaginaran … los flamantes nuevos bancos basaban sus operaciones en… COBOL (lenguaje de programacion originado en los 50s)!!!!

Teniendo en cuenta esta realidad sobre las plataformas base, hay algo que por fuerza rompe los esquemas y es el caso de una integracion como la que motiva esta nota. Ingenuamente creia que en el momento de la fusion se evaluaba cual de las plataformas a integrar era mas conveniente no tanto por solvencia tecnologica, sino por volumen de carga actual (cual de las dos org. mueve mas informacion dia a dia) y flexibilidad para dar soporte a la mayor parte de los modelos de negocio de la otra organizacion, pues no, la realidad es mucho mas prosaica y simple: politica y poder. Vale decir que quien pone la plata decide cual es el camino, asi que para esto contare dos casos que he visto mas o menos de cerca para ver la realidad (comprenderan que no mencione nombres, pero son caso veridicos).

A tiene mas operaciones que B, A usa una plataforma solida, difundida y con respaldo, B usa una plataforma que tuvo sus 15 minutos de fama en los 80 pero que en los 90 tuvo que ser adquirida por otra corporacion que no innova esta linea pero al menos da soporte. B “la pequeña” es adquirida por una corporacion internacional que la usa como puente para la adquisicion de A. Resultado: la plataforma de B sera el soporte de la nueva organizacion AB causando problemas (transaccionales y de drivers por si te interesaba la marcianaba) a la hora de portar los desarrollos hechos por A.

La corporacion M decide adquirir a “n”, una empresa pequeña dentro de su sector, la cual habia desarrollado una logica de negocios agil que habia permitido una cierta rentabilidad y bajos costes, en la integracion se informa que la plataforma de “n” sera dejada de lado y se usara la de M casi 10 años mas antigua, usando un modelo de datos que no cubre totalmente las necesidades de logica de negocio que dieron agilez y rentabilidad a “n”, a usar calzador se ha dicho.

Visto estos antecedentes uno ya puede preveer cual sera el futuro de esta integracion, el BanSud marcara la pauta tecnologica de la nueva organizacion, no importando si la del BWS pueda ser mejor (que no lo se), el tamaño de la cartera de clientes, el volumen de operaciones ni la implantacion a nivel nacional, esa es mi apuesta, ojala me equivoque y primen mas los criterios tecnicos y no politicos.