La habilitación en código administrado Microsoft .NET: ejemplos y retos

Ejemplos de Microsoft .NET

Desarrollar e implementar una arquitectura de tecnología de la información (TI) conectada a servicios Web no es una tarea fácil. Para ello, Microsoft .NET Framework ofrece justo lo que un negocio necesita: smart clients, servidores para alojar los servicios Web, las herramientas de desarrollo y las aplicaciones para crearlos y usarlos y una red global de más de 35,000 empresas certificadas como Microsoft Certified Partner que proporcionan ayuda a los usuarios.

Cuarta parte de la serie Los sutiles (y no tan sutiles) matices de la habilitación en Microsoft .NET.

Si desea consultar una explicación general de la evolución de la arquitectura de sistemas, refiérase a Evolución de la arquitectura: desde la arquitectura de los marcos principales hasta la arquitectura orientada a los servicios o de cómo el ambiente Microsoft .NET trata esta situación, refiérase a Los sutiles (o no tan sutiles) matices de la habilitación de Microsoft .NET.

Primer ejemplo: Intuitive Manufacturing Systems

El primer ejemplo de un producto administrado con .NET es Intuitive Manufacturing Systems, una empresa de Kirkland, Washington que ofrece soluciones completas de planificación de los recursos de la empresa (ERP) para pequeñas y medianas empresas que trabajan en el campo de la fabricación discreta (Intuitive Manufacturing Systems Shows Maturity in Adolescent Age). Hace poco fue adquirida por Made2Manage Systems, el hambriento (como lo ha demostrado últimamente) proveedor del mid-market (consulte Made2Manage Systems un año más tarde, reactivado y creciendo). La destreza tecnológica en .NET que caracteriza a Intuitive ha sido considerada uno de los principales atractivos debido a que la mayoría de las líneas de productos ERP de Made2Manage estaban (en el mejor de los casos) en ese momento entre la compatibilidad y la habilitación en .NET.

Intuitive anunció recientemente el tan importante lanzamiento de Intuitive ERP 8.0, que representa el fin de una reescritura importante de la funcionalidad de Intuitive ERP usando código administrado .NET que se inició hace algunos años. En esta versión, todos los procesos principales de manufactura se han convertido a la nueva arquitectura, además de que varias áreas de la funcionalidad nueva se ofrecen ahora en Intuitive ERP 8.0, como los nuevos procesos de orden de cambio de ingeniería (ECO) que soportan la introducción de productos nuevos (NPI) y las solicitudes de cambio de ingeniería (ECN) que permiten agilizar la introducción de los productos en el mercado.

También tiene herramientas aprobadas para los proveedores que se diseñaron específicamente para la industria de manufactura por contrato -que está en crecimiento- y que reemplazan las hojas de cálculo que son tan comunes pero ineficaces y propensas a los errores. Finalmente y con el propósito de soportar la cadena de suministro controlada por la demanda, planear los requerimientos de material y capacidad toma ahora sólo unos minutos, lo que permite realizar una planificación por demanda. La versión 8.0 se puso a disponibilidad de los clientes nuevos en mayo de 2006, y los clientes existentes podrán obtener la Versión 8.1 (programada para finales de 2006), una vez que las herramientas de migración estén disponibles.

Hay que notar que los servicios Web se crean naturalmente como subproducto del software administrado con .NET, aunque también se crean naturalmente como subproducto del soporte .NET de Progress OpenEdge en, por ejemplo, Epicor Vantage (que no se a reescrito totalmente en código administrado .NET puro). Para ello, Intuitive organizó la lógica del negocio en componentes u objetos .NET detallados, con lo cual todas las transacciones se dan en lenguaje extensible de marcas (XML). Por una parte, esto significa que un servicio Web en Intuitive no funciona como en otras partes:muchos otros vendedores del mid-market han decidido agregar aplicaciones wrapper a las aplicaciones legadas completas (como gestión de los recursos de los clientes [CRM] o compras) y promueven la capacidad que tienen dichas aplicaciones para funcionar en una columna vertebral de ERP como aplicación compuesta o arquitectura orientada al servicio (SOA). Algunas encuestas de investigación del mercado demuestran que aunque esto puede resultar conveniente para los ambientes complejos y de nivel uno, los fabricantes que se enfocan en el mid-market y que tienen plataformas de software más homogéneas no lo aceptarán tan fácilmente. Por eso, Intuitive se ha esforzado por dividir sus aplicaciones en partes con funciones que tengan más sentido para los negocios.

De hecho, si no se usan, los servicios Web no son más que una tecnología “estupenda”. Un ejemplo real de una aplicación del negocio detallada es el servicio Web de disponible para promesa (ATP) o capacidad para promesa (CTP) de Intuitive ERP 8.0, en el que se aplica este concepto a la cadena de suministro controlada por la demanda. El uso de Microsoft Office Outlook (con el próximo lanzamiento de Microsoft Office 2007) agrega más valor al ejemplo, ya que permite que el usuario de Intuitive ERP dé a sus clientes clave acceso a los servicios Web ATP o CTP para que realicen situaciones de planificación “what-if”, dándoles una colaboración práctica con la cadena de suministro en tiempo real. Los socios de la cadena de suministro podrán tomar decisiones más rápidamente de acuerdo a las fechas de entrega y las cantidades que se encuentran en ese momento en producción o en inventario (usando ATP) y de los nuevos planes de producción (con CTP) sin tener que esperar una llamada o un correo electrónico.

Además, la fuente de una transacción mantiene su transparencia dentro del innovador Intuitive Framework. En otras palabras, ya sea que la transacción provenga de los usuarios de Intuitive ERP que la están introduciendo de forma interactiva en su computadora, o del mundo exterior (como un servicio Web), el sistema usa un solo conjunto de lógica del negocio. Con ello se debe eliminar todos los problemas que existen generalmente en otras aplicaciones, donde es necesario tener conjuntos de código duplicados para las diferentes fuentes de solicitudes y datos de las transacciones. La tecnología de los servicios Web sigue siendo relativamente joven y poco sólida para cumplir su promesa, y el hecho de que esté administrada con .NET facilita la escritura, la implementación y el consumo de los servicios Web. Desafortunadamente, muchas otras de las grandes ventajas que representa el ambiente administrado con .NET (como coherencia de un ambiente integrado) se pierden en medio de la publicidad exagerada que rodea los servicios Web y la SOA.

Segundo ejemplo: VISIBILITY.net

Visibility Corporation es otro proveedor de una aplicación ERP que aprovecha al máximo la SOA basada en .NET Framework junto con el código administrado .NET. La empresa tiene sus oficinas en Andover, Massachusetts, y desde 1980 su serie VISIBILITY ha ayudado a cerca de 150 fabricantes de productos técnicos y a otras empresas orientadas a los proyectos.. Con VISIBILITY.net, que representa su séptima generación de productos, la empresa decidió preceder el uso de aplicaciones wrapper para ofrecer una funcionalidad basada en .NET Framework. Para lograrlo, ha dedicado los últimos cuatro años a convertir completamente la aplicación principal basada en client/server para usar una arquitectura en código administrado .NET puro habilitada mediante el uso de servicios Web y formularios Active Server Page (ASP) .NET. El enfoque que usaron en este caso ha dado a los clientes un cliente zero footprint real que pueden implementar, en el que no necesitan más componentes que un navegador en la terminal del cliente.

El enfoque que se usa en la aplicación VISIBILITY.net tiene muchas ventajas, como una importante reducción en la cantidad de código necesario para ofrecer las más de 1,000 funciones distintas; un aumento de tres a cuatro veces en el desempeño de las transacciones y la capacidad de graduación relacionada y una reducción en el costo de implementación y gestión, ya que cualquier cliente que sea capaz de usar como navegador Microsoft Internet Explorer (IE) v5.5 SP2 o una versión más reciente, podrá usar la aplicación. La forma en que Visibility abstrajo el modelo de la aplicación para usar el código administrado y los servicios Web, que implementan de forma distinta la forma, la lógica del negocio y las capas de conexión de los datos, ha hecho que adquiera más capacidad para afectar la independencia de las bases de datos, mejorar el desempeño del funcionamiento y la capacidad de extensión de la aplicación en comparación con otras aplicaciones que usan una SOA bien formada.

Tercer ejemplo: Epicor for Service Enterprises

Epicor for Service Enterprises es una solución nueva de automatización de los servicios de la empresa (ESA) que representa el último ejemplo de un producto de pila sólo Microsoft que contiene código administrado .NET puro y servicios Web “agresivamente” organizados en componentes. Este producto pretende proporcionar una sola fuente para administrar y automatizar casi todas las áreas de las empresas que se enfocan en los proyectos. Está escrito completamente en código administrado .NET y en las últimas versiones de Microsoft .NET Framework 2.0, Microsoft SQL Server 2005, VS.NET 2005 y servicios Web. Para ser precisos, la última versión (8.1.1), que se lanzó al público hace apenas unas semanas, funciona en SQL Server 2005, .NET Framework 1.1 y VS.NET 2003. Actualmente está en proceso de obtener la certificación para pasar a .NET 2.0 y VS.NET 2005, y se espera que esté disponible en los próximos meses con soporte para Microsoft Project 2007, siguiendo con el compromiso que tiene Epicor de dar soporte constante a las pilas Microsoft más recientes. En cualquier caso, la escritura de esta aplicación tardó varios años (el lanzamiento inicial se realizó en junio de 2003 y actualmente cuenta con más de 70 clientes y 25,000 usuarios) y, a diferencia de sus hermanos en Epicor, está limitada únicamente a la tecnología Microsoft debido a su enfoque -aunque también tiene las ventajas de .NET que se mencionaron.

Además, el producto cuenta con el respaldo del Epicor Internet Component Environment (ICE), que es un esquema de trabajo basado en normas que se escribió con Microsoft VS.NET y que funciona encima de Microsoft .NET Framework. Ofrece un ambiente de desarrollo de aplicaciones (herramientas de personalización y extensión para ensamblar, implementar, ejecutar y mantener las aplicaciones) con una interfaz de usuario (IU) llena de funciones (aunque sea thin client) y acceso puro a la red para los clientes. Epicor ICE usa servicios Web para casi toda la lógica de la aplicación, por ello, proporciona una IU separable y altamente configurable que se puede implementar y mantener con facilidad.

Al igual que con otros componentes de Epicor ICE que abogan por la agilidad, se podría notar que la combinación de Epicor ICE y la tecnología de gestión de los procesos del negocio (BPM) permite que las empresas automaticen y simplifiquen los procesos del negocio para asegurar las mejoras continuas. Así, el ICE BPM Director funciona como una solución para el flujo de trabajo y los procesos del negocio dentro de la plataforma ICE, incluyendo soporte del esquema de trabajo en mensajería para eventos del negocio y una aplicación de organización del negocio. Tanto los desarrolladores de aplicaciones como los trabajadores de la información pueden usar BPM Director para coordinar los procesos del negocio, organizar los flujos de trabajo y automatizar la toma de decisiones (consulte Gestión de los procesos del negocio: un curso rápido y básico de lo que implica y del por qué utilizarlo).

Todos los enfoques representan un reto

Intuitive ERP, Epicor, VISIBILITY.net y Microsoft Dynamics CRM son ejemplos de los pocos productos que no son administrados por completo con .NET. Parece que las versiones futuras de las líneas de productos Microsoft Dynamics ERP se escribirán cada vez más en código administrado .NET. Todo esto puede ser un indicador del objetivo final, pero el reto principal que tiene este enfoque es que requiere una reescritura lenta de la funcionalidad. La transformación, que implica convertir o reescribir cada línea del código del software y modificar el diseño arquitectural del producto para aprovechar las ventajas que promueve .NET Framework, no será nada fácil para la base instalada de clientes. La conversión de un producto para que se base por completo en .NET Framework es un esfuerzo enorme. Por eso, ningún vendedor de software debe convertir simplemente la líneas del código de su antiguo lenguaje a uno nuevo basado en .NET Framework y luego recompilarlas usando un compilador .NET. Una conversión bien pensada debe involucrar un cambio en el diseño del producto que permita aprovechar las nuevas funciones del ambiente .NET, satisfacer los nuevos requisitos de conectividad a Internet y posicionar mejor el producto para adaptarse mejor a la tecnología avanzada que aparecerá en un futuro lejano.

De hecho, siempre y cuando el “antiguo” software satisfaga las necesidades del negocio, los cambios no dependerán de la nueva tecnología, por lo que la creación de productos de reemplazo en un esquema de trabajo nuevo representa una estrategia mucho más arriesgada. Algunos de los productos que están “habilitados únicamente en .NET” se encuentran en su enésima generación, y esto ha dado a los vendedores la oportunidad para optimizar sus códigos y resolver algunos problemas de seguridad y otros conflictos. La funcionalidad de los productos sigue siendo de gran importancia, y mientras los proveedores de aplicaciones empresariales den importancia a la implementación del “salto cuántico” más reciente en informática, no se podrá afirmar que el primero que llegue al mercado será quién tenga éxito. De hecho, la experiencia -incluyendo la reciente adquisición de Intuitive- nos dice que puede ser todo lo contrario. Hay muchos vendedores que han debido enfrentarse a la desagradable situación de tener bases de clientes que no están listos para dar el salto tecnológico. Por lo tanto, cuando tienen el peso de una base de clientes que sigue contando con productos antiguos y que soporta tecnologías que ya pueden ser obsoletas, aún los vendedores más grandes han tenido que dar marcha atrás y reconsiderar sus estrategias para descontinuar las versiones de los productos más antiguos.

Aunque el software manejado con .NET tiene las elegantes funciones de Windows XP (mientras que los pedazos de funciones basadas en COM siguen teniendo la apariencia “cuadrada” de Windows 98), se puede pensar en algunas mejoras funcionales que justificarían optar por el producto. Por supuesto que la tecnología .NET permite que los desarrolladores produzcan IU ricas y coloridas sin mayores dificultades, ya que con .NET se pueden usar los nuevos y detallados iconos de 48x48 pixeles, los gradientes de color que se degradan de un color a otro y las gráficas y tablas llenas de detalles.

Asimismo, el software basado en .NET Framework es más veloz, especialmente para acceder a las bases de datos de Microsoft SQL Server, aunque estas no parecen ser razones de peso para que los usuarios ordinarios que no se orientan a TI inicien el doloroso proceso de migración. En otras palabras, la idea de “no reparar lo que no está roto” puede ser contraproducente para Intuitive, Visibility y Microsoft si no demuestran tener una mejor propuesta de valor, como un desarrollo más rápido de una funcionalidad vertical nueva. No son muchos los usuarios que tienen el conocimiento necesario para darse cuenta de que los sistemas que han agregado código Microsoft a una tecnología central antigua tendrán que tratar con la conversión entre la capa antigua y la nueva y con los problemas de captura de datos, formateo, interfaz y desempeño, con los dilemas de compatibilidad entre las versiones y otros problemas sutiles.

Conclusión y recomendaciones

A modo de recomendación, el razonamiento del negocio siempre debe ser el factor que controle las decisiones técnicas. Cada negocio debe enfocarse en optimizar sus procesos y sus competencias principales, como reducir los costos, aumentar el nivel de satisfacción de los clientes, lograr entregas más rápidas, etc. Entonces es necesario realizar ejercicios dolorosos para determinar cuáles son los habilitadores tecnológicos. Para la gran mayoría de las empresas, las carteras futuras de activos de TI seguirán conteniendo una mezcla de aplicaciones legadas de cosecha propia y organizadas en paquetes, y no reescrituras completas. En otras palabras, probablemente muchos vendedores estén satisfechos con (por ejemplo) aprovechar sólo las aplicaciones Web que tienen ASP.NET o la nueva IU dentro de .NET Framework 3.0, pero no con realizar una reescritura total del sistema principal. Un buen ejemplo del grado de implicación de la decisión es la fusión de Made2Manage e Intuitive. A saber, la tecnología administrada con .NET de Intuitive será ahora la base, pero las decisiones relacionadas con la reescritura de los módulos de Made2Manage ERP existentes en código administrado .NET o su simple habilitación en .NET mediante aplicaciones wrapper de servicios Web se siguen analizando desde todos los puntos de vista. Claro está que cualquier funcionalidad nueva será escrita en código administrado .NET.

Los usuarios que se centran en Microsoft deben detenerse a pensar si la panacea final es el software de código administrado .NET. Es cierto que evita muchos problemas que los usuarios que usan el software tradicional Microsoft Windows deben enfrentar, como los (tristemente) célebres procesos complejos de instalación de DLL, las desinstalaciones pobres, etc.; esquiva las causas de muchos de los errores y los problemas de seguridad que sufren los usuarios. Estos sistemas con código administrado .NET serán más fáciles de instalar y administrar, por lo tanto, serán más baratos a largo plazo y más fáciles de proteger contra los hackers. Asimismo, los sistemas basados en .NET tendrán menos errores y harán que los fallos misteriosos de “pantallas azules” se vuelvan cosa del pasado. Si bien es cierto que menos problemas representan menos tiempo perdido para los usuarios y los profesionales de TI, ¿realmente es convincente en este momento? No hay una respuesta universal para el usuario prospecto. Para algunos puede ser suficiente con saber que el producto se diseñó usando objetos del negocio, componentes y normas XML. Al menos, esto puede servir para indicar si el producto realmente está habilitado para .NET.

Con esto concluye la serie Los sutiles (y no tan sutiles) matices de la habilitación en Microsoft .NET.