Estrategia de adopción de SOA en el Banco Nacional

ULACIT
UNIVERSIDAD LATINOAMERICANA DE CIENCIA Y TECNOLOGIA
LICENCIATURA EN INFORMATICA
CON ENFASIS EN GESTION DE RECURSOS TECNOLOGICOS
“Estrategia de adopción de una Arquitectura Orientada a
Servicios en el Banco Nacional de Costa Rica”
Sustentante: Luis Diego Masís Sanabria
Cédula: 1-1002-0367
PROYECTO DE GRADUACION PARA OPTAR POR EL GRADO DE
LICENCIATURA EN INFORMATICA
CON ENFASIS EN GESTION DE RECURSOS TECNOLOGICOS
Profesor tutor: Lic. Marco Vinicio Ureña Irola
Nota obtenida: 100.
San José – Costa Rica
ENERO 2005
ii
Dedicatoria
A mi hijo Cristhian y mi esposa Mixy,
por el amor tan profundo que me brindan día con día,
y por las horas de sacrificio que invirtieron en este proyecto.
iii
Agradecimientos
Deseo agradecer
a Dios, por cuanto Él encierra todo lo bueno y justo,
a mis padres, porque ellos son los arquitectos que forjaron mi destino,
a mi asesor académico, Lic. Marco Vinicio Ureña por todo el apoyo brindado.
iv
DECLARACIÓN JURADA
Yo, Luis Diego Masís Sanabria alumno de la Universidad Latinoamericana de Ciencia y
Tecnología (ULACIT), declaro bajo la fe de juramento y consciente de la
responsabilidad penal de este acto, que soy el autor intelectual de la tesis de grado
titulada: “Estrategia de adopción de una Arquitectura Orientada a Servicios en el Banco
Nacional de Costa Rica”, por lo que libero a la ULACIT, de cualquier responsabilidad
en caso de que mi declaración sea falsa.
Brindada en San José-Costa Rica en el día 03 de febrero del año dos mil cinco.
____________________________________
Ing. Luis Diego Masís Sanabria
Cédula número 1-1002-0367
v
ULACIT
UNIVERSIDAD LATINOAMERICANA DE CIENCIA Y TECNOLOGIA
TRIBUNAL EXAMINADOR
Reunido para los efectos respectivos, el Tribunal Examinador de la Escuela de
Postgrados compuesto por:
Tutor: Lic. Marco Vinicio Ureña Irola
Director de Carrera: Wilberth Molina Pérez
Presidente del Tribunal: Mauricio Vega Díaz
vi
Resumen ejecutivo
En el contexto de Plan Estratégico de Tecnologías de Información, la Gerencia
General de Banco Nacional de Costa Rica ha definido objetivos ambiciosos, enfocados
principalmente en la disminución de los costos que representa la infraestructura
tecnológica actual y en los tiempos necesarios para implementar los servicios que
requiere la organización. De esta manera se pretende aprovechar de la mejor manera las
oportunidades que el mercado presenta.
En este sentido, es claro que la organización, y en especial la Dirección
Corporativa de Tecnología y Operaciones, debe responder a una dinámica que se torna
cada vez más compleja y que en general exige explotar y equilibrar las capacidades de
planificación y reacción ante las necesidades de los clientes.
La industria de TI se ha enfrentado a estos problemas desde hace mucho tiempo,
y como parte de sus posibles respuestas, ha analizado a profundidad el concepto de
Arquitectura Orientada a Servicios en el marco de las posibilidades tecnológicas
actuales. Este enfoque arquitectónico proporciona una manera diferente de construir
sistemas pensando en la reutilización de servicios y otorgando gran importancia a los
modelos de negocio, de manera que disminuye el tiempo de implementación de nuevos
servicios transaccionales y se logra una mayor sincronización entre los procesos de
negocio y de TI.
La revisión de la situación actual de los sistemas financieros confirma que existe
una amplia gama de características que han impedido un crecimiento ordenado en los
sistemas financieros de la Institución. Sin embargo, al analizar el conjunto de variables
definidas para esta investigación, se ha determinado un ambiente propicio para la
adopción y consolidación de una Arquitectura Orientada a Servicios en el Banco, a
vii
través de un proceso dividido en tres grandes etapas que inician con la modernización
de la Plataforma de Integración de Aplicaciones existente y la implementación de la
iniciativa de Conector Universal.
Al margen de estas propuestas, la tecnología por sí misma no es suficiente para
garantizar la adopción de un modelo arquitectónico a nivel organizacional, de esta
manera se han identificado áreas estratégicas que la administración debe considerar para
lograr los objetivos del Plan Estratégico y se ha propuesto, para su evaluación, un
portafolio de proyectos que pretende concentrar los esfuerzos de la organización en las
actividades relevantes del proceso.
En este orden de ideas, este documento revela un nivel más detallado de la
situación actual del Banco y una estrategia complementaria a este diagnóstico.
viii
Índice de contenidos
Índice de contenidos ...................................................................................................... viii
Índice de cuadros .............................................................................................................. x
Índice de gráficos.............................................................................................................. x
CAPITULO I .................................................................................................................... 1
1.1. Introducción ............................................................................................................... 2
1.2. Justificación del tema................................................................................................. 3
1.2. Justificación del tema................................................................................................. 3
1.3. Planteamiento del problema....................................................................................... 5
1.3.1. Formulación del problema .................................................................................. 7
CAPITULO II ................................................................................................................... 8
2.1. Modelos de desarrollo versus el mercado actual ....................................................... 9
2.2. Arquitectura de Software – Definición.................................................................... 12
2.3. Arquitectura Orientada al Servicio – Definición ..................................................... 14
2.4. Razones para impulsar la adopción de SOA............................................................ 17
2.5. Elementos generales para adoptar SOA................................................................... 19
2.6. Consideraciones técnicas al adoptar SOA ............................................................... 22
CAPITULO III................................................................................................................ 25
3.1 Tipo de investigación................................................................................................ 26
3.2. Matriz de diseño de investigación ........................................................................... 27
3.3. Matriz de operacionalización de variables............................................................... 29
3.4. Sujetos y fuentes de información............................................................................. 31
3.4.1. Definición de población.................................................................................... 31
3.5. Instrumentos de recolección de datos ...................................................................... 32
3.6. Alcances y limitaciones de la investigación ............................................................ 33
3.6.1. Alcances............................................................................................................ 33
3.6.2. Limitaciones...................................................................................................... 33
CAPITULO IV ............................................................................................................... 34
4.1.
Análisis de la información .................................................................................. 35
4.1.1. Redundancia funcional ..................................................................................... 35
4.1.2. Islas tecnológicas .............................................................................................. 36
4.1.3. Segmentos funcionales ..................................................................................... 38
4.1.4. Dominios tecnológicos ..................................................................................... 40
4.1.5. Costos de operación y mantenimiento. ............................................................. 41
4.1.6. Vida útil de los sistemas. .................................................................................. 42
4.1.7. Implementación de un nuevo servicio. ............................................................. 45
4.1.8. Penetración de reutilización mediante la integración de aplicaciones.............. 46
4.2.
Interpretación de resultados ................................................................................ 47
4.2.1. Diagnóstico basado en la observación. ............................................................. 47
4.2.2. Oportunidad de impulsar SOA. ........................................................................ 49
CAPITULO V................................................................................................................. 51
5.1.
Conclusiones....................................................................................................... 52
5.2.
Recomendaciones ............................................................................................... 54
5.2.1.
Estrategia de adopción de SOA en el Banco Nacional............................... 54
ix
5.2.2.
A la Gerencia General del Banco Nacional de Costa Rica......................... 54
5.2.3.
A la Dirección Corporativa de Tecnología y Operaciones. ........................ 55
5.2.4.
A la Dirección Desarrollo de Sistemas de Información. ............................ 56
CAPITULO VI ............................................................................................................... 57
6.1.
Identificación de la propuesta ............................................................................. 58
6.2.
Identificación de áreas estratégicas..................................................................... 58
6.2.1. Estrategia de negocios ...................................................................................... 58
6.2.2. Arquitectura ...................................................................................................... 59
6.2.3. Proyectos y aplicaciones................................................................................... 60
6.2.4. Organización y gobierno................................................................................... 60
6.3.
Portafolio de proyectos propuesto para la adopción incremental de SOA ......... 61
Glosario de términos....................................................................................................... 65
Bibliografía ..................................................................................................................... 68
ANEXOS ........................................................................................................................ 70
x
Índice de cuadros
Cuadro #1. Sistemas financieros del Banco Nacional................................................... 32
Cuadro #2: I Etapa. Publicación y consumo de servicios (2005-2006) ........................ 62
Cuadro #3: II Etapa. Arquitectura del negocio (2006-2007) ........................................ 63
Cuadro #4: III Etapa. Transformación de TI y el negocio (2007 en adelante) ............. 63
Índice de gráficos
Gráfico #1: Interconexión de N Aplicaciones. .............................................................. 10
Gráfico #2: Proceso de adopción de SOA en la empresa. ............................................. 20
Gráfico #3: Funcionalidad común entre sistemas financieros del banco....................... 36
Gráfico #4: Modelos de comunicación con el Sistema Financiero Bancario. ............... 37
Gráfico #5: Modelos utilizados para la comunicación front end – Sistemas Centrales. 38
Gráfico #6: Categorías de los sistemas financieros en el BNCR................................... 39
Gráfico #7: Dominios para el desarrollo de aplicaciones.............................................. 40
Gráfico #8: Dominios para administrar bases de datos. ................................................ 41
Gráfico #9: Costo de operación y mantenimiento de los sistemas financieros. ............ 42
Gráfico #10: Año de entrada al umbral de vida útil de los sistemas financieros........... 43
Gráfico #11: Distribución de versiones de Oracle utilizadas en sistemas financieros. . 43
Gráfico #12: Versiones de Microsoft SQL Server utilizadas en sistemas financieros. . 44
Gráfico #13: Sistemas financieros que han alcanzado el umbral de vida útil. .............. 45
Gráfico #14: Tiempo estimado para implementar un nuevo módulo en los sistemas. .. 46
Gráfico #15: Arquitectura conceptual del Conector Universal. .................................... 50
Gráfico #16: “Roadmap” del Portafolio de Proyectos para el Banco Nacional. ........... 64
CAPITULO I
FORMULACION
2
1.1. Introducción
El propósito fundamental de esta investigación es analizar los sistemas
operacionales y de apoyo existentes en el Banco Nacional de Costa Rica, determinar sus
características principales y con base en estas formalizar un conjunto de
recomendaciones que permitan a la institución consolidar una Arquitectura Orientada a
Servicios, que haga posible la creación ágil y eficiente de nuevos sistemas.
Adicionalmente, esta investigación presenta como objetivo conexo la
consolidación definitiva de la Plataforma de Integración de Aplicaciones implementada
por el banco, consolidación que consiste en el aumento de su utilización para el
desarrollo de nuevos productos y/o mejoras funcionales a los sistemas existentes. De
esta manera se pretende que no sea considerada simplemente “otra plataforma” dentro
de la complejidad tecnológica de la institución y que, por el contrario, permita mejorar
la comunicación e interoperabilidad de las plataformas existentes en la institución.
3
1.2. Justificación del tema
De acuerdo con la realidad actual, la semántica del negocio como un todo se
encuentra completamente dispersa a lo largo de las plataformas, haciendo difícil su
reutilización sin construir interfaces o dependiendo en exceso de los distintos dominios
tecnológicos. Esta situación se debe a que los sistemas no fueron pensados para utilizar
la funcionalidad que implementan en forma atómica, es decir que dicha funcionalidad
depende más de lo normal del contexto y del sistema que la ejecuta.
Cuando una plataforma tecnológica comienza su tramo final del ciclo de vida,
todos los sistemas implementados comienzan a generar mayores costos operacionales.
Es común ver cómo tecnologías que han llegado a su fin, se mantienen operativas
porque esa tecnología no ha sido en forma oportuna migrada, pagando en consecuencia
un alto costo de mantenimiento. Desafortunadamente, volver a escribir los sistemas
operacionales con años de evolución y estabilidad no es una tarea sencilla, es por eso
que muchos administradores de TI postergan la decisión de migrarlos.
De acuerdo con las necesidades del negocio, la funcionalidad de los sistemas
debe ser encapsulada en componentes, los cuales deben ser ubicados en un único punto
integrador conocido como middleware, al especializar a los sistemas cliente en la
exposición y captura de datos, y a los sistemas centrales en la persistencia de datos.
De esta manera se logra el objetivo de consolidar la Plataforma de Integración de
Aplicaciones del banco con funciones claras y no se dedica a ser simplemente “otra
plataforma” dentro de la complejidad tecnológica de la institución, abriendo el camino
para la adopción de arquitecturas orientadas a servicios también conocidas como SOA.
Dentro de los beneficios esperados de esta propuesta se encuentran los
siguientes:
4
•
Mayor flexibilidad ante los cambios repentinos del negocio por cuanto se
promueve la utilización de servicios, en lugar de la creación de sistemas. Es
decir que si surge la necesidad de un nuevo sistema de información, existirá toda
una gama de servicios que ya han sido implementados para otros sistemas en el
middleware y el nuevo sistema simplemente tendría necesidad de consumirlos o
extender la funcionalidad existente.
•
Mayor nivel de reutilización en la organización, pues se elimina el nacimiento
aislado de sistemas de información que gestionan individualmente toda su
funcionalidad. Se pretende que cada sistema se empiece a orientar hacia la
arquitectura propuesta y que inicie un proceso de reducción de funcionalidades
redundantes.
•
Menor impacto ante cambios tecnológicos mediante la unificación de las reglas
del negocio. Si los cambios que se originan son a nivel interno, dentro de la
lógica del negocio se modifica el middleware como único punto concentrador y
no se debe modificar cada sistema que posea de manera redundante esta lógica.
•
Mayor capacidad para ensamblar servicios antes que programar sistemas, pues
esta arquitectura propone la visualización de los componentes tecnológicos
como piezas individuales que pueden ser unidas de acuerdo con la necesidad de
un nuevo servicio.
•
Garantizar la correcta utilización de la Plataforma de Integración de
Aplicaciones adquirida por la institución, pues sin estrategias formalmente
definidas la tecnología no es efectiva.
•
Promover una mejor interoperabilidad de los sistemas debido a que se elimina la
cadena de dependencia de “muchos a muchos” en la relación tecnológica de los
sistemas de la institución.
5
1.3. Planteamiento del problema
El Banco Nacional de Costa Rica es una entidad del Estado fundada el 9 de
octubre de 1914 con el nombre de Banco Internacional de Costa Rica. La vocación
inicial de la institución se orientó hacia el desarrollo agrícola y rural del país, la cual se
ha conservado a lo largo de toda su vida, sin perjuicio del estímulo que ha prestado a las
restantes actividades productivas de la Nación.
El 5 de noviembre de 1936 se le cambió el nombre a Banco Nacional de Costa
Rica y desde entonces se ha consolidado como un verdadero banco de desarrollo con
una proyección positiva en la vida económica, social y financiera del país.
La Institución actualmente cuenta con más de 140 agencias a lo largo del
territorio nacional, ofreciendo sus servicios en los rincones más alejados del país.
Bajo la administración del Lic. William Hayden Quintero, el Banco Nacional
obtuvo el año 2003 una utilidad récord de más de doce mil millones de colones, y es
reconocido como el Banco más grande de Centro América y el Caribe.
Su organización se encuentra conformada por una casa matriz, ubicada en su
edificio principal en el centro de San José y 6 Bancos regionales, a saber:
•
Banco Regional San José Este.
•
Banco Regional San José Oeste.
•
Banco Regional de Guanacaste-Puntarenas.
•
Banco Regional de Cartago Sur.
•
Banco Regional de Heredia-Limón.
•
Banco Regional de Alajuela.
La casa matriz es responsable de emitir las directrices que rigen el
funcionamiento de todos los Bancos regionales, estandarizando así el servicio ofrecido
por la Institución.
La misma se encuentra conformada por diferentes Direcciones
6
Corporativas, entre las cuales se destaca la Dirección Corporativa de Tecnología y
Operaciones, responsable de ofrecer el soporte tecnológico
necesario para que la
Institución continúe a la vanguardia del sector financiero costarricense.
Durante muchos años, la Dirección Corporativa de Tecnología y Operaciones se
ha encargado de brindar a la institución todos los servicios referentes al desarrollo y
mantenimiento de las soluciones tecnológicas que posibilitan la gestión del negocio
bancario. De esta manera se ha dado respuesta a las necesidades del banco a nivel de
desarrollo de software, infraestructura de seguridad y comunicaciones y el soporte y
operación de los sistemas en producción.
A pesar de que la gestión de la Dirección de Tecnología ha sido un apoyo
invaluable para el desarrollo y fortalecimiento de la institución, al igual que en la
mayoría de las organizaciones, los sistemas operacionales y de apoyo del Banco
Nacional de Costa Rica fueron construidos a lo largo del tiempo, utilizando distintas
plataformas de desarrollo y diferentes modelos arquitectónicos (monolíticos, clienteservidor, tres capas y otros), dando origen a un complejo modelo de interoperabilidad.
La realidad actual de los sistemas del banco plantea una comunicación de “muchos a
muchos”, lo cual se traduce en una fuerte inversión de tiempo y recursos en el
mantenimiento, no solo de la solución tecnológica en sí misma, sino también entre estas
relaciones.
Por ejemplo; en la actualidad cada uno de los canales de distribución de la
institución posee un componente tecnológico que le permite comunicarse al sistema de
cuentas corrientes y de ahorros, con el objetivo de obtener información genérica como
las cuentas relacionadas a un cliente. Adicionalmente cada uno de estos canales
(Sistema de cajas, E-Banking, banca telefónica, cajeros automáticos) utiliza
transacciones distintas a nivel de ese sistema central para obtener la misma información.
En un escenario hipotético, en el cual fuera necesario modificar el concepto de consulta
de cuentas de un cliente, se deben modificar N transacciones y N canales relacionados,
lo cual eleva los costos y sin duda aumenta la probabilidad de errores u omisiones.
7
Uno de los objetivos planteados por la Dirección de Tecnología para el año 2005
es simplificar esta interoperabilidad mediante la consolidación de una Arquitectura
Orientada al Servicio, a través de la integración de dominios tecnológicos. Esta
integración está fundamentada en una solución llamada Plataforma de Integración de
Aplicaciones (PIA). La idea central de esta iniciativa es consolidar las reglas de negocio
en un único punto, bajo la premisa de la reutilización; ello significa que si bien es cierto
no todos los sistemas necesitan la misma información, se puede contar con una
transacción general que obtiene las cuentas del cliente y brinda el resultado de la
ejecución especializada al sistema que lo solicitó.
Si bien en el corto plazo, el desafío es integrar a los distintos dominios
tecnológicos (plataformas), fundamentado principalmente en la continuidad del negocio,
para mediano y largo plazo se ha definido el objetivo de lograr la convergencia de las
reglas del negocio hacia la capa intermedia y la especialización tanto de los sistemas de
cara al cliente como de los sistemas centrales del banco, de manera tal que se minimicen
las relaciones complejas de los sistemas del banco entre canales y sistemas centrales.
La meta es desarrollar un modelo y una disciplina la cual permita que los
sistemas operacionales no evolucionen dentro de compartimientos en sí mismos, sino
como un conjunto de piezas perfectamente desacopladas, que son construidas con
diversas tecnologías y pueden ser reemplazadas individualmente.
Como parte del portafolio de proyectos principal de la Dirección de Tecnología,
se encuentra la primera etapa de esta consolidación que consiste en desarrollar una
investigación la cual permita analizar las diferentes soluciones de software que posee el
banco con la intención de establecer un proceso de convergencia tecnológica, todo esto
mediante definición de métricas y análisis del ciclo de vida de las plataformas actuales.
1.3.1. Formulación del problema
¿Cómo planificar a nivel estratégico la adecuación de los sistemas computacionales del
Banco Nacional de Costa Rica a una arquitectura de sistemas orientada a servicios?.
CAPITULO II
MARCO TEORICO
9
2.1. Modelos de desarrollo versus el mercado actual
Durante las últimas décadas, los departamentos de TI de las empresas se han
dado a la tarea de construir una infraestructura que soporte la operación normal, tanto a
lo interno de la organización como a lo externo, para brindar un valor agregado a los
clientes quienes utilizan los bienes o servicios proporcionados.
Debido a que la ciencia de la computación e informática se encuentra en
continuo crecimiento, el camino que estas empresas han debido transitar para llegar
hasta este punto no ha sido fácil ni económico; pues las organizaciones se han visto
obligadas a aprender de los errores y aciertos de la industria. El resultado de este
proceso, ha sido la construcción y mantenimiento de muchas aplicaciones al interior de
las empresas, cada una responsable de sus propias tareas.
Con el nacimiento del comercio electrónico – amparado ampliamente por el
crecimiento exponencial experimentado por los medios digitales como Internet y
tecnología que la ha sabido utilizar – el mercado mismo presiona a las organizaciones
para crear rápidamente sistemas más complejos con menos dinero. Cuando la
organización cuenta con una infraestructura de TI que soporta la operación, la
construcción de estas aplicaciones va a requerir de servicios funcionales que
probablemente fueron de forma previa implementadas como parte de otro sistema.
Ante esta necesidad, los arquitectos de software tienen dos opciones para
implementar el servicio:
1. Reutilizar la funcionalidad ya implementada en otros sistemas. La
complejidad de esta opción es alta, debido a que los otros sistemas no fueron
diseñados para integrarse con múltiples plataformas y/o tecnologías. Si se
encuentra una alternativa técnica de realizar la reutilización, se debe asumir
tanto el riesgo de alterar un sistema en producción que está funcionando sin
problemas, como la posibilidad de generar inconvenientes de interoperabilidad
en el nuevo sistema.
10
2. Volver a implementar la funcionalidad requerida, utilizando el producto o
tecnología particular donde se está construyendo el sistema. Aunque
probablemente tome mucho más tiempo de desarrollo, en teoría es la más
sencilla y la más segura.
En la mayoría de los casos la segunda opción es la preferida para los arquitectos
de software. A corto plazo se visualiza como una buena decisión, pero a largo plazo
genera inconvenientes como los siguientes:
•
Funcionalidad replicada a lo largo de muchas plataformas y sistemas.
•
Se presenta mayor dificultad para migrar los sistemas internos, pues existen
múltiples conexiones desde otros sistemas que dependen de estos para ejecutar
correctamente su funcionalidad.
•
Debido a la falta de una estrategia formal para integración de aplicaciones, se
generan múltiples puntos de falla, que pueden provocar problemas en la
operación o incluso detener a muchos sistemas fácilmente.
Gráfico #1: Interconexión de N Aplicaciones.
Fuente: Elaboración propia.
11
De acuerdo con este planteamiento, es importante analizar las prioridades que
define el negocio con relación a la TI. A nivel global, Information Week indica
mediante West(2004) que “los impulsores del negocio, en el caso de las TI, han seguido
siendo los mismos desde hace años: mejorar las eficiencias y comunicaciones de la
empresa, optimizar la toma de decisiones y apoyar la colaboración.”.
A nivel local PriceWaterHouseCoopers(2004) indica que dentro de las
prioridades estratégicas para TI que posee la Gerencia General del Banco Nacional de
Costa Rica, se encuentran; entre otras, las siguientes:
•
Contar con un backoffice robusto, que elimine aplicaciones e interfaces y
proporcione información en tiempo real.
•
Reducción de la estructura tecnológica en propiedad del Banco y su alto costo de
operación
•
Adopción de las mejores prácticas bancarias, en lugar de la implantación
tecnológica de las prácticas actuales
•
Disminución de los tiempos de entrega de servicios y productos técnicos. (p.25).
Como se puede observar los objetivos estratégicos definidos por la
administración de la institución están sincronizados con lo observado en la industria;
por lo tanto es indispensable que los proyectos e iniciativas que planifique la Dirección
Corporativa de Tecnología y Operaciones brinden respuesta rápida y contundente a
estos temas.
12
2.2. Arquitectura de Software – Definición
A pesar de ser un tema de tanta importancia y contar con una amplia aceptación
como parte de las estrategias de TI, no existe una definición de arquitectura de software
que satisfaga a todos los involucrados en este proceso. De acuerdo con las últimas
investigaciones en la historia de la ingeniería del software, en el año 1968 Edsger
Dijkstra; quien trabajaba en la Universidad Tecnológica de Eindhoven en Holanda,
formuló una primera definición cuando indicó la necesidad de que se establezca una
estructuración correcta de los sistemas de software antes de iniciar su construcción
escribiendo el código desordenadamente. A pesar de que Dijkstra no utiliza el término
“arquitectura” para describir el diseño conceptual del software, sus trabajos sientan los
fundamentos de las definiciones que se analizarán a continuación.
Existe una definición reconocida por la industria en general, publicada por
Clements(1996), la cual se refiere a la arquitectura de software de la siguiente manera:
Es a grandes rasgos, una vista del sistema que incluye los componentes
principales del mismo, la conducta de esos componentes según se la percibe
desde el resto del sistema y las formas en que los componentes interactúan y se
coordinan para alcanzar la misión del sistema. La vista arquitectónica es una
vista abstracta, aportando el más alto nivel de comprensión y la supresión o
diferimiento del detalle inherente a la mayor parte de las abstracciones.
Es importante hacer la aclaración que en este caso “componente” no se refiere a
la implementación tecnológica en una herramienta de desarrollo determinada, como por
ejemplo COM, CORBA, Enterprise Java Beans y otras. En este caso un componente es
una entidad a la que los arquitectos prefieren llamar “componente” antes que “objeto”,
para evitar que se confunda con el paradigma de desarrollo orientado a objetos.
La definición formal de Arquitectura de Software que utiliza la industria; por
común acuerdo, la brinda la IEEE(2000) dentro del estándar 471-2000, la cual indica
que “la Arquitectura de Software es la organización fundamental de un sistema
encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios
que orientan su diseño y evolución”.
13
De esta manera se puede indicar que la arquitectura de software se refiere a la
estructura general del sistema, mediante una estructura consistente compuesta por
componentes y las relaciones entre ellos. Inevitablemente estas cuestiones estructurales
se relacionan con las tareas diseño, pues la arquitectura es una forma de diseño de
software que se manifiesta en las primeras etapas de la concepción de un sistema; con la
diferencia que este diseño se presenta a un nivel más abstracto que los algoritmos y las
estructuras de datos. Se pueden mencionar se encuentran los siguientes componentes:
•
Protocolos de comunicación.
•
La sincronización y el acceso a datos.
•
La asignación de funcionalidad a elementos del diseño.
•
Distribución física.
•
Composición de los elementos de diseño.
•
Escalabilidad y rendimiento.
•
Selección entre alternativas de diseño.
•
Confiabilidad.
•
Usabilidad.
Es importante mencionar que el concepto clave de la arquitectura es la
organización (tomando este concepto de forma cualitativa o estructural), mientras que la
ingeniería tiene fundamentalmente que ver con procesos sistemáticos que son
susceptibles de cuantificarse, por esa razón el concepto de la arquitectura concierne a un
alto nivel de abstracción.
En síntesis la Arquitectura de Software representa la clave para comprender,
organizar y comunicar un sistema, además, permite implantar conceptos como
reutilización y facilita el desarrollo de la solución.
14
2.3. Arquitectura Orientada al Servicio – Definición
Como se analizó anteriormente, la reutilización es uno de los fundamentos que
justifica la concepción del propio concepto de arquitectura. Apoyado en este principio,
una estrategia de aplicaciones empresariales definida de manera correcta deberá facilitar
la integración de dichas aplicaciones entre sí.
Esta tendencia de arquitectura de software es conocida como Arquitectura
Orientada al Servicio (SOA) y básicamente consiste en una serie de patrones de
arquitectura de acuerdo con las mejores prácticas promovidas por la industria para
permitir y motivar la construcción de servicios, más que de aplicaciones o sistemas
independientes. Estos servicios serán los encargados de exponer una funcionalidad bien
definida a la aplicación que la requiera. De esta manera, una aplicación final
simplemente orquesta o coordina la ejecución de un conjunto de estos servicios, añade
lógica particular y le presenta una interfaz al usuario final.
Microsoft (2004) define SOA como “una arquitectura para propósitos generales,
inspirada por la Internet y la Web, con el objetivo de habilitar interoperabilidad
extensible y federada, basada en conceptos generales de redes como protocolos e
intermediarios”
Colan(2004), quien labora para IBM Corporation, indica que SOA es “una
propuesta para construir sistemas distribuidos que publiquen su funcionalidad como
servicios para ser consumidos por aplicaciones de usuario final o para construir otros
servicios” (p.4).
Ambas definiciones se apoyan ampliamente en el concepto de servicios, pues
exponer procesos de negocio como servicios, es la clave a la flexibilidad de este tipo de
arquitectura. El objetivo primordial en este caso es permitir que otras piezas de
funcionalidad (aún cuando también se encuentren implementadas bajo esta arquitectura)
hagan uso de otros servicios de manera natural, sin importar su ubicación física. De esta
manera un sistema evoluciona con nuevos servicios y se mejora a nivel independiente.
15
La Arquitectura Orientada a Servicios resultante, define los servicios de los
cuales estará compuesto el sistema, sus interacciones, y las tecnologías con la cuales
finalmente serán implementados. Las interfaces que utiliza cada servicio para exponer
su funcionalidad deben ser bien definidas y gobernadas por contratos, que definen
claramente el conjunto de mensajes soportados, su contenido y las políticas aplicables;
para que en conjunto formen parte integral de los procesos de negocio.
De acuerdo con su naturaleza, se han identificado cuatro tipos de servicios que
se complementan entre sí, conocidos como servicios de entidad, actividad, proceso e
infraestructura.
Servicios de entidad: Operaciones unitarias y atómicas en una entidad, la cual
puede ser una base de datos, un componente, un sistema legado o bien un socio de
negocios. Ejemplo: débito a una cuenta, crédito a una tarjeta.
Servicios de actividad: Coordinan la operación de varios servicios de entidad
como una operación única y atómica. Ejemplo: Pago de tarjeta de crédito, debitando de
una cuenta. (Nótese que en este caso el servicio entidad “débito a una cuenta” puede ser
ejecutado en una base de datos de la empresa y el de “crédito a una tarjeta” incluso
puede ser provisto por un socio de negocios fuera de la empresa).
Servicios de proceso: Ejecutan grandes procesos de negocio, los cuales pueden
involucrar complejos flujos de trabajo e incluso participación humana. Ejemplo:
Aprobación de un crédito.
Servicios de infraestructura: proveen una plataforma de funcionalidad general
que permite la correcta ejecución de los servicios descritos anteriormente. Ejemplo:
administración, seguridad, auditoría y monitoreo.
Estos tipos de servicio poseen una característica en común y es que deben ser
una aplicación completamente autónoma e independiente. A pesar de esto, no se le
puede considerar una isla funcional porque expone una interfaz de llamado basada en
mensajes, capaz de ser accedida a través de la red. Generalmente, los servicios incluyen
tanto lógica de negocios como manejo de estado (datos), relevantes a la solución del
16
problema para el cual fueron diseñados. La manipulación de este estado es administrada
por las reglas de negocio.
Como recién se ha mencionado, la comunicación desde y hacia el servicio, es
realizada utilizando mensajes y no llamadas a métodos. Estos mensajes deben contener
o poseer referencia a toda la información necesaria para entenderlo. La idea es que haya
el mínimo posible de llamadas entre el cliente y el servicio.
En resumen se puede indicar que un servicio es la evolución en complejidad y
funcionalidad de un componente distribuido. Si se compara con un componente
distribuido, se puede decir que los servicios:
™ Se encuentran mucho menos acoplados con las aplicaciones cliente que los
utilizan.
™ Poseen menor descomposición de funciones.
™ No son implementados necesariamente como parte de una aplicación punto a
punto.
™ Son controlados y administrados de manera independiente.
™ Exponen su funcionalidad a través de protocolos abiertos e independientes de la
plataforma en la que se encuentran desarrollados, aún cuando esto arriesga
ocasionalmente el rendimiento y probablemente se pueda traducir en un
incremento del consumo de recursos.
™ Son en cierta medida “transparentes” de su localización en la red, de esta manera
buscan mejoras en criterios como escalabilidad y tolerancia a fallos.
™ Tienen sus propias políticas de escalabilidad, seguridad, tolerancia a fallos,
manejo de excepciones, configuración y demás.
17
2.4. Razones para impulsar la adopción de SOA
Por lo general, las empresas que utilizan como estrategia competitiva la
prestación de nuevos y mejores servicios a sus clientes, han realizado una gran
inversión en tecnología a lo largo del tiempo. Actualmente se puede decir que este perfil
de organizaciones cuenta con un alto porcentaje de procesos de negocio automatizados
mediante elementos tecnológicos complejos; los cuales han requerido una gran cantidad
de tiempo para su consolidación.
De acuerdo con esta realidad se debe cuestionar la necesidad de adoptar un
nuevo modelo arquitectónico y enumerar algunos beneficios que proporciona esta
inversión. Bea Systems (2004) indica que “SOA es valioso para las empresas que
necesitan resolver problemas de negocio críticos utilizando tecnologías de información,
incluyendo a las empresas que buscan minimizar la infraestructura redundante y crear
una interface de negocios común entre los sistemas orientados a los clientes y a los
empleados; negocios que necesitan personalizar información de usuarios basados en
roles y flujos de trabajo, y organizaciones que buscan utilizar Internet para aumentar las
ganancias mediante venta cruzada y el acceso mediante dispositivos móviles”. De
acuerdo con esta teoría se puede indicar que las empresas que adopten una arquitectura
de este tipo experimentarán beneficios desde el punto de vista de TI, y lo que es más
importante, del negocio mismo.
2.4.1. Beneficios para el negocio
Eficiencia: Permite a la organización la transformación de los procesos de
negocio en servicios compartidos con un menor costo en el mantenimiento.
Adaptabilidad: Hace más sencillo para la empresa el proceso de adopción de
cambios, a la vez que se añade flexibilidad y se reduce esfuerzo.
Mejorar la capacidad de respuesta: Hace posible una rápida adaptación y
despliegue de servicios, lo cual es indispensable para aumentar los niveles de servicio y
de esta manera solventar las exigencias de los clientes, los aliados de negocio y los
empleados.
18
2.4.2. Beneficios para TI
Reducción de complejidad: Por cuanto se fundamenta en garantizar una
compatibilidad basada en estándares frente al concepto de integración punto a punto.
Aumenta la reutilización: Permite mayor eficiencia en el desarrollo, entrega de
proyectos y aplicaciones, debido a la reutilización de servicios compartidos que han
sido previamente desarrollados y desplegados.
Integra aplicaciones heredadas: De esta manera se publica la funcionalidad
residente en estos sistemas como servicios reutilizables, reduciendo de esta manera el
costo implícito a su mantenimiento e integración.
Más allá de los beneficios que brinda, es indispensable indicar que la industria
misma es una fuerza externa que impulsa la adopción de SOA en las organizaciones. La
presión ejercida es tal que Gartner (2004), al analizar el futuro de la TI en el mundo y en
Latinoamérica, recomienda fuertemente a las empresas:
Diseñar arquitecturas y estrategias basadas en la fundamental e inevitable
confluencia de:
•
Infraestructura en tiempo real.
•
Banda Ancha Wireless.
•
Dispositivos móviles de bajo costo y bajo consumo de energía.
•
SOA. (p.39)
En la medida que este tipo de arquitectura ha dejado de ser un planteamiento
teórico y se ha transformado en una alternativa real para las empresas mediante el uso
de Web Services y estándares que los regulan, las organizaciones deben comprender
que el año 2005 es un año de preparación para las exigencias que impulsará la industria.
Al respecto Gartner (2004) también recomienda “mejorar las habilidades para adoptar
las nuevas plataformas y así poder ganar” puesto que “los años clave son el 2006 y el
2007 – el futuro será muy bueno para los que aumenten sus habilidades hoy” (p.39).
19
2.5. Elementos generales para adoptar SOA
Es razonable considerar que la adopción de una arquitectura orientada al servicio
es un proceso incremental y que debe responder a las necesidades de la organización; es
decir que una estrategia de choque a nivel de sustitución de sistemas implica por sí
misma la pérdida de una gran parte de la inversión que la organización ha realizado a
nivel de software y probablemente de hardware.
El negocio de hoy demanda un importante retorno de su inversión en tecnología,
lo cual evidencia que la idea de un nuevo modelo de arquitectura que sugiera costos
muy elevados será muy difícil de vender a la administración. En términos generales se
sugiere que los requerimientos de adopción de SOA consideren lo siguiente:
•
Mantener los activos existentes, pues estos sistemas raramente pueden ser
descontinuados por el valor que le generan a la empresa. Estratégicamente se
debe plantear una arquitectura que mantenga ese valor mediante estrategias de
integración y que desde el punto de vista táctico permita realizar proyectos
incrementales que mejoren, o incluso a largo plazo, sustituyan el modelo
aplicativo actual.
•
Permitir todos los tipos de integración requeridos, el modelo debe responder a
necesidades tales como:
o Interacción con el usuario: permitir una experiencia de usuario sencilla e
interactiva.
o Conectividad entre aplicaciones.
o Integración de procesos.
o Integración de información
o Procesos de construcción orientados a la integración.
•
Permitir implementaciones incrementales y migración de activos, con el objetivo
concreto de implementar un retorno de inversión más temprano.
20
•
Hacer posible la implementación de nuevos modelos de computación,
específicamente modelos fundamentados en portales basados en clientes y
computación por demanda (modelos asincrónicos).
Como toda decisión estratégica, las organizaciones deben empezar con un plan
concreto que describa las necesidades actuales de la empresa y sus futuros
requerimientos. Bea Systems (2004) presenta el siguiente diagrama donde ilustra un
ejemplo de plan progresivo para implementar SOA.
Gráfico #2: Proceso de adopción de SOA en la empresa.
Fuente: Bea Systems (traducción).
Mediante la exposición de los servicios más altamente reutilizables(o genéricos)
para el consumo de los aliados de negocio y los usuarios internos, el departamento de
tecnología puede demostrar rápidamente a los involucrados en el proceso el valor real
de SOA. Por ejemplo, las empresas pueden exponer servicios B2B en sitios de
colaboración para sus aliados de negocio, mientras eliminan infraestructura redundante.
Varhol (2004) apoya la iniciativa de iniciar con la publicación y el consumo de
los Web Services cuando recomienda que “en primer lugar, se debe entender la
tecnología que está detrás de los Web Services y SOA. Esto es importante porque se
debe conciliar lo que es posible con lo que es práctico. El conocimiento de los
fundamentos de la tecnología detrás de SOA y como pueden ser aplicados dentro de la
infraestructura de la organización es esencial para asegurar que cualquier diseño puede
ser implementado satisfactoriamente”
21
Esta primera etapa está sujeta a comprender correctamente el negocio, lo cual
significa que no solo es necesario contar con una vista general de lo que la empresa
hace y cómo lo hace; sino también experimentar directamente las prácticas del negocio
y de esta manera, entendiendo los detalles, contar con la información necesaria para
diseñar los servicios con un nivel de especialización que soporten esas necesidades.
Al respecto Varhol (2004) también añade que la siguiente tarea dentro de esta
etapa es “implementar uno o dos servicios de gran valor que llenen las necesidades
inmediatas y los requerimientos de arquitectura proyectados a futuro”, puesto que
mediante la correcta definición de estos servicios y la medición de cómo están
supliendo las necesidades actuales.
El éxito que alcance esta primera etapa frecuentemente impulsa la creación de
servicios más complejos que transforman los procesos de negocio y administran los
flujos de trabajo. Una de las áreas de orquestación de negocios que presenta un
crecimiento más rápido es la de aplicaciones de autoservicio, las cuales pueden entregar
servicios de compra de productos y servicios.
También se pueden implementar servicios que mejoren los procesos
administrativos de la empresa. Por ejemplo, muchos subprocesos se inician cuando se
realiza contratación de un nuevo empleado; requieren acceso a la red de la organización,
a las instalaciones físicas, carné de identificación, activación en sistemas donde deba
realizar sus funciones y muchas tareas más. Utilizando SOA el negocio puede modelar
el proceso entero de creación de un nuevo empleado, el cual inicia en la solicitud de
creación del usuario en los diferentes sistemas de la empresa mediante procesos basados
en servicios que soportan el flujo de trabajo, monitorean el estado de las solicitudes y
eventualmente elaboran un resumen de los resultados.
Una empresa de servicios financieros puede mejorar el servicio al cliente,
vinculando las personas y los procesos de clientes mediante una interface de negocios
común, sencilla y personalizada; tanto para los sistemas de los clientes como los
empleados, permitiendo características indispensables como la reutilización.
22
La tercera etapa de esta estrategia está orientada para buscar transformar las
áreas de TI y negocios; para este fin las organizaciones habilitarán SOA a través de la
empresa, lo cual implica que las interacciones de todas las aplicaciones estarán basadas
en la arquitectura orientada a servicios de la institución y establecer un gobierno eficaz
y efectivo de esta arquitectura.
Bea Systems (2004) indica al respecto:
Para algunas empresas este cambio involucra la publicación de aplicaciones tipo
mainframe existentes como servicios en la arquitectura, en vista que almacenan
datos críticos de la empresa. Para otras, podrá implicar una reestructuración de la
organización en sí misma. Por ejemplo, con la adopción de SOA en la empresa,
TI necesitará definir los procesos de gobierno de toda la arquitectura.
2.6. Consideraciones técnicas al adoptar SOA
Considerando los beneficios que genera su utilización, es conveniente en la
mayoría de los casos modelar el negocio considerando una arquitectura de servicios; sin
embargo a nivel tecnológico la implementación de un servicio presenta inconvenientes
que deben ser considerados y en la medida de lo posible solucionados para obtener de
esta manera una implementación ideal y acorde con las demandas del negocio. De
acuerdo con West(2004) una arquitectura de este tipo “ha de incluir atributos de tiempo
de corrida que satisfagan las metas del negocio; a saber, disponibilidad, seguridad,
interoperabilidad, flexibilidad, desempeño y escalabilidad”.
•
Disponibilidad y seguridad. SOA supone que en un sistema distribuido se
presentarán problemas. A pesar que exista todo un esfuerzo por brindar
soluciones de continuidad del negocio nunca se debe partir del hecho que un
servicio se ejecutará en un ambiente común en J2EE o Microsoft .NET. Para
garantizar la disponibilidad e integridad
del sistema se deben integrar las
mejores prácticas de la industria con elementos tecnológicos que permitan hacer
frente a fallas parciales.
23
Desde el punto de vista de seguridad se debe proporcionar una adecuada
protección frente a las interrupciones, con una combinación de fuerte
autentificación, restricciones en los procesos de autorización, encriptación de los
datos, garantía de confidencialidad del contenido y no repudio de los mensajes;
esto incorporado a la infraestructura de seguridad existente en la organización,
de manera que se cuente con una adecuada protección de los recursos cruciales
dentro de la empresa y mecanismos de monitoreo y defensa contra ataques mal
intencionados, que minimicen las interrupciones en el servicio
•
Interoperabilidad. Este concepto es crucial, puesto que impacta directamente el
costo de propiedad y las ganancias del negocio. Dentro de una SOA los procesos
prioritarios son los que se encuentran relacionados al negocio y la
interoperabilidad con el backoffice.
La interoperabilidad de los procesos de negocio comprende la capacidad de
intercambiar transparentemente información entre aplicaciones. Mediante el
nivel de especialización que requiere este tipo de arquitectura permite un nivel
de diferenciación basada en crear o administrar procesos de negocio.
Con respecto al backoffice, el departamento de TI debe suministrar un
proceso ágil y eficiente para los usuarios y que abarque todos los canales
(Internet, IVR, servicio al cliente).
•
Flexibilidad. La capacidad de adaptarse de manera natural presenta tres
requisitos: detectar los cambios en el ambiente, en los sistemas y ejecutar los
ajustes necesarios donde se requiera. Al respecto se recomienda monitorear,
reaccionar e implementar cambios a través de diferentes mecanismos; por
ejemplo se pueden mencionar modificaciones a las políticas que se practican en
conjunto con las aplicaciones, estimar el peso o impacto de las modificaciones
propuestas, efectuar estos cambios sin interrumpir el ambiente de producción de
servicios no relacionados y que adicionalmente reporte el estado y
comportamiento de los servicios a un mecanismo de monitoreo integral.
24
•
Desempeño. Una aplicación construida sobre servicios Web debe mejorar la
productividad de los usuarios. Para planificación de la capacidad el desempeño
general debe ser cuantificable y descrito en términos de la inversión de la
infraestructura requerida. Las definiciones del desempeño requerido y el
subsiguiente monitoreo también deben ser descritos de manera que permitan
obtener un más alto nivel, tomando en cuenta la experiencia de los usuarios.
•
Escalabilidad. Dentro de este tipo de arquitectura los servicios tienen que
escalar a través de todos los elementos del sistema sin interrumpir su
disponibilidad. Cuando se añade un nuevo recurso, la aplicación que exponga un
servicio tiene que sacar ventaja transparentemente de esta incorporación. El
ambiente también debe permitir la escalabilidad hacia abajo para prever la
subutilización de recursos; y la implementación del concepto de niveles de
servicio entre las aplicaciones.
CAPITULO III
MARCO METODOLOGICO
26
3.1 Tipo de investigación
En esta investigación se utiliza el enfoque descriptivo, el cual constituye una
herramienta fundamental para cumplir con los objetivos del proyecto, específicamente
el objetivo de propuesta relacionado con la recomendación de un proceso de migración
de las reglas de negocio de la institución a una nueva arquitectura.
De acuerdo con lo indicado por Hernández, Fernández y Baptista (1998) “los
estudios descriptivos pueden especificar las propiedades importantes de personas,
grupos, comunidades o cualquier otro fenómeno que sea sometido a análisis”, en este
caso es importante establecer las características fundamentales de los sistemas definidos
como de misión crítica de la institución, por parte de la Dirección Corporativa de
Tecnología y Operaciones.
Este tipo de investigación mide o evalúa diversos aspectos, dimensiones o
componentes del fenómeno o fenómenos por investigar. Desde el punto de vista de un
estudio científico, describir se interpreta como medir, por ello se relaciona con una serie
de elementos y se mide cada una de ellos independientemente, para así describir lo que
se investiga con la mayor precisión posible.
Hernández et al. (1998), también indican que:
La investigación descriptiva, en comparación con la naturaleza poco estructurada
de los estudios exploratorios, requiere considerable conocimiento del área que se
investiga para formular las preguntas específicas que busca responder, por lo que
puede ser más o menos profunda pero en cualquier caso se basa en la medición
de uno o más atributos del fenómeno descrito. (p. 60-62)
Por esta razón se ha definido que en este trabajo de investigación se utilizará el
tipo de investigación descriptiva para la recopilación de datos, pues con ello se permite
la interpretación de la información a un nivel mayor de detalle técnico con el fin de dar
resultados más certeros y oportunos.
27
3.2. Matriz de diseño de investigación
TEMA
Estrategia de adopción de una Arquitectura Orientada al Servicio en el Banco Nacional
de Costa Rica
PROBLEMA
¿Cómo planificar a nivel estratégico la adecuación de los sistemas computacionales del
Banco Nacional de Costa Rica a una arquitectura de sistemas orientada a servicios?
OBJETIVOS DE DIAGNOSTICO
GENERALES
ESPECIFICOS
Analizar la situación actual de los 1. Establecer una clasificación de los
sistemas financieros de apoyo del Banco
sistemas actuales con base en su
Nacional de Costa Rica para determinar el
importancia para el negocio.
ciclo de vida de las plataformas de
desarrollo actuales.
2. Ubicar a los sistemas financieros de
apoyo
de
acuerdo
con
esa
clasificación.
3. Identificar la funcionalidad de cada
uno de los sistemas clasificados.
4. Establecer el grado de reutilización de
la funcionalidad identificada.
5. Analizar el modelo de arquitectura
corporativa y el ciclo de vida de las
plataformas actuales
28
OBJETIVOS DE PROPUESTA
GENERALES
Recomendar
un
ESPECIFICOS
proceso
gradual
de 1. Establecer
la
estrategia
de
introducción y consolidación de los
convergencia
conceptos de SOA en el desarrollo de
sistemas con base en la clasificación
sistemas de la institución
anterior y el grado de reutilización que
tecnológica
de
los
presenta su funcionalidad.
2. Recomendar un plan de acción, según
corresponda, para cada uno de los
dominios
tecnológicos
de
la
institución.
3. Recomendar sistemas apropiados para
iniciar
el
tecnológica.
ciclo
de
convergencia
29
3.3. Matriz de operacionalización de variables
Variables
Definición Conceptual
Definición Operacional
Indicadores
Redundancia
funcional
Transacciones que residen en
un mismo sistema central de
la institución que realizan la
misma funcionalidad
Cantidad
actual
transacciones
para
funcionalidad
Promedio de redundancia
funcional
Islas tecnológicas
Sistema o plataforma que de
acuerdo con las necesidades
identificadas, se ha visto en
la necesidad de crecer de una
manera aislada diseñando su
propia lógica para su
operación
Seleccionar un subconjunto de
la funcionalidad más común en
los sistemas financieros de
apoyo de la institución
Analizar las transacciones que
realizan esta función.
Identificar la presencia de
mecanismos propietarios para
llevar a cabo la funcionalidad
requerida.
Segmentos
funcionales
Dominios
tecnológicos
Agrupación de sistemas,
utilizando como criterio el
objetivo que persiguen, para
determinar los segmentos
donde se ha enfocado la
institución.
Plataformas de desarrollo
utilizadas para la creación y
operación de los sistemas del
Banco.
Cantidad de
cada sistema
BackEnd.
Cantidad de
comunicación
sistema
Instrumentos de
recolección
de
datos
de Cuestionario
cada
conexiones de Cuestionario
con sistemas
tecnologías de
utilizadas por
Se
debe
inventariar
la Número de sistemas por área Cuestionario
funcionalidad principal para identificada
cada sistema operacional y de Porcentaje del total que
representa el servicio directo al
apoyo.
cliente
en
canales
de
distribución
Identificar
las
diferentes Número entero de plataformas Cuestionario
plataformas de desarrollo diferentes de desarrollo que
los
sistemas
utilizadas en la institución que soportan
financieros de apoyo.
se han originado en el tiempo.
30
Costos de operación Costo relacionado a la
y mantenimiento
operación normal
y al
mantenimiento
(nuevas
funcionalidades)
de
un
sistema
Vida útil de los Tiempo estimado en el cual
sistemas
un determinado sistema
pasará
a
etapa
de
obsolescencia
Implementación de De acuerdo con el criterio de
un nuevo servicio
expertos, el tiempo promedio
que toma desarrollar una
nueva funcionalidad en la
institución
Penetración de la Presencia e impacto de la
reutilización a través reutilización e integración de
de la integración de aplicaciones en la institución
aplicaciones
Diferencia de versión entre el
software actual y la última del
mercado
Diferencia
promedio
de
versión en los productos
tecnológicos utilizados
Costo
de
operación
y Cuestionario
mantenimiento por sistema
Costo total de operación y
mantenimiento de los sistemas.
Determinar los costos de
operación y mantenimiento que
significa para la institución la
operación de los sistemas
descritos.
Identificar la vida útil de cada Cantidad de sistemas que han Cuestionario
sistema financiero de apoyo de superado su vida útil
Variancia entre la vida útil
la institución.
estimada y el tiempo actual de
producción
promedio
de Cuestionario
Consultar con el dueño o Tiempo
administrador del sistema el implementación de servicios.
promedio
de
tiempo promedio para la Tiempo
implementación un nuevo implementación de servicios
módulo
de
complejidad por sistema
normal.
de
estrategias Cuestionario
Analizar la presencia de una Presencia
iniciativa
dirigida
a
la formales de reutilización e
reutilización y la integración. integración de aplicaciones.
de
sistemas
Una vez determinada su Cantidad
presencia se debe identificar el incorporados a la iniciativa
beneficio de esta iniciativa Cantidad de transacciones
reutilizadas
para la institución
31
3.4. Sujetos y fuentes de información
3.4.1. Definición de población
Se entiende por población un conjunto de elementos que pueden ser desde
personas, animales, empresas, organizaciones, objetos y otros. Así con el estudio se
pretende conocer las características del conjunto y generalizar los resultados o
conclusiones que se obtengan.
Una población posee la característica de ser finita o infinita. La población finita
tiene un número limitado de elementos, mientras que una población infinita la forman
un número ilimitado. Como existen sujetos encargados de cada uno de los sistemas
financieros de la institución, y este número es limitado, se procedió a definir como la
siguiente población finita: “los sistemas financieros que apoyan la gestión del Banco
Nacional de Costa Rica”. Esta definición excluye claramente a sistemas de apoyo
administrativo y logístico, pues la estrategia de la administración de la institución es la
compra de este tipo de sistemas.
A continuación se detalla cada uno de los 23 sistemas que se considerarán en
esta investigación:
Consecutivo
Descripción
Arquitectura
1 ARCHIVO VIRTUAL
N capas
2 BACOSI (imágenes de cheques)
N capas
3 BN CONECTIVIDAD
Cliente Servidor
4 BN BANCA TELEFONICA
Monolítico
5 BN PAGUESE
N capas
6 BN SINPE
N capas
7 BN VEP
N capas
8 BN VIAJES
N capas / Cliente Servidor
9 BUC
N capas
10 CALL CENTER
Cliente Servidor
32
11 DDO
N capas
12 FINESSE
Cliente Servidor
13 FIRMAS
Cliente Servidor
14 INTERNET BANKING CORPORATIVO
N capas
15 INTERNET BANKING PERSONAL
N capas
16 MOPAA
Cliente Servidor
17 PIA
N capas
18 SFB
Monolítico
19 SARCLI
Cliente Servidor
20 SETBN
Monolítico
21 SIACC
Cliente Servidor
22 SISAE
N capas
23 TARJETAS DE CREDITO
Cliente Servidor
Cuadro #1. Sistemas financieros del Banco Nacional
Fuente: Dirección Desarrollo de Sistemas, BNCR
3.5. Instrumentos de recolección de datos
Debido a que en la Dirección Corporativa de Tecnología y Operaciones existen
encargados técnicos de cada uno de los sistemas en la población y que la cantidad de
información por obtener de los ingenieros es similar, se utilizó como instrumento de
recolección de datos el cuestionario, el cual fue planteado con preguntas muy generales
al principio, hasta otras muy concretas al final.
El cuestionario se aplicó a los funcionarios a partir de la tercera semana de
octubre de año 2004. Para su aplicación se procedió a realizar una breve explicación del
objetivo del estudio y de la importancia que tiene contestar adecuadamente cada
pregunta. El último cuestionario fue entregado por los ingenieros de la Institución en la
tercera semana de noviembre del año 2004.
33
3.6. Alcances y limitaciones de la investigación
3.6.1. Alcances
La presente investigación plantea como alcance realizar un diagnóstico de la
situación actual de los sistemas financieros que apoyan la gestión del Banco Nacional.
Con base en ese diagnóstico y la teoría planteada por la industria, se debe determinar la
factibilidad de aplicar una Arquitectura Orientada a Servicios en la Institución y una
propuesta de estrategia para su adopción.
3.6.2. Limitaciones
•
En esta investigación no se considera la resolución de aspectos tecnológicos para
implementar soluciones particulares, por cuanto este aspecto forma parte de un
plan táctico y operativo más detallado.
•
Una gran cantidad de información sensible de la Institución no será difundida en
este documento, por cuanto violenta las políticas de Seguridad Informática de la
Institución.
•
El planteamiento de las Arquitecturas Orientadas a Servicios es reciente en la
industria, por lo cual en Costa Rica no se conoce algún caso de éxito para tomar
como referencia práctica. Por esta razón, el enfoque de esta investigación tiene
un alto elemento teórico.
CAPITULO IV
ANALISIS E INTERPRETACION DE
RESULTADOS
35
4.1. Análisis de la información
A continuación se detallan los criterios más importantes que se infieren una vez
realizada la recopilación de los datos, los cuales permiten examinar en detalle las
variables planteadas con el objetivo de identificar características importantes acerca de
la situación actual de los sistemas financieros de apoyo que operan en la institución.
4.1.1. Redundancia funcional
El crecimiento de los sistemas transaccionales del banco ha sido, históricamente,
una secuencia de buenas intenciones que han originado excelente calidad funcional de
cara al usuario final, pero con un alto porcentaje de redundancia para las transacciones
que son más comunes en la institución.
Como se muestra en el gráfico #1, una consulta de cuentas relacionadas a una
identificación presenta ocho diferentes opciones para escoger, cada una basada en las
necesidades particulares del sistema que la solicitó. Desde el punto de vista de
integración lo ideal es que se cuente con una definición clara y universal de esta
consulta, la cual sea publicada como un servicio que satisfaga las necesidades de todos
los sistemas que la utilizan.
Para que este planteamiento de integración sea válido, el middleware debe
identificar claramente que sistema “cliente” requiere de sus servicios y, de acuerdo con
las necesidades descritas por este sistema, cómo debe comportarse y retornar la
información suficiente para que se cumpla el objetivo inicial de la transacción.
Un ejemplo claro de esta problemática, amparado en la información recolectada,
es el caso de la transferencia de fondos. Cuando ha sido necesario habilitar la
transferencia entre monedas nuevas como el Euro, se ha necesitado modificar al menos
cinco diferentes programas que brindan esta solución en el sistema central, modificar la
interfase de los sistemas con dicho sistema y adicionalmente modificar la capa de
presentación.
36
Banco Nacional de Costa Rica
Funcionalidad común en sistemas financieros
Diciembre 2004
a) Cuentas cliente
b) Tarjeta crédito
c) Préstamos de un cliente
d) Recibos pendientes
e) Saldo de cuenta
f) Movimiento de cuenta
g) Transferencia de fondos
h) Pago de servicios
i) Pago tarjeta crédito
j) Pago préstamo
k) Avance efectivo
l) Aporte BN-Vital
m) Inversión BN-Fondos
0
2
4
6
8
Gráfico #3: Funcionalidad común entre sistemas financieros del banco.
Fuente: Elaboración propia
A la luz de estos datos se encuentra que para cada funcionalidad común
identificada se tiene como mínimo tres componentes tecnológicos que la resuelven y un
máximo de ocho, lo cual indica una fuerte tasa de redundancia.
4.1.2. Islas tecnológicas
Producto de la investigación se ha identificado una gran cantidad de mecanismos
para comunicarse con los sistemas más importantes de la institución, lo cual se agrava
cuando se toma en cuenta que el SFB, reconocido como el sistema más importante en la
institución, cuenta con 5 formas diferentes de comunicación y al menos 14 interfaces
formales identificadas (no se tomó en cuenta para el estudio el intercambio de
información asincrónico, como el envío de archivos mediante FTP).
37
De acuerdo con el gráfico #2, se interpreta que el modelo de comunicación más
utilizado en la institución lo representan los programas “sockets” basados sobre TCP/IP,
esto supone un alto esfuerzo de integración con el sistema central, debido a que
tradicionalmente estos programas se han desarrollado a lo interno de la institución de
forma “artesanal”. Desde el punto de vista de la administración esta información se
traduce en un aumento en los costos de construcción de los sistemas y un periodo de
entrega más largo.
Banco Nacional de Costa Rica
Modelos de comunicación con SFB
Diciembre 2004
21%
Socket
MCSII
7%
51%
COMS
PIA
21%
Gráfico #4: Modelos de comunicación con el Sistema Financiero Bancario.
Fuente: Elaboración propia
Los sistemas de colocación del banco (SIACC y Tarjeta de Crédito) y el sistema
central de convenios se encuentran implementados utilizando bases de datos
relacionales, sin embargo el mecanismo por el cual los sistemas cliente establecen
comunicación con los mismos tampoco está regulado. Dentro de la variedad de
posibilidades de comunicación que existen actualmente se encuentran consultas directas
a la base de datos al emplear lenguaje SQL, consumo de procedimientos almacenados
implementados en su mayoría con necesidades particulares del sistema que lo solicitó,
programas de tipo “socket” de comunicación para envío de tramas y hasta la
comunicación con la Plataforma de Integración de Aplicaciones mediante el concepto
de middleware.
38
Como se puede analizar de los datos presentados en el gráfico #3, existen
alrededor de 8 interfases que se establecen mediante “socket”, 21 establecidas mediante
procedimientos almacenados y 6 consultas directas a la base de datos. Este caso y sus
consecuencias son similares a los expuestos para el SFB, desde el punto de vista de
incremento en tiempos de entrega y costos, con el agravante de que si existen consultas
directas a la base de datos, la aplicación depende 100% de esta capa para su ejecución.
Banco Nacional de Costa Rica
Modelos utilizados por las aplicaciones Front End para
comunicarse con sistemas centrales
Diciembre 2004
10
9
8
7
6
5
4
3
2
1
0
10
Tarjetas
Crédito
Convenios
6
5
3
3
3
2
2 2 2
1
0
SP
Consulta
PIA
Socket
Gráfico #5: Modelos utilizados para la comunicación front end – Sistemas Centrales.
Fuente: Elaboración propia
4.1.3. Segmentos funcionales
Debido a la gran cantidad de servicios que presta la institución, y al crecimiento
histórico que ha experimentado, se han desarrollado una gran cantidad de sistemas
centrales que administran y regulan la prestación de cada servicio en particular.
Adicionalmente se han implementado sistemas para la atención del cliente, utilizando la
mayoría de canales de distribución para una institución financiera tales como Internet,
cajeros automáticos, banca por teléfono (IVR), ventanilla, entre otros.
39
Proporcionalmente, la institución cuenta con un 26% de sus sistemas financieros
de apoyo enfocados a la atención del cliente en forma directa y un 35% de esos sistemas
enfocados a la persistencia de datos de cada uno de los servicios en particular, tal y
como se puede visualizar en el gráfico #4.
Si se toma en cuenta que los sistemas para apoyo operativo y el middleware
apoyan la gestión entre los sistemas cliente y los sistemas centrales, se puede inferir que
un 91% de los sistemas financieros están enfocados a la atención del cliente.
Banco Nacional de Costa Rica
Sistemas financieros por categoría
Diciembre 2004
Canal de distribución
4%
9%
26%
Apoyo operativo
Sistema central
Middleware
35%
26%
Apoyo a toma de
decisiones
Gráfico #6: Categorías de los sistemas financieros en el BNCR.
Fuente: Elaboración propia
40
4.1.4. Dominios tecnológicos
A través del tiempo la institución ha implementado sus servicios financieros
haciendo uso de diversas plataformas tecnológicas, de acuerdo con la necesidad
imperante en ese momento y las posibilidades dadas por la misma industria. Como los
dominios aplicativos pueden ser distintos a los dominios de base de datos que permiten
la operación del sistema, se ha dividido esta variable en dominios para desarrollo de
aplicaciones y dominios para persistencia de datos.
Para el desarrollo de aplicaciones se identificaron 5 grandes plataformas de
desarrollo de software, lo cual indica una amplia diversidad de conocimiento necesario
para el mantenimiento de la plataforma tecnológica del banco y un elevado costo por
concepto de licenciamiento, soporte y otros. Como se observa en el gráfico #5 existe
una amplia penetración de las plataformas Microsoft y Oracle para desarrollo de
aplicaciones; sin embargo el SFB está desarrollado en plataforma Unisys en el lenguaje
de programación llamado Linc; razón por la cual a pesar que representa un 12% del
total, su implementación es vital para la institución.
Banco Nacional de Costa Rica
Dominios para desarrollo de aplicaciones
Diciembre 2004
8%
12%
12%
20%
Unisys
Sybase
Microsoft
Oracle
Siebel
48%
Gráfico #7: Dominios para el desarrollo de aplicaciones.
Fuente: Elaboración propia
41
En cuanto a la persistencia de datos se identificaron 3 grandes plataformas para
implementar esta administración. De acuerdo con lo expuesto en el gráfico #6 existe
una amplia penetración de las plataformas Microsoft y Oracle, pero aplica la misma
observación que se realizó para la plataforma Unisys en el caso anterior.
Banco Nacional de Costa Rica
Dominios para administrar bases de datos
Diciembre 2004
26%
13%
0%
Unisys
Sybase
Microsoft
61%
Oracle
Gráfico #8: Dominios para administrar bases de datos.
Fuente: Elaboración propia
4.1.5. Costos de operación y mantenimiento.
En la medición de esta variable se deben destacar algunas revelaciones
importantes. Por ejemplo, los expertos consideraron que un 83% de los sistemas
analizados presentan costos de operación y mantenimiento de menos de US $100,000
anuales. Este porcentaje es representado por 19 sistemas, los cuales a pesar de su costo
relativamente bajo requieren de recursos especializados para el mantenimiento de la
tecnología que poseen, tal y como se analizó en lo que respecta a las islas tecnológicas.
Tomando como referencia los costos estimados por los expertos, y haciendo una
proyección conservadora de los costos, la cual consiste en tomar en cuenta para todos la
cifra intermedia entre el límite inferior y superior del rango indicado, se obtiene
aproximadamente un costo de US $2,300,000.00, equivalente a más de mil millones de
colones, inversión que indudablemente la institución debe realizar de la mejor manera,
para garantizar su permanencia como líder del mercado.
42
Banco Nacional de Costa Rica
Costo de operación y mantenimiento de los sistemas
Diciembre 2004
Muy bajo (Menos de 25,000)
2, 9%
1, 4%
Bajo (25,000 a 99,999)
1, 4%
9, 39%
Medio (100,000 a 249,999)
Alto (250,000 a 500,000)
Muy Alto (Más de 500,000)
10, 44%
Gráfico #9: Costo de operación y mantenimiento de los sistemas financieros.
Fuente: Elaboración propia
4.1.6. Vida útil de los sistemas.
La medición de esta variable se realizó utilizando como punto de partida los
dominios tecnológicos descritos anteriormente. El aspecto más importante que se
necesita describir es la situación actual de los sistemas financieros en relación con el
software sobre el cual han sido desarrollados; y de esta manera identificar la existencia
de algún riesgo relacionado con versiones obsoletas. Como el objetivo de la
investigación es proponer una estrategia fundamentada en datos reales, se consideraron
los elementos que permitieran tener un escenario completo a un alto nivel.
De acuerdo con las estimaciones de los expertos en cada sistema, un 82.5% de
los sistemas fueron diseñados para contar con una vida útil superior a los 4 años. No
obstante es necesario destacar que; del total de los sistemas, un 40% han alcanzado el
umbral de su vida útil para el año 2004. Como se observa en el gráfico #8, para el año
2005 otro 22% de los sistemas alcanzará su umbral, por lo cual se puede deducir que a
finales de ese año un 62% de los sistemas de la institución se encontrarán al menos
cerca del final de su vida útil.
43
Banco Nacional de Costa Rica
Año de entrada al umbral de vida útil estimada de
los sistemas financieros
Diciembre 2004
4%
4%
2004 o inferior
40%
30%
2005
2006
2007
22%
2008
Gráfico #10: Año de entrada al umbral de vida útil de los sistemas financieros.
Fuente: Elaboración propia.
Otro aspecto interesante en este análisis tiene que ver con la tecnología que hace
posible el funcionamiento de estos sistemas. Al respecto es importante mencionar en
primera instancia el caso de las versiones de Oracle que soportan la ejecución de
algunos de los sistemas de misión crítica de la institución. Como se observa en el
gráfico #9, las versiones utilizadas en producción para el funcionamiento de los
sistemas son muy inferiores a las versiones recomendadas por Oracle, como 9i ó 10g.
Banco Nacional de Costa Rica
Distribución de versiones de Oracle en los
sistemas financieros
Diciembre 2004
17%
7.3.4
8.1.6
50%
8.1.7.4
33%
Gráfico #11: Distribución de versiones de Oracle utilizadas en sistemas financieros.
Fuente: Elaboración propia.
44
Cuando se analiza la situación de los sistemas financieros que utilizan la
plataforma Microsoft SQL Server para su operación, el comportamiento difiere de la
plataforma Oracle en cuanto a que la mayoría utiliza la última versión publicada por el
proveedor. Como se puede observar en el gráfico #10, los sistemas que no utilizan la
última versión al menos emplean la anterior y esto significa que todas las versiones de
este producto en la institución son plataformas soportadas por Microsoft Corporation.
Banco Nacional de Costa Rica
Distribución de versiones de SQL Server en los
sistemas financieros
Diciembre 2004
43%
7.0
2000
57%
Gráfico #12: Versiones de Microsoft SQL Server utilizadas en sistemas financieros.
Fuente: Elaboración propia.
Es de suma importancia destacar que los sistemas que han pasado el umbral de
su vida útil y que son un riesgo potencial, a pesar de la estabilidad demostrada durante
años de operación, son de los más importantes para la operación de la institución. En el
gráfico #11 se muestran sistemas centrales de la trascendencia del SFB o tarjeta de
crédito y también canales de distribución como el sistema de cajas, banca por Internet,
cajeros automáticos y banca telefónica superando el umbral de su vida útil, algunos de
ellos antes del año 2004.
Otro dato relevante para la institución es que la Plataforma de Integración de
Aplicaciones; parte esencial del middleware de la institución, es de reciente
implantación y no entrará al umbral de su vida útil sino hasta el año 2007.
45
Banco Nacional de Costa Rica
Sistemas financieros que han alcanzado el umbral de vida útil
Diciembre 2004
2004
2002
2000
Año umbral
de vida útil
1998
1996
1994
1992
1990
1988
SFB
Tarjet a de
crédito
BN-Int ernet
Banking
Corporat ivo
BN-Banca
Telef ónica
BNConectividad
BN-Int ernet
Banking
Sistema de
cajeros
(Finesse)
SETBN
Firmas
Gráfico #13: Sistemas financieros que han alcanzado el umbral de vida útil.
Fuente: Elaboración propia.
4.1.7. Implementación de un nuevo servicio.
Para analizar esta variable se utilizó como parámetro el desarrollo de un nuevo
módulo para cada sistema en estudio; entendiendo la palabra módulo como un conjunto
de nuevas funcionalidades relacionadas. Este aspecto presenta una gran ventaja desde el
punto de vista de análisis de datos, pues la comprensión del tamaño y la complejidad de
cada módulo están relacionadas con el sistema al que pertenece.
De acuerdo con los datos analizados en esta investigación, se ha determinado
que aproximadamente un 74% de los sistemas tienen prevista una duración de más de
un mes para construir un nuevo módulo, tal como está representado en el gráfico #12.
A simple vista este dato parece no tener mucha relevancia, sin embargo si se
toma en cuenta que la medición considera sistemas centrales y canales, además
normalmente los servicios que se publican implican relación entre ellos; se podrá
dimensionar lo difícil de obtener que el desarrollo se lleve a cabo en la misma línea de
tiempo para diferentes sistemas. Este aspecto y la complejidad de implantar los cambios
realizados, indica que el problema no se limita a la construcción de los servicios en sí,
sino también a la reutilización y la integración que se haga entre ellos.
46
Banco Nacional de Costa Rica
Tiempo promedio para implementar un nuevo módulo
en sistemas financieros
Diciembre 2004
Muy bajo (2 semanas)
9%
17%
Bajo (2-4 semanas)
26%
9%
Normal (1-2 Meses)
Alto (2-3 Meses)
Muy Alto (+ 3 Meses)
39%
Gráfico #14: Tiempo estimado para implementar un nuevo módulo en los sistemas.
Fuente: Elaboración propia
4.1.8. Penetración de reutilización mediante la integración de aplicaciones
Desde el año 2001 la Dirección de Desarrollo de Sistemas ha impulsado y
fortalecido el tema de la Integración de Aplicaciones, esfuerzos que se tradujeron en
realidad en el año 2003 con la puesta en producción de la Plataforma de Integración de
Aplicaciones.
La plataforma ha permitido a la Institución solventar una serie de problemas
presentados en sus sistemas de banca por Internet, sin embargo a la fecha sólo este
sistema utiliza formalmente los lineamientos definidos por esta iniciativa y también es
el único sistema integrado en dicha plataforma. Ello significa que existe un amplio
potencial de crecimiento en dicha tecnología que está siendo subutilizado y que podría
brindar mayor valor agregado de cara a los conceptos de reutilización e integración. Por
esta razón no existe hasta el momento una transacción reutilizada entre varios sistemas,
pues solamente el caso mencionado se encuentra alineado a la plataforma.
47
4.2. Interpretación de resultados
4.2.1. Diagnóstico basado en la observación.
De acuerdo con esta investigación se puede indicar que el Banco Nacional posee
una arquitectura donde predominan las islas tecnológicas, las cuales a su vez han
generado una gran cantidad de mecanismos para comunicarse entre sí. Estas interfaces
de comunicación no están reguladas y mientras no se aplique una medida correctiva al
respecto, seguirán creciendo de la misma manera. Esta tendencia se evidencia
claramente en las fechas de implantación de los sistemas financieros, las cuales revelan
que desde la creación del SFB en el año 1990 hasta la implementación de los nuevos
sistemas del año 2004, no se ha planteado una solución efectiva a esta problemática.
Producto de esta proliferación de islas tecnológicas, y de la misma presión del
negocio, el banco ha necesitado crecer en este modelo arquitectónico y fortalecerlo para
garantizar aspectos tan importantes como la continuidad del negocio y el servicio al
cliente; lo cual ha generado que se implementen múltiples piezas de código que realizan
una función similar incluso dentro de un mismo sistema central. Esta redundancia
funcional ocurre cuando un sistema cliente requiere una transacción previamente
desarrollada para otro, pero con algunos datos de más o un comportamiento particular
en determinada circunstancia; en ese momento la decisión más rápida y sencilla de
implementar es la creación de una nueva transacción. Con el paso del tiempo esta
situación ha dificultado el mantenimiento de los sistemas centrales de la Institución y la
implementación de nuevos servicios, pues para su creación normalmente requiere un
desarrollo completo en el sistema central.
Como se mencionó en el apartado 2.1 del marco teórico, parte de la estrategia de
la Gerencia General de la Institución es precisamente adoptar las mejores prácticas
promovidas por la industria, con el objetivo de eliminar aplicaciones e interfaces. Si se
logra concretar una propuesta que impulse la nueva arquitectura, se avanza en la
reducción de interfaces entre aplicaciones y complejidad tecnológica, puesto que de
48
acuerdo con el apartado 2.5.2 del marco teórico, uno de los beneficios que provee una
Arquitectura Orientada a Servicios es precisamente el impulso que, por sus propias
características, este tipo de patrones brindan al concepto de reutilización.
El tema de gobernabilidad de TI es otro aspecto complejo por considerar en la
situación actual de la Institución, porque cuando existe una regla de negocio publicada
de distintas maneras en los sistemas centrales, y con el agravante de ser consumidas
mediante distintas interfaces, se genera un gran esfuerzo técnico y administrativo para
mantener y operar esta arquitectura. Mediante la implementación y el fortalecimiento
de las mejores prácticas en cuanto a la reutilización se espera que SOA brinde dentro de
sus beneficios la reducción de la complejidad de la administración y gobierno de TI.
Al observar los dominios tecnológicos que han surgido en la organización se
puede concluir que a nivel de sistemas centrales existen tres tecnologías predominantes
con una amplia penetración en la estructura operativa de la Institución. También se
determinó que los sistemas centrales basados en la plataforma Unisys han consumido su
vida útil hace mucho tiempo; y debido a su tecnología “mainframe” cuentan con un alto
costo de operación, desarrollo de nuevas funcionalidades y licenciamiento.
Los sistemas centrales basados en plataformas Oracle han mostrado un
comportamiento anormal con respecto a la versión utilizada del producto. En el caso del
Sistema de Tarjeta de Crédito cuenta con la versión 7.3.4, la cual ya no es cubierta por
el fabricante del software en caso de requerir soporte técnico.
En general, de acuerdo con la investigación realizada se determinó que al
concluir el año 2005 al menos un 62% de los sistemas financieros de la Institución
habrán agotado su vida útil; y si se toma en cuenta que la plataforma tecnológica sobre
la cual fueron desarrollados también presenta problemas de actualización, se podrá
observar la necesidad de llevar a cabo una acción inmediata con estos sistemas,
especialmente los de misión crítica.
49
4.2.2. Oportunidad de impulsar SOA.
Este conjunto de hechos demostrados hacen que la adopción de SOA adquiera
mayor valor al considerar el apartado 2.6 del marco teórico “Elementos generales para
adoptar SOA”. En ese apartado se mencionó la importancia de mantener el valor de los
activos existentes para no provocar una mayor inversión; por lo cual de acuerdo con la
teoría, estos sistemas son casos adecuados para iniciar un ciclo de convergencia
tecnológica en el cual se publique la funcionalidad de cada sistema central como
servicios en la nueva arquitectura, mientras se inicia el proceso de sustitución paulatina
de la plataforma tecnológica sobre la cual operan.
Otro resultado de la investigación fue observar que, a pesar de los múltiples
esfuerzos llevados a cabo por la Dirección Corporativa de Tecnología y Operaciones, no
se ha logrado la consolidación definitiva de la utilización de la Plataforma de
Integración de Aplicaciones como el corazón transaccional de la Institución. A pesar de
la estabilidad y rendimiento demostrado durante más de un año, en este momento
solamente se encuentra integrado el sistema de E-Banking dicha plataforma. Muchos de
los principios importantes que este sistema busca consolidar en la organización (como
reutilización, entre otros) no han logrado la penetración requerida, de manera que
problemas mencionados anteriormente como la redundancia funcional, no hallan una
respuesta oportuna en esta implementación tecnológica.
Finalmente se identificó una iniciativa de la DCTO desde el punto de vista
tecnológico para publicar y consumir Web Services, denominado “Conector Universal”.
Este componente de software ha sido conceptualizado como una capa de
comunicaciones intermedia entre la Plataforma de Integración de Aplicaciones y las
organizaciones externas al banco. Esta interface será implementada mediante la
utilización de estándares de la industria para el catálogo y publicación de los servicios.
De acuerdo con BNCR (2004) “El conector universal provee un modelo de
integración de aplicaciones más centralizado, donde un hub de integración se coloca
entre los sistemas del Banco y los de sus socios de negocios.
50
La diferencia con el escenario actual está, en que cada sistema no necesita de
una nueva conexión construida a su medida, sino que todos los sistemas externos
utilizarán un único punto de entrada a los sistemas del Banco. Esta conexión, estará
basada en estándares de la industria (como XML, SOAP, WSDL) lo que implica que la
interconexión con aplicaciones en otros sistemas operativos, lenguajes de programación,
manejo de excepciones, manejo de errores y demás, es de muy bajo costo de
mantenimiento”.
Gráfico #15: Arquitectura conceptual del Conector Universal.
Fuente: Banco Nacional de Costa Rica.
CAPITULO V
CONCLUSIONES Y RECOMENDACIONES
52
5.1. Conclusiones
La investigación realizada ha demostrado que la Dirección Corporativa de
Tecnología y Operaciones del Banco Nacional cuenta con una gran cantidad de
elementos por resolver en su infraestructura tecnológica para el año 2005, y de esta
manera garantizar que el banco está preparado para los retos que la industria visualiza
para el año 2006.
A pesar de contar con un alto porcentaje de sistemas enfocados al cliente, los
sistemas financieros más importantes de la institución son los sistemas centrales que
administran los productos y servicios básicos para su operación; entre estos destacan los
sistemas de cuentas corrientes, ahorros, inversiones, tarjetas de crédito, préstamos y
pago de servicios diversos. Estos sistemas se encuentran en producción hace varios años
y han mostrado un excelente desempeño y gran estabilidad, sin embargo poseen
características como un alto costo de operación y versiones de software declaradas
obsoletas por los fabricantes, las cuales hacen necesaria una estrategia para alinearlos a
los objetivos planteados por la Gerencia General.
En este caso se menciona alinear los sistemas en lugar de sustituirlos, pues
también se ha logrado concluir que los dominios tecnológicos presentes en la Institución
están bien definidos y estables. De acuerdo con lo estudiado en la teoría, no es
recomendable desestabilizar la operación normal mediante la sustitución inmediata de
los activos existentes, sino que se debe plantear una solución que permita realizar
tácticamente proyectos incrementales que mejoren, o a largo plazo, sustituyan el modelo
aplicativo actual.
Se ha logrado determinar la necesidad de disminuir la redundancia funcional y las
islas tecnológicas presentes en la plataforma tecnológica de la Institución, pues estos
factores dificultan el desarrollo de nuevos servicios y su implantación en producción,
mientras que aumentan los costos de mantenimiento y operación.
53
La tecnología por sí misma no es suficiente para lograr los cambios requeridos en
la Institución; esto queda demostrado cuando se toma en cuenta que la implementación
y funcionamiento de un middleware de excelentes características técnicas como la
Plataforma de Integración de Aplicaciones, no ha logrado solventar en dos años los
problemas descritos en esta investigación. Por el contrario, si no existe una estrategia
clara para cambiar el modelo arquitectónico del banco, la PIA presentará a corto plazo
los mismos problemas que aquejan al resto de los sistemas.
La implementación del Conector Universal, a pesar de encontrarse basado 100%
en Web Services, no acerca por sí sola a la organización a una Arquitectura Orientada a
Servicios, pues está claro desde el punto de vista de la industria que SOA no se puede
entender como el simple uso de Web Services.
La situación actual del Banco Nacional de Costa Rica es propicia para aprovechar
los beneficios que brinda la adopción de una Arquitectura Orientada a Servicios para
reducir el impacto inmediato de un cambio de tecnologías y brindar el tiempo necesario
para continuar con el ciclo de convergencia. En este caso, plantear una estrategia que
permita la utilización y posicionamiento de la Plataforma de Integración
de
Aplicaciones y la implementación del concepto de Conector Universal serán
determinantes para obtener el éxito en esta iniciativa.
54
5.2. Recomendaciones
5.2.1. Estrategia de adopción de SOA en el Banco Nacional
Una estrategia es una visión de largo plazo que tiene como objetivo organizar la
toma de decisiones, estableciendo el orden de prioridades en que se deben evaluar las
posibles soluciones según los objetivos estratégicos, los cuales deben ser medidos con
la obtención de metas también llamadas indicadores de logro.
El objetivo de esta estrategia es proporcionar al Banco Nacional de Costa Rica
una adecuada preparación para los retos tecnológicos que se presentarán en el mercado
financiero y la industria de la tecnología a largo plazo, mediante la adopción de una
Arquitectura Orientada a Servicios, la cual permita eliminar aplicaciones e interfaces,
proporcione información en tiempo real, reduzca los costos de operación de la
infraestructura y disminuya los tiempos de entrega de productos y servicios.
5.2.2. A la Gerencia General del Banco Nacional de Costa Rica
•
Incorporar el tema de adopción de una Arquitectura Orientada a Servicios
como parte del Plan Maestro de Implementación del Banco Nacional para
los años 2005, 2006 y 2007; con el fin de definir una alta prioridad al
proceso.
•
Definir el comité de Arquitectura del Negocio, encargado de la ejecución de
los proyectos necesarios para la adopción de SOA en la institución.
•
Promover y patrocinar la ejecución de los proyectos propuestos por la
DCTO, para alcanzar los objetivos planteados en torno a la reducción de
costos, aplicaciones y desarrollos hechos en casa.
•
Llevar a cabo las medidas administrativas pertinentes para que la
organización se identifique plenamente con el proceso.
55
5.2.3. A la Dirección Corporativa de Tecnología y Operaciones.
•
La DCTO debe plantear dentro de su Plan Estratégico de Tecnologías de
Información (PETI) la adopción de una Arquitectura Orientada a Servicios
como un medio para alcanzar los objetivos planteados por la Gerencia.
•
Fomentar el “empowerment” al negocio, para que éste se involucre de lleno
en el proceso de adopción de la nueva arquitectura; desde el punto de vista
de patrocinio como la ejecución misma de proyectos que la promuevan.
•
Crear un comité de Arquitectura de TI que trabaje bajo la dirección del
comité de Arquitectura del Negocio. Este comité debe velar por el
cumplimiento de las metas fijadas para el proceso de adopción de SOA a
nivel de TI y garantizar que los proyectos ejecutados por esta Dirección,
generen un verdadero valor agregado al negocio.
•
Garantizar la ejecución correcta de proyectos de infraestructura que aseguren
la correcta operación de la SOA del Banco Nacional y cumplimiento de
contratos de servicios con proveedores.
•
Divulgar en todos los niveles de la jerarquía organizacional la nueva
arquitectura y fomentar el desarrollo de iniciativas que la utilicen.
•
Impedir en la medida de lo posible el crecimiento de la infraestructura de
mainframes y sistemas centrales hasta tanto se tenga claridad de los pasos
por seguir con esos sistemas.
•
Enfocar la inversión de recursos internos en los sistemas financieros de la
Institución. Sistemas de apoyo logístico u operativo pueden ser adquiridos y
adaptados, de manera que el enfoque de la Dirección sea exclusivamente
hacia el negocio bancario.
56
5.2.4. A la Dirección Desarrollo de Sistemas de Información.
•
La DDSI debe coordinar el correcto crecimiento de los sistemas que tiene
actualmente a su cargo, considerando el tema de SOA de antemano, de
manera que los esfuerzos realizados en el modelo arquitectónico actual sean
estrictamente necesarios.
•
Ejecutar proyectos tecnológicos que busquen la adopción y consolidación de
SOA en la organización.
•
Apoyar fuertemente los proyectos institucionales los cuales busquen la
transformación del negocio y de TI, de manera que se asegure al banco que
los proyectos están siendo orientados en todo momento donde deben.
•
Fortalecer las iniciativas tecnológicas alineadas a los estándares de la
industria, tales como PIA y el Conector Universal.
•
Organizar un plan de permanente capacitación para todas las áreas del Banco
Nacional en temas relevantes para la nueva arquitectura.
•
Dictar lineamientos y estándares acordes a la nueva arquitectura, así como
eliminar los desarrollos sobre programas tipo socket y otros mecanismos
artesanales de comunicación.
•
Garantizar la penetración y utilización de las mejores prácticas para el
desarrollo y reutilización del software, tanto del desarrollado sobre la nueva
arquitectura como en los modelos de desarrollo tradicional.
CAPITULO VI
PROPUESTA
ESTRATEGIA DE CONVERGENCIA
TECNOLÓGICA
58
6.1. Identificación de la propuesta
Una vez analizada la situación actual de los sistemas del Banco Nacional de
Costa Rica y emitidas las conclusiones y recomendaciones que esta investigación ha
originado; se propone la siguiente estrategia de implementación de una Arquitectura
Orientada a Servicios en la Institución.
El enfoque por seguir para definir la estrategia de implementación es el
siguiente:
•
Identificar las áreas estratégicas que debe organizar el Banco para la
implementación del nuevo concepto arquitectónico.
•
Definir objetivos de cada una de las áreas de acuerdo con el marco teórico.
•
Definir la implementación de los objetivos de cada área mediante la
ejecución de actividades originadas por esta iniciativa u otras que se
encuentran en ejecución.
•
Agrupar y priorizar los proyectos mediante un portafolio de proyectos, cuya
ejecución exitosa debe ser responsabilidad del grupo de Arquitectura
Corporativa de la Institución.
6.2. Identificación de áreas estratégicas
6.2.1. Estrategia de negocios
De acuerdo con el análisis llevado a cabo en la Institución; y conforme lo indica
la teoría, el principal esfuerzo que se debe llevar a cabo gira en torno al nuevo enfoque
centrado totalmente en los modelos de negocio; sin embargo este esfuerzo no se
centraliza en los departamentos de TI sino que trasciende al plano estratégico de la
organización.
59
El Banco Nacional necesita articular la estrategia de negocios mediante la
identificación y categorización de los procesos críticos del negocio para formar un
marco de trabajo para SOA. Una vez identificados los problemas del negocio se deben
definir soluciones coherentes y repetitivas; es hasta este momento donde se piensa en
una implementación mediante la incorporación de tecnología.
La estrategia de negocios debe indicar claramente la visión del negocio con
respecto a la prestación de servicios financieros, de manera que se posea certeza de los
nichos de mercado en los que el banco desea incursionar, mantenerse o incluso retirarse.
Una vez identificados esos sectores a nivel gerencial, se deben definir tácticamente los
productos y servicios que se brindarán al cliente para garantizar un nivel de excelencia
en el servicio.
6.2.2. Arquitectura
El Banco Nacional debe implementar un marco de trabajo para su arquitectura
que permita ensamblar componentes y servicios para una entrega rápida y dinámica de
las soluciones tecnológicas que necesita el negocio. Es evidente que dentro del concepto
de marco de trabajo están implícitos los patrones que soportan el nuevo modelo
arquitectónico.
Desde el punto de vista de SOA, la Plataforma de Integración de Aplicaciones
debe ser fortalecida para transformar su enfoque netamente transaccional y convertirlo
en una plataforma que soporte y exponga servicios, mediante la incorporación de los
estándares de la industria para el análisis, diseño, construcción, publicación,
descubrimiento y consumo de Web Services.
Es importante indicar la necesidad de analizar este proceso de fortalecimiento
basado en la plataforma tecnológica actual que soporta PIA, o bien determinar si para el
negocio es preferible la incorporación de otros componentes que fortalezcan y
complementen esta plataforma. Este análisis debe ser enfocado desde los puntos de vista
estratégico, económico, operativo y técnico.
60
6.2.3. Proyectos y aplicaciones
Paralelo al crecimiento de la nueva arquitectura, se debe vigilar que el desarrollo
de nuevos proyectos y aplicaciones sean planificadas como servicios, desde el punto de
vista conceptual. En otras palabras, las nuevas aplicaciones deben ser planteadas para
ser utilizadas por todos los sectores del negocio, lo cual debe detener el crecimiento de
la redundancia funcional y los mecanismos caseros para comunicar sistemas en la
Institución.
La Dirección Corporativa de Tecnología y Operaciones debe ser la encargada de
promover esta iniciativa y de provocar la disminución de redundancia funcional en la
Institución, mediante iniciativas que tácticamente permitan una sustitución incremental
de los principales problemas de la Institución.
6.2.4. Organización y gobierno
Los procesos mencionados hacen necesaria la definición de roles y
responsabilidades en torno a la adopción de la nueva arquitectura. Por esta razón es
necesaria la creación de un comité de Arquitectura del Negocio, compuesto por
funcionarios que posean un alto dominio del negocio bancario y con una visión clara del
rumbo que deben tomar las iniciativas financieras de la Institución.
Este comité será el responsable de definir los roles y responsabilidades de cada
dependencia funcional involucrada en el proceso; además de orquestar todos los
esfuerzos que lleva a cabo la organización, de manera tal que las iniciativas de TI se
encuentren apoyando oportunamente al negocio financiero del banco. Se sugiere que
este comité cuente con un representante a nivel ejecutivo de las siguientes áreas
funcionales:
- Proyectos institucionales.
- Banca electrónica.
- Banca de negocios.
- Banca de desarrollo.
- Banca de inversión.
- Crédito.
- Operaciones.
- Tecnología.
61
6.3. Portafolio de proyectos propuesto
adopción incremental de SOA
para
la
Como se analizó en el punto 2.5 del marco teórico “Elementos generales para
adoptar SOA” el proceso de adopción de este tipo de arquitecturas debe ser incremental
y enfocado a diferentes segmentos de la organización, en medio de un proceso ordenado
de evolución.
El énfasis inicial del proceso es fortalecer la Plataforma de Integración de
Aplicaciones mediante la utilización de patrones de desarrollo de servicios y la
incorporación de los componentes tecnológicos que permitan la utilización de los Web
Services como su mecanismo estándar de comunicación.
Adicionalmente el proceso evolutivo requiere la implementación del concepto de
“Conector Universal” del banco, el cual tendrá como objetivo servir de interface entre la
PIA y el mundo fuera del banco, para la publicación de Web Services externos.
Con la implementación de estos dos elementos; más otros proyectos de negocios
e infraestructura necesarios, se puede iniciar el primer ciclo de publicación y consumo
de servicios entre el banco y sus aliados de negocio. Los sistemas recomendados para
iniciar este ciclo son BN-Convenios y BN-Ventanilla de Pagos, por cuanto ambos
sistemas se utilizan para publicar transacciones con socios de negocios, pero utilizando
software “hecho en casa” y sockets de comunicación. Para ambos sistemas se propone
un proceso de modernización que elimine las interfaces propietarias y adapte los
estándares de la industria a su funcionamiento normal.
Con respecto al resto de los objetivos, se propone al Banco Nacional la ejecución
del siguiente portafolio de proyectos cuyo objetivo es agrupar las principales iniciativas
en los tres segmentos de la organización descritos por la teoría y adaptados a la realidad
de la Institución.
62
Cuadro #2: I Etapa. Publicación y consumo de servicios (2005-2006)
Nombre del proyecto
Objetivos
•
PKI
Definir una infraestructura de llave pública y privada de acuerdo
con los estándares de la industria, para la autenticación,
autorización y no repudio de la mensajería entre las personas y
los sistemas transaccionales y de apoyo de la Institución.
Fortalecimiento de PIA
•
Fortalecer la infraestructura tecnológica de PIA
•
Publicar transacciones comunes en el Middleware
•
Definir lineamientos para garantizar su crecimiento y la
reutilización del código transaccional
•
Definir estándares para comunicación con los BackEnd
•
En conjunto con el proyecto del Conector Universal, definir el
mecanismo de publicación interna de Web Services.
•
Conector Universal
Definición de estándares y lineamientos que gobiernen cualquier
Web Service publicado o consumido por la Institución.
•
Definir niveles de servicio para la infraestructura de Web
Services de la Institución.
•
Definir la infraestructura de comunicaciones y seguridad
necesaria para cumplir con los niveles de servicio definido.
•
Promover el B2B mediante la modernización de BN-Convenios y
Ventanilla de Pagos Virtual.
Modernización interfaces
•
de sistemas centrales
Analizar los servicios brindados por los sistemas de cuentas,
inversiones, tarjeta de crédito y préstamos: para publicarlos como
Web Services en la infraestructura de PIA.
•
Disminuir al mínimo las islas funcionales y la redundancia
funcional presente en la Institución.
Definición
de
•
Arquitectura de Negocios
Divulgación de los conceptos y lineamientos de la Arquitectura
Orientada a Servicios en todos los niveles: Gerencia, Direcciones
Corporativas, Unidades Operativas, entre otras.
•
Definición de los roles participantes en la Arquitectura
Corporativa de Negocios, al lado de los arquitectos de TI.
•
Plan de comunicación del rumbo estratégico del banco, para
modelar el negocio de la mejor manera.
•
Definición de métricas para evaluar el desempeño y el ROI de la
implementación de SOA.
•
Modificar la estructura organizacional y prepararla para el diseño
de servicios conjunto entre la DCTO y la Dirección de Negocios.
63
Cuadro #3: II Etapa. Arquitectura del negocio (2006-2007)
Nombre del proyecto
Diseño de servicios de
Objetivos
•
Negocio mediante TI
Implementar
el
resultado
del
proyecto
“Definición
de
Arquitectura de Negocios”.
•
Tomar los proyectos propuestos para el año 2006 y modelarlos de
acuerdo con los nuevos lineamientos definidos para SOA.
•
Ejecutar el control de calidad de los procesos definidos, de
manera que sean corregidos y/o modificados de acuerdo con la
experiencia que se adquiera en ese momento.
Convergencia de canales
•
hacia SOA
Impulsar la modernización de canales mediante el alineamiento a
SOA.
•
Eliminar mecanismos “hechos en casa” para acceder sistemas
centrales.
•
Implementar modelos de negocio más complejos en la
infraestructura de SOA, tales como flujos de trabajo y
orquestaciones de negocio.
•
Disminuir los costos de mantenimiento y creación de nuevos
servicios para los sistemas financieros de la institución.
Cuadro #4: III Etapa. Transformación de TI y el negocio (2007 en adelante)
Nombre del proyecto
Diseño de servicios de
Objetivos
•
Negocio mediante TI (2)
Modernización
sistemas
centrales
Asegurar los procedimientos y estándares necesarios para
garantizar la gobernabilidad de TI
de
•
Garantizar la total adopción de SOA a lo largo de la Institución.
•
Analizar la mejor vía para transformar la funcionalidad brindada
y
por los sistemas centrales; ya sea un proceso de sustitución,
mainframes
migración o transformación.
•
Reducción de costos de operación y mantenimiento de la
infraestructura tecnológica del Banco Nacional.
•
Garantizar el menor impacto posible para la Arquitectura
Orientada a Servicios de la Institución.
•
Disminuir los costos de mantenimiento y creación de nuevos
servicios para los sistemas financieros del banco.
64
De acuerdo con el conocimiento del negocio generado por esta investigación, se
sugiere que la ejecución de este portafolio sea incremental a través del tiempo, tal y
como se puede observar en la siguiente figura:
Gráfico #16: “Roadmap” del Portafolio de Proyectos para el Banco Nacional.
Fuente: Elaboración propia.
65
Glosario de términos
B2B. Por sus siglas en ingles: Business to Business. Modalidad de comercio electrónico
en el que las operaciones comerciales se realizan entre empresas y no con usuarios
finales. Algunos, muy pocos, utilizan el acrónimo español EAE.
Back office. Término utilizado frecuentemente para describir el conjunto de procesos
humanos y tecnológicos que se realizan en las organizaciones como apoyo al servicio al
cliente y que soporta su operación.
Front end. Término equivalente a interface de usuario en el contexto de software.
Frecuentemente se le llama de esta manera a la parte “cliente” de un programa y a la
parte que corre en el servidor se le llama Back end.
FTP. Por sus siglas en inglés: File Transfer Protocol. Es un protocolo de Internet que
permite transferencia de archivos. Se utiliza en modo cliente-servidor: conectados a un
servidor remoto que ofrece dicho servicio, el programa cliente permite solicitar la
transferencia de archivos en cualquiera de las dos direcciones.
IVR. Por sus siglas en inglés: Interactive Voice Response (Respuesta Interactiva de
Voz). Es una tecnología de telefonía, mediante la cual un cliente utiliza un teléfono de
tonos para interactuar con un sistema de información sin la intervención de un operador
humano. Un ejemplo de esta tecnología es BN-Banca Telefónica del Banco Nacional.
J2EE. Por sus siglas en inglés: Java 2 Platform Enterprise Edition. Es una plataforma
desarrollada por Sun Microsystems para aplicaciones en Internet, que permite
desarrollar, desplegar y administrar aplicaciones en múltiples capas. Se puede decir que
J2EE es la siguiente generación de aplicaciones Java.
Microsoft .NET. Conjunto de nuevas tecnologías en las que Microsoft ha estado
trabajando durante los últimos años con el propósito de mejorar sus sistemas operativos,
su modelo de componentes y obtener un entorno específicamente diseñado para el
66
desarrollo y ejecución del software en forma de servicios que puedan ser tanto
publicados como accedidos a través de Internet de forma independiente del lenguaje de
programación, modelo de objetos, sistema operativo y hardware utilizado tanto para
desarrollarlos como para publicarlos. Este entorno es lo que se denomina la
plataforma.NET, y los servicios antes mencionados son a los que se denomina servicios
Web.
Middleware. Término genérico para describir el Software que conecta dos o más
aplicaciones separadas con el propósito de brindar servicios unificados. Frecuentemente
la conexión entre aplicaciones se realize mediante el trasiego de datos entre sistemas de
cara al usuario (Front End) y sistemas centrales (Back End).
SFB.
Por sus siglas: Sistema Financiero Bancario. Sistema central de cuentas
corrientes, ahorros e inversiones del Banco Nacional de Costa Rica implementado con
tecnología Mainframe.
SIACC. Por sus siglas: Sistema Administrador de la Cartera Crediticia. Sistema central
de préstamos del Banco Nacional de Costa Rica implementado con tecnología Oracle.
SOA. Por sus siglas en inglés Service Oriented Architecture. Es una arquitectura de
aplicaciones donde todas las funcionalidades son definidas como servicios, utilizando
un lenguaje descriptivo y que poseen interfaces que pueden ser invocadas para ejecutar
procesos de negocio. Un cliente con cualquier dispositivo, sistema operativo o lenguaje
de programación puede utilizar estas interfaces, pues deben ser independientes de las
plataformas en las que se ejecutan,
Sockets. En Unix y otros sistemas operativos se le llama socket a un tipo especial de
software que se encarga de conectar las aplicaciones con un protocolo de red
determinado.
TI. Por sus siglas: Tecnologías de Información.
67
Web Services. El término Web Services describe una manera estandarizada de integrar
aplicaciones basadas en Internet mediante la utilización de mecanismos unificados de
describir los datos (XML), transferirlos (SOAP), listar (UDDI) y describir (WSDL) los
servicios disponibles. Utilizado primordialmente para la comunicación entre empresas y
con sus clientes, este tipo de servicio permite el trasiego de datos sin un conocimiento
profundo de la tecnología utilizada por quien lo consume.
68
Bibliografía
Bea Systems (2004). Why Adopt SOA.
http://www.beasys.com/framework.jsp?CNT=index.htm&FP=/content/solutions/soa/
Fecha de acceso: 12 de noviembre.
Clements,
Paul.
(1996).A
Survey
of
Architecture
Description
Languages.
http://csdl.computer.org/comp/proceedings/iwssd/1996/7361/00/73610016abs.htm.
Fecha de acceso: 25 de agosto.
Colan, Mark. (2004). Characteristics of Service-Oriented Architecture. New York, NY:
IBM Corporation.
Gartner (2004). El futuro de la TI en el Mundo y en Latinoamérica. Buenos Aires:
Technology Value Partners.
Hernández R, Fernández C, Baptista P. (1998). Metodología de la Investigación
Colombia: Mc Graw Hill.
Institute of Electrical and Electronics Engineers (IEEE). (2000). IEEE Recommended
Practice
for
Architectural
Description
of
Software-Intensive
Systems.
http://standards.ieee.org/reading/ieee/std/se/1471-2000.pdf. Fecha de acceso: 25 de
junio.
Microsoft Corporation (2004). Service-Oriented Architecture. Redmond, WA:
Microsoft Press.
PriceWaterHouseCoopers (2004). Plan estratégico de tecnología de la información para
el Banco Nacional de Costa Rica. Análisis de la situación actual. San José: Banco
Nacional de Costa Rica.
69
Varhol (2004). SOA: Get it Right the First Time
http://www.ftponline.com/weblogicpro/2004_05/magazine/features/pvarhol/. Fecha de
acceso: 24 de noviembre.
West, Kenneth (2004). Es… la SOA.
http://www.netmedia.info/informationweek/articulos.php?id_sec=46&id_art=4941.
Fecha de acceso: 08 de diciembre.
ANEXOS
1. Complementos al Marco teórico
1.1. Campos de la Arquitectura de Software
Actualmente la Arquitectura de Software es un conjunto heterogéneo de áreas de
investigación teórica y de formulación práctica. La Arquitectura comenzó siendo una
abstracción descriptiva que no investigó utilizando procesos sistemáticos, analizó las
relaciones que la vinculaban con los requerimientos previos, o los pasos metodológicos
que seguían para llevar a cabo el diseño del software.
Como elemento fundamental dentro de la concepción de la abstracción planteada
por una Arquitectura de Software es la reutilización. Se puede analizar como uno de los
objetivos primordiales de esta área el proporcionar una “bodega” estructurada con este
tipo de información reutilizable de diseño a un alto nivel.
Esta información permite que las decisiones de alto nivel inherentes a cada uno
de los subconjuntos lógicos establecidos por la misma arquitectura no necesiten ser reinventadas, re-validadas y re-descritas. Un razonamiento arquitectónico también
consiste en esgrimir un argumento sobre los elementos estructurales de un sistema, los
cuales conforman los aspectos que debe resolver la disciplina en su margen de acción,
dentro de los cuales se puede citar:
™ Diseño o selección de la arquitectura: ¿Cómo crear o seleccionar una
arquitectura en base de requerimientos funcionales, de rendimiento o de calidad?
™ Representación de la arquitectura: ¿Cómo comunicar una arquitectura? Este
problema se ha manifestado como el problema de la representación de
arquitecturas utilizando recursos lingüísticos, pero el problema también incluye
la selección del conjunto de información a ser comunicada.
™ Evaluación y análisis de la arquitectura: ¿Cómo analizar una arquitectura para
predecir cualidades del sistema en que se manifiesta? En este apartado también
se analiza el mismo hecho de comparar y escoger entre diversas arquitecturas en
competencia.
™ Desarrollo y evolución basados en arquitectura: ¿Cómo construir y mantener
un sistema dada una representación de la cual se cree que es la arquitectura que
resolverá el problema correspondiente?
™ Recuperación de la arquitectura: ¿Cómo hacer que un sistema “legacy”1
evolucione cuando los cambios afectan su estructura; para los sistemas de los
que se carezca de documentación confiable? Para este proceso se debe llevar a
cabo lo que se llama una “arqueología arquitectónica” para determinar y
documentar su arquitectura.
Debido a la complejidad de los sistemas, la forma de documentar una
Arquitectura es mediante Vistas, es decir, mediante descripciones simplificadas del
sistema desde una perspectiva particular. El modelo más conocido de vistas es el que
define RUP2 (4+1) vistas que comprende:
™ Vista del Diseño
™ Vista del Proceso
™ Vista de la Implementación
™ Vista del Deployment
™ Vista de Casos de Uso
En síntesis la Arquitectura de Software representa la clave para comprender,
organizar y comunicar un sistema, además, permite implantar conceptos como
reutilización y facilita el desarrollo de la solución.
1
Aplicación Legacy: Cualquier aplicación basada en tecnologías y hardware más antiguos, la cual
continúa brindando servicios esenciales en una organización.
2
Por sus siglas, Racional Unified Process.
1.2. Modelos de negocio basados en SOA
Considerando los beneficios que genera su utilización, es conveniente en la
mayoría de los casos modelar el negocio considerando una arquitectura de servicios; sin
embargo a nivel tecnológico la implementación de un servicio presenta inconvenientes
que deben ser considerados y en la medida de lo posible solucionados para obtener de
esta manera una implementación ideal y acorde con las demandas del negocio:
•
Tiempo de llamado: debido principalmente a la infraestructura de
comunicaciones, el tamaño de los mensajes y otros. Este punto implica que la
utilización de mensajería de red confiable sea obligatoria para evitar problemas
comunes asociados a la pérdida de paquetes en una red (como las
retransmisiones), pues inciden directamente en los tiempos de respuesta.
•
Respuesta del servicio: la respuesta que el servicio pueda brindar es afectada de
forma directa por elementos externos, como problemas en la red, errores en la
configuración y demás. Se deben considerar estos elementos en la etapa de
diseño, conceptualizando los mecanismos de contingencia que minimicen el
riesgo de falla en las aplicaciones y servicios que dependen de él.
•
Tolerancia a fallas: Al margen de lo citado, es totalmente necesario que el
modelo deba soportar comunicaciones no confiables, mensajes impredecibles,
reintentos, mensajes fuera de secuencia y otros, sin embargo los mismos deben
ser evitados para no sacrificar en una proporción mayor el tiempo de respuesta.
Con el objetivo de brindar flexibilidad en este aspecto, el servicio debe publicar
una interfaz (Ejemplo: WSDL3) fácilmente localizable dentro de la red. La idea es que
la interfaz se encuentre ampliamente documentada para facilitar y promover su
utilización y que a su vez ésta funja como un contrato del servicio, donde se describa
cada una de las funciones que publica e incluso aspectos como niveles de prestación de
dicho servicio.
3
Por sus siglas: Web Service Description Language.
El diseño exitoso de una arquitectura orientada a servicios debe utilizar una
plataforma de mensajería confiable, la cual aísle de la implementación funcional
muchos de los problemas anteriormente mencionados y que incluya las siguientes
características:
•
Entrega garantizada de mensajes.
•
Seguridad del contenido de los mensajes.
•
Calidad del Servicio.
•
Escenarios “en línea” y “fuera de línea”.
Una comunicación basada en mensajes por lo general implica que no existen
sesiones por lo cual los clientes no almacenan un estado en el servicio, con la idea de
brindar mayor escalabilidad, lo cual necesariamente implica que la autenticación se
debe dar a nivel de cada mensaje.
2. Proceso de recolección de Información.
2.1. Instrumento aplicado.
El siguiente cuestionario se aplicó a 18 diferentes profesionales de la Dirección
de Desarrollo de Sistemas del Banco Nacional de Costa Rica. Cada uno de ellos es
especialista en uno o más sistemas financieros que apoyan la gestión del Banco
Nacional de Costa Rica-
Periodo: El cuestionario se aplicó entre la segunda y la cuarta semana del mes
de noviembre de 2004.
CUESTIONARIO
Estimado compañero(a):
Muchas gracias por su tiempo. El siguiente cuestionario tiene como objetivo
recopilar de forma objetiva y con fines académicos, información acerca de los sistemas
que posee la institución y aspectos tecnológicos relacionados al mismo, lo cual
permitirá un proceso de análisis y evaluación de resultados.
Por favor observe las siguientes instrucciones:
1. Lea de forma pausada cada una de las preguntas del cuestionario
2. Marque su respuesta con una “X”, en caso de seleccionar una opción que solicita
detalle exponga de forma concisa su opinión.
3. Para preguntas de selección múltiple, se indicará esta característica en el
enunciado.
4. Seleccione el sistema que tiene a su cargo y conteste el cuestionario con este
sistema en mente.
Fecha:
_______________________________.
Sistema:
_______________________________.
1. De las siguientes categorías de sistemas ¿En cuál categoría se clasifica el sistema
que usted ha seleccionado?
1. ( ) Canal de distribución, servicio a clientes (E-Banking, Cajeros, etc).
2. ( ) Sistema de apoyo operativo (Call Center, Recursos humanos, etc).
3. ( ) Sistema central (Cuentas, Tarjetas, Préstamos, etc).
4. ( ) Sistema integrador (Middleware).
5. ( ) Otros________________________________
2. ¿En cuál lenguaje de programación utilizado en la institución se implementó este
sistema?
1. ( ) Linc.
2. ( ) Power Builder.
3. ( ) Visual Studio 6.0 o .NET
4. ( ) Oracle Developer.
5. ( ) Siebel 2000.
6. ( ) Otros________________________________
3. ¿Qué tecnología utiliza este sistema para administrar la persistencia de sus datos?
1. ( ) DMSII.
Versión: ___________________.
2. ( ) Oracle.
Versión: ___________________.
3. ( ) SQL Server.
Versión: ___________________.
4. ( ) Otro______________ Versión: ___________________.
4. ¿En qué año fue implementado el sistema?: __________.
5. Cuando el sistema fue construido, ¿cuál fue la proyección de su vida útil?:
1. ( ) Menos de 1 año
2. ( ) De 1 a 2 años
3. ( ) De 2 a 3 años
4. ( ) De 3 a 4 años
5.
( ) Más de 4 años
6. ¿Cuánto tiempo tomó el desarrollo de este producto? (tomando como punto de
partida el análisis y como punto final la implantación final del producto en
producción):
Menos de 3 meses
Entre 3 y 6 meses
Entre 12 y 18 meses
Más de 18 meses
Entre 6 meses y 12 meses
7. De la cantidad de componentes o programas que fue necesario desarrollar para este
sistema, los que partieron totalmente de cero representan aproximadamente:
De 0% a 20%
De 21% a 40%
De 61% a 80%
De 81% a 100%
De 41% a 60%
8. De los siguientes elementos, ¿cuál le presentó a nivel tecnológico la mayor
dificultad en la implementación (desarrollo) del sistema?:
1. ( ) Utilización de la tecnología adquirida
2. ( ) Integración con sistemas centrales
3. ( ) Construcción de funcionalidad base (monitoreo, auditoria, seguridad, etc.)
4. ( ) Protocolos de comunicación e infraestructura
5.
( ) Otros________________________________
Nota:
Si el sistema seleccionado se encuentra en las categorías “Apoyo interno” o “Canal
de distribución”, favor contestar las siguientes preguntas. En caso de encontrarse en
las categorías “Sistema central” o “Integrador” diríjase a la pregunta 12.
9. Considerando todo tipo de conexión a otros sistemas con que cuenta la aplicación,
sea a nivel transaccional o de consulta, ¿cuántas conexiones posee este sistema a
otras aplicaciones?
Menos de 3
Entre 3 y 5
Entre 9 y 10
Más de 10
Entre 6 y 8
10. La siguiente lista presenta una serie de transacciones identificadas como de amplia
utilización en la institución, por favor indique si el sistema que usted analiza utiliza
alguna, ya sea explícitamente en el sistema o como un proceso interno para llevar a
cabo otro. (puede seleccionar más de una opción).
a) ( ) Consulta de cuentas de un cliente
b) ( ) Consulta de tarjetas de crédito de un cliente
c) ( ) Consulta de préstamos de un cliente
d) ( ) Consulta de recibos pendientes
e) ( ) Consulta de saldos (cuentas corrientes y ahorro)
f) ( ) Consulta de movimientos (cuentas corrientes y ahorro)
g) ( ) Transferencia de fondos
h) ( ) Pago de servicios
i) ( ) Pago de tarjeta de crédito
j) ( ) Pago de un préstamo
k) ( ) Avance de efectivo
l) ( ) Aporte BN-Vital
m) ( ) Inversión BN-Fondos
11. La aplicación analizada utiliza el (los) siguiente(s) mecanismo(s) para establecer la
comunicación con el sistema central indicado (puede seleccionar varios
mecanismos):
9.1.Sistema Financiero Bancario (SFB)
( ) Socket propio
( ) MCSII
( ) COMS
( ) Plataforma de Integración
9.2.Tarjeta de Crédito
( ) Procedimiento almacenado
( ) Consulta tabla/vista
( ) Plataforma de Integración
( ) No aplica
9.3.Sistema Administrador de la Cartera Crediticia
( ) Procedimiento almacenado
( ) Consulta tabla/vista
( ) Plataforma de Integración
( ) No aplica
( ) No aplica
9.4.BN-Conectividad
( ) Procedimiento almacenado
( ) Consulta tabla/vista
( ) Plataforma de Integración
( ) Socket conectividad
( ) No aplica
12. Una “bodega” de servicios comunes hubiera facilitado el desarrollo del sistema en
mención.
i.
( ) Muy de acuerdo
ii.
( ) De acuerdo
iii.
( ) Ni de acuerdo ni desacuerdo
iv.
( ) En desacuerdo
v.
( ) Muy en desacuerdo
13. Cuando se debe implementar un nuevo módulo para este sistema, el tiempo
promedio que se debe invertir solamente en el desarrollo y pruebas es:
i.
( ) Muy bajo (Menos de dos semanas)
ii.
( ) Bajo (De dos a cuatro semanas)
iii.
( ) Normal (De uno a dos meses)
iv.
( ) Alto (De dos a tres meses)
v.
( ) Muy alto (Más de tres meses)
14. Según su criterio, el costo económico de brindar mantenimiento y operar este
sistema (considerando recurso humano, hardware, licencias, soporte, etc.) es:
i.
( ) Muy bajo (Menos de US $25,000.00 anuales)
ii.
( ) Bajo (Entre 25,000.00 y 99,999.99 US $ anuales)
iii.
( ) Medio (Entre 100,000.00 y 249,999.99 US $ anuales)
iv.
( ) Alto (Entre 250,000.00 y 500,000.00 US $ anuales)
v.
( ) Muy alto (Más de US $500,000.00 anuales)
15. Con respecto a la distribución de nuevas versiones del software que soporta el
sistema se puede decir que es:
1. ( ) Inmediata, los clientes se actualizan en tiempo real
2. ( ) Sencilla, con un instalador estándar.
3. ( ) Normal, requiere la generación de un instalador y cambios manuales.
4. ( ) Compleja, requiere la generación de instaladores y guías para ejecución.
5. ( ) Muy compleja, se debe trasladar prácticamente todo el sistema.
16. De acuerdo con su criterio y a su conocimiento del comportamiento transaccional
del sistema, el promedio de consultas mensuales que resuelve corresponde a :
1. ( ) Menos de 10,000
2. ( ) De 10,000 a menos de 25,000.
3. ( ) De 25,000 a menos de 100,000.
4. ( ) De 100,000 a menos de 500,000.
5. ( ) Más de 500,000.
17. De acuerdo con su criterio y a su conocimiento del comportamiento transaccional
del sistema, el promedio de transacciones mensuales que resuelve el sistema
corresponde a:
1. ( ) Menos de 10,000
2. ( ) De 10,000 a menos de 25,000.
3. ( ) De 25,000 a menos de 100,000.
4. ( ) De 100,000 a menos de 500,000.
5. ( ) Más de 500,000
Muchas Gracias por su colaboración.
2.2. Tabulación de los resultados.
Banco Nacional de Costa Rica
Cuadro #5: Clasificación por sistema
Diciembre 2004
Canal de
Apoyo
distribución operativo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
BN-Conectividad
SFB
PIA
DDO
Call Center
MOPAA
BN-Viajes
Tarjeta de crédito
Sistema de cajeros (Finesse)
SETBN
Ventanilla de pagos
Base Única de Clientes
BN-SINPE
BN-Paguese
Apuestas electrónicas
BN-Banca Telefónica
SIACC
BN-Internet Banking Personal
Archivo Virtual
Sistema de imágenes
SARCLI
Firmas
BN-Internet Banking Corporativo
TOTALES
Sistema
central
Apoyo a toma
Middleware de decisiones
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
6
6
8
1
2
Banco Nacional de Costa Rica
Cuadro #6: Redundancia funcional.
Diciembre 2004
a)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
BN-Conectividad
SFB
PIA
DDO
Call Center
MOPAA
BN-Viajes
Tarjeta de crédito
Sistema de cajeros (Finesse)
SETBN
Ventanilla de pagos
Base Única de Clientes
BN-Sinpe
BN-Paguese
Apuestas electrónicas
BN-Banca Telefónica
SIACC
BN-Internet Banking Personal
Archivo Virtual
Sistema de imágenes
SARCLI
Firmas
BN-Internet Banking
23 Corporativo
TOTALES
b)
c)
d)
1
1
1
1
1
1
1
8
f)
g)
1
h)
i)
j)
k)
1
1
1
1
1
1
1
1
1
1
1
1
5
1
7
1
1
1
1
1
1
1
1
e)
1
1
1
1
1
1
1
l)
m) a) Cuentas del cliente
b) Tarjeta de crédito
c) Préstamos de un cliente
d) Consulta recibos pendientes
e) Saldos de cuenta
f) Movimientos de cuenta
g) Transferencia de fondos
h) Pago de servicios
i) Pago tarjeta crédito
1 1 j) Pago préstamo
k) Avance efectivo
l) Aporte BN-Vital
m) Inversión BN-Fondos
1
1
1
1
1
1
1
1
1
1
1
1
1
1
3
1
6
1
4
1
5
1
3
1
4
1
5
1
5
1
3
1
3
Banco Nacional de Costa Rica
Cuadro #7: Dominios tecnológicos.
Diciembre 2004
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
BN-Conectividad
SFB
PIA
DDO
Call Center
MOPAA
BN-Viajes
Tarjeta de crédito
Sistema de cajeros (Finesse)
SETBN
Ventanilla de pagos
Base Única de Clientes
BN-Sinpe
BN-Paguese
Apuestas electrónicas
BN-Banca Telefónica
SIACC
BN-Internet Banking
Archivo Virtual
Sistema de imágenes
SARCLI
Firmas
BN-Internet Banking Corporativo
TOTALES
Aplicación
Unisys Sybase Microsoft Oracle Siebel
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
3
3
12
5
2
Base de datos
Unisys Sybase Microsoft Oracle
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
3
0
1
1
1
1
1
1
15
5
Banco Nacional de Costa Rica
Cuadro #8: Costos operacionales.
Diciembre 2004
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
BN-Conectividad
SFB
PIA
DDO
Call Center
MOPAA
BN-Viajes
Tarjeta de crédito
Sistema de cajeros (Finesse)
SETBN
Ventanilla de pagos
Base Única de Clientes
BN-Sinpe
BN-Paguese
Apuestas electrónicas
BN-Banca Telefónica
SIACC
BN-Internet Banking Personal
Archivo Virtual
Sistema de imágenes
SARCLI
Firmas
BN-Internet Banking Corporativo
TOTALES
Muy bajo Bajo Medio
1
Alto
Muy Alto
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
9
1
1
10
1
2
1
86
Banco Nacional de Costa Rica
Cuadro #9: Vida útil de los sistemas.
Diciembre 2004
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
BN-Conectividad
SFB
PIA
DDO
Call Center
MOPAA
BN-Viajes
Tarjeta de crédito
Sistema de cajeros (Finesse)
SETBN
Ventanilla de pagos
Base Única de Clientes
BN-Sinpe
BN-Paguese
Apuestas electrónicas
BN-Banca Telefónica
SIACC
BN-Internet Banking
Archivo Virtual
Sistema de imágenes
SARCLI
Firmas
BN-Internet Banking Corporativo
TOTALES
Año 1
1999
1990
2002
2003
2001
2002
2002
1996
2000
2000
2002
2004
2001
2004
2001
1998
2001
2001
2003
2001
2002
2000
1998
1-2
2-3
3-4
+4
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
0
1
3
1
19
Banco Nacional de Costa Rica
Cuadro #10: Implementación de un nuevo servicio.
Diciembre 2004
Inmediata
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
BN-Conectividad
SFB
PIA
DDO
Call Center
MOPAA
BN-Viajes
Tarjeta de crédito
Sistema de cajeros
(Finesse)
SETBN
Ventanilla de pagos
Base Única de Clientes
BN-Sinpe
BN-Paguese
Apuestas electrónicas
BN-Banca Telefónica
SIACC
BN-Internet Banking
Personal
Archivo Virtual
Sistema de imágenes
SARCLI
Firmas
BN-Internet Banking
Corporativo
TOTALES
Sencilla
Muy
Compleja compleja
Normal
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
3
15
1
5
0
88
Banco Nacional de Costa Rica
Cuadro #11: Islas tecnológicas - SFB.
Diciembre 2004
SFB
Socket MCSII COMS PIA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
BN-Conectividad
SFB
PIA
DDO
Call Center
MOPAA
BN-Viajes
Tarjeta de crédito
Sistema de cajeros (Finesse)
SETBN
Ventanilla de pagos
Base Única de Clientes
BN-Sinpe
BN-Paguese
Apuestas electrónicas
BN-Banca Telefónica
SIACC
BN-Internet Banking Personal
Archivo Virtual
Sistema de imágenes
SARCLI
Firmas
BN-Internet Banking
23 Corporativo
TOTALES
No aplica
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
7
3
1
1
3
13
89
Banco Nacional de Costa Rica
Cuadro #12: Islas tecnológicas – Tarjeta de crédito.
Diciembre 2004
Tarjetas de crédito
SP Consulta PIA Socket
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
BN-Conectividad
SFB
PIA
DDO
Call Center
MOPAA
BN-Viajes
Tarjeta de crédito
Sistema de cajeros (Finesse)
SETBN
Ventanilla de pagos
Base Única de Clientes
BN-Sinpe
BN-Paguese
Apuestas electrónicas
BN-Banca Telefónica
SIACC
BN-Internet Banking Personal
Archivo Virtual
Sistema de imágenes
SARCLI
Firmas
BN-Internet Banking
23 Corporativo
TOTALES
No aplica
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
3
3
6
2
5
90
Banco Nacional de Costa Rica
Cuadro #13: Islas tecnológicas – SIACC.
Diciembre 2004
SIACC
SP
Consulta PIA Socket No aplica
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
BN-Conectividad
SFB
PIA
DDO
Call Center
MOPAA
BN-Viajes
Tarjeta de crédito
Sistema de cajeros (Finesse)
SETBN
Ventanilla de pagos
Base Única de Clientes
BN-Sinpe
BN-Paguese
Apuestas electrónicas
BN-Banca Telefónica
SIACC
BN-Internet Banking Personal
Archivo Virtual
Sistema de imágenes
SARCLI
Firmas
BN-Internet Banking
23 Corporativo
TOTALES
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
10
1
2
1
2
4
91
Banco Nacional de Costa Rica
Cuadro #14: Islas tecnológicas – BN-Conectividad.
Diciembre 2004
BN-Conectividad
SP Consulta
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
BN-Conectividad
SFB
PIA
DDO
Call Center
MOPAA
BN-Viajes
Tarjeta de crédito
Sistema de cajeros (Finesse)
SETBN
Ventanilla de pagos
Base Única de Clientes
BN-Sinpe
BN-Paguese
Apuestas electrónicas
BN-Banca Telefónica
SIACC
BN-Internet Banking Personal
Archivo Virtual
Sistema de imágenes
SARCLI
Firmas
BN-Internet Banking
23 Corporativo
TOTALES
No
PIA Socket aplica
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
5
2
1
0
3
17