Blog de JoseMPelaez

Aprendimiento: aprender del entorno con atrevimiento

Posts Tagged ‘datos’

Navegar hacia las nubes de datos

Posted by josempelaez en Jueves, 5 marzo 2009

El reciente nombramiento de un director de sistemas de información en el nuevo gobierno estadounidense me permite relacionar otra vez el software y la política. Los criterios que han impulsado la mejora y el acceso a los datos también conducen a potenciar el uso de aplicaciones web que saquen partido de la «computación en la nube». Este enfoque puede trasladarse fácilmente a otros terrenos donde deben cooperar diversas entidades, como el de las «cadenas de suministros».

cartel-publicitario_derribado-viento

Cartel derribado por viento. Madrid (©ÁlvaroGarcía, El País 090305)

El temporal ha arreciado y el viento se ha mantenido soplando fuerte y constante por España en estos días. Además, las tasas de desempleo han seguido subiendo, los tipos de interés han continuado bajando y los juegos de los políticos, aunque hayan rolado, no han amainado demasiado. Parece que quedaron atrás los rompientes de los lances cinegéticos, de las filtraciones periodísticas, de las contiendas electorales…, pero ahora tenemos delante los bajíos de los coches gallegos, de los espías madrileños, de los golpes vascos

Todavía quedan cargas en mi tintero para escribir sobre varios aspectos que considero paradójicos en relación con la situación social que nos afecta, y mucho. Sin embargo, voy a dirigirme a otras aguas menos borrascosas y provocadoras de naúseas. Trataré de mantener el rumbo emprendido después de la virada en mi última navegación web a bordo de este cuaderno de bitácora. Resulta que, cada vez que intento adentrarme en los mares de la economía y la gobernanza española, termina surgiendo en mi mente la sensación de deslizarme por terrenos casi ignotos por irracionales. Navegando por zonas donde prevalece un oleaje de intereses creados y respuestas viscerales, se termina levantando mi temor a un naufragio tenebroso.

En mi entrada previa puse rumbo hacia la participación ciudadana y el desarrollo de software al traducir la mayor parte de un artículo donde se lee que «we need to create open innovation platforms for citizens to create solutions for themselves». Uno de sus enlaces apuntaba al concurso Apps for Democracy, en cuya organización había participado la agencia digital del redactor del texto. Hoy he recordado esta iniciativa al conocer el nombramiento de otro de sus promotores como nuevo CIO del gobierno estadounidense

Vivek Kundra, que hasta ahora era el CTO del Distrito de Columbia (Washington DC), fue premiado por el MIT Sloan CIO Symposium en 2008 como un innovador en el uso de las tecnologías de información. Ha sido uno de los tecnólogos que ha contribuido a los planes de acción del gobierno federal. Como anécdotas ilustrativas cabe reseñar que es usuario de Twitter y que ha promovido el empleo de las aplicaciones web de Google entre los funcionarios de WDC como alternativa a la suite de Microsoft Office que tenían.

Vivek Kundra escuchando (cc David Clow, Flickr 080725)

Vivek Kundra (34 años) escuchando (cc David Clow, Flickr 080725)

Entre las políticas implantadas está la de emplear tecnología ya disponible comercialmente —en vez de encargar desarrollos específicos a los proveedores habituales en este tipo de adjudicaciones—. Para lo que deseo anotar hoy aquí, me interesa subrayar también el criterio de gestión de potenciar la transparencia y la participación ciudadana eliminando barreras para acceder y compartir la información. [Vamos, algo distinto de lo que pasó ayer con el uso de Twitter en la Asamblea de Madrid, por ejemplo.]

En la línea de fomentar la participación, el concurso de aplicaciones referido ha recibido 47 propuestas para ser votadas por los futuros usuarios, es decir, por los ciudadanos. Una de las condiciones era la de usar los datos que se publican para favorecer los desarrollos web de mash-ups empleando técnicas estándar y ágiles. Con esta iniciativa también se perseguía el superar las anticuadas y toscas herramientas de ofimática que aún lastran la productividad de las personas y grupos en muchas organizaciones públicas y privadas.

La facilitación del acceso a las bases públicas de datos me ha recordado la disponibilidad de los Amazon Public Datasets. Se anunció poco después de una conversación que tuve con el autor de Nubeblog sobre el futuro de la captura y explotación de datos en La Nube. En ese encuentro comenté con Diego Parrilla —que hoy promueve la tecnología de Abiquo— las posibilidades y ventajas de las nubes públicas frente a las privadas. Las primeras permiten la explotación de los datos que son de interés para muchas personas y organizaciones, o que son susceptibles de tipos distintos de aprovechamiento. 

tienda-ropa

Tienda de ropa variada (Phil's Stock World Favorites, 080611)

Para ilustrar mi postura usé ejemplos de las «cadenas de suministros» para el aprovisionamiento (supply chains), algo que yo prefiero llamar «redes de abastecimiento» de la demanda (demand networks). Por ello también he recordado mi enfoque tras leer ayer un artículo de AMR Research sobre «Categorizing Content in the Supply Chain». Trata de los desafíos que plantea la gestión de los distintos tipos de datos (“contenidos”) que se manejan en las supply chains, de los que algunos han de ser necesariamente compartidos por distintos motivos. Uno de los casos que menciona es el de los efectos de las terapias sanitarias, situación que en España resulta de actualidad ante el caso de unas vacunas contra el cáncer de útero.

El análisis de datos agregados puede aportar un gran valor, aunque resulta escaso cuando se limita al plano individual. El contenido y precio de un carro de compra semanal de una familia aporta cierta información, pero no es comparable con la del análisis de todas las compras de esa familia durante un largo periodo de tiempo. Tampoco lo es con el valor que pueden obtener los comerciantes capaces de procesar adecuadamente los datos agregados de consumo por artículos y clientes en toda clase de segmentos zonales y temporales.

Podemos encontrar otros ejemplos ya también clásicos en los actuales servicios disponibles en la web para muchos usuarios que comparten información por encima de la plataforma, como el recién lanzado Likaholix. Sin embargo, los ejemplos más antiguos y lucrativos provienen del sector financiero —pionero y usuario intensivo de los ordenadores—, como exponía IC en «el front running, la madre de todos los negocios».

Todo esto me lleva a pensar en otra idea, pero ya la compartiré en la entrada siguiente.

Entradas de este cuaderno con alguna relación: ¿Jugamos a la política o desarrollamos algo?, Captura de datos en la nube, Conmutación a la nube.

Suscribirse a las entradas de este cuaderno mediante un lector.

Posted in software | Etiquetado: , , , , , | Leave a Comment »

Paradojas en la arquitectura maestra

Posted by josempelaez en Miércoles, 2 julio 2008

En las dos notas precedentes reflexioné sobre los programas orientados a procesos y a datos, y sobre la integración de aplicaciones empleando estructuras comunes de datos, entre otros medios. En ambos casos eché mano de mis recuerdos informáticos con la idea de explicar-me —”a mí, mismamente”, a mi penfriend Luis y a quienquiera leerlas— por qué no comulgo con la idea de que los datos maestros de las aplicaciones transaccionales deben estar en un sitio común.

ERP monoliticoCierto es que los llamados ERPs (Enterprise Resource Planning), que también se han denominado «paquetes integrados de gestión empresarial» precisamente por ello, resolvieron varios problemas derivados de las lagunas e inconsistencias de la información procesada con aplicaciones que formaban sistemas deslavazados. Por cierto, que quien empleó lo de planificación para referirse a estos sistemas transaccionales no debía de saber mucho de operaciones, o le encantaban las paradojas. Además, hubiera sido mucho más veraz referirse a controlar, y no a planear.

No obstante, en la misma década de los 90 en que se propagaron los anteriores, también se difundían modelos de interoperabilidad de sistemas. El CORBA del OMG en el plano de la aplicaciones, y el DCE/RPC del OSF en un nivel más bajo, fueron promovidos por algunas empresas relevantes de tecnología como alternativas flexibles al monolitismo de la base y modelo de datos únicos.

Sin embargo, a pesar del buen nombre de sus promotores, se impuso el modelo integrado de datos para construir los nuevos sistemas de información (SI) empresariales frente al de las interfaces técnicas entre aplicaciones especializadas. Ello sucedió, de nuevo paradójicamente, en el marco de una gran expansión del empleo de las redes locales (LAN) y la arquitectura C/S derivada. Creo que la clave está en que SAP, como gran propulsor de modelo triunfador, era una empresa de programación que nació para resolver un problema importante de los financieros.

Además, en 1993, tras haber logrado el apoyo de las dos grandes empresas de miniordenadores de la época (HP y DEC), supo ceder servicios de implantación para poder crecer más rápido aliándose con las grandes empresas de consultoría de negocio. Éstas vendían el BPR a los miembros (y “miembras”, según Aído) de los comités de dirección de sus clientes empresariales. Prometían que la “nueva” herramienta (R/3) de SAP, que promovían y en la que habían formado a su gente, iba a materializar los deseados cambios. ¡Y vaya si tuvieron que cambiar para adaptarse al modelo funcional del nuevo paquete, aunque no creo que fueran exactamente esos sus ansiados deseos!

Las suites de aplicaciones comenzaron a aparecer al poco por dos motivos adicionales a los tradicionales de especialización y flexibilidad. Por un lado, como resultado de las adquisiciones de business software hechas para crecer más rápido por empresas como Oracle, Descartes Systems, i2 Technologies, SAP, etc. Había que integrarlas con las existentes y, con sus bases de clientes, no se podían permitir el rehacerlas desde el núcleo para que tuvieran las mismas estructuras maestras que las aplicaciones del adquirente.

Por otro, los ERP transaccionales derivados de los programas de contabilidad (FABS), o de los de planificación de la producción (MRP), no cubrían importantes áreas de actividad cotidiana (CRM, SRM, PLM…). Ni para el director financiero ni el de producción las visitas comerciales debían de ser relevantes para “sus negociados”. Tampoco cubrían las funciones más propias de los DSS, que sí interesaban a ambos, pero que se dejaban fuera porque entonces podían “tumbar” los servidores con algunas de sus “potentes queries“.

Creo que la situación actual es la descrita al final de la entrada sobre Estructuras maestras. El uso de internet (una arquitectura C/S abierta, al fin y al cabo) ha determinado que los «servicios web», herederos del CORBA, estén predominando en la interacción entre sistemas modernos, que ya no son los ERPs. HP llegó a llamar e-speak a este enfoque a mediados de 1999. Microsoft comenzó a referirse a un concepto similar con la etiqueta .Net un año después. IBM hablaba de e-business desde años antes.

Las necesidades del comercio internacional (OASIS y UN/CEFACT), y el apoyo del consorcio de estándares de internet (W3C), han ido afianzando la difusión del XML como elemento esencial de dichos servicios de conectividad e interacción. En el terreno de las aplicaciones para consumidores, los agregadores de contenido (RSS) y las interfaces gráficas de usuario (GUI) basadas en Ajax también lo difunden con profusión.

¿Quieres saber las implicaciones y lo que opino sobre todo lo anterior? Por favor, lee la entrada siguiente y última de esta serie sobre estructuras de datos maestros comunes titulada «Paradojas en el proceso».

[Ilustración 1: Software as a concrete block. Blog ZDNet Phil Wainewright]
[Ilustración 2: Esquema de mySAP Business Suite. SAP]

Posted in integración | Etiquetado: , , , , , , , | Leave a Comment »

Estructuras maestras

Posted by josempelaez en Lunes, 30 junio 2008

El comentario con que arrancaba mi reflexión sobre Maestros y estructuras es el que me había llevado a preguntarme: ¿por qué las distintas aplicaciones empresariales tienen que «disponer de estructuras maestras comunes para las transacciones particulares»? En esta anotación voy a avanzar en la exposición de mi pensamiento, pero su conclusión quedará para la siguiente, por lo que ya advierto de que tampoco voy a llegar a mi destino en este segundo intento.

Creo que, con datos maestros, nos estamos refiriendo a los atributos de entidades tales como clientes, proveedores, empleados, materiales, productos, vehículos, rutas, ubicaciones, centros, operarios, cursos, unidades de obra, cuentas… Es decir, aspectos de la realidad empresarial que tienen cierta estabilidad, si es que esto sigue existiendo hoy. Es preciso que se introduzcan o modifiquen en un sólo sitio, o mejor dicho, una sola vez en cada ocasión en que se requiera. Tienen que ser consistentes y no depender de las aplicaciones. No obstante, con el estado de la técnica moderna, opino que no deben sacrificarse ciertas cosas (flexibilidad, creatividad, innovación, agilidad, adaptabilidad, economía…) a fin de evitar copias duplicadas para ganar espacio, tiempo o robustez del sistema.

grid computingNo es que estos últimos factores no sean ya importantes, sino que se pueden conseguir unos niveles adecuados para ellos a base de replicar, publicar-suscribir, propagar, emular, etcétera. Las computadoras en cluster, los gestores de bases de datos distribuidas, la tecnología grid, las redes de intercambio entre pares, la sincronización de agendas, la “virtualización” de sistemas operativos, el utility/cloud computing… nos brindan posibilidades que antes sólo conocían muy pocos ya que eran aplicables en ambientes reducidos.

Ahora, el almacenamiento y el procesamiento son baratos y bien conocidos. Se puede trabajar perfectamente de forma interactiva y con alta disponibilidad empleando sistemas distribuidos, lo que a veces requiere duplicaciones controladas y datos “desnormalizados”. Me parece que los mayores defensores de los supercomputadores de multiproceso simétrico herederos del mainframe (IBM, Sun…), frente a los más partidarios del proceso masivamente paralelo (Intel, HP, Fujitsu, Dell…) —que emplean granjas de «estaciones de trabajo», redes de servidores estándar baratos, armarios compactos con blades, etcétera— no pueden esgrimir otro argumento mejor que el de la eficiencia energética, y de manera discutible.

También me parece que SAP nos brinda un ejemplo muy ilustrativo en el campo de las aplicaciones y sus datos. Su producto integrado —R/2-R/3-MySAP ERP, para entendernos, ya que en la praxis tienen el mismo núcleo interno— comenzó a implantarse para ofrecer una respuesta financiera inmediata en las grandes empresas alemanas muy estructuradas y dispersas territorialmente por el mundo. Aunque SAP tardó mucho en cambiar su discurso comercial por otro menos limitante, lo hizo finalmente con el anuncio de Netweaver a primeros de 2003. La rigidez puede llegar a ser muy eficiente, pero no suele generar eficacia, que es lo primero que hay que lograr.

No fueron muchos los que se dieron cuenta que su cambio rompía el enfoque de paquete con modelo integrado de datos que aseguraba estructuras maestras comunes para las aplicaciones, lo que habían defendido a ultranza durante casi 30 años. Al nacer el mercado del business software en 1969 —tras “segregar” IBM las aplicaciones y servicios del hardware de sus mainframes— lo que se ofrecía eran soluciones best-of-breed inconexas para los paquetes empresariales (contabilidad, nómina, almacén…). Los problemas de inconsistencias y demoras de consolidación de información que SAP resolvió en sus comienzos tienen ahora mejor respuesta. Y ésta fue adoptada por quienes habían propagado un enfoque previo monolítico y cerrado, pero que resolvió un problema real, al menos para los directores financieros que tardaban meses en consolidar las cuentas anuales de su grupo.

Los planteamientos alternativos a los problemas derivados del ERP integrado no se habían consolidado como una buena opción. Las programaciones de interfaces a medida, el empleo de estándares derivados de EDIFACT, la ejecución de proyectos de «integración de sistemas» con paquetes de EAI dotados de conectores, y la promoción de algunas capacidades de los portales B2B (exchanges) han sido soluciones caras y complejas de implantar y mantener. No han llegado a ser útiles de manera general porque los estándares EDI son rígidos y de mínimos, los proyectos ad hoc emplean mucho tiempo y dinero, y los marketplaces, además de facilitar el intercambio de datos, también pretenden reintermediar los negocios existentes, lo que no gusta a sus agentes.

Entreprise Service Bus Las herramientas de integración basadas en sistemas de mensajería referidas (EAI) nacieron a mitad de los 90 con la proliferación de aplicaciones departamentales. Ésta se apoyó en la difusión de la arquitectura C/S —que también potenció extraordinariamente el despliegue de R/3—, y a su consolidación se aplicaron los enfoques utilizados en la automatización de fábricas y diálogos entre sistemas financieros de los 70 y 80. En la década actual han ido evolucionando hacia los llamados ESB y BPM, planteamientos derivados de los gestores de workflows documentales (difundidos con Lotus Notes) y de las herramientas ingenieriles para diagramar procesos. Creo que estos productos comerciales, junto a las suites de aplicaciones a las que me referiré en otro momento, se van a seguir considerando buenas opciones. Están introduciendo el mismo tipo de middleware que permite conformar un sistema integrando fácilmente muchos componentes «débilmente acoplados». Otra cosa es que puedan mantener sus precios dadas las alternativas disponibles en programación de código abierto.

En cualquier caso, considero que en la base de estos movimientos está el hecho de que, a finales de los 90, el “viejo” lenguaje XML y los estándares de «servicios web» para el intercambio automático de información en internet entre aplicaciones (una forma de interfaz M2M) empezaron a modificar radicalmente el panorama. Después del posterior abandono de Microsoft del grupo de empresas tecnológicas que apoyaban el lenguaje Java multiplataforma para desarrollar aplicaciones empresariales en internet, el XML ha quedado como la herramienta más efectiva de programación orientada a datos de entre las consensuadas en el mundo. Frente a otras de este tipo, como SQL, XML tiene la ventaja de ser extensible y autodefinible. Por tanto, es más capaz de salvar las diferencias que caben al interpretar o implementar los estándares de consenso, por naturaleza lentos en su avance.

Termino esta reflexión con la idea de referirme en la siguiente a algunas implicaciones relevantes del actual enfoque adoptado por la mayoría de las grandes empresas suministradoras de sistemas empresariales, así como a su impacto en las «estructuras maestras comunes» de sus aplicaciones.

[Ilustración 1: arquitectura grid promovida por el CERN.]
[Ilustración 2: tomada de la nota sobre ESB, BPM y SOA en el blog La vida en bytes.]

Posted in software | Etiquetado: , , , , | 2 Comments »