{"id":73965,"date":"2021-06-24T08:00:00","date_gmt":"2021-06-24T06:00:00","guid":{"rendered":"https:\/\/e3magpmp.greatsolution.dev\/?p=73965"},"modified":"2021-06-25T11:30:09","modified_gmt":"2021-06-25T09:30:09","slug":"modernizacion-del-codigo","status":"publish","type":"post","link":"https:\/\/e3magpmp.greatsolution.dev\/es\/modernizacion-del-codigo\/","title":{"rendered":"Modernizaci\u00f3n del c\u00f3digo"},"content":{"rendered":"

Con una modernizaci\u00f3n inteligente del c\u00f3digo y una arquitectura de destino adecuada, una empresa tambi\u00e9n puede llevar a cabo proyectos de transformaci\u00f3n complejos con relativa facilidad, rapidez y optimizaci\u00f3n de costes. <\/p>\n\n\n\n

Las tareas para los actuales clientes de SAP est\u00e1n claramente definidas: Por un lado, deben migrar a Hana y S\/4; por otro, deben utilizar simult\u00e1neamente nuevas tecnolog\u00edas y arquitecturas para impulsar de forma coherente la modernizaci\u00f3n en el marco de la transformaci\u00f3n digital, por ejemplo, en lo que respecta a la introducci\u00f3n r\u00e1pida y flexible de nuevos modelos de negocio.<\/p>

\"\"<\/a><\/div>
\"\"<\/a><\/div>
\"\"<\/a><\/div>\n\n\n\n

El c\u00f3digo personalizado de Abap en los sistemas heredados, en particular, plantea un reto importante durante la migraci\u00f3n. Las empresas que llevan mucho tiempo utilizando sistemas SAP tienen una gran cantidad de c\u00f3digo personalizado que se ha desarrollado a lo largo del tiempo para dar soporte al crecimiento y a los requisitos empresariales en constante cambio. <\/p>\n\n\n\n

Gran parte de este c\u00f3digo puede quedar obsoleto con el tiempo porque no est\u00e1 dise\u00f1ado teniendo en cuenta los requisitos actuales, como la seguridad, el rendimiento o la mantenibilidad. <\/p>\n\n\n\n

Adem\u00e1s, a menudo el c\u00f3digo ya no es ejecutable en los nuevos entornos S\/4. De este modo, el c\u00f3digo Abap personalizado obstaculiza la innovaci\u00f3n al entorpecer los proyectos de modernizaci\u00f3n y las actualizaciones.<\/p>\n\n\n\n

Contenedores<\/h3>\n\n\n\n

En t\u00e9rminos m\u00e1s generales, el proceso de modernizaci\u00f3n en el contexto SAP tiene por objeto contenerizar y modificar las aplicaciones con vistas a mejorar su funcionamiento y facilitar su actualizaci\u00f3n. <\/p>\n\n\n\n

En este caso, el c\u00f3digo personalizado plantea dificultades, ya que suele estar estrechamente vinculado al enfoque monol\u00edtico de los sistemas SAP ERP\/ECC 6.0 tradicionales. Una migraci\u00f3n de igual a igual dif\u00edcilmente puede mapearse y no ofrece ning\u00fan valor a\u00f1adido. <\/p>\n\n\n\n

Las tareas consisten, por tanto, en hacer primero un inventario del c\u00f3digo personalizado, identificar las dependencias ambiguas y proporcionar interfaces entre los componentes de la aplicaci\u00f3n. El resultado de estas actividades es una mayor transparencia, un mantenimiento m\u00e1s f\u00e1cil y la eliminaci\u00f3n de regresiones.<\/p>\n\n\n\n

Modernizaci\u00f3n del c\u00f3digo personalizado<\/h3>\n\n\n\n

La modernizaci\u00f3n del c\u00f3digo personalizado se lleva a cabo b\u00e1sicamente en las cuatro fases de an\u00e1lisis, descomposici\u00f3n, integraci\u00f3n y concepci\u00f3n de la arquitectura de destino.<\/p>\n\n\n\n

El primer paso consiste en analizar el c\u00f3digo e identificar las partes de las aplicaciones de sistemas existentes que son adecuadas para su transformaci\u00f3n en microservicios y una arquitectura basada en contenedores. <\/p>\n\n\n\n

El an\u00e1lisis tambi\u00e9n suele revelar que en los sistemas SAP hay c\u00f3digo que ya no se utiliza y que, por tanto, puede eliminarse tras una auditor\u00eda; la proporci\u00f3n de este c\u00f3digo no utilizado sobre el total de c\u00f3digo existente en un sistema puede ser de hasta el 60%. <\/p>\n\n\n\n

\"\"
Del an\u00e1lisis a la arquitectura de destino con la automatizaci\u00f3n SmartShift.<\/figcaption><\/figure>\n\n\n\n

El an\u00e1lisis identifica posibles candidatos que pueden desacoplarse mostrando las dependencias entre objetos. Adem\u00e1s, se identifican las violaciones del c\u00f3digo fuente para que los procesos empresariales sean ejecutables en un entorno S\/4.<\/p>\n\n\n\n

Segundo paso: En la fase de descomposici\u00f3n tiene lugar una concepci\u00f3n iterativa de componentes que renuevan la base de c\u00f3digo existente y sirven de bloques de construcci\u00f3n para nuevos desarrollos. Los componentes admiten la comunicaci\u00f3n de protocolos modernos sin estado, los llamados microservicios.<\/p>\n\n\n\n

El tercer paso consiste en la integraci\u00f3n con una conexi\u00f3n de los componentes para el intercambio de datos y procesos en tiempo real. Para ello debe utilizarse una plataforma que permita un acoplamiento flexible y utilice conectores API, programaci\u00f3n basada en eventos y sincronizaci\u00f3n as\u00edncrona para mejorar la tolerancia a fallos.<\/p>\n\n\n\n

El \u00faltimo paso se refiere al dise\u00f1o de la arquitectura de destino real, que idealmente se basa en contenedores. En concreto, se trata, por ejemplo, de cubrir las necesidades de escalado o de apoyo a los procesos mediante la automatizaci\u00f3n de las actualizaciones, la supervisi\u00f3n o las pruebas.<\/p>\n\n\n\n

Plataforma de nube h\u00edbrida<\/h3>\n\n\n\n

Adem\u00e1s de la metodolog\u00eda utilizada, la arquitectura de destino tiene una importancia decisiva para el \u00e9xito de la migraci\u00f3n. Y mientras tanto, ha surgido una plataforma de destino ideal. <\/p>\n\n\n\n

Si una empresa quiere abordar temas de innovaci\u00f3n, est\u00e1 claro con respecto a la arquitectura de destino que no hay forma de evitar el uso de nuevas plataformas, marcos, aplicaciones y tecnolog\u00edas: Las plataformas h\u00edbridas multi-nube integradas, las aplicaciones nativas en la nube, los contenedores, los microservicios y las API son los componentes clave.<\/p>\n\n\n\n

El desarrollo tambi\u00e9n est\u00e1 claramente marcado en el \u00e1rea de SAP: Las plataformas de nube h\u00edbrida y el desarrollo de aplicaciones nativas de la nube tendr\u00e1n un impacto duradero en el futuro. El ecosistema SAP avanzar\u00e1 hacia plataformas de nube h\u00edbrida.
La arquitectura modernizada y los clientes actuales de SAP utilizar\u00e1n cada vez m\u00e1s en el futuro una combinaci\u00f3n de servicios locales, privados y de nube p\u00fablica, no s\u00f3lo para SAP, sino tambi\u00e9n para cargas de trabajo ajenas a SAP. <\/p>\n\n\n\n

\"\"
El concepto de extensibilidad Side-by-Side de SAP.<\/figcaption><\/figure>\n\n\n\n

Adem\u00e1s, los entornos de ejecuci\u00f3n nativos de la nube se convertir\u00e1n en el patr\u00f3n de despliegue dominante, ya que son el motor m\u00e1s din\u00e1mico de la innovaci\u00f3n. La comunicaci\u00f3n basada en API adquirir\u00e1 un significado especial en el mundo SAP del futuro. Las API abiertas son la base t\u00e9cnica para conectar en red datos, aplicaciones y dispositivos y, por tanto, tambi\u00e9n para implementar innovaciones sin crear nuevos silos de TI.<\/p>\n\n\n\n

API abiertas<\/h3>\n\n\n\n

El uso de API abiertas es casi indispensable, especialmente en lo que respecta al concepto de extensibilidad side-by-side de SAP. Su objetivo es conectar los datos, procesos e interfaz de usuario de SAP con entornos de programaci\u00f3n modernos, integraci\u00f3n continua y entrega continua, as\u00ed como m\u00e9todos DevOps. <\/p>\n\n\n\n

\"\"
Integraci\u00f3n \u00e1gil de cargas de trabajo SAP y no SAP.<\/figcaption><\/figure>\n\n\n\n

Las denominadas \"extensiones side-by-side\" para sistemas S\/4 permiten, a diferencia de los desarrollos internos cl\u00e1sicos basados en Abap, la implementaci\u00f3n sencilla de procesos de extremo a extremo y, por lo tanto, tambi\u00e9n integran el entorno SAP con sistemas que no son SAP. Este concepto puede realizarse c\u00f3modamente sobre la base de la plataforma empresarial Kubernetes Red Hat OpenShift. Esto ofrece al usuario libertad de elecci\u00f3n en t\u00e9rminos de infraestructura y la opci\u00f3n de uso de nubes m\u00faltiples o h\u00edbridas.<\/p>\n\n\n\n

Se necesitan soluciones de integraci\u00f3n y gesti\u00f3n para implantar el concepto de ampliaci\u00f3n side-by-side de forma f\u00e1cil y r\u00e1pida. Las soluciones modernas de gesti\u00f3n de API, como las disponibles con la versi\u00f3n empresarial 3scale API Management, son modulares, altamente escalables y se verifican con las API de la nube de SAP y con muchos sistemas de TI de terceros. <\/p>\n\n\n\n

Adem\u00e1s, se requiere una soluci\u00f3n de integraci\u00f3n \u00e1gil con la que los desarrolladores puedan establecer una comunicaci\u00f3n bidireccional con Hana y las aplicaciones. El marco de c\u00f3digo abierto Apache Camel o Red Hat Fuse son especialmente adecuados en este caso.<\/p>\n\n\n\n

\"\"
Arquitectura de extremo a extremo en el contexto SAP.<\/figcaption><\/figure>\n\n\n\n

Uno al lado del otro<\/h3>\n\n\n\n

Si se implementa un concepto side-by-side, tambi\u00e9n es posible un uso c\u00f3modo de soluciones de automatizaci\u00f3n como Ansible. Ansible ayuda a los usuarios de SAP en implementaciones de nube h\u00edbrida, por ejemplo, en la provisi\u00f3n y gesti\u00f3n automatizadas de cargas de trabajo SAP tradicionales y nuevas en contenedores, as\u00ed como de aplicaciones que no son SAP en entornos de nube h\u00edbrida. <\/p>\n\n\n\n

Ansible tambi\u00e9n ofrece automatizaci\u00f3n DevOps en el \u00e1rea SAP, es decir, soporte para el desarrollo automatizado, despliegue, puesta en marcha y administraci\u00f3n de plataformas SAP.<\/p>\n\n\n\n

En general, una nueva y moderna arquitectura de sistema de nube h\u00edbrida ofrece a los usuarios de SAP numerosas ventajas. Estas incluyen, entre otras:<\/p>\n\n\n\n