Principios Fundamentales de La Arquitectura de Aplicaciones

Principios fundamentales
de diseño de aplicaciones
Arquitectura de Aplicaciones
Principios fundamentales de diseño de aplicaciones
Histórico de revisiones
Revisiones
Fecha de la revisión: Fecha de la próxima revisión:
Número Fecha Resumen Cambios

Revisión Revisión Marcados
1.0 15/02/2010 Primera versión
1.1 18/02/2010 Inclusión de leves modificaciones NO
Distribución
Este documente se ha distribuido a:
Nombre Título
0. Introducción.........................................................................................................................4
0.1 Visión General..............................................................................................................................................4
0.2 Ámbito de aplicación de los principios.........................................................................................................5
Actualización: 18/02/2010 | 743283128.docx | Página 2 de 23

1. Unicidad de datos................................................................................................................ 6
1.1 Centralización y disposición de los datos.....................................................................................................6
1.2 Unificación de formatos internos.................................................................................................................7
2. Orientación Cliente.............................................................................................................. 8
2.1 Coherencia de procedimientos y contenidos...............................................................................................8
3. Modularidad........................................................................................................................ 9
3.1 Modularización.............................................................................................................................................9
3.2 Ámbito funcional de un Servicio de Aplicación...........................................................................................11
3.3 Granularidad adecuada de los servicios.....................................................................................................11
3.4 Externalización de Reglas de Negocio........................................................................................................12
3.5 Contingencia de Infraestructuras y Aplicaciones........................................................................................13
4. Contexto............................................................................................................................ 14
4.1 Independencia de Entidad..........................................................................................................................15
4.2 Independencia de Negocio/Marca.............................................................................................................16
4.3 Independencia de Canal.............................................................................................................................16
4.4 Independencia de Centro...........................................................................................................................17
4.5 Independencia de Idioma...........................................................................................................................18
4.6 Independencia de Usuario..........................................................................................................................19
5. Trazabilidad........................................................................................................................20
Normalizar los datos del Diario Electrónico Centralizado.......................................................................................20
6. Sostenibilidad técnica........................................................................................................ 21
6.1 Uso de ABSIS (Arquitectura y Metodología)...............................................................................................21
6.2 Servicios aislados de otros backends..........................................................................................................22
6.3 Principio de optimización 80/20.................................................................................................................22

0. Introducción
0.1 Visión General

El presente documento es una recopilación de los principios de diseño de aplicaciones que se deben seguir, tanto
para el desarrollo de nuevas aplicaciones, como al abordar una reingeniería de una aplicación existente.
Los principios aquí descritos se derivan por una parte del estudio de las Dimensiones de Negocio, que constituyen
los aspectos básicos a considerar en la Arquitectura de los Sistemas de Información de “la Caixa”, y otros se
derivan de la Arquitectura Técnica de Ejecución.
Este documento se estructura en base a los Principios fundamentales de diseño de aplicaciones:
Todos los datos deben estar centralizados y con forma

Unicidad de unificada de acceso a los mismos para facilitar la visión
datos
completa de la información y el reflejo de la realidad
actual de forma que el cliente
Las aplicaciones deben diseñarse
Orientación
Cliente perciba al Banco como una entidad única independiente
del canal,
Construcción producto, segmento,…
de aplicaciones en base a módulos
Modularidad
funcionales completos e independientes para poder ser
reutilizados de acuerdo al mapa de aplicaciones de la
Los productos yinstalación
servicios deben diseñarse
Contexto
independientes del contexto. Las infraestructuras
funcionales deben proporcionar el contexto donde se
Todo proceso debe ejecutan
dejar traza de principio a fin
Trazabilidad guardando un identificador único que diferencie una
operación en el mismo de cualquier otra
Las aplicaciones deben estar diseñadas para asegurar la
Sostenibilidad
técnica máxima eficiencia, escalabilidad y su mantenibilidad
futura
Unicidad
de datos
Modularid Orienta
ad Contexto Trazabilida
ción d
cliente
Sostenibili
dad
técnica

0.2 Ámbito de aplicación de los principios
Los principios aplican al diseño de aplicaciones desde el punto de vista de los servicios funcionales que éstas deben
proporcionar.
Consideramos como servicio aquella función reutilizable proporcionada por un backend y que será consumida por
una aplicación de canal, posiblemente formando parte de una integración con otros servicios. Entran en esta
definición, los Servicios de Integración, los Servicios de Negocio, Subservicios de Negocio y los Servicios de
Aplicación.
Alcance desarrollo Proveedor de servicios

1. Unicidad de datos
Definición:
 Los datos administrados centralizadamente garantizan la coherencia, unicidad de criterio y el óptimo
mantenimiento y evolución de los sistemas.
 La información debe ser reflejo en todo momento de la realidad actual;
– la estática en cuanto a contenido y
– la dinámica en contenido y temporalidad.
 La información debe ser accesible y estar disponible en el momento que se necesite para ser utilizada por
aquellos recursos autorizados de la Organización que se consideren oportunos con los criterios de
confidencialidad establecidos.
Normas de diseño:
 Centralización y disposición de los datos
 Unificación de formatos internos
1.1 Centralización y disposición de los datos
La información debe ser accesible y estar disponible para ser utilizada por aquellos recursos que se
consideren oportunos en la entidad.
• Hay cierta información que debe estar centralizada para garantizar la consistencia de la instalación. Por
este motivo existen y se deben utilizar las Infraestructuras Funcionales, que gestionan (entre otros) datos
fijos como centros, calendarios, cotizaciones de divisa, etc.
• Se recomienda que la información no se encuentre duplicada
Guía para el diseño de aplicaciones:
1. LA APLICACIÓN NO DEBE ALMACENAR DATOS FIJOS QUE UNA INFRAESTRUCTURA FUNCIONAL PUEDA OFRECER
2. LA GESTIÓN Y DEFINICIÓN DE CALENDARIOS Y FECHAS NO DEBE ESTAR CODIFICADA INTERNAMENTE EN LAS APLICACIONES.

Dato. El concepto de Dato no se modifica en la arquitectura
ABSIS, sin fundamentales
Principios embargo, si desediseño
modifica su estructura. La
de aplicaciones
estructura se va a dividir en una “Estructura Base” y un
conjunto de “Representaciones Físicas”. La Estructura
Base del Dato contiene los campos que identifican el
concepto que quiere representar el Dato (nombre,
descripción, alias, etc.) y las Representaciones Físicas se
refieren a cómo dicho concepto es utilizado por las distintas
aplicaciones (tipo de campo, longitud, etc.). A continuación se
muestra la Estructura actual del Dato y algunos ejemplos:
ESTRUCT
URA
DATO
EJEMPLO
S
Dato Físico. Este concepto se define como la utilización que

se realiza de un Dato en el sistema. Esta utilización implica:
Seleccionar una Representación Física del Dato.
Referenciar la información de la Estructura Base.
Añadir Información Adicional para la utilización.
Hay que tener en consideración que el Dato Físico sólo

realiza una referencia a la información de los Datos
(Estructura Base y Representación Física). El Dato Físico sólo
es propietario de la ‘Información Adicional’ definida para
ESTRUCT la utilización. Ejemplos:
URA EJEMPLO
DATO

1.2 Unificación de formatos internos
Internamente los módulos de los Servicios de Aplicación deberán utilizar un único formato de
representación para cada tipo de dato (fechas, contratos, identificadores de persona, etc.
• Actualmente no existe una unificación de formatos internos para los tipos de datos por lo que se
dificultan los mappings de datos entre servicios y proliferan las funciones/macros de conversión.
• Es necesario estandarizar los formatos para todos los tipos de datos (fechas, contratos, nifs, etc.) con los
que trabajan los módulos de las aplicaciones.
• En la capa de presentación ya se presentarán estos datos según los estándares de guía de estilo definidos
por “la Caixa”.

3. USAR LAS DEFINICIONES ESTÁNDAR DE DATOS DEFINIDAS EN EL CATÁLOGO DE DATOS.
4. ANTES DE CREAR UN DATO NUEVO, COMPROBAR SI YA EXISTE UN CAMPO REUTILIZABLE EN EL CATÁLOGO DE DATOS

2. Orientación Cliente
Definición:
 Los sistemas deben estar diseñados para facilitar la visión global y actualizada del cliente, así como
facilitar el conocimiento del cliente (rentabilidad, riesgo, etc).
 Dicha información se diseñará para facilitar la gestión interna y la acción comercial
 Todo proceso comercial y su operativa asociada debe estar adaptada a la satisfacción de las necesidades
del cliente.
Se debe garantizar la independencia de los productos en la distribución, la comercialización y la administración,
pero de forma articulada
Normas de diseño:
 Coherencia de procedimientos y contenidos
2.1 Coherencia de procedimientos y contenidos
Los sistemas deben estar diseñados para facilitar la visión global y actualizada del cliente, así como
ofrecer unos procedimientos similares entre los distintos canales.
• Todo proceso comercial y su operativa tiene que estar adaptada a la satisfacción de las necesidades del
cliente
• Se debe garantizar la independencia de los productos en la distribución, la comercialización y la
administración, pero de forma articulada

5. RESPETAR LAS GUÍAS DE DISEÑO DE LOS DISTINTOS CANALES

3. Modularidad
Definición:
 Deben quedar desacoplados:
– Los procesos de negocio propios de cada aplicación
– Los procesos con la lógica de negocio de los procesos con la lógica de infraestructura
– Los procesos internos propios de coherencia técnica
 Deben utilizarse las infraestructuras funcionales existentes:
– Evitar duplicidad de funcionalidades
– Extrapolar lógica legislativa o contable fuera de las aplicaciones (unicidad en modificaciones)
 Debe modelarse con la granularidad necesaria según la funcionalidad o el/los servicios asociados.
Normas de diseño:
 Modularización
 Ámbito funcional de un Servicio de Aplicación
 Granularidad adecuada de los servicios
 Externalización de Reglas de Negocio
 Contingencia de Infraestructuras y Aplicaciones
3.1 Modularización
La modularización es una técnica de diseño y programación encaminada a reducir el acoplamiento

funcional de las aplicaciones y aumentar la cohesión funcional de cada una de ellas.
• El acoplamiento funcional se define como la medida de la interacción entre los módulos de una misma
aplicación o de varias aplicaciones.
• La cohesión es la medida del grado de identificación de un módulo con una función concreta.
• Un Servicio tiene que estar bien identificado con funcionalidades propias de su dominio funcional y debe
aislar funciones que no son propias de su negocio, por ejemplo la contabilidad. Estas funciones pasarán a
ser realizadas por Infraestructuras Funcionales:

Mapa de Infraestructuras Funcionales
• Aislar la lógica de negocio de la lógica infraestructural. En los siguientes gráficos se muestra la transición
de una aplicación con lógica funcional y lógica de negocio integrada en el mismo código a una solución en
D
la que se aíslan la lógica infraestructural para que ésta pueda ser encapsulada en la Infraestructura:
ef
• Paso 1: Aislar la lógicainde negocio de la lógica infraestructural
Cobr
C D
ef
ic o in os y
Gnta ic
Cobr
ió Lógica ió
osdey Liqui
ebi
Auto n
li Liqui
d Cont
E n rizac
ione d
Negocioe daci
C st
s a daci
ones Auto
abili
st d d P Fi ones
o ió r
o rizac
dad A
ru e ds
m A Aplicación
n u ione
producto
ct
Comerciales Pr ctc rq
is Al C h d o
s s Informacionales
ur o al u
io fa or or e
a d id e Operativas
n b re ro Di
d u a o
e ét s vi
e ct d Estructurales
s ic p. s
C o
o Cl a
e ieDs Comunicativas
s M
nt ntef
ro
• Paso 2: Exportar infraestructura para poder serCobr ó otras aplicaciones
reutilizada por
ein
s T sic os y d
G ul
al ió Lógica de Liqui
e Cont oC
E le n Negocio daci
C st Auto
abili Co
st r d Fi ones
o ió rizac
dad obr
ru d e s A A
m A Aplicación
n ione o
ct e Pr c producto rq nt
ut Informacionales
Comerciales
is Al C h d s as
ur Pr or al or u
io fa o or e y
bl
a o red id iz e Operativas
n b ro Di eLi
d d a a. o
e ét su vi q
e u ct d Estructurales
s ic p. s ui
C ct Cl
o o a .
e o ies Comunicativas
s
nt s nt
ro e
s s
6. AISLAR EN MÓDULOS TODAS AQUELLAS FUNCIONES QUE NO SON PROPIAS DE LA APLICACIÓN Y QUE EN UN FUTURO PASARÁN A
SER RESUELTAS POR SERVICIOS DE INFRAESTRUCTURAS FUNCIONALES.

7. USAR INTERFACES ESTANDARIZADAS ENTRE EL PROGRAMA PRINCIPAL Y LOS MÓDULOS (P.E: INTERFACE DE CONTABILIDAD). LA
DEFINICIÓN DE INTERFACES ESTÁNDARES EN LOS S.I.M. DE “LA CAIXA” FACILITARÁ LA INTEGRACIÓN DE LAS APLICACIONES CON
LAS NUEVAS INFRAESTRUCTURAS CUANDO ESTÉN DISPONIBLES.
8. AISLAR EL CÓDIGO DE ACCESO A BBDD EN MÓDULOS SEPARADOS DEL PROGRAMA PRINCIPAL. ESTO PERMITIRÁ FUTURAS
SOLUCIONES DE CONVIVENCIA BASADAS EN INTERCEPCIÓN Y CONVERSIÓN, CUANDO HAYA CAMBIOS DE MODELOS DE DATOS.
9. DISEÑAR LOS MÓDULOS PARA QUE SE PUEDAN PROBAR FÁCILMENTE DE FORMA UNITARIA. INTERFASES SENCILLAS QUE
ADMITAN JUEGOS DE PRUEBA COMPLETOS.
3.2 Ámbito funcional de un Servicio de Aplicación
Un Servicio de Aplicación sólo implementa funciones que están dentro del ámbito funcional de la
Aplicación.
• Un servicio implementa únicamente funcionalidad propia de la aplicación y, por lo tanto, no puede llamar
a módulos de otras aplicaciones. Si es necesario, se debe integrar mediante un Servicio de Aplicación
(ADS).
• Uso de Infraestructuras y mecanismos de Arquitectura. Todo aquello que no sea exclusivo de la lógica de
negocio de la aplicación se debe resolver en Infraestructuras funcionales o en mecanismos de
Arquitectura y si no existen, se deberá impulsar su creación a través del arquitecto de aplicaciones.

10. AQUELLOS SERVICIOS DE APLICACIÓN QUE LLAMAN A MÓDULOS DE OTRAS APLICACIONES NO SE PUEDEN USAR EN SERVICIOS
DE NEGOCIO. ES NECESARIO REESCRIBIRLOS E INTEGRAR LA FUNCIONALIDAD EN EL SERVICIO DE NEGOCIO O DESDE SERVICIOS
DE INTEGRACIÓN.
11. UN SERVICIO DE APLICACIÓN DEBE PROPORCIONAR FUNCIONALIDADES SENCILLAS. ES MEJOR CREAR VARIOS SERVICIOS DE
APLICACIONES DIFERENTES QUE UN ÚNICO SERVICIO QUE AGLUTINE MUCHA FUNCIONALIDAD.
3.3 Granularidad adecuada de los servicios
La granularización de los servicios de una aplicación consiste en distribuir adecuadamente las

funciones que deben proporcionar los servicios, así como el diseño adecuado de las interfases de
los mismos, con el fin de cubrir un gran número de casos de uso y potenciar al máximo la
reutilización, teniendo en cuenta también el volumen de peticiones y el coste en recursos de cada
petición.
• Se definen dos tipos de granularidad:

• Coarse grained: Servicios cuya interfase permite devolver muchos datos para cubrir el máximo
de casos de uso desde el punto de vista de los solicitantes del servicio.

• Fine grained: Servicios cuya interfase sólo devuelve exclusivamente los datos para un
determinado caso de uso. En este caso, para obtener todos los datos que devolvería un servicio
coarse es necesario integrar y llamar varios servicios fine grained
• Los servicios deben tener la granularidad adecuada para:
• Facilitar la creación de Servicios de Integración y aumentar la reutilización de Servicios de
Negocio.
• Disminuir el consumo de recursos que implica la planificación de transacciones en backends tipo
HOST.
• El segundo objetivo primará sobre el primero si el volumen de peticiones es alto.

12. PARA LA GRANULARIDAD, SE DEBE TENER EN CUENTA DOS ASPECTOS:
1- FACILITAR LAS CREACIÓN DE SERVICIOS DE INTEGRACIÓN Y AUMENTAR LA REUTILIZACIÓN DE SERVICIOS DE NEGOCIO,
2- DISMINUIR EL CONSUMO DE RECURSOS QUE IMPLICA LA PLANIFICACIÓN DE TRANSACCIONES EN BACKENDS TIPO HOST.
EL SEGUNDO OBJETIVO PRIMARÁ SOBRE EL PRIMERO SI EL VOLUMEN DE PETICIONES ES ALTO
13. USAR EL MECANISMO DE SUBSCRIPCIÓN DE DATOS QUE OFRECE LA ARQUITECTURA DE EJECUCIÓN PARA RECIBIR SÓLO
AQUELLOS DATOS DE LA INTERFAZ DEL SERVICIO EN LOS QUE EL PETICIONARIO ESTÁ INTERESADO.
14. UN MÉTODO DE UN SERVICIO DE INTEGRACIÓN NO PUEDE LLAMAR A MÁS DE UN SERVICIO DE NEGOCIO POR CUESTIÓN DE
RENDIMIENTO. EL EMPAQUETAR FUNCIONALIDAD DEBE ESTABLECERSE A NIVEL DE SERVICIO DE NEGOCIO.
Cuando se trate del mismo backend se debe integrar en un único SN, ofreciendo la funcionalidad
completa. En backends distintos no existe la posibilidad de integración a nivel de SN, así pues, se deberá
realizar la integración en la Capa de integración
En este gráfico se muestra como un método del SI sólo puede llamar a un SN
3.4 Externalización de Reglas de Negocio
Las Reglas del Negocio describen políticas, normas, operaciones, definiciones y restricciones que se
aplican sobre los procesos de negocio que realiza “la Caixa”.
• Las necesidades del negocio cambian constantemente debido a numerosos factores: estrategias de
dirección, evolución del negocio, comportamiento de la competencia, cambios en la legislación, etc. A la
información que soporta dichas necesidades y que está formada por un conjunto de lógicas de negocio
complejas la denominamos REGLAS DE NEGOCIO.

• Actualmente las reglas de negocio suelen estar ocultas bajo el código de los Servicios de Aplicación, lo que
dificulta su conocimiento y modificación.
• Las reglas de negocio se pueden usar para expresar condiciones complejas de autorización de una
operación

15. LAS REGLAS DE NEGOCIO SE DEBEN INVENTARIAR EN LA PROPUESTA DE SOLUCIÓN Y DETALLAR EN EL DISEÑO FUNCIONAL DE LA
APLICACIÓN.
16. LAS APLICACIONES DEBEN EXTRAER DE LA LÓGICA DE APLICACIÓN TODAS AQUELLAS CONDICIONES (REGLAS) CON O SIN
PARÁMETROS, SUSCEPTIBLES DE PODER SER ACTUALIZADAS DE FORMA EXTERNA, POR EJEMPLO UNA CONDICIÓN SOBRE UN
RANGO DE IMPORTES.
17. LAS REGLAS DE NEGOCIO SE PUEDEN USAR PARA CONDICIONAR EL FLUJO DE UN SERVICIO DE INTEGRACIÓN, PARA
CONDICIONAR EL FLUJO EN UN SERVICIO DE NEGOCIO ADS, Y PARA EXTERNALIZAR CONDICIONES DEL CÓDIGO DE UN SERVICIO
DE APLICACIÓN.
18. SE DEBERÁ UTILIZAR LA INFRAESTRUCTURA DE REGLAS DE NEGOCIO (EN LA ACTUALIDAD, RDN), QUE ES LA HERRAMIENTA POR
LA CUAL SE DEBEN IMPLEMENTAR LAS REGLAS DE NEGOCIO
3.5 Contingencia de Infraestructuras y Aplicaciones
Diseñar y construir los servicios de infraestructuras y Aplicaciones para dar respuesta de

contingencia ante problemas técnicos y evitar así que se paren ciertas operativas.
• Cuando hay problemas técnicos o de lógica que impiden la utilización correcta de una infraestructura, la
operativa de las aplicaciones se para.
• Ejemplo: SGC no devuelve comisiones debido a un problema técnico en el bind de una tabla. Este hecho
para la operativa de las oficinas ya que la mayoría de transacciones acceden a comisiones.
• Si en SGC abenda un acceso a tablas al intentar leer comisiones, se activa el interruptor de inicialización
en producción y devuelve siempre comisión 0 sin abortar el proceso de las aplicaciones
• El condicionante es que la acción de compensación posterior tenga un impacto menor que el de no
permitir la operativa que utiliza la infraestructura.

19. LAS INFRAESTRUCTURAS EN GENERAL Y ALGUNAS APLICACIONES EN PARTICULAR TENDRÁN UN “INTERRUPTOR” ACCESIBLE
ONLINE QUE PERMITIRÁ DESACTIVAR SU FUNCIONALIDAD DE MANERA QUE SE DEVUELVAN LOS DATOS INICIALIZADOS SIN
INTERRUMPIR EL FLUJO DE EJECUCIÓN.

4. Contexto
Definición:
Se deberá considerar la construcción de módulos que puedan trasladarse a otra instalación, recogiendo el
contexto donde se ejecutan de las infraestructuras funcionales, para garantizar:
Multipaís: Capacidad de ofrecer servicios y procesos en varios países
Multientidad: Capacidad de dar servicio a múltiples organizaciones (propias y externas)
Multidivisa: Posibilidad de ofrecer productos en múltiples divisas de operación
Multidioma: Flexibilidad de presentar operaciones en múltiples idiomas desde los puntos de vista cliente
Multicanal: Flexibilidad para brindar distintos grados de acceso por canal
Normas de diseño:
 Independencia de Entidad
 Independencia de Negocio / Marca
 Independencia de Canal
 Independencia de Centro
 Independencia de Idioma
 Independencia de Usuario
Estos principios se deben cumplir siempre. Sin embargo, pueden existir requerimientos justificados de Negocio que
impliquen desarrollar servicios dependientes de Entidad, Negocio/Marca, Centro o Canal.

4.1 Independencia de Entidad
Un servicio debe contener lógica de negocio válida para cualquier Entidad del grupo de “la Caixa” y
por tanto no debe contener lógica condicionada por entidades concretas.
• Los servicios de las aplicaciones darán servicio a las diferentes entidades del grupo. En este contexto, las
aplicaciones deberán ser indiferentes a la entidad con la que están trabajando.
• Las aplicaciones (locales y corporativas) deben estar preparadas para dar servicio a múltiples entidades
desde una única instancia de la aplicación.
• Un servicio contendrá la misma lógica para todas las entidades
• Sólo excepcionalmente puede ser necesario condicionar la lógica de los servicios en función de la entidad.

20. LOS SERVICIOS DE NEGOCIO HOST NO DEBEN TENER EL FLUJO CONDICIONADO A ENTIDAD. SI ES INEVITABLE APLICAR LÓGICA
DIFERENCIADA POR ENTIDAD, SE ENCAPSULARÁN LOS TRATAMIENTOS EN UN SERVICIO DE APLICACIÓN DISTRIBUIDOR.
Diseño incorrecto Diseño correcto
Como beneficio, no hay que rehacer el diseño ni regenerar el código del Servicio de Negocio ADS si se
incorpora un nuevo tratamiento diferenciado por Entidad.
21. SI ES NECESARIO SE CREARÁ UN SERVICIO DE APLICACIÓN DISTRIBUIDOR QUE DERIVE LA LÓGICA A UN MÓDULO ESPECÍFICO POR
ENTIDAD-PAÍS. PARA ELLO DEBERÁN USAR LA ENTIDAD OPERANTE, DISPONIBLE EN EL CONTEXTO DE EJECUCIÓN.
22. MODULARIZAR Y AISLAR LAS FUNCIONALIDADES PROPIAS O EXCLUSIVAS DE UNA ENTIDAD CONCRETA
23. LOS SERVICIOS QUE REQUIERAN FILTRAR INFORMACIÓN EN FUNCIÓN DE LA RELACIÓN ENTRE LA ENTIDAD OPERANTE Y LAS
ENTIDADES DE LOS CONTRATOS QUE GESTIONEN: EMISORA, COMERCIALIZADORA Y GESTORAS DE PRODUCTO Y CONTRATO,
DEBERÁN USAR SIEMPRE LOS SERVICIOS DE FILTRADO DE REPOSITORIO DE CLIENTES Y CONTRATOS (ALFABÉTICO), Y NO APLICAR
FILTRADOS EN SU EN SU PROPIO LÓGICA
24. LA APLICACIÓN DEBE TENER IDENTIFICADOS EN LA FASE DE DISEÑO FUNCIONAL LA OPERATIVA COMÚN Y DISTINTA POR
ENTIDAD - PAÍS Y CENTRO.

4.2 Independencia de Negocio/Marca
La lógica de negocio de un servicio debe ser la misma para cualquier Negocio y/o Marca
• En tiempo de ejecución, las aplicaciones funcionan indiferentes a la marca o segmento de negocio con el
que están trabajando (misma lógica para todas las marcas o segmentos).
• Una excepción son aquellos servicios de aplicaciones de gestión, destinados a análisis y seguimiento de
resultados de negocio por Negocio y/o Marca, que requerirán diferenciar por estos conceptos.
• Otra excepción son las aplicaciones exclusivas de un determinado negocio.
• Actualmente, los criterios únicos que permiten deducir de una manera univoca, el segmento de cada
cliente se encuentran en fase de definición por parte de negocio.

25. LOS SERVICIOS DE NEGOCIO HOST NO DEBEN TENER EL FLUJO CONDICIONADO A NEGOCIO Y/O MARCA. SI ES INEVITABLE
APLICAR LÓGICA DIFERENCIADA POR NEGOCIO Y/O MARCA, LA MEJOR PRÁCTICA ES ENCAPSULAR LOS TRATAMIENTOS EN UN
SERVICIO DE APLICACIÓN (DISTRIBUIDOR).
26. MODULARIZAR Y AISLAR LAS FUNCIONALIDADES PROPIAS O EXCLUSIVAS DE UN NEGOCIO Y/O MARCA EN MÓDULOS
ESPECÍFICOS DE APLICACIÓN.
27. EN UN SERVICIO NO SE DEBERÁN APLICAR DIRECTAMENTE CRITERIOS PARA DETERMINAR EL SEGMENTO DE UN CLIENTE. DEBERÁ
USAR SERVICIOS DE LA INFRAESTRUCTURA DE REPOSITORIO DE CLIENTES Y CONTRATOS (ALFABÉTICO) PARA CONSULTAR EL
NEGOCIO ASOCIADO AL CLIENTE Y/O CONTRATO.
4.3 Independencia de Canal
La lógica de negocio de un servicio debe ser la misma para cualquier Canal y por tanto no debe
preguntar por el canal que ha originado la petición.
• Un servicio se debe diseñar de entrada para dar servicio a los múltiples canales de distribución que
dispone “la Caixa” y por tanto no se debe pensar para un canal concreto, como puede ser Oficinas. Se
debe realizar la máxima abstracción de las funcionalidades de canal en el diseño del servicio

28. SIEMPRE QUE SEA POSIBLE, LOS TRATAMIENTOS EXCLUSIVOS DE CANAL SE DEBEN PASAR A LA CAPA DE FRONTEND
(APLICACIONES DE CANAL) Y/O A LA CAPA DE SERVICIOS DE INTEGRACIÓN.
29. LOS SERVICIOS DE NEGOCIO NO DEBEN TENER EL FLUJO CONDICIONADO POR CANAL. SI ES INEVITABLE APLICAR LÓGICA
DIFERENCIADA POR CANAL, LA MEJOR PRÁCTICA ES ENCAPSULAR LOS TRATAMIENTOS EN UN SERVICIO DE APLICACIÓN
(DISTRIBUIDOR).

Diseño incorrecto Diseño correcto
30. MODULARIZAR Y AISLAR LAS FUNCIONALIDADES PROPIAS O EXCLUSIVAS DE UN CANAL EN MÓDULOS ESPECÍFICOS DE
APLICACIÓN.
31. CADA ACCIÓN DEBE REGISTRARSE EN EL BACKEND Y DAR COBERTURA AL GLOBAL DE ACCIONES, ES DECIR, CUBRIR TODAS LAS
ACCIONES REALIZADAS POR CUALQUIER CANAL
4.4 Independencia de Centro
La lógica de negocio de un servicio no debe estar condicionada por el Centro del Usuario.
• Aunque existen operativas que están autorizadas para determinados centros, los servicios de las
aplicaciones no deben preguntar directamente por el centro del usuario y condicionar la lógica de negocio
al mismo. Es más, al tener en cuenta el principio de independencia de canal, es posible que el centro no
esté informado, caso del canal Homebanking.

32. LOS SERVICIOS DE NEGOCIO NO DEBEN TENER EL FLUJO CONDICIONADO POR CENTRO.
33. LOS SERVICIOS DE APLICACIÓN NO DEBEN TENER EN EL CODIGO SENTENCIAS CONDICIONALES QUE EVALÚEN EL CENTRO DEL
USUARIO.
34. LA AUTORIZACIÓN DE EJECUCIÓN DE UNA OPERATIVA (SERVICIOS) POR UN DETERMINADO CENTRO SE DEBE DELEGAR A LA
INFRAESTRUCTURA DE GESTIÓN DE AUTORIZACIONES, QUE EN ESTE CASO DEBERÁ ACTUAR DE FORMA TRANSPARENTE A LAS
APLICACIONES, A TRAVÉS DE LA ARQUITECTURA DE EJECUCIÓN.
35. EL FILTRADO DE OPCIONES DE MENÚ POR CENTROS SE DEBE RESOLVER EN LA CAPA DE PRESENTACIÓN, YA SEA POR
MECANISMOS DE ARQUITECTURA, YA SEA POR DESARROLLO DE APLICACIONES DE CANAL.

4.5 Independencia de Idioma
Un servicio en ningún caso deben devolver literales, sino códigos que la capa de presentación se
encargará de traducir a literales usando el idioma del usuario o cliente según el caso, o por defecto,
el de la entidad.
• Los servicios que ofrece un backend serán consumidos por aplicaciones de canal. Estas aplicaciones de
canal están especialmente diseñadas para adaptar la presentación a las particularidades del canal: tanto
desde el punto de las posibilidades tecnológicas de los dispositivos como desde el punto de vista del tipo
de usuario o cliente que recibe la información y su idioma.
• Por tanto, es necesario delegar la presentación de literales a la capa de presentación. Las aplicaciones
deberán codificar todos los literales que manejan: avisos, mensajes, errores, literales de aplicación, etc. y
la infraestructura de multi-idioma se encargará de la traducción, según idioma y canal.
• Pueden existir literales de entrada / salida de un servicio que son considerados como datos de aplicación.
Por ejemplo: el motivo de una transferencia. Estos datos no se consideran en la solución multi-idioma.
• Las aplicaciones deben codificar todos los literales que manejan: mensajes, errores, literales de aplicación.
Ejemplos de literales de aplicación pueden ser, entre otros, los nombres, descripciones y observaciones
de tarifas, de un Catálogo de Productos

36. LAS APLICACIONES DEBEN CODIFICAR TODOS LOS LITERALES QUE MANEJAN: MENSAJES, ERRORES, LITERALES DE APLICACIÓN,
ETC, USANDO EL ESTÁNDAR DE CODIFICACIÓN NORMALIZADO DE LA SOLUCIÓN MULTI-IDIOMA.
El modelo multi-idioma contempla el tratamiento de literales de pantalla, error/aviso y aplicativos:
Literals aplicativos
Literales de
Texto que tratan las aplicaciones y que pantalla
pueden ser bien de entrada (introducido
por el cliente), como bien de salida Texto estático de salida
(nombres de producto, descripciones, asociado a una pantalla
…)
Literales de error/aviso
Texto de salida que describe una situación excepcional y
que puede tener información variable (en el ejemplo, el
importe “1800” és un parámetro del literal “Ha ingresado
una cantidad igual o superior a XXX...”
Las aplicaciones trabajan sólo con códigos de literales y éstos se traducen vía la herramienta multi-idioma
al idioma correspondiente:

4.6 Independencia de Usuario
Un servicio no debe condicionar la lógica en función del usuario de la aplicación peticionaria del
servicio
• Aunque existen operativas cuya ejecución dependa de las atribuciones del usuario, los servicios de las
aplicaciones no deben preguntar directamente por el usuario y condicionar la lógica de negocio al mismo.
Es más, al tener en cuenta el principio de independencia de canal, es posible que el usuario no esté
informado en la petición.

37. LOS SERVICIOS DE NEGOCIO NO DEBEN TENER EL FLUJO CONDICIONADO POR USUARIO.
38. LOS SERVICIOS DE APLICACIÓN NO DEBEN TENER EN EL CODIGO SENTENCIAS CONDICIONALES QUE EVALÚEN EL CÓDIGO DEL
USUARIO.
39. LA AUTORIZACIÓN DE EJECUCIÓN DE UNA OPERATIVA (SERVICIOS) POR UN DETERMINADO USUARIO SE DEBE DELEGAR A LA
INFRAESTRUCTURA DE GESTIÓN DE AUTORIZACIONES, QUE EN ESTE CASO DEBERÁ ACTUAR DE FORMA TRANSPARENTE A LAS
APLICACIONES, A TRAVÉS DE LA ARQUITECTURA DE EJECUCIÓN.
40. EL FILTRADO DE OPCIONES DE MENÚ POR USUARIOS / PERFILES SE DEBE RESOLVER EN LA CAPA DE PRESENTACIÓN, YA SEA POR
MECANISMOS DE ARQUITECTURA, YA SEA POR DESARROLLO DE APLICACIONES DE CANAL.
41. LOS USUARIOS UTILIZADOS PARA CONECTARSE A UN SISTEMA DEBEN TENER PALABRAS CLAVE ASOCIADAS DE 8 CARACTERES
COMO MÍNIMO (PASSWORDS)

5. Trazabilidad
Definición:
 La aplicación deberá almacenar, en un registro dedicado a ello, toda operación llevada a cabo, con su
tipología y su identificador, de forma que se garantice el conocimiento del estado o situación de cualquier
proceso.
* Por operación se entiende cualquier acción que produzca variación en la información del
cliente/usuario:
– Alta/baja/modificación/cancelación de contratos
– Operaciones de Ingresos y Reintegros
– Operaciones de consulta
– Etc.
Normas de diseño:
 Normalizar los datos del Diario Electrónico Centralizado
Normalizar los datos del Diario Electrónico Centralizado
El Diario Electrónico Centralizado (DEC) es la infraestructura encargada de registrar de manera

única la operativa realizada por los usuarios en los distintos canales que posee la Caixa.
• DEC ofrece ventanas de búsquedas por tipo de operación, rangos de importes, números de contrato,
usuario, terminal, timestamp, etc. Sólo se podrán hacer estas búsquedas si se informan correctamente
todos los campos
• Es necesario que las aplicaciones HOST informen correctamente y con el mismo formato todos aquellos
campos del mensaje circulante destinados a DEC y que únicamente pueden informar las propias
aplicaciones: Importes, Contratos, NIFs, etc.
• En los registros DEC tenemos una serie de indicadores para almacenar información de arqueo,
anulaciones, etc. Estos indicadores deben estar correctamente informados en el mensaje circulante para
su posterior registro en DEC. De este modo se posibilitan diversas operativas (online y batch) desde DEC.

42. EN EL DISEÑO FUNCIONAL, LAS APLICACIONES DEBEN IDENTIFICAR TODOS LOS DATOS A REGISTRAR EN EL DIARIO ELECTRÓNICO.
43. SE DEBE GARANTIZAR LA CALIDAD DE LOS DATOS REGISTRADOS EN DEC A EFECTOS DE CONTROL, AUDITORÍA, EFICIENCIA Y
ARQUITECTURA.

6. Sostenibilidad técnica
Definición:
 La construcción de una nueva aplicación tiene que realizarse en base a el uso adecuado de los recursos,
considerando (RESET):
– Reutilización: uso de las infraestructuras
– Estandarización: diseño acorde a las Normas y Estándares de la Arquitectura de Aplicaciones
– Simplificación: reducción de la complejidad de los procesos de la aplicación (modularizar)
– Eficiencia: diseño optimizado de los principales procesos de negocio, desde una perspectiva
funcional y técnica
– Transmisión: mantener actualizada la documentación, material formativo para el usuario
(negocio y técnico)
Cumplimiento de la Metodología ABSIS en todo del Ciclo de Vida Productivo.
Normas de diseño:
 Uso de la ABSIS (Arquitectura y Metodología)
 Servicios aislados de otros backends
 Principio de optimización 80/20
6.1 Uso de ABSIS (Arquitectura y Metodología)
Cualquier nuevo desarrollo deberá realizarse en ABSIS
• ABSIS aporta:
• Nueva estructura organizativa para la función de Desarrollo que favorezca el alineamiento con
las áreas de negocio aprovechando las oportunidades que ofrece la nueva arquitectura
• Marco de cumplimiento de las normas del nuevo modelo y procedimientos necesarios para su
publicación, control, seguimiento y mejora continua
• Metodología para el ciclo de vida de desarrollo de software del grupo, cubriendo todas las capas
del nuevo sistema y adaptado a los tipos de desarrollo más relevantes
• Conjunto de herramientas que facilitan la construcción de aplicaciones bajo el nuevo modelo
• Infraestructura de software (SSMM, host y seguridad) que permite a las aplicaciones abstraerse
de los elementos técnicos para concentrarse en los aspectos de negocio

44. SEGUIR LAS FASES DE DISEÑO Y CONSTRUCCIÓN DE PROYECTOS DE LA METODOLOGÍA ABSIS

6.2 Servicios aislados de otros backends
Un Servicio de Negocio HOST o un Servicio de Aplicación no pueden conectar vía online con
servicios proporcionados por otros backends.
• Un backend proveedor de servicios no se conecta con otro backend proveedor de servicios a nivel de los
servicios que estos proporcionan. La única vía es integrar servicios desde la capa de integración y control
prevista en la Arquitectura Técnica de Ejecución.
• No se permite encolar transacciones desde un Servicio de Aplicación y por tanto, usar el mecanismo de
Funciones de Negocio actual.

45. UN SERVICIO DE APLICACIÓN NO PUEDE ENCOLAR UNA TRANSACCIÓN (FUNCIÓN DE NEGOCIO) PARA LLAMAR A OTRO SERVICIO
DEL MISMO BACKEND O DE OTRO BACKEND.
46. AQUELLOS SERVICIOS DE APLICACIÓN QUE ENCOLEN TRANSACCIONES NO SE PODRÁN USAR EN LA INTEGRACIÓN DE SERVICIOS
DE NEGOCIO HOST. SE DEBERÁN DUPLICAR Y REESCRIBIR RESPETANDO ESTE PRINCIPIO.
6.3 Principio de optimización 80/20
El 20% de los requerimientos normalmente cuesta el 80% del tiempo/presupuesto

Se puede ganar un 80% de efectividad optimizando el 20% del código
• En decisiones de convivencia utilizar el principio de optimización de Pareto (análisis de coste/beneficio)

para cubrir el máximo de requerimientos con el mínimo coste
• Donde sea aplicable
• Infraestructuras: Desarrollar funcionalidad para cubrir al menos el 80% de los requerimientos de
las aplicaciones
• Recoger acciones alternativas (manuales) para el 20% restante o plantear desarrollos de futuro

1. DISEÑAR PENSANDO EN OPTIMIZAR EL RENDIMIENTO DEL APLICATIVO.

Principios Fundamentales de La Arquitectura de Aplicaciones

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Principios Fundamentales de La Arquitectura de Aplicaciones

Cargado por

Copyright:

Formatos disponibles

Principios fundamentales

Número Fecha Resumen Cambios

Actualización: 18/02/2010 | 743283128.docx | Página 2 de 23

Actualización: 18/02/2010 | 743283128.docx | Página 3 de 23

0.1 Visión General

Todos los datos deben estar centralizados y con forma

Actualización: 18/02/2010 | 743283128.docx | Página 4 de 23

0.2 Ámbito de aplicación de los principios

Alcance desarrollo Proveedor de servicios

Actualización: 18/02/2010 | 743283128.docx | Página 5 de 23

1.1 Centralización y disposición de los datos

Guía para el diseño de aplicaciones:

Actualización: 18/02/2010 | 743283128.docx | Página 6 de 23

Dato Físico. Este concepto se define como la utilización que

Seleccionar una Representación Física del Dato.

Referenciar la información de la Estructura Base.

Añadir Información Adicional para la utilización.

Hay que tener en consideración que el Dato Físico sólo

Actualización: 18/02/2010 | 743283128.docx | Página 7 de 23

1.2 Unificación de formatos internos

Guía para el diseño de aplicaciones:

Actualización: 18/02/2010 | 743283128.docx | Página 8 de 23

2.1 Coherencia de procedimientos y contenidos

Guía para el diseño de aplicaciones:

Actualización: 18/02/2010 | 743283128.docx | Página 9 de 23

La modularización es una técnica de diseño y programación encaminada a reducir el acoplamiento

Actualización: 18/02/2010 | 743283128.docx | Página 10 de 23

Mapa de Infraestructuras Funcionales

Actualización: 18/02/2010 | 743283128.docx | Página 11 de 23

3.2 Ámbito funcional de un Servicio de Aplicación

Guía para el diseño de aplicaciones:

3.3 Granularidad adecuada de los servicios

La granularización de los servicios de una aplicación consiste en distribuir adecuadamente las

• Se definen dos tipos de granularidad:

Actualización: 18/02/2010 | 743283128.docx | Página 12 de 23

Guía para el diseño de aplicaciones:

En este gráfico se muestra como un método del SI sólo puede llamar a un SN

3.4 Externalización de Reglas de Negocio

Actualización: 18/02/2010 | 743283128.docx | Página 13 de 23

Guía para el diseño de aplicaciones:

3.5 Contingencia de Infraestructuras y Aplicaciones

Diseñar y construir los servicios de infraestructuras y Aplicaciones para dar respuesta de

Guía para el diseño de aplicaciones:

Actualización: 18/02/2010 | 743283128.docx | Página 14 de 23

Actualización: 18/02/2010 | 743283128.docx | Página 15 de 23

4.1 Independencia de Entidad

Guía para el diseño de aplicaciones:

Diseño incorrecto Diseño correcto

Actualización: 18/02/2010 | 743283128.docx | Página 16 de 23

4.2 Independencia de Negocio/Marca

Guía para el diseño de aplicaciones:

4.3 Independencia de Canal

Guía para el diseño de aplicaciones:

Actualización: 18/02/2010 | 743283128.docx | Página 17 de 23

Diseño incorrecto Diseño correcto

4.4 Independencia de Centro

Guía para el diseño de aplicaciones:

Actualización: 18/02/2010 | 743283128.docx | Página 18 de 23

4.5 Independencia de Idioma

Guía para el diseño de aplicaciones:

El modelo multi-idioma contempla el tratamiento de literales de pantalla, error/aviso y aplicativos:

Actualización: 18/02/2010 | 743283128.docx | Página 19 de 23

4.6 Independencia de Usuario