domingo, 28 de septiembre de 2008

Aplicaciones Enterprise

Una aplicación enterprise es un sistema fuertemente orientado a un negocio determinado, que debe cumplir ciertos requerimientos no funcionales. En general, las aplicaciones enterprise:
  • persisten datos de forma masiva
  • suelen ser multiusuarios (varios usuarios pueden acceder de forma concurrente)
  • cuentan con muchísimas interfaces de usuario
  • se integran con otros sistemas
  • presentan disonancia conceptual (usuarios con vistas contrapuestas)
  • tienen lógica de negocio
¿Una aplicación enterprise es aquella que cumple con todas las características recién enunciadas? No necesariamente. En mi opinión personal, la única característica importante e imprescindible es la última. Una aplicación enterprise es aquella que tiene lógica de negocio, por eso empecé el post afirmando que es un sistema fuertemente orientado al negocio y por eso en mucha bibliografía a las aplicaciones enterprise se las suele llamar aplicaciones de negocio (business applications).

En general, que tengamos una lógica de negocio acarrea que debamos guardar el estado (los conceptos o las entidades) de esa lógica para poder recuperarlo en todo momento. También implica que esos conceptos puedan ser mostrados de alguna manera a los usuarios del negocio, a los clientes, y en general, los clientes suelen ser muchos, y suelen ejecutar consultas en paralelo. Así es como un requerimiento no funcional lleva a otro y nos encontramos con que, cuando nos enfrentamos a una aplicación enterprise que va creciendo en tamaño y complejidad, son necesarias casi todas las características antes enumeradas.

Casi se podría decir que cualquier aplicación compleja y grande es una aplicación enterprise. Yo diría que no es tan así, pero tampoco la afirmación está tan lejos de la verdad.

El concepto de aplicación enterprise nació con el fin de modularizar y organizar el desarrollo de aplicaciones complejas de negocio, cuyo número de desarrolladores, analistas, diseñadores crecía exponencialmente al paso que se multiplicaban los requerimientos no funcionales. Como la posibilidad de automatizar negocios cada vez más complejos se hizo posible gracias al escalamiento de hardware y de paradigmas y técnicas de programación más efectivas (como la orientación a objetos y las metodologías de desarrollo), se necesitó una forma de separar lo que es la lógica de negocio (requerimientos funcionales) de lo que es la lógica de la aplicación (requerimientos no funcionales). Entonces comenzaron a surgir algunos frameworks, primero en el mundo de Java, que intentaban lograr esta separación. Surgió la especificación de Sun Microsystems para los Enterprise Java Beans (EJB) y un tiempo después Microsoft se metió en el mercado para hacerle frente con una plataforma bastante más sencilla llamada .NET, pero que demoró mucho en madurar.


Durante demasiados años, tanto la plataforma enterprise de Java (J2EE) como .NET tuvieron muchísimos problemas. Las especificaciones no eran del todo felices y, en el afán de abstraer al programador de los requerimientos no funcionales comunes a todas las aplicaciones enterprise (la lógica de aplicación), las herramientas para diseñar una buena lógica de negocio se vio limitada, brutalmente recortada, logrando que la programación orientada a objetos retrocediera unos cuantos pasos. Hasta se habló de anti-patrones en J2EE y se publicaron varias tesis y artículos al respecto. ¡Pero era lo que había!

Recién hace tres o cuatro años que el panorama está mejorando. No fue hasta que comenzaron a surgir los famosos frameworks livianos (como Spring por ejemplo) que los programadores pudieron volver a aplicar la programación orientada a objetos en todo su esplendor para construir lógicas de negocio más robustas, escalables y parecidas a la realidad. Sun Microsystem tomó muchas de las ideas de los frameworks livianos y lanzó una nueva especificación: EJB 3.0, a la vez que cambió el nombre de su plataforma J2EE a JavaEE.

Arquitectura de 4-tiers

Los requerimientos no funcionales más comunes en una aplicación enterprise son:
  • Bajo Tiempo de Respuesta
  • Alta Interactividad con el Usuario
  • Baja Latencia
  • Muchas Transacciones por segundo (throughput)
  • Alta Carga (número de usuarios concurrentes)
  • Baja Degradación (variación del Tiempo de Respuesta con la Carga)
  • Alta Eficienta (performance)
  • Alta Capacidad (máxima entre el throughput y la carga)
  • Alta Escalabilidad (horizontal: + servidores; vertical: +CPU,+memoria)
  • Alta Disponibilidad o Nivel de Servicio
Para satisfacer este tipo de requerimientos, en general, las aplicaciones enterprise han adoptado un tipo de arquitectura casi estándar, que consiste en dividir el sistema en cuatro capas físicas (tiers):
  • Presentación
  • Acceso al Negocio
  • Negocio o Dominio
  • Persistencia

El Cliente, por ejemplo un browser (si hablamos de una aplicación web) o una ventana gráfica del sistema operativo (si hablamos de una aplicación desktop), accede a la capa de Presentación. La capa de presentación es responsable del formateo de los datos para la visualización y de la interpretación de los comandos del usuario. En la capa de presentación podrían vivir los servlets, por ejemplo, si hablamos de una aplicación web en Java.

Esta capa podría acceder directamente a la capa de negocio o dominio, de hecho muchos autores proponen eso. Pero en realidad, lo más correcto sería contar con una capa (que a veces es muy delgada) entre la de presentación y la de dominio, para que desacople ambas y podamos construir distintas presentaciones que accedan concurrentemente y se abstraigan del uso de la lógica de negocio. Esta capa de la que hablo es la de Acceso al Negocio o Capa de Aplicación o Capa de Servicio (Martin Fowler la llama Service Layer). En la capa de Acceso al Negocio vivirán los casos de uso del sistema, los requerimientos funcionales, los servicios de la lógica de dominio, de la lógica de negocio, que deben ser expuestos. Esta capa tendrá permiso para manipular los objetos de negocio que viven en la Capa de Negocio, en el dominio de la aplicación. Podría decirse que se trata de un facade del dominio.

La Capa de Negocio es la más importante, ya que aquí es donde vive el modelo, donde vive la lógica de negocio y, como antes mencioné, la lógica de negocio es lo más importante en una aplicación enterprise. Prefiero no hablar mucho ahora del dominio ni de la clase de modelos que uno puede insertar ahí dentro, ya que planeo dedicar varios post en el futuro a su construcción y las implicaciones filosóficas y técnicas que ésta acarrea.

Por último, tenemos una capa de Persistencia, cuya función principal es la de desacoplar la aplicación de la base de datos para no depender de un SGBD específico y gestionar el acceso a la misma de forma eficiente. Esta capa debería hacernos menos dolorosa una posible migración futura de base de datos.

Si prestan atención al gráfico de arquitectura pueden ver que la capa de Acceso al Negocio apunta a la capa de Dominio, y a su vez, la capa de Persistencia también apunta a la capa de Dominio. Estas flechas que parecen tan inocentes están simbolizando dependencia. Según cómo el framework implemente la capa de Persistencia, el dominio apuntará a la de Persistencia o al revés. Lo que trata de hacer un ORM como Hibernate, por ejemplo, es invertir la dependencia del flujo normal de tiers para que el dominio no tenga que conocer absolutamente nada de la aplicación. De esta forma, logramos desacoplar por completo la lógica de negocio, para usarla en cualquier otra aplicación o plataforma.

En post futuros profundizaré sobre este tema.

jueves, 4 de septiembre de 2008

Val IT

La iniciativa Val IT, en la que se incluyen investigaciones, publicaciones y servicios de soporte, tiene como objetivo ayudar a la gerencia a garantizar que las organizaciones logren un valor óptimo de las inversiones de negocio posibilitadas por TI a un coste económico, y con un nivel conocido y aceptable de riesgo. Val IT proporciona guías, procesos y prácticas de soporte para ayudar al consejo/directorio y a la dirección ejecutiva a comprender y desempeñar sus roles relacionados con dichas inversiones.


En concreto, Val IT se centra en la decisión de invertir (¿estamos haciendo lo correcto?) y la realización de beneficios (¿estamos obteniendo beneficios?). CobiT se centra específicamente en la ejecución (¿lo estamos haciendo correctamente?) (¿lo estamos logrando bien?).


La aplicación eficaz de los principios, procesos y prácticas contenidas en Val IT permitirá a las organizaciones:
  • Aumentar el conocimiento y transparencia de los costes, riesgos y beneficios, dando como resultado decisiones de gestión mucho mejor informadas.
  • Aumentar la probabilidad de seleccionar inversiones que tengan el potencial de generar la mayor rentabilidad.
  • Aumentar la probabilidad de éxito al ejecutar las inversiones elegidas de modo que logren o sobrepasen su rentabilidad potencial.
  • Reducir costes no haciendo cosas que no deben hacerse y tomando rápidamente medidas correctivas o terminando inversiones que no están cumpliendo su potencial esperado.
  • Reducir el riesgo de fracaso, especialmente el fracaso de alto impacto.
  • Reducir sorpresas en relación con el coste y entrega de TI, y de esa forma aumentar el valor del negocio, reducir costes innecesarios y aumentar el nivel global de confianza en TI.
Val IT complementa a CobiT desde el punto de vista financiero y de negocio, y ayudará a todos aquellos con un interés en la entrega de valor a partir de TI. Es responsabilidad del consejo, del Director General y de todos los ejecutivos garantizar la optimización de la rentabilidad de los accionistas y socios mediante el uso juicioso de los recursos y oportunidades disponibles. Esta responsabilidad abarca las inversiones de negocio y recursos de TI donde los costes, la visibilidad de éxito o fracaso y los riesgos de destrucción de valor son altos, pero existe un evidente potencial para una creación importante de valor.

El Marco

Val IT consiste en un conjunto de principios directrices y varios procesos acordes con dichos principios, que además se definen como conjunto de prácticas de gestión.

Val IT permite soportar el objetivo de negocio de
Realizar un valor óptimo de las inversiones de negocio impulsadas por IT a un coste económico y con un nivel aceptable de riesgo

____y está guiado por
____Un conjunto de principios aplicados a procesos de gestión de valor

________que son impulsados por
________Prácticas claves de gestión con referencias cruzadas a los controles claves de CobiT

____________y que se miden por
____________Métricas de resultados y rendimiento

Principios

  • Las inversiones posibilitadas por TI se gestionarán como cartera de inversiones.
  • Las inversiones posibilitadas por TI abarcarán el pleno alcance de actividades que son necesarias para lograr el valor de negocio.
  • Las inversiones posibilitadas por TI se gestionarán a lo largo de su ciclo de vida económico completo.
  • En las prácticas de entrega de valor se reconocerá que existen distintas categorías de inversión cuya evaluación y gestión será diferente.
  • En las prácticas de entrega de valor se definirán y monitorizarán las métricas claves y se responderá rápidamente a cualquier cambio o desviación.
  • Las prácticas de entrega de valor implicarán a todos los stakeholders y se asignará la responsabilidad correspondiente para la entrega de capacidades y la realización de beneficios del negocio.
  • Se hará un monitoreo, evaluación y mejora conti nua de las prácticas de entrega de valor.

Procesos

  • Gobierno del valor
  • Gobierno de cartera
  • Gobierno de inversiones

Buen Gobierno del Valor: VG – Value Governance

El buen gobierno del valor tiene como objetivo optimizar el valor de las inversiones posibilitadas por TI de una organización:
  • Estableciendo el marco de buen gobierno, monit oreo y control
  • Marcando la dirección estratégica para las inversiones
  • Definiendo las características de la cartera de inversiones

Gestión de Cartera: PM – Portfolio Management

La gestión de cartera tiene como objetivo asegurar que la cartera global de inversiones posibilitadas por TI de una organización esté alineada con l os objetivos estratégicos de ésta, y contribuyendo valor óptimo a los mismos:
  • El establecimiento y gestión de perfiles de recursos
  • La definición, priorización y selección, aplazamiento o rechazo de nuevas inversiones
  • La gestión de la cartera global
  • El monitoreo e informes sobre el rendimiento de la cartera

Gestión de Inversiones: IM – Investment Management

La gestión de inversiones tiene como objetivo asegurar que los programas individuales de inversiones posibilitadas por TI entreguen un valor óptimo a un coste económico y con un nivel conocido y aceptable de riesgo, mediante:
  • La identificación de necesidades de negocio
  • La adquisición de un claro entendimiento de los programas de inversión candidatos
  • El análisis de las alternativas
  • La definición del programa y la documentación de un caso de negocio detallado, incluyendo detalles de los beneficios
  • La asignación clara de responsabilidad y propiedad
  • La gestión del programa durante todo su ciclo de vida económica
  • El monitoreo e informes sobre el rendimiento del program a
Existen tres componentes claves de la gestión de inversi ones:
  • Desarrollo del caso de negocio: Dando soporte a la selección de los programas de inversión oportunos
  • Gestión de programas: Gestionando la ejecución de los p rogramas
  • Realización de beneficios: Gestionando activamente la realización de los beneficios de los programas

Prácticas Claves de Gestión que Soportan los Tres Procesos


Fuentes