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:
Referencias:
No hay comentarios.:
Publicar un comentario