Determinación del alcance de una iniciativa SOA

Los proyectos con una inadecuada definición de alcance son altamente propensos a tener problemas, y dejar a más de una parte interesada disconforme. Los proyectos en SOA obviamente no son la excepción.

Sin embargo, iniciativa de transformación a SOA se caracteriza por requerir un alineamiento más notorio con los objetivos del negocio, ya que dada la magnitud y complejidad de estas iniciativas se requiere de un patrocino ejecutivo que se mantenga indeleble.

Para lograr una definición precisa del alcance, y conducente a los objetivos de la iniciativa SOA, se puede utilizar una técnica denominada “modelado servicio-objetivo”, la cual utiliza los objetivos del negocio para la definición y restricción del alcance. Muy en resumen, esta técnica se centra en identificar los objetivos de negocio, articulándolos de manera precisa, luego priorizándolos y finalmente obteniendo un acuerdo consensuado, respaldado por la firma de cada uno de los terceros relevantes de la iniciativa. Luego estos objetivos son utilizados para determinar cuales servicios y aplicaciones están dentro del alcance de la transformación organizacional, dejando sólo a aquellos donde se puede establecer una traza directa hacia la realización de los objetivos de negocio priorizados que la organización tiene más interés en lograr.

Referencias:
SOA Governance: Achieving and Sustaining Business and IT Agility

Estandarización de estructuras de datos para la adopción de SOA

Dentro de los múltiples factores que deben ser abordados para lograr una adecuada adopción de SOA dentro de una organización, uno de los más relevantes y que debe ser abordado tempranamente es el de la estandarización de sus estructuras de datos. Una organización que posee un modelo de datos común está en muy buen pie para lograr buenos niveles de reutilización y flexibilidad organizacional.

Sin embargo, es muy probable que la existencia de un modelo de datos común y transversal sea más la excepción que la regla, y que la mayor parte de las organizaciones de gran tamaño tengan bases de datos con esquemas redundantes. También puede que la documentación de los modelos de datos no esté disponible, o sea propietaria. Por último, es muy probable que el grado de acoplamiento, o dependencia estructural, entre las aplicaciones de software y sus respectivos modelos de datos sea tan alto que haga imposible su modificación a un costo razonable. Debido a todo lo anterior, una iniciativa de adopción de SOA debe tomar la estandarización de datos desde otro ángulo, buscando la estandarización de las estructuras a nivel de mensajería. Como paso concreto, la organización debiera instaurar mecanismos para estandarizar y gobernar todos sus esquemas XML.

Antes de empezar a realizar un levantamiento de todas las estructuras de datos relevantes, y de comenzar generar un modelo de datos común para toda la organización, se debe investigar si existen modelos estándares aportados por la industria para el dominio concreto del negocio (por ejemplo, modelos para la industria de seguros, naviera, financiera, etc.,) o para un dominio transversal, como por ejemplo el de recursos humanos. Existen organizaciones como OASIS (www.oasis-open.org) que se dedican a la creación de estándares abiertos, y cuentan con sitios tales como www.xml.org enfocados en áreas específicas de negocios.

De existir tales modelos, debe privilegiarse su uso, pues facilitará la interoperación con organizaciones externas y la integración entre sistemas internos. Un modelo levantado sin esta consideración muy probablemente requerirá de transformaciones para interoperar fuera del ámbito en que fue concebido, lo que llevará a múltiples problemas que pueden ser evitados, como mayores costos de hardware y middleware, y perdidas de desempeño en las aplicaciones que requieran de tales transformaciones.

En caso de adoptar la estrategia de adoptar modelos estandarizados para una industria o negocio específico, se deben tomar acciones para mitigar el riesgo de que, debido al tamaño y la complejidad que muchas veces tienen estos modelos, los proyectos SOA se vean inesperadamente impactados en su avance. La adopción de esta estrategia es una apuesta al largo plazo, que fácilmente puede poner en peligro un proyecto con plazos y presupuesto limitados, y que tenga un acercamiento ingenuo en torno al esfuerzo que implica adoptar estos modelos.

Referencias:
SOA Governance: Achieving and Sustaining Business and IT Agility

Distribución e integración del desarrollo

Al igual que en otras disciplinas, es usual distribuir la construcción de un software de gran escala en múltiples equipos. Esta práctica permite desarrollar en paralelo sus distintos módulos, reduciendo potencialmente los tiempos para su entrega.

En algún momento del desarrollo, los distintos módulos deben ser integrados. Es entonces cuando múltiples problemas pueden surgir y crear atrasos no planificados. Esta situación puede tornarse gravísima dependiendo de los errores que se hayan cometido al momento de concebir la separación de los desarrollos, y de las incompatibilidades que se vayan introduciendo en cada uno. En el extremo, un desarrollo desagregado en distintos equipos, donde no se realizó tempranamente un diseño adecuado de cómo integrar lo producido por cada equipo, puede fracasar exclusivamente por la imposibilidad de conectar todas sus piezas dentro de los tiempos comprometidos.

En consecuencia, un artefacto irrenunciable en un desarrollo que busque obtener los beneficios del trabajo en paralelo, es un adecuado plan de integración. Este plan debe ser creado en etapas muy tempranas del proyecto y elaborado de forma progresiva, considerando que: (i) sólo tras la definición de la arquitectura del sistema, se contará con la información técnica que permita tomar decisiones adecuadas respecto a la asignación de tareas, y (ii) los eventos que ocurran durante la construcción pueden forzar a cambios de estrategia en cualquier etapa.

El diseño de integración de los productos de trabajo es un artefacto clave para la adecuada distribución del desarrollo. Este diseño es responsabilidad de los arquitectos, los cuales junto con concebir la estructura y el comportamiento de las interfaces que permitirán integrar los distintos componentes, deben ser capaces de entregar sugerencias que permitan identificar el esquema óptimo de distribución de trabajo a los tomadores de decisiones.

Lamentablemente, esto no es suficiente para mitigar completamente los riesgos de retrasos por integración, ya que muchas veces las decisiones de arquitectura son mal interpretadas o socavadas involuntariamente. Es por esto que el diseño de integración debe ser tomado rápidamente como entrada para la creación e implementación de planes de pruebas, que permitan verificar continuamente la ausencia de incompatibilidades entre los módulos en desarrollo.

Para las pruebas de integración, el nivel de automatización es directamente proporcional a la mitigación de los riesgos. En todo momento se debe evitar las pruebas manuales de las integraciones, pues esto atenta contra su ejecución continuada.

Todo lo anterior se resume en una fuerte sugerencia para los desarrollos de gran escala: Concebir y mantener siempre un plan de integración, que esté respaldado por un diseño arquitectónico de integración detallado, y resguardado por un plan de pruebas, implementado de manera que maximice la automatización y frecuencia de su ejecución.

Reduciendo riesgos de malos tiempos de respuesta en SOA con XTP

Adoptar una arquitectura orientada a servicios (SOA) para el desarrollo de una aplicación conlleva el riesgo de tiempos de respuesta inadecuados. Esto debido principalmente a que los estándares que se utilizan para la construcción de este tipo de aplicaciones hacen uso intensivo del lenguaje XML, el cual por ser basado en texto requiere mayores recursos de procesamiento.

Existen varias formas de mitigar este riesgo, pero quisiera mencionar una notablemente efectiva: la construcción de servicios utilizando tecnologías de procesamiento extremo de transacciones (XTP).

Este tipo de tecnologías, del cual el producto Oracle Coherence es un ejemplo, permiten que los servicios no requieran ir necesariamente a una base de datos cuando tengan que guardar u obtener información, ya que utilizan la memoria de múltiples servidores como un gran caché de objetos distribuido y robusto sobre el cual los servicios pueden trabajar en vez de con la base de datos. Este caché tiene la inteligencia necesaria para guardar la información en las bases de datos anacrónicamente si así se desea.

Al trabajar con memoria, en vez de ir a buscar información a los dispositivos clásicos de almacenamiento (discos duros, SANs, etc.), los tiempos de respuesta aumentan en orden de magnitud.

A los CIOs o gerentes de desarrollo que estén embarcándose en nuevos proyectos, con altos requerimientos de desempeño, y donde SOA no sólo vaya a usarse para integrar legacys, sino que para construir activos reutilizables, definitivamente recomiendo al menos leer el resumen de las capacidades de productos como Oracle Coherence. A los arquitectos de software, recomiendo estudiar el patrón Service Grid, el cual aclara cómo técnicamente la construcción de los servicios puede hacerse para aprovechar estas tecnologías.

 Fuentes
 

Información util para presupuestar el gasto en TI

Estimar nunca es una tarea fácil, por lo que tener información de referencia basada en la industria siempre resulta útil. La siguiente distribución del gasto en TI se ha encontrado que aplica, en términos generales, para las grandes compañías.

• Para manufactura, educación, legal y transporte, las compañías tienden, en promedio, a gastar entre el 2% al 3% de sus ganancias anuales brutas en el presupuesto anual de TI.
•  Para operaciones basadas en servicios y operaciones (publicación, compañías de reservas, hoteles, establecimientos corporativos promedio, etc.) las compañías tienden, en promedio, a gastar entre el 3% al 6% de sus ganancias anuales brutas en el presupuesto anual de TI.
• Para operaciones intensivas en información (bancos, bolsa, seguros, tarjetas de crédito, etc.), las compañías tienden, en promedio, a gastar entre el 6% y el 10% de sus ganancias anuales brutas en el presupuesto anual de TI.

Además, para una firma típica, aproximadamente el 40% del presupuesto de TI es para costos de operaciones y el 60% para el desarrollo de nuevas aplicaciones.

Del presupuesto para aplicaciones, para muchas firmas el 20% o menos es utilizado para venta interna o relaciones con los usuarios de negocios.

Del presupuesto de operaciones, entre el 27% y el 33% (en promedio el 30%) tiende a ser para personal, entre 21% y 25% (en promedio el 23%) es para equipamiento (estas son figuras basadas en una amortización anual), entre el 15% y el 19% (17% promedio) para licencias de software, 10-14% (12% promedio) en comunicaciones, 10-16% (13% promedio) para servicios de soporte externo (sin incluir carriers), 4-6% (5% en promedio) para instalaciones (p.e. centros de datos, sitios de respaldo, oficinas, etc.) y misceláneos.

El 12% destinado a comunicaciones se divide generalmente de la siguiente manera: entre el 83-87% (85% promedio) en servicios de voz, 13-17% (15% en promedio) en servicios de datos e internet.

Fuente:

Redimensionamiento de la partición raíz en LVM para ampliar el swap

En Oracle Enterprise Linux (y probablemente RH), la instalación por omisión del LVM utiliza todo el espacio de almacenamiento disponible, no dejando extents libres para ampliar las particiones. Esto es un problema cuando se quiere instalar la base de datos Oracle y se encuentra que el espacio de swap no es suficiente. (La instalación de la infraestructura de grid para un cluster y Oracle RAC de la 11gR2 requiere un mínimo de 2.5 GB en RAM e igual espacio en swap)
 Para redimensionar la partición raíz y dejar más espacio para ampliar la de swap se debe hacer lo siguiente:

• Arrancar el sistema desde el primer cd de instalación del OEL
• Iniciar el sistema operativo en modo de rescate (o sea, poniendo linux rescue en las opciones de arranque)
• No montar los sistemas de archivos
• Asumiendo un disco de 20 gigas, el que se quiere reducir a 17.5, ingresar los siguientes comandos

# lvm vgchange -a y
# e2fsck -f /dev/VolGroup00/LogVol00
# resize2fs -f /dev/VolGroup00/LogVol00 17.5G
# lvm lvreduce -L17.5G /dev/VolGroup00/LogVol00

Una vez realizado esto, es posible ampliar el swap (en este ejemplo, a 2.5GB y asumiendo que el swap se encuentra en el LogVol01):

# swapoff -v /dev/VolGroup00/LogVol01
# lvm lvresize /dev/VolGroup00/LogVol01 -L 2.5G
# mkswap /dev/VolGroup00/LogVol01
# swapon -va

Esto se probó en OEL Relase 5 Update 4.

Fuentes:
http://www.linuxquestions.org/questions/fedora-35/how-to-resize-root-lvm-logical-volume-337823/
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/s1-swap-adding.html