Estas aquiContenido / Interoperabilidad (y IV): Estrategias para las organizaciones

Interoperabilidad (y IV): Estrategias para las organizaciones


Poradmin- Publicado el16 Junio 2009

Por Fernando Acero

En el artículo anterior de esta serie dedicada a la interoperabilidad vimos algunas estrategias que nos permitían mejorar nuestra capacidad de comunicación con otros usuarios y la seguridad de nuestra información. Estas estrategias se basaban en uso de estándares abiertos y las podemos poner en práctica, sin muchos problemas, en nuestro ámbito doméstico. Sin embargo, lograr la interoperabilidad en las organizaciones es mucho más complicado de lo que parece. Está claro que las medidas y estrategias que vimos en el artículo anterior son un buen comienzo para cualquier organización y son sencillas de implantar en las estaciones de trabajo, pero en las organizaciones, con independencia de su tamaño, es necesario ir más lejos y tener una visión de conjunto, ya que el escenario puede ser muy complejo...

Lo primero que necesita una organización para lograr la interoperabilidad es ser consciente del problema y tomar las medidas adecuadas para solucionarlo. Como ya hemos dicho, el elemento clave para lograr la interoperabilidad es el factor humano. Debemos tener en cuenta que nuestra interoperabilidad dependerá de las decisiones tecnológicas que tome una persona, o grupo de personas, en nuestra organización. Una vez que seamos conscientes del problema, es fundamental la especialización de los responsables de las tecnologías de la información de la organización y la formación de los usuarios.

Debemos estar convencidos de que la interoperabilidad interna y externa de las organizaciones, son claves para el desarrollo eficiente y sostenido de la organización. No creo que sea una buena política el perder un porcentaje de clientes, aunque sea pequeño, por problemas de interoperabilidad, que además, se pueden solucionar sin invertir más dinero, o incluso, ahorrando dinero. Igualmente, ninguna organización puede ser competitiva si arrastra un pesado lastre de "legacy", o si no puede optar libremente por las tecnologías que más le interesen en cada momento.

Desgraciadamente, la realidad es muy distinta y los monopolios tecnológicos han provocado que un elevado porcentaje de organizaciones públicas y privadas sean víctimas del "legacy" y por lo tanto, cautivas de tecnologías privativas, dificultando seriamente su capacidad de innovación, poniendo en riesgo el acceso a su conocimiento e información y limitando su capacidad de comunicación interna o externa.

 

El marco de interoperabilidad

Una vez que somos conscientes del problema de la interoperabilidad, una buena práctica es elaborar un documento que defina la forma en la que vamos a lograrla en nuestra organización. Este documento recibe diversos nombres, como esquema de interoperabilidad, arquitectura técnica de referencia, marco de interoperabilidad, pero eso es lo de menos. Lo que debemos contestar de forma prioritaria es la pregunta ¿qué es lo que debe contener este importante documento?.

Muchas organizaciones se empeñan en relacionar en sus marcos de interoperabilidad las aplicaciones "estándar" a utilizar en la organización, lo que no es una buena idea, puesto que las aplicaciones cambian con el tiempo, suelen estar ligadas a un determinado marco tecnológico y la mayoría de ellas, permiten usar estándares abiertos y formatos privativos de forma indistinta. Por lo tanto, si no se definen y establecen adecuadamente los estándares abiertos a utilizar en el marco de interoperabilidad, este documento no será muy útil para lograr nuestros objetivos.

Un buen marco de interoperabilidad ha de tener presente el concepto de "neutralidad tecnológica" y debe relacionar con claridad meridiana los estándares abiertos que se usarán en nuestra organización. Además, estos estándares deberían estar clasificados como emergentes o recomendados, obligatorios o normalizados y en abandono, como referencia para los usuarios y desarrolladores de lo que está por venir y de lo que debemos ir abandonando, para no quedar desfasados y no poner en riesgo el acceso, o la seguridad de nuestra información en el futuro.

Por lo tanto, este documento ha de estar vivo y debe estar sometido a cambios y a las sugerencias de los usuarios. De nada sirve un marco de interoperabilidad si no es dinámico y capaz de adaptarse a las nuevas tecnologías y a los nuevos estándares con el paso del tiempo. Asimismo, debe contener una serie de normas claras y positivas que nos permitan lograr la interoperabilidad dentro de la organización de forma transparente y natural.

Una de las tareas más complicadas para establecer un buen marco de interoperabilidad es el establecimiento uno los criterios, normas y estándares, que sean adecuados para la finalidad que pretendemos. Para facilitar este trabajo, lo mejor es definir unos principios básicos a los que someteremos el contenido de todo el documento. Por ejemplo, podemos establecer los siguientes principios:

  1. Neutralidad tecnológica y capacidad de adaptarse sin problemas a las nuevas tecnologías.
  2. Eliminación del "legacy" y de la dependencia tecnológica de empresas, tecnologías o proveedores.
  3. Facilitar el acceso a los servicios de la organización.
  4. Lograr la transparencia tecnológica.
  5. Eficacia y eficiencia de los métodos y procedimientos.
  6. Lograr la interoperabilidad vertical, horizontal y en el tiempo.
  7. Mejorar la cooperación y coordinación entre los distintos departamentos de la organización.
  8. Mejorar la participación efectiva de los miembros de la organización y en la generación y transferencia de conocimiento dentro y/o fuera de la organización.

Además, un buen marco de interoperabilidad debería cumplir con los siguientes objetivos básicos:

  1. Garantizar la comunicación electrónica y el acceso a los servicios de la organización, sin dependencias tecnológicas. Es decir, el marco de interoperabilidad ha de apostar claramente por la eliminación de todas las barreras tecnológicas que pueden existir en la organización, mediante el uso de estándares abiertos y un serio compromiso con la neutralidad tecnológica, pero sin caer en las utopías irrealizables, o en una mera declaración de intenciones. No es un buen marco de interoperabilidad aquel que tiene recomendaciones que no se pueden llevar a cabo, o el que es tan rígido, que no permite poner en práctica proyectos piloto, o iniciativas para la mejora de la infraestructura tecnológica. El marco de interoperabilidad ha de ser un mecanismo flexible y dinámico de coordinación y un instrumento objetivo y positivo para todos los miembros de la organización, conteniendo unas normas claras y precisas, que puedan ponerse en práctica a todos los niveles.
  2. Garantizar la interoperabilidad de los servicios y sistemas de información, tanto para la relaciones internas como para las externas.
  3. Preservar el conocimiento generado, asegurando el acceso al mismo de forma transparente, controlada y segura, con independencia del momento, o de la plataforma tecnológica con la que fue generado.
  4. Garantizar el uso eficaz y eficiente de las infraestructuras tecnológicas de la organización.

 

Algunas estrategias útiles

Si queremos lograr la interoperabilidad dentro de nuestra organización debemos atender a sus dimensiones organizacional, semántica y tecnológica, pero hay algunas estrategias generales que nos pueden ser de utilidad, como por ejemplo, las siguientes:

  1. Buscar la accesibilidad de los contenidos y el conocimiento, con independencia de la tecnología que se use para acceder a ellos.
  2. Establecer unas políticas de seguridad y privacidad coherentes y fáciles de llevar a cabo, con unos mínimos acordes con el nivel de amenaza y tipo de información a proteger. Hay que tener en cuenta, que la seguridad suele ir reñida con la comodidad.
  3. Uso exclusivo de estándares abiertos, convirtiendo a estos estándares toda la información que se encuentre en formatos privativos, o que se encuentre almacenada usando estándares abiertos en situación de abandono.
  4. Siempre que sea posible, se debería optar por el uso de software libre. No en vano, el software libre suele usar preferentemente estándares abiertos. Asimismo, es frecuente que el software libre ayude a definir nuevos estándares abiertos y sus especificaciones están disponibles públicamente. La disponibilidad del código fuente también tiene como consecuencia el debate abierto y democrático sobre sus especificaciones y estándares, lo que lo suele hacer que el software libre sea más robusto e interoperable que las aplicaciones privativas equivalentes. No será muy complicado encontrar aplicaciones libres que cumplan con los criterios de nuestro marco de interoperabilidad, por lo que las deberíamos considerar en igualdad de condiciones con sus contrapartidas propietarias en todo plan de adquisición.
  5. Si es posible, deberíamos usar aplicaciones, o herramientas de desarrollo, que puedan funcionar en más de una plataforma tecnológica. En este sentido, las aplicaciones JAVA, o tecnologías como el XML, serán de gran ayuda para lograr nuestros objetivos de interoperabilidad sin caer en las trampas de la dependencia tecnológica, o del "legacy". Si optamos por aplicaciones y herramientas multiplataforma, no tendremos problemas para optar por una u otra plataforma tecnológica en base a nuestras necesidades futuras.
  6. El uso de la virtualización nos puede ayudar a lograr la interoperabilidad a un coste razonable y sin tener que renunciar a la plataforma tecnológica que consideremos más adecuada en cada momento.
  7. Las arquitecturas orientadas a servicios y las aplicaciones Web, si las diseñamos interoperables y basadas en estándares abiertos, nos permitirán independizar la plataforma tecnológica del cliente de la del servidor, lo que aumentará la neutralidad tecnológica de la organización y mejorará su capacidad para cambiar de plataforma tecnológica de los clientes, o del servidor, si se considerase necesario.

El aspecto organizacional de la interoperabilidad es evidente que depende de nuestra organización, por lo que es complicado hablar de un caso general, o de una recomendación básica, que cubra todas nuestras necesidades y situaciones. En el aspecto semántico, la recomendación básica sería el uso de XML, incluso con el establecimiento de diccionarios personalizados y adaptados a las necesidades específicas de nuestra organización. Sin embargo, en el aspecto tecnológico, como más general, sí es posible establecer unas recomendaciones básicas para lograr la interoperabilidad técnica. Cuando pensemos en la interoperabilidad técnica debemos considerar los siguientes escenarios:

  1. Las comunicaciones hacia el exterior:
    1. La presentación e intercambio de datos.
    2. La accesibilidad a la información y diseño de las interfaces.
    3. La posibilidad de acceso multicanal.
    4. Los juegos de caracteres e idiomas.
    5. La posibilidad de generación de conocimiento de forma colectiva y concurrente.
    6. Los estándares para el almacenamiento de información y formato de documentos.
    7. La compresión de archivos.
  2. En las comunicaciones internas debemos considerar:
    1. La integración de datos y el middleware.
    2. El uso de estándares XML y EDI (Electronic Data Interchange).
    3. El establecimiento de servicios web.
    4. El uso de arquitecturas distribuidas orientadas a servicios (SOA).
    5. El establecimiento de servicios de interconexión.
    6. El uso de protocolos de transferencia de archivos e información.
    7. El transporte y seguridad de la información, teniendo en cuenta además, que la seguridad afecta a todas las capas de comunicación. En general, la seguridad debe tenerse en cuenta para establecer los servicios de seguridad, las infraestructuras de clave pública, los sistemas de cifrado, la seguridad de los servicios web, los cortafuegos y la protección general contra malware e intrusiones.
    8. El establecimiento de servicios de almacenamiento de información.
    9. El acceso a las cuentas de correo corporativas y a los servicios distribuidos.
    10. El establecimiento de servicios de directorio y de nombres de dominio.
    11. El establecimiento de todos los servicios de red.

En todo caso, el 80% de nuestros problemas de interoperabilidad corporativa, en sus dimensiones vertical, horizontal y en el tiempo, deberían desaparecer si usamos estándares abiertos y tenemos en cuenta el principio de neutralidad tecnológica en todas nuestras decisiones, olvidándonos por un momento de la plataforma tecnológica que estamos usando y de las aplicaciones "oficiales" aprobadas en nuestra organización, para comenzar a pensar de forma global y prioritaria, en estándares abiertos.



"Copyleft 2009 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved"

Etiquetas

Comentarios

Selecciona arriba tu forma preferida de visualizar los comentarios y pulsa el botón para guardar tu elección para próximas visitas (sólo si eres usuario registrado).

Fernando,

Gracias por otro de los excelentes artículos de esta interesante serie.

Debo decir que estoy de acuerdo, salvo en algunos puntos que paso a detallar.

En "Algunas estrategias útiles", en el punto 3 pones "uso exclusivo de estándares abiertos". Esto, aunque deseable, lamentablemente no siempre es posible.

Para comenzar, la mayoría de las organizaciones grandes o muy grandes que producen bienes de uso (coches, trenes, barcos, neveras, televisores) o bienes a granel (combustibles, lubricantes, bebidas cola, productos químicos, comidas envasadas, etc) tienen sistemas altamente especializados que son prácticamente imposibles de reemplazar aunque quisieran. Claro que no quieren, ya que en la mayoría de los casos son aplicaciones que se han ido refinando con los años hasta alcanzar un nivel de sofisticación que sería carísimo igualar comenzando desde cero.

También está el caso de las instituciones bancarias y financieras (entre muchas otras), donde prevalece el uso de Mainframes que otra vez, son imposibles de reemplazar por los ordenadores de juguete (en comparación) con los que normalmente tenemos contacto. No insistas, los Mainframes juegan en otra liga con la que directamente no se puede competir.

Otras áreas especializadas como clima, defensa, diseño industrial, etc, tienen super-ordenadores especializados que utilizan su propio software y por razones obvias, también son muy difíciles o directamente imposibles de reemplazar.

En el punto 3 recomiendas la utilización de software libre. Otra vez, aunque deseable, muchas veces no es posible. El software libre puede ser perfectamente apto para muchas tareas y quizás sea perfectamente apropiado para el uso hogareño (a mi familia y a mi, ciertamente nos alcanza y nos sobra) o en pequeñas -muy pequeñas- empresas. Pero la realidad es que en muchos casos no está a la altura del software comercial, por lo que es muy difícil de reemplazar. Las aplicaciones comerciales más nombradas con grán ventaja sobre sus homólogos de software libre son Photoshop, Excel y Oracle, claramente superiores -y en varios órdenes de magnitud- a Gimp, Calc y MySQL. Sin embargo, estos son solo unos ejemplos de software generalista. La mayoría de las empresas utiliza software comercial especializado o para el cual en general no hay contrapartida de software libre, comenzando por Directorio Activo, continuando por SAP, pasando por software de Punto de Ventas, control de Stock, Logística y muchísimas cosas más. Nótese que hay cierta cantidad de estas aplicaciones comerciales que corren bajo Unix/Linux, Oracle siendo sólo una de ellas, pero también he visto software de punto de ventas ejecutándose sobre Linux, por ejemplo. A éstos también los cuento como software comercial y no libre, a pesar que se ejecuten sobre sistemas operativos libres.

En el punto 5 mencionas el uso de Java y XML. Con éste último estoy de acuerdo. Sin embargo, con Java no. Aclaro que es una opinión personal. Java es algo a evitar a toda costa y parece haber sido inventado por Intel y Kingston por su altísimo consumo de procesador y memoria, además de ser la mar de ineficiente. Si quieres algo multiplataforma utiliza C/C++ y mantente dentro de POSIX.

En el punto 6 mencionas el uso de la virtualización para ayudar a lograr la interoperabilidad. Con este punto no es que esté en desacuerdo, sino simplemente no entiendo cómo la virtualización puede ayudar aquí (igual estoy un poco espeso), por lo que te pido que por favor me lo expliques.

Lo dicho anteriormente: con el resto estoy de acuerdo.

Un saludo,
Andy

Una cosa son los estándares abiertos y otra bien distinta las aplicaciones y los sistemas operativos. El uso de estándares abiertos no tiene que implicar el cambio de sistemas o de programas, incluso se pueden establecer capas de interoperabilidad para interconectar un mundo interoperable con otro que no lo es, es solamente un problema de estrategia y visión a largo plazo. No debes caer en la tentación de simplificar un problema tan complejo y menos, cayendo en los tópicos de siempre.

No recomiendo el uso de SL, digo que se debería usar siempre que sea posible, que son dos cosas distintas. No estoy conforme con el ámbito de aplicación que propones puesto que son las grandes corporaciones, en mainframes y en aplicaciones críticas o de supercomputación, los que más están usando software libre en este momento. Por otro lado, no voy a entrar en un debate que ya es viejo en relación a las bondades o carencias del software libre y el privativo, pero si tenemos en cuenta la ley de Pareto y el uso que hacen los usuarios del software, creo que los argumentos del 80% de los usuarios en defensa de la "calidad" o "prestaciones" del software privativo carece de fundamento.

En realidad la estrategia multiplataforma es mucho más compleja que el uso de herramientas de desarrollo que puedan generar código en y para varias plataformas, también pasa por intentar usar software que también sea multiplataforma. La idea es maximizar la neutralidad tecnológica de nuestra organización, eliminando los puntos de fricción que puedan producir dependencias tecnológicas. Como bien dices, hay muchas opciones para el desarrollo multiplataforma, no solamente Java, efectivamente, aunque tenía previsto hablar un poco de POSIX (Portable Operating System Interface) junto con SOA, al final se me olvidó y quedó en el tintero, gracias por recordarlo.

En relación con la virtualización creo que está claro, la idea es poder probar o usar otras plataformas tecnológicas sin renunciar a la que usamos normalmente en la empresa u organización. Es posible que la virtualización no mejore directamente la interoperabilidad, pero nos permite cierto grado de neutralidad tecnológica, o de adaptación a las condiciones cambiantes, sin tener que cambiar de golpe toda la arquitectura tecnológica.

Un saludo, Fernando Acero

"Copyleft 2009 Fernando Acero Martí­n. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved".

Buenas las recomendaciones para pensar en una correcta "interoperabilidad", no solamente domestica como también empresarial o corporativa y por sobre todo gubernamental. Las empresas o corporaciones en el ámbito de crecimiento y desarrollo necesariamente tienen que considerar seriamente a la base para sus proyectos de dinámica, de no hacerlo, su aislamiento conduciría a su desaparición hasta que alcancen sus recursos económicos que le permiten su cobertura o consideren las universales tendencias tecnológicas como dinámica de permanencia.

Es bueno hacerle un reconocimiento al señor Richard Stallman, quien ha venido haciendo un titánico esfuerzo para que la comunicación, la información, el conocimiento, . . . pertenezcan a la humanidad. (ofrezco mis disculpas por quedarme tan corto ...)

En libertad, os envío un cordial saludo.

p.d. "Kriptópolis es posible gracias a GNU/Linux ..."

Excelente serie de artículos, que ya los podrían leer ciertas personas a ver si aprenden algo. Me gusta que sobre todo ya indicas que de fácil no tiene nada y que debe ser analizado y planeado cuidadosamente, porque si no se puede acabar casi tan mal como se empieza. EL problema es que siendo soluciones que se deben aplicar a largo plazo , en muchas organizaciones no se lo plantean , prefieren el aquí y ahora y no ven el coste a largo plazo y si los "problemas" momentáneos .

Gracias por estos artículos, son una muy buena referencia.

"Contra la estupidez, los propios dioses luchan en vano" - Schiller

Me parece que la visión debe ser intermedia, si el objetivo es lograr la "interoperabilidad" para las organizaciones, es mucho más fácil integrar a sistemas como AS/400 IBM390 ó UNISYS Clearpath componentes que permitan interconectar sus aplciaciones y datos con entornos más abiertos ó colaborativos. Que nos complejos de instalar ni de mantener sin abordar grandes proyectos para cambiar estas plataformas que han costado años de inversión y esfuerzo.

Adicionalmente el tema de la interconectivad en las organizaciones desde el punto de vista interno está siempre ligado a los niveles de seguridad y privacidad de la información, no se trata solo de "Conectar" nuestros sistemas, se trata de diseñar y soportar funcionalidad hacia la organización y sus clientes de forma segura y estable.

No creo posible acabar con los sistemas legacy ni depender exclusivamente de software libre.

Patrocinadores

Kriptópolis alojado en
Zilos-Veloxia Network

Tu mejor defensa:
Bufet Almeida