Smartcards: Tecnología y Potencial

Preparado por: Ing.Declan Good
Agosto 2002

Sinopsis

Una aplicación legacy es una aplicación basada en tecnologías y hardware más viejos, tales como mainframes, la cual continua brindando servicios esenciales para una organización. Las aplicaciones Legacy muchas veces son grandes, monolíticas y difíciles de modificar, y desecharlas o reemplazarlas, en general, implica aplicar reingeniería a los procesos de la organización. La transformación de aplicaciones legacy se trata de la retención y extensión del valor de la inversión en Legacy por medio de la migración a nuevas plataformas. La re-implementación de aplicaciones en nuevas plataformas de esta manera puede reducir costos operativos y las capacidades adicionales de las nuevas tecnologías pueden brindar acceso a valiosas funciones tales como Servicios Web y Ambientes Integrados de Desarrollo. Una vez finalizada la transformación, las aplicaciones pueden adecuarse más a las necesidades futuras de las empresas agregando nueva funcionalidad a la aplicación transformada. En resumen, el proceso de transformación de aplicaciones legacy puede ser efectivo en cuanto a costos y puede ser una manera precisa de preservar las inversiones legacy y por tanto evitar los costos e impactos comerciales de la migración hacia un software totalmente nuevo. Este estudio explica cómo funciona la transformación y propone una estrategia para evaluar la idoneidad de las aplicaciones existentes para la migración a plataformas modernas tales como J2EE y .NET. El objetivo de la transformación de aplicaciones legacy es mantener el valor del activo legacy en la nueva plataforma. En la práctica esta transformación puede tomar diversas formas. Por ejemplo, puede involucrar la traducción de código fuente, o cierto grado de reutilización del código existente más una capacidad de conectar el sistema legacy a la web para brindarle al cliente el acceso requerido por la empresa. Si fuese necesario re-escribir, entonces se podría extraer las reglas existentes de la empresa para que formen parte de la declaración de requisitos para una re-escritura. El estudio adopta la posición de que el J2EE o .NET son plataformas meta adecuadas para la transformación. Los argumentos a favor se basan en factores técnicos y de costos, en el hecho de que la mayoría de los productos de traducción automática se dirigen hacia estas plataformas, en una creciente oferta de expertos en J2EE y .NET, facilitando así el reclutamiento de personal, y en la disponibilidad de protocolos estándar basados en XML para ser utilizados con otras aplicaciones, lo que facilita la publicación de la función de aplicación a una red (por lo general denominada “Servicios Web”). Hoy día es factible automatizar una parte considerable de este proceso de transformación, convirtiendo la transformación en una propuesta económica atractiva en comparación con re-escritura o reemplazo la aplicación legacy. Las herramientas disponibles cubren todos los aspectos del proceso aunque se requiere cierta intervención manual. La utilización de herramientas en la práctica dependerá de la escala de la tarea y de si la automatización es necesaria o económica en todos los casos. Se asume por supuesto que las aplicaciones existentes poseen una calidad suficiente y satisfacen las necesidades de las empresas de manera adecuada como para que valga la pena su transformación.

Las herramientas disponibles en el mercado son soluciones específicas – son aplicables a escenarios específicos y manejan únicamente parte del proceso de transformación. Por consiguiente, existirá una necesidad de comprar servicios para ayudar a diseñar y ejecutar la transformación ya que hay demasiadas incógnitas que superar sin la ayuda de expertos con experiencia previa. Los recursos internos serán necesarios para impartir los conocimientos disponibles acerca de las aplicaciones legacy, y para crear la base futura de conocimiento para mantener las aplicaciones transformadas y alineadas con las necesidades de las empresas. La transformación de aplicaciones legacy es una tarea que implica tanto riesgo como recompensa. Es fácil caer en la trampa de utilizar aplicaciones que parecen ser estables y tener la esperanza de que sean adecuadas para seguir adelante con la empresa al menos a mediano plazo. Pero estas aplicaciones legacy se encuentran en el centro de las operaciones de hoy en día y si se alejan mucho de las necesidades de las empresas, el impacto será considerable, y posiblemente catastrófico. El reto para el Gerente de Sistemas es presentar los argumentos para la inversión en legacy de la mejor forma posible, pero a la vez darle a la administración el panorama completo de estos riesgos y recompenses de manera que estos puedan tomar una decisión con una amplia disposición de los hechos. Por último, la transformación de aplicaciones legacy es un proyecto ‘habilitador’, que permite que sucedan otras cosas pero a su vez tiene sus propios beneficios directos. Al escoger un proveedor o proveedores para un proyecto de transformación, es mejor alcanzar un balance entre los participantes orientados hacia el proyecto (quienes se harán cargo de la transformación en sí), y los proveedores de infraestructura y el personal interno quienes deben lograr que el resultado final funcione cada día. Con los últimos adelantos, los conocimientos especializados en transformación deben ser el centro de la solución. Esto puede lograrse asignando un gerente de proyecto independiente (interno o contratista) y manteniendo los cambios funcionales y el trabajo de integración separados de las tareas de traducción de códigos, migración de datos y pruebas relacionadas. En conclusión, las herramientas y técnicas automatizadas disponibles hoy en día hacen que la transformación de aplicaciones legacy sea técnica y económicamente factible. El reemplazar o re-escribir es necesario en ciertos casos, pero si la aplicación legacy existente satisface las necesidades actuales de la empresa y la calidad es buena, entonces es posible que el activo pueda ser transformado de manera efectiva para seguir satisfaciendo las necesidades de la empresa en el futuro.

Conclusiones

• No siempre es necesario desechar o reemplazar las aplicaciones legacy. La transformación esuna opción factible si las aplicaciones actuales son de buena calidad y satisfacenrazonablemente las necesidades de la empresa.
• Hay herramientas automatizadas disponibles para migrar la mayoría de los datos y códigos aplataformas modernas.
• Si se necesita re-escribir por completo, existen herramientas disponibles para ayudar a extraerlas reglas existentes de la empresa para utilizarlas como aporte para la re-escritura.
• No ignore las aplicaciones legacy con la esperanza de que desaparezcan. Lleve a cabo unaauditoria regular sobre “que tan aptas son con respecto al propósito”.
• Avance en los Servicios Web: La evolución de los Servicios Web pondrá mayor presión paraordenar las aplicaciones legacy y hacerlas más accesibles a los clientes y los socioscomerciales. Comience a planear desde ahora.
• La transformación requiere tanto planeamiento y participación de la empresa como cualquier otro proyecto de TI.
• Involucre al personal técnico interno en el proyecto de transformación para asegurarse deobtener una transferencia de conocimientos -de lo contrario la organización puede encontrarsenuevamente donde comenzó, con aplicaciones que nadie entiende y que son imposibles demantener.
• No espere que el personal técnico interno esté contento con la transformación – la mayoría vaa preferir re-escribir la aplicación legacy o reemplazarla con el paquete de aplicación másreciente.
• No intente llevar a cabo la transformación usted solo la primera vez -escoja un proveedor consuficiente experiencia en transformación para que trabaje con usted.

Bajar Versión en Español del Informe

————————————————————————————————————————–

Synopsis

A legacy application is any application based on older technologies and hardware, such as mainframes, that continues to provide core services to an organisation. Legacy applications are frequently large, monolithic and difficult to modify, and scrapping or replacing them often means reengineering a organisation’s business processes as well. Legacy transformation is about retaining and extending the value of the legacy investment through migration to new platforms. Re-implementing applications on new platforms in this way can reduce operational costs, and the additional capabilities of new technologies can provide access to valuable functions such as Web Services and Integrated Development Environments. Once transformation is complete the applications can be aligned more closely to current and future business needs through the addition of new functionality to the transformed application. In short, the legacy transformation process can be a cost-effective and accurate way to preserve legacy investments and thereby avoid the costs and business impact of migration to entirely new software. This report explains how transformation works and proposes a strategy for assessing the suitability of existing applications for migration to modern platforms such as J2EE and .NET. The goal of legacy transformation is to retain the value of the legacy asset on the new platform. In practice this transformation can take several forms. For example, it might involve translation of the source code, or some level of re-use of existing code plus a Web-to-host capability to provide the customer access required by the business. If a rewrite is necessary, then the existing business rules can be extracted to form part of the statement of requirements for a rewrite. The report takes the view that J2EE or .NET are suitable target platforms for transformation. The arguments in favour are based on technical and cost factors, on the fact that most automatic translation products target these platforms, on a growing skill-base in J2EE and .NET, making it easier to recruit staff, and on the availability of standard XML-based protocols for use by other applications, which facilitate the publication of application function to a network (usually referred to as ‘Web Services’).

Substantial automation of this transformation process is now feasible, making transformation an economically attractive proposition compared with rewriting or replacing the legacy application. The available tools cover all aspects of the process, although some manual intervention will be required. Using the tools in practice will depend on the scale of the task and whether automation is necessary or economic in every case. It is assumed of course that the existing applications are of sufficient quality and fit business needs well enough to make them worth transforming.

The tools available in the market are point solutions – they are applicable to specific scenarios and only handle part of the transformation process. Consequently there will be a need to buy in services to help design and execute the transformation as there are too many unknowns to be overcome without help from experts with previous experience. In-house resources will be needed to impart available knowledge about the legacy applications, and to build up the future knowledge base for maintaining the transformed applications and aligning them with business needs.

Transforming legacy applications is a task with both risks and rewards. It is easy to fall into the trap of relying on what seem like stable applications and hoping that they will be adequate to keep the business going, at least in the medium term. But these legacy applications are at the heart of today’s operations and if they get too far out of step with business needs the impact will be substantial, and possibly catastrophic. The challenge for the CIO is to present the arguments for the legacy investment in the best possible light, but also to give management the full picture of these risks and rewards so that they can make a decision in full possession of the facts. Ultimately, legacy transformation is an ‘enabling’ project, that allows other things to happen, but has its own direct benefits as well.

In selecting a supplier or suppliers for a transformation project, it is best to strike a balance between the project-oriented players (who will take care of the transformation itself), and the infrastructure suppliers and in-house staff who have to make the end-result work every day. In today’s state of the art, transformation expertise must be at the heart of the solution delivery. This can be done by appointing an independent project manager (in-house or contractor), and keeping functional changes and integration work separate from the tasks of code translation, data migration and associated testing. In conclusion, the automated tools and techniques now available make legacy transformation technically and economically feasible. Replacement or rewrite are necessary in certain instances, but if the existing legacy application meets current business needs and the quality is good, then the chances are that the legacy asset can be effectively transformed to continue to meet the needs of the business in the future.

Conclusions

• It’s not always necessary to scrap or replace legacy applications. Transformation is a feasibleoption if the current applications are of good quality and a reasonable fit to business needs.
• Automatic tools are available to migrate most data and code to modern platforms.
• If a total rewrite is required, there are tools available to help extract the existing business rulesfor use as input to the rewrite.
• Don’t ignore legacy applications and hope they will go away. Carry out a regular audit on‘fitness for purpose’.
• Heads up on Web Services: Evolution of Web Services will put more pressure on to sort outlegacy applications and make them accessible to customers and business partners. Startplanning now.
• Transformation requires as much planning and business involvement as any other IT project.
• Involve in-house technical staff in the transformation project to ensure knowledge transfer –otherwise the organisation may be back where it started, with applications that no-oneunderstands and are impossible to maintain.
• Don’t expect in-house technical staff to beat the drum for transformation – most of them willprefer to rewrite the legacy application or replace it with the latest application package.
• Don’t attempt transformation on your own first time out -choose a supplier with the appropriatetransformation expertise to work with you.
Bajar Versión en Inglés del Informe

Patrocinan