Soluciones de integración

Se pueden identificar los siguientes problemas de integracion:

  1. Integración de procesos
  2. Integración de aplicaciones
  3. Integración de información

Integración de información

Ante diversas fuentes de información heterogeneas en la organización se busca el acceso a informacion consistente.

Soluciones:

  1. Replicación de Datos en cada departamento de la organización
  2. Federación de Datos: La federación de bases de datos, es la integración de múltiples bases de datos y modelos de bases de datos en una vista única y unificada de las bases de datos. En otras palabras una base de datos federada es una base de datos virtual compuesta de muchas bases de datos reales físicas.
  3. Uso de formatos no propietarios (XML) para el intercambio de información entre aplicaciones
  4. Creación de repositorio comun de de datos o Datawarehouse

Integración de Procesos

Invocación de tareas en el orden correcto y apropiado para soportar el manejo y ejecución de procesos.

  1. Se basa en la utilizacion de herramientas de WORKFLOW y Groupware que facilitan el diseño de los flujos de trabajo y favorecen el intercambio de informacion entre los grupos de trabajo.

Integración de aplicaciones

La integración de las aplicaciones se puede plantear basandose en tres soluciones:

  1. Soluciones de Integración Orientadas al Servicio
  2. Soluciones de Integración Orientada al Portal

Las soluciones orientadas al Servicio se basan en la ARQUITECTURAS SOA cuya implementación más conocida son los Servicios Web (HTTP+SOAP+UDDI+WSDL+XML).

Las soluciones orientada al Portal se basan en el desarrollo de una sola interfaz comun para todas las aplicaciones.

fuentes:

3 respuestas a Soluciones de integración

  1. paranoias dice:

    No estoy en absoluto de acuerdo con la mayor parte la sección de “Integración de información”.

    >>>1. Replicación de Datos…

    Esto no hace sino incrementar los problemas de integración de información!!!. Es contraproducente crear procesos de ETL (Extración-Transformación-Carga) entre sistemas de información para aunar información, lo que se consigue es tener la misma información desorganizada en MAS sitios, con el handicap de que encima has introducido procesos intermedios que pueden derivar en una degradación mayor de los datos en caso de fallos puntuales.

    >>>2. Federación de Datos:

    Por federación se entiende una visión virtual de sistmas unificados efectivamente, pero orientandose a la administración de los mismos (políticas de seguridad, usuarios, almacenamientos en disco etc) pero el fallo de integración subsiste, por lo que realmente lo único que hemos hecho es “poner bonito” nuestro sistema T.I. pero no hemos arraglado nada.

    >>>3. Uso de formatos no propietarios (XML)

    Esta si es una buena solución, pero no integra nada, es tan sólo una forma inteligente de estandarizar el acceso a datos desde tus aplicaciones para que lean DTDs similares, pero la extracción de los XML deberá hacerlo cada sistema de información de forma individual.

    >>>4. Creación de repositorio comun de de datos o Datawarehouse

    Esto si que no que no. Datawarehousing es una metodología apoyada en varias tecnologías para unificar información, pero a cambio de desrnormalizarla, por lo que para los sistemas transaccionales (los “normales”) es casi NULA como base de información.

    Solo serviría cóm integración de información en caso de que nuestro único objetivo fuese explotar (datamining o reporting) esa información, pero no para “trabajar” con ella.

  2. lcflores dice:

    Creo que el enfoque del árticulo era posibles soluciones de integración, no problemas para la integración. Es evidente que la integración de datos tiene sus problemas y menos mal🙂 porque afortunadamente es lo que nos da de comer a muchos.

    Si pensamos en un sistema de información como una serie de aplicaciones con datos compartidos, podemos pensar según forrester (http://www.forrester.com) en tres tipos de arquitecturas:

    1) Centralizada: Todo en un mismo repositorio.
    2) Distribuida: Varios repositorios.
    3) Federada: Ultimamente muy de moda, sobre todo en la administración pública donde comparten información y tienen muy claro quien es responsable de que datos.

    Problemas vs ventajas, hay miles. Pero a día de hoy son las tres arquitecturas posibles para compartir datos.

    Dicho esto, si nuestros sistemas no tienen nada que ver unos con otros y queremos compartir información. Ciertamente, tenemos 4 opciones:

    1) Replicación de datos: Sin duda es costoso, pero ¿es bueno? o ¿es malo?. Pues depende, hay que mirar los requisitos. Si no necesitas sincronismo total, si puedes tener un día de retraso en la información, si necesitas acceso rápido de lectura en varios centros separados fisicamente,….etc puede que sea una opción a tener en cuenta.

    2) Federación de datos: Es por definición un sistema virtual, pero por ejemplo si nos basamos en el metodo BSP de IBM para modelar nuestro sistema, donde los roles y las responsabilidades sobre la información están claramente definidas, entonces su relación con un modelo de datos federados es simple y sencilla.

    3) XML: XML y webservices son integración casi por definición. Hoy en día es la base para integrar muchos sistemas antiguos con herramientas de ultima generación (ERPs, CRMs,….). Por otro lado, creo que este punto se refiere mas a la generación de formatos neutros de datos en XML para intercambio de información. Los formatos neutros es una solución muy antigua, que con el uso de XML se ha simplificado notablemente.

    4) Data warehouse: Implica desnormalización para integrar los datos, pero vuelvo a mencionar lo que dije en el primer punto, todo depende de las necesidades a cubrir.

  3. paranoias dice:

    Totalmente de acuerdo, sólo que estas hablando de soluciones de Arquiecturas de Sistemas de Información, NO de modelos de integración de datos. Si hablas de modelos de integración de datos, eso NO sirve.

    Otra cosa es que tu Arquiectura, cómo tantas otras, no requiera de una integración de datos, o por lo menos no de una completa, pues entonces perfecto, pero no sólo hay esas opciones, hay bastantes más, ya que sólo el mundo de las soluciones Federadas o del intercambio de información vía XML puede derivar en varias Arquitecturas.

    Perooooo me reafirmo en que si hablamos únicamente de integración de datos, la 1, 2 y 4 (está última si nos orientamos a sistemas transaccionales) no lo son, y la 3 parcialmente.

    P.D. Y no me hables de forrester que soy partner y me leo sus putas “waves” cada dos por tres, putos plastas…

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: