Arquitectura de Aplicaciones

ARQUITECTURA
EMPRESARIAL
DEFINICIN DE LA
ARQUITECTURA DE
APLICACIONES
CLIENTE: Electrocentro S.A. DEFINICIN DE LA ARQUITECTURA APLICACIONES
DEFINICIN DE LA ARQUITECTURA DE
APLICACIONES
NOMBRE DOCUMENTO DEFINICIN DE LA ARQUITECTURA DE APLICACIONES
CREADO POR: FECHA: 07 12 17
REVISADO POR: FECHA: 08 12 17
APROBADO POR: FECHA: 08 12 17
CONTROL DE VERSIONES
VERSI
FECHA DESCRIPCIN CAMBIO
N
01 12 17 1.0 Liberacin Versin Inicial para revisin
08 12 17 2.0 Primera mejora para revisin
DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 2

Tabla de contenido
1 Introduccin.................................................................................................................5
1.1 Propsito del Documento......................................................................................5
1.2 Compromiso contractual............................................................................................6
1.3 Glosario de Trminos y abreviaciones...................................................................7
2 Alcance........................................................................................................................ 9
3 Objetivos y Restricciones...........................................................................................10
3.1 Objetivos de Alto nivel.........................................................................................10
3.2 Objetivos Especficos..........................................................................................10
3.3 Definicin de Stakeholders y sus intereses..........................................................11
3.4 Capacidades........................................................................................................21
4 Cumplimiento............................................................................................................. 23
4.1 Principios de Arquitectura....................................................................................23
4.2 Polticas y Estndares.........................................................................................24
5 Supuesto y dependencias..........................................................................................26
5.1 Supuestos........................................................................................................... 26
5.2 Dependencias......................................................................................................28
6 Arquitectura de Aplicaciones - Base...........................................................................29
6.1 Arquitectura Conceptual de Aplicaciones Base................................................29
6.2 Catlogo de Aplicaciones Lgicas Base............................................................30
6.3 Vista del catlogo de aplicaciones Actual............................................................30
7 Justificacin para la definicin de una Arquitectura de Aplicaciones..........................32
7.1 Justificacin......................................................................................................... 32
7.2 Enfoque............................................................................................................... 38
7.3 Decisiones........................................................................................................... 39
8 Definicin de Arquitectura de Aplicaciones.................................................................42
8.1. Descripcin de la Arquitectura de Aplicaciones.......................................................42
8.2 Estrategia de transicin para lograr la Arquitectura de Aplicaciones Objetivo..........45

9 Una Arquitectura de Aplicaciones que emerge a servicios.........................................54
9.1 Modelo Conceptual de Servicios que guen la arquitectura objetivo....................54
9.2 Catalogo Funcionalidades y Servicios de Aplicaciones - hoja funcionalidades....59

1. Introduccin
1.1. Propsito del Documento
Este documento comprende la descripcin de la arquitectura de aplicaciones base,

arquitectura de aplicaciones objetivo y anlisis de brecha para el proyecto definicin
del Programa de Arquitectura Empresarial de Electrocentro S.A..
El documento de Definicin de Arquitectura de Aplicaciones es el entregable

contenedor de los principales artefactos de la arquitectura de aplicaciones creados
durante el proyecto. Analiza los diferentes estados de la arquitectura: actual
(baseline) y objetivo (target). Est documento presenta una vista conceptual de las
soluciones de negocio y sus artefactos complementarios (catlogos, matrices y
diagramas); brinda una gua para articular las aplicaciones que deban conformar la
arquitectura de aplicaciones objetivo.

Este entregable cubre la fase C Arquitectura de Aplicaciones del Mtodo de

Desarrollo de la Arquitectura (ADM, Architecture Development Method) contenido en
el marco de referencia TOGAF (The Open Group Architecture Framework), en
donde la evolucin del documento entregable es un proceso iterativo a travs del
todo el proyecto. Cada paso inicia con la verificacin de los requerimientos. En
adicin, este entregable se complementa con una serie de artefactos referenciados
en diferentes secciones y dan profundidad a las definiciones presentadas en los
captulos que describen la arquitectura de aplicaciones.
1.2. Compromiso contractual
Este documento como entregable propio de la metodologa TOGAF (The Open

Group Architecture Framework) en su fase C Arquitectura de Aplicaciones , da
cumplimiento contractual con las OBLIGACIONES DEL CONSULTOR Definir,
disear y documentar la arquitectura empresarial objetivo para Electrocentro S.A.,
incluyendo los dominios de arquitecturas de negocio (funciones, procesos,
estructura organizacional, servicios de negocio),de informacin (flujos de
informacin, modelo de datos, seguridad de la informacin, indicadores), de
aplicaciones (requerimientos funcionales, servicios de aplicacin, modelo de
integracin, modelo de contexto) y de tecnologa (requerimientos no funcionales,
servicios de TI, diagramas de infraestructura")
De manera complementaria su contenido y artefactos dan alcance con la
descripcin de la arquitectura actual de los diferentes dominios y la definicin de la
Arquitectura objetivo, que confluyen en los entregables que indican los documentos
mnimos esperados por fase como se ilustra a continuacin:
Fase Etapa Entregable
B Arquitectura Arquitectura Objetivo Documento con elementos de la
Objetivo de Negocio Arquitectura Objetivo de Aplicaciones
de la Electrocentro S.A.
1.3. Glosario de Trminos y abreviaciones
TOGAF -(The Open Group Architecture Framework)

ADM -Mtodo de Desarrollo de Arquitectura (ADM, Architecture Development
Method)
STORM- Sistema de supervisin y control que permite mediante el diseo y
posterior diligenciamiento de formularios, reportar informacin estructurada

SIGA: Sistema de Informacin de Gestin Administrativa

SIAF: Sistema de Informacin de Administracin Financiera
SPSS- Programa estadstico informtico muy usado en las ciencias sociales y
las empresas de investigacin de mercado utilizado para el anlisis de riesgos
financieros de Electrocentro S.A..
SOA - Arquitectura Orientada a Servicios.
Extensibilidad - Es un factor de calidad del software que consiste en la facilidad
de adaptacin del software a nuevos requisitos o cambios en la especificacin.
Escalabilidad - Facilidad con la que un sistema o un componente puede
modificarse para corregir errores, mejorar su rendimiento u otros atributos, o
adaptarse a cambios del entorno.
Integracin - Conectar aplicaciones con la intencin de compartir informacin
entre ellas.
Flexibilidad - Facilidad con la que un sistema o un componente puede
modificarse para ser empleado con aplicaciones o en entornos distintos para los
que fue construido.
Portlets - Componentes modulares de las interfaces de usuario gestionadas y
visualizadas en un portal web. Los portlets producen fragmentos de cdigo de
marcado que se agregan en una pgina de un portal.

2. Alcance
El propsito de esta seccin es presentar el alcance de la arquitectura de aplicaciones que

se define para Electrocentro S.A.:
Identificar las diferentes aplicaciones de Electrocentro S.A., representada en un

catlogo de aplicaciones y sus componentes.
Interpretar el cubrimiento funcional que brindan las aplicaciones actuales para poder
establecer oportunidades de mejora en el soporte a los objetivos misionales y
requerimientos operativos de la Entidad.
Analizar y registrar los hallazgos encontrados con el fin de apoyar las
recomendaciones y con ello establecer una arquitectura de aplicaciones objetivo con
mayor cobertura funcional de las necesidades misionales de la Entidad.
Identificar las brechas para llevar del estado actual a la arquitectura de aplicaciones
objetivo con pasos claros para representarse en oportunidades y soluciones
potenciales.
Brindar artefactos que apoyen la comunicacin de la arquitectura de aplicaciones para
dar a conocer y facilitar un nivel de conocimiento, que d soporte a las necesidades
de negocio, datos y aplicaciones.
Sugerir un modelo de Arquitectura Orientada a Servicios que cubra las necesidades
de negocio, datos y aplicaciones dentro y fuera de Electrocentro S.A.

3. Objetivos y Restricciones
El cometido de esta seccin es presentar los objetivos de la arquitectura de aplicaciones y

las limitantes/restricciones de la arquitectura de aplicaciones y del presente documento.
En trminos de los criterios de calidad, esta seccin debe establecer:
Objetivos de alto nivel (de negocio y tecnolgicos) que incentivan el desarrollo de
arquitectura de aplicaciones.
Objetivos especficos (de negocio y tecnolgicos) que se pretenden alcanzar con el
ejercicio de arquitectura
Limitantes/restricciones (de negocio y tecnolgicos) que deben ser tenidos en cuenta
debido a su posible influencia en la toma de decisiones para la definicin de la
arquitectura de aplicaciones.
3.1. Objetivos de Alto nivel
Actualizar el inventario y realizar el diagnstico de la situacin actual de los

sistemas de informacin y sus interfaces.
Sugerir los sistemas que se van a integrar a nivel de Electrocentro S.A..
Realizar un diagnstico de los sistemas de Informacin versus los procesos de
la Entidad.
3.2. Objetivos Especficos
ID TITULO TIPO DESCRIPCIN DEL OBJETIVO

OE-1 Plataforma Arquitectura Proponer la actualizacin e
tecnolgica integracin de la plataforma
integrada y tecnolgica, por medio de
consolidada. integracin de procesos
facilitando la prestacin de
servicios; el suministro de
informacin y la comunicacin
interna y externa.
OE-2 Equipo de TI Arquitectura Fortalecer la implementacin

del ciclo de vida de las
aplicaciones.
OE-3 Servicios TI Estratgico Fortalecer la gestin

documental de los servicios
que soportan la operacin del
sistema de informacin integral.
OE-4 Comunicacin Arquitectura Sugerir y fortalecer la

integridad, interoperabilidad y
cumplimiento de estndares a

travs del cumplimiento de la

arquitectura empresarial de
Electrocentro S.A.
3.3. Definicin de Stakeholders y sus intereses
En esta seccin se encuentran registrados la informacin referente a los

responsables, funciones y hallazgos por cada aplicacin que existe en Electrocentro
S.A. ya sean desarrollos a la medida, como aplicaciones de proveedores y
productos propietarios. La cual refleja el estado actual de aplicaciones frente
quienes dan soporte o mantenimiento.
REA A CARGO DE
OPERAN Y/O SOLICITAN DESCRIPCIN DE
LA APLICACIN APLICACIN
REQUERIMIENTOS INTERESES
(TECNOLOGA)
Descripcin de la
aplicacin, mdulos, etc.
Observaciones
De qu rea depende?
(licencias, software,
rea Financiera SIAF Qu documentacin /
personal, etc.)
informacin necesita?
Cmo se realiza el
mantenimiento?
Capacitacin?
Depende directamente
Software corporativo que
de la Gerencia Regional
Sistema administra y controla
rea de TIC y funcionalmente de la
Comercial informacin de las
Jefatura Corporativa de
Optimus actividades comerciales
Tecnologa de la
de Electrocentro S.A..
Informacin
rea de TIC Sistema Sistema de informacin
Georreferencia tcnica georreferenciado
do Maximus II MAXIMUS II, que

administra la
infraestructura elctrica
en nuestra Empresa,
manteniendo
actualizadas la
informacin de las redes
elctricas en AT/MT/BT.,
interfase con el Optimus

para la generacin y
actualizacin del rbol
elctrico que sirve como
base para la informacin
comercial de nuevos
suministros,
interrupciones y otros.
Sistema de gestin
empresarial -
Planificacin de
rea de TIC ERP SAP Recursos Empresariales
ERPSAP Mdulos FI,
CO, FM, PS, HR, MM,
PS, BW
Sistema de apoyo al rea

rea de Administracin de Carta de de finanzas para la
Proyectos Fianza gestin de las cartas
fianzas.
Sistema de Gestin
rea de Administracin de
BSC Estratgica Balanced
Proyectos
Scorecard
Esta solucin
complementa las
carencias de reportes del
Programa sistema comercial
rea de TIC comercial Optimus: facturacin,
Optitool recaudacin, cobranzas,
consumos. Se acceso a
la base de datos Optimus
como solo consulta

Desarrollado para la
generacin de reportes
varios para las diferentes
Aplicacin
rea de Administracin de rea comercial y
Generador de
Proyectos administrativas, de
reportes
acuerdo a sus
necesidades de
informacin
Reportes varios
Koncentra administrativos,
Proyectos
comerciales y tcnicos.
Sistema desarrollado
para el control de
Sistema de
indicadores establecidos
control de
rea de TIC en las instrucciones del
indicadores
Sistema de Gestin de
BABEL
Calidad y gestin de
acciones de mejora
Aplicativo desarrollado
para el control de firmas
y autorizaciones de
rea Legal Detracciones
detracciones de acuerdo
a las normativas de
tributacin.
Aplicativo de apoyo al
rea Legal Contatool
rea Contable

Notiman: Aplicativo para

la emisin de
notificaciones de clientes
morosos. Factura: Para
la impresin rpida y fcil
Notiman, de facturas emitidas por
Factura, PAM Electrocentro - rea de

rea Legal
Contabilidad. PAMF:
Administracin de
informacin del programa
de asistencia mdica
familiar (Control de
gastos, impresin de
formatos, reportes etc.).
Aplicativo para control de

cumplimiento de los
rea de Calidad y
CSAuditoria correctivos de acuerdo
Fiscalizacion
observaciones de
Auditora Interna
Aplicativo de para la
Evaluacin de
rea de TIC ejecucin de evaluacin
Personal
de personal 360
rea de Administracion de Control de Aplicativo de control de

Proyectos combustible uso de combustibles.
Control de ejecucin de
rea de TIC MICOM acuerdo de reuniones de
todo nivel.

Administracin de
Admicom contratos de todo tipo y
Proyectos
su control de ejecucin.
Balance de energa a
nivel de SED's a detalle y
rea de TIC Detecta
seguimiento de trabajos
de reversin.
Priorizacin de atencin
de actividades de
rea de TIC Prioriza
atencin de nuevos
suministros
3.4. Capacidades
En esta seccin se mencionan los aspectos fundamentales que deben contener las
aplicaciones al momento de su creacin y que deben dar continuidad en las fases
de soporte y mantenimiento.
TITULO DESCRIPCIN DEL OBJETIVO
Centrada al Suministrar un modelo de datos institucional, permitiendo a los usuarios
usuario una mejor comprensin de la informacin suministrada.
Estrategia Que permita la interaccin con los funcionarios de la Entidad,
Multicanal mejorando la interaccin con el usuario final frente a la Entidad.
Orientada al Brindar la capacidad para definir, operar y monitorear las operaciones
flujo de de la Entidad requeridas para habilitar los servicios y trmites.
Procesos.
Estandarizaci Es un prerrequisito de los elementos construidos independientemente:
n Modularidad, Simplicidad, Flexibilidad los cuales tiene un alto nivel de
parametrizacin, permitiendo la integracin con un bajo acoplamiento.
Modularidad Sugerir que aplicaciones deben tener componentes independientes,

funcionales por s mismos, que puedan ser ensamblados de diferentes

maneras y cuyas combinaciones resulten con nuevas soluciones.
Simplicidad Las soluciones deben ser definidas con baja complejidad y bajo
acoplamiento, sin dejar de un lado los requerimientos de la Entidad.
Flexibilidad y Que permita responder gilmente a los requerimientos, condiciones y
alto nivel de regulaciones cambiantes de la Entidad y su entorno, mediante la
parametrizaci implementacin de parmetros en las aplicaciones con condiciones
n propios que permitan las modificaciones e integracin con otras
soluciones.
Integracin Que permita ejecutar transparentemente varias funciones a nivel de
datos, procesos y reutilizacin de servicios.

4. Cumplimiento
4.1. Principios de Arquitectura
Nombre Flexibilidad de aplicaciones

La arquitectura de aplicaciones debe ser modular, escalable y de fcil
Declaracin
acoplamiento.
Las aplicaciones con estas caractersticas permiten:
- Optimizar la agilidad y minimizar la complejidad de integracin.
- Simplificar la implementacin y mantenimiento.
Justificacin
- Gestionar los cambios en las soluciones de negocio con un impacto
bajo en los procesos y facilita una arquitectura orientada a servicios
(SOA).
Establecer un mtodo de integracin comn.
Implicacione
Implementar arquitecturas basadas en servicios.
s
Establecer estrategias de integracin de aplicaciones
Nombre Racionalizacin de Aplicaciones

La arquitectura de aplicaciones debe promover la racionalizacin en el
Declaracin portafolio de soluciones de negocio, maximizando su aprovechamiento y
evitando la implementacin de funcionalidades ya existentes.
La correcta identificacin funcional del portafolio de aplicaciones de la
Justificacin Entidad evita que se propongan e implementen soluciones que cubran
funcionalidades ya existentes en aplicaciones actuales.
Gestionar el portafolio de aplicaciones de la Entidad
Gestionar los requerimientos comparndolos con las funcionalidades
Implicacione
existentes en las aplicaciones actuales.
s
Establecer trazabilidad en la identificacin de necesidades de
modernizacin y relevamiento de aplicaciones
Nombre Reutilizacin de Funcionalidades

La arquitectura de aplicaciones debe establecer soluciones conformadas
Declaracin por componentes y servicios que habiliten la reutilizacin de
funcionalidades.
El proceso de reusar aplicaciones reduce costos y promueve la
Justificacin integracin por componentes asegurando consistencia en el desarrollo
de soluciones.
Implicacione Reusar componentes actuales de aplicacin mientras sea posible.
s Establecer el catlogo de servicios (funcionalidades expuestas por

otros aplicativos)
Nombre Aplicaciones orientadas al usuario

La arquitectura de aplicaciones debe procurar la implementacin de
Declaracin soluciones de negocio orientadas al ciudadano y la prestacin de
servicios.
La liberacin de soluciones de negocio debe evitar la generacin
Justificacin
rechazo o resistencia al cambio por su dificultad de uso o complejidad.
Fcil usabilidad de aplicaciones
Implicacione
Soportar eficiencia de los procesos
s
Tramites interinstitucionales
4.2. Polticas y Estndares
Suministran los esquemas necesarios para visualizar, entender y disear una

arquitectura de aplicaciones con un grado de detalle de alto nivel. El modelado
propuesto por TOGAF puede utilizarse para crear esquemas conceptuales y lgicos
que establezcan estndares internos de Electrocentro S.A. los cuales puedan ser
usados para proponer y comunicar una arquitectura de aplicaciones con un
desempeo acorde a la Entidad, vinculando los requerimientos de negocio que
soportan la operacin del da a da con la infraestructura actual de la Entidad.
Archimate un es lenguaje de notacin unificado donde se modela de forma
tradicional una arquitectura de aplicaciones de alto nivel, el cual permite visualizar
e identificar las aplicaciones negocio, sub-aplicaciones, componentes, bases de
datos, servicios, etc. y sus respectivas interacciones.
El modelado de una arquitectura de aplicaciones forma parte del concepto de
Metodologa de Diseo, Desarrollo y Evaluacin de Software soportado por la
norma ISO 12207 que a su vez son los estndares y polticas regidas por la
norma 1074 IEEE, la cual define al ciclo de vida del software como una
aproximacin lgica a la adquisicin, el suministro, el desarrollo, la
explotacin y el mantenimiento del software.

5. Supuesto y dependencias
5.1. Supuestos
Es el conjunto de informacin que se asume como cierto a efectos de la

planificacin del proyecto.
Titulo Descripcin Fecha Origen Fuentes

Verificar el estado de las
debilidades de los
Debilidades de
sistemas de
los sistemas
informacin(Proyecto
de informacin
Seguridad de la
Informacin)
Presupuesto
Aplicaciones
en lnea
Con el
desarrollo del
proyecto de
El marco de trabajo Arquitectura
de ITIL provee una Empresarial se
gua de buenas dar una mayor
ITIL prcticas aplicable a claridad de los
la Entidad para servicios que
proveer los servicios ITIL debe
de TI al negocio. gobernar a nivel
de aplicaciones,
datos y
tecnologa.
5.2. Dependencias
Es el conjunto de informacin que se asume como cierto a efectos de la

planificacin del proyecto.
Titulo Descripcin Impacto Comentarios
Se debe tener en
cuenta la renovacin
La implementacin de de la plataforma
Alto
Estrategia de nuevos sistemas y cambios tecnolgica, el
Portal
Lineamientos de en los procesos debe desarrollo y el
Web
Aplicaciones en lnea. considerar los lineamientos cumplimiento de las
de aplicaciones en lnea. fases del manual de
aplicaciones en
Lnea.

6. Arquitectura de Aplicaciones - Base
6.1 Arquitectura Conceptual de Aplicaciones Base

Diagrama conceptual del modelo actual de aplicaciones

Aplicaciones misionales: Son aquellas aplicaciones utilizadas constantemente por
usuarios (internos, externos) y que son de crucial importancia para la operacin de la
Entidad en su conjunto y de algunas aplicaciones de apoyo.
Aplicaciones de apoyo: Son aquellos aplicativos desarrollados a la medida para
Entidad o aplicaciones propietarias, que consumen datos originados de las aplicaciones
misionales, con el fin de generar nueva informacin para las operaciones del da a da y
para la toma de decisin.
La Arquitectura de Aplicaciones que emerge a servicios, se realizara el modelado del
TO-BE del diagrama de aplicaciones propuesto por medio del lenguaje Archimate,
Diagrama conceptual del modelo actual de aplicaciones hace referencia a la integracin
actualidad de los sistemas de informacin de Electrocentro S.A. por medio de sus
bases de datos.
6.2 Catlogo de Aplicaciones Lgicas Base
En esta seccin se referencia el Catlogo Portafolio de Aplicaciones en relacin de

aplicaciones con los procesos de negocio AS-IS.
6.3 Vista del catlogo de aplicaciones Actual
Esta vista incluye las mismas aplicaciones del catlogo de aplicaciones y

adicionalmente ubica unos nombres de archivos de Excel, los cuales pueden ser
candidatos para automatizar y constituir aplicaciones en corto o medio plazo.

Vista del catlogo de aplicaciones Actual

7. Justificacin para la definicin de una Arquitectura de Aplicaciones
9.1 Justificacin
Las organizaciones dependen de sus activos de informacin para la toma de decisiones

efectivas para la adecuada ejecucin de sus objetivos estratgicos. Por sta razn, se
requiere de una Arquitectura de Aplicaciones en la Entidad que proponga la
reutilizacin del uso de las funcionalidades existentes. Con el diseo de una
arquitectura que sugiera un bajo acoplamiento entre sus componentes y que
promuevan la reutilizacin de los mismos, favoreciendo la identificacin de un conjunto
de servicios en red y la definicin de los procesos por los cuales interactan,
proporcionando informacin de alta disponibilidad, confiable, oportuna y que de soporte
a los siguientes aspectos:
Alinear las aplicaciones existentes en Electrocentro S.A. con la infraestructura
tecnolgica y procesos de TI a las necesidades actuales de conectividad
requeridas por Gobiernos en lnea.
Sugerir la adopcin de un modelo de Gestin del Conocimiento, el cual permita
garantizar la transferencia de conocimiento de los funcionarios de la Direccin de
Informtica y Desarrollo, que se retiran, cambian de rea o que cambian de
funciones dentro de la misma rea.
Enfocar una arquitectura de integracin de servicios que permite potencializar el
portal Institucional como canal de comunicacin y medio de apoyo entre
EMPRESA y empleados, ciudadanos y entes externos de la Entidad a travs de
servicios de aplicacin e informacin que soporten en tiempo real las operaciones
brindadas de una manera gil, segura, confiable y altamente disponible.
La calidad de los servicios identificados a partir de las funciones misionales de las
aplicaciones de gran importancia para Electrocentro S.A. se debe enfocarse en dar
valor de marca a la Entidad.
Generar un esquema autoservicio de actualizacin de datos, que permita mejorar
la experiencia del ciudadano y del usuario interno (funcionario de la Entidad) en la
interaccin con los servicios de Electrocentro S.A.
Identificar las funciones que pueden ser candidatas para ser servicios web de las
aplicaciones de proveedores que actualmente operan en la Entidad.
Identificar la creacin y exposicin de servicios de negocio, partiendo de la
composicin de servicios tcnicos existente

Centralizar la invocacin de servicios web utilizando un catlogo especializado que
tipifique el tipo de servicios disponibles. Permitir la comunicacin de las distintas
aplicaciones que actualmente se encuentran operando sobre diferentes
plataformas tecnolgicas.
Fomentar el uso del ciclo de vida de los servicios de integracin mediante
herramientas idneas para la administracin de los servicios web.
El modelo de arquitectura de integracin actual est basado en sus bases de
datos, con un nivel muy complejo de entendimiento al momento de realizar algn
ajuste en la lgica de presentacin, este modelo se establece como una unidad
central de intercambio de datos entre sistemas.
Una arquitectura de integracin orientada a servicios permite estandarizar los
reportes y definir herramientas para su generacin y consulta, que respondan
adecuadamente a las necesidades de los usuarios (internos y externos) de la
Entidad.
Una arquitectura de integracin orientada a servicios debe apoyar la gestin de
procesos societarios, la implementacin de estrategias y esquemas para la
sincronizacin de la informacin local a partir de fuentes externas
Proponer un modelo de arquitectura de integracin flexible que permita a
Electrocentro S.A. ser una Entidad abierta, la cual pueda comunicarse a travs de
distintos canales de informacin y datos, sobre un conjunto heterogneo de
sistemas de informacin integrados para dar una respuesta conjunta a las
demandas del negocio.
Generar estructuras claras de Gobierno IT, con decisin definidas para las
aplicaciones existentes bajo el modelo de Ciclo de Vida del Desarrollo de Software.
Los requerimientos no funcionales proporcionan una descripcin de las caractersticas
del software y hardware que debe tener el sistema de informacin para satisfacer las
necesidades del negocio. Las cules sern una base para el anlisis, diseo y pruebas
del sistema al momento de la implementacin o ajustes a las aplicaciones misionales y
de apoyo, enmarcados en los Modelos de Calidad del Desarrollo del Software.
Requerimiento Descripcin requerimiento No Funcional

Categoras de requerimientos relacionados con la cantidad de
usuarios (concurrentes) y dimensin de los repositorios de datos
actuales, tiempo de respuesta requerido para el acceder a los
Escalabilidad
diferentes contenidos (Mtodo de acceso a los diferentes tipos de
contenidos) e integracin con bajo acoplamiento con mdulos,
componentes, aplicaciones y otras tipos de arquitectura.
Categoras de requerimientos relacionados con flexibilidad del
Extensibilidad software a cambios de requerimientos (ajustes o nuevos
(Modificabilidad) requerimientos) necesarios para la integracin con proveedores
externos.
Categoras de requerimientos relacionados con el anlisis de todo el
entorno de hardware (tipos de servidores bases de datos, redes)
Plataformas
actual y software (sistemas operativos, herramientas informticas y su
licenciamiento).
Proteccin de Datos
Categoras de requerimientos relacionados con la proteccin de datos
de Carcter Personal
personales.
(LOPD)
Capacidades Categoras de requerimientos relacionados con la gestin de flujos de
administrativas informacin, monitorizacin de procesos, evaluacin y optimizacin
del rendimiento.
Categoras de requerimientos relacionados con los marcos de
Estndares
referencia utilizada para identificacin requerimientos de negocio.
Categoras de requerimientos relacionados con la alta disponibilidad
Alta disponibilidad relacionada con tolerancia a fallos y su respectiva recuperacin de
forma autnoma.
Balance o balanceo de Categoras de requerimientos relacionados con la capacidad que
carga deben soportar los servidores Web a nivel transaccional.
Procedimiento de
despliegue y gestin Actualizacin de versiones y configuracin de componentes.
de versiones
Mecanismo de
Categoras de requerimientos relacionados con la autenticacin del
autenticacin de los
usuario (firmas digitales y certificados digitales).
tipos documentales
Categoras de requerimientos relacionados con interoperabilidad con
Movilidad
terminales mviles y funcionamiento off line.
Capacidades en funcin de integraciones con diferentes herramientas

Colaboracin
propietario (alcance y limitaciones de integracin).
Categoras de requerimientos relacionados con los tiempos de

Rendimiento
respuesta acordados.
Tipos de requerimiento relacionado con la capacidad del usuario final
Fiabilidad
para confiar en la informacin suministrada por el sistema.
Categoras de requerimientos relacionados con la disponibilidad del
Disponibilidad
sistema frente a los usuarios finales.
Categoras de requerimientos relacionados con privacidad de los
Seguridad flujos de datos y su respectivo almacenamiento en sitio seguros,
polticas de intrusiones.
Categoras de requerimientos relacionados con la migracin a otra
Portabilidad plataforma tecnolgicas sin afectar la operacin de las operaciones
del da a da de La Entidad.

Categoras de requerimientos relacionados para ejecucin de
controles de revisin y control de cambios sobre la funcionalidad del
Mantenibilidad
sistema sin incurrir en costos exagerados o fuera del presupuesto de
la Entidad.
Categoras de requerimientos relacionados con los componentes o
Reusabilidad funcionalidades del sistema que suministran servicios a otros
sistemas.
Categoras de requerimientos relacionados con la medida de la
calidad de la experiencia del usuario en la interaccin con el servicio
Usabilidad
expuesto por el aplicativo y/o el fcil uso de la aplicacin (diseo
grfico enfocado con facilidad por parte del usuario final).
Categoras de requerimientos relacionados con la interoperabilidad
Interfaces
con otros sistemas de informacin.
Categoras de requerimientos relacionados con el grado en que un
Capacidad de Prueba servicio facilita el establecimiento de criterios de prueba y su
realizacin, para determinar si se han cumplido los criterios.
Capacidad de recursos Categoras de requerimientos relacionados con la infraestructura
de infraestructura tecnolgica requerida que permitirn al sistema funcionar
tecnolgica correctamente y que cumpla las expectativas en temas de
rendimiento, eficiencia eficacia.
Categoras de requerimientos relacionados con posibilidad del sistema
Confiabilidad de realizar las funciones para las que fue diseado sin presentar
fallos.
Tipo requerimiento que especifica el grado en que un servicio es
Visibilidad
visible y reconocible para los usuarios potenciales

9.2 Enfoque
En esta seccin se describe el enfoque metodolgico mediante el cual se plantea la

Arquitectura de Aplicaciones Objetivo, describiendo las actividades y premisas ms
importantes en esta definicin. El resultado detallado de cada una de las actividades se
reflejar en el captulo 8 de este documento y en los artefactos all referenciados.
Las actividades a desarrollar para la construccin de la Arquitectura de Aplicaciones
Objetivo son las siguientes:
Confirmar y extender el catlogo de aplicaciones partiendo de la informacin
complementaria que se ha identificado en las reuniones de entendimiento funcional
de las aplicaciones, las cuales fueron desarrolladas por el frente de Aplicaciones y
el frente de Datos.
Elaboracin del catlogo de funciones de las aplicaciones que son impacto para la
Entidad.
Etc.
Elaboracin del diagrama del Modelo Conceptual de Aplicaciones clasificando las
aplicaciones base a travs de las funcionalidades.
Registrar las brechas identificadas dentro frente de la Arquitectura de Aplicaciones
en la Matriz de Brechas Oportunidades y Soluciones Potenciales.
Registrar y consolidar las oportunidades y soluciones potenciales en la Matriz de
Brechas Oportunidades y Soluciones Potenciales que van alimentar desde el frente
de aplicaciones el portafolio de proyectos a implementar.
Es importante recalcar que un insumo que se ha tenido en cuenta para su alienacin
con las recomendaciones de Arquitectura de Aplicaciones, ha sido el PETI entregado
por Electrocentro S.A., en donde se establece temas como:
Implementar estndares para la gestin de aplicaciones.
Generar modelos de informacin para escenarios de anlisis y explotacin de
conocimiento.
Automatizar y monitorear procesos.
Implementar el Sistema de informacin integral Misional.
Implementar los Sistemas de informacin de soporte a los procesos estratgicos.
Implementar los Sistemas de informacin de soporte a los procesos de apoyo.
Implementar el Portal Institucional y servicios WEB

Debern cumplirse siguiendo los lineamientos de la Arquitectura de Aplicaciones, y
tendrn un mayor de detalle para su especificacin en la consolidacin de
Oportunidades y Soluciones potenciales que se entreguen.
9.3 Decisiones
El documento identificar las decisiones tomadas para la definicin de la Arquitectura

de Aplicaciones objetivo desde el punto de una solucin de Integracin de Aplicaciones
Empresariales EAI (Enterprise Application Integration) para Electrocentro S.A., por
medio de una seria de diferentes vistas, que se describirn a lo largo del documento. La
presentacin de estas vistas dar una idealizacin significativa del comportamiento de
la arquitectura, apoyada en el lenguaje de modelado ArchiMate, el cual proporciona una
visin de los principales elementos conceptuales y sus relaciones dentro de la
arquitectura propuesta de los sistemas candidatos con sus componentes, conexiones,
repositorios de datos y usuarios o sistemas externos. Los modelos presentados pueden
llegar a cambiar tanto como la arquitectura evolucione.
En la construccin de la Arquitectura de Aplicaciones objetivo se han tomado las
siguientes decisiones:
Se realizara un diagrama conceptual de las capas de servicios del sistema que
debe interactuar en la arquitectura de integracin objetivo. Se realizar un
diagrama conceptual de arquitectura de referencia de integracin entre servicios.
Se realizar el diagrama conceptual de las Entidades de negocio, componentes y
servicios de negocio.
No se modelar la arquitectura de aplicaciones actual As Is, dado que, al no
existir actualmente ningn modelo de datos claro, ni de aplicaciones que soporte
los procesos de Electrocentro S.A., la construccin de este no genera ningn valor
para la construccin de la Arquitectura de Aplicaciones objetivo. De manera
conjunta con el dominio de datos, se realizar el levantamiento de las funciones de
las aplicaciones que actualmente soportan los procesos misionales de la Entidad.
Las aplicaciones detectadas que soportan los procesos misionales de la Entidad
son:
Sistema de Gestin de seguridad y salud en el trabajo

Sistema de Gestin de la Calidad
Sistema de Gestin Medioambiental

8. Definicin de Arquitectura de Aplicaciones
8.1 Descripcin de la Arquitectura de Aplicaciones
Luego de analizar la arquitectura de aplicaciones actual se establece una definicin de

la Arquitectura de Aplicaciones Objetivo de Electrocentro S.A. siguiendo los
lineamentos metodolgicos de ejecucin de la fase C Arquitectura de Aplicaciones del
Mtodo de Desarrollo de la Arquitectura (ADM, Architecture Development Method)
contenido en el marco de referencia TOGAF (The Open Group Architecture
Framework).
Este anlisis se apoya en los criterios de decisin diseados dentro del desarrollo de la
Arquitectura de Aplicaciones con base en el marco de referencia TOGAF, que permiten
definir la evolucin de la arquitectura de aplicaciones objetivo. Los cuales se
encuentran a continuacin:
Criterios de referencia TOGAF

A continuacin se describen los criterios de decisin para la Arquitectura de
Aplicaciones Objetivo. Las razones por las cuales aplicar cada uno de estos criterios no
deben cumplirse en su totalidad, solo permiten generar una orientacin en las
decisiones.

Criterio de Arquitectura de Aplicaciones Objetivo
De acuerdo a los criterios mencionados la arquitectura de aplicaciones objetivo
contendr los elementos que se ilustran a continuacin:

Diagrama de arquitectura de aplicaciones objetivo

Los bloques que conformarn conceptualmente la arquitectura de aplicaciones se
establecen en un modelo conceptual TO-BE.
En la seccin a continuacin se detalla la estrategia para llegar a ello.
8.2 Estrategia de transicin para lograr la Arquitectura de Aplicaciones Objetivo
Desde el dominio de arquitectura de aplicaciones se determinan tres grandes

transiciones para alcanzar una evolucin adecuada en la arquitectura de aplicaciones
segn la realidad de Electrocentro S.A.
Transicin 1: 1 de diciembre de 2017
Transicin 2: 8 de diciembre de 2017
DESCRIPCIN DE LAS TRANSICIONES

Transicin 1:
Poder INCORPORAR un Buscador empresarial para las aplicaciones misionales,
RELEVAR anlisis sociedades, MODERNIZAR todo los Storm de aplicaciones
misionales, MANTENER, pero sin ser parte del alcance la Modificacin al rgimen de
sociedades, MANTENER el software SPSS y Firmas Digitales en aplicaciones de apoyo
y seguimiento.
Transicin 2:
Poder INCORPORAR un anlisis y se seguimiento financiero, en los flujos de trabajo
financiero, RELEVAR generador de oficios en la aplicacin de apoyo y seguimiento,
MODERNIZAR Storm Web de aplicaciones misionales, MANTENER, pero sin ser
parte del alcance el Documanager en aplicaciones de apoyo y seguimiento,
MANTENER el software SPSS y Firmas Digitales en aplicaciones de apoyo y
seguimiento.

Transicin 1

9. Arquitectura de Aplicaciones que emerge a servicios
La Arquitectura de aplicaciones en sus transiciones a una arquitectura objetivo depende de
varias iniciativas pero la principal es aquella que promueve la implementacin de una capa de
servicios. Aqu se plantea el modelo conceptual de integracin para emerger a servicios y da
una gua de entendimiento para el modelo de valoracin y autodiagnstico para evolucionar a
una arquitectura SOA.
9.1 Modelo Conceptual de Servicios que guen la arquitectura objetivo
En el documento se encontrarn las diferentes vistas que se deben contemplar al

momento de implementar una arquitectura de integracin. Estas vistas podrn apoyar
aquellos requerimientos iniciales para la adopcin de este tipo de arquitectura. De esta
forma, el documento podr ser estudiado y analizado por personas que cumplan con
distintos roles dentro de la organizacin y que de uno u otro modo deban que
interactuar con la arquitectnica propuesta.
La arquitectura de referencia de Integracin entre servicios que se muestra en la figura
de Criterio de Arquitectura de Aplicaciones Objetivo indica las capacidades de

interconexin requeridas para integrar servicios heterogneos implementados a travs
de un mediador de mensajes que proporcione los servicios de transporte, eventos y
mediacin. Los servicios de transporte proporcionan la capa bsica de conexin, los
servicios de eventos permiten al sistema responder estmulos especficos que son parte
de un proceso de negocio, y los servicios de mediacin permiten la existencia de
servicios de bajo acoplamiento en el sistema propuesto.
Conceptos claves a nivel de arquitectura de empresarial sobre la base de la
arquitectura de referencia orientada a servicios para Electrocentro S.A.:
Servicios de interaccin: Manejan las interacciones directas con las personas
involucradas en el proceso de negocio, por ejemplo, procesar los artefactos que
estn distribuidos como elementos de procesos en colaboraciones o en flujos de
procesos.
Servicios de procesos: Soportan la ejecucin de otros servicios que expresan su
comportamiento usando flujos de procesos o motores de reglas. Los flujos de
procesos, por ejemplo, son usados para describir la interaccin con los otros
servicios (bajo cualquiera de los tipos de integracin, incluyendo otros servicios de
flujos de procesos) para ejecutar tareas que son requeridas para implementar las
funciones ofrecidas por el nuevo servicio de negocio (combinados o agregados).
Arquitectura de referencia de Integracin entre servicios

Servicios de acceso: Proporcionan las funciones de negocio atmicas (aquellas que
no estn compuestas de otros servicios) que son requeridas por el servicio de
negocio global. Esto incluye adaptadores a aplicaciones existentes o paquetes de
software y nuevos componentes de aplicaciones que son creados para solucionar
una necesidad funcional que no es cubierta actualmente por las aplicaciones
existentes.
Servicios de acceso: Proporcionan las funciones de negocio atmicas (aquellas que
no estn compuestas de otros servicios) que son requeridas por el servicio de
negocio global. Esto incluye adaptadores a aplicaciones existentes o paquetes de
software y nuevos componentes de aplicaciones que son creados para solucionar
una necesidad funcional que no es cubierta actualmente por las aplicaciones
existentes.
Servicios a terceros: Maneja la adaptacin desde tres perspectivas
ortogonales:
Basado en los factores de forma de la interfaz de acceso tales como tamao
de la pantalla, memoria y limitaciones de procesamiento (yendo desde
estaciones de trabajo hasta dispositivos de mano).
Basado en los modos de interaccin, incluyendo interacciones
convencionales de pantalla y teclado, as como interacciones basadas en
habla o combinaciones de estos (multa-modalidad).
Tipos de conexiones tales como punto a punto, cliente servidor a travs de
un rango de tipos de conexiones, incluyendo operaciones completamente
desconectadas.
Servicios de informacin: Ayudan a integrar la informacin localizada en una
variedad de fuentes de datos, tales como bases de datos o aplicaciones existentes;
para acceder (consultar, actualizar y buscar) dicha informacin, analizarla de esas
fuentes de datos en escenarios de inteligencia de negocios, o para administrar los
metadatos sobre la informacin y los servicios que son usados y provistos por los
servicios de negocios que son parte del ambiente operativo.
Servicios de desarrollo: Permiten modelar e integrar las nuevas funcionalidades
desarrolladas a travs de la implementacin de servicios en todas sus formas, desde
servicios de acceso a funciones atmicas de las aplicaciones, como a servicios
provistos a travs de flujos de procesos, tareas humanas, manejadores de eventos, y
motores de reglas.

Capa de Mediacin: El principal eje de la arquitectura orientada a servicios es un
flujo de mediacin. Este tipo de arquitectura proporciona las capacidades de
interconexin requeridas para desplegar, usar y reutilizar los servicios implementados
en ella, reduciendo el nmero, tamao y complejidad de las interfaces.
Caractersticas:
Enruta los mensajes entre los servicios
Convierte los protocolos de transporte entre el solicitante y el servicio
Transforma los formatos de mensajes entre el solicitante y el servicio
Administra los eventos de negocios entre fuentes dispares
Nivel de Servicios: Se observa las diferentes capas a nivel de servicios de una
arquitectura de referencia.
Capas de servicios del sistema

Las capas descritas en el diagrama son:
1. Recursos de aplicaciones existentes: Corresponde a los componentes de
aplicaciones que se van a exponer como servicios en la organizacin. A este nivel
corresponden los componentes.
2. Componentes globales: Corresponde a los componentes a nivel de empresa (no
los especficos a las aplicaciones particulares) que realizan actividades generales

no relacionadas directamente al negocio pero que sirven como puente sobre los
sistemas existentes para exponer la informacin como servicios. En esta categora
estn los componentes de infraestructura.
3. Servicios: Corresponde a las interfaces de los sistemas nuevos o existentes vistos
desde la perspectiva de servicios. Las interfaces en este nivel estn desacopladas
de las aplicaciones que lo suministran. Estos servicios se van a construir con base
en las interfaces identificados en la matriz de funcionalidades.
4. Procesos: Son los componentes que permiten implementar los flujos de procesos,
los eventos de procesos y las actividades humanas. Estos se implementan en
flujos de procesos automatizados.
5. Presentacin: Es el conjunto de componentes que permite visualizar la informacin
proveniente de las capas inferiores y les permite a los usuarios consumir los
servicios que demandan a partir de los servicios ofrecidos. Estos deben ser portlets
del Portal de la Entidad.
6. Arquitectura de integracin: Permite la comunicacin entre las diferentes capas de
la arquitectura. Especialmente cuando los componentes de cada capa estn
distribuidos espacialmente en diversos componentes de infraestructura.
7. Componentes de administracin: Son los componentes que permiten administrar
los niveles de servicio, la seguridad y el monitoreo del consumo y produccin de
servicios.
9.2 Catalogo Funcionalidades y Servicios de Aplicaciones - hoja funcionalidades
Para poder proponer los componentes funcionales de Arquitectura de Aplicaciones

objetivo se realiz una descomposicin funcional de las aplicaciones identificadas como
soporte tecnolgico directo a la funcin misional.
De acuerdo a su naturaleza funcional los servicios sern siniestrados por los siguientes
sistemas de informacin contextuales, como lo indica en la siguiente figura:

Diagrama conceptual sistema de informacin

10. Evaluacin de la Preparacin SOA
El objetivo es realizar una evaluacin de la preparacin SOA de alto nivel, que ayude a la
Entidad a crear una hoja de ruta (Modelo de madurez SOA) para su transformacin gradual
hacia niveles ms maduros para la integracin de servicios, aplicando la metodologa de
Servicio de Integracin del Modelo de Madurez (OSIMM- Open Group) que ha sido
desarrollada y aprobada por The Open Group, con el fin de lograr el aumento de los beneficios
empresariales asociada con niveles ms altos de madurez.
A continuacin se hace una breve descripcin de la metodologa de alto nivel utilizada para
realizacin de una Evaluacin de madurez SOA (Arquitectura Orientada a Servicios) del Open
Group Standard
La metodologa del Servicio de Integracin del Modelo de Madurez (OSIMM- Open Gruop)
proporciona una metodologa que permite evaluar los niveles de madurez de una arquitectura
orientada a servicios de una organizacin (SOA). En donde se define un proceso para crear
una hoja de ruta de adopcin incremental. El modelo consta de siete niveles de madurez y
siete dimensiones que representan puntos de vista significativos de las empresas y
Capacidades de TI aplicados en los principios de SOA esencial para el despliegue de
servicios. El OSIMM acta como un modelo cuantitativo para ayudar en la evaluacin de la
situacin actual y deseado estado futuro de madurez de SOA.
Niveles de madurez
OSIMM cuantas con siete niveles de integracin madurez de negocios de la organizacin
y de los servicios de TI. Cada uno de los siete niveles refleja un posible estado de
abstraccin de una organizacin en trminos de su madurez en la integracin de sus
servicios (organizacin y / o IT) y soluciones SOA. Cada nivel de madurez se basa en el
fundamento de sus predecesores y tendr un conjunto acumulativo de atributos de
madurez.
Nivel 1: Silo
Las piezas individuales de la organizacin estn desarrollando su propio software de
forma independiente, sin integracin de los datos, procesos, normas o
tecnologas. Esto limita severamente la capacidad de la organizacin para
implementar procesos de negocio que requieren la cooperacin entre los diferentes
partes, y los sistemas de TI no pueden ser integrados sin intervencin manual
significativo, como volver a escribir y re-interpretacin de los datos.
Nivel 2: Integrado

Las tecnologas se han puesto en marcha para la comunicacin entre los silos, para
integrar los datos y sus interconexiones. La construccin de un sistema informtico
que se integre a travs de diferentes partes de la organizacin se vuelve posible. Sin
embargo, la integracin no se extiende a las normas comunes en los datos o
procesos de negocio. Por lo tanto, para conectar dos sistemas, se requiere de una
conversin compleja de los datos, de las operaciones y protocolos de los sistemas
que existentes. Cada uno de la conexin podra requerir un cdigo a medida y
adaptadores, lo que lleva a la proliferacin de software que es difcil gestionar. Por
tanto, no es fcil desarrollar o automatizar nuevos negocios procesos.
Nivel 3: Componentes
Los sistemas de TI en los silos han sido analizados y desglosados en componentes,
con un marco en el que se pueden desarrollar en nuevas configuraciones y
sistemas. Tambin puede ser un anlisis limitado de la funcionalidad empresarial en
componentes. Aunque los componentes pueden interactuar a travs de interfaces
definidas, que no estn dbilmente acoplados, lo que limita la agilidad e
interoperabilidad entre los distintos segmentos de la organizacin (o incluso
diferentes organizaciones en el "ecosistema" de negocios). Esto provoca dificultades
en el desarrollo y despliegue de los procesos empresariales compartidos. Los
componentes empresariales y de infraestructura son discretos y reutilizables a travs
del cdigo y las tcnicas de reutilizacin de EAI. Sin embargo, a menudo se replican
y son redundantes
Nivel 4: Servicio
Las aplicaciones compuestas se construyen a partir de los servicios de acoplamiento
dbil. La forma en que los servicios pueden ser invocados se basa en estndares
abiertos y es independiente de la aplicacin de origen. Los servicios se ejecutan en
una infraestructura de TI, que es compatible con los protocolos adecuados,
mecanismos de seguridad, transformacin de datos y capacidades de gestin de
servicios. Los servicios por lo tanto, pueden interactuar a travs de todas las partes
de la organizacin e incluso a travs de diferentes organizaciones del ecosistema, y
son a menudo administrados por la asignacin de responsabilidades para la gestin
de los acuerdos de nivel del servicio (SLA) a los sectores de la organizacin.

El negocio funcionalidad se ha analizado en detalle y se descompone en diversos
servicios que residen dentro de una arquitectura empresarial que garantice que los
servicios sern compatibles a nivel de negocio. Adems, es posible definir los
servicios a travs de un lenguaje de especificacin tales como WSDL o Servicio
Arquitectura de componentes (SCA), que define sin ambigedad las operaciones
realizadas por el servicio, lo que permite la construccin de un catlogo de
servicios. La combinacin de la informtica y de servicios arquitecturas permite la
construccin de sistemas en base a estos servicios, operando a la derecha a travs
de las organizaciones en el ecosistema. Sin embargo, en esta etapa la composicin
de los servicios y flujo de control dentro de una aplicacin compuesta todava estn
definidos por los desarrolladores que escriben cdigo a la medida. Esto limita la
agilidad del desarrollo de nuevos procesos de negocio como servicios.
Nivel 5: Servicios de compuestos
En este nivel de madurez de los servicios es posible construir un proceso de negocio
para que interacten con un conjunto de servicios, no slo por el desarrollo a medida,
sino por el uso de una composicin de servicios o por un lenguaje de modelado
procesos empresariales y controles a travs de los servicios individuales.
Esto permite que el conjunto de los servicios compuestos en los procesos de
negocios, puedan ser cortos o de larga ejecucin, sin la construccin significativa de
cdigo. Por lo tanto, el diseo y el desarrollo de servicios son giles, y pueden ser
realizados por los desarrolladores bajo la estrecha orientacin de los negocios
analistas.
Nivel 6: Servicios virtualizados
Los servicios de negocios y de TI ahora se ofrecen a travs de una fachada, un nivel
de direccionamiento indirecto. El consumidor de servicios no invoca el servicio
directamente, sino a travs de la invocacin de un " servicio virtual. La
infraestructura realiza el trabajo de convertir la invocacin virtual en una llamada
fsica del servicio real, y puede, como parte de esta conversin cambiar la direccin,
en donde la red, el protocolo, los datos, y el patrn de sincronizacin estn
contenidos en la llamada. Tal conversiones pueden ser un servicio complejo en su
propio derecho, tales como la transformacin de los datos de un modelo de datos a
otro.

El servicio virtual se convierte de modo acoplado de manera ms flexible en cuanto a
la infraestructura en la que se est ejecutando, lo que permite ms oportunidades
para la composicin de servicios. Esto est en contraste con los niveles ms bajos de
madurez del servicio, donde el servicio es ms estrechamente acoplado a la
infraestructura. Aunque la virtualizacin se ha utilizado en los sistemas SOA, este
nivel se extiende el concepto (ventajas) de la virtualizacin de servicios.
Nivel 7: Servicios dinmicamente reconfigurable
Antes de este nivel, el conjunto de procesos de negocio, aunque gil, se lleva a cabo
en tiempo de diseo desarrolladores (bajo la gua de anlisis de negocio y jefes de
producto). Ahora bien, este conjunto puede ser realizado en tiempo de ejecucin, ya
sea asistido por los analistas de negocio a travs de herramientas adecuadas, o por
el propio sistema. Esto requiere la capacidad de acceder a un repositorio de servicios
y para consultar este repositorio a travs de las caractersticas de los servicios
requeridos. En su forma ms simple, estas caractersticas pueden haber sido definida
de antemano, lo que restringe el sistema a seleccionar y localizar ejemplos
especficos de servicios.
Dimensiones
Nivel de madurez de SOA de una organizacin puede ser evaluada a travs del siguiente
conjunto de dimensiones los cuales son indicadores esenciales para la adopcin de SOA
eficaz:
Negocios o VISTA EMPRESARIAL
La dimensin empresarial se centra en la arquitectura de negocio, es decir,
direcciona las polticas del negocio y su respectivo diseo de procesos de
negocio. La dimensin de negocios tambin se ocupa de cmo se asigna el costo de
las capacidades de TI en toda Electrocentro S.A..
Organizacin y Gobierno
La dimensin de Organizacin y Gobierno se centra en la estructura y el diseo de la
propia organizacin y las medidas necesarias de eficacia de la organizacin en el
contexto de una arquitectura SOA y la gobernabilidad de SOA. El aspecto
organizacional se centra en la estructura de la organizacin, relaciones, roles y el
empoderamiento necesario para adoptar una estrategia orientada a los servicios.

Este incluye los tipos y el alcance de las habilidades, la formacin y la educacin que
estn disponibles en la organizacin. Gobierno se asocia con procesos formales de
gestin para mantener las actividades de TI, capacidades de servicio, y soluciones
SOA alineados con las necesidades de Electrocentro S.A..
Mtodo
La dimensin del mtodo se centra en los mtodos y procedimientos empleados por
la organizacin por su TI y la transformacin del negocio, y la madurez de la
organizacin en todo el Ciclo de vida de desarrollo de Software, tales como el uso de
la gestin de requisitos, tcnicas de estimacin, gestin de proyectos, procesos de
garanta de calidad, las metodologas, tcnicas de diseo y herramientas para el
diseo de soluciones.
Aplicacin
La dimensin de aplicacin se centra en la estructuracin de las aplicaciones y su
descomposicin funcional, reutilizacin, flexibilidad, fiabilidad y capacidad de
ampliacin de las respectivas soluciones, la comprensin y uso uniforme de las
mejores prcticas y patrones que han sido creadas para servir a las diferentes lneas
de negocio esencialmente y la disponibilidad de esquemas empresariales.
Arquitectura
La dimensin de Arquitectura se centra en la estructura de la arquitectura que incluye
topologa, tcnicas de integracin, las decisiones de arquitectura empresarial,
normas y polticas alineados a los niveles servicios web para su adopcin y los
criterios de cumplimiento SOA, y los artefactos tpicos producidos.
Informacin
La dimensin de la informacin se centra en cmo se estructura la informacin, cmo
la informacin es modelado, el mtodo de acceso a los datos de Electrocentro S.A.,
la abstraccin del acceso a los datos en los aspectos funcionales, las caractersticas
de datos, la capacidad de transformacin de datos, el servicio y el proceso de
definiciones, la manipulacin de los identificadores, credenciales de seguridad,
gestin del conocimiento, modelo de informacin y gestin de contenidos.
Infraestructura y Gestin
La dimensin de Infraestructura y Gestin se centra en la infraestructura de la
organizacin, gestin de servicios, capacidades tecnolgicas de las operaciones de
TI, gestin de TI y administracin de TI.

Los beneficios que traera la realizacin de evaluacin de madurez SOA bajo el marco de
referencia de Servicio de Integracin del Modelo de Madurez (OSIMM- Open Gruop) de
alto nivel, es reforzar la hoja de ruta en cuanto a la Estrategia de transicin y Modelo
Conceptual de Servicios que guen la arquitectura objetivo propuesta en la Arquitectura de
Aplicaciones Objetivo(un gobierno de servicios bajo una arquitectura de integracin
orientada a servicios) para la Modernizacin de la plataforma tecnolgica de la
EMPRESA.
10.1 Ejecucin para un modelo de madurez SOA
Para creacin de un modelo de madurez SOA, bajo el marco de referencia de Servicio

de Integracin del Modelo de Madurez (OSIMM- Open Gruop) de alto nivel y acorde a
la situacin actual de la Entidad se definen dos fases mencionadas a continuacin:
A. Fase 1: Realizacin de evaluacin de madurez SOA
Esta fase incluye la especificacin de alto nivel del marco de referencia de Servicio
de Integracin del Modelo de Madurez (OSIMM- Open Gruop), utilizado para el
diseo y construccin del modelo de evaluacin por dimensiones, indicadores de
madurez sus respectivos niveles, adaptado a la Entidad para una valoracin de las
evaluaciones de madurez SOA.
Actividades Entregables Descripcin

Construccin de Evaluacion Madurez Elaboracin de la herramienta
la herramienta de SOA de evaluacin de madurez SOA,
evaluacin de bajo la metodologa Grupo de
madurez SOA Servicio de Integracin del
Modelo de Madurez (SOA
Maturity Model Integration
-OSIMM) del Open Gruop
Realizacin de la Evaluacion Madurez La avaluacin fue realizada por:
valoracin de SOA - Artiaga Tapia Josmel
evaluacin de - Casimiro Lopez Frank
madurez SOA - Chamorro Reinoso Jhony
- Mamani Cordova Meyda
- Prado Laura
- Travezao Lopez Aldair
B. Fase 2: Anlisis de modelo de madurez SOA
Esta fase incluye el anlisis de la evaluacin de madurez SOA inicial desarrollado
en la fase 1 en la herramienta Evaluacin Madurez SOA para la realizacin de

modelo que permita la proyeccin de una modelo de madurez SOA acorde al
Modelo Conceptual de Servicios que guen la arquitectura objetivo y a la Estrategia
de Transicin 1 y 2 con su respectivo anlisis de la evaluacin de madurez SOA
para la Modernizacin de la plataforma tecnolgica de la EMPRESA.
- Resultado de evaluacin de nivel de madurez SOA
El resultado de la evaluacin realizada en la fase 1 es Nivel 1 de Madurez

SOA, as como lo muestra en el Nivel General de Madurez SOA y
representado grficamente en la ilustracin Puntaje de madurez actual
Nivel General de Madurez SOA
Puntaje de madurez actual

- Anlisis del Nivel 1 de Madurez SOA - Riesgos de Continuar en el Nivel
Actual
Posibilidad de inversiones sin retorno en SOA

Aumento del costo de mantenimiento de SOA
Aumento en la dificultad de evolucin en SOA proporcional al nmero
de servicios desarrollados
Riesgo en dar visibilidad de los beneficios de SOA en cuanto al re-
uso de servicios
Falta de visibilidad sobre los resultados de SOA
Dificultad a futuro para obtener presupuesto para el desarrollo de
servicios y evolucin de SOA
Falta de infraestructura para el Gobierno de SOA
- Conclusin del Escenario Actual de SOA Nivel 1 de Madurez SOA de la
Entidad
Hay una necesidad de evolucin para apoyar las iniciativas SOA de la Entidad
con los siguientes objetivos:
Potencializar los beneficios ms importantes de SOA
Reducir el posible costo de mantenimiento y desarrollo adicional
generado
Evitar la falta de visibilidad y retorno de SOA
Tener un hoja de ruta planeado y ejecutarlo para mitigar los riesgos
de evolucin y ejecutar proyectos seguros trayendo beneficios
inmediatos
- Proyeccin del modelo de madurez SOA para la Entidad
El resultado de la proyeccin de evaluacin realizada en la fase 1 para los

aos 2014 es Nivel 2.00 y para el 2016 es Nivel 3.25 de Madurez SOA, as
como lo muestra la ilustracin proyeccin de Nivel General de Madurez SOA y
representado grficamente en la ilustracin Puntaje proyeccin de Madurez

Proyeccin de Nivel General de Madurez SOA
Puntaje proyeccin de Madurez

- Anlisis de las proyecciones del modelo de madurez SOA para los aos
2014 Nivel 2 y 2016 Nivel 3.25 de Madurez SOA por rea de capacidad
Hoja de ruta Sugerido para puntaje 3.5 al 5.75 DIMENSIN VISTA

EMPRESARIAL o de NEGOCIO
SOA permite la automatizacin de procesos de negocio, medicin de la
eficiencia y optimizacin a lo largo del tiempo que de soporte al ciclo de
vida completo de los procesos de negocio:
Creacin de cuadros de mando departamentales sobre los procesos

Controlar los SLAs (acuerdos de nivel de servicio) de los procesos a
travs de indicadores
Visin de Procesos orquestando servicios
Construccin de los procesos principales con foco en beneficios para
TI
Mayor foco en procesos, creando vnculos entre TI y negocio (un
repositorio compartido de procesos con alguna rea de negocios
Creacin de tableros de control en tiempo real con base en procesos
automatizados.
Hoja de ruta Sugerido para puntaje 1.0 al 4.75 DIMENSIN
GOBERNANCIA Y ORGANIZACIN
SOA requiere alineacin organizacional con objetivos de negocio,
incluyendo incentivos y entrenamiento para motivar comportamiento
deseado y nuevo roles y responsabilidades:
Creacin de un plan de evolucin SOA en sintona con el Plan de
Evolucin del Negocio
Entrenamientos de SOA para los analistas del negocio
Gestin de SLAs (acuerdos de nivel de servicio), Alertas y Procesos
de Escalacin
Mayor involucramiento de las reas de negocio y procesos en las
soluciones SOA, mejorando la relacin entre TI y Negocios
Hoja de ruta Sugerido para puntaje 1.0 al 4.0 DIMENSIN MTODOS
Gobierno SOA ataca la implementacin y desarrollo de polticas y
procedimientos para asegurar entregas en SOA y las estrategias de
negocio:
Creacin de un plan de evolucin SOA en sintona con el Plan de
Evolucin del Negocio
Entrenamientos de SOA para los analistas del negocio
Gestin de SLAs (acuerdos de nivel de servicio), Alertas y Procesos
de Escalacin
Mayor involucramiento de las reas de negocio y procesos en las
soluciones SOA, mejorando la relacin entre TI y Negocios
Hoja de ruta Sugerido para puntaje 1.25 al 3.25 DIMENSIN
APLICACIONES

SOA requiere un enfoque a nivel empresarial para desarrollar,
implementar y satisfacer los proyectos, aplicativos y servicios:
Inicio de Iniciativas de Gestin Bsica de Procesos (Pequeas
iniciativas de solucin con Gestin de procesos de negocio y
Monitoreo de actividades de negocio
Reglas y polticas del negocio abstradas y retiradas del cdigo de las
aplicaciones, estructuradas como reglas de negocio y disponibles
como servicios
Estructura de Gobierno con polticas definidas y control en la
contribucin de proyectos y reas para la evolucin de SOA
Creacin de Aplicaciones Compuestas con el objetivo de reutilizar la
infraestructura SOA facilitando la creacin de portales, y la
diseminacin e interconexin entre usuarios, servicios, contenido e
informacin de los sistemas (I.e. front-end (entrada nica) unificado,
consolidacin de interfaces) y con el objetivo de ofrecer una visin
nica a los procesos de negocio (Portal de Procesos)
Hoja de ruta Sugerido puntaje 1.0 al 4.00 DIMENSIN
ARQUITECTURA
La arquitectura empresarial permite incluir nuevos sistemas en el
ambiente actual reflejando la visin futura de su organizacin y la
estrategia SOA:
Inicio de evolucin en SOA a travs del establecimiento de una hoja
de ruta y el establecimiento de mtricas e indicadores de gestin de
la hoja de ruta
Implementacin del uso de repositorio de servicios, catalogacin y
taxonoma de servicios
Construccin y aplicaciones de las mejores prcticas (arquitectura,
patrones, estndares), por medio de la definicin, utilizacin y
aseguramiento de estndares y patrones de arquitectura SOA
Implementar mecanismos que definan y mantengan el control de los
servicios a nivel de la organizacin
Creacin de una capa de servicios de negocio unificada
Adopcin extendida de una metodologa SOA

Grupo de Arquitectura inicia actividades de negocio como objetivo de
orientar y diseminar el uso de SOA
Guas para la puntuacin y calificacin de proyectos, de acuerdo a la
arquitectura SOA, polticas y patrones, as como su contribucin a la
evolucin de la Hoja de ruta
INFORMACIN
La Informacin y el anlisis proveen las mtricas clave que permitan el
mejoramiento del negocio, en donde el objetivo principal de SOA es
formar formatos cannicos (modelo que define la estructura de la
informacin en una organizacin):
Acciones iniciales para la representacin estandarizada de objetos de
negocio formatos cannicos
Construccin de esquemas y modelos estndares limitados para
procesos, aplicaciones y proyectos.
Creacin de servicios de datos Wrapper-style (Estilos de envoltura)
para especificaciones WSDL (Lenguaje de descripcin de Servicios
Web) y declarado en el esquema XML ('lenguaje de marcas
extensible') y se utiliza como una envoltura de operacin para un flujo
de mensajes.
Iniciativas de construccin y gerenciamiento de metadatos,
inicialmente departamentales
Inversin en la Integracin de los Datos para anlisis por medio de
Servicios analticos, informacin vinculada al contexto, modelos
convergentes para productos, clientes, etc.
Iniciar proyectos para anlisis departamental sobre algunos procesos,
con el objetivo de mostrar el valor de soluciones BPM y BAM
estructuradas por SOA por medio de Anlisis de Procesos en Tiempo
Real
INFRAESTRUCTURA Y ADMINISTRACIN
La infraestructura SOA ofrece la plataforma y herramientas comunes para
ejecutar sus iniciativas SOA:

Establecimiento de soluciones de apoyo (Error Management y/o BAM
para la generacin de alertas)
Establecimiento de infra-estructura para Gobierno SOA (Repositorio
de Servicios, Polticas, Monitoreo SOA, Portafolio de Servicios, entre
otros)
Externalizacin de la Lgica de los Sistemas (Orquestacin de
Servicios)
Orquestacin utilizada para que la lgica sea controlada por
entidades externas (orquestador) y no por los sistemas
Externalizacin de Reglas para facilitar el mantenimiento y reducir los
cambios en el ciclo de vida de los servicios
Establecer infraestructura bsica para la gestin de los servicios
(SLAs (acuerdos de nivel de servicio), QoS (calidad de servicio),
Polticas y Seguridad)
Definicin de una infraestructura comn para todos los servicios,
proveyendo los niveles de servicio apropiados y generando un
aprovechamiento de la plataforma.
Infraestructura para el versionamiento dinmico de servicios
Establecimiento del modelo de operacin de servicios y medicin de
la infraestructura tecnolgica
Ofrecer la capacidad de proveer enrutamiento dinmico y proteccin
de la infraestructura

Arquitectura de Aplicaciones

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Arquitectura de Aplicaciones

Încărcat de

Drepturi de autor:

Formate disponibile

ARQUITECTURA

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 2

1.1 Propsito del Documento......................................................................................5

1.2 Compromiso contractual............................................................................................6

1.3 Glosario de Trminos y abreviaciones...................................................................7

3.1 Objetivos de Alto nivel.........................................................................................10

3.2 Objetivos Especficos..........................................................................................10

3.3 Definicin de Stakeholders y sus intereses..........................................................11

4.1 Principios de Arquitectura....................................................................................23

4.2 Polticas y Estndares.........................................................................................24

6 Arquitectura de Aplicaciones - Base...........................................................................29

6.1 Arquitectura Conceptual de Aplicaciones Base................................................29

6.2 Catlogo de Aplicaciones Lgicas Base............................................................30

6.3 Vista del catlogo de aplicaciones Actual............................................................30

7 Justificacin para la definicin de una Arquitectura de Aplicaciones..........................32

8 Definicin de Arquitectura de Aplicaciones.................................................................42

8.1. Descripcin de la Arquitectura de Aplicaciones.......................................................42

8.2 Estrategia de transicin para lograr la Arquitectura de Aplicaciones Objetivo..........45

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 3

9 Una Arquitectura de Aplicaciones que emerge a servicios.........................................54

9.1 Modelo Conceptual de Servicios que guen la arquitectura objetivo....................54

9.2 Catalogo Funcionalidades y Servicios de Aplicaciones - hoja funcionalidades....59

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 4

1.1. Propsito del Documento

Este documento comprende la descripcin de la arquitectura de aplicaciones base,

El documento de Definicin de Arquitectura de Aplicaciones es el entregable

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 5

Este entregable cubre la fase C Arquitectura de Aplicaciones del Mtodo de

Este documento como entregable propio de la metodologa TOGAF (The Open

1.3. Glosario de Trminos y abreviaciones

TOGAF -(The Open Group Architecture Framework)

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 6

SIGA: Sistema de Informacin de Gestin Administrativa

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 7

El propsito de esta seccin es presentar el alcance de la arquitectura de aplicaciones que

Identificar las diferentes aplicaciones de Electrocentro S.A., representada en un

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 8

El cometido de esta seccin es presentar los objetivos de la arquitectura de aplicaciones y

Actualizar el inventario y realizar el diagnstico de la situacin actual de los

ID TITULO TIPO DESCRIPCIN DEL OBJETIVO

OE-2 Equipo de TI Arquitectura Fortalecer la implementacin

OE-3 Servicios TI Estratgico Fortalecer la gestin

OE-4 Comunicacin Arquitectura Sugerir y fortalecer la

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 9

travs del cumplimiento de la

3.3. Definicin de Stakeholders y sus intereses

En esta seccin se encuentran registrados la informacin referente a los

do Maximus II MAXIMUS II, que

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 10

Sistema de apoyo al rea

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 11

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 12

Notiman: Aplicativo para

Factura, PAM Electrocentro - rea de

Aplicativo para control de

rea de Administracion de Control de Aplicativo de control de

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 13

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 14

funcionales por s mismos, que puedan ser ensamblados de diferentes

DEFINICIN DE LA ARQUITECTURA DE APLICACIONES 15

4.1. Principios de Arquitectura

Nombre Flexibilidad de aplicaciones

Nombre Racionalizacin de Aplicaciones