¿El fin de las aplicaciones empresariales que no se comprometen con una sola base de datos?

La forma en que muchos proveedores de software ofrecen arquitectura orientada a los servicios (SOA) ha hecho que cambie el enfoque en la arquitectura de las aplicaciones. Si bien es cierto que es mejor separar una aplicación en capas, la cuestión sigue siendo si la aplicación debe estar bien integrada con la base de datos. Según el enfoque tradicional, que no se compromete con una sola base de datos, los usuarios pueden seleccionar una aplicación y una base de datos de forma independiente. En un principio, este enfoque puede parecer bueno, pero a la larga sacrifica el desempeño y la flexibilidad del sistema.

Esto se debe a que para poder soportar varias bases de datos, el proveedor de software debe seleccionar el conjunto de funciones de una base de datos que tenga el común denominador más bajo, para que lo use la aplicación. Muchas veces esto produce un diseño, una experiencia para los usuarios y un desempeño del sistema que están por debajo de los niveles óptimos. Al enfocarse en una base de datos en particular, los desarrolladores pueden aprovechar al máximo sus funciones. Así, la aplicación puede ofrecer capacidades adicionales que no se pueden obtener usando una aplicación que no se compromete con una base de datos en particular, y esto se traduce en una funcionalidad más completa. Una estrecha integración entre la aplicación y la base de datos también reduce los costos de gestión de bases de datos, ya que la misma aplicación puede automatizar estas tareas constantes de gestión, eliminando con ello gran parte del trabajo que debe realizar un administrador de bases de datos.

En este artículo se habla de las aplicaciones que están estrechamente integradas con la plataforma de la base de datos con que funcionan. Este método para desarrollar la aplicación aumenta la funcionalidad, mejora el desempeño del sistema y reduce los costos tanto de desarrollo como de mantenimiento. Antes, las bases de datos eran el punto de integración donde las aplicaciones conectadas podían comunicarse entre sí. Sin embargo, en nuestros días, este mismo punto de integración es la capa de middleware. Las empresas están invirtiendo más en adquirir middleware y las competencias para manejarlo, y no en tecnología y experiencia con bases de datos. Para aumentar la eficiencia de los costos, están seleccionando ellas mismas una sola capa de middleware que usan con todas sus aplicaciones, en lugar de aceptar lo que les indican sus proveedores de aplicaciones. Dicho de otro modo, están dejando las aplicaciones que no se comprometen con una sola base de datos, para acercarse a las soluciones que no se comprometen con un solo middleware.

Mucho más que almacenamiento

El día de hoy, las aplicaciones de bases de datos son más que un dispositivo para almacenar y buscar información, ya que incluyen funciones importantes de consultas de información y gestión de datos. Los proveedores de aplicaciones empresariales trabajan arduamente para agregar funciones de búsqueda tipo Google, pero será más fácil que las empresas de desarrollo que dependen de las funciones de creación de índices y consultas de texto que tienen sus bases de datos subyacentes, logren colocar esta funcionalidad en el mercado. Sin embargo, hay que desarrollar una y otra vez las aplicaciones que no se comprometen con una sola base de datos para que se puedan ajustar a las distintas bases de datos. Esto representa tanto un costo adicional que los clientes deben absorber en forma de mayores tarifas por licencias, como más trabajo y dinero que deben pagar los proveedores para actualizar estas aplicaciones.

Es más, operar estas capacidades de búsqueda representa mucho trabajo para la base de datos. Si usted puede confiar en que su base de datos llevará a cabo estas funciones, evitará presionar a los recursos del sistema que deben sacar esta información de la base de datos para llevar a cabo la búsqueda. Del mismo modo, los medios interactivos, como el video y el audio, se pueden manejar con mucha mayor facilidad cuando se puede acceder a ellos desde el interior de la base de datos, sin tener que sacar un archivo enorme de la tabla en que reside.

Además de la búsqueda empresarial, las aplicaciones que trabajan con una base de datos en particular pueden proporcionar con más facilidad funciones de business intelligence (BI) y data-mining. Es posible crear herramientas de BI, como cubos de procesamiento analítico en línea (OLAP) directamente en la aplicación en el nivel de la base de datos -donde debe residir este tipo de funcionalidad, lo más cerca de los datos.

Las aplicaciones que no se comprometen con una sola base de datos necesitan herramientas y procesos de gestión para la capa de la base de datos, distintos a los que se necesitan para la capa de la aplicación. Una aplicación que usa una base de datos específica puede reducir los costos, ya que unifica el conjunto de herramientas y el tiempo de gestión para ambas capas, reduciendo o eliminando con ello la necesidad de usar los servicios de un administrador de bases de datos y recortar los costos de gestión de la aplicación.

Asimismo, una aplicación que no se compromete con una sola base de datos tiene características de desempeño distintas que dependen de la base de datos en la que funciona la instancia de la aplicación. Si bien existen otras partes del sistema, como el sistema operativo y el hardware, que pueden variar sin afectar mucho el desempeño de la aplicación, no sucede lo mismo cuando la aplicación funciona en bases de datos diferentes. Puede ser que las consultas que se realizan rápidamente en una base de datos Oracle tarden mucho en SQL Server de Microsoft o DB2 de IBM, o viceversa, dependiendo de cómo se optimice la aplicación.

La nueva tecnología resuelve los problemas

Uno de los argumentos en favor del diseño de aplicaciones que no se comprometen con una sola base de datos era la diferencia que se percibe entre el nivel de habilidad y el esfuerzo necesarios para manejar diferentes plataformas para bases de datos. A lo largo de la historia, SQL Server se ha caracterizado por por ser relativamente simple y fácil de usar, pero mucha gente creía que para usar Oracle necesitaba un administrador de bases de datos que conociera mucho sobre herramientas y metodología.

Sin embargo, recientemente se ha descubierto que sucede exactamente lo contrario. En marzo del 2006, Edison Group, Inc. publicó un estudio en el que revela que administrar las bases de datos de Oracle consume menos tiempo y dinero que administrar las bases de datos actuales de lenguaje de consulta estructurado (SQL). El estudio, titulado Comparative Management Study of Oracle Database 10g Release 2 and Microsoft SQL Server 2005 (visite www.theedison.com), llega a las conclusiones siguientes:

• los administradores de bases de datos pueden llevar a cabo funciones administrativas típicas con una rapidez 38 por ciento superior al usar Oracle Database 10g Release 2, que al usar Microsoft SQL Server 2005.
• Oracle Database 10g Release 2 requiere 30 por ciento menos pasos que Microsoft SQL Server 2005 para realizar el mismo grupo de tareas administrativas estándar para un sistema de gestión de bases de datos relacionales (RCBMS), de acuerdo a la métrica de evaluación de la complejidad que fijó Edison Group.
• Al aprovechar el aumento en la productividad del administrador de bases de datos, las empresas pueden ahorrar hasta 31,664 dólares (USD) por cada administrador de bases de datos si usan Oracle Database 10g Release 2 en lugar de Microsoft SQL Server 2005.

Aún sin tomar en cuenta estos hechos, muchos usuarios de aplicaciones que funcionan en bases de datos Oracle no tienen administrador de bases de datos. Las herramientas de automatización que contiene la base de datos han “igualado las circunstancias” en cuanto a costos y actividades de mantenimiento. Es cierto que hay que dar algo de mantenimiento a todas las bases de datos, y todos los tipos de mantenimiento -como el mantenimiento y el trabajo necesarios para prepararse para un restablecimiento de las funciones en caso de que falle el sistema- son similares, no obstante el proveedor de la base de datos. El día de hoy, cualquier persona que tenga el conocimiento y las habilidades para administrar una base de datos SQL puede hacer lo mismo con una base de datos Oracle. Es como cuando cambia de marca de automóvil; cuando tiene que encender las luces del auto, puede hacerlo si sabe dónde está el interruptor.

Pero al integrar la aplicación con la base de datos, es posible diseñar la aplicación de manera que pueda realizar por sí misma gran parte del mantenimiento de rutina de la base de datos. Eso es simple cuando la aplicación está diseñada para comprender las características del desempeño y los requisitos de mantenimiento de la base de datos, pero es más difícil y costoso cuando la aplicación debe soportar varias bases de datos.

Hay un argumento en contra de las aplicaciones empresariales que funcionan con una base de datos en particular, y es el miedo a sobrecargar la base de datos y a generar con ello un cuello de botella en el sistema. Gracias a tecnologías como Oracle Grid Computing y Oracle Real Application Clusters, se ha podido eliminar esta preocupación. Real Application Clusters permite que una aplicación comparta una sola base de datos a través de los nodos o los servidores de un cluster informático. Ahora es posible operar una aplicación empresarial poderosa que está integrada con su base de datos subyacente, en un ambiente que se puede graduar de forma infinita -sin sufrir problemas de desempeño o requerir hardware costoso para el servidor.

Enfoque en el nivel medio

A finales de la década de los noventa -más o menos cuando Microsoft compró SQL Server-, muchos clientes de software empresarial estaban interesados en aplicaciones que no se comprometían tanto con una sola base de datos y que podían, por lo tanto, soportar SQL Server. Si bien en aquellos días había razones para no favorecer una base de datos en particular, ahora las cosas han cambiado.

Alrededor de esas fechas empezó a cambiar el enfoque en la forma en que interactúan las aplicaciones, de manera que la base de datos en que funciona la aplicación adquiere un poco de importancia, siempre que pueda hacer el mejor uso de su plataforma de bases de datos. El día de hoy es más importante que la aplicación sea compatible con varios productos de middleware porque esto da a los usuarios más libertad.

Hace tan sólo diez años, las aplicaciones se diseñaban para que generaran reportes directamente desde el nivel de la base de datos. También la integración con otros sistemas se hacía desde la base de datos. Si se desarrollaba un programa adicional para la aplicación, se ligaba directamente a la base de datos. La base de datos era el centro funcional de la aplicación, y la capacidad para seleccionar la base de datos afectaba la forma en que podía interactuar con otros sistemas.

Pero las cosas han cambiado. Ahora, cualquier trabajo de integración se lleva a cabo a través de los servicios web que están en el nivel medio de la aplicación, y el desarrollo de programas adicionales está ligado de forma similar a la aplicación que está en el nivel medio mediante servicios que se comunican con las interfaces de programación de las aplicaciones (API). Los reportes no se hacen contra la base de datos, sino contra esquemas de datos de lenguaje extensible de marcas (XML) en el nivel medio. En pocas palabras, el nivel medio se ha convertido en el lugar donde se encuentran todos los puntos de contacto y las interfaces de una aplicación empresarial.

Ahora los clientes dan más importancia a la selección del middleware que quieren usar, y menos a la selección de la base de datos. Es como si la base de datos se estuviera convirtiendo en una “caja negra”, es decir, que realizara sus tareas de forma discreta, con poca intervención humana. Todo lo que hace un usuario con una aplicación empresarial moderna depende del nivel medio, mientras que los elementos de la funcionalidad que están escondidos pueden, de hecho, depender de las características que se incluyen en la capa de la base de datos.

La aplicación empresarial del futuro no tendrá que ofrecer la opción de varias bases de datos, sino que dará a los usuarios el poder para seleccionar el middleware. Esto permitirá que los proveedores de aplicaciones del siglo XXI ofrezcan productos de tecnología neutra, con funcionalidades que se puedan adaptar rápidamente a los cambios tecnológicos sin tener que interrumpir toda la pila de aplicaciones. Al implementar estas aplicaciones, una empresa puede seleccionar el middleware que usará, como Oracle Fusion, SAP NetWeaver® o IBM® WebSphere® -o puede optar por una solución de software libre, como Jboss®.

Hay que notar que muchos de los principales productos de software empresarial son propiedad de empresas que también se dedican a vender middleware. Los proveedores de aplicaciones que especifican una solución de middleware -o que obligan a los usuarios a adaptar las suyas- están aumentando el costo y la complejidad de las soluciones de sus clientes. Operar un solo producto de middleware produce un ambiente de tecnología de la información (TI) más homogéneo y reduce el costo total de propiedad, ya que limita las tarifas de las licencias y los costos de capacitación. Sin embargo, actualmente, casi todas las empresas usan varios productos, como software de planificación de recursos empresariales (ERP) y gestión de las relaciones con los clientes (CRM), extranets y aplicaciones caseras. Cuando estos productos ofrecen una opción de middleware, las empresas pueden normalizar su sistema a un solo producto, pero si cada aplicación requiere un producto diferente, entonces la situación se vuelve difícil para el cliente.

Piense en una empresa que opera Oracle Financials en middleware Oracle Fusion. Si compra una solución de mantenimiento nueva ¿podrá seguir usando Oracle Fusion? Si su producto de mantenimiento no soporta Fusion ¿se verá obligada a adoptar un segundo middleware, como WebSphere, para adaptarse a su nueva solución de mantenimiento? O si una empresa que ya está usando WebSphere para manejar las integraciones con sus antiguas computadoras centrales ¿podrá seguir usando WebSphere? ¿O deberá aprender a usar una segunda plataforma cuando adquiera su nueva aplicación de negocios?

Desgraciadamente, las respuestas a estas preguntas no son lo que las empresas quieren oír.

Por ejemplo, un cliente de SAP está limitado a usar NetWeaver. Un cliente de aplicaciones empresariales de Microsoft debe usar Windows Server. Otros productos, como los de Lawson (que ahora pertenece a Infor Global Solutions), limitan a los usuarios al uso de WebSphere.

Conclusión

Hace algún tiempo, las aplicaciones empresariales que no se comprometen con una sola base de datos tuvieron ventajas marginales. Pero aún entonces, estas aplicaciones tenían desventajas tanto para los usuarios como para los proveedores. El día de hoy, la nueva tecnología ha eliminado los beneficios, y las ventajas de integrar una aplicación con la base de datos subyacente son más convincentes que nunca. Al mismo tiempo, cada vez es más importante que los proveedores de aplicaciones empresariales ofrezcan varias opciones de middleware.

Una aplicación que no se compromete con un solo middleware reduce el costo total de propiedad y la complejidad, además de que hace que los compradores de software empresarial dejen de depender de los proveedores que usan sus aplicaciones de middleware para obligar a los clientes a adoptar su software empresarial. Después de todo ¿por qué un proveedor de aplicaciones desarrollaría su propio middleware si no es para forzar a sus clientes a usar sus soluciones y acabar con la competencia?

Acerca de los autores

Rick Veague es director de tecnología de IFS North America y trabaja en sus oficinas de Schaumburg, Illinois. Se encarga de dirigir la forma en que IFS usa la arquitectura orientada a los servicios (SOA) y trabaja con los principales clientes de la empresa para provechar la SOA para obtener gestión de los activos empresariales (EAM) y planificación de los recursos empresariales (ERP) de primera calidad. Se le puede contactar en Rick.Veague@ifsna.com.

Dan Matthews es director de tecnología del departamento de investigación y desarrollo de IFS y es responsable del plan estratégico y de desarrollo de la arquitectura, las herramientas de desarrollo y la plataforma tecnológica que se usa en IFS Applications. Se unió a IFS en 1996, después de trabajar como consultor independiente de software. Se le puede contactar en dan.matthews@ifsworld.com.