Gestión de cartera de aplicaciones

La gestión de la cartera de aplicaciones de TI ( APM ) es una práctica que ha surgido en organizaciones de tecnología de la información (TI) de tamaño mediano a grande desde mediados de la década de 1990. ^[1] La gestión de la cartera de aplicaciones intenta utilizar las lecciones de la gestión de la cartera financiera para justificar y medir los beneficios financieros de cada aplicación en comparación con los costos de mantenimiento y operaciones de la aplicación.

Es probable que la primera mención de la Cartera de Aplicaciones haya sido en el artículo de Cyrus Gibson y Richard Nolan en HBR "Managing the Four Stages of EDP Growth" en 1974. ^[2]

Gibson y Nolan postularon que la comprensión y el uso exitoso de TI por parte de las empresas "crecen" en etapas predecibles y que el progreso de una empresa determinada a través de las etapas se puede medir observando la cartera de aplicaciones, la conciencia del usuario, las prácticas de gestión de TI y los recursos de TI dentro del contexto de un análisis del gasto total en TI.

Nolan, Norton & Co. fue pionera en el uso de estos conceptos en la práctica con estudios en DuPont, Deere, Union Carbide, IBM y Merrill Lynch, entre otros. En estas "evaluaciones de etapas", midieron el grado en que cada aplicación respaldaba o "cubría" cada función o proceso empresarial, el gasto en la aplicación, las cualidades funcionales y las cualidades técnicas. Estas medidas proporcionaron una visión integral de la aplicación de TI en el negocio, las fortalezas y debilidades, y una hoja de ruta para la mejora.

APM fue ampliamente adoptado a fines de la década de 1980 y durante la década de 1990, cuando las organizaciones comenzaron a abordar la amenaza de falla de las aplicaciones cuando la fecha cambió al año 2000 (una amenaza que se conoció como Año 2000 o Y2K). ^[3] Durante este tiempo, decenas de miles de organizaciones de TI en todo el mundo desarrollaron una lista completa de sus aplicaciones, con información sobre cada aplicación.

En muchas organizaciones, los líderes empresariales cuestionaron el valor de desarrollar esta lista, preocupados por el costo de abordar el riesgo del Y2K . En algunas organizaciones, la noción de administrar la cartera se presentó a los ejecutivos a cargo del presupuesto de Tecnología de la Información como un beneficio de realizar el trabajo, más allá de administrar el riesgo de falla de la aplicación .

Existen dos categorías principales de soluciones de gestión de carteras de aplicaciones, generalmente denominadas enfoques "de arriba hacia abajo" y "de abajo hacia arriba". ^[4] La primera necesidad en cualquier organización es comprender qué aplicaciones existen y sus características principales (como flexibilidad, capacidad de mantenimiento, propietario, etc.), generalmente denominadas "inventario". Otro enfoque de APM es obtener una comprensión detallada de las aplicaciones en la cartera mediante el análisis del código fuente de la aplicación y sus componentes relacionados en una base de datos de repositorio (es decir, "de abajo hacia arriba"). Las herramientas de minería de aplicaciones, ahora comercializadas como herramientas APM, respaldan este enfoque.

Existen cientos de herramientas disponibles para respaldar el enfoque "de arriba hacia abajo". Esto no es sorprendente, ya que la mayor parte de la tarea consiste en recopilar la información correcta; el mantenimiento y almacenamiento reales de la información se pueden implementar con relativa facilidad. Por ese motivo, muchas organizaciones evitan el uso de herramientas comerciales y utilizan Microsoft Excel para almacenar los datos de inventario. Sin embargo, si el inventario se vuelve complejo, Excel puede volverse complicado de mantener. La actualización automática de los datos no es compatible con una solución basada en Excel. Por último, una solución de inventario de este tipo está completamente separada de las necesidades de comprensión "de abajo hacia arriba".

Según Forrester Research , "las empresas gastan dos tercios o más de sus presupuestos operativos de TI en operaciones y mantenimiento continuos". ^[5]

Es habitual encontrar organizaciones que cuentan con múltiples sistemas que realizan la misma función. Esta duplicación puede deberse a muchas razones, entre ellas, la antigua preponderancia de la informática departamental, los silos de aplicaciones de los años 1970 y 1980, la proliferación de fusiones y adquisiciones corporativas y los intentos fallidos de adoptar nuevas herramientas. Independientemente de la duplicación, cada aplicación se mantiene por separado y se actualiza periódicamente, y la redundancia aumenta la complejidad y el costo.

Dado que una gran mayoría de los gastos se destinan a la gestión de las aplicaciones de TI existentes, la transparencia del inventario actual de aplicaciones y el consumo de recursos es un objetivo principal de la gestión de la cartera de aplicaciones. ^{[6] [7]} Esto permite a las empresas: 1) identificar y eliminar aplicaciones parcial o totalmente redundantes, 2) cuantificar la condición de las aplicaciones en términos de estabilidad, calidad y capacidad de mantenimiento, 3) cuantificar el valor comercial/impacto de las aplicaciones y la importancia relativa de cada aplicación para el negocio, 4) asignar recursos de acuerdo con la condición e importancia de las aplicaciones en el contexto de las prioridades comerciales.

La transparencia también ayuda a los esfuerzos de planificación estratégica y disipa los conflictos entre el negocio y la TI, porque cuando los líderes empresariales comprenden cómo las aplicaciones respaldan sus funciones comerciales clave y el impacto de las interrupciones y la mala calidad, las conversaciones dejan de culpar a la TI por los costos excesivos y se centran en cómo gastar mejor los valiosos recursos para respaldar las prioridades corporativas.

Tomando ideas de la gestión de cartera de inversiones, los profesionales de APM reúnen información sobre cada aplicación en uso en una empresa u organización, incluido el costo de construir y mantener la aplicación, el valor comercial producido, la calidad de la aplicación y la vida útil esperada. ^[8] Con esta información, el administrador de cartera puede proporcionar informes detallados sobre el rendimiento de la infraestructura de TI en relación con el costo de propiedad y el valor comercial entregado.

En la gestión de carteras de aplicaciones, la definición de una aplicación es un componente fundamental. Muchos proveedores de servicios ayudan a las organizaciones a crear su propia definición, debido a los resultados a menudo polémicos que surgen de estas definiciones. ^[9]

• Software de aplicación : componente de software ejecutable o conjunto estrechamente acoplado de componentes de software ejecutables (uno o más), implementados en conjunto, que brindan algunos o todos los pasos necesarios para crear, actualizar, administrar, calcular o mostrar información para un propósito comercial específico. Para que se cuente, cada componente no debe ser miembro de otra aplicación.
• Componente de software : conjunto ejecutable de instrucciones informáticas contenidas en un único contenedor de implementación de forma que no se puedan dividir en partes. Algunos ejemplos son una biblioteca de vínculos dinámicos , una página web ASP y una aplicación de línea de comandos " EXE ". Un archivo zip puede contener más de un componente de software porque es fácil dividirlos en partes (descomprimiendo el archivo ZIP).

Aplicación de software y componente de software son términos técnicos que se utilizan para describir una instancia específica de la clase de software de aplicación con fines de gestión de cartera de TI . Consulte software de aplicación para obtener una definición para quienes no sean profesionales de la gestión de TI o la arquitectura empresarial.

La gestión de la cartera de aplicaciones de software requiere una definición bastante detallada y específica de una aplicación para poder crear un catálogo de aplicaciones instaladas en una organización.

La definición de una aplicación tiene las siguientes necesidades en el contexto de la gestión de la cartera de aplicaciones:

• Debe ser sencillo de explicar, comprender y aplicar para los miembros del equipo empresarial.
• Debe tener sentido para el desarrollo, las operaciones y la gestión de proyectos en los grupos de TI.
• Debe ser útil como insumo para una función compleja cuyo resultado sea el costo total de la cartera. En otras palabras, hay muchos factores que determinan el costo total de una cartera de TI. La gran cantidad de aplicaciones es uno de esos factores. Por lo tanto, la definición de una aplicación debe ser útil en ese cálculo.
• Debe ser útil para los miembros del equipo de Arquitectura Empresarial que intentan juzgar un proyecto con respecto a sus objetivos de optimización y simplificación de la cartera.
• Debe definir claramente los límites de una aplicación de modo que una persona que trabaje en una actividad de "simplificación de cartera" medible no pueda simplemente redefinir los límites de dos aplicaciones existentes de tal manera que las llame una sola aplicación.

Muchas organizaciones volverán a abordar la definición de aplicación en el contexto de sus prácticas de gestión y gobernanza de cartera de TI. Por ese motivo, esta definición debería considerarse como un punto de partida.

La definición de una aplicación puede resultar difícil de transmitir con claridad. En una organización de TI, puede haber diferencias sutiles en la definición entre equipos e incluso dentro de un mismo equipo de TI. Resulta útil ilustrar la definición proporcionando ejemplos. La sección siguiente ofrece algunos ejemplos de cosas que son aplicaciones, cosas que no son aplicaciones y cosas que comprenden dos o más aplicaciones.

Según esta definición se consideran aplicaciones las siguientes:

• Un punto final de servicio web que presenta tres servicios web: InvoiceCreate, InvoiceSearch y InvoiceDetailGet
• Una aplicación empresarial orientada a servicios (SOBA) que presenta una interfaz de usuario para crear facturas y que, a su vez, llama al servicio InvoiceCreate . (Tenga en cuenta que el servicio en sí es una aplicación diferente).
• Una aplicación móvil que se publica en una tienda de aplicaciones empresariales y, por lo tanto, se implementa en dispositivos portátiles propiedad de los empleados u operados por ellos, lo que permite el acceso autenticado a datos y servicios.
• Un sistema heredado compuesto por un cliente rico, un nivel intermedio basado en servidor y una base de datos, todos ellos estrechamente acoplados (por ejemplo, es muy probable que los cambios en uno desencadenen cambios en otro).
• Un sistema de publicación de sitios web que extrae datos de una base de datos y los publica en formato HTML como un subsitio en una URL pública.
• Una base de datos que presenta datos en un libro de trabajo de Microsoft Excel que consulta la información para el diseño y los cálculos. Esto es interesante porque la base de datos en sí es una aplicación, a menos que ya esté incluida en otra aplicación (como un sistema heredado).
• Una hoja de cálculo de Excel que contiene un conjunto coherente de macros reutilizables que aportan valor comercial. La hoja de cálculo en sí misma constituye un contenedor de implementación para la aplicación (como un archivo TAR o CAB ).
• Un conjunto de páginas web ASP o PHP que funcionan en conjunto para ofrecer la experiencia y la lógica de una aplicación web. Es totalmente posible que un subsitio pueda considerarse una aplicación independiente según esta definición si el acoplamiento es débil.
• Un punto final de servicio web establecido para la comunicación de máquina a máquina (no para la interacción humana), pero que puede entenderse racionalmente como que representa uno o más pasos útiles en un proceso comercial.

No son aplicaciones las siguientes:

• Un sitio web HTML.
• Una base de datos que contiene datos pero que no es parte de ninguna serie de pasos para generar valor comercial utilizando esos datos.
• Un servicio web que es estructuralmente incapaz de formar parte de un conjunto de pasos que aportan valor. Por ejemplo, un servicio web que requiere datos entrantes que rompen el esquema compartido.
• Un script por lotes independiente que compara el contenido de dos bases de datos realizando llamadas a cada una y luego envía un correo electrónico a un alias de monitoreo si se detectan anomalías en los datos. En este caso, es muy probable que el script por lotes esté estrechamente acoplado con al menos una de las dos bases de datos y, por lo tanto, debe incluirse en el límite de la aplicación que contiene la base de datos con la que está más estrechamente acoplado.

Las siguientes son muchas aplicaciones:

• Una aplicación SOA compuesta que consta de un conjunto de servicios reutilizables y una interfaz de usuario que aprovecha esos servicios. Hay al menos dos aplicaciones aquí (la interfaz de usuario y uno o más componentes de servicio). Cada servicio no se cuenta como una aplicación.
• Una aplicación cliente-servidor heredada que escribe en una base de datos para almacenar datos y una hoja de cálculo de Excel que utiliza macros para leer datos de la base de datos para presentar un informe. Hay DOS aplicaciones en este ejemplo. La base de datos pertenece claramente a la aplicación heredada porque se desarrolló con ella, se entregó con ella y está estrechamente acoplada a ella. Esto es así incluso si el sistema heredado utiliza los mismos procedimientos almacenados que la hoja de cálculo de Excel.

Existen muchas medidas financieras populares, e incluso más métricas de diferentes tipos (no financieras o complejas) que se utilizan para evaluar aplicaciones o sistemas de información.

El retorno de la inversión es una de las métricas de evaluación y medición del rendimiento más populares que se utilizan en el análisis empresarial. El análisis del ROI (cuando se aplica correctamente) es una herramienta poderosa para evaluar los sistemas de información existentes y tomar decisiones informadas sobre adquisiciones de software y otros proyectos. Sin embargo, el ROI es una métrica diseñada para un propósito determinado: evaluar la rentabilidad o la eficiencia financiera. No puede sustituir de manera confiable a muchas otras métricas financieras para brindar una imagen económica general de la solución de información. Los intentos de usar el ROI como la única o principal métrica para la toma de decisiones con respecto a los sistemas de información no pueden ser productivos. Puede ser apropiado en un número muy limitado de casos/proyectos. El ROI es una medida financiera y no brinda información sobre la eficiencia o la eficacia de los sistemas de información. ^[10]

Medida del desempeño financiero de una empresa basada en la riqueza residual calculada deduciendo el costo de capital de su beneficio operativo (ajustado por impuestos sobre la base de efectivo). (También se denomina "beneficio económico").

Fórmula = Utilidad operativa neta después de impuestos (NOPAT) - (Capital * Costo del capital)

El costo total de propiedad es una forma de calcular el costo de la aplicación durante un período de tiempo definido. En un modelo de costo total de propiedad, los costos de hardware, software y mano de obra se capturan y organizan en las distintas etapas del ciclo de vida de la aplicación. Un modelo de costo total de propiedad detallado ayuda a la administración a comprender el costo real de la aplicación, ya que intenta medir los costos de creación, ejecución/soporte e indirectos. Muchas grandes empresas de consultoría han definido estrategias para construir un modelo de costo total de propiedad completo.

TEI fue desarrollado por Forrester Research Inc. Forrester afirma que TEI analiza sistemáticamente los efectos potenciales de las inversiones en tecnología en cuatro dimensiones: costo (impacto en TI); beneficios (impacto en el negocio); flexibilidad (opciones futuras creadas por la inversión); riesgo (incertidumbre).

El programa ITBV fue desarrollado por Intel Corporation en 2002. ^[11] El programa utiliza un conjunto de mediciones financieras del valor empresarial que se denominan Indicadores de Valor Empresarial. Es un programa multidimensional, que incluye un componente empresarial, y es relativamente fácil de implementar.

AIE es un método de análisis de decisiones desarrollado por Hubbard Decision Research. AIE afirma ser "el primer método verdaderamente científico y teóricamente sólido" que se basa en varios métodos de la teoría de decisiones y el análisis de riesgos, incluido el uso de métodos de Monte Carlo. AIE no se utiliza a menudo debido a su complejidad.