Documento Diseño de Arquitectura v1.6

Diseño de
Arquitectura
Octubre de 2018
ECOPETROL
1603871/2526189 de 2018
Análisis de Arquitectura
ECOPETROL
Análisis, Diseño funcional y técnico, Configuración, Desarrollo, Pruebas, Puesta

en producción, Estabilización y transición a la operación de la Solución
para el Departamento de Tierras.
CONTRATO 16037871/2526189 DE 2018
Registro de Modificaciones
Fecha Creación / Fecha

Versión Descripción Autor Aprobado por
Modificación Aprobación
BISA -Ing. César
1.0 Versión Base Omar León Agosto 2018 Agosto 2018
Mancipe
BISA -Ing. César Septiembre
1.1 Actualización Omar León Septiembre 2018
Mancipe 2018
2
ECOPETROL
1603871/2526189 de 2018
Actualización de
BISA -Ing. César
1.2 Arquitecturas de Omar León Octubre 2018 Octubre 2018
Mancipe
Referencia
Arquitectura y BISA -Ing. César Noviembre
1.3 Omar León Noviembre 2018
Componentes Azure Mancipe 2018
Observaciones sobre
BISA -Ing. César Noviembre
1.4 los componentes de Omar León Noviembre 2018
Mancipe 2018
Azure
Se actualiza para el
BISA -Ing. César
1.5 pase a producción Omar León Octubre 2019 Octubre 2019
Mancipe
del primer hito
Se actualiza
configuraciones e BISA -Ing. César Nomviembre
1.6 Omar León Noviembre 2019
información de Mancipe 2019
seguridad
3
ECOPETROL
1603871/2526189 de 2018
Contenido
1 Introducción............................................................................................................................... 6
2 Alcance del Sistema.................................................................................................................. 7
2.1 Administrativo...................................................................................................................... 7
Ámbito:.................................................................................................................................. 7
Excepciones:......................................................................................................................... 7
2.2 Transaccional...................................................................................................................... 8
Ámbito:.................................................................................................................................. 8
Excepciones:......................................................................................................................... 8
2.3. Inteligencia.......................................................................................................................... 9
Ámbito:.................................................................................................................................. 9
Excepciones:......................................................................................................................... 9
3 Sistema Actual......................................................................................................................... 10
4 Sistema Propuesto.................................................................................................................. 13
4.1 Arquitectura Propuesta (Análisis)....................................................................................13
4.1.1 Solución Integral Aplicación Web .Net con BD on Cloud y Visor en AGOL.....................13
4.1.2 Solución Integral Aplicación Web .Net con BD on Premise y Visor en AGOL.................15
4.1.3 Solución Integral Aplicación .Net on Premise y Visor en AGOL......................................16
4.1.4 Solución Integral Aplicación en Sharepoint Online y Visor en AGOL..............................16
4.1.5 Solución Integral Aplicación Web en Azure con Sharepoint Add-Ins y Visor en AGOL...17
4.1.6 Solución Integral Aplicación Web en Azure con Sharepoint Add-Ins y BD on Premise con
Visor en AGOL............................................................................................................................. 19
4.1.7 Solución Integral Aplicación Web .Net con BD on Cloud y Visor en Portal for ArcGIS....20
4.1.8 Solución Integral Aplicación Web .Net con BD on Premise y Visor en Portal for ArcGIS 21
4.1.9 Solución Integral Aplicación Web .Net on Premise y Visor en Portal for ArcGIS............22
4.1.10 Solución Integral Aplicación en Sharepoint Online y Visor en Portal for ArcGIS..........23
4.1.11 Solución Integral Aplicación Web en Azure con Sharepoint Add-Ins y Visor en Portal for
ArcGIS 24
4.1.12 Solución Integral Aplicación Web en Azure con Sharepoint Add-ins con BD on Premise
y Visor en Portal for ArcGIS......................................................................................................... 25
4.1.13 Solución Integral Aplicación Web .Net con BD on Cloud y Visor personalizado con API
ESRI 26
4.1.14 Solución Integral Aplicación Web .Net con BD on Premise y Visor personalizado con
API ESRI26
4.1.15 Solución Integral Aplicación Web .Net on Premise y Visor personalizado con API ESRI
27
4.1.16 Solución Integral Aplicación en Sharepoint Online y Visor personalizado con API ESRI
28
4.1.17 Solución Integral Aplicación Web en Azure con Sharepoint Add-Ins y Visor
personalizado con API ESRI........................................................................................................ 29
4.1.18 Solución Integral Aplicación Web en Azure con Sharepoint Add-Ins con BD on Premise
y visor personalizado con API ESRI............................................................................................. 30
4.1.19 Solución Integral Aplicación Web .Net con BD on Cloud y Visor SIGDI.......................31
4.1.20 Solución Integral Aplicación Web .Net con BD on Premise y Visor SIGDI...................32
4.1.21 Solución Integral Aplicación Web .Net on Premise y Visor SIGDI................................33
4.1.22 Solución Integral Aplicación en Sharepoint Online y Visor SIGDI.................................34
4.1.23 Solución Integral Aplicación Web en Azure con Sharepoint Add-Ins y Visor SIGDI.....35
4
ECOPETROL
1603871/2526189 de 2018
4.1.24 Solución Integral Aplicación Web en Azure con Sharepoint Add-Ins y Visor SIGDI.....36
4.1.25 Solución Integral Aplicación Web en Azure y Visor personalizado con API ESRI........37
4.1.26 Solución Integral Aplicación Web en Azure con BD on Premise y Visor personalizado
con API ESRI............................................................................................................................... 38
4.2 Análisis y Evaluación de las Arquitecturas......................................................................39
4.3 Selección de la Arquitectura a Desarrollar......................................................................44
4.4 Análisis previo para una Aplicación Móvil.......................................................................47
5 Despliegue............................................................................................................................... 52
5.1 Despliegue del primer Hito.............................................................................................. 52
5
ECOPETROL
1603871/2526189 de 2018
Índice de Anexos
Archivo Descripción
6
ECOPETROL
1603871/2526189 de 2018
1 Introducción
El presente documento tiene por objeto contextualizar un “Análisis Situacional” y

“Marco de Trabajo” con el cual será desarrollada y entregada una Solución Informática
denominada: Solución Integral de Gestión de Tierras; todo esto en relación y bajo
conformidad de los términos establecidos en la contratación 16037871/2526189 de 2018,
suscrita ante ECOPETROL.
Del concepto “Solución” se debe desprender la idea que el producto a entregar

está compuesto por un portafolio de Programas Informáticos con vida independiente,
pero inter-relacionables entre sí, los cuales en su conjunto darán respuesta a las
necesidades de los usuarios que usarán la Solución.
La Solución está compuesta por los siguientes programas informáticos:
 Base de Datos Transaccional y Espacial (Core)

 Servicios de Interoperación en un Bus de Integración (SAP/FileNet P8)
 Aplicación de Captura Web (Administración y Usuario)
 Bodega de Datos (SAP HANA BI)
 Reportes e Indicadores de Inteligencia del Negocio (Power BI).
Una vez entregada la Solución, este documento servirá como fuente de conocimiento
para que esta pueda ser comprendida por cualquier interesado. Se requiere un
conocimiento técnico básico-intermedio para abstraer su contenido.
7
ECOPETROL
1603871/2526189 de 2018
2 Alcance del Sistema
La solución tiene tres (3) alcances definidos, a saber:
2.1 Administrativo
Comprende la capacidad de configurar y administrar la Solución Integral, registros,

datos y entidades a través de sus aplicaciones especializadas.
Ámbito:
 Administración de registros y entidades:

o Capacidad de administrar y gestionar las tablas maestras de la Solución.
o Capacidad de administrar y gestionar los Registros de datos y Entidades de
la Solución sin alterar la captura de datos.
 Usuarios, Roles y Permisos (Seguridad):
o Capacidad de integrarse con el API de usuarios y autenticación.
o Capacidad para manejar roles internos y propios de la gestión inmobiliaria
 Auditoría de los Programas y Procesos:
o Se generarán registros de eventos para aquellas operaciones del modelo
del negocio.
Excepciones:
 La Solución no ofrece esquemas de seguridad, auditoría o administración sobre:

o Los Requisitos no Funcionales en los cuales debe operar la Solución.
Entiéndase: centro de datos, hardware, software, sistema operativo, redes,
comunicaciones, perímetro de seguridad informática y otros conexos.
o Los Requisitos Funcionales de los cuales la Solución alimenta su Modelo de
Negocio sino hasta el ámbito de su propia operación.
o El uso indebido del sistema rompiendo los protocolos de seguridad
establecidos en ECOPETROL. Entiéndase: exposición/distribución de la
contraseña, filtraciones de datos sensibles y otros casos similares.
 La Solución no contempla las siguientes operaciones o actividades de la Plataforma
Tecnológica:
o Adquisición, Montaje e Interconexión de hardware y equipos del requisito
funcional.
8
ECOPETROL
1603871/2526189 de 2018
o Configuración; salvo la del montaje y puesta en marcha de los Programas

de la Solución Integral.
o Gestión; salvo aquella necesaria para prestar servicio, soporte y calidad a la
Solución.
2.2 Transaccional
Comprende la capacidad de la Solución para Capturar, almacenar, procesar y

presentar la Información Transaccional y Espacial que apoya/sustenta la Gestión
Inmobiliaria.
Ámbito:
 Captura/Registro de datos:
o Capacidad de capturar datos para la base de datos transaccional/espacial
de la Solución Integral que apoya/sustenta la Gestión Inmobiliaria; esto
conforme a los diseños de los flujos configurados en la Solución.
 Consulta y seguimiento de datos:
o Capacidad de consultar entidades y registros de datos desde la base de
datos transaccional/espacial de la Solución Integral que apoya/sustenta a la
gestión Inmobiliaria.
o Capacidad de consultar servicios del Bus de Integración para interactuar
con las aplicaciones involucradas (FileNet P8 y SAP)
Excepciones:
 La operación de la Solución en dispositivos móviles tiene algunas limitaciones y

restricciones en su modalidad de uso OFF-LINE, tales como:
o Sincronización de data de gestión.
o Envió de coordenadas geográficas.
o Recepción de notificaciones.
o Consulta a Solicitudes
o Gestión de Fotos de Daños
9
ECOPETROL
1603871/2526189 de 2018
2.3. Inteligencia
Ámbito:
Herramientas y procesos de Extracción, Transformación y Carga de la Data

registrada y administrada por la Solución Integral con el propósito de generar
conocimiento e inteligencia para la gestión inmobiliaria.
Excepciones:
 Los procesos de inteligencia y alimentación del Data mart, están limitados a los
diseños de dimensiones, métricas e indicadores requeridos por la Gestión
Inmobiliaria para interpretar desempeño del mismo. Estos elementos no son
estáticos y pueden implementarse en diferentes momentos de la producción de la
Solución.
 El consumo de datos de inteligencia está limitado a las capacidades y
licenciamiento de las herramientas (y accesorios de éstas) especificadas en la
contratación.
10
ECOPETROL
1603871/2526189 de 2018
3 Sistema Actual
Para la fecha de la contratación de la Solución Integral, ECOPETROL tiene una inmensa

carga de trabajo alrededor de la Gestión Inmobiliaria; dentro de la entidad existe una serie
de herramientas y repositorios de información que interactúan de manera
descentralizada, lo cual genera un esfuerzo adicional para mantener sincronizada la
información (Centinela, Proyect, Excel, Ecogeos, Sharepoint Online, FileNet P8, Solicitudes
de Pago en SAP, etc), este consumo de tiempo adicional en la duplicación de información,
la validación de pendientes y las notificaciones de manera manual disminuyen la
posibilidad de agilizar la gestión.
Es importante determinar que se cuenta con una base de datos espacial llamada RE
(Real State) en instancias de producción y calidad, así mismo ambas instancias definen
también a RE2 y RE3 que funcionan como BDs de Calidad y todas las BDs tienen la misma
estructura, a excepción de RE de la instancia de calidad, que es la que lleva el desarrollo
más avanzado, trabajando de esta forma para no afectar el proceso que tienen en
productivo con las diferentes RE.
Gráfico 1: As-Is
Todo el proceso empieza con una solicitud de un subservicio que requieren las
diferentes vicepresidencias para su gestión inmobiliaria, la cual se realiza desde
Sharepoint Online a través de un formulario el cual guarda su información a través de
11
ECOPETROL
1603871/2526189 de 2018
listas de Sharepoint, una vez se recibe una solicitud por parte de los profesionales de
Gestión y Control, viene una etapa de validación y verificación para poder determinar un
Plan de Trabajo (PDT) donde se asignan los recursos necesarios para poder atender dicho
subservicio, pero en este proceso de validación se descarga la data de los formularios a
archivos en Excel, cada grupo de trabajo valida las solicitudes que le correspondan según
su vicepresidencia y/o proyecto, así estos grupos pueden hacer el seguimiento pero de
manera separada de la información que se pueda llevar con la información en las Listas de
Sharepoint.
Una vez realizado los PDTs, que normalmente se arman ya sean en Proyect o Excel
dependiendo del grupo de trabajo, pero con un mismo fin, que es balancear sus recursos,
empieza un proceso de interacción con el sistema Centinela, pero al ser una aplicación
aislada realizada con una base de datos en posgresql y Aplicación Web realizada en php y
al no sincronizarse con los demás sistemas, los usuarios tienen que transcribir fechas y
demás datos para alimentar este último, también hay una interacción aislada con otro
aplicativo llamado SOMO (Solicitud de modificación) que se utiliza para realizar un control
de cambio sobre el PDT original (Project o Excel) y esto conlleva nuevamente a interactuar
con Centinela para retroalimentarlo.
A grandes rasgos el aplicativo Centinela, gestiona solo los subservicios que tengan que
ver con pagos ya sea por servidumbre o por concepto de daños generados sobre los
predios, así mismo, en el proceso cuando se llega a los pagos, se debe interactuar con
solicitudes a SAP para poder continuar con los pagos, pero los demás subservicios que no
tengan que ver con pagos, no tienen una herramienta propia de gestión más allá de
formatos propios en Excel.
Adicionalmente hay una interacción en varios puntos del proceso con un gestor
documental llamado FileNet P8 de IBM, el cual es repositorio oficial ya sea de los
documentos del proyecto o de los predios identificados con un código SIG, este código SIG
para poderlo obtener pasa por un proceso manual y de validación en varias fuentes para
poderlo determinar, por el mismo hecho de que la data no está centralizada, no está
automatizado.
Otro de los puntos de vista del proceso, es la calidad de los datos y su veracidad, desde
que se empieza el proceso con la solicitud, el cliente (Líder de Proyecto), no se tiene
parametrizado los documentos que tiene que subir dependiendo del subservicio a pedir,
por lo que en Sharepoint Online, pueden subir una foto del predio que necesita gestionar,
o un archivo Word, un archivo CAD, o un ShapeFile Geográfico, cualquier archivo para la
12
ECOPETROL
1603871/2526189 de 2018
ayuda de la validación de la gestión, pero esto conlleva un reproceso, ya que cerca del
30% de las solicitudes, según indicadores de gestión, se devuelven porque no se entiende
que es lo que realmente desean gestionar, así mismo se juega un papel de verificación con
el cliente por cualquier otro medio (e-mail o teléfono) para pedir claridades o indagar
sobre lo requerido.
Siguiendo con temas de calidad de data, se ha evidenciado que en los export que se
realizan desde las diferentes herramientas, ya sea desde Sharepoint Online o Centinela, se
ven temas de caracteres extraños no alineados a una codificación única, llámese UTF-8 o
UNICODE, lo cual conlleva a una limpieza manual que realiza los usuarios finales
normalmente sobre formatos en Excel.
Otro de los grandes inconvenientes que hacen consumir una gran cantidad de tiempo
y papel, es la validación constante en diferentes puntos del proceso a los proveedores
(Dueños/Habitantes de los Predios) en cuanto a su vinculación en listas negras (Lista
Clinton, Policía Nacional, Listas de Persona Públicamente Expuestas, OFAC, Procaduria,
etc), actualmente en cada validación se hacen capturas de pantalla de la consulta de cada
uno de los medios y se lleva impreso, aunque en el último mes se han estado alineando a
una herramienta que unifica en gran parte estas listas en el site de LexisNexis.
En cuanto al tema geográfico hay una clara diferenciación de la captura de datos

divididos entre las instancias de producción y calidad (SIGECP); en la instancia de
producción se almacena la captura de datos geográficos del año 2016 en adelante, esto se
hace a través de otra herramienta llamada SIGDI y en la instancia de calidad se está
haciendo un trabajo de captura de históricos del año 2016 hacia atrás, con la
particularidad que en este ambiente los constraint se levantaron en pro de tener toda la
data allí para posteriormente hacer una migración a la instancia de producción.
13
ECOPETROL
1603871/2526189 de 2018
4 Sistema Propuesto
4.1 Arquitectura Propuesta (Análisis)
Se propone contar con una Solución Integral, segura, con rendimiento, facilidad de
uso, parametrizable para sustentar la gestión inmobiliaria, atado a los requerimientos del
anexo técnico del contrato, para ello se plantean como base 26 acercamientos para el
desarrollo de la capa de Aplicación tanto a nivel Transaccional y Geográfico.
De acuerdo al levantamiento de requerimientos no funcionales realizadas en

conjunto con el personal de Ecopetrol tanto funcionales como técnicos se determina los 6
criterios más relevantes para la selección de una de las arquitecturas, estos 6
requerimientos son:
1. Integrabilidad (Integración de componentes con múltiples arquitecturas)

2. Usabilidad (Experiencia de Usuario)
3. Latencia (Tiempo de Respuesta)
4. Seguridad (Datos-Funcionalidad)
5. Confiabilidad (Disponibilidad de fuentes y calidad de datos)
6. Costos (Licenciamiento)
A continuación, se detalla cada una de las arquitecturas propuestas y posteriormente

se determinarán las arquitecturas que serán evaluadas con criterio de experto con
personal de Ecopetrol y Bisa para determinar la más adecuada según los 6 requerimientos
no funciónales y criterios de selección expuestos.
4.1.1 Solución Integral Aplicación Web .Net con BD on Cloud y Visor en AGOL
El primer acercamiento contempla una aplicación hecha con ASP. NET la cual será el
“core” de la solución integral, basado en tres grandes módulos, el primero es en cuanto al
Balanceo de Recursos, emulando un proceso para la gestión de los planes de trabajo
(PDTs) con las funcionalidades de manera integrada al flujo de trabajo, la ventaja de este
enfoque es la integración nativa que va a tener con la entidad relacional definida en la
base de datos con el proceso y no de manera aislada con Microsoft Proyect.
14
ECOPETROL
1603871/2526189 de 2018
Gráfico 2: To-Be Propuesta 1
El segundo gran modulo a contemplar es el de un WorkFlow parametrizable

adaptado al proceso que tienen actualmente, teniendo en consideración de que los flujos
se desean reutilizables y hasta cierto punto en su construcción dinámicos por parte del
usuario final para agregar nuevos subservicios a futuro, según lo especifica el
requerimiento REQ002 y REQ010 del documento de requerimientos técnicos y
funcionales.
El tercer módulo es con respecto a las notificaciones, aunque el flujo contempla
eventos de notificación, esta actividad se vuelve recurrente en el tiempo, hasta que las
actividades no se culminen, el tema de notificaciones debe estar funcional y con la
periodicidad que se le configure para cada uno de los pasos del WorkFlow, este módulo
sirve como base a los indicadores diarios que se entregan sobre el seguimiento a la
gestión predial.
Siguiendo con el acercamiento planteado, observamos que todos los temas de
indicadores se sacaran en Power BI y se montan sobre Sharepoint Online en las diferentes
áreas correspondientes de las vicepresidencias involucradas, así mismo conectándose a un
Data Marts montado en SAP Hana, según como se pide en los requerimientos
contractuales REQ011, también con Sharepoint Online que es el portal oficial de
Ecopetrol, tendría el acceso directo a la Solución Integral.
15
ECOPETROL
1603871/2526189 de 2018
De igual manera Sharepoint funcionaria como repositorio de documentación inicial

que se usan para determinar el plan de trabajo (PDT), de allí en adelante se usará FileNet
P8 para los documentos oficiales que se procesaran en cada una de las fases.
En cuanto al tema de seguridad, se plantea utilizar el controlador de dominio
replicado en Sharepoint Online para que sirva de autenticación a la Solución Integral, pero
con un esquema de roles dentro de la nueva aplicación para que la administración de la
gestión inmobiliaria quede centralizada en el área correspondiente.
El visor bajo este enfoque se propone que sea un desarrollo sobre ArcGIS Online, el
cual contendrá un visor con acceso a los diferentes servicios geográficos montados sobre
la capa de servicios geográficos que provee ArcGIS Server.
4.1.2 Solución Integral Aplicación Web .Net con BD on Premise y Visor en AGOL
Este enfoque es similar al anterior 4.1.1, con la particularidad de bajar la latencia

teniendo las bases de datos on-premise y generar una reducción de costos en la nube
pero a su vez podrá incrementar los costos de mantenimiento de la infraestructura local
aunque no deberían de subir en gran proporción ya que Ecopetrol cuenta con DBAs
actualmente en el manejo de Oracle y tener la base de datos en la nube y en otra
tecnología como la de Microsoft obliga a tener 2 puntos de gestión con diferentes
motores de base de datos que este enfoque busca solventar además del punto de
integralidad que es de los más valorados por los usuarios finales.
16
ECOPETROL
1603871/2526189 de 2018
4.1.3 Solución Integral Aplicación .Net on Premise y Visor en AGOL
Este enfoque es similar a los anteriores 4.1.1 y 4.1.2, con la particularidad de bajar la
latencia aún más teniendo el aplicativo web y las bases de datos on-premise y generar una
reducción de costos aún mayor en la nube, aportando a una mayor integración y
reducción de latencia.
4.1.4 Solución Integral Aplicación en Sharepoint Online y Visor en AGOL
En este acercamiento se plantea el uso de las herramientas propias de Sharepoint

Online usando Power Apps y Microsoft Flow que sean los que se encarguen de controlar la
gestión.
Dentro de Sharepoint Online se integraría Power BI, pero igual que en los
acercamientos anteriores consumiendo un origen de datos del BI de Hana, y los
componentes del visor geográfico, los servicios de LexisNexis, incluso el manejo de los
archivos de las solicitudes se integra en Sharepoint Online. En este acercamiento se
utilizaría powerApps para el frontend de los módulos de la solución integral y la lógica de
17
ECOPETROL
1603871/2526189 de 2018
negocio y comunicación con la base de datos se haría a través de una capa de servicios
montada en la DMZ de la organización, sobre un proyecto de WCF o Web API 2.
Lamentablemente este enfoque no resulta una alternativa viable ya que las

herramientas propias de Sharepoint Online solucionan casos muy puntuales y para una
solución tan robusta se tendría que delegar mucho trabajo ya sea a un Sharepoint On-
Premise o a la capa de servicios transaccionales propuesta.
Esta propuesta se rechazó en comité por el manejo de sharepoint como base del
desarrollo y las experiencias con aplicaciones con PowerApps que resultan complejas para
integraciones robustas.
en AGOL
Este enfoque involucra Sharepoints Add-in alojados en Azure, los cuales tendrán la
funcionalidad de extender las capacidades de Sharepoint Online y así poder definir la
lógica de negocio necesaria para la gestión inmobiliaria en la nube.
18
ECOPETROL
1603871/2526189 de 2018
Teniendo la lógica de negocio en Sharepoints Add-ins se puede acceder a data de

Sharepoint Online a través de las diferentes APIs incluidas en Sharepoint, en este punto
existen 2 caminos a tomar, el primero es Sharepoint-Hosted y el otro que se propone para
esta solución es el Provider-Hosted, bajo este último enfoque la solución se centraría en
una aplicación web donde la lógica de negocio estaría del lado del servidor.
Gráfico 6: Sharepoint-hosted vs Provider-hosted

Source: Microsoft
19
ECOPETROL
1603871/2526189 de 2018
El modelo de la gestión inmobiliaria en este enfoque está orientado a una

arquitectura con un front-end web que sirve las solicitudes del cliente y un trabajo que
realiza tareas que requieren un uso intensivo de recursos, flujos de trabajo de larga
duración o trabajos por lotes. El front-end se comunica con el trabajo a través de una cola
de mensajes.
El back-end consiste en una API web, la cual se puede usar con una aplicación de
una sola página que realiza las llamadas AJAX.
Esta arquitectura, Azure la define como Web-Queue-Worker y tiene las siguientes

ventajas:
- Arquitectura relativamente sencilla y fácil de entender.

- Relativamente fácil de implementar y administrar.
- Clara separación de problemas.
- El front-end se desacopla del trabajo por medio de la mensajería asincrónica.
- El front-end y el trabajo pueden escalarse de forma independiente.
4.1.6 Solución Integral Aplicación Web en Azure con Sharepoint Add-Ins y BD on

Premise con Visor en AGOL
Esta propuesta es la misma que la 4.1.5 también involucra Sharepoints Add-in

alojados en Azure con la particularidad que la base de datos se propone on-premise por
temas de integrabilidad y latencia con la BD geográfica que se pueda originar desde la
aplicación en la nube.
20
ECOPETROL
1603871/2526189 de 2018
4.1.7 Solución Integral Aplicación Web .Net con BD on Cloud y Visor en Portal for
ArcGIS
Esta propuesta es similar a la propuesta 4.1.1 con la única diferencia que no estaría
usando AGOL para el visor geográfico sino Portal for ArcGIS, ya que se contempló esta
opción en diferentes reuniones, aunque en comité de arquitectura se descartan las
propuestas con Portal for ArcGIS por temas de exposición a la nube y licenciamiento.
21
ECOPETROL
1603871/2526189 de 2018
4.1.8 Solución Integral Aplicación Web .Net con BD on Premise y Visor en Portal
for ArcGIS
22
ECOPETROL
1603871/2526189 de 2018
4.1.9 Solución Integral Aplicación Web .Net on Premise y Visor en Portal for
ArcGIS
23
ECOPETROL
1603871/2526189 de 2018
4.1.10 Solución Integral Aplicación en Sharepoint Online y Visor en Portal for

ArcGIS
Adicionalmente esta propuesta se rechazó en comité por el manejo de sharepoint

como base del desarrollo y las experiencias con aplicaciones con PowerApps que resultan
complejas para integraciones robustas.
24
ECOPETROL
1603871/2526189 de 2018
en Portal for ArcGIS
propuestas con Portal for ArcGIS por temas de exposición a la nube y licenciamiento,
adicionalmente las arquitecturas con base en sharepoint online también se descartan por
consenso en comité de arquitectura y experiencias con el uso de Sharepoint como base
para los proyectos.
25
ECOPETROL
1603871/2526189 de 2018
4.1.12 Solución Integral Aplicación Web en Azure con Sharepoint Add-ins con BD
on Premise y Visor en Portal for ArcGIS
propuestas con Portal for ArcGIS por temas de exposición a la nube y licenciamiento,
adicionalmente las arquitecturas con base en sharepoint online también se descartan por
consenso en comité de arquitectura y experiencias con el uso de Sharepoint como base
para los proyectos.
26
ECOPETROL
1603871/2526189 de 2018
4.1.13 Solución Integral Aplicación Web .Net con BD on Cloud y Visor

personalizado con API ESRI
Esta propuesta es similar a la propuesta 4.1.1 y 4.1.7 con la única diferencia que no
estaría usando AGOL para el visor geográfico ni Portal forArcGIS sino un visor hecho a la
medida con la tecnología API javascript propia de ESRI, este enfoque nace de la necesidad
de disminuir costos en licenciamiento de ArcGIS ya que las anteriores propuestas tienen
implícitas estos costos.
4.1.14 Solución Integral Aplicación Web .Net con BD on Premise y Visor

27
ECOPETROL
1603871/2526189 de 2018
4.1.15 Solución Integral Aplicación Web .Net on Premise y Visor personalizado con
API ESRI
28
ECOPETROL
1603871/2526189 de 2018
4.1.16 Solución Integral Aplicación en Sharepoint Online y Visor personalizado con

API ESRI
29
ECOPETROL
1603871/2526189 de 2018
Esta propuesta se descarta por consenso en comité de arquitectura y experiencias

con el uso de Sharepoint como base para los proyectos.
30
ECOPETROL
1603871/2526189 de 2018
4.1.18 Solución Integral Aplicación Web en Azure con Sharepoint Add-Ins con BD
on Premise y visor personalizado con API ESRI

31
ECOPETROL
1603871/2526189 de 2018
4.1.19 Solución Integral Aplicación Web .Net con BD on Cloud y Visor SIGDI
Esta propuesta es similar a la propuesta 4.1.13 con la diferencia que se estaría

reutilizando SIGDI como base del proyecto para el visor geográfico, aunque a la final se
presentó la arquitectura en combinación con API ESRI ya que los componentes de SIGDI se
construyen con la funcionalidad del API de ESRI, bajo una plantilla de carpetas y
organización propia de ESRI, este enfoque nace de la necesidad de disminuir costos en
licenciamiento de ArcGIS y en pro de avanzar más rápidamente hacer reciclaje de
componentes de ser necesario del SIGDI.
32
ECOPETROL
1603871/2526189 de 2018
4.1.20 Solución Integral Aplicación Web .Net con BD on Premise y Visor SIGDI

33
ECOPETROL
1603871/2526189 de 2018
4.1.21 Solución Integral Aplicación Web .Net on Premise y Visor SIGDI

34
ECOPETROL
1603871/2526189 de 2018
4.1.22 Solución Integral Aplicación en Sharepoint Online y Visor SIGDI

35
ECOPETROL
1603871/2526189 de 2018
SIGDI


36
ECOPETROL
1603871/2526189 de 2018
SIGDI


37
ECOPETROL
1603871/2526189 de 2018
4.1.25 Solución Integral Aplicación Web en Azure y Visor personalizado con API
ESRI
Esta propuesta nace de la necesidad de evaluar una arquitectura que solo se

contemple Azure, sin Sharepoint Online más allá de utilizar el Document Library,
asegurando una arquitectura PaaS con todos los beneficios que trae la nube.
38
ECOPETROL
1603871/2526189 de 2018
4.1.26 Solución Integral Aplicación Web en Azure con BD on Premise y Visor

Esta propuesta nace de la necesidad de evaluar una arquitectura que solo se

contemple Azure, sin Sharepoint Online más allá de utilizar el Document Library similar a
la arquitectura 4.1.25 pero contemplando la BD on Premise.
39
ECOPETROL
1603871/2526189 de 2018
4.2 Análisis y Evaluación de las Arquitecturas
Una vez analizadas las 26 arquitecturas y descartadas según criterio de expertos, se

hizo una evaluación sobre las siguientes:
- (a1) 4.1.1 Aplicación Web .Net con BD on Cloud y Visor en AGOL
- (a2) 4.1.2 Aplicación Web .Net con BD on Premise y Visor en AGOL
- (a3) 4.1.3 Aplicación Web .Net on Premise y Visor en AGOL
- (a6) 4.1.13 Aplicación Web .Net con BD on Cloud y Visor personalizado
con API ESRI
- (a7) 4.1.14 Aplicación Web .Net con BD on Premise y Visor personalizado
con API ESRI
- (a8) 4.1.15 Aplicación Web .Net on Premise y Visor personalizado con
API ESRI
- (a11) 4.1.25 Aplicación Web en Azure y Visor personalizado con API ESRI
- (a12) 4.1.26 Aplicación Web en Azure con BD on Premise y Visor
40
ECOPETROL
1603871/2526189 de 2018
A continuación, se resume el ejercicio de valoración de cada una de las arquitecturas

seleccionadas versus cada uno de los criterios de evaluación seleccionados:
Integrabilidad (integración de componentes con múltipes arquitecturas)

a1 a2 a3 a6 a7 a8 a11 a12
Alexis 5 6 7 6 7 8 9 7
Juan 4 4 4 5 5 7 8 6
Efrain 5 6 7 6 5 6 8 6
Fabián 5 5 6 5 5 7 7 8
Oscar N. 6 7 7 7 7 8 8 7
Dresné 6 7 6 8 6 8 7 5
Omar 5 5 6 6 6 7 6 6
Diego P. 4 6 7 5 6 8 7 8
Angelo 5 5 5 6 6 7 7 6

Total 5 5,67 6,11 6 5,89 7,33 7,44 6,56
Usabilidad (experiencia de usuario)

a1 a2 a3 a6 a7 a8 a11 a12
Alexis 5 5 5 6 6 6 7 7
Juan 5 5 5 5 5 5 7 7
Efrain 5 5 5 6 5 5 7 7
Fabián 6 6 6 6 6 5 5 5
Oscar N. 7 7 8 8 8 8 8 8
Dresné 6 5 3 7 4 5 7 3
Omar 6 5 5 6 5 6 7 7
Diego P. 4 5 5 6 6 7 7 7
Angelo 5 4 5 5 6 6 7 7

Total 5,44 5,22 5,22 6,11 5,67 5,89 6,89 6,44
Latencia (tiempo de respuesta)
41
ECOPETROL
1603871/2526189 de 2018
a1 a2 a3 a6 a7 a8 a11 a12
Alexis 5 4 6 5 5 6 5 5
Juan 4 4 5 5 4 4 6 4
Efrain 5 4 6 5 4 5 7 6
Fabián 4 4 7 7 6 7 7 7
Oscar N. 5 4 7 8 5 7 8 7
Dresné 5 4 8 7 4 7 8 4
Omar 6 6 6 6 6 6 7 6
Diego P. 6 6 6 6 5 7 7 6
Angelo 5 4 4 6 6 6 7 5

Total 5 4,44 6,11 6,11 5 6,11 6,89 5,56
Seguridad (datos + funcionalidad)

a1 a2 a3 a6 a7 a8 a11 a12
Alexis 4 4 6 5 5 6 7 7
Juan 4 5 5 5 5 6 7 6
Efrain 5 5 5 5 5 5 5 5
Fabián 7 7 6 7 6 6 6 6
Oscar N. 5 6 7 7 7 7 8 7
Dresné 6 6 6 7 6 7 8 5
Omar 6 6 6 6 7 7 7 7
Diego P. 6 6 7 6 6 7 7 6
Angelo 6 5 5 6 6 6 7 7

Total 5,44 5,56 5,89 6 5,89 6,33 6,89 6,22
42
ECOPETROL
1603871/2526189 de 2018
Confiabilidad (disponibilidad de fuentes y calidad de datos)

a1 a2 a3 a6 a7 a8 a11 a12
Alexis 5 5 4 6 5 4 7 6
Juan 4 5 4 5 5 4 6 6
Efrain 5 5 4 6 5 4 8 8
Fabián 6 6 6 6 5 5 6 6
Oscar N. 8 9 9 8 8 8 8 8
Dresné 6 6 7 7 6 5 7 5
Omar 6 6 6 6 6 6 7 7
Diego P. 5 7 7 6 6 7 7 7
Angelo 6 5 4 5 6 5 8 8

Total 5,67 6 5,67 6,11 5,78 5,33 7,11 6,78
Costos (licenciamiento)
a1 a2 a3 a6 a7 a8 a11 a12
Alexis 3 2 3 5 4 5 4 3
Juan 3 3 3 3 3 6 4 4
Efrain 3 2 3 5 4 5 4 3
Fabián 4 4 5 6 5 4 6 6
Oscar N. 3 4 6 8 6 8 5 6
Dresné 2 4 3 7 3 4 7 4
Omar 3 3 3 3 4 6 7 7
Diego P. 2 4 4 4 5 7 6 7
Angelo 4 4 4 5 5 5 5 4

Total 3 3,33 3,78 5,11 4,33 5,56 5,33 4,89
43
ECOPETROL
1603871/2526189 de 2018
Haciendo un análisis de lo totales se observa que la arquitectura (a11) gana en 5 de

los 6 criterios seleccionados quedando como la mejor valorada y la arquitectura (a8) como
la segunda mejor valorada ya que gana en uno de los criterios y queda como segunda en 3
criterios.
Priorización
7 a11 0.15
6 a8 0.14
8 a12 0.13
4 a6 0.13
5 a7 0.12
3 a3 0.12
2 a2 0.11
1 a1 0.11
Priorización de Arquitecturas Evaluadas
Se detallan observaciones adicionales con ventajas y desventajas a tener en

consideración para la selección de la arquitectura a desarrollar:
(a8) 4.1.15 Aplicación Web .Net (a11) 4.1.25 Aplicación Web

On Premise y Visor personalizado en Azure y Visor
con API ESRI personalizado con API ESRI
Ventajas 1) Al tener la aplicación On 1) Al tener la aplicación On
Premise se puede reducir la Cloud se aprovechan las
latencia al tener integrada una ventajas de escalamiento
base de datos con los temas horizontal que provee Azure
geográficos y transaccionales o si pero así mismo crecen los
es el caso en 2 esquemas, pero costos de manera
sobre la misma instancia. proporcional.
2) Se reduce la elaboración de Web 2) Arquitectura orientada a
Services que de tener la Base de ser PaaS.
Datos transaccionales en la nube
serían necesarios, al tener el motor
de base de datos On Premise
44
ECOPETROL
1603871/2526189 de 2018
muchas transacciones se harían sin

tener que pasar por un servicio
adicional.
3) Es notable la reducción de
costos al aprovechar la
infraestructura y los recursos con
la que ya cuenta Ecopetrol.
Desventajas La infraestructura de la Aplicación Bases de datos distribuidas
está bajo la administración de On Premise y Cloud con
Ecopetrol diferentes tecnologías (SQL
Azure y Oracle)
Ambas arquitecturas son las propuestas para que quede a criterio de selección de
Ecopetrol.
4.3 Selección de la Arquitectura a Desarrollar
Una vez analizadas y evaluadas las arquitecturas, se lleva a comité técnico de

expertos los pros y los contras de las arquitecturas ganadoras y se llega al siguiente
consenso:
1. Las bases de datos se van a trabajar on Premise bajo un mismo esquema
2. La aplicación se desarrollará bajo estándares modernos de arquitectura ya que la
decisión final de estar alojado on cloud u on premise es de Ecopetrol, incluso no
se habla de Azure sino de Virtualización en Cloud
3. El visor como lo dicta la arquitectura mejor valorada será desarrollado a la
medida con API ESRI y reutilizando módulos y funcionalidades de SIGDI
4. Este on premise o en la nube se requiere separar las capas de servicios
transaccionales de las geográficas
5. Se desarrollará la aplicación de manera portable usando lenguaje .Net Core
45
ECOPETROL
1603871/2526189 de 2018
Gráfico 29: Arquitectura a Desarrollar
Una vez definida la arquitectura base, se detalla a continuación los servicios Azure
que darán vida al backend, para ello se detalla a continuación cada uno de los
componentes que lo integran en un ambiente de desarrollo:
Tipo de Objetivo Región Descripción
46
ECOPETROL
1603871/2526189 de 2018
Servicio
Azure Servicio para la administración de los East US 3 A4 v2 (4 vCPU; 8 GB de
Kubernetes Microservicios en Contenedores, 5 a 6 RAM) nodos x 730 Hours;
Service (AKS) microservicios, se estima 2 nucleos y 4 Pago por uso; 0 discos de
de RAM para cada uno en ambiente SO administrados: S4
productivo
Container Lleva el registro de las 6 Imágenes cada East US Nivel Estándar, 1 unidades
Registry una con 3 versiones x 30 días, 0 GB de ancho
de banda, 0 GB
Almacenamiento adicional
API Administra el uso de las API contenidas East US Nivel Premium, 1
Management en los containers, validando su unidad(es), 730 Hours
integridad y salud
App Service Servicio de hospedaje para el Front-End East US Nivel Estándar; 1 S3 (4
de la solución integral bajo el concepto núcleos, 7 GB de RAM, 50
SPA como Web App for Container GB de almacenamiento) x
730 Hours; SO Windows
47
ECOPETROL
1603871/2526189 de 2018
Gráfico 30: Servicios Azure
4.4 Análisis previo para una Aplicación Móvil
En cuanto a la aplicación móvil que ayudaría al profesional de campo, se tienen

como referencia a las Apps del catálogo de ESRI, por ser la naturaleza espacial el proyecto
de Gestión Inmobiliaria y por otro lado tenemos las aplicaciones nativas para Android;
Buscando un equilibrio entre la integración del flujo de trabajo en la herramienta móvil y
el consumo de servicios geográficos se hace un análisis de estas herramientas.
Gráfico 29: Arcgis Apps vs Aplicaciones Nativas, Hibridas y Web
Partimos de una comparación entre tecnologías para poder determinar la más

viable en cuanto a desarrollo y adaptación al proyecto, empezando con una
conceptualización de las aplicaciones de ESRI:
Workforce: Esta herramienta móvil trabaja en conjunto con una aplicación Web, desde la
aplicación Web se puede controlar el trabajo de personal de campo, desde la aplicación
móvil se puede ir actualizando el estado del trabajo asignado.
48
ECOPETROL
1603871/2526189 de 2018
Con esta herramienta se crea un proyecto en la web y se van asignado los usuarios
según sus roles ya sea un controlador o un usuario móvil, luego de esta asignación se
puede desarrollar una integración con otras aplicaciones como Navigator for Arcgis,
Collector for Arcgis o Survey123 for Arcgis para simular un flujo de trabajo (Ordenes de
Trabajo).
Navigator: Esta App, permite utilizar los datos que se proporcionan a través de servicios
de ArcGIS, o datos personalizados para crear rutas de navegación a los diferentes activos
de la organización, en este caso nos daría una ruta eficiente para llegar a un predio que se
esté gestionando.
Collector: Esta App proporciona las siguientes funcionalidades: Captura puntos

geográficos utilizando el mapa o el GPS, Permite descargar los mapas en el dispositivo
móvil y trabar sin conexión, puede capturar puntos, líneas, áreas y datos relacionados,
permite adjuntar fotos a entidades, permite buscar lugares y entidades, así mismo puede
realizar un seguimiento de donde ha estado el profesional de campo.
Survey123: Esta App es otro capturador de información más orientado a la captura sobre
formularios previamente configurados, desde datos alfanuméricos hasta campos
espaciales.
Explorer: Esta App es un visor más avanzado que permite usar búsquedas con
herramientas de marcado y medición para encontrar fácilmente el camino e intercambiar
con otros usuarios información sobre puntos de referencia, activos y áreas de interés.
Gráfico 30: Integración Apps ESRI para Operaciones en Campo
49
ECOPETROL
1603871/2526189 de 2018
Las Apps de ESRI, dan soluciones puntuales a diferentes casos de uso, pero la
administración con la llamada solución integral, se vería subordinada a las aplicaciones
web/móvil propias de ESRI que interactúan entre sí a través de Workforce for Arcgis,
dejando un gran espacio para la adaptación lo cual llevaría un desarrollo propio a través
de AppStudio for Arcgis (Desktop) o utilizando una automatización con scripts hechos con
ArcGIS API for Python hacia Workforce en la nube.
Para poder integrar las apps Móviles/Web de ESRI con el PDT (Plan de Trabajo) y
todo lo que esto involucra (Asignación de usuarios automáticamente, fechas de entrega,
alertas, Ids, Descripción de la tarea que se debe hacer en campo, adjuntos necesarios
para la gestión, etc) y no tener que dejarlo aislado, para que la configuración de toda esta
data que ya viene de la Solución Integral se haga de manera automática, se tendría que
hacer un desarrollo móvil hibrido, bajo un estándar propio de Arcgis, con un desarrollo de
Frontend bajo componentes en QML de Qt, APIs en QML y desarrollo de módulos en
leguaje C++. Todo esto también se podría realizar accediendo al esquema de Workforce
utilizando una sincronización con Scripts desarrollados con ArcGIS API for Python (A
manera de ETL para Cargar Asignaciones/Reasignaciones de trabajo desde la Solución
Integral, Importar los profesionales de campo, eliminar de su bandeja las tareas
culminadas, etc.) así como lo recomienda ESRI en su documentación oficial.
Por otro lado, tenemos el desarrollo estándar de aplicaciones móviles, ya sea

Nativas, Hibridas y Web, esta última descartada ya que no permiten trabajar de manera
Offline y en cuanto al desarrollo de la aplicación hibrida conlleva a contemplar su
rendimiento en equipos de baja y media gama.
Se podría debatir sobre un desarrollo nativo sobre Android, asegurando el

rendimiento de la aplicación manteniendo su calidad y usabilidad en la mayoría de los
dispositivos Android, permitiendo el uso propio de funciones avanzadas para sacar
provecho de los procesadores gráficos que en los desarrollos híbridos no le sacan
totalmente provecho.
Dentro de las ventajas del desarrollo nativo que se contemplan para el desarrollo
de la Gestión Inmobiliaria están:
- Proporcionan mayor seguridad ya que el uso de plugins y javascript en las

aplicaciones hibridas introduce nuevas capas de complejidad susceptibles a ser
atacadas.
50
ECOPETROL
1603871/2526189 de 2018
- Mejoran la duración de la batería ya que el código esta optimizado para la

arquitectura del móvil, hace un uso más adecuado de los distintos núcleos de
GPU/CPU y necesita menos capas de software para ejecutarse.
- Al contemplarse varias funcionalidades como las planteadas inicialmente las cuales
describo a continuación se denota un panorama donde se hace mucho uso de
servicios web tanto transaccionales como espaciales, manejo offline de mapas
entre otros que al hacerlo de manera hibrida el peso de la aplicación
irremediablemente crecerá haciendo más uso de memoria RAM y por ende baja de
rendimiento:
o Sincronización de data de gestión.
o Envió de coordenadas geográficas.
o Recepción de notificaciones.
o Consulta a Solicitudes
o Gestión de Fotos de Daños
- En las aplicaciones nativas se pueden crear tantos hilos de ejecución como se
desee y se pueden soportar los servicios del sistema, cosa que las hibridas no
manejan, sobre todo para temas de notificación como bien es una de las
características que se plantea desarrollar.
- En dado caso que se desee crear las notificaciones como actividades en segundo
plano, estas en hibrido están limitadas al acceso de red, y esta actividad, aunque se
puede tratar de usar ciertos plugins normalmente se ejecuta en el hilo de la UI de
manera limitada y trayendo consigo temas de rendimiento.
51
ECOPETROL
1603871/2526189 de 2018
Gráfico 31: App Móvil Solución Integral
52
ECOPETROL
1603871/2526189 de 2018
5 Despliegue
5.1 Despliegue del primer Hito
Según lo establecido por la gerencia se realizará el despliegue a producción

del sistema de gestión de tierras, para lo cual se contemplan los siguientes
componentes de la arquitectura base:
Tipo de Servicio Descripción

Azure Kubernetes Servicio para la administración de los Microservicios en Contenedores, 6
Service (AKS) microservicios:
- API Gestión Tierras
- API Geográfico
- API Impuesto Predial
- API Presupuesto
- API Indemnizaciones
- API Observatorio
Container Registry Lleva el registro de las 6 Imágenes cada una con 3 versiones
API Management Administra el uso de las API contenidas en los containers, validando su
integridad y salud
App Service Servicio de hospedaje para el Front-End de la solución integral bajo el
concepto SPA como Web App for Container
Esquema de Oracle Despliegue del esquema SGI en una instancia de Oracle On Premise
Servicios Geográficos Despliegue sobre los servidores Arcgis de los geoprocesos, features y map
en ArcGis Server server services:
- Geo procesó de Nuevas Gestiones
- Geo procesó de Conversión de Coordenadas
- Geo procesó de Autocompletar Geometrías
- Geo procesó de Validación de Topologías
- Directorio de Capas Geográficas
Site en Sharepoint Publicación de sitio en Sharepoint con acceso al Document Library donde
reposaran los archivos de la Gestión Inmobiliaria como repositorio de primer
nivel.
53
ECOPETROL
1603871/2526189 de 2018
Gráfico 32: Arquitectura Azure para el despliegue del Hito 1
5.2 Configuración de Seguridad
Se detalla a continuación cada uno de los puntos para asegurar la solución

integral contra ataques externos/internos, aplicando buenas practicas de
aseguramiento de la data, la cual es necesario que el equipo de ciberseguridad
tenga presente al momento de hacer los despliegues a producción.
5.2.1 Base de Datos
La aplicación como cualquier otra tiene data sensible, sobre todo referente
a los propietarios de los predios y en cuanto a la información propia de los usuarios
54
ECOPETROL
1603871/2526189 de 2018
de la solución, para ello se identifican los siguientes campos que tienen

encriptación:
- Personas.numeroDocumento
- Personas.lugarExpedicion
- Personas.fechaNacimiento
- Personas.telefonoContacto
- Personas.direccionContacto
- Usuarios.telefono
- Usuarios.numeroDocumento
Gráfico 34: Tablas susceptibles a cifrado
La solución cuenta con 2 funciones (Encriptación/Desencriptación) las

cuales usan el método dbms_obfuscation_toolkit de Oracle, las mismas cuentan
con un Key que se debe sustituir en ambiente productivo, el cual se resalta a
continuación:
55
ECOPETROL
1603871/2526189 de 2018
56

Documento Diseño de Arquitectura v1.6

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Documento Diseño de Arquitectura v1.6

Cargado por

Copyright:

Formatos disponibles

Diseño de

Análisis, Diseño funcional y técnico, Configuración, Desarrollo, Pruebas, Puesta

CONTRATO 16037871/2526189 DE 2018

Fecha Creación / Fecha

El presente documento tiene por objeto contextualizar un “Análisis Situacional” y

Del concepto “Solución” se debe desprender la idea que el producto a entregar

La Solución está compuesta por los siguientes programas informáticos:

 Base de Datos Transaccional y Espacial (Core)

2 Alcance del Sistema

La solución tiene tres (3) alcances definidos, a saber:

Comprende la capacidad de configurar y administrar la Solución Integral, registros,

 Administración de registros y entidades:

 La Solución no ofrece esquemas de seguridad, auditoría o administración sobre:

o Configuración; salvo la del montaje y puesta en marcha de los Programas

Comprende la capacidad de la Solución para Capturar, almacenar, procesar y

 La operación de la Solución en dispositivos móviles tiene algunas limitaciones y

Herramientas y procesos de Extracción, Transformación y Carga de la Data

Para la fecha de la contratación de la Solución Integral, ECOPETROL tiene una inmensa

En cuanto al tema geográfico hay una clara diferenciación de la captura de datos

4.1 Arquitectura Propuesta (Análisis)

De acuerdo al levantamiento de requerimientos no funcionales realizadas en

1. Integrabilidad (Integración de componentes con múltiples arquitecturas)

A continuación, se detalla cada una de las arquitecturas propuestas y posteriormente

Gráfico 2: To-Be Propuesta 1

El segundo gran modulo a contemplar es el de un WorkFlow parametrizable

De igual manera Sharepoint funcionaria como repositorio de documentación inicial

Este enfoque es similar al anterior 4.1.1, con la particularidad de bajar la latencia

Gráfico 3: To-Be Propuesta 2

4.1.3 Solución Integral Aplicación .Net on Premise y Visor en AGOL

Gráfico 4: To-Be Propuesta 3

4.1.4 Solución Integral Aplicación en Sharepoint Online y Visor en AGOL

En este acercamiento se plantea el uso de las herramientas propias de Sharepoint

Gráfico 5: To-Be Propuesta 4

Lamentablemente este enfoque no resulta una alternativa viable ya que las

Teniendo la lógica de negocio en Sharepoints Add-ins se puede acceder a data de

Gráfico 6: Sharepoint-hosted vs Provider-hosted

Gráfico 7: To-Be Propuesta 5

El modelo de la gestión inmobiliaria en este enfoque está orientado a una

Esta arquitectura, Azure la define como Web-Queue-Worker y tiene las siguientes

- Arquitectura relativamente sencilla y fácil de entender.

4.1.6 Solución Integral Aplicación Web en Azure con Sharepoint Add-Ins y BD on

Esta propuesta es la misma que la 4.1.5 también involucra Sharepoints Add-in

Gráfico 8: To-Be Propuesta 6

Gráfico 9: To-Be Propuesta 7

Gráfico 10: To-Be Propuesta 8

Gráfico 11: To-Be Propuesta 9

4.1.10 Solución Integral Aplicación en Sharepoint Online y Visor en Portal for

Adicionalmente esta propuesta se rechazó en comité por el manejo de sharepoint

Gráfico 12: To-Be Propuesta 10

Gráfico 13: To-Be Propuesta 11

Gráfico 14: To-Be Propuesta 12

4.1.13 Solución Integral Aplicación Web .Net con BD on Cloud y Visor

Gráfico 15: To-Be Propuesta 13

4.1.14 Solución Integral Aplicación Web .Net con BD on Premise y Visor

Gráfico 16: To-Be Propuesta 14

Gráfico 17: To-Be Propuesta 15

4.1.16 Solución Integral Aplicación en Sharepoint Online y Visor personalizado con

Gráfico 18: To-Be Propuesta 16

Esta propuesta se descarta por consenso en comité de arquitectura y experiencias

Gráfico 19: To-Be Propuesta 17

Esta propuesta se descarta por consenso en comité de arquitectura y experiencias

Gráfico 20: To-Be Propuesta 18

Esta propuesta es similar a la propuesta 4.1.13 con la diferencia que se estaría

Gráfico 21: To-Be Propuesta 19