Como mantenedor de parte de la infraestructura de ONO, y tristemente, doy fe de la última frase.

Acierta de lleno en los problemas de toda empresa grande con sus sistemas de la información. Me equivoco o este speech es sólo la introducción para presentar un producto que soluciona todos esos problemas, etc etc ?

He trabajado como jefe de proyectos para la banca y doy fe que este vídeo es una perfecta radiografía del problema. Lo que pasa es que no tiene solución.

La mecanización crece por arrogación de cosas que se van mecanizando. Hay piezas que tiene 40 años de funcionamiento, basadas incluso en ficheros clásicos, yo he conocido activos en el año 90 cosas que aun funcionaban con fichas perforadas, junto a piezas basadas en procesos Batch sobre Bases de Datos Relacionales y otras piezas trabajando on-line con tecnología cliente/servidor, porque son cosas con años de diferencia en la implantación y la mezcla es un caos, porque nunca nadie se plateó al principio mecanizar la totalidad de la compañía, sino solo un proceso determinado, por ejemplo las cuentas corrientes y luego otro que nada tenia que ver como el pago de impuestos a Hacienda y luego otro de personal y luego otro que interactuaba con dos ya creados la liquidación de las retenciones de nóminas y así uno detrás de otro, con cambios de equipo y tecnologías por medio.

El resultado es un caos, del cual me alegro pues me ha permitido vivir muy dignamente tratando de poner orden en el caos un montón de años haciendo Interfases y más interfases entre piezas de software cada uno de su padre y de su madre, como cuenta este señor, que añaden mas y más ruido al cáos.

Pero que creo que nadie puede seriamente plantearse el evitarlo, pues ¿Cómo se puede plantear hoy el Banco de Santander mecanizar a partir de cero toda su gestión?, Es un imposible ya lo intentó Telefonica con el proyecto Arco y hobo que tiearlo a la papelera después de gastar barios miles de millones de pesetas y por ello pese a todo sólo se puede ir echando más parches y más parches a lo que existe para tratar de mantener en pie la máquina que mueve la compañía.

Desde el punto de vista de programacion, creo que es posible hacer una aplicacion fiable y que no falle, pero “se acabaria el negocio”. y el punto es que el software y el hardware es un negocio. Personalmente he creado software para una empresa para areas tan disimiles como “Mantenimiento de Maquinas” y “procesador de marcaciones electronicas” – fueron aplicaciones hechas en 1995 con un programa de la edad de piedra como Clipper. no molesta para nada, y si molesta sera al depto de sistemas que ha intentado reemplazarlos por programas bajo windows y que cuestan varios cientos de dolares y ninguno hace lo que hacen estos programas.

mi anotacion va al punto. si es posible hacer programas fiables y que hagan lo que deben hacer, pero se nos acaba el negocio. Nunca me llaman ni siquiera para soporte y los programas y las BD ni siquiera se dañan cuando se va la energia.

Saludos.

yo me sumo a la petición de poder ver el video completo, si hubiera alguna forma de subir el archivo (por ejemplo partido y a megaupload) yo colaboraría conel trabajo de editarlo y subirlo a youtube en partes también.

Un saludo!

Tiene un acento bastante bueno, y lo entiendo casi todo, pero no está subtitulado como dices Enrique…! Si puedes subir la versión subtitulada, mejor :-)

Gracias

Pues si Enrique, a ti aún te puede sorprender y escribir un post sobre los tres problemas de la gestión de la información en la empresa a partir de un video, pero los viejos rockeros como Gorki o como yo, no tan viejo –mis respetos Gorki lo de viejo va por la experiencia- que perdimos la raya del culo en nuestras sillas rascando miles y miles de líneas de código en Cobol, RPG, PL/1 o en el lenguaje de programación, madre de todos los lenguajes, el Assembler, que nos permitía jugar con los bits -digo bits no bytes- como diestros malabaristas, podemos dar fe de los tres, cuatro y más problemas de gestión de los SI.

Por ejemplo, las aplicaciones en Cobol todavía tienen un peso significativo en grandes centros de procesos de datos. En el 2006, según un estudio de Computerworld, en las grandes organizaciones USA, el 62% de aplicaciones estaban programadas en COBOL, por delante Visual Basic con el 63% pero no comparable por ser pequeñas aplicaciones monopuestos o departamentales, y por detrás el Java y el JavaScript, no tengo los datos del 2010, pero a pesar de la sustitución de aplicaciones tipo Cobol por otras más modernas, todavía tienen un peso significante. Como dato, la sacrosanta bolsa de NY migró, en el 2006, sus 800 aplicaciones en Cobol funcionando en un mainframe de IBM, a un clusted de servidores en Windows Server … estamos en la era 2.0, pero todavía son cientos de miles de aplicaciones de los años 80 y 90 son las que mantienen vivo el corazón de los SI del mundo mundial, con todos los problemas de integración con los nuevos entornos… hay ritmos y ritmos…
Un viejo rockero no tan viejo, pero la experiencia es un grado :-)

Me también a la petición de poder disponer del vídeo completo.

Muy bueno! Gracias por compartirlo.

#015 JLP
No me ofendo, la palabra viejo no es un insulto, es utilizar un término que nomina una realidad. Muchos por un sentido de la caridad, la eluden cuando hablan de nosotros, se lo agradezco, pero creo que es bueno que cada cual conozca su realidad aunque a veces escueza.

En efecto mi vida ha sido trabajar mucho en COBOL y compaginarlo con aplicaciones en lenguajes como Piton, para tecnología cliente servidor.

De lo que más orgulloso me siento de toda mi vida profesional es haber diseñado un traductor de programas fuentes de RPG, a programas fuentes en COBOL. Lo hicimos en C++ y era tan perfecto, que hasta trasladaba las lineas de comentario a su lugar adecuado me resultó fascinante el crearlo.

No se si habrá cambiado mucho en estos últimos tiempos, pero hace solo cinco años, casi toda la banca funcionaba en COBOL en le Back Office, solo el Front Office era a veces aplicaciones en otros lenguajes modernos. El COBOL, por ser un lenguaje de estructura muy normalizada, tenía en procesos Batch dos ventajas, es robusto y cualquiera lo entiende, lo que es una cualidad esencial que para trabajar en grandes corporaciones, lo que lo hace dificilmente insustituible. La programación orientada a objetos es mucho mas obscura y cuando tienes que retocar o modificar lo que hizo otro te vuelves loco.

El gran problema esta en los datos cuando incluyes productos realizados por otros generalmente se duplican los datos pues la estructura de los mismos no coincide en el sistema existente y la que se necesita en el nuevo. Por ejemplo en uno viene las fechas en formato DD/MM/AAAA y en otro en Juliana con lo que tienes que empezar a hacer intefases que sincronicen ambas estructuras de daros y cuando eso se multiplica al final nadie termina sabiendo cuales son los datos fiables en un momento dado y es el caos. (que te permite, o permitía vivir, muy dignamente)

Offtopic: Hace unos días algunos se quejaban de dificultades con la legibilidad de los enlaces. Yo los veo bien, pero tengo problemas para visualizar (con XP y Firefox) los números que aparecen a la izquierda de los comentarios.

También me ocurre que cuando pincho en un link y luego regreso al Blog no vuelvo exactamente al mismo lugar de la página o comentario sobre el que estaba (como ocurría en el blog antiguo) sino que aparezco al principio de la página y esto, sumado a no poder ver la numeración de los comentarios, me hace perderme un poco. Salu2.

Enrique, aqui tienes MATERIAL NUEVO de Larry Ellison para tus clases:
http://fora.tv/2009/09/21/Oracle_CEO_Larry_Ellison_Unscripted
Es una entrevista con Ed Zander de una hora y media de duraccion en el Churchill Club de Nueva York.
Espectacular!, y lo tienes por capitulos, segun te interese: Larry Ellison Fanclub on Facebook, Looking Back at Oracle’s Origins, America’s Cup, Acquisition of Sun Microsystems, Trend Toward Industry Consolidation, Cloud Computing, Mobile Internet, Microsoft, …

“Larry Ellison Fanclub on Facebook,”

???? Y habrá alguien apuntado ahí? Joer, eso si que debe ser masoquismo, ser fan de Ellison! :)))

#030,

“Para mi el grave problema es que hay cuatro empresas monstruas que ademas de tomarnos el pelo, compran a todo aquel que haga algo para que dejen de hacerlo.”

Ahí le has dado. Totalmente de acuerdo.

Lo único que queda es aceptar la realidad. El despliegue de recursos que requeriría realizar una integración ‘total’ en una empresa de tamaño medio (o incluso pequeña) sencillamente lo hace inviable.
Aunque de vez en cuando nos puede venir algún visionario a quien un avispado vendedor de software le ha convencido de que su producto SOA es la “bala de plata” que va a solucionar todos sus problemas. Hace una propuesta de proyecto que la dirección se traga, la empresa (u organismo público, que como tiran con pólvora del rey, suelen ser más generosos) se gasta una millonada en la aventura, que fracasa estrepitosamente ante la complejidad sobrevenida del tema y finalmente el que puede se escaquea discretamente. Por lo menos, unas decenas de informáticos han tenido curro durante un par de añitos y tienen algo que poner en el CV.

Hola Enrique, soy un profesional que trabaja en el sector y paso a responder a este post:

FRAGMENTACIÓN DE LAS BASES DE DATOS: No es culpa de la industria la cantidad de bases de datos que tengan los clientes.

EXCESO DE INTEGRACIÓN DE SOFTWARE: En la evolución informática de una empresa a medida de que la empresa crece y se hace más compleja pasa de una informática de producto a una de servicio, pero también pasa de una filosofía “Best of Breed” (un montón de aplicaciones específicas interconectadas mediante interfases y básicamente elegidas por ser productos terminados, específicos y baratos) a una filosofía “ERP” (Enterprise Resource Planning, o sistema integrado de gestión, donde todas las aplicaciones específicas comparten la misma base de datos e integración y son programables mediante el 4GL del ERP).

ERPs NO TERMINADOS TOTALMENTE: Resulta obvio que si un zapato tiene que encajar dentro de un pie, no lo puedes terminar al 100%. Por eso los ERP son productos horizontalizados que la consultora de implantación debe verticalizar para el cliente. De otra forma tendrían que deconstruir parte del ERP para volver a construir algo que medianamente se pudiese adaptar al cliente.

Un saludo
Alfredo Gómez

Mi profe de matemáticas solía decir: “Problema bien planteado, problema resuelto”. El Sr. L.E lo plantea impecablemente. ¿La solución?