superintendencia nacional de salud · 5.1.2 directorio activo _____ 15 5.1.3 iométrico ... 7.1...

COFL02 Página 1 de 49

Superintendencia Nacional de Salud

OFICINA DE TECNOLOGÍAS DE LA INFORMACIÓN

ARQUITECTURA DE REFERENCIA DE SOFTWARE BASE PARA LAS SOLUCIONES DE T.I.

EN LA SUPERINTENDENCIA NACIONAL DE SALUD

AGOSTO DE 2017


Historia de versionamiento

Fecha Versión Comentarios Autor

2015-08-20 0.1 Versión inicial Ing. Mario Monsalve

2015-08-23 0.2 Ajustada según retroalimentación

recibida al documento en general de los

grupos de Aplicaciones y Arquitectura.

Ing. Mario Monsalve

2016-03-11 0.3 Versión Ajustada según lineamientos

internos de la entidad.

Ing. Mario Monsalve

2016-05-31 0.4 Inclusión del modelo de Gobierno Ing. Mario Monsalve

2015-08-20 0.5 Versión Ajustada según

retroalimentación del Grupo de

Arquitectura y Aplicaciones.

Ing. Mario Monsalve

2015-09-29 0.6 Ajustes solicitados por el Grupo de

Aplicaciones, Oficina Asesora de

Planeación y Mintic.

Ing. Mario Monsalve

2016-10-21 1.0 Ajustes de alineación con el sistema

integrado de gestión de calidad

Ing. Mario Monsalve

2017-02-21 1.1 Ajuste con nuevos lineamientos y

retroalimentación de los grupos de la

OTI.

Ing. Erika Díaz – Ing. Luis

Enrique Camacho – Ing.

Germán Cortes.

2017-08-30 2.0 Ajuste solicitado por el grupo de

aplicaciones

Ing. Erika Díaz – Ing. Luis

Enrique Camacho


Aprobación del documento.

Por política de cero papel, se suspende la tabla de firmas de los autores y aprobadores del presente documento que venían siendo incluidas en la versión 1.0, sin embargo, cabe resaltar que los lineamientos aquí definidos fueron propuestos por el Grupo de Gestión de Arquitectura de T.I. en cabeza de la coordinadora del Grupo Ing. Erika Díaz Abella, posteriormente fueron revisados y evaluados en mesas de trabajo donde participan los coordinadores de los grupos de: Administración y Seguridad de la Información, Ing. Manuel Acero, Gestión de Aplicaciones de T.I., Ing. Patricia Manosalva y Gestión de Infraestructura y Soporte de T.I., Ing. Fabio Andrés Parrado y finalmente fueron aprobados por el jefe de la oficina de Tecnologías de la Información, Ing. Guillermo Cadena Ronderos, quien da la formalidad a dicha aprobación, solicitando a la Oficina Asesora de Planeación, la publicación de éste documento en el portal interno de la entidad.


TABLA DE CONTENIDO

1 INTRODUCCIÓN Y ANTECEDENTES _______________________________________ 7

2 PROPÓSITO DEL DOCUMENTO __________________________________________ 7

3 VISIÓN DE ALTO NIVEL DE LA ARQUITECTURA DE REFERENCIA DE LA SUPERINTENDENCIA NACIONAL DE SALUD ____________________________________ 10

3.1 Visión Actual de Arquitectura de Aplicaciones de la Supersalud ___________ 10

3.2 Visión lógica de la arquitectura de referencia _________________________ 12

3.3 Visión de la nueva Arquitectura de Referencia de componentes de software base para las soluciones de TI ________________________________________________ 12

4 DIAGRAMA DE COMPONENTES HABILITADORES DE ALTO NIVEL DE LA ARQUITECTURA DE REFERENCIA ____________________________________________ 14

5 COMPONENTES TECNOLÓGICOS HABILITADORES DE SOFTWARE BASE PARA LAS NUEVAS SOLUCIONES _____________________________________________________ 14

5.1 Capa de acceso y seguridad ________________________________________ 14 5.1.1 Administración ___________________________________________________________ 15 5.1.2 Directorio Activo __________________________________________________________ 15 5.1.3 Biométrico _______________________________________________________________ 16

5.2 Capa de presentación ____________________________________________ 16 5.2.1 Portalización _____________________________________________________________ 16 5.2.2 PORTAL 2.0 (CONTENIDO, COMUNIDADES, FOROS, BLOGS, CENTRO DE TAREAS, WIKIs) _ 16 5.2.3 Framework De Desarrollo – Alm (Application Life Cicle Management). _______________ 18 5.2.4 ALM - TFS _______________________________________________________________ 19 5.2.5 Administración de la configuración ___________________________________________ 20

5.3 Capa de aplicaciones y lógica de negocio _____________________________ 20 5.3.1 Componente de negocio ____________________________________________________ 20 5.3.2 Servidor de Aplicación _____________________________________________________ 20 5.3.3 Patrón de Localización _____________________________________________________ 20 5.3.4 Servicios de Negocio _______________________________________________________ 21 5.3.5 Manejo de Caché _________________________________________________________ 21 5.3.6 Componentes de Acceso a Datos _____________________________________________ 21 5.3.7 Componente de Automatización de los Procesos de Negocios (BPM) ________________ 21

5.3.7.1 Reglas de Negocio ______________________________________________________ 22 5.3.7.2 Gestor Procesos y Flujos de Trabajo ________________________________________ 23 5.3.7.3 Centro de trabajo/gestión - bandeja de entrada ______________________________ 23 5.3.7.4 Centro de Control ______________________________________________________ 24 5.3.7.5 Centro de Tareas _______________________________________________________ 24


5.4 Capa media (Middleware) _________________________________________ 24 5.4.1 Integración ______________________________________________________________ 24

5.4.1.1 Bus empresarial de servicios ______________________________________________ 25 5.4.1.2 Catálogo de Servicios ____________________________________________________ 26 5.4.1.3 Servicios Web para SOA __________________________________________________ 27

5.4.2 Servidor de aplicaciones ____________________________________________________ 27

5.5 Capa de Persistencia de Datos ______________________________________ 27 5.5.1 Clúster de base de datos ____________________________________________________ 27 5.5.2 Base de datos ____________________________________________________________ 28 5.5.3 Transaccional ____________________________________________________________ 28 5.5.4 Analítica ________________________________________________________________ 28

5.5.4.1 Herramientas de BI _____________________________________________________ 29 5.5.5 Auditoria ________________________________________________________________ 30 5.5.6 Repositorio de Gestión Documental ___________________________________________ 30 5.5.7 Generación de Reportes e Indicadores de Gestión _______________________________ 30

5.6 Capa de Sistemas operativos y máquinas virtuales _____________________ 31

5.7 Capa de Infraestructura ___________________________________________ 31

6 VISTA DESPLIEGUE DE SERVICIOS _______________________________________ 31

7 MODELO DE GOBIERNO DE LA ARQUITECTURA DE REFERENCIA PARA LOS COMPONENTES DE SOFTWARE BASE DE LAS APLICACIONES EN LA OTI _____________ 33

7.1 Proceso de gobierno de la arquitectura de referencia de software_________ 33

7.2 Definición y Mantenimiento de la Arquitectura de Referencia de Software _ 34 7.2.1 Elaborar líneas base de la ARS _______________________________________________ 34

7.3 Despliegue de la Arquitectura de referencia __________________________ 34 7.3.1 Socializar líneas base de la ARS en el equipo de la OTI ____________________________ 34 7.3.2 Ajustes y aprobación de nuevas líneas base ____________________________________ 34

7.4 Gestionar solicitudes de cambios o personalizaciones a la ARS ___________ 35 7.4.1 Recepción de solicitudes de revisión arquitectónica de nuevos proyectos de aplicaciones 35 7.4.2 Emitir conceptos y sugerencias de modelos arquitectónicos convenientes ____________ 35

7.5 Revisión de cumplimiento _________________________________________ 35 7.5.1 Planear y programar revisiones de cumplimiento a nuevos proyectos ________________ 35 7.5.2 Efectuar revisiones de cumplimiento __________________________________________ 35 7.5.3 Manejo de no conformidades ________________________________________________ 35

7.6 PRINCIPIOS PARA EL GOBIERNO DE LA ARQUITECTURA DE REFERENCIA DE SOFTWARE ___________________________________________________________ 36

7.6.1 Estandarización ___________________________________________________________ 36 7.6.2 Reutilización _____________________________________________________________ 36 7.6.3 Desempeño ______________________________________________________________ 36 7.6.4 Gestión del Conocimiento ___________________________________________________ 37 7.6.5 Código fuente ____________________________________________________________ 37 7.6.6 Costos de inversión y tenencia _______________________________________________ 37 7.6.7 Servicios Soporte __________________________________________________________ 37 7.6.8 Innovación _______________________________________________________________ 37 7.6.9 Disponibilidad ____________________________________________________________ 38 7.6.10 Escalabilidad _____________________________________________________________ 38


7.6.11 Interoperabilidad _________________________________________________________ 38 7.6.12 Plataforma ______________________________________________________________ 38 7.6.13 Seguridad _______________________________________________________________ 38

7.7 Organización humana que requiere este modelo de gobierno ____________ 38 7.7.1 Roles que intervienen ______________________________________________________ 38

7.8 Responsabilidades frente al modelo _________________________________ 39 7.8.1 Coordinación del grupo de arquitectura _______________________________________ 39 7.8.2 Coordinación del grupo de Aplicaciones _______________________________________ 40 7.8.3 Coordinación del grupo de Infraestructura y Soporte _____________________________ 40 7.8.4 Coordinación del grupo de Administración y seguridad de la Información ____________ 40

7.9 Lineamientos a considerar en la implementación de soluciones de TI ______ 41 7.9.1 Requerimientos para migración y población de datos ____________________________ 41 7.9.2 Requisitos no funcionales a tener en cuenta ____________________________________ 42

7.9.2.1 Generales _____________________________________________________________ 42 7.9.2.2 Base de Datos __________________________________________________________ 43 7.9.2.3 E-Learning ____________________________________________________________ 43 7.9.2.4 Documentación y notación _______________________________________________ 43 7.9.2.5 Seguridad _____________________________________________________________ 45

8 LISTA DE ABREVIATURAS Y GLOSARIO ____________________________________ 48


1 INTRODUCCIÓN Y ANTECEDENTES

La Superintendencia Nacional de Salud definió en su plan estratégico de tecnología del 2014 el consolidar un equipo de trabajo de arquitectura de TI que desarrolle el ciclo de vida de las arquitecturas de las soluciones estratégicas que tienen un apalancamiento en las TIC con el fin de:

• Alcanzar mejor desempeño • Agilizar el negocio • Soportar nuevas funcionalidades • Soportar una plataforma orientada a flujos de trabajo

Y que las soluciones cumplan:

• El estándar WEB 2.5, permitiendo así el acceso web de los usuarios desde cualquier dispositivo (incluso en móviles)

• Garantizar la disponibilidad de componentes analíticos de inteligencia de negocios

• Que su arquitectura sea orientada a servicios (SOA Service oriented architecture) y que sus componentes interoperen o integren los servicios a través de un bus empresarial de Servicios ESB

• Que cumpla con los estándares de industria y seguridad.

El presente documento tiene por finalidad describir la Arquitectura de referencia de los componentes de software de las futuras soluciones de TI para la Superintendencia Nacional de Salud.

Para una mejor comprensión del presente documento, se requiere que el lector conozca el marco de la Metodología de Arquitectura empresarial.

2 PROPÓSITO DEL DOCUMENTO

Este documento de Arquitectura de referencia Formula los lineamientos y estándares de productos a integrar de software base y de gestión para poder garantizar trazabilidad y control en los proyectos de TI que se ejecuten en la entidad y proponer unas prácticas gobernables desarrollo de soluciones de software orientadas a servicios.

Una arquitectura de referencia de componentes de software base define una visión o estado futuro ideal para una organización que permita orientar la toma decisiones de diseño y evolución de las soluciones de TI (Sistemas de Información). Una arquitectura de referencia de componentes de software es crítica para la definición de una ruta de adopción teniendo en cuenta el estado actual y futuro del negocio y la tecnología.


Por ello este documento presenta la definición del Grupo de Arquitectura de la OTI para la arquitectura de los componentes de software base de las soluciones de TI de la Superintendencia Nacional de Salud a alto nivel, indicando capas y componentes que lo integran.

Este documento presenta conceptualmente un esquema para la arquitectura de referencia que estandarice los diseños de las aplicaciones y sobre ella se implementen tanto los requerimientos funcionales como los no funcionales de la Entidad.

Beneficios Importantes de una Arquitectura de Referencia

Varias son las ventajas de disponer de una arquitectura de referencia para los componentes de software base de las soluciones de TI:

• Definición una visión o estado futuro deseable para los dominios del diseño de una entidad y para la oficina de TI.

• Definición de una ruta de adopción teniendo en cuenta el estado actual y futuro del negocio y la tecnología.

• Los fundamentos y principios de una arquitectura de referencia incentivan la reutilización, estandarización y permite administrar mejor la evolución y el control del ciclo de vida de las aplicaciones.

• Crecimiento controlado y consistente de los sistemas de información basado en los lineamientos de la arquitectura y calidad de servicio, independiente de programadores y proveedores de software.

• Procurar la alineación de la tecnología para alcanzar los objetivos organizacionales.

• Disposición de estándares y herramientas que el mercado internacional ofrece para garantizar una mayor duración de las inversiones en TI.

• Mejor composición de servicios para soportar nuevos procesos organizacionales.

• Flexibilidad y mayor capacidad para implementar la demanda de nuevas soluciones o requerimientos

• Mejora en la oportunidad y agilidad para salir en producción en las implementaciones (time-to-market).

• Reducción de costos de inversión y operación a través de una plataforma común de servicios empresariales de TI reutilizables entre diferentes sistemas de información.

• Reducción de riesgos. Cada proyecto parte sobre la experiencia e inversión previa, en lugar de iniciar de cero con altos costos.

• Aseguramiento de criterios de calidad para los servicios requeridos.

• Mayor objetividad en las directrices para desarrollo de nuevas arquitecturas de solución y para la toma de decisiones técnicas de conveniencia.

• Entrega de las pautas y las ideas fundamentales para la integración de los elementos de la arquitectura como lo demuestra en las capas o componentes de construcción (SBB´s Solution building blocks).

• Facilitar y permitir la documentación de las capas de la arquitectura, bloques de construcción de la arquitectura (ABB), las opciones de capas y decisiones de diseño que contribuyen a la creación de una arquitectura consistente y sostenible.


• Permite disponer de un lenguaje común en las conversaciones con los vendedores de productos que habilitan los componentes de las soluciones.

La arquitectura referencia está diseñada para responder a algunas de las preguntas clave y los problemas encontrados por los arquitectos tales como:

o Cuáles son los aspectos de una arquitectura, expresada en términos de capas que se deben considerar en el diseño de soluciones basadas en principios y orientada a los servicios

o Cuáles son los elementos básicos que deben incluir en cada capa de las soluciones o Cuáles son algunas de las principales decisiones de arquitectura que se deben

tomar a la hora de diseñar una solución de TI (Sistema de Información) para la entidad.

Modelo de Gobierno de Arquitectura De Referencia

Dado el impacto tan relevante que tiene en la entidad la toma de decisiones alrededor de la Arquitectura de Referencia de Software base, se hace necesario tener claridad sobre el gobierno de dicha arquitectura, es decir, los niveles de autoridad y participación que están involucrados en sugerir y acoger los lineamientos, que además están directamente relacionados con los planes de inversión y actualización de la plataforma tecnología para en la Supersalud. Es por ello que antes de describir la Arquitectura de referencia en este documento se describe el modelo de gobierno de la Arquitectura de referencia para los componentes de software base de las aplicaciones en la OTI.


3 VISIÓN DE ALTO NIVEL DE LA ARQUITECTURA DE REFERENCIA DE LA

SUPERINTENDENCIA NACIONAL DE SALUD

3.1 Visión Actual de Arquitectura de Aplicaciones de la Supersalud

La Superintendencia Nacional de Salud ya cuenta con un conjunto de aplicaciones que se articularán con la nueva propuesta de Arquitectura de Referencia de componentes de software base para las soluciones de TI, la cual aporta componentes integradores:

La evolución de cómo se conformó el portafolio de aplicaciones de la Supersalud, no fue guiada por estándares sino solo por suplir requerimientos funcionales de la manera más oportuna y económica posible

Las aplicaciones implementadas en los últimos 4 años empezaron a observar algunos componentes comunes:

Base de Datos Microsoft SQL-Server

Sistemas Operativos Windows Server junto con servidor de aplicaciones IIS

La arquitectura de software no fue estandarizada, por ello cada aplicación tiene su propia arquitectura, que quedo a criterio del proveedor (desarrollador) de la misma.

El re-uso de componentes de software no se da en las aplicaciones

El conocimiento del diseño de las aplicaciones se dispersó y la fuente más confiable son los proveedores que las construyeron


Las aplicaciones se dejaron “envejecer” desde el punto de vista de vigencia tecnológica e incluso licenciamiento que hace mucho más costoso y tedioso mantener y aumentar el nivel de satisfacción de los servicios en los usuarios.

A continuación se ilustra la visión de evolución que se realziado en términos de T.I. para gestionar de manera adecuada los recusos tecnológicos y dar solución a las necesidades identificadas en el PETIC.

Basados en la Hoja de Ruta de nuevas aplicaciones definidas en el PETIC, se incluyen las siguientes aplicaciones, a las cuales se les aplicarán los lineamientos de la Arquitectura de Referencia aquí descrita, en el periodo 2016-2018:

• Aplicación de gestión de PQRD

• Aplicación de gestión documental, correspondencia y archivo.

• Aplicación para la gestión de las actuaciones disciplinarias

• Aplicación para la gestión de los Procesos administrativos

• Aplicación para el seguimiento a las intervenciones que adelanta la entidad

• Aplicación para el registro y asignación de interventores, liquidadores y Contralores.

• Aplicación de gestión de recursos físicos

• Aplicación de gestión de Auditorías para la Delegada de Supervisión Institucional

• Aplicación de gestión de Auditorías para la Delegada de Riesgos

• Aplicación para el registro y la habilitación de las entidades prestadoras de Salud

• Aplicación para la Gestión de Cobro Persuasivo y Jurisdicción Coactiva: Aplicación para la Gestión de contratación.

• Aplicación para la Gestión de recaudo y Cartera

• Nuevo RVCC

• Sistema de B.I.


3.2 Visión lógica de la arquitectura de referencia

En el siguiente esquema se presenta la visión de la arquitectura de solución prevista

en un modelo integrado de gestión de sistemas de información.

3.3 Visión de la nueva Arquitectura de Referencia de componentes de software base para las

soluciones de TI

Motivaciones y principios arquitectónicos a resolverse en la nueva arquitectura de referencia

• Reutilización de licenciamiento de productos o Microsoft o productos de otros proveedores que sean candidatos a reutilizar o Ahorro de Costos de licenciamiento de software base

• Estandarización de arquitecturas


• Reutilización de Componentes de las aplicaciones existentes vía servicios web. Como por ejemplo: Administración de Cuentas x Cobrar, Recaudo, Facturación (Utilizada en Tasa, Sanciones, Intereses, etc.).

• Mayor independencia para el uso del software y disminuir los costos de licenciamientos de desarrollo patrocinados por la Entidad

• Focalizar base de conocimientos y competencias del personal de la OTI

• Agilidad / Oportunidad en las implementaciones de nuevas soluciones

• Mejorar tiempos de respuesta a implementación de nuevos requerimientos en las aplicaciones

Dominios de la Arquitectura de referencia para los componentes del software Base propuesta para las nuevas aplicaciones

Los anteriores componentes de la arquitectura de software base , son los que este documento de arquitectura de referencia contextualizará y describirá como habilitadores de un nuevo modelo arquitectónico de referencia el cual debe orientar las futuras implementaciones de aplicaciones.

• Canales de Conectividad provistos por el Operacdor vogente (Colombia CompraEficiente)

• Firewall Fortinet D1200

• Servicios de autenticación del directorio de Office 365 (Dyrectory, Ldap) y Single Sign-On

• Perfilamiento de Usuarios

Capa de Acceso y seguridad

• Contenido Web en SharePoint

• Formularios SharePoint

• Búsquedas SharePoint

• Listas de valores

• Colaboración y manejo de enfoque social en SharePoint

Capa de Presentación (Front End)

• Framework de desarrollo Web de MIcrosoft

• Framework desarrollo Apps

• Automatización de Procesos de Negocio (iBPMS)

• eLearning (Moodle LMS)

• Componentes Transversales (Citaciones, Notificaciones, CxC, Actos Adm, Recaudo)

Lógica de Aplicaciones y Negocio

• Servidor de Aplicaciones Ms-IIS

• Bus empresarial de servicios, ESB, Motor de Reglas y orquestador Ms BizTalkCapa Media (Middleware)

• Base de Datos relacional SQL Srv

• Base de Contenido empresarial ECM, SharePoint

• Componente Analítico SQL Srv

• Alta Disponibilidad (SQL Srv)

Persistencia Datos

•Windows Server

•HiperVSistemas Operativos y Máquinas

Virtuales

•Nube privada (Iaas, PaaS, Storage, Backup)Infraestructura


4 DIAGRAMA DE COMPONENTES HABILITADORES DE ALTO NIVEL DE LA

ARQUITECTURA DE REFERENCIA

La arquitectura de referencia propuesta se basa en la articulación de los siguientes componentes:

• Seguridad, auditoría y control de acceso

• Canales

• Portalización

• Consultas, Búsquedas de Contenido (SEO) y Visualización

• Frameworks de Desarrollo de aplicaciones

• Flujos de Trabajo, Centro de Trabajo /Gestión (Bandeja de entrada)

• Lógica de Negocio

• Interoperabilidad

• Base de Datos

• Contenido Documental

• ALM - CMDB

5 COMPONENTES TECNOLÓGICOS HABILITADORES DE SOFTWARE BASE PARA

LAS NUEVAS SOLUCIONES

La arquitectura de software base se define en varias capas: capa de acceso y seguridad, capa de presentación, capa de aplicaciones y lógica de negocio, capa media, capa de datos y persistencia, capa de sistema operativo y virtualización y finalmente la capa de infraestructura.

5.1 Capa de acceso y seguridad Toda la solución debe asegurarse en la red y esta es la capa responsable de la seguridad de la solución. Sólo los usuarios autorizados tienen permiso de acceder a la aplicación. Por lo tanto, los mecanismos de seguridad deben construirse de forma tal que garanticen la

Seguridad, auditoría y control de acceso

Portalización CanalesCentro de Trabajo

(Bandeja de entrada)

Flujos de Trabajo

Consultas, Búsquedas de

Contenido (SEO) y Visualización

Interoperabilidad Lógica de Negocio

Base de DatosContenido

DocumentalALM - CMDB


autenticación y autorización de los usuarios. El uso de conexiones SSL (Socket Secure Layer) proporciona seguridad a nivel de software.

Las herramientas tecnológicas para garantizar canales de acceso seguros vía internet e intranet a los diferentes stakeholders de la Superintendencia Nacional de Salud, en este grupo de componentes se deben integrar los canales de acceso a los proveedores de Red, Firewall, Directorio Activo (LDAP), Herramientas de Control de Fuga de Información, AntiVirus, AntiSpam, controles de actualizaciones en “parches de seguridad” para los Browsers.

A manera especial se debe mencionar la capa de seguridad soportará los requerimientos no funcionales relacionados con:

• SSL • HTTPS • ACTIVE DIRECTORY – LDAP • AUTENTICACIÓN • AUTORIZACIÓN • FIREWALL • PROXY • WSSecurity • Antivirus – Antispam

Para acceso y autenticación se dispondrá del uso de Microsoft Directory (Office 365) LDAP y Políticas de Firewall, que ya posee la entidad, considerando la creación y gestión de los usuarios y el manejo y administración de las trazas de las acciones que se realizan en el sistema con el objeto de tener un control histórico.

5.1.1 Administración Esta es una solución avanzada para el control de acceso y la administración centralizada de identidades que proporciona orquestación de múltiples módulos de autenticación para formar un flujo de autenticación, mejora el diagnóstico y solución de problemas y aumenta el rendimiento de procesamiento en tiempo de ejecución.

Capitalizar esta innovación de versión mejorará el desempeño de la gestión de acceso.

5.1.2 Directorio Activo Actualmente se cuenta con el servicio de Directorio Activo incluido en el servicio de Office 365. Este es un servicio LDAP que da flexibilidad y compatibilidad del directorio estándar LDAP soportando entornos heterogéneos de aplicaciones y puede sincronizarse con directorios externos de LDAP. La actualización de este componente debe estar motivada para mejorar el rendimiento de la gestión del directorio activo y el Single Sign On.

Este componente deberá ser empleado para el acceso de las nuevas soluciones para el registro e ingreso de los usuarios, garantizando un único mecanismo de autenticación y acceso para usuarios internos


5.1.3 Biométrico Este componente se visualiza en el mediano plazo (2018-2019) para las aplicaciones que ofrecen acceso a vigilados y entes del sector.

5.2 Capa de presentación

5.2.1 Portalización El avance de las tecnologías y las nuevas tendencias globales exigen un cambio en las aplicaciones. Los cambios son impulsados por las nuevas necesidades de los usuarios, y estas se centran principalmente en facilidades de uso, colaboración, entre otras.

Las aplicaciones de hoy en día deben cumplir con estándares web 2.0. Que permitan la usabilidad, tener un diseño centrado en el usuario y ambientes de colaboración, entre otras características.

Teniendo en cuenta a el licenciamiento de SharePoint que posee la entidad, se puede identificar que a la fecha esta herramienta en versión 2016 está bien posicionada en el mercado.

Por otra parte, es importante aclarar que el framework de desarrollo utilizado por la entidad, debe permitir que las soluciones sean compatibles con diferentes tipos y versiones de navegadores y así mismo, que integre otras tecnologías de tendencia para web como HTML5 o CSS3, preprocesadores de CSS como SASS o LESS y funcionalidades de fácil creación de interfaces responsive.

Algunas de las funcionalidades son:

- Diseño gráfico personalizable. - Capacidad de personalización en tiempo de ejecución. - Administración del portal. - Seguridad reconfigurada del sitio. - Conjunto de servicios Web 2.0.

5.2.2 PORTAL 2.0 (CONTENIDO, COMUNIDADES, FOROS, BLOGS, CENTRO DE TAREAS, WIKIs)

Herramientas tecnológicas para garantizar un solo Font-End (Red Social). En este grupo de componentes se deben integrar las siguientes funcionalidades:

• Contenido del Portal Institucional (tanto el público como el asociado al perfil del visitante)

• Servicios de Búsquedas

• Acceso a Wikis, que orientan procedimentalmente al visitante

• Manejo de un centro unificado de trabajo que consolide notificaciones y mensajes asociados a la plataforma

• Información de la red de contactos con los que tiene relación autorizada


• Manejo del Blog del visitante y acceso a blogs autorizados por otros actores de la red, junto con el manejo de comentarios sobre los mismos.

• Acceso a Foros de temas especializados donde se le da acceso por su perfil de actor

• Registros de auditoría de las visitas, comentarios y cambios al contenido de su perfil

En este componente tiene como fin el de usar como único Front-End de aplicaciones Microsoft SharePoint. Con ello se logrará ofrecer una única experiencia de usuario, que implica un trabajo de diseño y normalización de la interfaz que pueda aplicarse a cualquier aplicación que se integre a esta estrategia. Dentro de las características a definir están las condiciones de usabilidad, navegabilidad, diseño gráfico y cumplimiento de directrices de gobierno en línea.

El portal Sharepoint integrará los servicios de Office 365 como el mecanismo de inicio de sesión (single sign on), a través de Directorio Activo de Windows para usuarios internos de la Superintendencia Nacional de Salud y un mecanismo alterno de registro de usuarios y autenticación para usuarios externos.

Componentes de Portalización

Este es un front-end a través del cual los usuarios podrán acceder a la aplicación.

Esta capa de presentación se deberá construir utilizando los componentes de portal de Microsoft Sharepoint y como estándar el uso de web 2.5 para proporcionar y garantizar:

• Portal o Contenido institucional o Comunidades o Foros o Blogs o Wikis o Servicios de búsqueda o Trabajo colaborativo o Control de visitas

• WEB 2.5 o Diseño o Participación o Estándares Web o Accesibilidad o Usabilidad o Movilidad o Compatibilidad o Responsive

• Multi-Canal


La Tecnología para construir la capa de presentación (front end) para que los usuarios interactúen con la aplicación. Esta capa debe tener las siguientes características:

• Perfil público y de visitante • Búsquedas • Wiki (información para guiar al visitante) • Gestión de blog de visitas • Administración de contenido

El portal debe contener 3 capas funcionales:

• Presentación: Esta es la capa que interactúa directamente con el usuario. • Capa de Servicio de Portal: Esta capa interactúa con la capa de acceso a la

información y pasa la información de vuelta a la presentación. Básicamente, este nivel accede como capa de servicio para luego cumplir con las necesidades del usuario.

• Capa de acceso a la información: Esta capa comunica directamente con las bases de datos y obtiene la información relevante necesaria para la capa del servicio anterior.

El servidor del portal se ejecuta sobre el servidor de la aplicación, SharePoint portal es la tecnología que adoptada por la Superintendencia Nacional de Salud.

5.2.3 Framework De Desarrollo – Alm (Application Life Cicle Management).

Como Framework de desarrollo se propone seleccionar una herramienta que permita aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero, pero sobre todo, herramientas que asistan completamente el ciclo de vida del Software desde los requerimientos hasta las pruebas. Dicho framework o frameworks seleccionados para hacer parte del proyecto deben proveer:

• Generar la capa de persistencia hacia la base de datos • Diseño y prototipo independientes de la plataforma • Vuelta atrás en los cambios • Capacidad de desarrollo extensible • Gestión del ciclo de vida de los requerimientos • Administración de la configuración • Pruebas de software • Pruebas funcionales • Pruebas de desempeño


5.2.4 ALM - TFS Para las nuevas aplicaciones se debe manejar un ALM (Application Life Cycle Management). Por tanto, la entidad debe tener acceso al estado del proyecto en todo momento, como dueño de las soluciones, para poder participar en el ciclo de vida, contando con métricas de avance en cualquier momento.

Los componentes de software y documentación de los nuevos desarrollos se registrarán en la herramienta ALM Team Foundation que asista completamente el ciclo de vida del software desde los requerimientos hasta las pruebas. Una herramienta que permita:

• Vuelta atrás en los cambios.

• Capacidad de desarrollo extensible.

• Gestión del ciclo de vida de los requerimientos.

• Administración de la configuración.

• Pruebas de software

• Pruebas funcionales

• Pruebas de desempeño

Grafica de referencia herramienta de ALM


5.2.5 Administración de la configuración En este aspecto la Oficina de Tecnologías de la Información de la Superintendencia Nacional de Salud realizará un trabajo que permita establecer un inventario de elementos de configuración, acompañado de lineamientos y directrices que establezcan claramente el control y su alcance, versionamiento, control de acceso y trazabilidad. La plataforma elegida por la Superintendencia Nacional de Salud para administrar los elementos de configuración es Microsoft Team Foundation System.

Para las aplicaciones se deberá acompañar en la definición y entrega de los componentes administrables de la solución para los ambientes de certificación, pruebas y producción. La Superintendencia Nacional de Salud deberá disponer de personal para administrar, mantener y soportar esta plataforma.

5.3 Capa de aplicaciones y lógica de negocio

5.3.1 Componente de negocio Estos son componentes que facilitan el manejo transaccional de concurrencia, seguridad, entre otros a partir de contendores de lógica de negocio. Estos componentes están diseñados para un alto desempeño de aplicaciones empresariales como framework que se consolide articule este componente.

5.3.2 Servidor de Aplicación

Los componentes del software de la aplicación web deben desplegarse en el servidor de aplicación. Los componentes deben construirse de forma genérica para que puedan ejecutarse en cualquier servidor, ej.: Los componentes deben ser portátiles. El servidor de la aplicación proporciona el contenedor web donde se ejecuta la aplicación con soporte de portales. Por lo tanto, la aplicación se debe ejecutar en cualquier servidor de aplicación que tenga un contenedor web.

. El servidor de la aplicación soporta la aplicación web con características adicionales para concurrencia, balance de carga, agrupación de conexiones, escalabilidad.

Las soluciones de aplicación deberán desplegarse en Microsoft IIS adoptado por la Superintendencia Nacional de Salud.

5.3.3 Patrón de Localización Este patrón de diseño debe implementarse en los servicios de las nuevas aplicaciones y debe conservarse dentro de la arquitectura de la aplicación para que sus componentes interactúen con componentes de servicio, como componentes lógicos de negocio y potencialmente mensajería que proporcionan servicios de negocio y capacidades de persistencia permite interactuar con estos componentes, a través de un servicio de


localización de componentes de servicio (referido como una operación de búsqueda) o crear un nuevo componente.

Este mecanismo seguirá siendo de ayuda a mejorar el desempeño de la aplicación.

5.3.4 Servicios de Negocio En cuanto a la interoperabilidad de los servicios de negocio que ha implementado las nuevas aplicaciones se debe conservar el seguir dando cumplimiento a los lineamientos del Ministerio de Tecnologías de la Información y las comunicaciones, a través del Programa Gobierno en línea, el cual expone que: La Plataforma de Interoperabilidad – PDI (Es el conjunto de herramientas necesarias que permite que los sistemas de información del Estado conversen entre sí mediante interfaces estándar de Comunicación entre procesos y sistemas de información) debe estar en un Lenguaje común para el intercambio de información entre aplicaciones (GEL XML) y varias Políticas de Interoperabilidad (GEL-POINT). (MinTIC Colombia)

5.3.5 Manejo de Caché Los componentes de cachés y constantes permiten definir caches distribuidos en memoria, soportando de esta forma ambientes de alta disponibilidad, con requerimientos de alto de desempeño.

Esta herramienta permite escalar previsiblemente aplicaciones de misión crítica, proporcionando acceso rápido a los datos utilizados con frecuencia. Los volúmenes de datos y expectativas del cliente, cada vez van en aumento, por lo que permite dar soporte a más datos en tiempo real, más datos compartidos y garantía de disponibilidad.

Por lo anterior los diseños de soluciones deben contar con el manejo de de cache en tiempo real para proporcionar información siempre exacta de la aplicación.

5.3.6 Componentes de Acceso a Datos Estos componentes de acceso a datos que se van a implementar en las nuevas aplicaciones ofrecen diferentes funcionalidades para acceder a los datos utilizados dentro de los componentes de la lógica de negocios.

5.3.7 Componente de Automatización de los Procesos de Negocios (BPM)

Esta capa se enfoca en gestionar y optimizar de forma continua, las actividades y procesos de negocios de la organización, incluyendo prácticas y políticas de gestión, métricas y procesos de control, al igual que herramientas que soporten estas actividades.

Esta capa de la arquitectura proveerá un nivel administrativo de los procesos de negocio que estarán alineados con los objetivos de negocio de la SNS y que estarán contenidos dentro del alcance de los módulos entregados como insumo de los proyectos.


El alcance en esta fase inicial será el de ofrecer la forma de configurar los flujos de trabajo de una forma ágil. Un flujo de trabajo exitoso empieza con una tarea, se pasan a los actores todos los ítems de acción asociados relevantes, los actores toman las acciones apropiadas en las tareas que reciben en su Bandeja de entrada (Inbox). La tarea se transfiere a diferentes estados y finalmente, una vez que todas las aprobaciones estén listas (acciones que deben realizarse en esas tareas) se completa la tarea. Por lo tanto, la solución de automatización de procesos debe soportar el ciclo de vida completo del flujo de trabajo.

El Componente de BPM deberá garantizar una interacción y orquestación con las aplicaciones ya implementadas y por implementar.

Esta herramienta debe cumplir con los estándares de WfMC (Estándares para la interoperabilidad de sistemas de gestión de flujos de trabajo) y de los BPMS (Business process management System).

Contar con esta herramienta permite que las nuevas implementaciones sean mucho más rápidas, reduce tiempos de desarrollo de nuevas funcionalidades ya que basta con el modelamiento de los nuevos procesos reduciendo tiempo de implementación. Por tanto, los costos de modificación y mejoramiento continuo son más asistidos, proveyendo herramientas para lograr una agilidad en implementaciones.

Esta herramienta ofrecerá la funcionalidad de modelado para los analistas de negocio, herramientas de desarrollador para la integración de sistemas, supervisión de la actividad empresarial para los paneles de controles e interacción del usuario para aquellos que participan en los procesos. En resumen, esta suite permite:

- Modelado de procesos, crear flujos de trabajo. - Optimización de diseño de procesos antes de implementación. - Supervisión de eventos de procesos y otras aplicaciones externas. - Monitoreo y mejoramiento de procesos. - Administración de motor de reglas - Generación de reportes estadísticos sobre la gestión de los procesos

De acuerdo con loa anterior se ha definido que la SNS hará uso de esta tecnología para la administración de los procesos de negocio y por ende la implementación de nuevas soluciones que impliquen gestión de procesos harán uso de ésta tecnología.

5.3.7.1 Reglas de Negocio

Para las nuevas aplicaciones se va a contar con un motor de reglas de negocio, esto hace que la implementación de nuevas reglas de negocio o modificación de la lógica de negocio sea una tarea manejable y mucho menos dispendiosa debido a que actualmente se requiere nuevos desarrollos, tarea que no es fácil para los equipos implementadores involucrados. Las reglas de negocio actualmente están incluidas en los programas fuente lo que implica que ante cualquier modificación se requiere la manipulación de código y tareas de despliegue lo que genera demoras en implementaciones.


Un motor de reglas de negocio, permite que un usuario final pueda cambiar las reglas de negocio sin necesidad de un programador, tarea que resulta eficiente a la hora de modificaciones y nuevas implementaciones fruto del cambio de la lógica de negocio.

Por lo anterior, las nuevas aplicaciones tendrán un Motor de Reglas de Negocio, para lo cual Microsoft en su BizTalk Server, provee la herramienta Microsoft Business Rules (última versión disponible 2016). Esta herramienta permite a los analistas de negocio definir, actualizar y administrar fácilmente las decisiones y políticas clave que rigen los procesos de negocio. Por tanto, el motor de reglas de negocio permitirá incrementar el control y el conocimiento de la organización.

5.3.7.2 Gestor Procesos y Flujos de Trabajo

Herramientas tecnológicas para garantizar un adecuado nivel de automatización de procesos de manera ágil y gobernable. En este grupo de componentes se deben integrar:

• Modelamiento e implementación de flujos de trabajo

• Integración de formularios con Sistemas de Información transaccionales vía web services

• Centro de trabajo de actividades por atender por gestor

• Notificaciones, escalamientos y manejo de alertas sobre acuerdos de niveles de servicio

La plataforma de BPM proveerá un robusto motor de workflow, con el cual la Superintendencia Nacional de Salud podrá implementar los flujos de trabajo requeridos para las aplicaciones. A través de componentes de integración, la arquitectura permite que otras aplicaciones puedan hacer uso de los servicios expuestos para el manejo de eventos de gestión tales como la creación de solicitudes, el registro de actuaciones, el cierre de solicitudes a partir del cumplimiento de reglas de negocio, los cuales podrán ser consumidos a través del bus de servicios empresariales Microsoft Biztalk.

5.3.7.3 Centro de trabajo/gestión - bandeja de entrada La plataforma de BPM y más específicamente la bandeja de entrada asociada permitirán implementar un concepto de centro de trabajo denominado “modelo genérico de gestión”, que consiste en un conjunto de funcionalidades que le permiten a un usuario visualizar y realizar acciones sobre las solicitudes que tiene asignadas. Una vez el usuario ha sido debidamente autenticado, el sistema le presenta la ejecución de una acción denominada genéricamente “Mis asignados”. Gráficamente se presenta un tablero de control que le muestra al usuario el número de solicitudes que están asignadas, agrupadas por tipo de solicitud y señalando cuántas se encuentran a tiempo (verde), próximas al vencimiento


(amarillo) y vencida (rojo), en función del plazo que se haya establecido en la tipificación de las solicitudes. El usuario puede identificar qué solicitudes no ha revisado (no leídas), ingresar al detalle de las solicitudes que cumplen un criterio determinado (por ejemplo, próximas a vencer para un determinado tipo de solicitud) y llegar a una solicitud específica. Sobre la misma podrá realizar acciones relacionadas con la gestión tales como registrar una actuación y cambiar un estado, diligenciar un formato o plantilla predeterminada, finalizar la gestión, adjuntar documentos, ver el expediente documental y consultar la trazabilidad de la gestión. Para efectos de conectar esta propiedad con la estrategia de Portalización, es necesario embeber esta funcionalidad para exponerla a través de Microsoft SharePoint.

5.3.7.4 Centro de Control Este permite a un usuario autorizado ver las operaciones (que le sean permitidas ver) con base en sus permisos de usuario, principalmente las operaciones de la Superintendencia Nacional de Salud. Se comportará como una especie de tablero de control en donde las personas podrán encontrar las alertas enviadas desde los diferentes módulos.

5.3.7.5 Centro de Tareas Gestiona las diferentes tareas dentro de la Superintendencia Nacional de Salud. Este esquema se encarga de orquestar el proceso de tal forma que le lleguen las tareas indicadas a las personas correspondientes.

5.4 Capa media (Middleware)

5.4.1 Integración La arquitectura de las nuevas aplicaciones debe ser una arquitectura orientada a servicios lo que amerita que se lleve los servicios de integración sean implementados en el Bus de Servicios empresariales, que permita la integración entre servicios, y las aplicaciones que interactúan con las nuevas aplicaciones.

El bus de servicios empresariales es un estándar, es mucho más robusto, y permite tener un mayor nivel de seguridad en la mediación de los Webservices, por consiguiente, se tiene una aplicación menos vulnerable. Por otro lado, el bus de servicios incluye conectores y adaptadores para casi todas las tecnologías de software base, lo que permite una integración de todos los componentes de la arquitectura.

Teniendo en cuenta lo anterior y la tecnología Microsoft BizTalk adquirida, la entidad debe realizar las implementaciones de los servicios de integración en este bus empresarial considerando la implementación de la última versión estable de la herramienta Microsoft Enterprise Services Bus (ESB) que permite la integración entre servicios, aplicaciones


tradicionales, aplicaciones empaquetadas y múltiples instancias a través de una red de servicios.

De igual forma, esta herramienta brinda capacidades para la virtualización de servicios, WebServices Security (WS-Security) y el cumplimiento de policitas entorno a la regulación y la agrupación de servicios a fin de cumplir con los requerimientos de confiabilidad, disponibilidad y desempeño, evitando así la sobrecarga de servicios Back-End. Microsoft BizTalk soporta integralmente SOA, WS-Reliable Messaging y WS-Security.

5.4.1.1 Bus empresarial de servicios

El bus de servicios hace referencia a una de las herramientas adquiridas por la entidad tecnológicas para garantizar la interoperabilidad e Integración de los sistemas de información internos y externos. En este grupo de componentes integra:

• Catálogo de servicios (Web Services) o Servicios propios. o Servicio para comunicación con terceros. o Webservice interacción con aplicaciones actuales y futuras

• Reglas de ruteo (orquestación) y transformación de servicios / mensajería

• Manejo sincrónico y asincrónico de transacciones

• Administrar reglas de excepción

• Optimizar desempeño de la interoperabilidad

• Manejo de errores y encolamiento de servicios.

Así mismo, el ESB proporciona las capacidades de buscar los servicios durante la ejecución. Incluso si dos servicios deben comunicarse, uno utilizando XML y el otro formato de datos, el ESB puede hacer la conversión del mensaje para permitir la comunicación. Funcionalidades principales:

• Administración de reglas de excepción.

• Optimización de desempeño de la interoperabilidad.

• Manejo de errores y encolamiento de servicios.

• Automatización de procesos.

• Integración de aplicaciones empresariales.

• Arquitectura orientada a servicios.

• Conectividad entre diferentes fuentes de información sin importar la estructura y tecnología.

• Implementación de capa de integración simple, escalable.


• Mensajería

• Intercambio de Archivos de manera segura (FTP)

• WebServices

• Adapters

• Catálogo de servicios. o Protocolo o Descripción o Seguridad o Estandarización

Administración y Monitoreo

- El monitoreo de Transacciones (Microsoft Biztalk) Se deberá utilizar esta herramienta que monitorea la ejecución de las actividades y los procesos de negocio y a partir de este define indicadores (KPIs), reportes y consultas, que muestran el desempeño del negocio en tiempo real. Mediante Microsoft BAM se podrá definir Key Performance Indicators (KPIs) y de esta forma determinar si las metas de desempeño de cada proceso o actividad se han cumplido.

- Monitoreo de Servicios (Microsoft Webservices Manager) Este componente permite monitorear los acuerdos de niveles de servicios SLAs (Services Level Agreements) a nivel de aplicaciones. La información sobre la ejecución de los servicios es generada por la capa de mediación, por el Microsoft Webservices Manager y es almacenada para futura consulta.

- Monitoreo de transacciones Para el monitoreo de transacciones en las nuevas aplicaciones se cuenta con Microsoft System Center para hacer un seguimiento de la operación de la aplicación, para informar sobre las métricas de negocio incrustadas en el contenido de transacciones y la gestión de errores de transacción. La implementación de esta herramienta es justificable ya que las nuevas aplicaciones es una aplicación que a nivel de transacciones va en crecimiento, por lo que debe estar apoyada por una herramienta que permita hacer monitoreo de transacciones de aplicaciones de alta capacidad y complejidad.

5.4.1.2 Catálogo de Servicios Se debe disponer de un catálogo de servicios que permita el registro de los servicios desplegados en el bus, a fin de disponer de la administración de los mismos, así como el control para posibles reúsos.


5.4.1.2.1 Sistemas y Servicios de Negocio Este conjunto de servicios representa para la entidad todos los sistemas back-end con los que la aplicación necesita interactuar. Principalmente, esto incluye que haya comunicación entre sistemas dispares para procesamiento y para los datos requeridos.

5.4.1.2.2 Servicios de Bajo Nivel Estos son servicios de granularidad más fina que interactúan con los sistemas de negocio para obtener detalles relevantes.

5.4.1.2.3 Servicios Compuestos Este conjunto de servicios contiene granularidad gruesa que están compuestos por dos o más componentes individuales. Estos servicios pueden llamarse a través de la capa de procesamiento que se encuentra sobre ésta.

5.4.1.2.4 Servicios de Procesos de Negocio Estos servicios tienen la capacidad de orquestación de procesos de negocio. Los servicios de granularidad fina y gruesa se orquestan juntos para alcanzar una funcionalidad de proceso de negocios.

5.4.1.3 Servicios Web para SOA Los servicios web deben disponer de tecnologías basadas en HTTP, XML, SOAP, REST y JSON que permitan gestionar la mensajería entre los diferentes componentes que la requieran. El diseño de los servicios de interoperabilidad debe permitir estandarización, tener bajo acoplamiento, ser reutilizables, presentar autonomía, soportar composición de servicios y disponer de contratos de servicios y su documentación relacionada conforme a la buena práctica sugerida por SOA.

5.4.2 Servidor de aplicaciones Las aplicaciones deberán desplegarse en el servidor de aplicaciones Microsoft Internet Information Services (IIS), que actualmente tiene la entidad, en su versión más reciente que da lugar a mejoras en términos de seguridad y rendimiento. Teniendo en cuenta que éste es el componente más importante de la capa middleware sobre el cual se basan los demás componentes, se requiere que se mantenga una versión siempre vigente y actualizada de la tecnología base, para que pueda soportar y evolucionar los desarrollos de la aplicación en nuevos componentes que permitan mejorar el rendimiento de las nuevas aplicaciones, las cuales son aplicaciones con altas proyecciones de transaccionalidad, que amerita contar con el soporte de las últimas tendencias tecnológicas.

5.5 Capa de Persistencia de Datos

5.5.1 Clúster de base de datos Actualmente el componente Microsoft Allways On que se encuentra en las nuevas versiones permite la implementación de bases de datos en clúster para alta disponibilidad,


rendimiento y agilidad. Permite ejecutar de manera eficiente cualquier aplicación empaquetada o personalizada.

Algunos de los beneficios de contar con esta herramienta actualizada son:

- Ejecuta todas las cargas de trabajo de la base de datos. - La más alta disponibilidad de la base de datos. - Administración flexible de cargas de trabajo.

Las nuevas soluciones de tipo crítico o misional deben disponer de un esquema de cluster para la capa de datos.

5.5.2 Base de datos Las nuevas aplicaciones deben soportar una base de datos relacional Microsoft SQL Server que permita alta transaccionalidad, cuenta con herramientas y tecnologías actualizadas que soportan el crecimiento y dan lugar a una constante evolución que evite el rezago tecnológico. Esta herramienta cuenta con más de 500 funciones nuevas, proporcionando utilidades para soportar computación en la nube, Big Data, seguridad y alta disponibilidad.

Microsoft SQL Server, presenta una nueva arquitectura multiusuario que simplifica el proceso de consolidación de las bases de datos sobre la nube; permitiendo a los clientes administrar muchas bases de datos como una, sin cambiar sus aplicaciones.

Esta nueva versión de Microsoft, permitirá reducir costos de la gestión de las bases de datos. Aumentará el rendimiento de las bases de datos, tiene características para mejorar el rendimiento, automatizar la administración y proporcionar flexibilidad en opciones de implementación. También incluye mejoras en aspectos importantes como seguridad, alta disponibilidad, escalabilidad y rendimiento.

Actualmente dentro de esta capa de datos se encuentran diferentes repositorios y sistemas de archivos de la arquitectura, que se deben seguir manejando.

Dentro de esta capa de datos se deben seguir manejando los diferentes repositorios y sistemas de archivos de la arquitectura, los cuales se enumeran a continuación para los cuales, la renovación tecnológica supondrá las mismas implicaciones.

5.5.3 Transaccional Las nuevas aplicaciones requieren del componente OLTP (OnLine Transaction Processing) en la Base de datos.

5.5.4 Analítica Las nuevas aplicaciones requieren un componente analítico OLAP (OnLine Analítica Processing) esta información es la base para realizar el análisis de datos que se realiza dentro de las nuevas aplicaciones, por lo general es información derivada de agregaciones de datos, y almacenada en un esquema de datos multidimensional. Aquí se encuentran estadísticas de operación del negocio, que generalmente se utiliza para soportar la toma de


decisiones estratégicas a la operación de la concesión o para la toma de decisiones del sector por parte de la entidad.

5.5.4.1 Herramientas de BI Capa que soporta el análisis del negocio para la toma de decisiones empresariales. Esta información debe utilizarse para generar reportes y análisis del negocio. Se debe recolectar la tendencia de los datos de negocio y se debe analizar para entender los futuros cambios del negocio.

Se entiende que la capa está dentro de una arquitectura de referencia que es deseable tenerla, en un proyecto de BI se incluye el crear, diseñar, poblar y explotar la bodega de datos.

Para los reportes de carácter analítico se debe utilizar el componente de BI dispuesto por la entidad.

La Herramienta tecnológica para consolidar la información estratégica y ofrecer servicios de consulta analítica permite interpretar comportamiento de los procesos de negocio y del entorno, para asistir la toma de decisiones. En este grupo de componentes se deben integrar:

• Definición de Data Marts (Bancos de Información a analizar)

• Definición de reglas de extracción, transformación y cargue (ETL)

• Definición de cubos analíticos

• Configurar consultas analíticas

• Llevar registro histórico de variables de análisis

• Permitir consultas detalladas (Drill Down)

A continuación, se presenta una vista lógica de los componentes involucrados en una implementación de BI:


MIcroStrategy es la solución que adoptó la Superintendencia Nacional de Salud para BI, sin embargo para información de las transacciones se utilizaran los servicios de Reporting Services de Microsoft.

5.5.5 Auditoria Las nuevas aplicaciones requieren componentes de Auditoria en la base de datos que almacena información de auditoria del sistema. Información relacionada con el historial de transacciones, modificaciones y consulta de datos. Esta información de auditoría es recolectada y administrada por medio de Microsoft SQL Server.

Por lo que se debe contar con un componente de versión actualizada, que administre es el repositorio central, altamente escalable y seguro, que almacene los datos de auditoría consolidados, así como los registros de eventos generados por el servidor de seguridad de base de datos. Además, debe ser la plataforma central para la presentación de informes, alertas y gestión de políticas.

5.5.6 Repositorio de Gestión Documental Componente de gestión de contenido empresarial (ECM Enterprise Content Management) encargado de administrar las imágenes y o archivos de los documentos asociados con la operación. Sera un componente transversal desde el Gestor documental a los módulos funcionales de las aplicaciones y deberá garantizar que la documentación este organizada y ligada a cada una de las actividades pertenecientes a cada uno de los procesos de la organización, de acuerdo con la tabla de retención documental establecida en la entidad.

En la entidad actualmente, se hace uso de Microsoft Share Point ECM como repositorio. Manuales

Centraliza y gestiona la base de conocimiento del sistema en aspectos de ayudas contextuales, Wikis y Material de capacitaciones (entrenamiento virtual) relacionados con el sistema. En la superintendencia se ha definido adoptar el uso de la herramienta Moodle, de tal forma que en este esquema se creen todos los contenidos visuales y dinámicos necesarios para las jornadas de capacitación de usuarios, autoaprendizaje y ayudas para la gestión del conocimiento en pro del uso y apropiación de los nuevos sistemas de información. De ésta forma reducir el uso de papel, documentos que pierden validez con las actualizaciones de las aplicaciones y el manejo y costo administrativo de manejar medios físicos.

5.5.7 Generación de Reportes e Indicadores de Gestión Centraliza la generación dinámica de nuevos reportes, indicadores e informes correspondientes, de toda la información del sistema. Garantiza la generación de los documentos operativos basados en plantillas editables por usuarios comunes no necesariamente con conocimientos avanzados de TI y la consulta de Indicadores y reportes básicos.


5.6 Capa de Sistemas operativos y máquinas virtuales

Los sistemas operativos y máquinas virtuales son herramientas tecnológicas para garantizar una optimización y flexibilidad en la administración de la infraestructura de servidores. En este grupo de componentes se deben integrar:

• Administración dinámica de ambientes de sistemas operativos

• Monitoreo al desempeño y capacidad de los equipos y configuración de las máquinas

Esta capa esta soportada por sistemas operativos Microsoft Windows Server en sus últimas versiones.

Considerando el alto costo de los componentes, la virtualización puede traer efectividad en los costos. La virtualización puede reducir los costos en instalaciones, energía, enfriamiento y hardware. Puede simplificar la administración y mantenimiento y promete un perfil TI más verde.

La virtualización permite ejecutar múltiples máquinas virtuales en una física y compartir los recursos de ese computador físico en varios ambientes. Se pueden ejecutar diferentes máquinas virtuales (VM) en diferentes sistemas operativos y varias aplicaciones en un mismo computador físico. El propósito de la virtualización, como componente intermedio y como estrategia del sistema integrado de información, es permitir una administración flexible de la infraestructura y mejorar la rentabilidad de su adquisición.

Microsoft Hyper-V es el componente de máquina virtual de Microsoft que adoptó la Superintendencia Nacional de Salud.

5.7 Capa de Infraestructura

En concordancia con la Normatividad Vigente en lo referente a contratación estatal, la Infraestructura a partir del 2015 es vista como un servicio proporcionado por un proveedor bajo un modelo de entrega de servicios de procesamiento, almacenamiento y aplicaciones. La infraestructura donde se concentran todos los recursos técnicos y humanos necesarios para el procesamiento, almacenamiento y publicación de la información se encuentra en un centro de datos. Los servicios se encuentran clasificados en varias categorías como son: IaaS para procesamiento, IaaS para almacenamiento, IaaS para Seguridad, Servicios Complementarios, PaaS.

6 VISTA DESPLIEGUE DE SERVICIOS


Este diagrama pretende mostrar los servicios involucrados en el entorno de TI de la entidad que estarán involucrados durante el desarrollo, lo importante por mencionar en este diagrama es que se deberá catalogar tantos los servicios simples en donde el bus se comportará como un proxy tanto como los servicios compuestos en donde se clasificarán por:

• Los servicios encadenados: Servicios compuestos por llamados a otros servicios en forma secuencial.

• Los servicios compuestos: Servicios que invocarán otras mediaciones o integraciones previamente desplegadas en el bus.

• Los servicios agregados: Servicios que realizarán invocaciones anidadas o con algún nivel de agrupación, es decir que dentro de su mediación se tengan que crear llamados dentro de un ciclo finito.

Las principales agrupaciones que podemos encontrar en el desarrollo son:

• Servicios de Interoperabilidad de las Aplicaciones: Serán todos aquellos servicios que por la capa de integración deberán estar expuestos para proveerle funcionalidad a algún sistema externo y que si y solo si sean operaciones que por cohesión, las pueda procesar o exponer el alcance funcional que tendrán las aplicaciones.

• Servicios propios de procesos: Son los servicios que la capa de procesos expondrá para el manejo de los flujos de trabajo. En este punto vale la pena aclarar que el término servicio no está enmarcado en el concepto técnico WebService sino que tiene un marco mucho más grande que incluye técnicamente las siguientes posibilidades (Stored Procedure, API, WebService REST, HTTP , EJBs, Entre otros).


• Servicios propios gestor documental: Son todos aquellos servicios que la herramienta de gestor documental exponga para cumplir con el concepto de gestor documental.

• Servicios existentes: Se detectó que en la actualidad existen servicios expuestos por las aplicaciones legadas como RVCC, SGT-TMS y consumidos por aplicaciones externas, la inclusión del nuevo sistema debe contemplar el causar el menor impacto posible a los entes externos.

• Servicios de integración: Son todos los servicios que deben ser expuestos en el bus para cumplir con los requerimientos detectados de interoperabilidad.

La arquitectura de referencia está soportada por los siguientes pilares tecnológicos:

• Una gran capa como base compuesta por Data Center, Sistemas operativos y Virtualización y las capas de Bases de datos y de persistencia.

• Sobre la anterior capa se encuentra una capa en la cual estarán los componentes de aplicación y el bus de servicios empresariales que se encargara de la integración de los componentes de la arquitectura.

• Apoyado en la anterior, se consideró una capa de procesos de negocio y BI, así como el servidor de aplicaciones encargado del despliegue de los componentes de aplicación, una capa de seguridad y la capa expuesta al cliente soportada con un portal.

7 MODELO DE GOBIERNO DE LA ARQUITECTURA DE REFERENCIA PARA LOS

COMPONENTES DE SOFTWARE BASE DE LAS APLICACIONES EN LA OTI

El propósito del modelo de gobierno, es presentar un modelo que oriente las decisiones arquitectónicas de cómo articular los componentes de software base de los proyectos de nuevas aplicaciones en la OTI de la SuperSalud.

7.1 Proceso de gobierno de la arquitectura de referencia de software Para garantizar la adopción de la arquitectura de referencia de software se debe establecer el siguiente proceso


7.2 Definición y Mantenimiento de la Arquitectura de Referencia de Software

7.2.1 Elaborar líneas base de la ARS La elaboración de la ARS es una actividad de mucha responsabilidad, pues va a regir sobre las inversiones en aplicaciones sobre las cuales se manejará la operación de la entidad, por este motivo debe existir una persona encargada de la redacción de este documento, el cual debe validar y velar por la claridad, coherencia y consistencia del mismo.

7.3 Despliegue de la Arquitectura de referencia

7.3.1 Socializar líneas base de la ARS en el equipo de la OTI

Cada vez que se elabore una nueva versión de la línea base de la ARS, se debe socializar con los coordinadores de grupo de la Oficina de Tecnologías de la Información y someter a una retroalimentación a la misma donde cada coordinador la socialice con sus integrantes de grupo.

7.3.2 Ajustes y aprobación de nuevas líneas base

La ARS debe estar en permanente evolución y perfeccionamiento, pues debe estar acorde a las innovaciones del mercado y más específicamente de las nuevas versiones de los productos de software base, los cuales traen nuevas características para construir sobre ellas soluciones más acordes a las tendencias de usabilidad y construcción de software.

•Elaborar lineas base de la ARS

•Estudios de referentes y conveniencia de adopción

Definición y Mantenimiento de la

Arquitectura de Refreencia

•Socializar lineas base de la ARS en el equipo de la OTI

•Ajustes y aprobación de nuevas lineas base

Despliegue de la Arquitectura de

referecia

•Recepción de solicitudes de revisión arquitectónica de nuevos proyectos de aplicaciones

•Emitir conceptos y sugerencias de modelos arquitectonicos convenientes

Gestionar solicitudes de cambios o

personalizaciones

•Planear y programar revsiones de cumplimiento a nuevos proyectos

•Efectuar revisiones de cumplimiento

•Manejo de no conformidades

Revisión de cumplimiento


Por lo cual se considera línea base cada versión aprobada, que debe estar monitoreado a través de las experiencias y estados del arte aplicables al contexto de la SuperSalud y ésta será sustituida por una nueva cuando sea propuesta por la Gestión de Arquitectura y aprobada por las coordinaciones de la OTI y el Jefe de la Oficina de Tecnologías de la información.

7.4 Gestionar solicitudes de cambios o personalizaciones a la ARS

7.4.1 Recepción de solicitudes de revisión arquitectónica de nuevos proyectos de aplicaciones

Cada vez que se dé inicio a un proyecto de nuevas aplicaciones, es necesario velar que la misma cumpla con la ARS, de otra manera habrá que efectuar un estudio de impacto y conveniencia de variaciones que presentar la solicitud de cambio al comité de gobierno de la ARS para poder justificar el no cumplimiento parcial.

Por este motivo el gestor de los proyectos de arquitectura debe efectuar un análisis pormenorizado de asuntos en pro y contra de la arquitectura de la nueva aplicación y el impacto de tendrá para garantizar convivencia de la misma con las otras aplicaciones.

7.4.2 Emitir conceptos y sugerencias de modelos arquitectónicos convenientes Los resultados de los análisis de conveniencia e impacto realizados por el responsable que la Coordinación del grupo de Arquitectura, deben documentarse y sustentarse al comité de gobierno de la ARS para poder comunicar las razones de aprobación o negación de la solicitud y junto con ellos llegar a un consenso que dará una decisión y una respuesta al solicitante de la solicitud de cambio

7.5 Revisión de cumplimiento

7.5.1 Planear y programar revisiones de cumplimiento a nuevos proyectos El grupo de arquitectura programará sesiones de revisión de cumplimiento a los lineamientos de la ARS de cada proyecto con una periodicidad mensual y deberá apoyar el cumplimiento en cada componente arquitectónico en cada proyecto.

7.5.2 Efectuar revisiones de cumplimiento Una vez se efectúe la revisión de cumplimiento arquitectónico se debe elaborar un informe de la revisión con los hallazgos del caso y las recomendaciones que se estimen pertinentes. De tal forma que sean entregadas al jefe la Oficina de Tecnologías de la Información para la toma de decisiones pertinentes.

7.5.3 Manejo de no conformidades En el evento que se detecte una no conformidad en un proyecto, se debe acordar un plan de acciones correctivas con el implementador de la solución para dar cumplimiento a cabalidad a los lineamientos definidos y de acuerdo a los resultados esperados del plan, se procederá a notificar al supervisor del contrato las conformidades para que aplique las sanciones de acuerdo de nivel de servicio que corresponda.


7.6 PRINCIPIOS PARA EL GOBIERNO DE LA ARQUITECTURA DE REFERENCIA DE SOFTWARE

7.6.1 Estandarización La ARS propende por la estandarización de componentes de software base para que en el futuro la mayoría de las aplicaciones utilicen los mismos componentes y de esta manera unificar los esquemas de licenciamiento y mantenimiento de las aplicaciones.

En caso que una nueva solución que se quiera implementar, que ya este desarrollada y que no cumpla con este principio, el comité de gobierno de la ARS debe evaluar la conveniencia de aceptar esa no conformidad, siempre y cuando haya criterios de peso que lo justifiquen, como, algunos de éstos criterios pueden ser:

• Cumplimiento de requerimientos funcionales

• Valor competitivo de la inversión

• Razonabilidad de los Costos de Sostenibilidad (operación, mantenimiento y actualización de licencias)

• Fecha de salida en vivo y estabilización versus un desarrollo a la medida

• Facilidad de mejora, evolución y

• Vida útil de la inversión, evaluar que los productos no utilicen componentes que estén por salir del mercado o que no tenga el respaldo del fabricante

• Esfuerzo de implementación

• Esquema de servicio post - implementación

• Proceso de contratación (Tiempo y complejidad)

• Alineamiento y tecnología estándar

• Madurez de la solución en el mercado de implementaciones exitosas en el sector

7.6.2 Reutilización La ARS debe ser comprendida por los implementadores de soluciones para que se reutilicen componentes de software existentes en la Entidad y no se sigan efectuando desarrollos alternos que cumplen el mismo propósito de los componentes de software referenciados

7.6.3 Desempeño La ARS debe garantizar que los tiempos de respuesta y el manejo de los picos de carga suplan la demanda de servicios tanto de transaccionalidad como de consulta de los usuarios de la solución.

Los componentes de software que formen parte una aplicación de negocio deben integrarse a la plataforma de software base de la entidad, con el fin que en conjunto puedan brindar tiempos de respuesta acordes con las necesidades del negocio en cuanto al acceso a la aplicación, despliegue de formularios, generación de consultas, procesamiento de funciones especiales y generación de informes, tiempos que serán definidos como parte de los requerimientos no funcionales de cada solución de software.


7.6.4 Gestión del Conocimiento Cada vez que se implemente una nueva aplicación, debe velarse que el responsable del proyecto gestione la transferencia del conocimiento entre el implementador y el equipo de aplicaciones de la OTI.

Esa transferencia de conocimiento, no solo consiste en un entrenamiento de cómo se incorporaron los componentes del software base a la aplicación, sino de talleres técnicos de cómo sacarles mejor provecho a los mismos y validar que el equipo base del grupo de aplicaciones desarrolló las competencias para poder asistir la mejora continua durante el ciclo de vida de la aplicación y la integración de la misma con las demás aplicaciones satélites, es decir, las que están alrededor de la aplicación.

7.6.5 Código fuente En la medida que sea viable comercial y financieramente se debe buscar que de las nuevas aplicaciones que se implementen por modalidad de desarrollo a la medida, se negocie la entrega del código fuente para poder tener oportunidad de evolucionar las aplicaciones por el equipo base del grupo de aplicaciones. En especial aquellas aplicaciones que brinden soporte a los procesos misionales de la entidad, con el fin de garantizar en mayor medida la oportunidad y no dependencia de un proveedor externo para la evolución y mejoramiento de las aplicaciones de negocio.

7.6.6 Costos de inversión y tenencia Al adquirir una nueva aplicación cumpliendo con los requerimientos funcionales, pero no cumpla a totalidad con la ARS, se debe evaluar si los costos ofertados son muy competitivos (menos del 60% del costo y menos del 70% de tiempo de implementación) versus con un desarrollo a la medida. Caso en el cual, se puede optar por la adquisición de un producto ya construido, siempre y cuando se oferte un paquete de servicios de interoperabilidad que permitan integrarla con las aplicaciones relacionadas y/o componentes transversales en caso que la unidad de negocio así lo requiera.

7.6.7 Servicios Soporte Todas las implementaciones de nuevas aplicaciones deben contemplar una negociación de un esquema de soporte técnico oportuno, un apoyo arquitectónico de recomendaciones y mejores prácticas para implementar nuevas funcionalidades o ajustar las existentes.

7.6.8 Innovación La ARS, debe irse acondicionando nuevos referentes / tendencias y análisis conveniencia de adopción de nuevos componentes por dominio de la arquitectura del software, por otra parte, también hay que monitorear las experiencias y estados del arte aplicables al contexto de la SuperSalud para poderlos capitalizar.

Por este motivo, es conveniente que cada año se revise la vigencia tecnológica de la ARS, y a través de estudios de mercado, pruebas de concepto internas y lecciones aprendidas, de tal forma que si es necesario se actualice el documento de ARS en los capítulos que lo componen para poder prolongar la vida útil de las aplicaciones de la entidad.


7.6.9 Disponibilidad Los componentes de la ARS, deben dar soporte a la disponibilidad requerida de las soluciones conforme a las necesidades operativas, de cubrimiento y de impacto del negocio, cada solución de software deberá definir el nivel de disponibilidad de sus componentes. En primera medida los componentes de software que brinden soporte a aplicaciones de negocio de tipo transversal o misional de la entidad deberán ser de alta disponibilidad.

7.6.10 Escalabilidad Los componentes de la ARS, deben soportar el crecimiento de la capacidad de cómputo en lo relacionado con aumento del volumen de datos y el volumen de conexiones de usuarios concurrentes, sin el desmejoramiento del servicio, esto deberá ser analizado y definido como parte de los requerimientos no funcionales de cada solución de software.

7.6.11 Interoperabilidad Los servicios de integración o interoperabilidad deberán implementarse en el bus de servicios empresariales, considerando que todos los servicios construidos para la integración de sistemas de información deben especializar sus métodos de acuerdo a funcionalidad o proceso de negocio, además de tener en cuenta el principio de granularidad del servicio, donde se enuncia que las funciones que se van a exponer dentro de los servicios web busquen evitar intercambios innecesarios de mensajes y como regla de rendimiento, debe esforzarse por publicar servicios de granularidad gruesa de modo que se acepten todos los parámetros e información necesarios, permitiendo así el crecimiento incremental y diferencial minimizando el impacto en transiciones posteriores, implementando servicios que logren el mejor rendimiento posible entre aplicaciones. Se debe, adicionalmente propender por un diseño de servicios agnósticos y autónomos que minimicen las dependencias entre sí.

7.6.12 Plataforma La plataforma de software base adoptada por la entidad está basada en componentes Microsoft, por lo que los componentes de las capas de portalización, acceso, aplicaciones, interoperabilidad y persistencia de datos deben ser compatibles con dichos componentes.

7.6.13 Seguridad Las soluciones de software o aplicaciones internas de negocio deben integrarse con el directorio activo de la entidad para la autenticación de los diferentes usuarios. De igual forma los componentes de software base dispondrán de los mecanismos de acceso y manejo conforme a las políticas definidas por el grupo de seguridad de la OTI.

7.7 Organización humana que requiere este modelo de gobierno

7.7.1 Roles que intervienen El modelo propuesto demanda un Comité de Gobierno de la Arquitectura de referencia del software conformado por los siguientes roles:

• Jefe de la OTI

• Coordinadores de Grupo de la OTI


• Grupo representativo de los arquitectos empresariales y arquitectos de software que el Jefe de la OTI o los coordinadores vean pertinente invitar

Con la siguiente jerarquía:

7.8 Responsabilidades frente al modelo

Las responsabilidades del gobierno del modelo están a cargo de comité de arquitectura el cual estará conformado por el Jefe de la Oficina de Tecnologías de la información y los representantes de cada grupo de trabajo interno, quienes harán seguimiento, análisis y toma de decisión frente a las implementación de nuevas tecnologías ó mejoras a las mismas, así como también instanciarán a los directivos los impactos y/o aprobaciones que se requieran para la implementación de nuevos proyectos, lineamientos y/o políticas internas, ello soportado en las propuestas y argumentaciones presentadas al comité.

Este comité es la de sesionar por lo menos una vez por mes, para efectuar revisión a los resultados de los procesos de gobierno.

Este comité sesionará por demanda cuando en una contratación de una nueva aplicación se necesite aprobar un no cumplimiento justificado de la arquitectura de referencia.

7.8.1 Coordinación del grupo de arquitectura La responsabilidad de esta instancia es de:

- Elaborar y proponer ante el comité las arquitecturas de referencia de T.I. y acompañar las implementaciones de dichas arquitecturas.

Jefe de la Oficina de Tecnologías de la Información

Coordinador del Grupo de

G. de Arquitectura

Gestores de trabajos de

arquitectura

Arquitecto de aplicaciones

Coordinador Grupo deG. de Aplicaciones

Profesionales del grupo de

trabajo


Infraestructura y Soporte


trabajo


Adminsitración y Seguridad de la Infomación


trabajo


- Citar los comités de arquitectura. - Coordinar las actividades del modelo de gobierno de Arquitectura de T.I., debe

instanciar el comité para la toma de decisiones planteando las situación y análisis realizado según sea el caso.

- Es la instancia encargada de llevar las notas, actas de las decisiones del comité y el seguimiento a los compromisos que se establezcan dentro del comité.

7.8.2 Coordinación del grupo de Aplicaciones

La responsabilidad de esta instancia es de:

- Durante la elaboración del diseño arquitectónico de las nuevas soluciones, es la instancia encargada de validar y aprobar en conjunto con los demás coordinadores las condiciones y características de los diseños realizados, desde el punto de vista de su función, tanto en la etapa de diseño como de implementación.

- Recibir el producto de las adquisiciones de software y que se encargará de supervisar el desempeño de la operación y mejora continua de las aplicaciones.

- Dar su concepto aprobatorio o sugerir alternativas para enriquecer la arquitectura con las lecciones aprendidas de la operación.

7.8.3 Coordinación del grupo de Infraestructura y Soporte


- Durante la elaboración del diseño arquitectónico de las nuevas soluciones, Es la instancia encargada de validar y aprobar en conjunto con los demás coordinadores las condiciones y características de los diseños realizados, desde el punto de vista de su función, tanto en la etapa de diseño como de implementación.

- Garantizar proveer la infraestructura requerida y definida para la implementación de las nuevas soluciones, se encargará de supervisar el desempeño de la operación y mejora continua de la infraestructura después de la puesta en producción de las aplicaciones.

- Validar y revisar el cumplimiento de los requerimientos de infraestructura y comunicaciones, definidos para las nuevas soluciones durante la implementación de las mismas, de acuerdo con su función y alcance del rol que desempeña.

7.8.4 Coordinación del grupo de Administración y seguridad de la Información


- Durante la elaboración del diseño arquitectónico de las nuevas soluciones, Es la instancia encargada de validar y aprobar en conjunto con los demás coordinadores


las condiciones y características de los diseños realizados, desde el punto de vista de su función, tanto en la etapa de diseño como de implementación.

- Validar y revisar el cumplimiento de los requerimientos de seguridad definidos para las nuevas soluciones durante la implementación de las mismas y realizar las actividades pertinentes para mantener mejorar las condiciones de seguridad de la información relacionadas con las nuevas soluciones adquiridas, de acuerdo con su función y alcance del rol que desempeña.

7.9 Lineamientos a considerar en la implementación de soluciones de TI

7.9.1 Requerimientos para migración y población de datos

Por migración se entiende que la base de datos actual que soporta las aplicaciones debe migrarse a la nueva base de datos que se desarrollará para la nueva solución.

• Se necesita realizar un estudio en la aplicación actual y en el diseño de la base de datos.

• Se debe proponer y decidir el diseño de la base de datos para la nueva solución.

• Una vez que estén claros ambos ítems, se discutirá y decidirá sobre la estrategia de migración.

La estrategia de migración debe analizarse y planearse de forma apropiada para cada sistema de información que se pretenda implementar. Se deben realizar los suficientes ensayos para asegurar que todo funciona adecuadamente. A continuación, se presentan las etapas que normalmente deben ser incluidas en la migración, el objetivo del proyecto se encaminará a definirlas y acotarlas.


7.9.2 Requisitos no funcionales a tener en cuenta

7.9.2.1 Generales ➢ Un módulo para mantener actualizadas las tablas básicas del sistema. En caso que

se necesite algún cambio en las tablas básicas, este módulo debe ser capaz de actualizar los cambios.

➢ Se define que el requerimiento hace mención a manejar tablas paramétricas para que el sistema tenga un nivel de configuración que no permita tener nada quemado en el código.

➢ Auto recuperable. En caso que algún proceso masivo falle, debe tenerse un mecanismo de copia de seguridad que ayude a recuperar el proceso desde el punto de fallo.

➢ Se aclara que el alcance de este punto es que el sistema conserve una capa transaccional que evite que una caída del sistema deje inconsistente la información.

➢ Concurrencia. Los sistemas deben soportar hasta 700 usuarios concurrentes. Este aspecto se debe tener en cuenta durante el dimensionamiento de los servidores de las tecnologías y los componentes del software y durante el diseño.

➢ Escalabilidad. El sistema debe ser escalable. ➢ En este punto el alcance que se requiere es que los Frameworks escogidos tengan

soporte, sean escalables y que la arquitectura provea y facilite un crecimiento sostenible.

➢ Modularidad. El sistema debe ser modular. Manejará a través del sistema de autorización y la correcta asignación de los procesos, es decir, la modularidad será dada por el funcionamiento independiente de las aplicaciones y los Módulos y por la independencia de los diferentes procesos.

➢ Configurable. Todos los valores de los parámetros deben ser configurables de forma tal que no esté quemado en el código fuente. El alcance de este punto es que exista un nivel de configuración que permita crecer organizadamente.

➢ Debe utilizar Servicios Web como mecanismos de interoperabilidad considerando el marco SOA.

➢ Debe utilizar MVC, patrones DAO, de acuerdo con el marco SOA. ➢ La aplicación debe ser portátil en diferentes navegadores y sistemas operativos. ➢ Para este punto se requiere que el sistema tenga Frameworks que rendericen según

el estándar. Se desea enfocar en las últimas versiones de los navegadores IE y Mozilla.

➢ Debe tener accesibilidad en móviles con iOs y Android. ➢ Debe soportar arquitectura de 32 y 64 bit. ➢ Debe tener conectividad vía JDBC, ODBC, OLDB cuando sea aplicable. ➢ Debe utilizar BI y ESB. ➢ Se debe poder acceder al portal de la aplicación vía celular


➢ Una solución de arquitectura deberá soportar los tres tipos de firmas (electrónica, digital y mecánica) de acuerdo con las políticas y necesidades del negocio.

7.9.2.2 Base de Datos Las Herramientas tecnológicas para garantizar la consistencia e integridad de la información de la plataforma. En este grupo de componentes se deben integrar los sistemas de bases de datos relacionales, con su contingencia (Alta disponibilidad) tanto para la información transaccional como para la analítica que ha de ser aprovechada a nivel gerencial en labores de inteligencia empresarial (Business Intelligence).

Esta es la capa de persistencia. La cual está representada por una base de datos relacional que se encargará de contener los datos de la aplicación, ésta tendrá la capacidad de obtener la información a través de sentencias SQL, esta capa tendrá como características fundamentales una alta escalabilidad, robustez para soportar múltiples usuarios concurrentes, seguridad y manejo transaccional.

Microsoft SQL Server es el componente propuesto para la Superintendencia Nacional de Salud, pues el que se ha venido implementando para prácticamente todas las aplicaciones misionales, estratégicas y de soporte.

7.9.2.3 E-Learning

Este componente se relaciona como una capa extra en donde se implementarán en Moodle los contenidos para transferencia de conocimiento continuo, de las nuevas soluciones (manuales y E-Learning). En resumen, será la capa que contendrá todo lo relacionado con:

• Ayudas contextuales • Errores comunes y solución • Manuales interactivos • Evaluaciones • Acceso al campus virtual

7.9.2.4 Documentación y notación

Cuando la entidad realice implementaciones de nuevas soluciones de tipo: “solución mayor”, se deben considerar los siguientes documentos de proyecto y de producto, así:

DE PROYECTO:

➢ Documento Project Charter: Este documento se debe elaborar y gestionar haciendo uso del marco PMI

➢ Documento Plan de Dirección de proyecto: Este documento se debe elaborar y gestionar haciendo uso del marco PMI

➢ Documento Plan de Gestión de Asimilación del Cambio


➢ Informe periódico de seguimiento: De acuerdo con lo definido por la entidad

➢ Informe final de cierre: De acuerdo con lo definido por la entidad

DE PRODUCTO:

a) Plan de Transferencia de Conocimiento

b) Instalación del Licenciamiento (cuando se adquiera productos)

c) Especificación detallada de requerimientos funcionales y no funcionales: Instrumentos usados para el levantamiento de requerimientos funcionales y no funcionales y sus documentos soportes, cuando aplique. i. Contexto de los límites funcionales de la solución

ii. Actores (interesados y sistemas) fuentes y destino que interactúan con la solución.

iii. Casos de uso o historias de usuario, de acuerdo con el tipo de requerimiento. iv. Especificación de requerimientos funcionales: Esta sección es una descripción

en lenguaje natural de la entidad, para cada requerimiento, debe tener desagregado componentes de interoperabilidad funcional, desarrollos complementarios y lo propio de la automatización de cada proceso, apoyado en Diagramas de flujo de datos, Diagramas de clase y Diagramas de actividad en notación UML.

v. Especificación de requerimientos no funcionales: Esta sección debe desagregar i) usabilidad y accesibilidad, ii) fiabilidad y iii) seguridad e interoperabilidad técnica.

vi. Matriz de trazabilidad de requerimientos, para identificación, seguimiento e implementación.

d) Diseño de lineamientos gráficos y experiencia de usuario e) Arquitectura de la Solución: Descripción de la arquitectura de la solución: lógica,

física, despliegue con los componentes, datos e infraestructura. f) Diseño de desarrollos complementarios. (cuando aplique) g) Estrategia y Plan de migración. (cuando aplique) h) Informe de resultado de la migración. (cuando aplique) i) Plan de pruebas funcionales j) Plan de pruebas no funcionales k) Informe de resultado de pruebas funcionales y no funcionales. l) Recibo a satisfacción de la solución, en ambiente de pruebas y producción. m) Manual funcional: n) Manual técnico: Descripción de la arquitectura física y lógica de la solución

vii. Descripción de la arquitectura de despliegue. viii. Modelo de datos

ix. Información de versionamiento de componentes de aplicación x. Información del software base requerido para instalación

xi. Procedimiento de instalación y actualizaciones


xii. Descripción de la configuración y parametrización de la solución. xiii. Recomendaciones de administración de tablas básicas y paramétricas,

administración de la configuración xiv. Procedimientos especiales de pruebas, mantenimientos, errores frecuentes,

etc. xv. Procedimiento para copias de respaldo,

xvi. Contactos del fabricante e implementador o) Descripción y alcance del modelo de soporte y garantía del fabricante de la licencia

y del implementador. (cuando aplique) p) Informes de ejecución de Plan de transferencia de conocimiento q) Plan de Puesta en Operación r) Informe de Mejoras post-producción. s) Informe de ejecución de Plan de Gestión de asimilación del cambio t) Código fuente de modelamiento y desarrollos complementarios. (Cuando aplique)

Notación: Los diagramas que se elaboren para los documentos técnicos deberán aplicar los estándares BPMN, para modelamiento de procesos, Archimate, para descripción de arquitecturas de todos los dominios y UML, para el diseño de arquitectura de software de las soluciones

7.9.2.5 Seguridad

a) La soluciones a implementar deben permitir la Gestión de Seguridad de Usuarios, grupos de usuarios y asignación de Roles y perfiles de usuarios, permitiendo asociar las acciones disponibles en la solución con respecto a roles de usuario, permitiendo parametrizar las funcionalidades que cada actor puede usar en la solución.

b) Un usuario puede estar asociado a uno o más roles, de tal manera que los menús de navegación de la solución se muestran o despliegan dependiendo de las acciones asociadas a cada rol de usuario, permitiendo así que cuando el usuario es autenticado correctamente, la solución verifica los roles que tiene activos para otorgarle únicamente las acciones autorizadas a realizar.

c) El diseñó de las soluciones deben definir los criterios necesarios para asegurar la trazabilidad y auditoría sobre las acciones de creación, actualización, modificación o borrado de los componentes de información, de tal manera que la solución debe permitirle al administrador de la solución parametrizar las tablas y eventos que pueden auditarse.

d) Las soluciones deben tener en cuenta mecanismos que aseguren el registro histórico para poder mantener la trazabilidad de las acciones realizadas por los usuarios, contemplando el registro de auditoría que contiene información de fecha y hora, identificación del registro, tabla afectada, descripción del evento, tipo de evento, usuario que realiza la acción, identificación de sesión y dirección IP del usuario que efectuó la transacción.


e) las soluciones deben proveer una consulta que permita a un usuario con los privilegios asignados, consultar los registros de auditoria, aplicando criterios de filtro (usuario, maquina, rango de fechas y tipo de operación).

f) las soluciones deben integrarse con LDAP – (Lightweight Directory Access Protocol) para los procesos de inicio de sesión y autenticación. La solución debe soportar la integración Nativa con Active Directory de Microsoft. Para usuarios externos (por ejemplo: vigilados y ciudadanos) el mecanismo de autorización, autenticación y acceso será controlado a través del modelo de seguridad de la solución.

g) las soluciones deben cumplir con los lineamientos de seguridad relacionados a su utilización a través de redes públicas y privadas, garantizando la confidencialidad e integridad de la información y acceso a ella.

h) Se debe evidenciar que, a través de pruebas de vulnerabilidad, garantiza la seguridad de la información. Estas pruebas deben suministrar evidencia de que se usaron umbrales de seguridad para establecer niveles mínimos aceptables de calidad de la seguridad y de la privacidad.

i) Deben incluir un mecanismo de cifrado de los datos que se transportan entre los diferentes componentes tecnológicos y los datos sensibles de la base de datos que representen un alto nivel de confidencialidad.

j) A nivel de la base de datos deben poder definirse reglas de validación de integridad de datos (unicidad, referencial y negocio).

k) Deben contemplar el cumplimiento de la normatividad vigente en cuanto a protección de datos personales y debe permitir el manejo de excepciones.

l) Deben permitir el manejo de certificados y/o firmas digitales en los documentos que así se definan para efectos de aprobación y digitalización. La Superintendencia Nacional de Salud, se encargará de gestionar ese servicio con un tercero avalado para tales fines, como por ejemplo Certicámara o emitidos por cualquiera de las entidades certificadoras existentes en Colombia de acuerdo a la Ley 527 de 1999 y Decreto 019 de 2012 o sus posteriores versiones o actualizaciones de la ley, así mismo debe disponer de mecanismos de firma digital de larga duración con formatos XADES, CADES o PADES, con el fin de dar cumplimiento a la ley 1437 de 2011 y Decreto 1080 de 2015. Además, debe permitir la integración con un proveedor de certificados digitales que permita comprobar el “time stamp” de los documentos firmados.

m) Deben tener en cuenta todas las exigencias regulatorias especialmente ley de protección de Datos 1581 de 2012, ley de transparencia 1712 de 2014 Manual GEL y sus subsecuentes actualizaciones.

n) Deben contemplar las prácticas de desarrollo seguro de aplicaciones y/o implementación segura de productos, para su naturaleza Web Enabled.

o) Deben funcionar sobre protocolo SSL (certificados internos de la entidad cuando los sistemas de información sean internas y certificados validos públicamente cuando los sistemas de información estén expuestas a internet).

p) Deben entregar un procedimiento para el respaldo de la información de acuerdo a las necesidades de la entidad.


q) Deben incluir uso de criptografía para transacciones y/o campos sensibles según lo indiquen las normas vigentes y las necesidades específicas del negocio de acuerdo como lo determine la entidad.

r) Deben contemplar un modelo de datos que garantice base de datos única para evitar que se pueda presentar duplicidad de información.

s) En la información confidencial solo puede ser consultada por los perfiles autorizados e igualmente restringir documentos de consulta según los privilegios o permisos asociados.

t) Debe evidenciar que, a través de pruebas de vulnerabilidad, garantiza la seguridad de la información.

u) A nivel de la base de datos deben poder definirse reglas de validación de integridad de datos (unicidad, referencial y negocio).

v) Deben permitir la administración y catalogación de los documentos asociados a los procesos de acuerdo a las TRD y dependencias involucradas.

w) Deben ser Web Enabled, lo que facilita los procesos de despliegue y actualización del mismo, para ello debe funcionar sobre protocolo SSL (certificados internos de la entidad cuando las aplicaciones sean internas y certificados validos públicamente cuando las aplicaciones estén expuestas a internet).

x) Deben cerrar las transacciones luego de máximo 10 minutos de inactividad. y) Deben incluir controles de bloqueo de cuenta después de un máximo de 5 intentos

erróneos a fin de evitar ataques de fuerza bruta. z) Los contratistas de las implementaciones deben tener implementado un sistema de

gestión y aseguramiento de la calidad y la seguridad para los servicios que el contrato demanda. Este sistema debe dar cobertura a las prácticas de Gestión de Proyectos, Gestión de Requerimientos, Modelamiento e Implementación de Soluciones, Administración de la Configuración, Pruebas, Integración de Producto, Despliegue a usuarios, Administración de Incidentes, resolución de problemas y manejo integral del riesgo durante el ciclo de vida del desarrollo de la solución, esto se debe evidenciar mediante procedimientos formalmente documentados y apropiados por el personal asignado al contrato, los cuales se darán a conocer formalmente al supervisor técnico del contrato y se controlará su cumplimiento durante la ejecución del contrato.

aa) En las implementaciones se deben efectuar pruebas de ethical hacking, análisis de vulnerabilidades, análisis de plataforma, carga, estrés y desempeño antes de la puesta en operación.

bb) Con el fin de validar el cumplimiento de Seguridad la entidad llevara a cabo pruebas de WEB PENETRATION TESTING en la fase de Ejecución tanto en la sub fase de pruebas como en la sub fase de despliegue mediante el uso de herramientas especializadas para tal fin, de igual forma la entidad efectuara una revisión de código fuente en cualquiera de las sub fases de la fase de ejecución (Análisis, Desarrollo, Pruebas, Despliegue, Estabilización, Monitoreo y Control) mediante el uso de herramientas especializadas para este fin y/o revisión manual, de igual manera la entidad efectuara pruebas de carga y estrés durante la sub fase de Monitoreo y control mediante el uso de scripts específicamente desarrollados para este fin. Es


importante aclarar en este punto que el contratista deberá llevar a cabo las tareas o correcciones que puedan generarse como resultado de las validaciones efectuadas por la Superintendencia nacional de Salud.

cc) Se deben disponer de procedimientos y/o actividades que permitan activar las auditorias disponibles tanto en los servidores como en las bases de datos y aplicaciones, así como destinar un recurso para la revisión proactiva y diaria de estos eventos.

dd) las soluciones deben cumplir con todos los lineamientos de desarrollo seguro establecidos en The OWASP Foundation recomendados en la “Guía de desarrollo OWASP” y “OWAS Cheat Sheet” y como mínimo tienen que estar protegidos y preparados para soportar ataques reportados en el top 10 de OWASP a saber: A1– Inyección, A2–Pérdida de Autenticación y Gestión de Sesiones, A3–Secuencia de Comandos en Sitios Cruzados (XSS), A4 – Referencia Directa Insegura a Objetos, A5– Configuración de Seguridad Incorrecta, A6 –Exposición de Datos Sensibles, A7–Ausencia de Control de Acceso a las Funciones, A8–Falsificación de Peticiones en Sitios Cruzados (CSRF), A9–Uso de Componentes con Vulnerabilidades Conocidas, A10–Redirecciones y reenvíos no validados.

8 LISTA DE ABREVIATURAS Y GLOSARIO

SIGLA Descripción general en español

ALM Gestión del ciclo de vida de las aplicaciones

Antispam Software que contrarresta los mensajes de correo electrónico no deseado

Antivirus Software que contrarresta las amenazas de virus informáticos

Back-End Servicios Informáticos de infraestructura que respaldan la operación

BI Inteligencia Empresarial

BPM Gestión de Procesos de negocio

CMDB Base de datos de configuración

CRM Gestión de las relaciones comerciales

ESB Bus empresarial de servicios de interoperabilidad

FIREWALL Cortafuegos, Herramienta informática de seguridad para contrarrestar amenazas web

Front end Capa de Presentación de los servicios de tecnología que estarán de cara a los usuarios

HTTPS Protocolo seguro de transferencia de hipertexto en la web

IIS Servidor de aplicaciones de Microsoft

JDBC Protocolo Java de conexión a las bases de datos

LDAP Servicio de AUTENTICACIÓN de usuarios


SIGLA Descripción general en español

Microsoft Allways On Componente de alta transaccionalidad de la base de datos SQL Server

Moodle Plataforma informática para enseñanza virtual

ODBC Protocolo de conexión a las bases de datos

OLTP Componente analítico de las bases de datos

PROXY Servidor de Puente entre los equipos y el canal de internet

Single Sign On Autenticación única de los usuarios de red

SLAs Acuerdos de niveles de servicio

SNS

SOA Arquitectura Orientada a servicios

SSL Protocolo de seguridad de las aplicaciones web

WSSecurity Protocolo de seguridad de los servicios web

superintendencia nacional de salud · 5.1.2 directorio activo _____ 15 5.1.3 iométrico ... 7.1...

Documents