Inicio
 > Informes e investigaciones > Blog de TEC > La relación entre la creación de modelos y la ag...

La relación entre la creación de modelos y la agilidad después de la implementación en la empresa

Escrito por: Predrag Jakovljevic
Publicado: octubre 11 2006

La arquitectura por modelos

Existen varias formas para tratar los requisitos que conlleva el cambio de un sistema de planificación de los recursos de la empresa, y una de ellas es mediante las llamadas arquitecturas por modelos. Se trata de esquemas de trabajo para desarrollo de aplicaciones que permiten describir estas últimas en términos de lo que deben hacer (el punto de vista del negocio del software) en lugar de cómo deben hacerlo (el punto de vista técnico del software). Este enfoque hace énfasis en diseñar los procesos y las reglas del negocio de forma directa para asegurarse de que la funcionalidad del negocio esté completa y sea correcta antes de iniciar la codificación. Si desea obtener más información sobre los retos que implica cambiar un sistema empresarial después de su implementación, consulte Los sistemas empresariales y su agilidad después de la implementación.

Segunda parte de la serie Los sistemas empresariales y su agilidad después de la implementación.

El enfoque en la creación de modelos permite visualizar la solución deseada para que los analistas, los usuarios y los desarrolladores puedan asegurarse de que se satisfacen las necesidades del negocio antes de que la implementación en el código del software haga que los cambios se dificulten o se vuelvan costosos. Con este modelo, el marco de trabajo genera automáticamente la aplicación ejecutable en lugar de que sea un equipo de programación quien convierta las especificaciones en software manualmente. Esta generación de código aumenta la eficacia del desarrollo y, en general, permite seleccionar la plataforma en que se realizará la generación. Para obtener más información, consulte What's Wrong with Application Software? A Possible Solution—What Is It, Why And How Does It Fit Into Your Future?.

Por otro lado, un almacén de información para toda la organización (como parte intrínseca del sistema principal de transacciones de la empresa en lugar de una “torre gemela” de información distinta) debe proporcionar dicha disponibilidad inteligente a los datos en todo el sistema. Por lo tanto, las aplicaciones deben residir dentro de un solo ambiente compartido en el que los metadatos (datos sobre los datos) se definan una sola vez y estén disponibles inmediatamente para las aplicaciones de finanzas, abastecimiento, costos de los proyectos, recursos humanos y nómina, entre otras. Este modelo de datos no sólo sirve como depósito compartido de información para las aplicaciones, sino que actúa como un “catálogo” definido automáticamente para toda una gama de herramientas especializadas de creación de reportes y transmisión de información. En otras palabras, las facilidades integradas de análisis, creación de reportes y comunicación (en donde los usuarios definen las visualizaciones del negocio de forma “en cualquier lugar, en cualquier momento y de cualquier forma”) se están convirtiendo en un elemento de base de las empresas que se centran en la gente, los proyectos y los servicios. La única forma de responder rápidamente a los cambios es proporcionar todos estos elementos dentro de un ecosistema y un contexto integrados.

Los gobiernos centrales en todo el mundo están exigiendo más el uso de automatización de las computadoras y la Internet para enlazar y administrar las agencias que dependen de ellos y para dar a sus empleados más poder. La idea es también mejorar el suministro de servicios locales y aumentar el grado de responsabilidad de las autoridades, los municipios, las ciudades, los pueblos y, finalmente, los usuarios finales (los ciudadanos). Además, las autoridades y los servicios de asistencia sanitaria o emergencia locales tienen la obligación de presentar informes sobre su desempeño a las unidades gubernamentales, ya sea que se trate de estados, provincias, cantones o cuerpos gubernamentales centrales. Por su parte, dichos cuerpos gubernamentales deben publicar los resultados de estos reportes al electorado. Así, los servidores públicos deben proporcionar servicios en línea a su clientela y deben ser capaces de buscar, amalgamar y crear reportes sobre los datos del éxito de sus agencias y de su avance hacia la automatización de la información. Necesitan una visualización completa y constante de la información de gestión para poder emitir juicios objetivos sobre los recursos y los servicios. Por lo tanto, las aplicaciones de software que soportan al sector público deben integrarse a lo largo de todos los procesos y deben dar soporte a los aspectos internos de la agencia o el cuerpo gubernamental relacionados con la gestión de datos, gente, finanzas y su misión específica -así como el público, que finalmente, debe aprovechar los estatutos del cuerpo gubernamental.

Además, las aplicaciones que usan arquitecturas por modelos se crean con base en los procesos y las reglas del negocio, y esto permite que los analistas del negocio entiendan y modifiquen la aplicación sin tener que sacrificar su calidad. Esto obvia los interruptores complejos y las tablas por parámetros que permiten configurar la aplicación realizando cambios a las reglas. Las aplicaciones personalizadas pueden crearse en poco tiempo para los negocios y las funciones del negocio que son únicos, y dichas arquitecturas permiten simplificar el código y tener un grado importante de automatización del desarrollo de código del software, lo que resulta en una mayor calidad de la aplicación.

Los peligros de la arquitectura orientada al servicio

Como se describió en Evolución de la arquitectura: desde la arquitectura de los marcos principales hasta la arquitectura orientada a los servicios, el concepto de arquitectura orientada a los servicios (SOA) debe (en teoría) ser capaz de ayudar a los negocios a reconfigurar sus procesos para responder con mayor rapidez y menores costos a las cambiantes condiciones del mercado. Eventualmente, debe fomentar la agilidad, la flexibilidad, la visibilidad y una colaboración con los socios comerciales (y entre los departamentos funcionales y de tecnología de la información [TI]), promoviendo la reutilización de servicios en un nivel más general (el componente del software) y no en los niveles detallados (y complicados) de los objetos. Además, SOA (una vez más, teóricamente) debe simplificar la interconexión “plug and play” y el uso de los activos de TI existentes, incluyendo los activos legados.

De acuerdo a Forrester, desde el punto de vista de los controladores del negocio, a largo plazo el concepto debe permitir que los usuarios adapten su sistema a los procesos (y no viceversa); mejorar la capacidad de intuición y uso del sistema; proporcionar analítica relevante; conectarse con los datos y los servicios externos y aprovechar las prácticas de excelencia y el conocimiento sobre la industria que ya están disponibles en los depósitos de los vendedores. En el idioma de la tecnología, SOA debe reducir la codificación personalizada mediante la configuración; promover normas abiertas para reducir los costos de integración; dar a los usuarios finales autosuficiencia (es decir que no deberán depender de los programadores) y proporcionar más flexibilidad para usar productos de primera (posiblemente dentro de aplicaciones compuestas).

Los datos que se publicaron en InfomationWeek el 4 de septiembre de 2006 coinciden con los resultados anteriores. De acuerdo a una encuesta que realizó InformationWeek Research, el 72 por ciento de las empresas quisieran usar SOA para obtener una mayor flexibilidad en el desarrollo de aplicaciones, el 61 por ciento espera crear aplicaciones orientadas a los servicios con mayor rapidez, el 58 por ciento pretende aumentar la modularidad del software y el 32 por ciento quiere tener un mayor potencial de personalización.

De cualquier forma, además de las normas comúnmente aceptadas que siguen madurando (y que a veces están en conflicto), algunos de los retos que debe enfrentar la implementación de SOA son el manejo de depósitos de metadatos del software dispares (es decir una frecuente racionalización y replicación de los datos), la incompatibilidad de abstracción del software dispar y los niveles adecuados de seguridad. Dirigir y proporcionar información en la interacción de los servicios puede resultar complicado, ya que la arquitectura depende de mensajería diversa compleja que puede producir códigos complicados y una ruptura en la comunicación, además de una posible falta de apego a los reglamentos gubernamentales. La flexibilidad de SOA implica amenazas a la seguridad, ya que estas aplicaciones se tragan los servicios, especialmente aquéllos que se encuentran fuera de los firewalls de la empresa. Por lo tanto, los servicios están más visibles a las personas externas que las aplicaciones tradicionales, y por ello los negocios deben definir políticas de protección de dicha información.

También pueden surgir problemas cuando los usuarios tratan de conectar los servicios que no se desarrollaron de la misma forma, y esto es muy probable cuando no se tiene un control dentro del ecosistema de cierto vendedor. Uno de los principales objetivos de SOA es retirar los enlaces de punta a punta cableados y que se escribieron con cierto propósito, para reemplazarlos con enlaces genéricos que se centran en las funciones y los procesos del negocio. Sin embargo, para lograrlo, es necesario agregar componentes nuevos de software a la ya compleja arquitectura, como motores de organización y flujo de trabajo, adaptadores de comunicación y traductores, herramientas de prueba y localizadores de servicios. Estas mega implementaciones pueden representar otra oportunidad para los gigantes de la consultoría, como IBM, que esperan enriquecerse con los proyectos de SOA. Es una situación muy similar a lo que sucedió durante el cambio al año 2000. Considerando las probables actualizaciones caras y problemáticas que no tienen ventajas comprobadas (y el hecho de que la publicidad exagerada de los vendedores está precediendo las capacidades reales de SOA), en este momento muchos clientes prospecto pueden creer que estos proyectos son otro ejercicio en la inutilidad del departamento de TI.

Irónicamente, aunque la SOA se ve como algo que ayuda a que los ambientes heterogéneos y legados se rejuvenezcan, puede funcionar mejor con un dominio y un contexto homogéneos, en donde los datos y los procesos están conscientes de sí mismos, como sucede con los productos Agresso Business World (ABW) o Epicor for Service Enterprises. Asimismo, Lawson Software acaba de aventurarse en una importante reescritura de productos con base en SOA llamada Landmark, en donde la idea es generar códigos de productos (y servicios) de forma automática y evitar las trampas que SOA puede representar -que se explicaron antes-, ya que el generador de código tendrá todas las reglas y restricciones de validación dentro del contexto del alcance del producto Lawson S3 (consulte ¿Una nueva plataforma para combatir la “inflamación” del software?).

Si se ponen estas condiciones de lado, siguen existiendo medios para que los cambios después de la implementación se conviertan en un proceso sólido y controlado que incluya gestión y calidad, mientras que da al usuario la capacidad para visualizar y evaluar las posibles modificaciones. De forma ideal, debe ayudar a que el usuario del negocio comprenda cuál será la apariencia del sistema y cómo funcionará después de los cambios -para evitar sorpresas y el trabajo adicional, y mejorar la aceptación por parte del usuario. Es necesario conocer desde antes todas las consecuencias que pueden tener los cambios, incluyendo su impacto en el sistema, así como el costo y el tiempo necesarios para realizarlos. Esto debe reflejarse en el “sistema total”, que incluye la documentación, los manuales de usuario, el texto de ayuda, etc., porque dicha información facilitará el proceso de gestión. Sin embargo, la mayoría de los desarrollos de SOA actuales están lejos de lo que prometen las nuevas versiones de los productos que permitirán reevaluar fácilmente cualquier modificación y reaplicarla como sea necesario con tiempo y costo realistas y una alta calidad -sin hablar de las modificaciones que evolucionan con las necesidades del negocio y los avances que da el vendedor.

En resumen, aunque SOA facilita la normalización, permite acoplar con soltura el ensamble y la integración de los componentes (servicios), aceptar una presentación personalizada con base en el portal y probablemente facilitar la integración, todavía no es una panacea. Por lo tanto, no es realista esperar que el simple concepto haga que los productos rígidos escritos en código antiguo se conviertan en aplicaciones flexibles que porporcionan información analítica que no se ha habilitado de forma nativa, ni que den ventajas de este tipo. Para tener un cambio radical, el producto subyacente debe crearse adecuadamente desde un principio (como sucedió con Agresso, que compara su agilidad con la capacidad que tiene un camaleón para adaptarse a su ambiente) o reescribirse por completo usando tecnologías y lenguajes nuevos y más modernos. Para obtener más información, consulte Rewrite or Wrap-around Old Software. Si no se modernizan en realidad la aplicaciones subyacentes, los embellecimientos que ofrece SOA serán irreales -aunque la mona se vista de seda...

A pesar de que teóricamente es posible abandonar la infraestructura existente para ir a un mundo ideal de aplicaciones ágiles, esto no será práctico para la gran mayoría de los ambientes heterogéneos. Para casi todos nosotros, el mundo de TI es una mezcla de aplicaciones, tecnologías, etc., y la arquitectura preferida será aquélla capaz de racionalizar los procesos del negocio sin tener que desperdiciar las inversiones que realizan actualmente las empresas en aplicaciones.

Resumen y recomendaciones a los usuarios

Todo cambia, hasta los ambientes comerciales. Por eso, el sistema empresarial subyacente debe ser un factor que promueva, y no que impida como lo hace actualmente, que el negocio cambie. La arquitectura de los sistemas empresariales del futuro debe aceptar que los negocios cambian y ayudar a que el software cambie con ellos. Las empresas usuarias necesitan las prácticas de excelencia, pero también necesitan prácticas “diferenciadoras” y la capacidad para responder a las necesidades de los clientes, los empleados y los socios comerciales. Los proyectos de modificación suelen ser muy grandes, pero para que las aplicaciones puedan responder, debe ser posible cambiarlas de forma económica tanto para los requisitos pequeños como para los grandes.

Con esto termina la serie Los sistemas empresariales y su agilidad después de la implementación.

Acerca de los autores

Predrag Jakovljevic es analista senior en Technology Evaluation Centers (TEC), y se enfoca en el mercado de las aplicaciones empresariales. Cuenta con cerca de veinte años de experiencia en la industria de la manufactura, incluyendo varios años como usuario experimentado de TI/ERP, así como consultor/implementador y analista del mercado. Es ingeniero mecánico de la Universidad de Belgrado (en la antigua Yugoslavia) y tiene un certificado en gestión de producción e inventario (CPIM) y en gestión integrada de los recursos (CIRM) de APICS.

Olin Thompson es director de Process ERP Partners. Cuenta con más de veinticinco años de experiencia como ejecutivo en la industria del software, y se le conoce como “el padre” de ERP de procesos. Escribe y da conferencias sobre temas como obtención de valor con ERP, planificación de la cadena de suministro (SCP), comercio electrónico y el impacto que tiene la tecnología en la industria. Se le puede contactar en Olin@ProcessERP.com.

 
comments powered by Disqus

Búsquedas recientes:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others