Article published in Software Guru Magazine, July - August 2006 issue.

1. • Reconstrucción
de arquitecturas
• Patrones de
diseño
• SOA
Software Guru CONOCIMIENTO EN PRÁCTICA
Año 02 No.04 • Julio-Agosto 2006 • www.softwareguru.com.mx
ESPECIAL
Integración de
Aplicaciones
[ ENTREVISTA ]
Gloria Quintanilla
Académica, empresaria,
consultora y pionera
¿QUÉ MUEVE A
México, $65.00
TU EMPRESA?
Las aplicaciones detrás de tus procesos
Noticias • Eventos • Fundamentos • UML • Tecnología • Reflexiones [ Tutorial ]
SAP NetWeaver

4. DIRECTORIO
Editor Ejecutivo
A>
Pedro Galván
EDITORIAL Coordinación Editorial
Mara Ruvalcaba
Edición y Producción
Edgardo Domínguez
Arte y Diseño
Oscar Sámano, Dafne Ortega
Consejo Editorial
Francisco Camargo, Guillermo Rodríguez,
Ralf Eder y Raúl Trejo, ITESM CEM;
El proyecto esencial de software en cualquier organización, es el desarrollo o im-
Hanna Oktaba, UNAM-AMCIS;
plantación de un sistema integral de información que automatice e integre los pro-
Luis Cuellar, Softtek;
cesos operativos. Sin duda, estos son proyectos que no pasan desapercibidos, Luis Vinicio León, e-Quallity - ITESO
y cada empresa tiene su propia historia de éxito o terror al respecto. El objetivo
de este número de SG es compartir tips y mejores prácticas para maximizar las Colaboradores
probabilidades de éxito en su próxima aventura con una aplicación empresarial. Luis Daniel Soto, Ariel García, Jorge Palacios,
Ana Vázquez, Rigoberto Calleja, Walter Risi,
Agradecemos el entusiasmo y esfuerzo de todos los colaboradores que hicie- Gerardo Borbolla, Adrián Ruffinatti, Enrique
ron posible este número de SG. En especial a Gloria Quintanilla, quien nos hace Duhne, Luis Antonio Rangel, Marco Antonio
sentir muy orgullosos de tener gente como ella en la industria. Les recordamos Cruz, Valerio Adrián Anacleto, Eduardo
que pueden enviar cualquier propuesta de contenido, o retroalimentación a Noriega, Gabriel Vázquez, Sergio Orozco,
editorial@softwareguru.com.mx. Teresa Lucio Nieto, Leon Tripp, Joaquín Uribe.
Ventas
Adicionalmente, queremos compartir con ustedes nuestra alegría por la madurez
Claudia Perea, Natalia Sánchez
y crecimiento que está alcanzando SG. El siguiente hito en este crecimiento está
en lograr que los gurús internacionales vengan a nuestro país a compartir su Distribución
conocimiento y experiencia. Esto lo vamos a conseguir con el congreso SG ‘06 en Daniel Velázquez
septiembre de este año, que precisamente se junta con el segundo aniversario
de SG. Asi que nos vemos en SG ‘06 para celebrar. Ilustración de Portada
Miguel Ángel Gonzaga Leyva
Contacto
info@softwareguru.com.mx
Equipo Editorial +52 55 5239 5502
SG Software Guru es una publicación bimestral editada
por Brainworx S.A. de C.V., Malinche no. 6, Col. El
Parque, C.P. 53398, Naucalpan, México. Prohibida la
reproducción total o parcial del contenido sin previo
aviso por escrito de los editores. Todos los artículos
son responsabilidad de sus propios autores y no
necesariamente reflejan el punto de vista de la
editorial. Reserva de Derechos al Uso Exclusivo: 04-
2004-090212091400-102. Certificado de licitud de tí-
tulo: 12999. Certificado de licitud de contenido:10572.
ISSN: 1870-0888. Registro Postal: PP15-5106. Se
imprimió en junio de 2006 en Litográfica Roma.
Distribución controlada por Sepomex. Distribución en
locales cerrados por CMDE.
02 JUL-AGO 2006 www.softwareguru.com.mx

5. contenido jul-ago 2006
Año 2 número 04
26
EN PORTADA
Aplicaciones Empresariales
Cualquier empresa moderna requiere
de aplicaciones empresariales para
automatizar e integrar sus procesos. En
esta ocasión, profundizamos sobre la
adquisición, implantación y evolución de
éstos sistemas.
Productos ESPECIAL 20
Enterprise Application Integration (EAI)
LO QUE VIENE 10 Walter Risi nos da un paseo por los
Genero db, Eclipse Calllisto, conceptos básicos de la integración de
Microsoft/SAP Duet aplicaciones, así como los escenarios
más comunes.
NOVEDADES 12
Visual Studio TeamSystem
TUTORIAL 16 Prácticas
SAP Composite Application Framework
ARQUITECTURA 36
Reconstrucción de Arquitecturas
Valerio Adrián Anacleto nos enseña la técnica
de reconstrucción de arquitecturas para conocer
cómo se encuentra estructurada una aplicación
Columnas
DISEÑO 38 Entrevista 24
Tejiendo Nuestra Red 08 Combinando Patrones de Diseño Gloria Quintanilla
por Hanna Oktaba Eduardo Noriega nos muestra como combinar
patrones de diseño para desarrollar soluciones
Mejora Continua 10 flexibles y robustas.
por Luis Cuellar En Cada Número
ARQUITECTURA 42
Tendencias en Software 45 Integración y Orquestación con SOA Noticias y Eventos 04
por Luis Daniel Soto En la primera parte de esta serie, Gabriel UML 46
Vázquez nos brinda un panorama sobre la arqui- Fundamentos 48
Cátedra y Más 54 tectura orientada a servicios (SOA), así como la Carrera 48
por Joaquín Uribe integracion y orquestación basada en servicios. Infraestructura 50
www.softwareguru.com.mx JUL-AGO 2006 03

6. NOTICIAS
Noticias
DebConf6 A diferencia de otras distribuciones de Linux, llevado a cabo en Francia, Canada, Noruega,
Debian no es financiado por grandes empre- Brasil, y Finlandia, así que fue un gran honor
Del 13 al 22 de mayo se celebró en México la sas, y es enteramente desarrollado por una que México fuera elegido este año. Agradece-
conferencia anual de desarrolladores de De- fuerte comunidad de voluntarios de todo el mos el esfuerzo de los organizadores locales,
bian, DebConf6, a la cual asistieron cerca de mundo. El objetivo de DebConf es juntar a especialmente Gunnar Wolf, por enfrentar
300 desarrolladores de todo el mundo. esta comunidad de desarrolladores una vez este reto y contribuir a poner a México en el
al año para conocerse, implementar mejoras mapa mundial del software.
Debian es un sistema operativo basado en al sistema, compartir experiencias, definir di-
software libre que utiliza el kernel de Linux. recciones futuras y, por supuesto, divertirse. Más información sobre Debian en:
Es reconocido por su estabilidad y seguridad. Las ediciones anteriores del DebConf se han www.debian.org
TechBA Montreal 2° Foro Nacional de Innovación y
Tendencias Tecnológicas
El pasado 9 de junio se llevó a cabo la apertura de TechBA Montreal,
la tercera aceleradora de negocios creada por el gobierno federal para La Cámara Nacional de la Industria Electrónica, de Teleco-
impulsar empresas mexicanas de tecnología en Norteamérica. municaciones e Informática (CANIETI), organizó del 1 al 3
de junio en las ciudades de Tijuana y Ensenada, el 2º. Foro
El programa TechBA tiene por objetivo apoyar empresas mexicanas Nacional de Innovación y Tendencias Tecnológicas.
altamente innovadoras, que hayan desarrollado tecnología propia y
estén interesadas en buscar nuevos mercados y aumentar sus posibili- El propósito del foro fue generar espacios de discu-
dades de hacer negocios en el extranjero. TechBA Montreal es la tercera sión de los expertos y especialistas internacionales,
aceleradora de este programa (junto con la de TechBA Silicon Valley y sobre las tendencias en las industrias de: electrónica
Austin), que en conjunto apoya a 97 empresas a la fecha. (TV Digital y semiconductores, nanotecnología), auto-
motriz, tecnologías de la información, productos mé-
TechBA Montreal se enfocará en los mercados de dispositivos médicos, dicos y biotecnología.
aeroespacial, alimentos y sistemas de software embebido para el sec-
tor automotriz Entre los conferencistas participantes estuvieron Mr.
Rajiv Chumar Bhatia (Embajador de la India en México),
Más información en: www.techba.com Luis Daniel Soto (Microsoft), Héctor Nava (IDC), y Ricardo
Zermeño (Select).
04 JUL-AGO 2006 www.softwareguru.com.mx

7. ESPECIAL
ENTERPRISE Mucho más que Productos de Moda Por Walter Risi
APPLICATION INTEGRATION
I maginemos el caso de una compañía petrolera, cuyos pro-
cesos de negocio van desde el descubrimiento de nuevas
fuentes de hidrocarburos hasta su explotación, pasando por
¿Qué es “Enterprise Application
Integration” (EAI)?
Se llama EAI al uso de medios de software para conectar a un
varios procesos intermedios. Todos estos procesos son sopor- conjunto de aplicaciones empresariales. En la definición ante-
tados por diferentes aplicaciones, en un ambiente hetero- rior, “medios de software” es cualquier mecanismo que permita
géneo con distintos proveedores, plataformas y productos. realizar tal conectividad, desde archivos planos hasta servicios de
Supongamos ahora que necesitamos una ficha completa de mensajería. Por otro lado, una “aplicación empresarial” es cual-
un pozo petrolero en una ubicación geográfica particular. quier aplicación que da servicios a la empresa, desde una aplica-
Dicha información podría estar diseminada entre una de- ción propia del mercado en el cual opera (petróleo, banca, etc.)
cena de aplicaciones distintas, ¿cómo podemos obtener la hasta las aplicaciones administrativas típicas (CRM, ERP etc.).
,
información integrada?
La forma más simple de EAI, como para ilustrar este con-
Situémonos ahora en la mesa de dinero de un importante cepto, es el intercambio de datos entre dos aplicaciones a
banco que ha pasado por una fusión con otro banco de través de algún medio como un archivo plano o una base
envergadura similar. Algunos productos financieros son de datos. Es muy común en una empresa, por ejemplo, la
manejados por una aplicación perteneciente al banco ad- existencia de “interfaces” consistentes en archivos planos de-
quirido, y otros por aquella que tenía ya el banco compra- positados temporalmente por un proceso en un directorio
dor. Sin embargo, debemos consolidar ambas fuentes para compartido, que luego son tomados por otro proceso. Otra
poder calcular ganancias y pérdidas... ¿Volcamos reportes forma muy común es a través de bases de datos accedidas por
de ambas aplicaciones y los consolidamos manualmente? diferentes sistemas. Finalmente, las formas más modernas de
¿Qué costo tendría eso? Y, ¿Cuál es la posibilidad e impacto EAI hacen uso normalmente de servicios de mensajería, des-
de un error? de ad-hoc hasta basados en estándares de la industria.
Situaciones como la anterior son vividas a diario por gran- Una Necesidad de Hoy y Siempre
des empresas de diferentes mercados, desde hace más de El concepto de EAI no es para nada nuevo. Es tan antiguo como
una década. Estas situaciones surgen de fenómenos natu- la necesidad de intercambiar datos entre dos aplicaciones separa-
rales en la empresa... aplicaciones que nacieron y crecieron das, y las empresas han tenido este problema casi desde el mismo
aisladas... aplicaciones de diversos fabricantes... fusiones momento en que empezaron a usar sistemas de software.
y adquisiciones... y, sin duda, otras razones particulares.
Sin embargo, algo queda claro: en la empresa actual, cuyas ¿Por qué EAI es una necesidad “de hoy y de siempre”? Por-
estrategias están cada vez más apoyadas desde las TIs, la in- que es una realidad que una empresa es un ecosistema de
tegración de las aplicaciones siguiendo las necesidades del aplicaciones diferentes en naturaleza, que requieren comu-
negocio es una realidad. Pero la solución no está en SOA, nicarse entre sí, pero que no fueron destinadas a comunicar-
Enterprise Service Bus, message-oriented middleware ni algún se entre sí. La necesidad de integración es estratégica y está
otro buzzword tecnológico, sino en una estrategia de inte- para quedarse. La integración no debe entenderse como un
gración claramente alineada, planeada y ejecutada según problema del “hoy”, heredado de los sistemas legacy que no
las necesidades del negocio. De eso trata este artículo, de tuvieron en cuenta la necesidad de integrarse. Muy por el
cómo abordar la Integración de Aplicaciones Empresariales contrario, la integración es una realidad de siempre, ya que
con un marco de trabajo en el cual la tecnología está “al siempre tendremos sistemas diferentes en diferentes sectores
servicio” del negocio. del negocio, cuyas realidades siempre serán diferentes.
Walter Ariel Risi es Coordinador de Consultoría Tecnológica y consultor en mejora de procesos de software para Pragma Consultores Argentina. Anteriormente,
se desempeñó como consultor de Lifia (Laboratorio de la Universidad Nacional de La Plata) para JPMorgan y Lumina Finance. Adicionalmente realiza tareas de
investigación, habiendo publicado artículos en congresos y publicaciones internacionales. Walter posee las certificaciones Certified Quality Engineer (CQE) y Cer-
tified Software Quality Engineer (CSQE) de la American Society for Quality (ASQ). wrisi@pragmaconsultores.com
20 JUL-AGO 2006 www.softwareguru.com.mx

8. Mientras que los problemas técnicos son
generalmente visibles, los problemas
organizacionales no son tan evidentes.
Las Dificultades del EAI Más adelante en este artículo revisaremos un enfoque estruc-
Las dificultades más inmediatamente visibles, aunque no turado y alineado al negocio, que busca encontrar y resolver
necesariamente las más importantes, son principalmente problemas organizacionales para un proyecto EAI. Pero an-
técnicas. Dado que muchos de los sistemas son pensados tes, conozcamos los diferentes tipos de integración.
para ser utilizados en forma aislada (para un departamento
o pequeño grupo de usuarios), raramente están preparados Tipos de Integración
para soportar la seguridad y escalabilidad requeridas para ha- No existe una forma única de integración adecuada a todas las
cerlos disponibles hacia otros usuarios y sistemas. situaciones, por el contrario, a lo largo de los años se han de-
sarrollado diferentes formas de integración, adecuadas a dife-
Por otro lado, existen problemas del estilo organizacional o rentes necesidades. Si bien no hay una taxonomía estándar, los
de gestión, entre los cuáles distinguimos los siguientes: siguientes son tipos de integración generalmente aceptados:
• Integración “miope” y no planificada. Las interfaces
pensadas para resolver la necesidad inmediata a veces 1. Integración Orientada a la Información. Consiste en el
crean acoplamientos indeseables, que se suman a la pila pasaje de información de un sistema a otro. Casos típicos: el
de sistemas legacy poco mantenibles. Se resuelve un pro- envío de transacciones comerciales, y las bases de datos inte-
blema y se crea otro. gradas (por ejemplo, bases de datos que reúnen los datos de
• Carencia de un análisis de impacto en la forma de trabajar todos los clientes de una compañía, en forma sincronizada
de los usuarios. Es decir, “luego de la integración de A y B... con las demás aplicaciones que usan tales clientes).
¿cómo se ve afectado el trabajo de los usuarios de A y B?”.
Los anteriores no son más que manifiestos evidentes de los
siguientes problemas de fondo, aún más graves:
• Mapa de aplicaciones no definido, desconocido o
“spaghetti”. Esto dificulta de sobremanera detectar si
una nueva integración no está causando un acoplamien-
to indeseable, o si se está integrando en forma consisten-
te en diferentes sectores de la empresa.
• Relación entre aplicaciones y procesos de negocio no Figura 1. Integración Orientada a la Información.
definida, poco clara o desordenada. Esto impide discer-
nir qué aplicaciones son responsables de cada proceso o Típicamente, la integración orientada a la información no requie-
flujo de información y, por lo tanto, impide discernir la re modificaciones en las aplicaciones integradas, sino solamente la
forma de integración más adecuada para el negocio. implementación del mecanismo de pasaje de información entre
los repositorios de datos de las aplicaciones respectivas; esto hace
Mientras que los problemas técnicos son generalmente que sea la forma de integración más simple y de menor impacto.
visibles, los problemas organizacionales no son tan evi-
dentes y, por lo tanto, son mucho más riesgosos. Y no Si bien la integración orientada a la información consiste en
sólo eso, sino que en general son también más difíciles el pasaje de datos entre los repositorios de las aplicaciones, no
y caros de solucionar. Por otro lado, la mayoría de los necesariamente esto implica que tal integración se realice pura
proyectos de EAI son conducidos por informáticos bien y exclusivamente usando tecnología de base de datos. También
capacitados para resolver el aspecto técnico de la integra- podría realizarse mediante archivos planos, APIs de las aplica-
ción, pero quizás no tan duchos en la detección y resolu- ciones, o incluso servicios de mensajería. La clave de este tipo de
ción de los problemas organizacionales. integración no está en el medio técnico, sino en el hecho de que
lo que se integra es información y no procesos o servicios.
Finalmente, es importante pesar las dificultades en térmi-
nos de los riesgos que las mismas suponen para el negocio. 2. Integración Orientada a Procesos. Subiendo en el nivel
Una dificultad técnica normalmente puede solucionarse, de abstracción, nos encontramos con la integración orien-
eventualmente con costo adicional. Sin embargo, una tada a los procesos de negocio. Esta integración consiste en
integración (posiblemente costosa) que no fue pensada la automatización de los diferentes pasos de un proceso de
claramente desde el punto de vista del negocio, puede no negocio a través de una o más aplicaciones. Si bien esto mu-
acarrear beneficios para el mismo, redundando en un gas- chas veces implica intercambio de información entre aplica-
to necesario (y tal vez problemas adicionales). Dejando a ciones, esto es simplemente un medio para lograr el fin en
un lado el peso relativo de tales problemas, es claro que cuestión. Además de información, en la integración orien-
un proyecto de EAI es tanto informático como organiza- tada a procesos de negocio también se integra el control. Tí-
cional, ya que tanto las necesidades como las dificultades picamente, este tipo de integración se lleva a cabo mediante
están de ambos lados. un flujo de trabajo (workflow).
www.softwareguru.com.mx JUL-AGO 2006 21

9. ESPECIAL
Figura 2. Integración Orientada a los Procesos de Negocio. Figura 4. Integración Orientada a los Portales.
3. Integración Orientada a Servicios. Otro tipo de integra- La integración mediante portales tampoco es necesariamen-
ción, muy en boga en estos días, es la integración orientada te excluyente de los otros tipos de integración. De hecho, el
a servicios. En este modelo, una aplicación expone una se- portal puede alimentarse a través de servicios, y el mismo
rie de servicios de negocio que pueden ser usados por otras portal puede también soportar la participación de actores
aplicaciones. Se busca no solamente el reuso, sino también humanos en procesos de negocio.
el hacer que cierta lógica de negocio sea implementada una
única vez en la empresa, y reutilizada el resto de las veces. Eligiendo un Tipo de Integración
No existe una receta mágica acerca de qué tipo (o tipos) de
integración se puede aplicar en cada situación. Sin embargo,
los siguientes puntos pueden proveer una guía básica:
����������������
�������������� • Si la necesidad es centralizar el origen de un cierto tipo
�������� ��������������� de dato (por ejemplo, centralizar una base de clientes),
entonces en principio nos es suficiente con una integra-
ción orientada a la información. En este caso es crucial
���������������� revisarlo con todos los actores importantes (los represen-
�������
�������� ����������������
tantes de TI y negocio relacionados con las aplicaciones
���������� a integrar) y acordar universalmente el flujo resultante
������������ de la integración. Esto para evitar futuras integraciones
inconsistentes con esta (por ejemplo, que si se acordó
�����������
una base única de clientes, no surja de pronto una base
�������������� alternativa de clientes).
�����������
��������� • Si la necesidad es centralizar cierta función de negocio
����
(por ejemplo, el cálculo de precios de los productos de
la compañía), entonces es conveniente pensar en térmi-
Figura 3. Integración Orientada a los Servicios. nos de servicios. Una aplicación debe ser elegida como
la oficial para realizar tal función (podrían ser varias, en
La orientación a servicios también permite la creación de las caso de que se determine en qué casos se invoca a una y
llamadas “aplicaciones compuestas”. Nuevas aplicaciones que en qué casos a otra).
surgen a partir de la unificación de diferentes servicios preexis- • El caso de la integración orientada a procesos normal-
tentes en la organización. En el diagrama anterior, la Aplicación mente está asociada a una decisión más estratégica. Si la
de Trading Web podría ser una aplicación compuesta, si toda su necesidad va más allá de un dato o función, y tiene que
lógica partiera de invocación a servicios de otras aplicaciones. ver con formalizar o automatizar procesos de negocio
completos, ésta es la opción adecuada.
La orientación a servicios y la orientación a procesos no son • La integración orientada a portales generalmente es un
excluyentes, sino complementarias. De hecho, el caso ideal caso más particular, y tiene que ver con la necesidad de faci-
de la integración es aquel en el cual los procesos de negocio litar la llegada de la información a quiénes la deben utilizar.
pueden ensamblarse a partir de la invocación ordenada y Por ejemplo, si un operador debe consultar cinco aplicacio-
coordinada de diferentes servicios, que satisfacen las necesi- nes al comenzar el día, claramente pierde bastante tiempo
dades de los distintos subprocesos. al tener que abrir las cinco y navegar hasta los datos que
necesita; un portal personalizado puede hacerle llegar todos
4. Integración Orientada a los Portales. Finalmente, algu- esos datos en una única pantalla. El portal puede servirse de
nos autores distinguen la integración orientada a los portales integraciones de información, servicios, e incluso facilitar la
como un tipo separado. El aspecto distintivo de esta forma automatización del proceso de negocio. Por esto, la orienta-
de integración es la agrupación de varios aplicaciones bajo ción orientada a portales puede convivir perfectamente con
una interfaz visual común, normalmente un portal web. los otros tipos de integración.
22 JUL-AGO 2006 www.softwareguru.com.mx

10. La integración mediante portales
tampoco es excluyente de los otros tipos
de integración.
En cualquiera de los casos, es importante ver cómo Determinar las unidades organizacionales, pro- aplicaciones, y optimizar la forma en que tales
juega el negocio en la decisión del tipo o tipos de cesos, aplicaciones y usuarios afectados. Una aplicaciones se relacionan para soportarlos.
integración a utilizar. En los primeros casos, más necesidad táctica no debería ser, por lo general, 2. Identificar el alcance e impacto organizacio-
simples, veamos que rescatamos la necesidad de muy abarcativa a nivel organizacional. En caso nal. Determinar las unidades organizacionales,
consensuar la integración con los actores. En el contrario, se recomienda nuevamente revalidar procesos, aplicaciones y usuarios afectados.
caso de los procesos, es claro que tales procesos si el rumbo no debería ser la ruta estratégica. 3. Identificar el mapa actual de procesos y aplica-
deben ser definidos por el negocio, y soportados 3. Identificar concesiones para hoy y acciones ciones. Es muy probable que aunque se conozca
por la TI. En el caso de los portales, hablamos de para mañana. Es posible que la naturaleza qué procesos se desea automatizar, los detalles
que la integración está motivada por las necesida- táctica de la solución requiera hacer algunas de los mismos no sean completamente conoci-
des de información de un actor del negocio. Es concesiones, como por ejemplo, realizar una dos, ni tampoco la forma en que se mapean a
fundamental, entonces, siempre tener en cuenta integración que resulta en un acoplamiento las aplicaciones. Es fundamental, antes de ini-
las necesidades de la organización antes de elegir no del todo deseable. En tal caso, es muy im- ciar un enfoque de integración estratégico, do-
productos que nos fuercen a un tipo de integra- portante identificar tales concesiones y esta- cumentar los procesos afectados, las unidades
ción que no es el que necesitamos. blecer algunas reglas de juego para evitar que a las que pertenecen, los roles que participan y
los riesgos subyacentes se potencien con el las aplicaciones requeridas para llevarlos a cabo.
Una Mapa de Ruta para tiempo. Por ejemplo, acordar que un acopla- De otra manera, no se tendrá el mapa actual
la Integración miento indeseable no será explotado más allá requerido para trazar el mapa futuro.
Tras haber conocido la necesidad, las dificul- de este proyecto particular. Adicionalmente, 4. Trazar el mapa futuro de procesos y aplica-
tades inherentes y las diferentes formas que pueden programarse acciones a futuro para ciones. Una vez detectado el mapa actual, de-
puede tomar la integración, nos resta hilar remover tal acoplamiento. terminar como el mismo se verá afectado tras
esos componentes en un mapa de ruta que po- 4. Definir el tipo de integración a utilizar. la integración. Puntos clave a considerar son
damos usar para guiar nuestros proyectos de Una necesidad táctica normalmente podrá los procesos que sufrirán modificaciones, las
EAI. Veamos una metodología que nos puede ser resuelta con una integración de informa- aplicaciones que sufrirán modificaciones o se-
servir como checklist básico. ción o servicios. rán retiradas, y cómo los diferentes roles de
5. Seleccionar tecnología de integración. Elegir la organización deberán cambiar su forma de
En primer lugar, reconozcamos una realidad la forma de implementar el tipo de integra- trabajar en un aspecto u otro.
de la empresa, y es que no todos los emprendi- ción seleccionado. Si la necesidad es táctica, es 5. Establecer la ruta de transición a seguir. Un
mientos del día a día responden a planes estra- conveniente que sea resuelta con alguna de las proyecto estratégico raramente se ejecuta de
tégicos claramente orquestados. Es por eso que tecnologías ya probadas en la organización. una sola vez, dado su alcance y magnitud. En
muchas necesidades de integración a las cuáles 6. Planear la integración. Como todo pro- cambio, el mapa futuro se alcanzará siguiendo
nos enfrentamos puedan no responder a una yecto, una integración requiere cuidadosa una ruta consistente a través de varios proyec-
estrategia mayor, y aún así requerir llevarse a planificación. En especial, debe realizarse un tos que acercarán paulatinamente la situación
cabo para responder a necesidades bien reales. cuidadoso análisis de riesgos. actual a la futura.
En cualquiera de los casos, un enfoque cuida- 7. Planear la transición. ¿Qué debe hacerse 6. Implementar la ruta de transición establecida.
doso y estructurado nos ayudará a evitar que la para que el negocio siga funcionando co- Siguiendo lo ya mencionado, la ruta se ejecuta
respuesta a necesidades tácticas de hoy entor- rrectamente tras implantarse la integración? a través de varios proyectos de índole táctica.
pezca la integración estratégica que busquemos Esto normalmente incluye comunicación y
mañana. Por esto, dividimos nuestro mapa en capacitación a usuarios de las aplicaciones
dos “rutas”: una táctica y una estratégica. afectadas, y eventualmente la baja de alguna
función de alguna en las aplicaciones utiliza- Conclusión
La Ruta Táctica das anteriormente. La Integración de Aplicaciones Em-
La ruta táctica es aquella que seguiremos para 8. Implementar la integración y la transición. presariales es un tema de gran im-
responder a las necesidades de hoy, pero sin ir Llevar a cabo la integración y la transición si- portancia. Sin embargo, muchas
en detrimento de aquellas que podamos tener guiendo los planes establecidos. veces los conceptos centrales del EAI
mañana. Recurrimos a ella cuando tenemos una se pierden en la complejidad de la
necesidad a corto plazo que debemos suplir. Los La Ruta Estratégica oferta tecnológica y las promesas de
pasos recomendados son los siguientes: La ruta estratégica es aquella abordada por la los proveedores. EAI es un concepto
1. Identificar la necesidad a cubrir. Determinar si organización más allá de un proyecto particu- que debe entenderse desde las necesi-
debemos integrar información, funcionalidad y/o lar, y responde no sólo a necesidades de hoy, dades del negocio, la arquitectura de
procesos. En el caso de tratarse de un proceso, de- sino que adelanta las de mañana. Se utiliza las aplicaciones, y el valor que estas
berá ser un proceso sencillo y aislado; en caso con- cuando la necesidad está guiada por optimizar últimas proveen al negocio... y no
trario, raramente podrá ser tratado a nivel táctico, procesos de negocio en forma integral. Los pa- solamente desde la perspectiva pura-
y requerirá un enfoque estratégico. El caso de los sos recomendados son los siguientes: mente tecnológica.
portales raramente puede ser tratado a nivel tác- 1. Identificar la necesidad a cubrir. Un pro-
tico, a no ser que se trate de un prototipo inicial yecto estratégico normalmente estará asocia- En definitiva, ¡EAI es mucho más que un
restringido a un grupo limitado de usuarios. do a formalizar la manera en que uno o más conjunto de productos de moda!
2. Identificar el alcance e impacto organizacional. procesos de negocio son soportados por las
www.softwareguru.com.mx JUL-AGO 2006 23