Un artículo de Bloomberg, «America’s Cities Are Running on Software From the ’80s«, revela que muchas ciudades norteamericanas gestionan una gran cantidad de funciones vitales para su administración utilizando tecnología que debería más bien estar en un museo, con sistemas completamente anticuados procedentes en muchos casos de los años ’80. El artículo cita, de hecho, aquellos sistemas AS/400 de IBM que en los ’80 eran prácticamente el epítome de la gestión de sistemas corporativos, lo que me llevó a ilustrar la entrada con una buena dosis de nostalgia y de convencimiento de que cualquier tiempo pasado NO fue mejor :-)
La importancia de la cuestión va mucho más allá de lo que parece: el futuro de las ciudades es, cada vez más, convertirse en plataformas de intercambio de datos, en auténticas APIs abiertas preparadas para gestionar la información de todos los servicios que tienen lugar en ellas. Toda persona que trabaje en una ciudad debería estar obligada a exponer su trabajo en forma de una interfaz de servicio que sirva tanto para comunicarse interna como externamente, sin ningún tipo de excepción válida, sea cual sea la tecnología que se utilice. A partir de ahí, todo servicio que quiera prestarse en la ciudad, sea de transporte o de otro tipo, debería cumplir, como parte de la licencia que requiere para operar, con un acuerdo que le obligase a ceder todos aquellos datos de uso que puedan ser interesantes para la gestión municipal y alimentar esa plataforma adecuadamente, con el fin de posibilitar una gestión integrada. Seas Uber, un taxi o una empresa de alquiler de patinetes, la cosa debería ser tan sencilla como «no data, no party». Si no estás dispuesto a compartir y a integrar los datos de tu operativa con la ciudad, ni te molestes en pedir permiso para ofrecer tus servicios en ella.
La idea de una smart city tiene mucho más que ver con una arquitectura de sistemas de información que con ningún otro concepto. Y lógicamente, la construcción de una plataforma que permita la gestión integrada de una ciudad tiene necesariamente que estar desarrollada sobre unos sistemas que posibiliten su integración, de manera que en todo momento y en tiempo real podamos tener una imagen completa de lo que sucede en la ciudad, capturada tanto a través de sistemas propios desplegados por el propio ayuntamiento (sensores de contaminación, cámaras de seguridad, dispositivos de diversos tipos, etc.) como de infraestructuras o aplicaciones desplegadas por terceros.
El número de vehículos que circulan por una ciudad, por ejemplo, tiene que ser un parámetro estimable en cualquier momento, y accionable además en la medida de lo razonable: en algunas ciudades norteamericanas, por ejemplo, se empieza a barajar la idea de un muy polémico congestion pricing que cobre a los usuarios por la utilización de las vías a determinadas horas, y que precisaría de unos sistemas adecuados para su aplicación. Pero también hay que plantear la gestión, por ejemplo, de la oferta de transporte en una era que, frente a los antiguos sistemas de licencia que promovían la escasez, se caracteriza por la convivencia de múltiples plataformas que promueven la abundancia, y que es preciso mantener bajo control para evitar que se conviertan en un factor que empeore el tráfico en lugar de mejorarlo, y permita establecer dinámicamente, en caso de ser necesarios, cupos máximos de vehículos en función de las circunstancias a cada uno de los participantes.
Sin duda, eso va a exigir la modernización de muchos sistemas obsoletos. Pero más que eso, e incluso más allá de la antigüedad de los equipos, debería plantear una nueva arquitectura de sistemas, un desarrollo con mentalidad de plataforma o de API que en la actualidad es muy posible que pocas ciudades estén preparadas para ofrecer.
This post is also available in English in my Medium page, “When are we going to start running our cities as platforms?«
Siempre un placer leer tus reflexiones. El poder de la gestión e integración de los datos para gestionar la Cité, obviamente mejoraría la eficiencia urbana. En cambio, hoy en día me parece aún muy lejos la implantación de esos sistemas objetivos en la vieja Europa metida en otras ideologías que limitan el avance.
Saludos,
Toda persona que trabaje en una ciudad debería estar obligada a exponer su trabajo en forma de una interfaz de servicio que sirva tanto para comunicarse interna como externamente, sin ningún tipo de excepción válida, sea cual sea la tecnología que se utilice.
O lo he entendido mal, o indicas que se deberíia obligar a todos, a trabajar en una especie de escaparate digital a la vista de todos.
Sinceramente espero haberlo entendido mal, pues lo que indicas supera con mucho al Gran Hermano de 1984,.
No, Gorki. No hablo de sentar a los funcionarios en peceras de cristal :-) Hablo de interfaces, de exponer los datos necesarios para la gestión a través de APIs como única alternativa. Con tu experiencia, es un concepto que no puede sonarte ajeno. Mira lo que dijo Bezos al respecto hace muchos años:
https://homepages.dcc.ufmg.br/~mtov/pmcc/modularization.pdf
Lo he interpretado mal. Yo entendí que TODOS estábamos obligados a exponer los datos de nuestro trabajo, y solo te refieres a FUNCIONARIOS, que por estar pagados con el dinero de todos, si puede estar justificación que muestren sus datos en beneficio de todos.
Aun así, considero que habría que poner excepciones, No creo que sean conveniente que los dar tos que manejan Hacienda o de la Seguridad Social, estén al alcance de cualquiera, por ejemplo
De ahí el uso de APIs, conectores específicamente diseñados para permitir el intercambio de datos entre componentes de manera perfectamente controlada y definida. No hay problema en ofrecer los datos que la plataforma capta sobre densidad de personas o vehículos, por ejemplo, sin que eso implique ofrecerlos sobre quién está dónde y en qué momento…
Hacedme el favor de poner los enlaces en los comentarios como dios manda que estoy con la tablet y es un coñazo copiar y pegar. :)
Completamente de acuerdo. Las empresas que basen sus beneficios en operar servicios en las ciudades deben facilitar con lo que esté a su alcance la gestión de las mismas.
Al margen de ello, lo que urge hacer son políticas de desconcentración de las ciudades y vuelta al medio rural. La actual concentración de población en las ciudades es una auténtica locura con serias implicaciones de salud. Vivir en una ciudad como Madrid o Barcelona es, aunque parezca una exageración, vivir peligrosamente.
Hola Enrique , me ha hecho ilusión ver en tu TL la imagen del AS/400 , la “máquina” que lleva dándome de comer desde que acabe la universidad en los 90.
La pones como ejemplo de algo antiguo y si se mantiene en más de 1.000 empresas y entidades españolas , entre ellas la joya de la corona (eres gallego, si no me equivoco), es por su tecnología. Muchas de las innovaciones que se han ido incorporando a sistemas actuales ya venían en el AS/400: virtualización , integración , computación in-memory , etc.
Se asocia “el AS/400” a las pantallas verdes de la emulación 5250 pero ahora la BBDD DB2 de los System i (“el AS/400”) soporta tanto los desarrollos legacy de hace décadas como desarrollos actuales JEE.
Acceder a los datos mediante APIs es una es una estrategia que nada tiene que ver con que la infraestrucura que la soporta sea rápida,estable, fiable, ampliable… estando en la nube (“ordenadores de otros” como alguien la definió) o en un sistema en casa convenientemente mantenido y actualizado. Lo que sea más barato.
Larga vida al AS/400
PD : Si el chatbot de www.helvetia.es te convence para hacerte un seguro, podremos ver tus datos con un DFU en pantalla verde… aunque sea más usual el acceso desde la APP de CRM.
Que el AS400 se siga manteniendo por su tecnología de los 80, no tiene sentido alguno, está descaradamente obsoleto.
Se mantiene porque hay multitud de aplicaciones que aunque sean primitivas, funcionan y son tan criticas que no se atreven a migrarlas, puro miedo.
El coste de mantenimiento de esos dinosaurios es disparatado, pero por eso mismo, como dice Javier «da de comer» a muchos. Entre el miedo de unos y el hambre de otros…
Hola LEON, sin ánimo de desviarnos del tema de la apertura API…
1.- No creo que el AS/400 sea un sistema obsoleto:
https://symmetrycorp.com/blog/why-is-ibm-as400-still-used/
2.- Multitud de aplicaciones muy poco primitivas corren en as/400… Hacienda, INDITEX, grandes Bancos (estos sí primitivos pero muy eficientes), industria de automoción, aseguradoras, operadoras de telefonía…
3.- El coste de mantenimiento de esos dinosaurios es bajísimo, son sistemas auto-eficientes:
https://books.google.es/books?id=SQ0AAAAAMBAJ&pg=PA18&lpg=PA18&dq=staff+cost+cheap+as/400&source=bl&ots=6fu9L5EBk0&sig=ACfU3U0Z7GRUlqi2GhN-7T2WzSP0O09I7A&hl=es&sa=X&ved=2ahUKEwjf8rOTnOvgAhVUA2MBHWzqBHUQ6AEwBXoECAgQAQ#v=onepage&q=staff%20cost%20cheap%20as%2F400&f=false
Efectivamente. He trabajado para algunas de esas empresas y puedo asegurar que, por ejemplo en una de las grandes aseguradoras, el front-end era totalmente web, programado en Java, pero el «core» era Power i con RPG. Ellos nos lanzaban sus peticiones vía stored procedures. Nosotros les devolvíamos la respuesta vía result set. Y en el medio había RPG. Eso sí, RPG moderno. Formato libre, SQL embebido, etc.
RPG sigue siendo un «muerto» muy vivo. :)
Mal ejemplo el de poner el AS/400, ahora denominado IBMi, como sistema obsoleto, ya que se ejecuta en la plataforma IBM Power. Por poner un ejemplo, Google ha seleccionado dicha tecnologia para sus centros:
https://www.forbes.com/sites/patrickmoorhead/2018/03/19/headed-into-its-fifth-year-openpower-has-momentum-into-the-power9-generation/#365b08cb78a8
Excelente tu comentario Javier.
El AS/400 no es un sistema obsoleto.
Saludos
No se si yo también estoy entendiendo mal cuando Enrique dice que hay que modernizar los equipos. ¿Pues no habíamos quedado en que es más caro y menos flexible operar tu propio hardware y software que operar en la nube donde puedes dimensionar la potencia que necesitas y disponer del último grito en sistemas de gestión con un par de clicks?
Digo precisamente lo contrario: que no es una cuestión de hardware, sino de arquitectura y planteamiento de sistemas de información…
Buen artículo. En general una política de APIs es importante en toda organización. Por favor sigue insistiendo en ello ya que a la gente le cuesta mucho. La cantidad de información que esta en servidores y que hay que pedir ¨a mano¨ nunca deja de sorprenderme.
Ejemplos: Si una empresa de autobuses tiene sus horarios accesible con una url tipo empresatransporte.es/horarios.json yo sin saber programación puedo descargar automáticamente los horarios en excel y con unas formulas simples automáticamente recommendar transporte a gente que vaya a visitar una empresa.
Yo sin saber programación y un simple excel puedo automatizar un monton de tereas de copia, pega, cálculo simple si los datos son accesibles. El potencial de analizar los datos, las posivilidades añadir programación …. el futuro puede mejorar mucho
Si sabes » con unas formulas simples automáticamente recommendar transporte a gente que vaya a visitar una empresa». eres programador.
Eres programador de Excel y no es tan sencillo el hacerlo
Lo que debe haber cobrado IBM por todos esos equipos en los 80, recién ahora se deben estar amortizando…
No se bien si por ley, o por costumbre, la amortización de los equipos informáticos, es en cuatro años. El primero se amortiza la mitad de su valor, el segundo el 25% y el tercero y cuarto año el 12,5%
Por tanto un equipo comprado en 1980 estaba amortizado en 1985, lo que durara más, era un bien sin valor en libros contables. Lo mismo se aplicaba al software. . .
Estas muy desactualizado, Gorki.
Me he molestado en ver lo que indfica la Agencia Ttributaria:
https://www.agenciatributaria.es/AEAT.internet/Inicio/_Segmentos_/Empresas_y_profesionales/Empresas/Impuesto_sobre_Sociedades/Periodos_impositivos_a_partir_de_1_1_2015/Base_imponible/Amortizacion/Tabla_de_coeficientes_de_amortizacion_lineal_.shtml
Y dice :
Equipos para procesos de información Maximo anual amortizable 25% maximo de años 8 años
Sistemas y programas informáticos 33% y 6
Por tanto no andaba muy desacertado,
Por ley se puede amortizar un ordenador y los programas en cuatro años
Y puedo asegurarte que las empresas «serias» amortizan realmente los equipos y programas, (si pueden. por tener EBITDA suficiente), en las proporciones de 50% 25 % , 12,55 y 12,5% , llevando lo que por ley no les dejan llevar legalmente a Amortizaciones a Reservas Voluntarias, porque realmente los equipos y programas se devalúan en esa proporción
Si por algo son famosos los EEUU es por estirar la vida de todo más allá de sus límites obvios.
Los puentes, carreteras, ferrocarriles, líneas eléctricas, etc, etc, están, en su gran mayoría, obsoletos.
Así que con los sistemas informáticos lo mismo. Y no hay más que mirar los presupuestos para darse cuenta de que no son actualizaciones banales.
En eso son principiante, tenemos montones de «Puentes Romanos» (generalmente medievasles) en funcionamiento.
El acueducto de Segovia ha estado en funcionamiento continuado del siglo II al siglo XX
¡Ja, ja, ja, sí, tienes razón, pero es que los romanos -y medievales- sabían hacer las cosas para que duraran dos mil años! Muchas carreteras y autopistas están sobre calzadas Romanas y ahí siguen, perfectas. En cambio ahora Se empieza a parchear una autopista a los tres años de construirla…
El problema en EEUU es que que fueron pioneros, construyeron grandes obras públicas hace 100 o 150 años y ahí siguen, sin modernizar pero sin ser ni de lejos como un puente Romano. La última gran obra pública que hicieron fueron las interestatales, y de eso hace ya 80 años.
Y lo mismo se aplica a la informática: fueron los primeros, sí, pero siguen usando aplicaciones que hicieron hace cuarenta años y que nadie se ha molestado en actualizar.
¿Los iSeries (AS400) obsoletos? He estado trabajando con estas máquinas desde el año 1991 y he vivido su progresiva actualización con cada nueva tecnología que ha ido apareciendo. Son sistemas que, además de incorporar las novedades tecnológicas sin que te des ni cuenta, tienen un coste de mantenimiento en personal mínimo. Preguntad a cualquier operador de sistemas que también haya trabajado con un zSeries (IBM 390) o un Linux en cualquiera de sus sabores a ver qué le resultaba más fácil. ¡¡Qué atrevida es la ignorancia!!
Este articulo os da una idea del estado de salud del IBM i
https://www.helpsystems.com/es/blog/esta-muerto-el-as400
entre otras cosas dice esto:
Entonces, ¿está muerto el AS/400?
En una palabra, no. ¡La plataforma es más popular que nunca! Estas son cinco razones de por qué:
IBM i es escalable. Las empresas pueden empezar con un servidor económico 4-core y fácilmente ascender a máquinas de hasta 256-core. Es extraño que las necesidades de procesamiento de una empresa superen a IBM i.
IBM i es seguro. Cuando está correctamente configurado y equipado con el software adecuado, IBM i puede ser una plataforma muy segura.
IBM i es confiable. Se suele decir que esta plataforma trabaja todo el tiempo. De hecho, ofrece confiabilidad de nivel empresarial y herramientas de alta disponibilidad para operar 100% de manera continua.
IBM i es moderno. Además de ser capaz de ejecutar los programas existentes, IBM i soporta un saludable mix de lenguajes de desarrollo nativos y de código abierto, incluyendo RPG, SQL, Java, .NET, PHP y C++.
IBM i es compatible. Igual de verdadero que en 1988, la creciente compatibilidad de esta plataforma protege su inversión al evitar costosas migraciones de código cuando las plataformas son actualizadas.
si este señor supiese de que habla se daría cuenta que realmente lo importante son los datos, empresas como las bajo indicadas apuestan por la seguridad y no el coste que supone para las empresas mantener un entorno gráfico inestable, si desde el año 91 está funcionando es porque funciona realmente y las grandes empresas apuestan por estabilidad que es lo que hace que sean rentables, las modas tienen una vida de 5 a 10 años.
Que se lea este articulo antes de hablar de lo que no sabe:
https://www.forbes.com/sites/patrickmoorhead/2018/03/19/headed-into-its-fifth-year-openpower-has-momentum-into-the-power9-generation/#291541ac78a8
«Google Confirms POWER9 Processor Data Center Deployment At OpenPOWER Summit 2018…………..Tencent, Alibaba, Uber, and Limelight
Many large enterprises already use IBM’s Power Systems. IBM says 8/10 top retailers, 8/10 top insurance companies, 10/10 of the top Telcos, and 10/10 of the top banking firms run IBM Power Systems. Also, the company says 7/10 of Fortune 10 companies and 12/20 of the Fortune 20 enterprises run IBM POWER8 in their datacenters. …»
Y si tú supieses leer – y si no fueses un maldito maleducado – no mirarías el dedo cuando hablo de la luna.
¿y qué tal un urbanismo abierto en el que su evolución se adapte mejor a la evolución de la propia ciudad y de la tecnología en evolución?
…y no suceda como en la actualidad, en la que los medios de planeamiento urbano tardan más de 10 años en ponerse en práctica… ¿?