Inicio
 > Informes e investigaciones > Blog de TEC > ¿La infraestructura y las aplicaciones por SOA s...

¿La infraestructura y las aplicaciones por SOA son la próxima frontera?

Escrito por: Predrag Jakovljevic
Publicado: mayo 5 2005

SOA, la próxima frontera

El paso rápido que tienen los negocios globales actualmente presenta un conjunto de retos a todas las empresas que estén buscando mejorar y automatizar sus operaciones. Al mismo tiempo, las empresas deben ser capaces de adaptarse rápidamente a los cambios. Algunos de estos retos son la creciente competencia, la falta de reglamentos, la globalización, los requisitos de cumplimiento, las fusiones y las adquisiciones y la externalización, aunadas a las estructuras de la cadena de suministro y los estrictos requisitos que tienen los clientes dominantes, como Wal-Mart. Se trata de cambios críticos cuya implementación puede tomar tiempo debido a la complejidad que implica hacer que sus sistemas de tecnología de la información (TI) soporten el modelo nuevo del negocio. En muchos casos, es necesario evitar por completo los sistemas de TI de batalla y no proporcionar soporte alguno en los momentos en que dicho soporte es esencial. Por consiguiente, los compradores de software empresarial se han dado cuenta de que la arquitectura de los productos juega un papel de gran importancia en la rapidez con que los vendedores pueden implementar, mantener, expandir, adaptar e integrar sus productos.

La arquitectura de los productos debe hacer mucho más que ofrecer funcionalidades técnicas, interfaces de usuarios (UI) y soporte de las plataformas, ya que determinará si el producto durará, será graduable para muchos usuarios y podrá incorporar las tecnologías emergentes para adaptarse a los requisitos de los usuarios que están en evolución. Así, la mayoría de los vendedores de aplicaciones están hablando de integración, funciones avanzadas y tecnología. Sin embargo, no sólo deben ser parte de la estructura empresarial nueva, sino que deben darnos un aprendizaje para el futuro.

En una serie de artículos que se publicó hace tiempo, llamada What’s Wrong With Application Software?, hablamos de las realidades de los negocios ágiles comparados con la capacidad que tiene el software de aplicaciones contemporáneo para enfrentar esas realidades. Algunas de ellas eran:

  1. La economía. En todo el ciclo de vida de las aplicaciones existe un alto costo de desarrollo, soporte y mejoras. El dinero, el tiempo y la calidad limitan la forma en que el software instalado puede cubrir las demandas del negocio. Aunque la arquitectura antigua de los productos es un problema tecnológico, el costo (tiempo, dinero y calidad) es un problema del negocio. Por todas estas razones, las modificaciones, por ejemplo, no son bien vistas. Sin embargo, con los cambios económicos, los enfoques modificados o adaptados pueden resultar prácticos, aunque su costo a largo plazo siempre será más alto. Si quiere obtener mayor información, consulte What's Wrong with Application Software? It's the Economics.

  2. Los negocios cambian constantemente. El software debe actuar como habilitador (no como obstáculo) de los cambios al negocio, tanto durante el despliegue inicial como a lo largo de su ciclo de vida. Actualmente, el mercado se trata de aplicaciones “estables y configurables”, debido a la falacia de que las aplicaciones pueden permitir las “prácticas de excelencia” y tener la flexibilidad suficiente para adaptarse a la mayor parte de los negocios sin necesidad de modificarlos demasiado. Aunque el software puede ser configurado previamente -mediante tablas complejas, parámetros e interruptores- para que maneje una cantidad importante de opciones “flexibles” predeterminadas, esta flexibilidad implica tener que seleccionar de una lista de opciones predeterminadas. Así, aunque el problema de la flexibilidad fue resuelto para las implementaciones iniciales, no es lo mismo para la innovación constante del negocio. La siguiente generación de arquitectura empresarial debe permitir los cambios por demanda a medida que evoluciona el negocio. Si desea obtener mayores detalles, consulte What's Wrong With Application Software? Business Changes, Software Must Change With The Business.

  3. Los negocios son únicos. Todos los negocios tienen elementos únicos. Sin embargo, en lugar de evolucionar, el software de aplicaciones “unitalla” trata de soportar demasiadas funciones que están en conflicto para varias industrias. Asimismo, muchas de las funciones agregadas se aplican únicamente a algunas de las industrias que atiende, es decir que las demás industrias deben sufrir las consecuencias de la “hinchazón” del software que resulta de las funciones que no son esenciales. Es necesario tener una lógica compleja del programa para definir la ruta que debe seguir el programa, en lugar de ejecutar la funcionalidad. Para solucionar esto, los vendedores deben construir productos esbeltos que sirvan a conjuntos específicos de clientes y que permitan que el cliente construya sus propias necesidades. Si desea obtener mayor información, consulte What's Wrong With Application Software? Businesses Really Are Unique—One Size Can Never Fit.

  4. Procesos del negocio, no límites de las aplicaciones. La siguiente generación de arquitectura de las aplicaciones debe tratar el hecho de que los procesos del negocio cruzan las fronteras de las aplicaciones. Es necesario habilitar los procesos del negocio a través de las fronteras artificiales de las aplicaciones dispares que deben trabajar en conjunto para dar soporte a los procesos del negocio. La arquitectura deberá ofrecer una integración de los procesos del negocio y de las aplicaciones y una extensión de estas últimas para dar a las empresas todo el potencial de sus aplicaciones actuales. Con todas estas capacidades, las arquitecturas nuevas se usarán inicialmente para juntar varias aplicaciones y crear una aplicación compuesta efectiva. Eventualmente, la siguiente generación de aplicaciones empresariales también aceptará estas capacidades arquitecturales en la aplicación misma. Si desea obtener mayor información, consulte What’s Wrong With Application Software? Business Processes Cross Application Boundaries.

Parece que muchos vendedores de la comunidad de aplicaciones empresariales reconocen que es necesario cubrir estas necesidades y están tratando de ofrecer soluciones. Asimismo, desde hace algún tiempo, empresas como Microsoft e IBM están diciendo a sus clientes que en poco tiempo, si no es que ya ha sucedido, podrán construir aplicaciones integradas con funcionalidades cruzadas sin tener que invertir en paquetes importantes de sistemas nuevos. Al usar los servicios web y los componentes tanto existentes como nuevos, al igual que la tecnología y los servicios nuevos de estos vendedores, se supone que las empresas tendrán toda la flexibilidad que requieran.

Esta es la primera de tres partes que conforman esta nota.

La segunda parte hablará de SOA como la base para un escritorio universal para todas las aplicaciones web de una empresa.

La tercera parte explorará el futuro.

El paso rápido del desarrollo de software

El mundo del software se está convirtiendo en un lugar donde las aplicaciones poderosas nuevas que tienen todas las funciones de las series de software que subyacen en los negocios necesitan para ser construidas en días o semanas. El control está en manos de los hombres de negocios y no en los programadores o el personal técnico territorial, y con frecuencia se combinan las funciones de muchas aplicaciones distintas. Para construir una aplicación compleja y de funcionalidades cruzadas de acuerdo al software dispar de planificación de los recursos de la empresa (ERP), los usuarios querrán usar únicamente las herramienta intuitivas que hacen frente a los clientes o los usuarios finales, como los portales, las herramientas analíticas o de business intelligence, los navegadores web, la integración de formularios, Microsoft Exchange, Microsoft Excel u otras herramientas de búsqueda. No usarán mucho las rutinas, los lenguajes o las interfaces patentados y complicados, que tradicionalmente han formado parte de las aplicaciones empresariales actuales. Casi ninguna aplicación empresarial permanecerá completamente dentro de Microsoft Office o un producto ERP en particular. Es muy probable que cualquier aplicación que se construya en el futuro deba tocar muchas aplicaciones dispares pero necesarias.

Por consiguiente, casi toda la industria del software habla de conceptos como arquitectura orientada al servicio (SOA), también conocida como arquitectura de servicios empresariales (ESA) en el lenguaje de SAP. También se habla de aplicaciones cruzadas o compuestas (o SAP xApps, nuevamente terminología de SAP) y gestión de los procesos del negocio (BPM). Todos estos conceptos deben dar a los usuarios mayor poder sobre su software y los procesos de sus negocios. Consulte Understanding SOA, Web Services, BPM, BPEL, and More.

El paso a SOA es uno de varios elementos que permitirán que las aplicaciones empresariales manejen y hasta aceleren el cambio en los negocios. Por un lado, casi todos los participantes tecnológicos importantes se han reunido por primera vez gracias a un acuerdo sobre las normas y los protocolos que habilitan las comunicaciones de los servicios web. Así, los sistemas basados en tecnología Microsoft, Sun o IBM tienen ahora la infraestructura necesaria para funcionar entre ellos. Podemos usar como analogía una línea de teléfono confiable que se ha establecido y que permite realizar llamadas entre las plataformas usando marcado directo, aunque los usuarios deberán ponerse de acuerdo sobre el idioma que usarán para conversar.

En segundo lugar, y no menos importante, es el detalle que buscan los servicios web. El modelo general es un enfoque centrado en los documentos, no el nivel menor de detalle que propusieron los modelos de componentes anteriores y menos exitosos, como arquitectura de corredor de solicitudes de objetos comunes (CORBA) y el modelo de objetos comunes (COM). El nivel de detalle es esencial para que la comunicación entre sistemas dispares sea práctica. Si se piensa en sistemas que intercambian documentos del mismo modo que los hombres de negocios intercambian la copia amarilla de un formulario de pedido, se puede crear un modelo que se construya y mantenga de forma eficiente. Los servicios web se adaptan bien a este modelo.

Aunque no resulta práctico poner atención a cada estrategia y al matiz que aporta cada vendedor, Oracle y SAP parecen estar a punto de estrellarse con sus hazañas respectivas, Fusion (una pila de middleware que acaba de cambiar de marca) y ESA. Es posible que Microsoft Business Solutions (MBS) vaya por la misma ruta, aunque su código equivalente, llamado Project Green, que busca la convergencia de todos los productos ERP dispares de MBS en un solo código, parezca haber sido contraproducente hasta ahora. Esto se debe, en parte, a los retrasos en la terminación de Longhorn, el ambiente de sistema operativo padre de la siguiente generación de Microsoft. Es más, ha sido redirigido de un esfuerzo enfocado en entregar una base de código unificada para enfocarse en el proceso, el cambio y la orientación de los servicios.

El ecosistema de Microsoft .NET en el extremo inferior del mercado

Para dar a los clientes la flexibilidad que había prometido Microsoft .NET basado en servicios web y en lenguaje extensible d marcas (XML), muchos vendedores pequeños como Intuitive Manufacturing Systems, Epicor Software, Made2Manage Systems y SYSPRO están convirtiendo las funcionalidades existentes en sus series ERP a servicios web. Es posible ligarlas con otras aplicaciones para crear procesos nuevos del negocio con relativa facilidad. Estos vendedores difieren únicamente con respecto a ofrecer soluciones desde cero, o de forma más cuidadosa (para mayor información, consulte Rewrite or Wrap-Around Old Software?).

Es interesante ver cómo MBS está adoptando un enfoque deliberado cuando se trata de pasar sus propias aplicaciones al marco .NET. Hasta ahora, tiene un producto Microsoft CRM (gestión de las relaciones con los clientes) nuevo, desarrollado completamente en .NET. En cuanto a las soluciones ERP y de contabilidad, como Great Plains, Navision, Solomon y Axapta, el enfoque es en la capacidad que tiene .NET (con el soporte de los servicios web) para ofrecer un ambiente unificado a los socios que desarrollan extensiones de los productos. Asimismo, durante una conferencia de socios de los clientes de MBS que tuvo lugar recientemente, MBS anunció que la conmoción causada por Project Green permitirá que los usuarios utilicen las herramientas .NET y sus lenguajes para construir extensiones para las interfaces web de ERP. Del mismo modo, pensando en las interfaces con los servicios web, los socios de MBS podrán construir estas extensiones de forma que proporcionen una portabilidad más simple para las próximas versiones. El segundo Green mudará la lógica principal de la aplicación ERP y todas las herramientas a .NET. Por el momento, MBS está usando la tecnología .NET de forma indirecta. Está exponiendo las aplicaciones actuales mediante XML y servicios web para permitir que los socios de los clientes y los vendedores independientes de software (ISV) integren sus aplicaciones actuales con .NET. Esta estrategia permite impulsar el middleware y las herramientas de integración construidos en tecnología .NET, como el Microsoft SharePoint Portal Server y Microsoft BizTalk Integration Server.

Sin embargo, hay algo cierto con todos estos desarrollos: todos los vendedores principales e importantes están convencidos de que es importante terminar rápidamente la transición de arquitecturas cliente/servidor grandes y monolíticas a SOA. Para los “pocos grandes” (grandes vendedores que tienen una base de clientes importante), también es importante intensificar la carrera por las “pilas”, como aplicaciones, bases de datos, servidor de aplicaciones y middleware. Después de ver el impulso que recibió el equipo de investigación y desarrollo de Oracle gracias a la adquisición de PeopleSoft, parece que SAP piensa agregar otros 1,000 desarrolladores en 2005. El programa exige que el plan ESA de SAP quede terminado en 2007 y que ofrezca toda la serie de productos y todos los productos específicos para la industria en una de las próximas versiones de SAP NetWeaver que dará soporte a BPM y la orquestación. El gran proyecto ESA de SAP pondrá al descubierto las funciones y los datos subyacentes desde el interior profundo de su serie de aplicaciones ERP mySAP Business Suite (mySAP CRM, mySAP PLM, mySAP SRM, mySAP SCM, mySAP ERP, etc.). Hará que estén disponibles como servicios (componentes del software) que pueden ser conectados entre ellos y con los servicios de otras aplicaciones.

Durante los próximos tres años, SAP también se encargará de romper su tan amplia colección de funcionalidades de las aplicaciones para convertirla en una cartera manejable de componentes del proceso que pueden ser configurados. Los desarrolladores, los clientes y los socios comerciales de SAP podrán usar SAP NetWeaver para crear procesos a la medida de una necesidad específica, integrarlos a un ambiente existente u ofrecer una propuesta de valor que marque la diferencia. De esta forma, los clientes y los socios podrán construir aplicaciones nuevas y compuestas, además de que podrán encontrar formas para trabajar con las aplicaciones existentes.

La infraestructura tecnológica y las funcionalidades de las aplicaciones

El campo de batalla principal será la “apliestructura”, que, como su nombre sugiere, es una combinación de infraestructura tecnológica y funcionalidades de las aplicaciones. En el caso de SAP, está definida actualmente por SAP NetWeaver y mySAP Business Suite. Próximamente estará definida por una oferta de servicios web por componentes y controlada por un depósito de procesos que descanse encima de un SAP NetWeaver mejorado. Por lo tanto, NetWeaver dejará de ser una simple plataforma técnica de integración de las aplicaciones para convertirse en una plataforma de integración de procesos orientados al negocio, conocida como plataforma de composición o plataforma de los procesos del negocio (BPP).

En otras palabras, SAP sigue haciendo de SAP NetWeaver un BPP que eventualmente proporcionará un conjunto de servicios empresariales listos para ser utilizados y que será una infraestructura capaz de desplegar y administrar los servicios empresariales para crear aplicaciones compuestas. Esta visión, que se revelará durante los próximos años, estará definida por los ambientes SOA y de modelos de los procesos, que, a su vez, definirán el futuro del software empresarial. El objetivo es crear procesos reutilizables en el nivel de las aplicaciones que se podrán combinar con la plataforma (se espera que sea SAP NetWeaver). Esto, aunado a la idea de dominar la integración de datos y de procesos para dar soporte a las estrategias del negocio innovadoras y ágiles.

A pesar de que SAP es considerado un gigante aburrido, su visión de dividir la serie de aplicaciones empresariales en una cartera de componentes del proceso que pueden configurarse ha sido una parte esencial de su estrategia durante muchos años. El trabajo en esta renovación radical empezó en 2002. La estrategia ha sido convertir mySAP Business Suite en una aplicación SOA en los próximos cinco años. La hazaña está controlada por el hub de integración, SAP NetWeaver, antes conocido como mySAP Technology. De hecho, SAP NetWeaver es la evolución de mySAP Technology con mejoras modulares importantes, como gestión de los datos maestros (MDM) o gestión del conocimiento (KM), siempre con normas abiertas. El paso siguiente es hacer que las soluciones del negocio que están habilitadas por SOA están basadas en SOA. Esto implica un cambio de integración en el nivel de los datos a un nivel de mensajes, que se complica más cuando la arquitectura debe incluir clientes, proveedores, socios de canal de distribución y otros socios comerciales.

Asimismo, es poco conocido que el “mal necesario” de abrir la serie empresarial de SAP ha existido por casi una década, de una forma u otra. Concretamente, Hasso Plattner, el antiguo presidente y director general y visionario técnico del SAP actual, anunció frente a un público sorprendido y poco convencido en la conferencia de usuarios de 1995 que el SAP R/3 monolítico se abriría y dividiría en piezas más pequeñas. SAP hizo posible que las piezas de la serie monolítica funcionaran de forma independiente, aunque las interfaces siguen siendo patentadas, y que la unión entre los programas fuera fuerte y en un nivel bajo.

Más adelante, con el auge de la colaboración business-to-business (B2B) de principios de 2000, SAP se inspiró para abrir aún más sus aplicaciones. Su serie de productos, entonces conocida temporalmente como mySAP.com, permitía que aplicaciones que no eran de SAP, como herramientas de productividad del escritorio de Microsoft o mercados por Internet, se incorporaran estrechamente en la experiencia del usuario como si fueran parte de mySAP.com. Sin embargo, esto implicaba tener enlaces de código esencial y funciones en cada sistema participante.

Para contextualizar, debemos recordar que una interfaz del programa de aplicaciones (API) es un conjunto de rutinas, protocolos y herramientas para construir aplicaciones de software. Una API bien diseñada facilita el desarrollo de un programa, ya que proporciona todos los elementos de base que un programador debe ser capaz de reunir. La mayoría de los ambientes operativos ofrecen una API para que los programadores puedan escribir aplicaciones que se conformen al ambiente operativo. Aunque las API están diseñadas para los programadores, también son buenos para los usuarios, ya que garantizan que todos los programas que usen una API común tendrán interfaces similares, lo que facilita que los usuarios conozcan los programas nuevos.

La adquisición que hizo SAP en 2001 de TopTier, una empresa estadounidense/israelí de software para portales, dio a SAP un parte clave de su hub de integración y organización en componentes. También trajo a Shai Agassi, un miembro del consejo ejecutivo actual de SAP que generalmente es percibido como uno de los nuevos visionarios técnicos de SAP (consulte SAP Acquires Top Tier to Further Broaden Its Horizons). ESA, un indicador del compromiso que tiene SAP con SAP NetWeaver, y BPP entraron hace poco en la reorganización de toda la empresa, cuando Agassi, que había estado dirigiendo el desarrollo de SAP NetWeaver, empezó a ocuparse del desarrollo y la mercadotecnia de productos para todas las aplicaciones del negocio de SAP.

Servicios web

Pero de mayor o igual importancia fue la emergencia de normas de Internet ampliamente aceptadas, como XML, servicios web, .NET o servicios de mensajería Java (JMS). Así, las normas emergentes de tecnología de servicios web deben generar una mayor conciencia acerca del concepto de aplicaciones por componentes y acelerar su hasta ahora lenta adopción. La forma en que los grandes vendedores patrocinan la tecnología de los servicios web también debe ayudarlos a compensar por su latencia en el patrocinio de la tecnología de componentes hace algunos años.

Como se mencionó, los servicios web tienen el potencial para convertirse en la última evolución de la tecnología de integración de las aplicaciones o hasta en un modelo revolucionario de diseño de aplicaciones nuevas. Puede permitir que los desarrolladores creen o mejoren las aplicaciones conectando componentes detallados a los cuales se accede mediante protocolos web independientes de las plataformas. Aunque los desarrolladores impulsan el concepto ya establecido de la capacidad de reutilización de los objetos, es posibles que finalmente ofrezcan más al apegarse a las normas que están surgiendo –el soporte de las normas se percibe como la diferencia clave entre la arquitectura CORBA, cuya adopción fue menos exitosa, y los servicios web, que son más prometedores. CORBA fue desarrollado por un consorcio industrial conocido como el Object Management Group (OMG), y permite que la piezas de los programas, llamadas objetos, se comuniquen entre sí sin importar el lenguaje de programación en hayan sido escritos o el sistema operativo en que funcionen. Sin embargo, los servicios web pueden adaptarse prácticamente a cualquier tipo de funcionalidad existente en el negocio. Asimismo, los servicios web tienden a ser más simples, en parte gracias a las normas de Internet y porque también tienden a tener un nivel de abstracción mayor, lo que implica una mayor probabilidad de independencia de la plataforma y oportunidades para que los desarrolladores la combinen.

De este modo, la estrategia ayudará a empresas como SAP y Oracle a abrirse más o a dividir sus productos en componentes, ya que las normas como XML y el lenguaje extensible de hojas de estilo (XSL) permiten compartir datos y mantener una apariencia uniforme en una aplicación, sin tener que modificar el código fuente.

Con esto termina la primera de tres partes que conforman esta nota.

La segunda parte hablará de SOA como la base para un escritorio universal para todas las aplicaciones web de una empresa.

La tercera parte explorará el futuro.

Acerca de los autores

Olin Thompson es director de Process ERP Partners. Cuenta con más de 25 años de experiencia como ejecutivo en la industria de software. Se le conoce como “el padre del ERP de procesos” y escribe y da conferencias sobre temas de obtención de valor a partir de ERP, SCP, e-commerce y el impacto de la tecnología en la industria. Se le puede encontrar en Olin@ProcessERP.com

Predrag Jakovljevic es director de investigación de TechnologyEvaluation.com (TEC) y se enfoca en el mercado de aplicaciones empresariales. Cuenta con cerca de 20 años de experiencia en la industria de la fabricación, incluyendo varios años como usuario privilegiado de TI/ERP. También ha trabajado como consultor/implementador y analista del mercado. Tiene un título en ingeniería mecánica de la Universidad de Belgrado, en Yugoslavia y la certificación en gestión de la producción y el inventario (CIRM) de APICS.

 
comments powered by Disqus

Búsquedas recientes:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others