La estrategia que se propone para sostener el desarrollo de los servicios de la red de Infomed es construir un sistema que pueda integrarse con todo. Es una red con una arquitectura abierta de servicios basada en componentes en la que se pueden crear cadenas de valor.
En lugar de constuir un sistema que trate de hacerlo todo usemos las posibilidades que brinda cada sistema al máximo y trabajemos sobre las posibilidades de interoperación y orquestación. La intranet ha marchado bien pero es sólo una instancia. Podemos usar el Plone para crear una comunidad cerrada y eso puede funcionar, pero también podemos usarlo como servidor de aplicaciones específicas.
Así podemos usar Plone para determinadas cosas, Media Wiki para otras, y así en adelante.
No hay que amarrarse a un sólo sistema. La experiencia nos ha mostrado que Plone es bueno para el manejo de flujos y la producción de determinados tipos de contenido pero no para la integración de RSS por ejemplo. Ello nos sugiere combinar sistemas como se está haciendo con el ejemplo de el servidor o “back end” de enlaces al estilo de del.icio.us, o el servidor de páginas Wiki de Infomed wiki.sld.cu que estamos probando.
Siempre que exista una aplicación estable, con una buena comunidad de usuarios y desarrolladores que pueda servirnos como “back end” de determinados servicios podemos optar por ella como son los casos citados. Creo que tendremos que movernos hacia una infraestructura de servicios encima de los sistemas y “back ends” para agregar valor y facilitar la construcción de las citadas cadenas de valor que faciliten el desarrollo de la Infomed 2.0.
Así por ejemplo Drupal serviría para construir portales de agregación de contenidos, Plone para comunidades pequeñas de propósito claro con mucha interacción interna como el caso del área de logística del MINSAP , las misiones médicas en el exterior o la propia intranet del CNICM y sistemas como infoenlaces para socializar etiquetas y enlaces más allá de las fronteras de un sistema específico.
También se puede pensar en usar Plone para servicios de propósito específico cuando así convenga para aprovechar su estabilidad de desarrollo y sus recursos acumulados. Se puede crear un “back end” de artículos usando este tipo de contenido que pueda reusarse en cualquier contexto, o hacer un depositorio de imágenes, u otros tipos de contenido.
En la “ecología” de Infomed cabría una sana convivencia “holónica” de servicios y componentes que pueden orquestarse con relativamente pocas dificultades. Esto es coherente con lo que está pasando en Internet y trata de recoger las mejores experiencias y también la práctica de nuestra red que ya acumula casi 15 años de trabajo sostenido. La Biblioteca Virtual de Salud, la Universidad Virtual y todos los proyectos que puedan desarrollarse se beneficiarán de una alineamiento en torno a este modelo.
Ello nos plantea prioridades como la generalización del uso de “webservices” asociados a cada uno de los servicios con que contamos como las bases de datos que hoy están en webisis, el Localizador de Información de Salud que está funcionando en Scout y otras, el uso de microformatos y el desarrollo de microaplicaciones que puedan usarse fácilmente para integrar soluciones.
Necesitamos también formalizar esta arquitectura y enriquecerla permanentemente usando los propios criterios de trabajo en red, desarrollo de sistemas al estilo del movimiento de código abierto y contenidos abiertos y las herramientas más adecuadas a cada problema.
Filed under arquitectura, desarrollo 2.0, infomed 2.0, web 2.0 by on . Comment. 
Comentarios