Líneas de comentarios: Peores prácticas de transformación de servicios bancarios básicos y otras historias aterradoras

Cuando ningún proyecto TI grande está seguro

Como pueden dar fe muchos arquitectos, hay muchas historias aterradoras en la búsqueda de arquitecturas de soluciones objetivo. A veces, estas situaciones ocurren debido a falta de experiencia, peto también ocurren como resultado de no aplicar una sólida perspectiva arquitectónica a cierta situación. Este artículo analiza una cantidad de escenarios reales y sus resoluciones relacionadas con la esperanza de evitar percances similares. This content is part of the IBM WebSphere Developer Technical Journal.

Scott Simmons, Executive IT Architect, IBM  

Scott Simmonses el Lead Banking Solutions Architect para el Worldwide Banking Center of Excellence de IBM. Antes de trabajar en el Banking Center of Excellence, Scott fue Lead Architect del equipo Worldwide SOA Technical Architecture y jefe técnico de más de 50 arquitectos SOA de IBM en todo el mundo. Scott es Senior IT Architect Certificado por IBM y también Master IT Architect para Open Group. Se especializa en el diseño, desarrollo e implementación de arquitecturas SOA para clientes y socios y también es SOA Solution Designer Certificado. Publicó en muchos periódicos, entre ellos WebSphere Developer Technical Journal, Web Services Journal y WebSphere Journal. Antes de trabajar para IBM, fue arquitecto responsable de la Chief Technology Office de Peregrine/Extricity como director de Soluciones de Tecnología. Scott tiene amplia experiencia en arquitectura de integración y mensajes, como así también de diseño/implementación de arquitectura de datos mediante el empleo con Vitria, Illustra/Informix y Sybase.



03-08-2011

Era una oscura y tormentosa reunión de diseño...

Cuando era niño, me gustaban mucho las películas de terror comoLa criatura de la Laguna NegrayLa mancha. Incluso ahora me atraen estas historias de terror, aunque nunca imaginé que me encontraría con algo remotamente tan aterrador en la vida real.

Bien, en mi rol como arquitecto de soluciones para el®WorldwideBanking Center of Excellence de IBM, he sido testigo de una situación de un cliente ocasional que podría congelar a un arquitecto hasta la médula. Quiero compartir con ustedes algunas de las cosas más aterradoras (e increíbles) con las que me he encontrado mientras ayudaba a los bancos a desarrollar estrategias centrales de modernización bancaria. No hablo de fantasmas, duendes u otras criaturas, sino de algo mucho más aterrador porque existe en realidad:las peores prácticas.

Las declaraciones reales que comparto con ustedes a continuación son prueba de que hay cosas malas que acechan en las sombras de algunas organizaciones. Mi objetivo es sacar estas cosas malas de sus oscuros escondites y levarlas a la luz para ayudarlos a identificar si hay demonios similares a punto de crear caos cerca de ustedes.


Yendo a la luz

  • Caso:"Podemos documentar los requisitos no funcionales más tarde; ahora concentrémonos solo en el diseño funcional."

    Durante una reunión de diseño de una solución de banca por Internet, un arquitecto del Banco A manifestó la inquietud de que su inicio de sesión de usuarios finales requería más de 25 saltos individuales para autenticar el acceso para clientes externos. El arquitecto expresó inquietudes sobre rendimiento y disponibilidad. Un miembro central del equipo de seguridad de TI del banco respondió que la arquitectura de seguridad estaba fija y que los arquitectos del proyecto debían"dejarle la seguridad a los expertos”y"solo concentrarse en el diseño funcional”.

    Por qué es tan aterrador:

    El dilema clave es que las decisiones arquitectónicas de los aspectos funcionales y no funcionales (inclusive la seguridad) deben ser analizados a principios del proyecto, y proyecto por proyecto. Como parte del diseño de la solución, los arquitectos deben concentrarse en todos los aspectos no funcionales de la solución. Aunque la infraestructura de seguridad se puede considerar fija, el requisito de evaluar otros enfoques es fundamental como parte del diseño completo de la solución. En el caso de esta situación específica, el equipo siguió evaluando otros enfoques para resolver los problemas de seguridad y finalmente implementó un dispositivo de seguridad como parte de la solución.

  • Caso:"Como su ISV clave, queremos dar soporte a todos sus requisitos... Tenemos una solución flexible y podemos implementar funciones nuevas con facilidad."

    Durante un proyecto de core banking estratégico para el Banco B, el ISV (proveedor de software independiente) hizo ese comentario perturbador. Quedó claro que el paquete estaba siendo mejorado y ampliado como parte de la implementación real del proyecto con el cliente específico.

    Por qué es aterrador:

    Por un lado, la capacidad de adaptar aplicaciones empaquetadas a las necesidades del cliente es una característica clave; sin embargo, las mejoras eran mucho más que adaptaciones simples. Nos encontramos con esta situación a menudo debido a evaluaciones de RFP (solicitudes de propuestas), e instamos a nuestros clientes a asegurarse de que los requisitos sean claros, y de que se validen completamente en la evaluación. Recomendamos el uso de herramientas adecuadas para dar soporte a la definición del requisito, y además utilizar estas herramientas para dar soporte a la validación del requisito. Durante la evaluación, las organizaciones deben asegurarse de que las respuestas del proveedor articulen completamente las capacidades del producto en lugar de ofrecer promesas implícitas de capacidades futuras.

    Como inquietud adicional, descubrimos que los cambios de criterio en aplicaciones de servicios bancarios básicos (especialmente las hechas directamente por el cliente) a menudo conducen a el encierro en la versión con la incapacidad de actualizarse con nuevas versiones; como resultado, es imperativo que los clientes evalúen los aspectos de mejoras como parte del diseño de la solución.

    Este cliente aprendió una valiosa lección a un costo elevado: 18 meses después del inicio del proyecto, el equipo TI ejecutivo canceló el proyecto y ahora el banco está buscando enfoques alternativos, utilizando a IBM como un asesor de confianza en este proceso.

  • Caso:"Debemos agregar dos requisitos funcionales más a la próxima versión; pero son cambios pequeños."

    Un involucrado clave en del Banco C sacó este tema en una sesión de diseño con la autoridad de diseño del proyecto. El banco estaba en medio de la activación de los servicios internos de su solución de core banking®basada en CICS para proveer integración con un paquete bancario de un tercero.

    Por qué es aterrador:

    Los proyectos de modernización de servicios bancarios básicos (y los proyectos de TI grandes y complejos en general) requieren rigurosa planificación y una gestión de proyecto disciplinada para poder tener éxito. El control de cambios de base es obligatorio dada la gran cantidad de dependencias que hay en los proyectos de servicios bancarios básicos. Aunque se deberán hacer excepciones, las excepciones se deben gestionar como parte de los procesos formales de gobierno y gestión del proyecto. Puede ser difícil gestionar y coordinar solicitudes de cambios: los clientes deben utilizar herramientas y métodos de gestión de proyectos adecuados para asegurar el control de proyectos de base. En esta instancia específica, los involucrados no reconocieron que los cambios (aunque leves) se traducen en tiempo, dinero y riesgo, y esta conducta siguió sin cambios.

    Finalmente el banco abandonó el proyecto debido a una continua demora en la entrega de éste; un diseño de proyecto y una autoridad de gobierno efectivos habrían probablemente cambiado este resultado desafortunado. IBM está trabajando con el banco para establecer una función de gestión de proyecto más rigurosa para evitar que vuelva a ocurrir esto en el futuro.

  • Caso:"¿Podemos mapear nuestras operaciones CICS directamente a los servicios en nuestro enfoque de solución SOA?"

    Durante una implementación de contrato de servicios web CICS con el Banco D, este tema mostró que el banco no seguía ninguna metodología de diseño de servicios.

    Por qué es aterrador:

    Con el tiempo, el banco había hecho 3.000 operaciones CICS que variaban de simples búsquedas de datos a complejas funciones operativas. Antes de nuestra participación, el Cliente había decidido implementar servicios web CICS para las operaciones CICS utilizadas comúnmente, sin evaluar los requisitos de negocios o técnicos. Fundamentalmente el cliente estaba pasando directamente del análisis de activos a la implementación de servicios de candidatos. Recomendamos la adopción de SOMA ((Service Oriented Modeling and Architecture) para dar soporte al diseño de servicio en el proyecto, así como también utilizarlo como metodología de referencia para la organización. Específicamente, nos concentramos en los pasos de la identificación de servicios para garantizar la identificación de servicios de candidatos, y el uso de la metodología SOMA Service Litmus Test para garantizar que se estuvieran realizando los servicios correctos.

    El resultado de esta historia de cliente fue positive; mejoramos el enfoque del cliente al diseño de servicios. Como norma general, no se debe sacrificar un buen diseño de servicios para mitigar los desafíos de tiempo de salida al mercado.

  • Caso:"¿No podemos simplemente utilizar nuestra tecnología de mensajería existente para dar soporte a los requisitos de gestión de contenido?”

    Durante el diseño de una solución de gestión de cuentas, surgió esta cuestión mientras el Banco E estaba definiendo requisitos de gestión de documentos. Dado su uso de IBM WebSphere®MQ y las habilidades en desarrollo de interfaz de usuario, los desarrolladores propusieron inicialmente redactor una solución de gestión de contenido liviana y personalizada.

    Por qué es aterrador:

    Aunque el equipo desarrolló un diseño basado en SOA viable para la solución, este enfoque no era la manera correcta de abordar este tipo de requisito. El criterio clave para evaluar el desarrollo interno es TCA (costo total de adquisición), pero en su prisa por resolver los desafíos TCA, el banco no evaluó el alcance de los requisitos de gestión de contenido ni las implicaciones de largo plazo del mantenimiento de código.

    Seguimos viendo cómo las organizaciones desarrollan soluciones personalizadas para requisitos de infraestructura simplemente para mitigar costos. En nuestro rol de asesoramiento en el equipo de diseño, convencimos a los clientes de que evitaran armar capacidades de gestión de contenido. En lugar de desarrollar una solución personalizada, el banco implementó una solución de gestión de contenido basada en el proveedor para dar soporte a estos requisitos. Aunque la solución seleccionada ofrecía funciones importantes en comparación con los requisitos reales del proyecto, la solución del proveedor brindó ahorro de costos de largo plazo desde una perspectiva de mantenimiento y de desarrollo.

  • Caso:"La especificación de servicio es WSDL. Como desarrollador, es la única documentación que necesito para desarrollar el servicio."

    En el Banco F, uno de los desarrolladores clave hizo esa declaración durante una discusión de revisión de diseño de una solución de procesamiento de préstamos.

    Por qué es aterrador:

    Un aspecto clave del diseño de servicios es que los servicios deben estar bien documentados como parte del ciclo de vida de desarrollo, y que el diseño debe definir los requisitos funcionales y no funcionales, inclusive los aspectos de interacción de servicios, los acuerdos de nivel de servicios (SLA), la propiedad de los servicios, las políticas de servicios, los aspectos de composición de servicios y otros metadatos relacionados. En resumen, la especificación de servicios es más que solo WSDL. Además, el diseño de servicios necesita ser gestionado como parte de la autoridad de gobierno general y el desarrollo de la organización debe tener una participación activa en este proceso

    El desafío mencionado en este ejemplo fue un problema con el proceso de diseño (o falta del mismo) y un requisito de herramientas para dar soporte al diseño de servicios y la reutilización de activos. El resultado de esta situación fue la adopción de un enfoque de diseño de servicios más amplio y la introducción de un registro de servicios y herramientas de gestión de metadatos para permitir una definición completa de servicios, lo que condujo a un diseño de servicio optimizado y aumentó la reutilización de activos/servicios.

  • Caso:"La prueba del sistema requiere demasiados recursos y es muy dolorosa – no tenemos suficiente hardware para hacerlo bien".

    Un ejecutivo de TI del Banco G hizo este comentario muy sincero durante una revisión de su proyecto de core banking basado en SOA.

    Por qué es aterrador:Era claro que el banco tenía un problema grave: tenía siete entornos que soportar (prueba de unidad, prueba de integración, prueba del sistema, prueba de aceptación de usuario, prueba de esfuerzo/rendimiento, y otras) con más de 30 aplicaciones empaquetadas e internas con distintas bases de datos. Recomendamos la introducción de soluciones de aprovisionamiento automático y sugerimos mejores en la programación y solicitud de pruebas para mejorar la eficacia. Estos cambios resuelven los desafíos inmediatos pero no los de largo plazo. Como resultado, este Cliente ahora evalúa la implementación de una nube privada de desarrollo/prueba.

    La transformación de servicios bancarios básicos es muy compleja y creemos que implementar la virtualización y el aprovisionamiento manual no aborda completamente el riesgo y los problemas de gestión de recursos. Además, anticipamos que la implementación de nubes de prueba/desarrollo será la arquitectura preferida pues muchos bancos en todo el mundo buscan implementar o modernizar soluciones centrales existentes.

Queda claro que hay varias cosas que aprender en términos de proyectos de servicios bancarios básicos —o cualquier proyecto TI importante— estamos analizando lo que pasa en todo el mundo. La mayoría de los bancos han implementado grandes proyectos SOA y, como resultado, ya hemos encontrado (y resuelto, en la mayoría de los casos) muchos de estos desafíos. Muchos bancos de nivel medio se enfrentan ahora a estos desafíos, y espero que este artículo haya ayudado a señalar algunos temas clave a considerar para poder evitar que su diseño de solución se convierta en otra historia aterradora.

En lo que a mí respecta, me alegra decir que aún disfruto una buena historia de terror de vez en cuando, ¡lo cual es bueno porque hace que mi trabajo siga siendo interesante!

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere, SOA y servicios web , Industries
ArticleID=587642
ArticleTitle=Líneas de comentarios: Peores prácticas de transformación de servicios bancarios básicos y otras historias aterradoras
publish-date=08032011