Banksphere, el entorno de programación que hará que te suicides o que des con tus huesos en el frenopático

Banksphere

Banksphere

Banksphere es un entorno e-business de desarrollo de aplicaciones orientadas a sitios web de entidades bancarias; vamos, que no es un andar por casa de la programación informática, sino la meta de cualquier gurú desequilibrado que haya perdido sus facultades mentales y quiera acometer la “sencilla y amena tarea” de hacer los programas que manejan el dinero del resto de los ciudadanos.

Y no es que el tema bancario sea excesivamente complicado, que lo es (y mucho), sino que Banksphere parece complicarlo todavía un poco más, algo así como un valor aleatorio entre un seiscientos y un seis mil por cien, grosso modo.

El dudoso orgullo de ser la progenitora de esta plataforma lo tiene la empresa ISBAN (Ingeniería de Software Bancario), una compañía española que forma parte de la División de Tecnología y Operaciones del Grupo Santander, y que desarrolla este software y otros del estilo para su empresa matriz.

Surgido en el año 2002 y basado, entre otras cosas, en J2EE (o eso es lo que dicen, supuestamente), Banksphere consiste en un conjunto de herramientas utilizadas para dar soporte a la metodología de desarrollo e-business del Santander. Es una suerte de métodos y arquitecturas compuestos por herramientas de desarrollo y una plataforma de ejecución. Cubre absolutamente todo el proceso y metodología de desarrollo de una aplicación: funcionales, DDS, casos de uso, creación de maquetas, modelo lógico, modelo físico, despliegue y cambio de entorno.

Pero el problema principal de Banksphere es el odio visceral que despierta entre sus programadores por la complejidad del sistema, lo abstracto que resulta de manejar y el montón de problemas y errores que presenta. Dicen que el producto final son aplicaciones Java, pero no pueden ser tratadas como tales; la mayor parte de las veces, los usuarios terminan editando a mano oscuros ficheros XML no documentados; los numerosos cambios y parches aparecidos han obligado a deshacerse de código y a reprogramar funcionalidades; dicen los expertos que solo el documento que explica cómo hacer un Hola Mundo tiene 80 páginas (aunque no existen manuales oficiales).

Banksphere (clic para ampliar)

Banksphere (clic para ampliar)

Todo esto, y mucho más, hacen de Banksphere una tortura. Algunas de la frases que se pueden recopilar de aquellos que lo han intentado evidencian toda un representación sobre lo que estamos hablando: “Debe de haber tres personas en el mundo que entiendan la arquitectura, el resto de los mortales se dedica a seguir una serie de truquillos para resolver todos los problemas“; “Solo ves pelotas de colores, las cuales mueves grácilmente por la pantalla, y arrastras mapeos que no sabes si son datos, objetos…” (haciendo clara referencia al módulo Vega, un componente para crear aplicaciones de forma visual con diagramas de estados y componentes varios); “No ves las conexiones a bases de datos, con lo cual, saber dónde estás apuntando y por qué tus datos no son iguales a los de tu compañero es realmente divertido e imposible al mismo tiempo“.

Otros enunciados de gente implicada son aún más esclarecedores: “Actualmente, mi salud mental ha mejorado y trabajo felizmente en Java”; “Llevo casi un año con una migración y te juro que un día de estos me suicido“; “Llevo unos cuantos meses en eso y es lo peor que he visto en mi vida“; “Soy arquitecto J2EE, domino XSLT, XML, Java, etcétera, pero esta mierda no hay quien la entienda“.

Banksphere cambió de nombre en el año 2008 para intentar escapar de aquella mala fama que se había creado. Desde entonces se están usando los nombres Alhambra y Partenón para identificar sistemas basados o relacionados con Banksphere. Y, realmente, parece que la cosa ha mejorado un poco (muy poco). En 2013, después de años de evolución y procesos de reingeniería, se dieron indicios de que el funcionamiento interno pudo haber mejorado, posiblemente debido al creciente respeto a los patrones de diseño y a los fiascos producidos años atrás en el proyecto).

Banksphere (clic para ampliar)

Banksphere (clic para ampliar)

Banksphere es una de las plataformas informáticas más criticadas en la comunidad de desarrollo, y mira que existen lenguajes esotéricos raros de cojones. Actualmente hay desplegadas más de 160 aplicaciones desarrolladas con Banksphere en los distintos bancos del Grupo Santander (la mayoría aplicaciones usadas en oficinas y en las intranets del Grupo). También, toda la arquitectura de call centers está desarrollada en esta plataforma.

En fin, un entorno que tiene su propia entrada en ingenio2010.com (una wiki que monitoriza las peores aplicaciones expuestas al público y documenta los desastres y sus principales responsables técnicos y políticos) y su entrada en la humorística Inciclopedia. Además, y como no podía ser de otra manera, también tiene su propia versión meme del vídeo del niño loco alemán (a continuación).

3 comentarios a “Banksphere, el entorno de programación que hará que te suicides o que des con tus huesos en el frenopático”

  • […] Banksphere, el entorno de programación que hará que te suicides o que des con tus huesos en el fre… […]

  • Información Bitacoras.com

    Valora en Bitacoras.com: Banksphere Banksphere es un entorno e-business de desarrollo de aplicaciones orientadas a sitios web de entidades bancarias; vamos, que no es un andar por casa de la programación informática, sino la meta de cualquier gurú de..…

  • Pero el problema principal de Banksphere es el odio visceral que despierta entre sus programadores por la complejidad del sistema:

    “[…] sino la meta de cualquier gurú desequilibrado que haya perdido sus facultades mentales y quiera acometer la “sencilla y amena tarea” de hacer los programas que manejan el dinero del resto de los ciudadanos […]”

    “[…] Pero el problema principal de Banksphere es el odio visceral que despierta entre sus programadores por la […]”

    Tú lo has dicho. Visceral. Desde las vísceras, que es donde se van acumulando las frustraciones y las rabias acumuladas para todos aquellos que hemos tenido la mala suerte de ser captados para trabajar con esta aplicación.

    Las diferentes versiones de BankSphere son una huida hacia adelante para tratar de levantar un sistema estable a partir de una idea original que es buena.
    A partir de dicha idea original, lógica en su concepción, y tratando de diseñar modelos SEGUROS de intercambio de información interno (dentro de un entorno de transacciones bancarias, ésto es importante, no sólo debe ser seguro de cara al cliente, sino que debía proteger a nivel interno, -qué ocurre si un desarrollador, o un empleado con nociones sobre el sistema decidía atacar sus vulnerabilidades-).

    El cortoplacismo de los directivos de ISBAN, destinado a satisfacer los plazos de inversiones multimillonarias (y llevarse el dinero a la saca) por parte del centro neurálgico del Banco Santander (conocedor de la importancia estratégica de poseer un entorno de desarrollo propietario de aplicaciones, Y ABSOLUTO DESCONOCEDOR DE LAS NUEVAS TECNOLOGÍAS), dio como resultado una serie de versiones que, por la naturaleza de su producto, jamás iban a poder satisfacer la demanda de sus usuarios, ya que el número de contextos de los clientes crecía exponencialmente (tanto como las permutaciones de los componentes físicos y lógicos, tratando de satisfacer, además, los nuevos contextos para tecnologías moviles). Además BankSphere, como digo, debía ser seguro para todos los contextos de aplicación.

    Cada versión de ISBAN satisfacía al cliente, el Banco Santander, en los plazos pactados (probablemente porque, la carrera a nivel internacional ya había empezado hacía muchos años). Allí donde un plazo de entrega coherente debía ser 9, ISBAN decía 6, y el Banco Santander decía 3. Se imponía siempre la lógica del dinero. El Banco Santander estaba desesperado. No ya por ganar la carrera, sino por seguir dentro de ella. Por lo tanto el Banco Santander imponía sus plazos a golpe de chequera. Todo ello sin tener nadie ni puta idea del terreno que estaban pisando.

    ISBAN resolvió quedarse con la gran parte del pastel, los directivos con sus sueldazos, destinando salarios apetecibles a jefes de proyecto que se callarían la boca una vez que viesen el salario bruto que iban a recibir, y cuyos recursos humanos irían haciendo agua en el magma de la inestabilidad del sistema. Además hay que decir que, casi con total seguridad, dentro del contexto bancario, donde la seguridad es condición extrema (casi más que el producto en sí mismo), la mano derecha no sabía qué hacía la izquierda, con lo que además, hubo descoordinación entre las distintas partes del sistema.
    Se necesitaron más sólo para encarar el contexto en evolución creciente, más bugs iban surgiendo, más inestabilidad… más descoordinación… más necesidades… más dinero… y nadie sin cabeza que pudiese arrojar luz sobre la tremendísima bola de nieve que seguía creciendo y creciendo.
    Factorías de desarrolladores surgiendo por “todas partes”, con demandas de clientes, y con el conjunto de arquitectos de ISBAN desbordados y locos apagando un fuego por un lado para ver cómo ese fuego u otro surgía en otro sitio. Desarrollando versiones que eran meros parches, y componentes que darían lugar a incompatibilidades y a nuevos fuegos.
    Todo ésto allí donde los verdaderos músculos, los programadores (tanto desarrolladores como arquitectos), eran sobreexplotados hasta el extremo por sus responsables (guiados unos por la codicia, otros por la simple necesidad de satisfacer las demandas en su cadena de mando) para tratar de dar solidez a una gran balón de aire, BankSphere, que fue el resultado de una buena idea y un mal desarrollo.

    Sería algo así como si la máquina de Vonn Newmann hubiese sido implementada no usando una lógica binaria, sino ternaria, por el simple hecho de que al que le tocó implementarlo, lo hubiese hecho usando lógica ternaria, por el simple hecho de que aquél que disponía del dinero para llevar a cabo dicho desarrollo, le diese suerte el 3, y el 2 no le gustase… imaginad las consecuencias de cara al desarrollo de componentes electrónicos, el kaos, la falta de rentabilidad.

    El supersticioso con la chequera ilimitada sería el Banco Santander, e ISBAN sería el implementador que, o no pudo o no tuvo los cojones a decir “eso no se debe hacer”, cogió el fajo de billetes, y se lo metió en el bolsillo.

    El desarrollo de BankSphere como sistema viene a ser lo mismo. Un objetivo claro y sencillo (diseñar un sistema seguro y con capacidad de crecimiento, de desarrollo de aplicaciones bancarias en un contexto competitivo), se ha materializado en un sistema que usa el 95% de sus recursos a resolver sus propias inconsistencias para escudriñar entre sus oscuras librerías desarrolladas a martillazos en el manejo de excepciones, aquello que el cliente necesita, que a grosso modo… no es más que una puta página web!.

    El resultado, efectivamente, como has comentado, es un manual de “hola mundo” de 80 páginas, cuyo proceso de compilación, nos da varios cientos de miles de warnings y decenas de miles de errores (textualmente), y no nos garantiza el éxito de dicha compilación, sino que perfectamente podríamos necesitar compilar o ensamblar nuestra aplicación en 2 o 3 ocasiones, sin modificar ni una línea de código, tan sólo compilar… para obtener un resultado positivo, que no el deseado.

    Para un proyecto con una complejidad mínima, el número de warnings y de errores en la compilación puede perfectamente superar los varios millones. Decir también que estas cifras son cifras internas que no significa que no se pueda obtener un ensamblaje final, sin embargo estas cifras son indicadores exactos e inapelables de la constitución del sistema en su interior. Son cifras cuyas interpretaciones no admiten discusión. Cualquier argumentación en favor de su viabilidad como solución estable, y continuar el desarrollo de versiones usando este modelo, no son otra cosa que manipulaciones, y apagar fuegos usando gasolina.

    Bueno, y entonces, una vez visto y analizado el contexto histórico/comercial en el que es viable golpe de talonarios de ignorantes recogidos por putos chapuzas, la aparición y el mantenimiento de un sistema de desarrollo irreal, ineficaz, inestable e improductivo, que ni siquiera solventa la necesidad de la abstracción al código por parte de los desarrolladores, con una exigencia constante de producción de webs corporativas en factorias de desarrollo externalizadas a ISBAN, … la pregunta siguiente debería ser: “a pesar de ello, hay una demanda de producción que es clara y que debe ser satisfecha, ¿cómo a pesar de todo es posible satisfacer esta producción? ¿Quién se come esa mierda?”

    Y aquí cuando vi la respuesta a esta pregunta y se cerró el círculo, mucho tiempo antes de poder escribir un texto donde poder sintetizarlo, es cuando a mi me entró el acojone y salí de allí literalmente pitando. Salí por patas y sin mirar atrás.

    Nosotros los desarrolladores teníamos a nuestra disposición un sistema desconocido sin documentación, cuyo rendimiento de producción escasamente alcanzaba el 10% de las horas trabajadas, donde prácticamente el 85% del tiempo se trataba de llevar hacia adelante un proyecto cuyo avance se obstruía por fallos achacables exclusivamente al propio sistema de desarrollo. Esta cifra no iba a variar dependiendo de los conocimientos del programador, porque BankSphere era una mierda y para rentabilizar los tiempos de ejecución de aquello eran necesarios procesadores que todavía hoy no se han inventado, y cantidades de memoria RAM que se empiezan a ver hoy, con canutos de ancho de banda para la comunicación con los sistemas de almacenamiento masivo que incluso hoy se me antojan ridículos.

    La única forma de aumentar la producción, era, efectivamente, poner a más programadores en más ordenadores. Programadores relegados a meras funciones de tiradores de cajas! ojo. Y encontrarse con la suerte de que algunos de estos tiradores de cajas, además, tuviese cualidades y le quedasen ganas y energía para poner parches sobre códigos xml o javascript autogenerados. Suerte de la cual, sabiéndolo los gerentes o no, iba a depender al menos el 25% de la producción efectiva de aplicaciones. PERO! tiradores de cajas, pagados como tales… eso sí, sobre los que se descargan las responsabilidades sobre la producción, y cuyas cabezas son las primeras en salir rodando.

    Efectivamente, el peso recaía sobre los desarrolladores que, para colmo de los colmos, jamás, y lo repito, jamás iban a poder reutilizar sus conocimientos adquiridos sobre este sistema opaco por su ineficacia. Todo lo que se aprendía en aquellas factorías era para nada. No servía absolutamente de nada. Y para colmo, la producción, el mismo objeto producido ni siquiera era un producto creativo… aquello, lo pintasen como lo pintasen fabricaba páginas webs! con un formato específico, que se interconectaban con servidores bancarios internos que manejaban dinero (un conjunto de variables concretas!).

    BankSphere era un sistema vampiro que extraía todos los recursos de aquello con lo que entraba en contacto. Los recursos del PC, poco importaba el procesador o la memoria, los consumía todos. Consumía la paciencia y la inteligencia del desarrollador, que quedaba sumiso a condiciones de desarrollo inexplicables e inaceptables. Consumía todo el dinero que recibía tanto para el diseño y rediseño de su propia arquitectura y parches, como para satisfacer las necesidades de los grupos de desarrolladores… y además, desde el momento en el que era necesario que los desarrolladores tocasen el código autogenerado, se confirmaba que BankSphere no hacía su trabajo!!! ni siquiera funcionaba!!! Todo el mundo estaba tan ocupado en satisfacer los plazos de entrega y en tratar de diseñar una estrategia para minimizar el impacto de los errores que provocaba… que nadie se daba cuenta de que no funcionaba!!! Todo el mundo estaba tan frustrado y cabreado que absolutamente nadie parecía tener en cuenta de que, lo que al final salía adelante, no era por el propio BankSphere! sino gracias a la pericia de programadores expertos que, después de mucho zurrarse con el sistema, habían visto exactamente en qué puntos se encontraban los cuellos de botella o los punteros a ninguna parte!!! pero no por el hecho de poder conocer BankSphere por dentro, sino porque conocían la naturaleza del producto que querían ofrecer, y deducían en qué punto habían metido mierda los arquitectos…

    Como consecuencia del nivel de frustración por parte de los desarrolladores se convertía en una puta jungla. Externalizados malpagados con formación de programador, frustrados por no poder aplicar sus conocimientos, o sin formación apenas, tratando de aprender algo, en un “juego de las sillas” por obtener un puesto estable, en un entorno en el que no se puede aprender absolutamente nada. Todos sin darse cuenta haciendo tiempo hasta ser desangrados, con un sistema, BankSphere, que por su propia naturaleza tenía los años contados (sólo seguía vivo porque seguía el grifo del dinero abierto a tope, como la válvula de gas que calienta un globo de aire, pero era cuestión de tiempo que en un cielo lleno de aviones, un globo no sería nunca un sistema de transporte rentable), y que hacía al conjunto de sus desarrolladores imposible su reciclaje de cara a la aplicación de sus concimientos a otro tipo de sistemas de 4ª generación (no digamos ya aplicados a 3ª generación)…

    … así que, colegas y camaradas programadores, cuando yo vi aquello, salí de allí porrrrrrr patas!!!!!. Corriendo, y como dije, sin mirar atrás y sin siquiera despedirme, sin detenerme a tratar de resolver malentendidos a nivel personal que se hubiesen generado. Sin permitir que nadie tratase de convencerme y sin ceder a ningún tipo de presiones, ni siquiera un finiquito impagado. Mucho me he preguntado cómo es posible que semejante bazofia hubiese llegado tan lejos, con varios miles de programadores capaces e inteligentes a su servicio. Pero bueno! esa es un poco la lógica bancaria, no? Burocracia vertical descendente y unidades de trabajo que compiten por los recursos, y ni se plantean cooperar entre sí para llevar a cabo la producción de manera coordinada y limpia. Los recursos, el dinero se queda arriba, y abajo llegaban los excrementos.

    Mucha gente decía que servía para blanquear dinero, pero yo pienso que simple y llanamente, los que lo concibieron, eran unos putos incompetentes. Emilio Botín había chuleado ya mucho de su inmersión tecnológica y él vivía en la España del “más vale lo malo conocido que lo bueno conocer” y del “ande yo caliente y ríase la gente”. Y a Botín le abrigaban muchos millones, y además no tenía ni puta idea de nuevas tecnologías, ni él, ni el gabinete de reía las gracias en las reuniones. Fácilmente cualquier ingenierito con aires de comercial, sin mucha moral ni amor por su profesión, que supiese juntar algunas siglas y formase una frase coherente sobre sistemas de comunicación seguros, podría sorprender a aquellos directivos tan catetos y convencerlos de la viabilidad de seguir invirtiendo en bks… hasta que llegase un momento en el que la cifra de errores, warnings y costo económico gritasen más fuerte que los aires de comercial de aquellos informaticuchos metidos a comerciales, que tuvieron los cojones y la caradura de ir a tomarle el pelo a unos ricachones con chequera ilimitada.

    En fin… sírvame de terapia este texto que ahí os he plantado, y como aval argumentativo de una opinión sólida basada en cálculos sólidos, cuando os aconsejo lo siguiente:
    – a los que estáis … pedid un aumento y más estabilidad contractual o iros de ahí.
    – los que no estáis, ni os lo planteéis como una opción.

    Un saludo a todos los compañeros de trinchera.

Escribe tu comentario

eBook ‘retroPLOF!’

retroPLOF!

Especifica tu dirección de correo electrónico y pulsa 'Comprar ahora'. Puedes pagar con tu cuenta de PayPal o con cualquier tarjeta bancaria.

E-mail envío eBook:

Sigue teknoPLOF! vía…
 
RSS
Twitter
Facebook
Google
 
Ready Set Click!

Utilizamos cookies propias y de terceros para mejorar la experiencia de navegación. Más información.

CERRAR