El CPD del futuro

En la mayoría de las corporaciones, el centro de datos de empresa contiene una variedad compleja de hardware y software ( por ejemplo, múltiples variantes de Unix de alto nivel, OS/390 y otros sistemas operativos propietarios ) , lo cual requiere diferentes infraestructuras de soporte y ofrece poco valor en cuanto a integración . Como esto resulta inaceptable para el cliente, los departamentos de Tecnologías de la Información de las empresas y los vendedores están trabajando para unificar estas tecnologías mediante “middleware” de integración, migración a plataformas de arquitectura comunes y la inclusión de múltiples “personalidades” en una misma máquina .

Si se consideran estas tecnologías como internas o “back office”, y las tecnologías de proceso en red más recientes se consideran como externas o “front office”, el desafío para las organizaciones de TI ( y para los vendedores ) está en unir sin fisuras ambas capacidades suministrando un conjunto de sistemas y procedimientos medios o “middle office” que permita unir juntos los otros dos . Al ser relegadas más tareas back-office ( y algunas front-office ) a proveedores externos ( por ejemplo, proveedores de outsourcing ) , la mayoría de las grandes compañías mundiales están desarrollando una mezcla de suministro de servicios internos y externos . El ámbito de responsabilidad incluye las necesidades de los clientes, los proveedores externos, las conexiones de correo electrónico y los procesos que resulten más económicos bajo el entorno actual . El desafío queda acentuado por la aparición de nuevas iniciativas, como los almacenes de datos, proceso en red, inteligencia comercial, comercio electrónico y “Webificación” de aplicaciones comerciales . En el camino, deben resolverse también cuestiones correctoras como el cumplimiento del año 2000 y la conversión al Euro ( que están consumiendo hasta un 30% de los recursos y presupuestos informáticos ) . Para alcanzar estos objetivos, los departamentos de TI deben priorizar los elementos que garanticen que sea posible cumplir con los requerimientos cambiantes de los clientes, así como identificar criterios para seleccionar vendedores estratégicos a fin de compartir la carga que supone alcanzar esos objetivos .

Aunque es el departamento informático el que tiene la responsabilidad final por la satisfacción del cliente, también los vendedores desempeñan un papel clave . La organización de TI debe adoptar ahora decisiones difíciles sobre qué vendedores ayudarán a energizar su futuro centro de datos de empresa .

Integración

La integración es el factor de éxito más crítico para el centro de datos . Esta cuestión es equivalente a la de los estándares; los componentes middleware que permiten la integración sólo son efectivos si penetran y se difunden en todas las áreas y niveles . Las iniciativas de determinados vendedores para extender y ampliar el middleware “estándar” convierten con frecuencia a estos productos en no-estándar .

Para unir estas tecnologías de integración diversas se requerirán por parte de los vendedores iniciativas clave y decisivas, basadas en fuertes alianzas . Estas tecnologías incluyen arquitecturas basadas en plataformas ( por ejemplo, NUMA ( Non Uniform Memory Access ) , S/390 Parallel Sysplex, arquitecturas de almacenamiento de datos, y middleware como ORBs, SQL, gateways, monitores de transacciones distribuidas y sistemas de mensajes . Para los años 2000/2001, el Meta Group considera que el S/390 ( con Parallel Sysplex ) y NUMA ( con Intel ) penetrarán en la mayoría de las plataformas de empresa ( Hewlett-Packard, Sun e IBM tendrán plataformas basadas en NUMA en ese periodo ) como medio de unir pequeños grupos de procesadores formando clusters de procesadores más grandes . NUMA ofrece la ventaja de la tecnología de multiproceso simétrico ( SMP ) , con escalabilidad teórica para proceso masivamente paralelo ( MPP ) .

Aunque la capacidad de clustering SMP está limitada generalmente a 16-32 procesadores, los servidores NUMA pronto manejarán hasta 252 procesadores . Las ventajas de NUMA permiten una mayor disponibilidad, un costo menor y la posibilidad de consolidar cargas de trabajo en menos servidores, minimizando así el esfuerzo de gestión adicional y ofreciendo economías de escala .

Las arquitecturas de datos/almacenamiento son necesarias para ofrecer un acceso común a los datos ( independientemente de cuál sea la plataforma, estructura de datos, etc . ) y son también un medio común de ofrecer backup/recovery, archivo, HSM e interfuncionalidad base de datos/almacén de datos . Mientras que vendedores como EMC ( en asociación con vendedores de bases de datos y plataformas ) liderarán la marcha hacia el suministro de tecnologías con la capacidad necesaria, el departamento de TI deberá adoptar las herramientas de soporte apropiadas y desarrollar sistemas y procedimientos que garanticen la máxima disponibilidad, servicio ( velocidad de acceso ) e integridad de los datos . El objetivo es crear una jerarquía de almacenamiento integrado que ofrezca compensaciones entre el coste y el servicio .

En el área de la seguridad, el objetivo de DCE consistía en ofrecer integración para autentificación de usuarios de red mediante Kerberos, encriptación DES y conexión única ( sign on ) a base de datos . Sin embargo, durante este año Netscape y Microsoft habrán introducido en sus mercados mecanismos de encriptación y autentificación razonablemente efectivos ( mediante un sucesor al Secure Sockets Layer ) . Para 1999, esas tecnologías ( basadas en RSA y X . 509 ) y LDAP ofrecerán capacidades de directorio a nivel de empresa . Y para el 2001, este conjunto tecnológico, en una forma conocida como Public Key Infrastructure ( PKI ) , posiblemente suplantará a DCE para la autentificación y, para el 2003, también para la autorización .

En el contexto de las ORBs, la clave está en la arquitectura CORBA ( Common Object Request Broker ) . La falta de interfuncionalidad ha limitado la utilidad de CORBA como estándar para distribuir objetos ( es decir, su capacidad de actuar como un “policía de tráfico” para objetos ) , pero implementaciones como Universal Networked Objects han servido de ayuda en este sentido . Los desarrolladores que crean software a medida para distribución a múltiples plataformas en grandes instalaciones de proceso corporativas están comenzando a considerar seriamente la arquitectura CORBA . OLE/DCOM será también una posibilidad importante a considerar, como consecuencia del empuje continuado de Microsoft .

Los interfaces/middleware SQL son una cuestión difícil para muchos usuarios . La mayoría de las implementaciones cliente/servidor utilizan los productos del vendedor de la base de datos ( por ejemplo, Oracle SQL*Net, Sybase OpenClient ) . SQL continuará siendo un importante estándar middleware, suministrando los vendedores de sistemas SGBDR la mayor parte de la tecnología . Aunque una mayor interfuncionalidad seguirá siendo un objetivo, obstáculos políticos y técnicos continuarán impidiendo que haya un producto middleware SQL universal . Y, como las arquitecturas tecnológicas que están determinadas por los datos incluyen fuentes de datos y requerimientos de rendimiento más diversos ( incluyendo bases de datos ya existentes ) , los usuarios tendrán que moverse más allá del middleware SQL .

En lo relativo a interfaces y gateways SQL de terceros, los productos ODBC de Microsoft, EDA/SQL de Information Builders, SQL*Connect de Oracle y OmniSQL de Sybase ofrecen independencia de base de datos para aplicaciones con requerimientos de rendimiento limitados . La mejor forma de utilizar esta tecnología es para permitir el acceso de cliente a almacenes de datos ( es decir, que la mayoría de las herramientas DSS soportan ODBC o Windows ) , o para s