Consideraciones para la realización de pruebas de escalabilidad

Las pruebas de escalabilidad se utilizan para determinar si la aplicación permite acomodar a un número creciente de usuarios mediante la adición de hardware, sin tener que modificar el software. Durante su ejecución, no se busca realmente obtener cifras acerca de cuantos usuarios pueden subirse a la plataforma, sino que establecer un patrón de escalabilidad para el sistema. Esta información permite determinar el número de usuarios que pueden ser soportados, con un desempeño aceptable, para un entorno definido.

Los números obtenidos de una prueba de desempeño sólo son relevantes para un sistema específico, en un ambiente específico. Esto implica que los benchmarks que se obtienen de la industria no son más que una referencia, que inexcusablemente debe ser complementada con actividades de la propia organización para reducir el riesgo de salir a producción con niveles de servicio deficientes. 

En un sistema ideal, el desempeño no debiera degradarse a medida que se agregan usuarios, sino que debiera mantenerse constante hasta que la máquina se sature, punto en el cual se debiera apreciar una fuerte degradación del desempeño. Los gráficos de tiempos promedio de respuesta versus usuarios trabajando debieran mostrar una forma que se denomina “palo de hockey”.

La realidad, como siempre, es algo menos ideal, y lo que generalmente se encuentra es una figura como la siguiente:

En la figura se aprecia una leve pendiente, que implica que el sistema se está degradando a una tasa que puede ser aceptable o no dependiendo de la organización. En sistemas intensivos en utilización de recursos compartidos, la leve pendiente se podría ser, por ejemplo, una consecuencia de la contención de recursos que se pueda estar originando al llegar nuevos usuarios. 

Definición de escenarios para pruebas de escalabilidad
Los pasos para desarrollar una prueba de escalabilidad son los siguientes:

1. Definir un escenario realista 
2. Grabar el escenario 
3. Correr el escenario para simular usuarios concurrentes, simulando cada vez más usuarios 
4. Cuando el desempeño se degrada a tal punto que no permite usar aceptablemente el sistema, se ha encontrado el máximo número de usuarios. 

Para la definición del escenario, se deben tener las siguientes consideraciones:

• No se trata de una prueba funcional, por lo que se debe trabajar con escenarios de probable uso frecuente en producción y no en función de escenarios que constituyan condiciones de borde. 
• Sin embargo, los escenarios deben ser diversos, no deben acotarse por ejemplo siempre a una operación de consulta, sino que deben simularse múltiples casuísticas de ingreso, borrado, consulta, navegación, etc. 
• Se debe establecer un tiempo de respuesta promedio aceptable. Se recomienda que este tiempo se establezca en función del tiempo que se demora en ejecutare el escenario para un solo usuario. Por ejemplo, si para un sistema X, se ejecuta el escenario de prueba con solo un usuario y da como resultado un tiempo medio de respuesta de 300 ms, podría definirse el tiempo de respuesta promedio aceptable para una ejecución con múltiples usuarios como el doble, 600 ms. 

Escenarios de pruebas de memoria restringida
Las pruebas de memoria restringida se utilizan para determinar la cantidad de memoria consumida por usuario. Se realiza forzando a la memoria a ser un cuello de botella mediante su saturación. De esta manera, cuando el servidor se satura, se sabe que la causa es la memoria. Para realizar este tipo de pruebas, se debe contar con un poder de procesamiento sustancialmente mayor a la memoria disponible.

A modo de ejemplo, si corriendo el sistema con 4 CPUs (asumiendo que esto sobra) y 1 GB de RAM, se satura con 50 usuarios, el consumo medio de memoria por usuario se puede establecer en 20,48 MB/usuario. 

Escenarios de pruebas de CPU restringida
La segunda prueba que se puede hacer es para determinar cuantos usuarios por CPU pueden atenderse. Para esto se realiza la prueba con las condiciones revertidas: mucha RAM y poco CPU.

A modo de ejemplo, si corriendo el sistema con 1 CPU y 4 GB en RAM (sobre la base que esta sobra para lo que se desea realizar), el sistema colapsa a los 50 usuarios, se puede concluir que el sistema puede atender 50 usuarios por CPU. 

Ejecución de escenarios para pruebas de escalabilidad
Para la ejecución de los escenarios se deben tener en cuenta las siguientes consideraciones:

• Los escenarios se deben correr sobre condiciones que simulen la realidad. Aunque esto suene obvio, muchas veces se comete el error de simular la realidad sólo a nivel de infraestructura y middleware, y no se consideran otros factores como el estado probable del sistema tras el paso del tiempo. Por ejemplo, no se deben correr pruebas de escalabilidad sobre una base de datos vacía, sino que esta debe tener datos que simulen el volumen que tendrá la base de datos productiva dentro de uno o más años. 

• Para aplicaciones que serán accedidas de la Internet (o desde cualquier sistema cuyo ancho de banda disponible no puede ser establecido a priori), la demora que introduce el ancho de banda debe ser eliminada del análisis. Es un error realizar pruebas de escalabilidad (y de desempeño en general) a través de la internet (a menos que expresamente se quiera medir este efecto), ya que la distorsión introducida por la transmisión de paquetes TCP/IP no permitirá razonara adecuadamente sobre las demás características del sistema. 

• Se debe tener un adecuado dimensionamiento de los clientes desde los que se generarán las solicitudes. Si se disparan todas las solicitudes de una misma máquina, por ejemplo, la maquina cliente podría degradarse, en vez del servidor, arrojando resultados erróneos en la prueba. No es recomendable realizar estas pruebas sin simuladores automatizados de carga que puedan ser desplegados en una topología distribuida. 

• Los límites de escalabilidad deben ser establecidos sólo en función de escenarios que saturen a los servidores. Es un error pensar que por ejemplo, si el sistema sin estar saturado arroja un consumo de 4 GB de RAM cuando hay solo 10 usuarios concurrentes, se puede concluir que el sistema requiere de 102,4 MB/usuario. Esta conclusión es errónea y engañadora, pues no considera que: 
• El consumo podría deberse a reservas o gestión de la memoria que hace el middleware o la infraestructura anticipándose a una potencial demanda. 
• Que tanto el middleware como la infraestructura puede tener mecanismos avanzados de compartición de recursos, y que gracias a esto podrían soportar mucho más que lo que sugeriría una proyección lineal. 
• Siguiendo con el ejemplo, si este mismo sistema se saturarse a los 50 usuarios, el consumo real arrojado sería 20,48 MB/usuario, 5 veces más de lo que arrojó la medición parcial en estado de no saturación. 

• Los escenarios deben ser ejecutados simulando el comportamiento real de los usuarios. Las herramientas de automatización permiten que los escenarios grabados sean ejecutados a una velocidad mayor, y en muchas ocasiones los escenarios se corren casi sin pausas entre las acciones, para simular una alta demanda. Esta simulación de alta demanda es en realidad un error, pues no existen en la realidad usuarios (humanos) que no hagan pausas mientras ejecutan las distintas acciones del escenario (lo que técnicamente se le llama think time). Omitir artificialmente el think time, no solo fuerza al sistema a trabajar más de la cuenta en situaciones irreales, sino que dificulta razonar adecuadamente en torno a los usuarios que realmente fueron atendidos. 100 usuarios concurrentes no significa 100 usuarios demandando al sistema al mismo tiempo, sino que 100 usuarios trabajando de manera tal que envían solicitudes al sistema que muy probablemente llegarán en distintos instantes de tiempo.

Fuente:

• Guías de planificación de capacidad para productos de Middleware Oracle

Razones por las que no es aconsejable realizar estimaciones de puntos de función en proyectos de gran escala

Algún tiempo atrás, un cliente  me solicitó realizar contar los puntos de función (PF) para un proyecto de gran envergadura. Debido a que ya he realizado este tipo de estimaciones varias veces, intuí que lo que me estaban pidiendo no era factible.

En vez de iniciar la cuenta de manera similar a como lo había hecho en otros proyectos (siguiendo principalmente los lineamientos del manual gratuito de Longstreet Consulting), comencé a estimar el esfuerzo asociado a la estimación en sí, que preliminarmente resultó de un par de meses de dedicación exclusiva.

En este artículo explicaré cómo logre de todos modos aproximar el tamaño en puntos de función para el proyecto, las razones que me llevaron a anticipar que realizar una cuenta de la forma tradicional no era posible, para terminar explicando por qué no es aconsejable realizar una cuenta de puntos de función para proyectos de gran envergadura.

En primer lugar, lograr una aproximación (que necesariamente incorpora un error, pero que de todos modos resulta aceptable) de un proyecto en puntos de función es extremadamente fácil utilizando una técnica que se llama backfiring. La técnica del backfiring se sustenta en que hay miles de instituciones que han entregado a instituciones, como la Software Productivity Research, sus cuentas de puntos de función y el tamaño en líneas de código de sus proyectos. Esto ha permitido establecer un “promedio industrial de líneas de código en un lenguaje X necesario para producir 1 punto de función”. La Software Productivity Research publica año a año una tabla con tasas de conversión para más de 700 lenguajes y dialectos de programación.

En el caso de Java, este número mágico es 53. Es decir, se requieren 53 líneas de código Java, con toda su documentación y artefactos asociados (casos de uso, análisis, diseño, pruebas, matrices de trazabilidad, javadoc, y un largo etc.), para producir el equivalente a un punto de función.

Con esto, la estimación es sencilla: Se cuentan las líneas de código en Java, y se dividen por 53, y se obtiene la aproximación a PF.

Dado esto, considerando que el proyecto para el cual se me pidió la estimación tiene 1.119.124 LOCs al día de hoy, su cuenta en puntos de función es de aproximadamente 21.115,5 PFs.

(El proyecto que menciono, probablemente tenga un tamaño en PFs mayor al mencionado, debido a que si bien la mayor parte está construida en Java, hay una parte considerable – que estimo sobre el 30% – que está construida en base a otros lenguajes que no consideré para el estudio.)

Obviamente, el backfiring tiene una limitación severa (además de su falta de precisión): El software al que se le quiere estimar el tamaño en PFs debe tener un tamaño en LOCs conocido para poder aplicarlo, lo que no obviamente no está disponible si uno estimando un software a construir en el futuro. Es por eso que su uso principal es en actividades de benchmarking, y no de estimación. Sin embargo, cabe destacar que también puede ser utilizado con un buen grado de precisión para estimar el esfuerzo de modificaciones de software de tamaño inferior a 15 PFs.

Para entender por qué supe que la cuenta que me estaban pidiendo no era factible de realizar, consideren que un equipo auto-organizado, siguiendo metodologías ágiles tiene una productividad promedio de 15 PFs por miembro al mes. Para equipos donde todos son expertos, esto puede llegar a 20 PFs por miembro al mes, y cuando son novatos, puede bajar a 10 PFs por miembro al mes.

Si tomamos el promedio (15 PF), y asumimos una metodología ágil (en particular SCRUM, complementado con cualquier técnica ágil con excepción de pair programming), un equipo de 5 personas tendrá una productividad mensual de 75 PFs, y una anual de 900 al año, lo que cae en el rango de los proyectos pequeños.

Considerando que en Chile el sueldo promedio de un Ingeniero Civil en Informática con 5 años de experiencia es de $1,532.210, es decir, al dólar de hoy U$3.167,7, el costo de un punto de función es en promedio de $102.147 pesos, o U$211 aprox. Por lo que el proyecto pequeño del que hablo, costaría aproximadamente $91.932.300, o U$189.900

Si comparamos los $189.900 de este proyecto pequeño y ficticio, con los más de U$24.000.000 del proyecto grande y real para el cual se me pidió la estimación (haciendo la abstracción no menor del markup de las empresas proveedoras), no parece irracional asumir que realizar una cuenta de PFs para este proyecto es un desafío mayor e involucrará un consumo de recursos probablemente difícil de justificar.

 Pero ¿Por qué generalizar a que no se deben hacer cuentas de PFs para proyectos de gran envergadura (más de 10.000 PFs)? (a menos que obviamente hayan razones informadas para hacerlo)

Consideren lo siguiente:

1. Un experto en contar PFs es capaz de contar entre 400 y 600 por día
2. La tasa promedio del mercado (al año 2010) para las firmas especializadas en contar PFs era de U$3000 al día (en USA), lo que lleva a un costo entre U$5 y U$7 por cada PF contado.

Con estos antecedentes, y a modo de ejemplo, se deduce que contar los puntos de función para el proyecto que estaba analizando habría tenido un costo de U$105.577,5 y U$147.808,5 (considerando el dólar de hoy a $483,7 pesos chilenos por dólar, sólo contar los PFs habría salido entre $51.067.836,75 y $71.494.971).

El esfuerzo asociado a la actividad de contarlos además habría oscilado entre los 35 y lo 53 días – persona.

Generalizando, se puede afirmar que, tomando un costo promedio de U$6 por PF, un proyecto de más de 10.000 PFs costará inmediatamente U$60,000 más si se cuentan sus puntos de función.
A lo anterior, se debe agregar que si los requerimientos no están aceptablemente completos y correctamente levantados, la estimación tendrá fuertes retrasos y errores.

Esto lleva a la siguiente conclusión: Si bien teóricamente, es posible estimar los puntos de función de cualquier proyecto, en la práctica para proyectos grandes, los costos, tiempo y riesgo involucrados se elevan tanto que esta actividad se vuelve difícil de justificar.

Es por esto que en la práctica, los puntos de función se utilizan para proyectos de un tamaño proyectado inferior a los U$5.000, y la mayoría de las veces para proyectos pequeños de menos de U$1.000.

Pero, si entonces los proyectos de gran escala (más de 10.000 PFs) no se pueden estimar de manera económicamente conveniente usando puntos de función, ¿Existe una forma de hacerlo?

La respuesta es sí, y la forma es la siguiente…

(Fin a lo Matrix Reloaded)

Referencias:

• Software Productivity Research
• ISBSG
• www.mifuturo.cl 
• Banco Central de Chile 
• Longstreet Consulting Inc. 
• Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies

Problemas en la adopción de SOA: Transición inadecuada de roles

Un error común al incorporar SOA en una organización, es no sopesar adecuadamente lo que implica esta transición a nivel de las competencias técnicas y conceptuales de su personal; usualmente, las organizaciones simplemente ponen la palabra “SOA” al lado derecho del actual rol cumplido por la persona.  Por ejemplo, un “analista” pasa a ser “analista SOA”, un “arquitecto” pasa a ser “arquitecto SOA”, etc. Se asume una transición transparente y oportuna, subestimando fuertemente el esfuerzo, tiempo y conocimientos requeridos para ser competente en cada uno de estos nuevos roles.

 A modo de ejemplo, un arquitecto especialista en sistemas de arquitecturas tradicionales, va a requerir de mucho tiempo y esfuerzo para poder hacer la transición a sistemas orientados a servicios, debido a cambios en: (i) el tipo y cantidad de tecnologías nuevas involucradas, (ii) el tipo de abstracción con el que se  trabaja, (iii) los principios y fundamentos conceptuales que norman la construcción de aplicaciones.

Respecto al primer punto, se debe considerar que los estándares creados para la construcción de aplicaciones durante la primera y sobre todo durante la segunda generación en SOA son muchos. Si en la primera generación de SOA, bastaba con saber WSDL, SOAP, XSD/XML  y opcionalmente UDDI, en la segunda generación aparece un conjunto relevante de estándares WS-* (que hoy superan los 20). Además, en ambientes donde se requiere de interoperar con múltiples entidades externas, el conocer los perfiles WS-I es altamente recomendable.

Si bien no se requiere que un arquitecto conozca en detalle cada uno de los estándares SOA, debe conocer lo suficiente como para poder razonar a nivel arquitectónico en torno a ellos (por lo menos en torno a los más usados, como WS-BPEL, WS-Policy, WS-Security, etc.). La carencia de estos conocimientos probablemente lleve a una subutilización del middleware que se adquiera para la iniciativa SOA, o a la implementación redundante de mecanismos ya abordados por las especificaciones. Personalmente, me ha tocado ver varias implementaciones pobres y redundantes de funcionalidades ya provistas por componentes de middleware.

Una segunda arista de este problema es que el arquitecto debe conocer las características de varios  componentes de middleware que generalmente se asocian a las implementaciones de SOA, como por ejemplo: buses de servicios, motores de reglas, motores de orquestación, gestores de políticas de servicios Web, registros de servicios, etc. Este conocimiento no sólo es necesario para el adecuado uso de las piezas de middleware, también se necesita para proteger a la organización del constante bombardeo publicitario que los grandes productores de software han montado en torno a ellos, y que lleva a gran cantidad de organizaciones a comprar productos que no necesitan.

Respecto al segundo punto, los cambios también son relevantes: El arquitecto debe adquirir conocimientos que le permitan identificar servicios que tengan relevancia y trazabilidad a nivel de negocio, lo que implica un mayor conocimiento e internalización de los objetivos y guías centrales del negocio de la organización. Además, las implementaciones SOA modernas generalmente buscan la automatización de procesos de negocio, y no se limitan a soportar tareas puntuales, requiriendo que el arquitecto entienda estos procesos y sepa plasmarlos en el sistema mediante orquestaciones y coreografías de servicios.

Por último, el tercer punto es el que, en mi opinión, lleva de manera más subrepticia al fracaso de la iniciativa SOA en el logro de sus objetivos de mediano y largo plazo. La internalización de los principios y conceptos asociados a SOA es un proceso de lenta maduración, y es clave para que los sistemas manifiesten los atributos de calidad derivados del paradigma arquitectónico. Los saltos dados de una organización al paradigma SOA, sin una adecuada transición de sus arquitectos, pueden llevar a una proliferación de sistemas que: (i) usen tecnología (middleware y estándares) SOA y (ii) estén adecuadamente alineados con los objetivos del negocio, pero (iii) que se hayan concebido sólo en base a principios de otros paradigmas (orientación a objetos, a eventos, funcional, etc.). El desempeño de los sistemas así concebidos probablemente será peor al de su contraparte más simple, y no necesariamente manifestará las características deseables de un sistema orientado a servicios, lo que inevitablemente levantará cuestionamientos acerca de por qué se optó por una arquitectura tan compleja, cuando existía una forma más sencilla de hacer las cosas.

Referencias:

• SOA Governance: Achieving and Sustaining Business and IT Agility
• SOA Principles of Service Design
• Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services (The Prentice Hall Service-Oriented Computing Series from Thomas Erl)

Problemas y desafíos de la arquitectura de software

Las siguientes figuras son obtenidas de fuentes de prestigio y reconocimiento en la industria TI, y evidencian un problema general dentro de la industria del desarrollo de software:

Arquitectura de la aplicación Java EE PetStore

Fuente: Originalmente de http://sun.java.com, pero obtenida de www.theserverside.com

Arquitectura de servidor de mensajería Sun Java CommunicationSuite

Fuente: http://www.oracle.com
 

Arquitectura del Microframework .Net

Fuente: http://msdn.microsoft.com

La documentación de los sistemas de software generalmente incluyen una sección denominada “arquitectura del sistema”, la cual presenta una serie de diagramas similares a los expuestos.

Si bien a primera vista estos diagramas parecieran ser una buena guía para entender el sistema, una observación más cuidadosa permite constatar que todos ellos se caracterizan por:

·         la utilización de texto descriptivo y la utilización de diagramas de cajas y líneas

·         tener muy baja precisión, y ser más bien informales.

·         apelar a la intuición y pericia técnica del lector.

El uso de estos diagramas, hacen que en general la arquitectura de software sea considerado por muchos una “vista de alto nivel” del sistema, muchas veces abstracta e inherentemente imprecisa. Esto hace que las definiciones de  arquitectura sean sólo un punto de partida, y estén muy lejos de cumplir el rol de su análogo en la industria de la construcción.

De ahí que la ya no tan incipiente disciplina de arquitectura de software, tenga como sus grandes desafíos establecer los lineamientos teóricos y prácticos para que la arquitectura de software sea utilizada como un artefacto de ingeniería, basada en principios claros y no en definiciones ad-hoc, capaz de contribuir a (i) la comunicación entre las diferentes partes involucradas y (ii) la reducción del riesgo en el desarrollo mediante la captura precisa de las principales decisiones técnicas.

Otro gran desafío de la disciplina es la de permitir la construcción de sistemas con una base arquitectónica sólida e intelectualmente manejable. Como objetivos relacionados, se busca que los sistemas:

·         Puedan ser construidos en función de una composición de partes

·         Adhieran a la arquitectura definida para su construcción, manifestando en consecuencia las propiedades deseadas para ellos.

·         Utilicen crecientes grados de arquitecturas de integración estándares

·         Sean documentados de manera que la organización que los crea pueda reutilizar el conocimiento arquitectónico

·         Reducir los costos de producción de sistemas a gran escala mediante la definición de líneas de productos.

Fuentes:

• Notas del Curso de Arquitectura de Software, dictado por los Profesores David Garlan y Anthony Lattanze, en el programa de Master en Ingeniería de Software de la Universidad de Carnegie Mellon.
• www.theserverside.com
• www.oracle.com
• msdn.microsoft.com

Exploraciones de factibilidad técnica para SOA: consideraciones metodológicas.

La mayoría de las organizaciones, en sus etapas tempranas de adopción de SOA, se ven en la necesidad de tomar decisiones que determinarán de manera crítica el curso que seguirá la iniciativa en el futuro. Muchas de las decisiones a nivel de arquitectura tomadas durante esta etapa, conllevan el riesgo de imponer fuertes penalidades en caso de ser incorrectas. Es aquí donde se produce la mayor cantidad de errores tales como: adquisiciones innecesarias, lock in innecesario con proveedores de tecnología, elaboración de arquitecturas demasiado complejas para la realidad organizacional, incorporación de metodologías incorrectas y formación de estructuras organizacionales erróneas e ineficaces.

La mitigación de estos riesgos requiere de muchos elementos. Uno que me interesa mencionar tiene relación con el post previo respecto a la realización de las pruebas de factibilidad técnica: La adecuada planificación y realización de ellas puede tener beneficios extra en cuanto a la reducción del riesgo de cometer uno o más de los errores mencionados (y otros no mencionados). En particular, la selección de un escenario pequeño, pero que tenga funcionalidad que permita cubrir de punta a punta de todas las capas del stack de solución SOA, tiene la virtud de permitir a las organizaciones obtener información suficiente para recalibrar el alcance y complejidad de su iniciativa SOA, en caso de ser necesario.

Sin embargo, el éxito las pruebas será fuertemente afectado por las metodologías utilizadas para su desarrollo. En este aspecto, resulta ideal que el equipo a cargo de ellas tenga adecuadamente internalizados los cambios metodológicos a nivel de desarrollo que se desprenden del cambio de paradigma. A modo de ejemplo, si una organización tradicionalmente a usado el Proceso de Desarrollo Rational (RUP) para desarrollo de aplicaciones multicapas, el equipo de pruebas de factibilidad técnica debiera estar familiarizado, por ejemplo, con su extensión SOMA (Service Oriented Modeling and Architecture) para desarrollar aplicaciones SOA (incluso a nivel de notación, el equipo a cargo de las pruebas debiera conocer el perfil de UML soaML).

Si el equipo cuenta el conocimiento de metodologías “actualizadas” para el desarrollo en SOA, se pueden aprovechar estos ejercicios de factibilidad técnica para revisar que tan idónea es la metodología de desarrollo seleccionada, y realizar correcciones antes de institucionalizarla para desarrollos de mayor escala. Sin embargo, esto se debe hacer con sumo cuidado, ya que una “sobrecarga metodológica” podría poner en riesgo los objetivos principales de las pruebas de factibilidad técnica.

En caso de que el equipo no cuente con los conocimientos metodológicos adecuados, se está frente a un problema que podría poner en riesgo el éxito de las pruebas, situación que debe ser remediada incluso antes de iniciarlas.

Referencias:

1. SOA Governance: Achieving and Sustaining Business and IT Agility
2. Service-oriented modeling and architecture: How to identify, specify, and realize services for your SOA
3. Service oriented architecture Modeling Language (SoaML)

Instalación de Websphere en Ubuntu atascada en el script importConfigArchive

Debido a que Ubuntu tiene enlazado el shell sh a /bin/dash, en vez de a /bin/bash, la instalación del servidor de aplicaciones Websphere se queda atascada al ejecutar el script importConfigArchive durante la creación de un perfil.

Esto se puede corregir de la siguiente manera:

sudo -i
cd /bin
unlink sh
ln -s /bin/bash sh

Una vez ejecutados estos comandos, la instalación y posterior creación del perfil concluyen sin problemas.
Aunque obviamente no es recomendable reenlazar scripts provistos por el sistema operativo, no he visto efectos secundarios.
Esto se probó en Ubuntu 11.10 para un servidor Websphere 8.x

Fuentes:
http://www.pingudownunder.com/2009/09/10/getting-websphere-application-7-installed-on-ubuntu-9-04/

Exploraciones de factibilidad técnica al comienzo de una iniciativa SOA

Para mitigar los riesgos inherentes a un cambio de paradigma, y sobretodo uno como SOA que podría tener un impacto en toda la organización, resulta altamente recomendable realizar una exploración de factibilidad técnica las durante fases tempranas de la iniciativa. Esta es una práctica generalmente realizada cuando la tecnología es poco conocida o no se ha probado previamente, y existe un grado de complejidad que no permite incorporarla en un plan de proyecto sobre la base de conjeturas o analogías.

Las exploraciones de factibilidad técnica generalmente se materializan a través de una serie de pruebas de conceptos. Estas exploraciones debieran ser identificadas y acotadas en su alcance durante las fases iniciales del proyecto, ejecutadas, para luego utilizar sus salidas y resultados para obtener un adecuado conocimiento de la complejidad tecnológica, las complicaciones de implementar un servicio en ella y para refinar las decisiones de arquitectura y diseño. Este entendimiento extra es un gran apoyo para la adecuada asignación de recursos (tiempo, personal, pericia) conmensurable a la complejidad de la implementación de servicios.

En mi experiencia, si la organización tiene como política externalizar el desarrollo de sus aplicaciones, entonces resulta altamente conveniente externalizar la realización de estas pruebas de concepto, solicitando a potenciales proveedores que realicen ejercicios en la tecnología dada, o muestren implementaciones echas por ellos donde se demuestre que han utilizado exitosamente la tecnología. La razón detrás de esto, es que muchas veces las empresas desarrolladoras presentan propuestas donde aseguran contar con los conocimientos necesarios para realizar el proyecto, pero una vez adjudicado, se evidencian severas faltas de pericia en herramientas claves, lo que puede ser agravado por la indisponibilidad de expertos reales en el país e incluso en el continente.

Independiente de si el desarrollo es interno o externalizado, un enfoque que parece ser altamente efectivo en la reducción de riesgos es la utilización de las fases del Proceso Unificado Rational (RUP) de IBM, donde en su fase de elaboración (en la que aún no se invierte más del 30% del presupuesto), se implementan uno o más requerimientos que aseguren que todas las decisiones tecnológicas son factibles. Cualquier problema detectado en esta actividad, que pueden ir desde la detección de la falta de competencias técnicas en el personal disponible hasta incompatibilidades entre los productos de middleware escogidos (incluso si son de un mismo proveedor), implica una alerta roja que debe llevar a una reflexión sobre la conveniencia de continuar el proyecto en esas condiciones, o realizar cambios a los planes y la estrategia de desarrollo.

Referencias:

SOA Governance: Achieving and Sustaining Business and IT Agility