Diseño de la Arquitectura Empresarial para el Sistema Inteligente de Transporte de Bogotá Diana María Vásquez García _____________________ Facultad de Ingeniería, Proyecto Curricular de Ingeniería de Sistemas Bogotá D.C., Colombia 2015
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Diseño de la Arquitectura Empresarial para el Sistema Inteligente de Transporte de
Bogotá
Diana María Vásquez García
_____________________
Facultad de Ingeniería, Proyecto Curricular de Ingeniería de Sistemas Bogotá D.C., Colombia
2015
Diseño de la Arquitectura Empresarial para el Sistema Inteligente de Transporte de
Bogotá
Diana María Vásquez García
Trabajo de grado presentado como requisito parcial para optar al
título de:
Ingeniero de Sistemas
Director:
Dr. Edgar Jacinto Rincón Rojas
Codirector
Dr. Jorge Mario Calvo Londoño
Línea de Investigación:
Arquitectura Empresarial
Universidad Distrital Francisco José de Caldas
Facultad de Ingeniería
Bogotá D.C, Colombia
2015
Nota de aceptación:
___________________________ _____________________________ _____________________________ _____________________________ _____________________________ _____________________________ _____________________________
_________________________________
Firma del Director del Trabajo de Grado
_________________________________
Firma del Codirector del Trabajo de Grado
_________________________________
Firma del jurado
Bogotá, Agosto de 2015
Dedicatoria
“(…) Hasta ahora el Señor me ha ayudado” 1 Samuel 7:12.
A mi madre Stella por su amor y apoyo incondicional.
Diana María Vásquez García
Agradecimientos
Sinceros agradecimientos a mis directores de tesis, Dr. Edgar Jacinto Rincón Rojas y Dr.
Jorge Mario Calvo Londoño, por su especial dedicación, apoyo, sugerencias y
correcciones que hicieron posible el desarrollo de este trabajo.
Al grupo de Interventoría de la Universidad Distrital pertenecientes al Convenio Marco de
Cooperación N° 1029 quienes me permiten aprender cada día con su experiencia.
A mi familia por su apoyo y enseñanzas.
A mis amigos por su paciencia y colaboración a lo largo de la carrera.
A Dios por permitirme cumplir este primer sueño de ser ingeniera, a la espera de
alcanzar muchos sueños más.
Resumen
En busca del mejoramiento del tráfico en Bogotá, La Secretaría Distrital de Movilidad
(SDM) y su aliada tecnológica la Empresa de Telecomunicaciones de Bogotá (ETB),
proponen la implementación de un Sistema Inteligente de Transporte (SIT) en esta
ciudad. Los inconvenientes centrales para la puesta en marcha de esta implementación
obedecen principalmente a que, de un lado, la Secretaría Distrital de Movilidad no
presenta de forma detallada los requerimientos necesarios para el proyecto y de otro
lado, que el diseño propuesto por la ETB involucra principalmente operarios e
infraestructura, dejando de lado el componente inteligente, lo cual imposibilita el deseado
mejoramiento del tráfico en la ciudad. Por lo tanto, mientras se presenten estos
inconvenientes, ninguno de los objetivos que la SDM espera para el SIT podrá llevarse a
feliz término.
Este trabajo propone el diseño de la Arquitectura Empresarial necesaria para los fines
deseados bajo el marco de referencia TOGAF1, empleando específicamente la
metodología Architecture Development Method (ADM), para cubrir el gap identificado
entre la fase inicial y la de diseño, de manera que se obtenga el diseño ideal para
resolver el problema identificado y pueda hacerse un aporte significativo a la ejecución
del proyecto. Lo anterior con el propósito de contribuir a un plan empresarial de gran
magnitud, importancia y afectación para todos los ciudadanos como es el Sistema
Inteligente de Transporte para Bogotá.
Palabras clave: Arquitectura Empresarial, sistema inteligente de transporte.
1 TOGAF: The Open Group Architect Framework
Abstract
Looking forward for the traffic improvement in Bogota, the District Department of Mobility
(Secretaria Distrital de Movilidad, SDM) and its technological ally, Bogota’s
telecommunications Company (ETB) are proposing the implementation of a Smart
Transportation System (SIT) in the city. The main inconveniences to run such
implementation are due, in one side, that the District Department of Mobility does not
show in detail the necessary requirements for the Project and, on the other side, the
design proposed by the ETB involves mainly workers and infrastructure, leaving on the
side the intelligent component, which precludes the desired improvement for the city’s
traffic. Therefore, while these inconveniences are presented, none of the objectives that
the SDM expects for the SIT will be able to be accomplished.
With that being said, this draft proposes the design of the Enterprise architecture
necessary to achieve the desired purposes which are under the reference frame TOGAF,
using specifically the methodology of the Architecture Development Method (ADM), to
cover the identified gap between the initial phase and the design, in that way we would be
able to obtain the ideal design to resolve the issue that has been identified and also
giving an important input to the Project’s execution. This is with the purpose of
contributing to a huge Enterprise plan which has importance and affectation to all citizens,
as it is on the Smart Transportation System (SIT) for Bogota.
Keywords: Enterprise architecture, Smart Transportation System.
Contenido
INTRODUCCIÓN ........................................................................................................... 15
PRESENTACIÓN ............................................................................................................ 17
1.1. Planteamiento del problema ............................................................................. 18
1.2. Justificación ...................................................................................................... 19
1.3. Objetivos .......................................................................................................... 20
1.3.1. Objetivo general............................................................................................. 20
1.3.2. Objetivos Específicos..................................................................................... 20
MARCO REFERENCIAL Y CONCEPTUAL .................................................................... 21
MARCO REFERENCIAL ............................................................................................ 21
2.1 Antecedentes Convenio marco de cooperación N° 1029 de 2010 ......................... 21
2.2 Decreto 2573 del 12 de diciembre del 2014 .......................................................... 24
MARCO CONCEPTUAL ............................................................................................. 26
2.3. Arquitectura Empresarial ...................................................................................... 26
2.4. TOGAF ................................................................................................................ 27
2.5. Método de desarrollo de la arquitectura (ADM) .................................................... 30
2.5.1. Fase Preliminar.............................................................................................. 31
2.5.2. Visión de la arquitectura ................................................................................ 31
2.5.3. Arquitectura de negocios, sistemas de información y tecnología ................... 31
2.5.4. Oportunidades y soluciones ........................................................................... 32
2.5.5. Planeamiento de migración ........................................................................... 32
2.5.6. Implementación de gobierno .......................................................................... 33
2.5.7. Desarrollo y mantenimiento de Arquitectura Empresarial ............................... 33
2.5.8. Gestión de requerimientos ............................................................................. 33
2.6. Otros conceptos ............................................................................................... 34
DESARROLLO DE LA METODOLOGÍA ........................................................................ 37
3.1 Propósito del documento ...................................................................................... 39
3.2. Alcance ................................................................................................................ 39
3.2.1. Amplitud ......................................................................................................... 39
3.2.2. Dominio .......................................................................................................... 40
3.2.3. Profundidad .................................................................................................... 41
3.3. Metas, objetivos y limitaciones ............................................................................. 42
10
3.3.1. Objetivos a nivel organizacional ......................................................................42
3.3.2. Objetivos de negocio y tecnología ...................................................................43
3.3.3. Stakeholders ...................................................................................................45
3.3.4. Restricciones a nivel organizacional................................................................45
3.3.5. Capacidades ...................................................................................................46
3.4 Compliance ....................................................................................................... 48
3.4.1. Principios de arquitectura ................................................................................49
3.4.2. Políticas y normas ..........................................................................................52
3.5. Riesgos ................................................................................................................ 55
3.5.1. Análisis de riesgos ..........................................................................................55
3.5.2. Matriz de hallazgos, recomendaciones y beneficios .......................................59
3.6. Línea base de arquitectura ............................................................................... 61
3.6.1. Modelo de arquitectura de negocio.................................................................61
3.6.2. Modelo de arquitectura de información ...........................................................65
3.6.3. Modelo de arquitectura de tecnología .............................................................66
3.7. Mapeo de la arquitectura de repositorio ............................................................ 67
3.7.1. Arquitectura metamodelo ...............................................................................68
3.7.2. Arquitectura del escenario ..............................................................................68
3.7.3. Biblioteca de referencia ..................................................................................69
3.7.4. Normas base de información ..........................................................................69
3.7.5. Registros de gobernabilidad ...........................................................................70
3.7.6. Capacidad de la arquitectura ..........................................................................70
3.8. Arquitectura de destino ......................................................................................... 71
3.8.1. Modelo de arquitectura de negocio ................................................................71
3.8.2. Modelo de arquitectura de información ...........................................................74
3.8.3. Modelo de arquitectura de tecnología .............................................................75
3.9. Análisis de las deficiencias ............................................................................... 77
3.10. Evaluación de impacto .................................................................................. 78
3.10.1. Referencia de requerimientos específicos ...............................................78
3.10.2. Prioridad de stakeholders de los requerimientos para-fecha .........................79
CONCLUSIONES Y TRABAJO FUTURO .......................................................................81
Trabajo Futuro ............................................................................................................. 82
Bibliografía .................................................................................................................. 83
11
GLOSARIO DE TERMINOS ............................................................................................ 87
Anexos ...................................................................................................................... 89
12
Lista de figuras FIGURA 1 LÍNEA DEL TIEMPO CONVENIO MARCO DE COOPERACIÓN N° 1029 DE 2010. FUENTE:
PROPIA: REALIZADA CON INFORMACIÓN SUMINISTRADA POR LA SECRETARÍA DISTRITAL DE
MOVILIDAD ................................................................................................................ 22
FIGURA 2 LÍNEA DEL TIEMPO CONVENIO MARCO DE COOPERACIÓN N° 1029 DE 2010. FUENTE:
PROPIA: REALIZADA CON INFORMACIÓN SUMINISTRADA POR LA SECRETARÍA DISTRITAL DE
MOVILIDAD ................................................................................................................ 22
FIGURA 3 LÍNEA DEL TIEMPO CONVENIO MARCO DE COOPERACIÓN N° 1029 DE 2010. FUENTE:
PROPIA: REALIZADA CON INFORMACIÓN SUMINISTRADA POR LA SECRETARÍA DISTRITAL DE
MOVILIDAD ................................................................................................................ 23
FIGURA 4 LÍNEA DEL TIEMPO CONVENIO MARCO DE COOPERACIÓN N° 1029 DE 2010. FUENTE:
PROPIA: REALIZADA CON INFORMACIÓN SUMINISTRADA POR LA SECRETARÍA DISTRITAL DE
MOVILIDAD ................................................................................................................ 23
FIGURA 5 DOMINIOS DE LA ARQUITECTURA EMPRESARIAL IASA. FUENTE: IASA SPAIN CHAPTER
– VISIÓN GENERAL A TOGAF. RECUPERADO DE
HTTPS://WWW.YOUTUBE.COM/WATCH?V=IKWHOHBBWG0 EL 20 DE FEBRERO DE 2015 .. 27
FIGURA 6 TOGAF. FUENTE: IASA SPAIN CHAPTER – VISIÓN GENERAL A TOGAF. RECUPERADO
DE HTTPS://WWW.YOUTUBE.COM/WATCH?V=IKWHOHBBWG0 EL 20 DE FEBRERO DE 2015
................................................................................................................................ 28
FIGURA 7 ARCHITECTURE DEVELOPMENT METHOD. FUENTE: IMAGEN TOMADA DEL SITIO WEB:
HTTP://PUBS.OPENGROUP.ORG/ARCHITECTURE/TOGAF9-DOC/ARCH/FIGURES/ADM.PNG . 30
FIGURA 8 TOGAF, ADM. FUENTE: IASA SPAIN CHAPTER – VISIÓN GENERAL A TOGAF.
RECUPERADO DE HTTPS://WWW.YOUTUBE.COM/WATCH?V=IKWHOHBBWG0 EL 20 DE
FEBRERO DE 2015 ..................................................................................................... 34
FIGURA 9 OBJETIVOS SMART. FUENTE: IMÁGEN TOMADA DEL SITIO WEB
HTTP://NURIASAMPER.COM/MARCATE-OBJETIVOS-SMART-Y-ESTABLECE-TUS-KPIS-PART-1/
................................................................................................................................ 34
FIGURA 10 ESPECIFICACIÓN OBJETIVOS SIT. FUENTE: ELABORACIÓN PROPIA. ..................... 35
FIGURA 11 DOMINIOS DE ARQUITECTURA. FUENTE: ELABORACIÓN PROPIA ........................... 41
FIGURA 12 ESTÁNDAR ISO 14813-1:2007. FUENTE: ELABORACIÓN PROPIA ......................... 41
13
FIGURA 13 OBJETIVO ORGANIZACIONAL: ADOPTAR LOS PRINCIPIOS DEL GOBIERNO EN LÍNEA.
FUENTE: ELABORACIÓN PROPIA. ................................................................................ 43
FIGURA 14 ÁRBOL DE OBJETIVOS DEL SIT. FUENTE: ELABORACIÓN PROPIA ......................... 44
FIGURA 15 MATRIZ DE STAKEHOLDERS DEL SIT. FUENTE: ELABORACIÓN PROPIA. ADAPTADO
DE HTTP://PUBS.OPENGROUP.ORG/ARCHITECTURE/TOGAF9-DOC/ARCH/ ....................... 45
FIGURA 16 MODELO DE MADUREZ DE INTEGRACIÓN DE SERVICIOS DE OPEN GROUP ........... 47
FIGURA 17 ARQUITECTURA DE NEGOCIO LÍNEA BASE - OBJETIVO 1. FUENTE: ELABORACIÓN
PROPIA ..................................................................................................................... 63
FIGURA 18 ARQUITECTURA DE NEGOCIO LÍNEA BASE - OBJETIVO 2. FUENTE: ELABORACIÓN
PROPIA ..................................................................................................................... 64
FIGURA 19 ARQUITECTURA DE NEGOCIO LÍNEA BASE - OBJETIVO 3. FUENTE: ELABORACIÓN
PROPIA ..................................................................................................................... 64
FIGURA 20 ARQUITECTURA DE INFORMACIÓN LÍNEA BASE. FUENTE: ELABORACIÓN PROPIA ... 66
FIGURA 21 ARQUITECTURA DE TECNOLOGÍA LÍNEA BASE. FUENTE: ELABORACIÓN PROPIA .... 67
FIGURA 22 OVERVIEW OF ARCHITECTURE REPOSITORY. FUENTE: ADAPTADO DE IMAGEN
TOMADA DEL SITIO WEB: HTTP://PUBS.OPENGROUP.ORG/ARCHITECTURE/TOGAF9-
DOC/ARCH/CHAP36.HTML .......................................................................................... 68
FIGURA 23 ARQUITECTURA DE NEGOCIO ARQUITECTURA DESTINO- OBJETIVO 1. FUENTE:
ELABORACIÓN PROPIA ............................................................................................... 72
FIGURA 24 ARQUITECTURA DE NEGOCIO ARQUITECTURA DESTINO- OBJETIVO 2. FUENTE:
ELABORACIÓN PROPIA ............................................................................................... 73
FIGURA 25 ARQUITECTURA DE NEGOCIO ARQUITECTURA DESTINO- OBJETIVO 3. FUENTE:
ELABORACIÓN PROPIA ............................................................................................... 73
FIGURA 26 ARQUITECTURA DE INFORMACIÓN ARQUITECTURA DESTINO. FUENTE: ELABORACIÓN
PROPIA ..................................................................................................................... 75
FIGURA 27 ARQUITECTURA DE TECNOLOGÍA ARQUITECTURA DESTINO. FUENTE: ELABORACIÓN
PROPIA ..................................................................................................................... 77
14
Lista de tablas
TABLA 1 MACRO PROCESOS ACTUALES. FUENTE: ELABORACIÓN DE LA SECRETARÍA DISTRITAL
DE MOVILIDAD. .......................................................................................................... 40
TABLA 2 MATRIZ DE EVALUACIÓN DE RIESGOS Y CONTROLES EXISTENTES EN EL PROYECTO
SIT. FUENTE: ELABORACIÓN PROPIA. ......................................................................... 56
TABLA 3 MATRIZ DE EVALUACIÓN DE RIESGOS Y CONTROLES EXISTENTES EN EL PROYECTO
SIT. FUENTE: ELABORACIÓN PROPIA. ......................................................................... 57
TABLA 4 MATRIZ DE EVALUACIÓN DE RIESGOS Y CONTROLES EXISTENTES EN EL PROYECTO
SIT. FUENTE: ELABORACIÓN PROPIA. ......................................................................... 57
TABLA 5 MATRIZ DE EVALUACIÓN DE RIESGOS Y CONTROLES EXISTENTES EN EL PROYECTO
SIT. FUENTE: ELABORACIÓN PROPIA. ......................................................................... 58
TABLA 6 MATRIZ DE EVALUACIÓN DE RIESGOS Y CONTROLES EXISTENTES EN EL PROYECTO
SIT. FUENTE: ELABORACIÓN PROPIA. ......................................................................... 59
TABLA 7 MATRIZ DE EVALUACIÓN DE RIESGOS Y CONTROLES EXISTENTES EN EL PROYECTO
SIT. FUENTE: ELABORACIÓN PROPIA. ......................................................................... 59
TABLA 8 MATRIZ DE HALLAZGOS, RECOMENDACIONES Y BENEFICIOS. FUENTE: ELABORACIÓN
PROPIA...................................................................................................................... 61
TABLA 9 GAP ANALYSIS. FUENTE: ELABORACIÓN PROPIA .................................................... 78
15
INTRODUCCIÓN 1. En este documento se presenta el diseño de la Arquitectura Empresarial para el
sistema inteligente de transporte para Bogotá. La característica principal de este tipo
de arquitectura es permitir la definición de objetivos estratégicos de negocio que
deben ser soportados por tecnologías de información adecuadas para la
organización. Para analizar el caso de estudio inicialmente se presenta la
problemática a partir de la cual surge la necesidad del diseño de la arquitectura y los
objetivos de este. En seguida se muestra el marco conceptual de la temática, el cual
incluye los antecedentes del Sistema Inteligente de Transporte para Bogotá ─de
ahora en adelante SIT─, su estado actual, además la descripción detallada del marco
de referencia empleado (TOGAF) y el método de desarrollo de la arquitectura
(Architecture Development Method), presentando finalmente los demás conceptos
tomados en cuenta en el documento.
2.
3. A partir del capítulo III se inicia el desarrollo de la metodología la cual se ejecuta
conforme a las plantillas establecidas por TOGAF. En esta sección se elabora la
arquitectura de línea base y arquitectura destino (AS-IS y TO-BE) para
posteriormente llevar a cabo el análisis de las deficiencias (Gap analysis) y generar
conclusiones del estudio.
4.
5. Gracias a este trabajo se genera el diseño de la Arquitectura Empresarial del SIT
enfocándose en tres objetivos principales del SIT propuestos por la Secretaría
Distrital de Movilidad y aplicado a la primera fase del proyecto.
16
17
1
PRESENTACIÓN
La arquitectura, considerada como un arte mayor, ha sido necesaria desde que se
empezaron a construir las primeras edificaciones durante el desarrollo de la humanidad;
estas construcciones han ido adquiriendo un nivel de complejidad que hace
imprescindible un diseño arquitectónico previo. Una construcción caótica como el
Winchester Mystery House2, por ejemplo, se erigió a lo largo de los años sin que ningún
arquitecto pusiera orden en ninguna de las zonas que se fuese a construir. Muchas
habitaciones y escaleras sin sentido hacen de la mansión Winchester un incidente que de
haber existido una arquitectura planeada posiblemente no sería la pintoresca mansión
que hoy conocemos. Este ejemplo de construcción y la forma como fue concebida, nos
permite enfatizar en la importancia de la organización, la planeación y la articulación de
múltiples elementos para ― al contrario que en el caso de la mansión― consolidar una
obra arquitectónica adecuada para su buen uso y funcionalidad.
Si el caso anterior se considera en relación con las tecnologías de información ocurre lo
mismo. Las organizaciones están enfrentadas hoy a un conjunto de situaciones
organizacionales que les exigen optimizar sus operaciones, de forma tal que sean
capaces de responder con rapidez a los cambios estratégicos, amenazas externas o
regulaciones de la industria y que puedan lograrlo de la forma más efectiva posible; para
conseguir esto, las organizaciones definen objetivos estratégicos de negocio que deben
ser soportados por las tecnologías de información, pero en los casos de empresas que
adquieren datos, aplicaciones o servidores pretendiendo construir con ellas una serie de
sistemas que brinden soluciones temporales y estén acorde con las tecnologías
2
Ver http://www.winchestermysteryhouse.com/
18
modernas, se causa que la organización se convierta en la Winchester Mystery House de
la tecnología. Esta situación es la que la Arquitectura Empresarial busca solucionar
poniendo orden a los sistemas actuales.
La razón principal para desarrollar una Arquitectura Empresarial en una organización es
soportar sus objetivos de negocio y proveerle la tecnología fundamental y los procesos
estructurados para una estrategia de TI. Esto a su vez, permite que las tecnologías de
información sean un activo estratégico dentro de la organización, capaz de responder a
una estrategia de negocio actual y exitosa. Los directores ejecutivos son cada vez más
conscientes de que la adecuada administración y explotación de la información, a través
de Tecnologías de Información, es fundamental para el éxito del negocio y para obtener
ventaja competitiva. La Arquitectura Empresarial atiende estas necesidades facilitando un
contexto estratégico para la evolución de los sistemas de TI en respuesta a las
necesidades constantemente cambiantes del ambiente empresarial.
1.1. Planteamiento del problema La Secretaría Distrital de Movilidad (SDM) y su aliado tecnológico la Empresa de
Telecomunicaciones de Bogotá (ETB) en procura del mejoramiento del tráfico en la
ciudad, proponen la implementación de un Sistema Inteligente de Transporte SIT (ITS
por sus sigla en inglés Inteligent Transport System) para la misma, sistema que se
desarrolla en cuatro fases. La fase inicial se está ejecutando actualmente, mientras que
las demás están por definir. Esta fase inicial, objeto del presente documento, implementa
cuatro componentes específicos en el sistema: centro de gestión, semaforización,
detección electrónica de infracciones y paneles de mensaje variable.
La función de la SDM en esta primera fase del proyecto es la de identificar y hacer
explícitos los requerimientos y necesidades que deben ser satisfechos en la operación
del SIT para que la ETB inicie el diseño de implementación basado en esos
requerimientos; además, verifica y pondera las propuestas que presenta la ETB para
responder a los requerimientos planteados y aprobar el inicio de la ejecución de las
mismas, haciéndoles seguimiento de la mano de la entidad interventora contratada: la
19
Universidad Distrital Francisco José de Caldas ─de ahora en adelante La Universidad─,
así se regulará y evaluará el proceso hasta el completo y correcto fin de la primera fase.
La problemática asociada a esa primera etapa de la puesta en marcha de un Sistema
Inteligente de Transporte se sintetiza teniendo en cuenta que el principal producto de la
fase actual es un artefacto de software, el cual pese a que tiene un componente
importante de hardware (semáforos, sensores, paneles, infraestructura entre otros), su
motor central de ejecución se desarrolla por el funcionamiento del software que
indudablemente es lo que hace inteligente al sistema propuesto; pero al analizar el
proyecto que se está desarrollando hoy desde la perspectiva del proceso de desarrollo
de software (comprendido en cinco etapas: inicio, diseño, codificación, pruebas y puesta
en funcionamiento), se identifica de forma evidente un gran gap3 entre la fase de inicio y
la de diseño. Esto ocurre porque la Secretaría Distrital de Movilidad no presenta de forma
detallada los requerimientos y el diseño propuesto por ETB involucra principalmente
operarios e infraestructura y deja de lado el componente inteligente, acción que no
permitiría el mejoramiento del tráfico en la ciudad y en general ninguno de los objetivos
que la SDM espera para el SIT.
Este estudio tiene como objeto proponer la implementación de una Arquitectura
Empresarial. Se implementa el marco de referencia TOGAF para cubrir las necesidades
del proyecto en el proceso de implementación del SIT en Bogotá, con el fin de procurar el
éxito del sistema y garantizar los beneficios de la implementación de la arquitectura
dentro de la primera fase de un proyecto de gran magnitud, importancia y afectación para
todos los ciudadanos como lo es el Sistema Inteligente de Transporte SIT.
1.2. Justificación La Arquitectura Empresarial en el desarrollo del Sistema Inteligente de Transporte SIT
para Bogotá se implementa para contribuir al esfuerzo conjunto de tres entidades
públicas: la Secretaría Distrital de Movilidad, la Empresa de Telecomunicaciones de
Bogotá y la Universidad Distrital Francisco José de Caldas, con el propósito de aportar
significativamente a la ejecución del proyecto en su primera fase (que se está llevando a
3 Gap: Traducción al español: Brecha o vacío.
20
cabo actualmente) y para añadir beneficios operacionales, oportunidades operacionales y
oportunidades de TI, mientras decrecen los riesgos de operación, los costos de
operación y los riesgos y costos de TI.
La Arquitectura Empresarial que se desea implementar, siguiendo los parámetros del
marco de referencia TOGAF, proporciona respuestas a los interrogantes y vacíos que
quedaron después de la presentación de los requerimientos del SIT por parte de la
Secretaría y la propuesta de implementación basada en dichos requerimientos elaborada
por ETB. Lo anterior es con el objetivo de cooperar en el adecuado desarrollo del
Sistema Inteligente de Transporte para Bogotá el cual, más allá de ser un proyecto
académico o laboral, tiene implícita una constante motivación para todos los involucrados
en él: el aporte a la ciudad en una problemática, que si no es la de mayor importancia en
la ciudad, sí es una de las más urgentes por resolver: el tránsito vehicular.
1.3. Objetivos
1.3.1. Objetivo general Diseñar la Arquitectura Empresarial del Sistema Inteligente de Transporte para Bogotá
(SIT), en su primera fase de ejecución, utilizando el marco de referencia TOGAF.
1.3.2. Objetivos Específicos
Estudiar el contexto y las necesidades del Sistema Inteligente de transporte
para Bogotá.
Analizar y aplicar el marco de referencia TOGAF para el diseño de la
arquitectura del Sistema Inteligente de Transporte para Bogotá.
Estudiar y comparar arquitecturas de tecnologías de información y Sistemas
Inteligentes de Transporte de referencias internacionales.
Diseñar y documentar la arquitectura propuesta para la primera fase del
Sistemas Inteligente de Transporte de Bogotá.
21
2
MARCO REFERENCIAL Y CONCEPTUAL
En este capítulo se presenta los antecedentes del Convenio Marco de Cooperación N°
1029, establecido entre la Secretaría Distrital de Movilidad, la Empresa de
Telecomunicaciones ─ETB─ y la Universidad Distrital Francisco José de Caldas, cuyo
objeto es el planteamiento y ejecución del Sistema Inteligente de Transporte ─SIT─ para
Bogotá. De igual forma se referencian conceptos básicos de Arquitectura Empresarial, el
método ADM de TOGAF y cada una de las fases del mismo, el decreto 2573 del 12 de
diciembre de 2014 el cual establece la importancia de emplear una Arquitectura
Empresarial en proyectos del distrito, entre otros conceptos relevantes para el
documento.
MARCO REFERENCIAL
2.1 Antecedentes Convenio marco de cooperación N° 1029 de 2010
A continuación se presenta una serie de líneas del tiempo que ilustran el desarrollo del
convenio Marco de Cooperación N° 1029 desde su inicio en el 2010 hasta enero del año
2015.
22
Figura 1. Línea del tiempo Convenio Marco de Cooperación N° 1029 de 2010. Fuente: Propia:
Realizada con información suministrada por la Secretaría Distrital de Movilidad.
Figura 2. Línea del tiempo Convenio Marco de Cooperación N° 1029 de 2010. Fuente: Propia:
Realizada con información suministrada por la Secretaría Distrital de Movilidad.
2010
Convenio 1029 de 05 de agosto
Anexos Financieros Fase I
(ETB y UD)
2011
Modificatorio Anexo Financiero
Fase I (UD)
2012
Suspensión Anexo Financiero
Fase I (UD)
2013
Mesas de Trabajo SDM+ETB
Documentos modificación
Convenio.
Diseño Conceptual SIT
2014 - Enero
Conformación Equipo SIT en
SDM
Análisis estado proyecto
2014 - Febrero
05 Feb. formalizó el Otrosí modificatorio No. 1 del convenio
1029 de 2010..
Mesas de trabajo SDM+ETB Reunión.
2014 - Marzo
Generación documentos –
Equipo SIT
Visita terrenos de SDM y ETB-
Ubicación Centro de Gestión
2014 - Abril
Mesas de Trabajo SDM+ETB
Reunión Registraduría
Diseño conceptual zonas, centro de
gestión, detección electrónica
2014 - Mayo
Generación borradores de
necesidades centro de gestión, DEI y Semaforización.
Reuniones Policia de Tránsito
2014 - Junio
En revisión documentos de
necesidades para entrega oficial a
ETB
Se realizó Reunión NUSE
Reunión U. Distrital
23
Figura 3. Línea del tiempo Convenio Marco de Cooperación N° 1029 de 2010. Fuente: Propia:
Realizada con información suministrada por la Secretaría Distrital de Movilidad.
Figura 4. Línea del tiempo Convenio Marco de Cooperación N° 1029 de 2010. Fuente: Propia:
Realizada con información suministrada por la Secretaría Distrital de Movilidad.
2014 - Julio
El 17 de julio de 2014, con radicados SDM-SSM-91959 ,
se radicó Documentos de funcionalidades
versiones iniciales de Semaforización y
DEI”
2014 - Agosto
El 14 de agostoSDM-SSM-
105218, Documentos con
ajustes de Semaforización y
DEI
2014 - Septiembre
Mesas de Trabajo con ETB.
Visita a puntos críticos de
accidentalidad, para definición de instalación de
cámaras
2014 - Octubre
Seguimiento y Mesas de trabajo
Centro de Gestión, Semaforización, DEI
2014 - Noviembre
El 22 de noviembre firma del
Modificatorio No. 2 al Anexo financiero
del convenio Interadministrativo
SDM y UD.
2014 - Diciembre
Llegada del nuevo equipo de la Interventoría –Universidad Distrital Francisco José de Caldas.
El 26 de diciembre la Universidad Distrital manifiesta que en la propuesta presentada por ETB no se especifica la inteligencia del Centro
de Gestión.
2015 - Enero
*El 15 de enero de 2015 se suscribió la modificación No. 2 del Anexo Financiero No. 1
entre la SDM y la UD.
*El 29 de enero , se suscribió el Otrosí modificatorio No. 2 entre ETB, UD y SDM,
convenio marco 1029 de 2010.
24
La Universidad fue designada para ejercer la función de interventoría del Convenio
Interadministrativo No. 1029 de 2010, suscrito el día 5 de agosto de 2010, cuyo objeto se
presenta a continuación: “Con apego a los principios de la función administrativa
previstos en el artículo 209 de la Constitución Política , de igualdad, moralidad , eficacia,
economía, celeridad imparcialidad y publicidad, las partes suscribientes del presente
convenio se comprometen a aunar esfuerzos y recursos técnicos, tecnológicos humanos
y administrativos requeridos para el diseño, implementación, operación, mantenimiento y
expansión del Sistema Inteligente de Transporte (SIT) para la ciudad de Bogotá, en
adelante el “PROYECTO“, a partir de los estudios elaborados por la Secretaría para el
desarrollo del mismo, los cuales hacen parte de presente convenio”.
Los componentes definidos en la Fase 1 del Convenio se relacionan a continuación: 1)
Centro de Gestión, 2) Detección electrónica de Infracciones, 3) Paneles de Mensaje
Variable y 4) Modernización y Actualización al Sistema Semafórico.
2.2 Decreto 2573 del 12 de diciembre del 2014 Para el desarrollo del proyecto se tiene en cuenta el decreto número 2573 de Diciembre
de 2014, del Ministerio de Tecnologías de Información y de las Comunicaciones, por el
cual se establecen lineamientos generales para el máximo aprovechamiento de las
tecnologías de información y de las comunicaciones.
En el decreto 2573 de 2014, se expresa la necesidad de implementar una Arquitectura
Empresarial en los proyectos que se emprendan en las entidades del Estado. Tiene por
objeto generar valor a través de las Tecnologías de Información para que se ayude a
materializar la visión de las entidades por medio de la Arquitectura Empresarial, una
motivación más para promover el uso de esta buena práctica, en especial, para un
proyecto de impacto masivo como lo es la implementación de un Sistema Inteligente de
Transporte.
En general, en el decreto se establecen los lineamientos generales de la Estrategia de
Gobierno en Línea, se reglamenta parcialmente la Ley 1341 de 2009 y se dictan otras
disposiciones. En este decreto se definen los siguientes conceptos:
25
Arquitectura Empresarial: es una práctica estratégica que consiste en analizar
integralmente las entidades desde diferentes perspectivas o dimensiones, con el
propósito de obtener, evaluar y diagnosticar su estado actual y establecer la
transformación necesaria. El objetivo es generar valor a través de las Tecnologías
de la Información para que se ayude a materializar la visión de la entidad.
Marco de Referencia de Arquitectura Empresarial para la gestión de Tecnologías
de la Información: es un modelo de referencia puesto a disposición de las
instituciones del Estado colombiano para ser utilizado como orientador estratégico
de las arquitecturas empresariales, tanto sectoriales como institucionales. El
marco establece la estructura conceptual, define lineamientos, incorpora mejores
prácticas y orienta la implementación para lograr una administración pública más
eficiente, coordinada y transparente, a través del fortalecimiento de la gestión de
las Tecnologías de la Información.4
Adicionalmente se tienen en cuenta los siguientes componentes, instrumentos y
responsables:
TIC para Servicios: comprende la provisión de trámites y servicios a través de
medios electrónicos, enfocados a dar solución a las principales necesidades y
demandas de los ciudadanos y empresas, en condiciones de calidad, facilidad de
uso y mejoramiento continuo.
TIC para el Gobierno abierto: comprende las actividades encaminadas a fomentar
la construcción de un Estado más transparente, participativo y colaborativo
involucrando a los diferentes actores en los asuntos públicos mediante el uso de
las Tecnologías de la Información y las Comunicaciones.
TIC para la Gestión: comprende la planeación y gestión tecnológica, la mejora de
procesos internos y el intercambio de información. Igualmente, la gestión y
aprovechamiento de la información para el análisis, toma de decisiones y el
mejoramiento permanente, con un enfoque integral para una respuesta articulada
de gobierno y para hacer más eficaz la gestión administrativa entre instituciones
de Gobierno.
Seguridad y privacidad de la Información: comprende las acciones transversales a
los demás componentes enunciados, tendientes a proteger la información y los 4 https://www.cancilleria.gov.co/sites/default/files/Normograma/docs/decreto_2573_2014.htm
26
sistemas de información, del acceso, uso, divulgación, interrupción o destrucción
no autorizada.
MARCO CONCEPTUAL
2.3. Arquitectura Empresarial Para empezar a entender la Arquitectura Empresarial, se plantea la analogía con un
carro, analogía propuesta por Enterprise Architects5, organización enfocada en la
disciplina de la Arquitectura Empresarial. La analogía es la siguiente: una empresa se
asimila a un carro en marcha, en el que quien conduce es el director general y el consejo
administrativo. El destino del vehículo es un punto específico, para el ejemplo, y
parafraseando un poco el texto de Enterprise Architects, el vehículo se dirige de Medellín
a Bogotá, y lleva una encomienda en el maletero. Sus directores tienen unos paneles de
control dentro del carro, donde pueden ver el consumo de gasolina, de aceite, y el estado
de cualquiera de las herramientas que permiten que funcione bien el coche (la empresa).
Por otro lado, también manejan las velocidades del auto, en inclinaciones curvas, en
rectas, bajadas, pendientes inclinadas y demás. De la misma manera ocurre con los
consejos que conducen las empresas a través de indicadores organizacionales. En esta
analogía del auto tenemos a los trabajadores en la parte de atrás del coche (como si
fuesen pasajeros), tecnología para hacerlo funcionar (motor, embrague, cambios, etc.) y
por otro lado, los procesos. Estos procesos se asemejan con el estado de la carretera;
por ejemplo bajar la velocidad si llueve o hay neblina. En síntesis, personas, procesos y
tecnología serán los que van a concebir que la empresa llegue a su objetivo y son esas
tres partes, en su articulación y su buen funcionamiento en las que se concentra la
Arquitectura Empresarial, de manera que, en consecuencia, la integración de las partes
consiga aprovechar al máximo las capacidades de toda la empresa.
The Open Group, ha planteado definiciones simples que permiten definir Arquitectura
Empresarial:
5 Ver http://enterprisearchitects.com/
27
Empresa: colección de organizaciones que tienen en común unos objetivos y
metas.
Arquitectura: forma de organizar algo que comprende componentes y relaciones.
Arquitectura Empresarial: organización lógica para el control de los procesos de
negocio y de la infraestructura de tecnologías de información que consigue una
integración y estandarización de requerimientos para el modelo operacional de la
empresa.
Pero, ¿por qué EA? Porque necesitamos que el componente de Negocios y el de TI se
lleven bien, que vayan de la mano, sepan integrar personas, tecnología y procesos para
obtener beneficios para la organización en ambos componentes.
2.4. TOGAF En la EA se habla de cuatro dominios: negocio, aplicaciones, datos y tecnología.
TOGAF6 une aplicaciones y datos y lo llama información, por lo que habla solo de tres
dominios: negocio, información y tecnología. Dentro de los dominios hay subdominios,
por ejemplo, en “arquitectura de negocio” se encuentran los siguientes: requerimientos,
reglas, estructura, misión, visión, valores, objetivos, etc. En “tecnología” se encuentran
los siguientes: servidores, networking, sistemas operativos y en “aplicaciones” están las
bases de datos, la integración de las mismas, la calidad, el modelado y demás. Pero en
general los subdominios establecidos dependen de cada empresa.
Figura 5. Dominios de la Arquitectura Empresarial Iasa. Fuente: Iasa Spain chapter – Visión general a TOGAF. Recuperado de https://www.youtube.com/watch?v=IkwhohbBwG0 el 20 de febrero de 2015
6 TOGAF: The Open Group Architect Framework
28
Actualmente existen muchos frameworks de EA en el mercado. En el presente estudio se
implementa TOGAF, pero no está de más mencionar el trabajo de John A. Zachman,
creador del framework de la EA, quien en su artículo “A Framework for Information
Systems Architecture” de 1987 definió la EA y elaboró un modelo para ella. Pero dicho
modelo es más bien clasificación de documentación, más que un framework que facilite
modelos o procesos para EA. No así TOGAF que sí cuenta con el ciclo ADM, razón por
la cual es más utilizado. No obstante, se considera a Zachman como precursor emblema
de la EA.
¿Qué es TOGAF y por qué debe implementarse?
TOGAF es una metodología y un framework que sirve para que todos los que estén
vinculados al proyecto empresarial hablen el mismo lenguaje de la metodología en la EA.
TOGAF no tiene propietario, ahorra dinero, ahorra tiempo. Es un método de eficacia
probada durante años, además cuenta con recursos para que se pueda usar libremente y
el retorno de la inversión sea rápido y confiable.
Por estas razones será el framework que se empleará en el desarrollo del presente
estudio, ya que tiene componentes variados y de una multiplicidad favorable. TOGAF
aplica una metodología (ciclo ADM), una forma de documentar: Architect conten
framework, framework, referencias de modelos, guías y técnicas.
Figura 6. TOGAF. Fuente: Iasa Spain chapter – Visión general a TOGAF. Recuperado de https://www.youtube.com/watch?v=IkwhohbBwG0 el 20 de febrero de 2015
29
Open Group presenta el marco de Arquitectura Empresarial mostrado en la figura anterior
que está compuesto por siete partes. La primera no se detalla en la figura porque
corresponde a definiciones que utilizan a lo largo de toda la documentación de TOGAF.
La segunda es el método de desarrollo y arquitectura (ADM), uno de los núcleos
centrales de esta investigación. La EA se desarrolla con el mencionado ciclo. Más
adelante se detalla su proceso en el apartado sobre la metodología a implementar. En la
tercera parte, ADM Guidelines & techniques, se encuentran las guías y las técnicas para
gestionar ese ciclo de la arquitectura ADM, en otras palabras, consiste en un análisis
para saber en dónde se encuentra el proyecto y hacia dónde se dirige.
Luego, en la parte cuatro denominada Architecture Content Framework se gestiona toda
la documentación que se va a generar. TOGAF lleva a cabo la clasificación con
diagramas, matrices y catálogos que llevan a crear herramientas llamadas “artefactos”.
Esos artefactos llevan a concebir los “entregables” (deliverables) y todos ellos se
construyen a partir de los building blocks, las partes fundamentales que se van a
construir. TOGAF cuenta con unas plantillas de diagramas, matrices, catálogos,
entregables y artefactos para facilitar este trabajo.
La quinta parte es las herramientas. Enterprise continuum clasifica la documentación del
ADM y se ubica en un repositorio de arquitecturas para hacer uso de ellas en sucesivos
ciclos de ADM, ciclos continuos que se van a repetir en diferentes niveles estratégicos
de la empresa, sin repetir building blocks ni entregables y así poder hacer uso de todo lo
que se ha construido con anterioridad. La parte sexta de TOGAF, reference model, se
socia al framework de contenidos; TOGAF nos da dos modelos de referencia: TRM y III-
RM (Technical Reference Model y el Integrated Information Infraestructure Reference
Model) de tal manera que permiten que la documentación de la empresa tenga esos
modelos de referencia y a partir de ahí se puede construir la arquitectura. Pero hay
compañías que tienen modelos ya construidos de años anteriores o que utilizan solo
parte de ellos.
30
A través de los modelos de referencia se clasifica en lo que se denomina el Enterprise
Continuum, es un concepto lógico dividido en dos partes: el continuum de arquitectura y
el continuum de soluciones, pero se puse usar otro, depende de la compañía.
Finalmente la séptima parte del framework TOGAF, Architecture Capability Framework,
puede ser considerado como un meta framework debido a que contiene la forma de
gestionar la EA, es decir, es la forma de administrar la EA que proporciona TOGAF.
Todo ello gestionando el Enterprise continuum y el repositorio de arquitectura.
TOGAF no es obligatorio en ninguna de sus partes, sino que se acompaña el proceso y
brinda posibilidades para que quien ejecute el proyecto elija cómo usarlo.
2.5. Método de desarrollo de la arquitectura (ADM) La metodología que se implementa en la presente investigación, es el Architecture
Development Method (Método de desarrollo de la arquitectura), propuesto bajo el marco
de referencia TOGAF y descrito a continuación. En la figura que se presenta a
continuación se muestra gráficamente la metodología a aplicar.
Figura 7. Architecture development method. Fuente: Imagen tomada del sitio web: http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/adm.png
31
2.5.1. Fase Preliminar Se parte de una fase preliminar que activa el inicio de la EA en la compañía (principios,
mandato de la dirección general, especificación sobre con qué framework se trabajará).
Por eso en la figura, la fase “preliminary” está fuera de los ocho círculos que conforman
las fases del desarrollo de la metodología, porque la fase preliminar se realiza
únicamente al empezar a aplicar la metodología y no se vuelve a pasar por ella, sino que
se pasa de una fase de ADM a otra, entrando directamente a cualquier de ellas siempre
y cuando se haya pasado por la gestión de requerimientos (fase central).
2.5.2. Visión de la arquitectura En la fase a hay que definir los stakeholders, la visión de la EA y desarrollar el
documento de visión de arquitectura para poder proporcionar una guía general de los
cambios que se llevarán a cabo en la organización. En otras palabras, en esta fase de
visión se establece la fase 1, o fase conceptual, mencionada anteriormente, del proceso
de desarrollo de software, se elabora el contexto de lo desarrollará, es decir el caso de
negocio. Además se define la motivación para llevar a cabo el proyecto, se precisan los
objetivos, misión, visión y demás.
2.5.3. Arquitectura de negocios, sistemas de información y tecnología
Posteriormente tenemos tres fases diferentes en el diagrama: la fase b, c y d. Pero son
etapas que generalmente van de la mano, razón por la cual en el presente documento se
sintetizan en una sola fase. Dentro de esta se lleva a cabo el desarrollo de la arquitectura
a nivel de negocio, de sistemas de información y de tecnología. Pudieron ser cuatro
dominios pero TOGAF los resume en esos tres, pues fusiona en la fase c dos dominios
distintos: datos y aplicaciones, dándole el nombre de fase de información.
En estas tres fases se desarrolla la línea base de arquitectura (AS-IS Architecture) y la
arquitectura final (es decir, la arquitectura objetivo de la iniciativa de EA, TO-BE
Architecture) para cada dominio de arquitectura (negocio, datos, aplicaciones y
tecnología). Tras realizar las arquitecturas AS-IS y TO-BE, se debe realizar el gap
32
analysis entre ambos para producir la hoja de ruta de arquitectura (Roadmap
Architecture) y así llegar a la arquitectura objetivo.
El entregable principal de esta etapa es el documento de definición de arquitectura
(deliverable). Este documento contiene los artefactos arquitectónicos básicos creados
durante el proyecto y toda la información importante relacionada. El documento de
definición de arquitectura abarca todos los dominios de la arquitectura (negocios, datos,
aplicaciones y tecnología) y también examina todos los estados relevantes de la
arquitectura (línea base AS-IS, transición y destino TO-BE).
2.5.4. Oportunidades y soluciones En la fase e denominada “Oportunidades y soluciones” se define la planificación inicial
para la puesta en marcha de la arquitectura objetivo, se identifican y agrupan los
principales paquetes de trabajo necesarios, así como las posibles arquitecturas de
transición (es decir, arquitecturas intermedias hacia la arquitectura objetivo). Además,
debe definirse la estrategia de alto nivel para la implementación y la migración a la
arquitectura TO-BE.
2.5.5. Planeamiento de migración En la fase f, después de que se definen la solución de arquitectura, se definen e
implementan paquetes de trabajo (de qué forma trabajará) con oficinas de proyecto
(PMO) para definir también las arquitecturas intermedias en la fase de migración. En la
EA si se quiere conseguir el AS-IS al TO-BE, se tienen que definir pasos intermedios que
puede ser técnicas de gestión de planificación de proyectos PMP, y dependiendo del
proyecto se utilizan metodologías, por ejemplo de software RUP.
En esta fase, los proyectos de migración identificados en la etapa anterior son
priorizados. Para ello, se debe realizar la evaluación costo/beneficio, análisis de riesgo y
la asignación del valor para el negocio que se obtiene con ellos. Además, la hoja de ruta
de arquitectura debe ser confirmada, el documento de definición de arquitectura debe ser
actualizado y el plan de implementación y migración debe ser finalizado.
33
2.5.6. Implementación de gobierno En esta fase g, se confirma y supervisa el alcance y las prioridades de los proyectos de
implementación. También se realizan las revisiones de cumplimiento de EA, así como las
revisiones de post-implementación para validar cualquier proyecto respecto a la
arquitectura definida.
2.5.7. Desarrollo y mantenimiento de Arquitectura Empresarial En la fase h se revisa que la arquitectura resultante alcance el valor para el negocio que
se había establecido como objetivo. Además, también deben estar establecidos los
procedimientos necesarios para poder gestionar el cambio, tanto el proceso para la
implementación del cambio como el seguimiento y la gestión de riesgos.
2.5.8. Gestión de requerimientos La fase del centro, la “gestión de requerimientos”, que está en el centro de la figura
planteada, es una fase que afecta a todas las fases del ciclo ADM, porque en cualquier
fase se puede hacer una petición de requerimientos y se va a tener que evaluar y
gestionar.
Esa es una visión general del ciclo ADM que es la parte fundamental de TOGAF. Todo lo
anterior se puede definir en el siguiente gráfico. (Figura 8)
34
Figura 8. TOGAF, ADM. Fuente: Iasa Spain chapter – Visión general a TOGAF. Recuperado de
https://www.youtube.com/watch?v=IkwhohbBwG0 el 20 de febrero de 2015
1) Conseguir la involucración y compromiso de la organización.
2) Conseguir la arquitectura correcta.
3) Desarrollar el trabajo de arquitectura.
4) Mantener el proceso en marcha.
2.6. Otros conceptos A continuación se plantean algunos conceptos importantes destacados en la metodología desarrollada.
Identificación de objetivos SMART
Identificación objetivos claros y medibles tipo SMART (Figura5) para el desarrollo del proyecto.
Figura 9. Objetivos SMART. Fuente: imágen tomada del sitio web http://nuriasamper.com/marcate-
objetivos-smart-y-establece-tus-kpis-part-1/
S-Specific (Específico): la ambigüedad nunca ha servido para establecer
buenas metas, el ser específico nos permite reducir las áreas grises y mantener
nuestro enfoque durante el proceso. Es importante tener claro el “porqué” se
desea cumplir ese objetivo, el “dónde” se va a llevar a cabo y “cuáles” son los
elementos que se van a requerir.
35
SIT
Objetivo primer nivel
Objetivo segundo nivel
Objetivo tercer nivel
Objetivo segundo nivel
Objetivo tercer nivel
Objetivo primer nivel
Objetivo segundo nivel
Objetivo tercer nivel
M-Measurable (Medibles): ya lo dijo Peter Drucker “lo que no se mide no se
mejora”, por tanto el establecer un indicador de éxito en nuestros objetivos nos
permitirá saber que tan cerca estamos del resultado final.
Attainable (Alcanzable): al considerar si una meta es alcanzable y realista
podemos identificar qué tipo de habilidades, actitudes u otro tipo de recursos
necesitamos para cumplirlas.
R –Relevant (Relevante): quiere decir que está relacionada con una visión o un
plan maestro ya sea de vida o de negocio.
T -Time Bound- (En un marco de tiempo y con una fecha límite): si no
establecemos un límite de tiempo nuestras tareas y proyectos pueden
prolongarse por tiempo indefinido.
Teniendo en cuenta para la identificación de estos objetivos tipo SMART, el detalle de
cada uno de los objetivos planteados (Figura 10).
Figura 10. Especificación objetivos SIT. Fuente: Elaboración propia.
Los objetivos de primer nivel expuesto en la Figura 6, ya se encuentran planteados por la
Secretaría Distrital de movilidad:
a) Aumento de la movilidad.
b) Mejorar la percepción del ciudadano.
c) Mejorar la seguridad vial.
36
Se busca especificar al mayor detalle posible cada uno de ellos, con el fin de que
cumplan las cualidades de un objetivo SMART y sea posible determinar el procedimiento
concreto para su cumplimiento.
37
3
DESARROLLO DE LA METODOLOGÍA
En este capítulo se presenta el desarrollo de la metodología propuesta. El proyecto se
ejecutará hasta la fase d establecida en la metodología (2.5.1. Fase preliminar, 2.5.2.
Visión de la arquitectura y 2.5.3. Arquitectura de negocios, sistemas de información y
tecnología). Inicialmente se realiza la fase preliminar y la fase de visión de la arquitectura,
en las cuales se da inicio a la EA y se establece la fase conceptual del proceso de
desarrollo de software, se define el contexto y la motivación para llevar a cabo el
proyecto, se precisan los objetivos, misión, visión y demás. Continuando con el desarrollo
de la metodología se presenta la implementación de las fases siguientes: fases b, c y d:
arquitectura de negocios, sistemas de información y tecnología respectivamente. En
estas tres fases se desarrolla la línea base de arquitectura (AS-IS Architecture) y la
arquitectura final (es decir, la arquitectura objetivo de la iniciativa de EA, TO-BE
Architecture) para cada dominio de arquitectura (negocio, datos, aplicaciones y
tecnología). Tras realizar las arquitecturas AS-IS y TO-BE, se realiza el gap analysis o
análisis de las deficiencias entre ambos y así llegar a la arquitectura objetivo.
Como se mencionó anteriormente la metodología utilizada en el desarrollo de esta
investigación es el método ADM propuesto por TOGAF diseño de la Arquitectura
Empresarial bajo el marco de referencia TOGAF, siguiendo la metodología propuesta por
el mismo denominada ADM y detallada anteriormente. A partir de este documento la
Secretaría Distrital de Movilidad podrá corroborar el proceso que están manejando
actualmente en el desarrollo del SIT, comparar resultados y aplicar la metodología en las
siguientes fases del proyecto, si así lo desea. Cabe resaltar que el objeto del proyecto se
38
limita exclusivamente a la primera fase del desarrollo e implementación del SIT para
Bogotá (Fases establecidas por la Secretaría Distrital de Movilidad).
En el desarrollo de la metodología no se tuvo en cuenta significativamente los
documentos generados después de dar inicio a la fase a de la metodología empleada
(ADM): Visión de la arquitectura, puesto que en ese momento ya se contaba con la
información necesaria para la puesta en ejecución del presente proyecto, recopilada en
las tres entidades involucradas (SDM, ETB y La UD).
Para la obtención de la información se ha asistido permanentemente a reuniones con las
tres entidades en el periodo comprendido desde el 15 de diciembre de 2014 hasta la
fecha. Desde el 15 de diciembre de 2014 hasta el 15 de enero de 2015, la Universidad
Distrital recibió los siguientes documentos por parte de la Secretaría Distrital de
Movilidad, los cuales fueron fuente de información útil para el presente estudio:
Plan estratégico para la implementación del ITS de Bogotá. Documento preliminar
de discusión. Versión 2. Noviembre de 2013.
Definición de los servicios y funcionalidades asociadas al Sistema Inteligente de
Transporte – SIT para Bogotá. Versión 1.01. Diciembre 20 de 2103.
Centro de gestión de tráfico urbano diseño de adecuación e implementación -
funcionalidades del centro de gestión de tránsito. Versión 3. Octubre de 2014.
Operación y funcionalidades del centro de gestión del tránsito para la ciudad de
Bogotá D.C en el marco del sistema inteligente de transporte. Versión 3. Octubre
de 2014
Operación y funcionalidades del centro de gestión del tránsito para la ciudad de
Bogotá D.C en el marco del sistema inteligente de transporte. Versión 2.
Noviembre de 2014.
Proyecto SIT Bogotá- Centro de gestión alterno. Enero de 2015.
Por otra parte, en el periodo de elaboración de este estudio, representantes del equipo
de interventoría asistieron a la 7ma feria Andina Traffic 2015, llevada a cabo el 16 y 17 de
marzo de 2015, asistiendo a las conferencias allí impartidas, con especial atención en la
conferencia “DATEX II Hacia la homogenización de servicios de los ITS” llevada a cabo
por el PhD. Luis Felipe Herrera, quien actualmente es docente en Bogotá. Y en la
39
conferencia “Impacto en la calidad de diseño en la eficiencia operativa de proyectos ITS”
por el Prof. Ing. Klaus Banse.
3.1 Propósito del documento La Solicitud de Trabajo de Arquitectura, en el contexto de TOGAF, es un documento que
comunica el inicio de un ciclo de desarrollo de arquitectura. En él se consolidan
diferentes aspectos preliminares que desde un alto nivel establecen un fundamento para
el ejercicio de arquitectura a ser realizado.
Este documento contiene la descripción del contexto sobre el cual se desarrollará este
trabajo de arquitectura, señalando el alcance que tendrá a nivel organizacional. De igual
manera, recopila los marcos de gobierno y soporte que enmarcan este ejercicio, para
luego establecer la estructura del equipo de trabajo encargado de llevarlo a cabo. Dicho
esfuerzo también está soportado en una serie de principios que actúan como guías
durante su ejecución. Lo cuales, una vez expuestos, dan lugar a la adaptación del marco
de referencia TOGAF escogido para este proyecto. Por último, se plantean alternativas
sobre las herramientas de arquitectura que pueden ser empleadas en este trabajo para
mantener el repositorio de Arquitectura Empresarial con los respectivos modelos que
surjan.
3.2. Alcance El alcance del ejercicio de Arquitectura Empresarial aparece descrito a partir de tres criterios:
Amplitud: indica a nivel de la estructura organizacional del proyecto. Qué áreas
funcionales se ven involucradas/impactadas por los resultados del ejercicio.
Dominios: establece cuales son los aspectos a evaluar como parte del
Diagnóstico de Arquitectura Empresarial.
Profundidad: hace referencia a con qué nivel de detalle se llevarán a cabo las
tareas inmersas en el ejercicio.
3.2.1. Amplitud
40
Teniendo en cuenta el objetivo general del ejercicio, aparecen los macro procesos
actuales que lleva a cabo la Secretaría Distrital de Movilidad para poder ejecutarlos,
estos macro procesos los podemos ver en la siguiente figura (tabla 1):
Tabla 1. Macro procesos actuales. Fuente: Elaboración de la Secretaría Distrital de Movilidad
3.2.2. Dominio
Los dominios de Arquitectura asociados a la expectativa planteada por el objetivo general
del ejercicio son:
41
Figura 11. Dominios de arquitectura. Fuente: Elaboración propia.
3.2.3. Profundidad Para definir el nivel de profundidad, con el cual se llevará a cabo las tareas de análisis y
diagnóstico inmersas en el ejercicio, se hace una asociación entre los niveles de
definición de los procesos de una organización que plantea el estándar ISO 14813-
1:2007 en referencia la información disponible en los insumos del ejercicio asociados a
los macro procesos misionales del SIT:
ISO 14813-1:2007
• Nivel 1 - Servicios de dominio
• Nivel 2 - Arquitectura de referencia TICS
• Nivel 3 - Requerimientos para la descripción de la arquitectura.
• Nivel 4 - Modelo de referencia
• Nivel 5 - Elaboración
Figura 12. Estándar ISO 14813-1:2007. Fuente: Elaboración propia
Negocio
Técnología
Dominios de Arquitectura
Datos
Aplicaciones
42
ISO 14813-1: 2007 es asesor e informativo. Está diseñado para ayudar a la integración
de los servicios en una arquitectura de referencia cohesiva, ayudar a la interoperabilidad
y la definición de datos común. En concreto, los servicios definidos dentro de los grupos
de servicio serán la base para la definición de casos de uso y la funcionalidad de la
arquitectura de referencia resultante, junto con la definición de los datos de aplicación,
según los diccionarios de datos, así como las comunicaciones aplicables y normas de
intercambio de datos.7
Como lo muestra la figura, el nivel de profundidad considerado serán los objetivos del SIT
y los procedimientos que se desarrollarán para llevar a cabo el proyecto.
3.3. Metas, objetivos y limitaciones En asocio con los objetivos del ejercicio, aparecen también una serie de factores que a
nivel organizacional plantean objetivos y restricciones a ser tenidos en cuenta por parte
del equipo de Arquitectura Empresarial durante la ejecución de las fases del diagnóstico.
A continuación se detallan estos factores.
3.3.1. Objetivos a nivel organizacional A nivel organizacional aparece un gran objetivo centrado en la adopción de los principios
derivados del gobierno en línea8 del país:
7 Tomado de https://www.iso.org/obp/ui/#iso:std:iso:14813:-1:ed-1:v1:en
8 http://programa.gobiernoenlinea.gov.co
43
Principios derivados del gobierno en línea
Figura 13. Objetivo Organizacional: Adoptar los Principios del Gobierno en Línea. Fuente:
Elaboración propia.
3.3.2. Objetivos de negocio y tecnología El siguiente diagrama presenta los objetivos que serán objeto del presente ejercicio de
Arquitectura Empresarial:
Principios de
Negocio
Principios de
Aplicaciones
Principios de
Tecnología
Principios de
Datos
Figura 14. Árbol de objetivos del SIT. Fuente: Elaboración propia.
En el anexo A, se muestra la tabla que presenta los objetivos mencionados con las
respectivas referencias a los insumos que los describen.
3.3.3. Stakeholders A continuación se presentan los stakeholders del proyecto SIT.
Figura 15. Matriz de stakeholders del SIT. Fuente: Elaboración propia. Adaptado de http://pubs.opengroup.org/architecture/togaf9-doc/arch/
3.3.4. Restricciones a nivel organizacional Las restricciones más relevantes asociadas al ejercicio de Arquitectura de Empresarial
son:
1. Cada proceso misional es operado por áreas funcionales específicas que no son
transversales al que hacer de toda la organización.
46
2. No hay un repositorio centralizado y estructurado de insumos para el ejercicio.
Las fuentes oficiales son:
Intranet
Portal
Información enviada por la SDM, por correo electrónico.
Información enviada por la Empresa de Telecomunicaciones de Bogotá ─
ETB, por correo electrónico.
Información generada por el grupo de trabajo interventor de la Universidad
Distrital Francisco José de Caldas.
Reuniones de trabajo con los stakeholders y áreas respectivas.
3.3.5. Capacidades Con el ánimo de conocer el grado de preparación que tienen la Secretaría Distrital de
Movilidad, para dar cumplimiento a las nuevas directrices nacionales en torno al gobierno
electrónico (objetivos a nivel organizacional) y en general para abordar los nuevos
desafíos que plantean las transformaciones requeridas a raíz del ejercicio de Arquitectura
Empresarial, se lleva a cabo una evaluación inicial tomando como referencia el “The
Open Group Service Integration Maturity Model (OSIMM)”9, que especifica la forma de
medir los niveles de integración de servicios de una organización a partir de una serie de
dimensiones:
9 http://www.opengroup.org/soa/source-book/osimmv2/model.htm
47
Figura 16. Modelo de Madurez de integración de Servicios de Open Group
3.3.5.1. Dimensión de negocio Se puede observar en la documentación oficial enviada por la Secretaría Distrital de
Movilidad “Definición de Servicios y Funcionalidades asociadas al Sistema Inteligente de
Transporte ─ SIT para Bogotá” y “ Plan estratégico para la implementación del SIT de
Bogotá”, que algunos procesos misionales carecen de procedimientos, tiene asociados
lineamientos técnicos que a su vez contienen herramientas, pero este tipo de información
48
no permite realizar un seguimiento paso a paso de la trazabilidad de los procesos. Esto
permite determinar que el nivel que posee la dimensión de negocio es de 1 o Silo.
3.3.5.2. Dimensión de información En la información asociada a la dimensión de datos y aplicaciones permite concluir lo
siguiente:
No se cuenta con un vocabulario de datos común.
La arquitectura de información no tiene un modelo maestro de datos que
implemente un vocabulario de datos común.
La información se replica y es redundante.
No se cuenta con modelo conceptual de información empresarial.
Esto permite determinar que el nivel que posee la dimensión de datos es de 1 o Silo.
3.3.5.3. Dimensión de tecnología La información provista para la dimensión de tecnología permite concluir lo siguiente:
La infraestructura de TI no soporta requisitos, ni acuerdos de nivel de servicio
(SLAs)10 a nivel no funcional y operativo necesarios para operar un entorno SOA.
Poco apoyo operativo o inexistente para el despliegue de servicios.
Esto permite determinar que el nivel que posee la dimensión de tecnología es de 1 o Silo.
3.4 Compliance A continuación se precisa el aspecto legal del proyecto.
Cabe aclarar que se emplea el término Compliance debido a que es la palabra utilizada
en las plantillas y entregables asignados a la metodología ADM11 y su traducción exacta
no corresponde con el significado dentro del proyecto. A lo que se refiere el término,
dentro de este contexto, es al contenido legal del documento, el cual se explica a
continuación.
10
http://www.sla-zone.co.uk/ 11
Ver http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap36.html
49
3.4.1. Principios de arquitectura Los principios son normas de carácter general, directrices, destinadas a ser duraderas y
rara vez modificadas. Los principios informan y apoyan la forma en que la organización
se enfoca sobre el cumplimiento de su misión. La definición de estos principios para la
arquitectura orienta las decisiones de diseño e implementación, y deben ser
considerados como uno elementos, dentro del conjunto estructurado de ideas, que
definen colectivamente y guían el ejercicio de la arquitectura. (Anexo B).
Dependiendo de la organización, los principios pueden ser establecidos en cualquiera o
todos los niveles:
Principios organizacionales: proporcionan una base para la toma de decisiones en
toda la organización e informan cómo establece el cumplimiento de su misión. En
particular, son un elemento clave en una estrategia de gobernabilidad de las
arquitecturas.
Principios por dominios: son aquellos pertinentes a dominios dentro de la
organización y que nutren, guían las definiciones en cada uno de los dominios:
Negocio, Datos, Aplicaciones, Tecnología.
3.4.1.1. Contexto de gobierno en línea Para las entidades estatales colombianas desde el Ministerio de las TICs se ha planteado
un marco de referencia de arquitectura de TI dentro del programa de Gobierno en Línea12
estableciendo los siguientes principios de arquitectura en cada uno de sus dominios:
12
Gobierno en línea colombiano es un programa liderado por el Ministerio de TICs para normalizar y elevar el grado de apropiación de las TICs en las entidades estatales: http://programa.gobiernoenlinea.gov.co para habilitar iniciativas como dar apertura a datos públicos, Implementar la iniciativa cero papel, automatizar trámites y servicios, crear ventanillas únicas, abrir espacios de participación, fortalecer los medios de comunicación bidireccional con el ciudadano.
50
A. Principios de Negocio del Gobierno en Línea de Colombia.
B. Principios de Datos del Gobierno en Línea de Colombia.
C. Principios de Aplicaciones del Gobierno en Línea de Colombia.
D. Principios de Tecnología del Gobierno en Línea de Colombia.
3.3.5.4. Base conceptual definida por TOGAF para los principios de arquitectura “Los principios de arquitectura están relacionados al trabajo de arquitectura. Reflejan el
nivel de consenso a través de la organización y encarnan el espíritu y pensamiento de los
principios organizacionales”.13
Los principios de Arquitectura pueden categorizarse en principios que rigen el proceso de
la Arquitectura Empresarial, lo que afecta el desarrollo, mantenimiento y uso de la
arquitectura en la organización y los principios que rigen la aplicación de la arquitectura.
A. Características de los principios de arquitectura
Los principios de Arquitectura definen las normas y directrices generales que guían el
diseño y la evolución de las arquitecturas. Son el reflejo de un nivel de consenso
entre los diversos elementos de la empresa, y constituyen la base para la toma de
futuras decisiones.
Cada principio arquitectura está claramente relacionado los objetivos de negocio y los
elementos conductores o motivadores principales de la práctica de la AE.
a. Componentes de los Principios de Arquitectura
b. Desarrollo de los principios de arquitectura
c. Criterios que distinguen a un buen conjunto de principios:
d. Completos
e. Consistentes
f. Estables
g. La aplicación de los Principios de Arquitectura
13
Tomado del Libro TOGAF V.9.1. Capítulo 23 Sección 1.
51
3.4.1.2. Principios de Arquitectura Empresarial
A. Primacía de los principios
B. Alineamiento estratégico
C. Respetar los estándares organizacionales y cumplimiento de los marcos
normativos vigentes.
3.3.5.5. Principios de arquitectura de negocio
A. Cumplimiento de la Ley
B. Calidad de los servicios
C. Alineamiento a los procesos de negocio de las iniciativas de TICs.
D. Maximizar los beneficios para el cumplimiento de la misión para el SIT
E. Continuidad del Negocio
F. Orientación a servicios
3.3.5.6. Principios de arquitectura de aplicaciones La arquitectura de aplicaciones y la de datos están inmersas dentro de la arquitectura de
sistemas de información
A. Facilidad de uso
B. Basadas en componentes
C. Interoperabilidad
D. La arquitectura de las aplicaciones son: extensibles, escalables y adaptables.
3.3.5.7. Principios de arquitectura de datos La arquitectura de datos junto con la de aplicaciones está inmersa dentro de la
arquitectura de sistemas de información
52
A. El dato es un activo organizacional
B. El dato se comparte
C. El dato es accesible
D. El dato es seguro
3.3.5.8. Principios de arquitectura de tecnología Los principios para la arquitectura en el dominio de tecnología, cubre los elementos o
componentes del software de base, infraestructura de servidores y dispositivos de
telecomunicaciones
A. Cambios basados en necesidades del SIT
B. Interoperabilidad tecnológica
C. Consideración a estándares del mercado
3.4.2. Políticas y normas
3.4.2.1. Decreto 2573 del 12 de diciembre de 2014 Por el cual se establecen los lineamientos generales de la Estrategia de Gobierno en
Línea, se reglamenta parcialmente la Ley 1341 de 2009 y se dictan otras disposiciones.
Cuyo objeto es Definir los lineamientos, instrumentos y plazos de la estrategia de
Gobierno en Línea para garantizar el máximo aprovechamiento de las Tecnologías de la
Información y las Comunicaciones, con el fin de contribuir con la construcción de un
Estado abierto, más eficiente, más transparente y más participativo y que preste mejores
servicios con la colaboración de toda la sociedad.
A. Definición de conceptos
a. Arquitectura Empresarial
Es una práctica estratégica que consiste en analizar integralmente las
entidades desde diferentes perspectivas o dimensiones, con el propósito
de obtener, evaluar y diagnosticar su estado actual y establecer la
53
transformación necesaria. El objetivo es generar valor a través de las
Tecnologías de la Información para que se ayude a materializar la visión
de la entidad.
b. Marco de Referencia de Arquitectura Empresarial para la gestión de
Tecnologías de la Información
Es un modelo de referencia puesto a disposición de las instituciones del
Estado colombiano para ser utilizado como orientador estratégico de las
arquitecturas empresariales, tanto sectoriales como institucionales. El
marco establece la estructura conceptual, define lineamientos, incorpora
mejores prácticas y orienta la implementación para lograr una
administración pública más eficiente, coordinada y transparente, a través
del fortalecimiento de la gestión de las Tecnologías de la Información.14
B. Componentes instrumentos y responsables
a. TIC para Servicios
Comprende la provisión de trámites y servicios a través de medios
electrónicos, enfocados a dar solución a las principales necesidades y
demandas de los ciudadanos y empresas, en condiciones de calidad,
facilidad de uso y mejoramiento continuo.
b. TIC para el Gobierno abierto
Comprende las actividades encaminadas a fomentar la construcción de
un Estado más transparente, participativo y colaborativo involucrando a
los diferentes actores en los asuntos públicos mediante el uso de las
Tecnologías de la Información y las Comunicaciones.
c. TIC para la Gestión
Comprende la planeación y gestión tecnológica, la mejora de procesos
internos y el intercambio de información. Igualmente, la gestión y
aprovechamiento de la información para el análisis, toma de decisiones y
el mejoramiento permanente, con un enfoque integral para una respuesta
14
https://www.cancilleria.gov.co/sites/default/files/Normograma/docs/decreto_2573_2014.htm
54
articulada de gobierno y para hacer más eficaz la gestión administrativa
entre instituciones de Gobierno.
d. Seguridad y privacidad de la Información
Comprende las acciones transversales a los demás componentes
enunciados, tendientes a proteger la información y los sistemas de
información, del acceso, uso, divulgación, interrupción o destrucción no
autorizada.
3.4.2.2. Ley 1712 de 2014 – Ley de Transparencia y del Derecho de Acceso a la Información Pública Nacional
Con la reciente promulgación de la Ley 1712 de 2014 – Ley de Transparencia y del
Derecho de Acceso a la Información Pública Nacional, se ratifican los principios de la
gestión documental y la necesidad que tienen las entidades del Estado y los nuevos
sujetos obligados, de contar con información confiable y oportuna, fortalecer los
esquemas de publicación de información, crear y mantener actualizado el registro de
activos de información para uso y disposición del público.
En cuanto a los sujetos obligados de Ley, de conformidad con el artículo 15. “Programa
de Gestión Documental”, las directrices de este Programa serán aplicables a las
siguientes personas en calidad de sujetos obligados:
a. Toda entidad pública, incluyendo las pertenecientes a todas las Ramas del
Poder Público, en todos los niveles de la estructura estatal, central o
descentralizada por servicios o territorialmente, en los órdenes nacional,
departamental, municipal y distrital.
b. Lo órganos, organismos y entidades estatales independientes o
autónomos y de control.
c. Las personas naturales y jurídicas, públicas o privadas, que presten
función pública, que presten servicios públicos respecto de la información
directamente relacionada con la prestación del servicio público;
d. Cualquier personal natural, jurídica o dependencia de persona jurídica que
desempeñe función pública o de autoridad pública, respecto de la
información directamente relacionada con el desempeño de su función;
55
e. Los partidos o movimientos políticos y los grupos significativos de
ciudadanos;
f. Las entidades que administren instituciones parafiscales, fondos o
recursos de naturaleza u origen público.
Uno de los principales beneficios de la adopción del PGD por parte de las entidades es
facilitar el acceso y disposición al público de la información, en los términos referidos en
la Ley, a través de medios físicos, remotos o locales de comunicación electrónica.15
3.4.2.3. Ley 962 de 2005 “Ley antitrámites” Por la cual se dictan disposiciones sobre racionalización de trámites y procedimientos
administrativos de los organismos y entidades del Estado y de los particulares que
ejercen funciones públicas o prestan servicios públicos.16
La ley antitrámite tiene por objeto facilitar las relaciones de los particulares con la
Administración Pública, de tal forma que las actuaciones que deban surtirse ante ella
para el ejercicio de actividades, derechos o cumplimiento de obligaciones se desarrollen
de conformidad con los principios establecidos en los artículos 83, 84, 209 y 333 de la
Carta Política. En tal virtud, serán de obligatoria observancia algunos principios como
rectores de la política de racionalización, estandarización y automatización de trámites, a
fin de evitar exigencias injustificadas a los administrados.
3.5. Riesgos
3.5.1. Análisis de riesgos A continuación se presentan matrices de riesgos hallados y su criticidad. Las áreas
analizadas fueron las siguientes: Administración, software, hardware, infraestructura,
financiera, jurídica.
15
http://www.archivogeneral.gov.co/noticias/ley-1712-de-2014-%E2%80%93-ley-de-transparencia-y-del-derecho-de-acceso-la-informaci%C3%B3n-p%C3%BAblica 16
http://www.secretariasenado.gov.co/senado/basedoc/ley_0962_2005.html
56
3.5.1.1. Evaluación de riesgos y controles existentes Para la determinación de la matriz de riesgos se determinó el siguiente estándar:
(1) Identificador del riesgo
(2) Riesgo identificado
(3) Nivel de criticidad del riesgo
(4) Documento de trabajo en donde se evidencia la existencia del riesgo
(5) Criticidad de los riesgos: pueden clasificarse en alto, medio y bajo, se hace una
descripción de lo que sucede en caso de que exista el riesgo en cada nivel.
(6) Área analizada.
(1)
N°.
(2)
Control
(3)
Rie
sgo (5)
Criticidad de los controles
3- Alto 2- Medio 1-Bajo
(6)Administración
1 Existe una
estructura
orgánica definida
para el SIT por
parte de la SDM.
3 No está definida y
por lo tanto no se
conocen los
niveles y autoridad.
Existe, pero no está
claramente definida
Existe, está
claramente
definida y se
aplica.
2 No existe un
manual de
organización
dentro de la SDM
para el proyecto
SIT.
3 No se cumple la
estructura orgánica
Se cumple
medianamente la
estructura.
Se cumple la
estructura
orgánica a
cabalidad.
3 Planeada
segregación de
las funciones en
el equipo
encargado del
SIT.
3 Al no existir una
segregación
adecuada se
incumplen las
funciones de cada
empleado.
l departamento de
sistemas conoce
sus funciones
Cada uno de los
empleados
cumplen sus
funciones y las
conocen.
Tabla 2. Matriz de evaluación de riesgos y controles existentes en el proyecto SIT. Fuente:
Elaboración propia.
57
(1) N°.
(2) Control
(3)
Rie
sgo (5)
Criticidad de los controles
3- Alto 2- Medio 1-Bajo
(6)Software
1 ETB no presenta el componente de software en la propuesta.
3 El SIT no tendría otra funcionalidad más que visualizar lo que ya se tiene hoy en día.
Es posible construir el software y adecuarlo a la propuesta presentada.
El componente inteligente de la propuesta está bien definido.
2 El software propuesto no satisface las necesidades del SIT.
2 No son suficientes las funcionalidades propuestas en el componente de software para satisfacer el horizonte del SIT.
El software es escalable y cumple lo necesario en la primera fase del proyecto.
El software de la propuesta de ETB cubre completamente las necesidades del proyecto SIT.
3 El software propuesto no integra los componentes necesarios.
2 Al implementar software por componentes, no se tiene en cuenta la integración de los mismos e imposibilita la operación del Centro de gestión.
ETB presenta un software que permite integrar a futuro los componentes de la primera fase del proyecto y en adelante.
El software propuesto integra todos los componentes del SIT.
Tabla 3. Matriz de evaluación de riesgos y controles existentes en el proyecto SIT. Fuente:
Elaboración propia.
(1) N°.
(2) Control
(3)
Rie
sgo (5)
Criticidad de los controles
3- Alto 2- Medio 1-Bajo
(6)Hardware
1 No se tiene en cuenta los dispositivos instalados en calle.
2 En la propuesta de ETB no se presentan dispositivos como cámaras y sensores.
Se tiene en cuenta la ubicación de dispositivos en puntos estratégicos de la ciudad.
Se presenta la ubicación de todos los dispositivos que serán instalados en la primera fase del proyecto.
2 Determinación de los puntos estratégicos de la ciudad en donde estarán ubicados los dispositivos a partir de un estudio.
1 Ubicación de cámaras y sensores sin previo estudio en puntos aleatorios.
Ubicación de dispositivos en calle en puntos que no son necesariamente significativos en la movilidad.
Realización de un estudio de acuerdo a la movilidad de Bogotá para ubicar dispositivos.
Tabla 4. Matriz de evaluación de riesgos y controles existentes en el proyecto SIT. Fuente:
Elaboración propia.
58
(1) N°.
(2) Control
(3)
Rie
sgo (5)
Criticidad de los controles
3- Alto 2- Medio 1-Bajo
(6)Infraestructura
1 Distribución adecuada de espacios en el sitio destinado para el centro de gestión.
1 Falta espacio o se malgasta en algunas salas.
Es necesario redistribuir el espacio después de haber iniciado la obra.
Planeación adecuada conforme a los espacios actuales y lo que se desea instalar.
2 Planeación estratégica de puestos de trabajo
3 Puede que sobren operarios o que falten en algunos casos.
Los funcionarios de un sector deben sustituir a otros en donde hace falta personal.
Los puestos de trabajo están designados conforme a las necesidades del centro de gestión teniendo en cuenta la automatización del mismo.
3 Especial atención en aspectos de infraestructura dejando de lado el componente inteligente de la propuesta.
2 Sólo se cuenta con el sitio bien dotado pero no es posible tomar decisiones desde el puesto de control.
La toma de decisiones sigue efectuándose como estaba antes de la construcción el SIT.
El componente de software (inteligente) se ajusta exactamente a la descripción de infraestructura.
Tabla 5. Matriz de evaluación de riesgos y controles existentes en el proyecto SIT. Fuente:
Elaboración propia.
(1) N°.
(2) Control
(3)
Rie
sgo (5) Criticidad de los controles
3- Alto 2- Medio 1-Bajo
(6)Financiera
1 Los precios contemplados en la propuesta sobrepasan el presupuesto de la oferta.
1 No es posible terminar el proyecto SIT por falta de recursos.
Es necesario acortar el presupuesto en las siguientes fases y disminuir la calidad de los componentes restantes.
La propuesta financiera está acorde con el presupuesto asignado para el SIT.
2 En la oferta financiera de ETB no se tiene en cuenta el valor de los demás componentes.
2 Sólo se contempla el precio del centro de gestión pasando por alto componentes que pueden ser muy costosos como
No alcanza el presupuesto que queda después de la ejecución de la oferta para los demás componentes y
A pesar de que no se tiene en cuenta el valor de los demás componentes, tiene un costo aceptable para
59
semaforización.
fases. seguir ejecutando el proyecto.
3 No se contemplan precios de gerencia y operarios.
3 Es un costo alto que se omite y puede afectar el desarrollo del proyecto.
Se incluye dentro de otros gastos contemplados en la propuesta.
Están especificados en la propuesta presentada por ETB.
Tabla 6. Matriz de evaluación de riesgos y controles existentes en el proyecto SIT. Fuente:
Elaboración propia.
(1) N°.
(2) Control
(3)
Rie
sgo (5)
Criticidad de los controles
3- Alto 2- Medio 1-Bajo
(6)Jurídica
1 No Se especifica la propiedad de las licencias de uso de software
3 La SDM no sería la propietaria del software y además debe pagar continuas actualizaciones y licenciamientos.
La SDM es propietaria de los desarrollos a la medida y se garantiza uso a perpetuidad del software genérico adquirido.
Garantiza propiedad de la SDM de todos los productos software.
Tabla 7. Matriz de evaluación de riesgos y controles existentes en el proyecto SIT. Fuente:
Elaboración propia.
3.5.2. Matriz de hallazgos, recomendaciones y beneficios Para la determinación de la matriz de hallazgos, recomendaciones y beneficios se
determinó el siguiente estándar:
(1) Identificador del riesgo
(2) Hallazgo
(3) Nivel de criticidad del riesgo
(4) Riesgo que se corre a partir del hallazgo
(5) Recomendaciones para la mitigación del riesgo.
(6) Beneficios para el convenio si se tiene en cuenta el hallazgo y sus respectivas
recomendaciones.
(1)No. (2)Hallazgo (3)Evaluación
del Riesgo (4)Riesgo (5)Recomendaciones (6)Beneficios
Administración
1 Hace falta un conocimiento pertinente de parte de los empleados por visualizar
2 Si los empleados no conocen la estructura orgánica que el comité ejecutivo
Hacer pública y visible la estructura interna establecida, siempre y cuando ésta haya pasado por un comité de
Genera orden y garantías de eficiencia en el trabajo de la oficina, llevando a
60
la estructura de organización de la oficina asesora de sistemas.
estableció, no se llevaran a buen término las funciones y obligaciones de cada uno de los rangos existentes en la misma.
evaluación y verificación que asegure que tiene una jerarquía óptima para el desempeño de la oficina asesora de sistemas.
buen término las funciones y obligaciones de cada uno de los rangos existentes en la misma.
Software
2 La propuesta presentada por ETB NO ofrece una solución de software lo cual imposibilita que el SIT se considere inteligente.
3 Sin el componente de software lo único que se podrá llevar a cabo es la visualización de la movilidad, lo cual actualmente ya existe.
Aclarar al ofertante los requerimientos establecidos, si es necesario redefinirlos enfocados al software.
Organizar y adaptar una metodología para el establecimiento de requerimientos de software.
Hardware
3 Los dispositivos incluidos en la propuesta no tienen un previo estudio para cantidad y ubicación
2 Si no se realiza el estudio pertinente puede que sobren o falten dispositivos y no se cubran todos los puntos necesarios.
Basarse en datos estadísticos pero también realizar estudios actuales en base al software que se va a implementar para determinar cantidad y ubicación de los dispositivos.
Se maximizan beneficios y se optimiza tiempo y recursos.
Infraestructura
4 La determinación de los puestos de trabajo dentro del centro de gestión no se basa en las necesidades sino en el espacio.
3 Puede que falten o sobren operarios o puestos de trabajo dentro del centro de gestión.
Previo a ofertar un determinado número de puestos de trabajo se debe hacer la oferta del funcionamiento del centro de gestión para conocer exactamente el número de operarios necesarios.
Se maximizan beneficios y se optimiza tiempo y recursos.
Financiera
5 En la oferta presentada no se contemplan los valores de componentes importantes para la primera fase del SIT.
3 Sólo se contempla el precio del centro de gestión pasando por alto componentes que pueden ser muy costosos como
Se debe tener en cuenta el SIT con sus cuatro componentes y el componente inteligente, bien sea en una sóla propuesta o en una para cada uno.
El presupuesto planeado para el SIT es suficiente para llevar a cabo el trabajo deseado.
61
semaforización o el mantenimiento de los demás.
Jurídica
6 Se debe aclarar la propiedad de licencias de uso de software, cuando este se presente.
2 Si no se aclara, es posible que la Secretaría Distrital de movilidad deba pagar valores futuros que no fueron inicialmente presupuestados.
En los casos que sea posible, se debe ceder las licencias de uso y propiedad a la Secretaría Distrital de Movilidad, y de no ser así especificar detalladamente cómo se debe pagar las actualizaciones y licencias de software.
La Secretaría no va a tener que cancelar valores futuros en actualizaciones obligatorias de software ni en licencias de uso.
Tabla 8. Matriz de hallazgos, recomendaciones y beneficios. Fuente: Elaboración propia
3.6. Línea base de arquitectura A continuación se presenta la línea base de arquitectura (AS-IS Architecture),
enfocándose en tres principales objetivos establecidos por la Secretaría Distrital de
movilidad y mostrando cómo operan actualmente.
3.6.1. Modelo de arquitectura de negocio Para determinar la arquitectura de negocio del SIT se inicia estableciendo los principales
objetivos a los que se apunta con el proyecto, dichos objetivos se tienen en cuenta para
la arquitectura destino, puesto que los objetivos del proyecto son los mismos desde el
comienzo de la arquitectura. Continuando con la metodología de línea base, se muestra
el procedimiento conceptual y gráficamente que la Secretaría Distrital de Movilidad lleva
a cabo actualmente para cumplir estos objetivos.
3.6.1.1. Línea base de la arquitectura de negocio La Secretaría Distrital de Movilidad estableció tres objetivos principales a los cuales se
desea enfocar el Sistema Inteligente de Transporte de Bogotá: aumento de la movilidad,
mejoramiento de la percepción del ciudadano y aumento de la seguridad vial. Debido a
que estos objetivos son muy generales, en el presente proyecto se establecen tres
62
objetivos tipo SMART, generados a partir de los objetivos planteados por la Secretaría
Distrital de Movilidad:
a) Mejorar las condiciones de regulación, monitoreo y control del sistema de
movilidad.
b) Informar a los ciudadanos las condiciones de movilidad para sus decisiones de
desplazamiento.
c) Contribuir a las condiciones de seguridad vial en el sistema de movilidad.
3.6.1.2. Procedimiento conceptual de la arquitectura de negocio
a) Mejorar las condiciones de regulación, monitoreo y control del sistema de
movilidad.
Proceso actual:
Toma de aforos manuales de vehículos en estaciones maestras y por solicitudes
especiales y velocidades de punto y promedio en segmentos viales.
Operación asignada a un tercero a través de un proceso público de contratación.
Recolección manual.
Digitación y procesamiento en hojas de Excel.
Se carga en una base de datos Oracle para su explotación.
b) Informar a los ciudadanos las condiciones de movilidad para sus decisiones de
desplazamiento.
Proceso actual:
Información estática suministrada por IDU, IDECA y UMV) con software Arcgis,
base de datos Oracle, Servidores de aplicaciones, sistema de indicadores BI de
Oracle.
c) Contribuir a las condiciones de seguridad vial en el sistema de movilidad.
Proceso actual:
Información estática suministrada por IDU, IDECA y UMV con software Arcgis, base de
datos Oracle, Servidores de aplicaciones, sistema de indicadores BI de Oracle.
63
3.6.1.3. Proceso actual arquitectura de negocio A continuación se muestran gráficamente el proceso para cumplir los tres objetivos –
anteriormente descrito-, a través del software ArchiMate17 y empleando el lenguaje
UML.18
a) Mejorar las condiciones de regulación, monitoreo y control del sistema de
movilidad.
En la siguiente figura se muestra gráficamente el proceso anteriormente descrito que
cumple el objetivo planteado:
Figura 17. Arquitectura de negocio línea base - objetivo 1. Fuente: Elaboración propia
b) Informar a los ciudadanos las condiciones de movilidad para sus decisiones de
desplazamiento.
En la siguiente figura se muestra gráficamente el proceso anteriormente descrito
que cumple el objetivo planteado:
17
Ver http://www.opengroup.org/subjectareas/enterprise/archimate 18
Ver http://www.uml.org/
64
Figura 18. Arquitectura de negocio línea base - objetivo 2. Fuente: Elaboración propia
c) Contribuir a las condiciones de seguridad vial en el sistema de movilidad.
En la siguiente figura se muestra gráficamente el proceso anteriormente descrito que cumple el objetivo planteado:
Figura 19. Arquitectura de negocio línea base - objetivo 3. Fuente: Elaboración propia
65
3.6.2. Modelo de arquitectura de información En la arquitectura de información, se tiene en cuenta tanta la arquitectura de datos como
de aplicaciones, debido a que la metodología ADM así lo implementa, el proceso que se
desarrolla en esta etapa es similar a la arquitectura de negocio puesto que se estipulan
una vez más los objetivos a los que apunta el SIT, se realiza una descripción del
procedimiento conceptual de los datos y aplicaciones con los que se cuenta actualmente
para el desarrollo de este y finalmente se muestra gráficamente el proceso actual de la
arquitectura de información utilizado.
3.6.2.1. Línea base de la arquitectura de información La arquitectura de información actual del SIT se conforma de los datos y aplicaciones con
los que cuenta actualmente la Secretaría Distrital de movilidad para el cumplimiento de
los siguientes objetivos:
a) Mejorar las condiciones de regulación, monitoreo y control del sistema de
movilidad.
b) Informar a los ciudadanos las condiciones de movilidad para sus decisiones de
desplazamiento.
c) Contribuir a las condiciones de seguridad vial en el sistema de movilidad.
3.6.2.2. Procedimiento conceptual de la arquitectura de información Para el cumplimiento de los objetivos establecidos actualmente la Secretaría Distrital de
movilidad tiene en cuenta como actores principalmente los vehículos y el transporte
público, el NUSE y los ciudadanos son los encargados de suministrar información de
accidentalidad, en cuanto a la infraestructura se cuenta con datos de vías, semáforos y
PMT’s. Además de las anteriores fuentes de información también la policía y el grupo
guía suministran información a la entidad respecto al tráfico en Bogotá.
66
3.6.2.3. Proceso actual arquitectura de información A continuación se muestran gráficamente el proceso para cumplir los tres objetivos –
anteriormente descritos-, a través del software Enterprise Architect19 y empleando el
lenguaje UML.
En la siguiente figura se muestra gráficamente el proceso anteriormente descrito que
cumple los objetivos planteados:
Figura 20. Arquitectura de información línea base. Fuente: Elaboración propia
3.6.3. Modelo de arquitectura de tecnología
3.6.3.1. Línea base de la arquitectura de tecnología La arquitectura de tecnología actual del Sistema Inteligente de transporte está
conformada por los servidores, sistemas operacionales, bases de datos y redes (canales,
routers y firewalls) con los que cuenta la entidad.
19
Ver http://www.sparxsystems.com.au/products/ea/downloads.html
class Sistema
Trafico
- Distancia: int
- Ubicacion: char
- Velocidad: int
- Volumen: int
Infraestructura
Via
- Ancho: int
- Ubicacion: char
Semaforo
- Estado: char
- Tiempo: int
- Ubicación: char
Transporte
Publico
Vehiculo
- Estado: char
- Tamaño: int
- Ubicacion: char
Actor
Policia
- Ubicacion: char
PMT
NUSE
Ciudadano
Accidente
Gruo_guia
67
3.6.3.2. Procedimiento conceptual de la arquitectura de tecnología
Actualmente la Secretaría Distrital de Movilidad emplea software Arcgis, base de datos
Oracle, Servidores de aplicaciones y sistema de indicadores BI de Oracle, manejados por
la oficina de información sectorial de la subsecretaría de movilidad.
3.6.3.3. Proceso actual arquitectura de tecnología
A continuación se muestran gráficamente el proceso para cumplir los tres objetivos –
anteriormente descritos-, a través del software Enterprise Architect y empleando el
lenguaje UML.
En la siguiente figura se muestra gráficamente el proceso anteriormente descrito que
cumple los objetivos planteados:
Figura 21. Arquitectura de tecnología línea base. Fuente: Elaboración propia
3.7. Mapeo de la arquitectura de repositorio El propósito de esta sección es realizar un almacén de información en donde se
almacenan los elementos resultantes del ADM.
En la figura 22 se presenta la visión general de la arquitectura de repositorio.
68
Figura 22. Overview of Architecture Repository. Fuente: Adaptado de imagen tomada del sitio web: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap36.html
3.7.1. Arquitectura metamodelo Describe el framework empleado para llevar a cabo la Arquitectura Empresarial para el
SIT, en este caso el marco de referencia empleado es TOGAF y la metodología
propuesta por el mismo: el método ADM (método de desarrollo de la arquitectura), desde
la fase preliminar hasta la fase d.
3.7.2. Arquitectura del escenario La Arquitectura del escenario tiene vistas arquitectónicas del estado de la empresa en
determinados puntos en el tiempo. Debido a la gran cantidad y las diversas necesidades
de los stakeholders en la Secretaría Distrital de Movilidad, la arquitectura del escenario
se divide en tres niveles de granularidad propuestos por TOGAF:
Arquitecturas estratégicas: muestran una vista resumida a nivel ejecutivo y operativo
del equipo destinado para el SIT. En este caso se tiene el equipo establecido por ETB
69
como aliados estratégicos, el equipo de la Secretaría Distrital de Movilidad y el equipo
de la Universidad Distrital Francisco José de Caldas como entidad interventora entre
las dos anteriores.
Arquitecturas de segmento: Proporcionan modelos operativos más detallados de la
distribución de cada equipo dentro del proyecto. Actualmente para la ejecución de la
fase I del SIT cada uno de los stakeholders pertenece a uno o más de los siguientes
grupos:
Centro de gestión
Detección electrónica de infracciones
Semaforización
Paneles de mensaje variable
Financiera
Jurídico.
Arquitecturas de capacidad: Muestra de forma más detallada cómo la Secretaría
Distrital de Movilidad puede soportar una unidad en particular de la capacidad. En
este caso, la entidad cuenta con expertos en cada uno de los componentes
propuestos para la primera fase del SIT, resaltando sin embargo el acompañamiento
de profesionales de la Universidad Distrital Francisco José de Caldas en cada una de
las áreas: dirección, eléctrica, electrónica, civil, de transporte, de sistemas, financiera
y jurídica; y finalmente la guía de los profesionales de ETB.
3.7.3. Biblioteca de referencia La biblioteca ofrece un repositorio para sostener los materiales de referencia que se han
empleado para desarrollar arquitecturas en la entidad. En el caso de la Secretaría
Distrital de Movilidad el proyecto SIT es el primero que se emprende empleando
Arquitectura Empresarial, por lo tanto se inaugura la biblioteca de referencia con la
arquitectura desarrollada en el presente estudio.
3.7.4. Normas base de información Define los criterios de cumplimiento. En cuanto a los elementos políticos y normativos
asociados a Sistemas inteligentes de Transporte de Bogotá, se presentan apartes de las
70
normas o documentos para contextualizar el presente documento en la normatividad
vigente.
1. Código Nacional de Tránsito Terrestre – Ley 769 de 2002
2. Plan Maestro de Movilidad -PMM– Decreto 319 de 2006
3. Plan de Ordenamiento Territorial de Bogotá, Distrito Capital. – Decreto 190 de
2004 Por medio del cual se compilan las disposiciones contenidas en los
Decretos 619 de 2000 y 469 de 2003.
4. Plan de Desarrollo Distrital “Bogotá Humana 2012 - 2016” - Acuerdo Distrital 489
de 2012
5. Plan Nacional de Desarrollo 2010-2014 - Ley 1450 de 2011
6. Estructura organizacional y las funciones de la Secretaría Distrital de Movilidad -
Decreto 567 de 2006
3.7.5. Registros de gobernabilidad Registra los resultados de la actividad de gobierno, como las evaluaciones de
cumplimiento. Debido a que aún no se implementa ni ejecuta la Arquitectura Empresarial
del presente estudio las evaluaciones de cumplimiento que se realicen a partir de que se
genere un cronograma del proyecto se almacenen en esta sección.
3.7.6. Capacidad de la arquitectura Describe la organización, funciones, competencias y responsabilidades de la función de
Arquitectura Empresarial. Para hacer un recuento general de la organización designada
para el SIT, se hace la separación por entidades:
Secretaría Distrital de Movilidad: Su función es la dirección general del proyecto,
encargada de realizar el diseño conceptual y plantear los requerimientos claros
conforme a los objetivos del SIT.
ETB: Entidad contratista, quien presenta una propuesta acorde con lo solicitado
por la Secretaría Distrital de Movilidad y la ejecuta.
Universidad Distrital Francisco José de Caldas: Encargada de llevar a cabo la
interventoría entre las dos entidades anteriores, velar por el cumplimiento de los
objetivos del SIT y supervisar el correcto desempeño de su ejecución.
71
3.8. Arquitectura de destino
3.8.1. Modelo de arquitectura de negocio
3.8.1.1. Arquitectura destino de negocio Con base en los objetivos, los principios anteriores (Anexo B), y los capítulos
desarrollados se propone la siguiente visión TO-BE para la Arquitectura Empresarial del
SIT; teniendo en cuenta una vez más los tres objetivos a los que apunta el SIT y
desarrollados en este estudio:
a) Mejorar las condiciones de regulación, monitoreo y control del sistema de
movilidad.
b) Informar a los ciudadanos las condiciones de movilidad para sus decisiones de
desplazamiento.
c) Contribuir a las condiciones de seguridad vial en el sistema de movilidad.
3.8.1.2. Procedimiento conceptual de la arquitectura de negocio
a) Mejorar las condiciones de regulación, monitoreo y control del sistema de
movilidad
Proceso destino:
Toma de aforos manuales de vehículos en estaciones maestras y por solicitudes
especiales y velocidades de punto y promedio en segmentos viales.
Captura permanente y transmisión en línea; procesamiento y análisis
automatizado de la información.
b) Informar a los ciudadanos las condiciones de movilidad para sus decisiones de
desplazamiento.
Proceso destino:
La información estática suministrada por IDU, IDECA y UMV, Se integrará al centro de
gestión. El sistema deberá efectuar la monitorización de las vías y Disponer a los
usuarios información del tránsito en tiempo real a través de una aplicación que recibirá
información del IDU, IDECA y UMV de los ciudadanos.
72
c) Contribuir a las condiciones de seguridad vial en el sistema de movilidad.
Proceso destino
La información estática suministrada por IDU, IDECA y UMV, se integrará al centro de
gestión.
3.8.1.3. Proceso destino arquitectura de negocio A continuación se muestran gráficamente el proceso para cumplir los tres objetivos –
anteriormente descritos-, a través del software ArchiMate y empleando el lenguaje UML.
a) Mejorar las condiciones de regulación, monitoreo y control del sistema de
movilidad.
En la siguiente figura se muestra gráficamente el proceso anteriormente descrito que
cumple el objetivo planteado:
Figura 23. Arquitectura de negocio Arquitectura destino- objetivo 1. Fuente: Elaboración propia
b) Informar a los ciudadanos las condiciones de movilidad para sus decisiones de
desplazamiento.
En la siguiente figura se muestra gráficamente el proceso anteriormente descrito que
cumple el objetivo planteado:
73
Figura 24. Arquitectura de negocio Arquitectura destino- objetivo 2. Fuente: Elaboración propia
c) Contribuir a las condiciones de seguridad vial en el sistema de movilidad.
En la siguiente figura se muestra gráficamente el proceso anteriormente descrito que
cumple el objetivo planteado:
Figura 25. Arquitectura de negocio Arquitectura destino- objetivo 3. Fuente: Elaboración propia
74
3.8.2. Modelo de arquitectura de información
3.8.2.1. Arquitectura destino de información Para el cumplimiento de los objetivos establecidos se propone la arquitectura de
información la cual básicamente es una mejora a la arquitectura base de información con
la que cuenta la Secretaría Distrital de Movilidad, en la que se tienen en cuenta más
fuentes de datos que son relevantes para la primera fase del SIT.
3.8.2.2. Procedimiento conceptual de la arquitectura de información En el procedimiento para llevar a cabo la arquitectura de información se propone que la
Secretaría Distrital de movilidad tome a consideración como actores no sólo el vehículo y
el transporte público sino también el peatón y el ciclista, teniendo en cuenta que estos
son parte importante de la movilidad e indispensables para el cumplimiento de uno de los
objetivos de la entidad el cual busca mejorar la percepción del ciudadano. En cuanto a la
infraestructura, es necesario incluir en el sistema información de PMT’s, semáforos y vías
teniendo en cuenta en estas últimas los huecos y las tapas de alcantarilla.
En cuanto a la accidentalidad, ha dado buenos resultados la información proporcionada
del NUSE y de la ciudadanía pero también se incluye datos históricos del tráfico, los
cuales permitan verificar la recurrencia e histórico de accidentes en determinados puntos
o corredores viales. Los datos históricos también permitirán verificar el estado del tráfico
en determinadas horas, días, temporadas y eventos; teniendo en cuanta que los eventos
pueden ser o no meteorológicos y los que no lo son se subdividen en previstos o no
previstos, con el único fin de contar con toda la información posible y que sea relevante
para proporcionar al centro de gestión, en donde finalmente se tomarán las decisiones.
3.8.2.3. Proceso destino arquitectura de información A continuación se muestran gráficamente el proceso para cumplir los tres objetivos –
anteriormente descritos-, a través del software Enterprise Architect y empleando el
lenguaje UML.
En la siguiente figura se muestra gráficamente el proceso anteriormente descrito que
cumple los objetivos planteados:
75
Figura 26 Arquitectura de información arquitectura destino. Fuente: Elaboración propia
3.8.3. Modelo de arquitectura de tecnología
3.8.3.1. Arquitectura destino de tecnología La arquitectura de tecnología destino del Sistema Inteligente de transporte busca la
integración de la información que se tiene con el centro de gestión por medio de software
que permita que la información sea procesada y entregada para la toma de decisiones.
3.8.3.2. Procedimiento conceptual de la arquitectura de tecnología Actualmente la Secretaría Distrital de Movilidad emplea software Arcgis, base de datos
Oracle, Servidores de aplicaciones y sistema de indicadores BI de Oracle, manejados por
la oficina de información sectorial de la subsecretaría de movilidad. Estos software se
pueden seguir empleando teniendo en cuenta que la principal necesidad del Sistema
Inteligente de transporte es un producto software que facilite la utilización, orden y
class Sistema
Ev ento_metereologico
- Tipo: char
- Ubicacion: char
Prev isto
Hueco
- Ubicacion: char
Trafico
- Distancia: int
- Ubicacion: char
- Velocidad: int
- Volumen: int
Infraestructura
Via
- Ancho: int
- Ubicacion: char
Semaforo
- Estado: char
- Tiempo: int
- Ubicación: char
Peaton
- Ubicacion: char
Ciclista Transporte
Publico
Vehiculo
- Estado: char
- Tamaño: int
- Ubicacion: char
Actor
No_prev isto
Policia
- Ubicacion: char
Tapa_alcantarilla
- Ubicacion: char
PMT
Datos_historicos Trafico
- Hora: char
- Velocidad: int
- Volumen: int
NUSE
Ciudadano
Accidente
Gruo_guia
Ev ento
76
suministro de la información recolectada, por lo tanto es necesario introducir a la
tecnología actual de la Secretaría Distrital de Movilidad este producto.
En este estudio se presenta como un software integrador que permita la visualización en
tiempo real, el procesamiento de los datos y la entrega de información que permita a los
operarios del centro de gestión tomar decisiones sobre la movilidad.
Este software debe ser propuesto por la ETB, como entidad contratista, con las
especificaciones que consideren necesarias para el mismo, pero teniendo en cuenta los
siguientes puntos:
Dispositivos en calle requeridos para la visualización y toma de datos.
Capacidad de integración con las bases de datos actuales de la Secretaría
Distrital de Movilidad.
Debe poder ser alimentado con la información que ya se tiene en movilidad, como
lo es el mapa georeferencial de la ciudad.
Contar con la capacidad de suministrar información útil a los funcionarios del
centro de gestión conforme a los objetivos del SIT.
Capacitación a funcionarios de la Secretaría Distrital de Movilidad para el manejo
del mismo.
Garantizar con claridad las licencias de uso de software.
3.8.3.3. Proceso destino arquitectura de tecnología A continuación se muestran gráficamente el proceso para cumplir los tres objetivos –
anteriormente descritos-, a través del software Enterprise Architect y empleando el
lenguaje UML.
En la siguiente figura se muestra gráficamente el proceso anteriormente descrito que
cumple el objetivo planteado:
77
Figura 27. Arquitectura de tecnología arquitectura destino. Fuente: Elaboración propia
3.9. Análisis de las deficiencias A continuación se presenta la matriz de análisis de deficiencias (GAP analysis). En la
matriz se resume la transición del modelo de arquitectura de línea base a la arquitectura
destino, destacando las deficiencias del modelo actual de la Secretaría Distrital de
Movilidad y mostrando las mejorías de este al implementar la Arquitectura Empresarial.
78
Análisis de las deficiencias
Línea base
Arq
uit
ectu
ra d
esti
no
Arquitectura de negocio Arquitectura de información
Arquitectura de tecnología
En el nuevo modelo de arquitectura de negocio planteado, se reduce el número de operarios, esto se debe a que la captura de la información se realiza automáticamente lo cual permite que los datos sean más acertados. Además la información se transmite en línea y en tiempo real, en el modelo de línea base la recolección, digitación y procesamiento manual hacia que el monitoreo del sistema de movilidad fuera mucho más lento. Finalmente en el modelo actual se entrega la información recolectada en hojas de Excel, en el modelo destino se propone la entrega de datos ordenados en el software para la toma de decisiones.
Uno de los principales factores que garantizar el mejoramiento del modelo de arquitectura base a la arquitectura destino, es que se tienen en cuenta actores –que no se tenían en cuanta antes- los cuales permiten el cumplimiento de objetivos propuestos por la Secretaría Distrital de Movilidad como lo son el peatón y el ciclista. Además otros elementos nuevos que ingresan al modelo de información es el detalle de las vías y los eventos registrados. Finalmente el modelo también mejora al incorporarse los datos históricos (relacionados con la movilidad) como fuente de información.
En la arquitectura tecnológica del SIT mientras en el modelo de línea base es la oficina de información sectorial quien recibe la información y la procesa con los software con los que se cuenta, en el modelo de arquitectura destino todos los software, bases de datos y sistemas que son alimentados en la OIS, pasan a ser fuentes de información para el software denominado “software de inteligencia”, el cual también recibirá y procesará los datos de los dispositivos en calle, del data center instalado en ETB y en general de todas las fuentes, para el procesamiento y almacenamiento de datos, proporcionando información útil para la toma de decisiones a los operarios.
Tabla 9. Gap Analysis. Fuente: Elaboración propia
3.10. Evaluación de impacto
3.10.1. Referencia de requerimientos específicos El estudio realizado se basó en los requerimientos establecidos por la Secretaría
Distrital de movilidad, para el Sistema Inteligente de Transporte para Bogotá,
plasmados en el documento “Definición de los servicios y funcionalidades
asociadas al sistema inteligente de transporte – SIT para Bogotá” entregado a la
Universidad el 5 de agosto de 2014 con el radicado SDM-SSM- 102377-2014 y
79
oficialmente al equipo de interventoría el 3 de diciembre del mismo año vía
correo electrónico.
Como se mencionó en el documento, los objetivos del SIT se pueden sintetizar
en tres objetivos principales:
a) Aumento de la movilidad.
b) Mejorar la percepción del ciudadano.
c) Aumentar la seguridad vial.
Los cuales fueron modificados para hacer cada uno de ellos más específico, obteniendo como resultado los siguientes, los cuales son la referencia del estudio.
a) Mejorar las condiciones de regulación, monitoreo y control del sistema de movilidad.
b) Informar a los ciudadanos las condiciones de movilidad para sus decisiones de
desplazamiento.
c) Contribuir a las condiciones de seguridad vial en el sistema de movilidad.
3.10.2. Prioridad de stakeholders de los requerimientos para-fecha
Teniendo en cuenta que los objetivos tratados en el estudio no son los únicos a
los que apunta el SIT y por ende los interesados en el proyecto, se clasifica lel
impacto del estudio conforme a los objetivos establecidos en el árbol de objetivos
y ordenados de acuerdo a su prioridad.
El formato utilizado para la matriz de evaluación se explica a continuación:
(1) Stakeholder: Parte interesada en el proyecto, de acuerdo a su nivel de autoridad e
influencia en el SIT.
(2) Objetivo del SIT de acuerdo a la documentación entregada por la SDM, teniendo
en cuenta su nivel de prioridad.
80
Tabla 10: Prioridad de stakeholders de los requerimientos para fecha
Objetivo
Alto Bajo
(1)S
tak
eh
old
er
Alto
Aumento de la movilidad. Mejorar la percepción del
ciudadano. Aumentar la seguridad vial.
Ba
jo
Gestionar de forma integral todos los factores medibles que afecten o intervengan en las condiciones movilidad en un territorio.
Disponer de información para viajes en un territorio definido, a través del uso de datos actualizados, en línea y en tiempo real de los diferentes sistemas de transporte que operan e interactúan en el mismo.
Dar respuestas más rápidas a incidentes y emergencias utilizando dispositivos de detección a través de medios electrónicos.
Propender por una mayor fluidez en la circulación, a través de diversas estrategias como de pago electrónico (peajes, estacionamientos y otros)
Tener un mejor control de las diferentes flotas, a través del monitoreo remoto de las flotas y comunicación con conductores.
Mejorar las condiciones de medioambiente en Bogotá, a través de la integración de dispositivos (sensores) ambientales en las vías y vehículos con la gestión de condiciones de circulación.
81
4
CONCLUSIONES Y TRABAJO FUTURO
1. Se pudo determinar, mediante el diseño de la Arquitectura Empresarial para el
SIT que la principal herramienta de la que carece la Secretaría Distrital de Movilidad y
debe solicitar en los requerimientos del proyecto es el componente de software que
reciba, almacene y procese los datos de diferentes fuentes –existentes y por instalar-,
entregando la información ordenada para la toma de decisiones.
2. El marco de referencia TOGAF ayuda a utilizar los recursos de manera más
eficiente y eficaz proponiendo tecnologías para la organización que son útiles y
coherentes con los objetivos planteados.
3. El método de desarrollo de la arquitectura (ADM) facilitó la implementación de la
Arquitectura Empresarial, obteniendo como conclusión la necesidad evidente de la
Secretaría Distrital de Movilidad de automatizar procesos para garantizar la exactitud de
los datos recibidos y la información suministrada a la ciudad.
4. Se realizó la comparación de las arquitecturas línea base y destino para las
arquitecturas de negocio, información y tecnologías, permitiendo destacar la importancia
de los productos software que serán las herramientas principales en los cuatro
componentes del SIT.
5. A partir del análisis de los objetivos y procesos propuestos y llevados a cabo
actualmente por la Secretaría Distrital de Movilidad para el SIT, se pudo determinar las
82
deficiencias actuales tanto de los requerimientos de la Secretaría como de la propuesta
de ETB.
6. El modelo planteado reduce el número de operarios, transmite la información en
línea y en tiempo real y garantiza la entrega de información y datos organizados
facilitando la toma de decisiones.
7. Entre los principales factores que garantizan el mejoramiento del modelo de
arquitectura base a la arquitectura destino, se encuentra el reconocimiento de actores
que no se tenían en cuanta antes, el detalle en la información que se tiene de vías e
intersecciones semafóricas y la incorporación de datos históricos; los cuales permitirán
que la información del centro de gestión sea confiable y certera.
8. Este trabajo permitió desarrollar el diseño y documentación de la arquitectura
propuesta para la primera fase del Sistemas Inteligente de Transporte, referenciando que
es un trabajo innovador en su área.
Trabajo Futuro
Este es un trabajo pionero para el desarrollo de proyectos para la Secretaría Distrital de
Movilidad, sin embargo se plantea llevar a cabo más iteraciones de la metodología
propuesta. Además, para trabajos futuros se plantea el uso y ampliación de la
metodología aquí propuesta tanto en las siguientes fases del SIT como en otros
proyectos que involucren tecnologías de la información.
83
Bibliografía
[1] TOGAF® Framework and ArchiMate® Modeling Language Harmonization:
Glossaries Comparison, White Paper (W14A), August 2014, published by The
Open Group.
[2] TOGAF® Version 9.1, Enterprise Edition, Open Group Standard (G116),
December 2011, published by The Open Group; available:
www.opengroup.org/bookstore/catalog/g116.htm
[3] ArchiMate® 2.1 Specification, Open Group Standard (C13L), December 2013,
published by The Open Group; available:
www.opengroup.org/bookstore/catalog/c13l.html
[4] Tatyana Mikeheeva. “Intelligent Transport Systems: methods, algorithms,
realization”. Lambert.
[5] IBI Group, Lockheed Martin. “Development of Canadian Architecture for Intelligent
Transportation Systems – Final Report Volume A”.
[6] Canby, Anne P. “Managing the Urban Transportation System – The Need for A
New Operating Paradigm”. Agosto 2001.
[7] Chen, Kan and John Miles (Editors). «ITS Handbook 2000: Recommendations
from the World Road Association (PIARC)». London: Artech House.
[8] David HARRISON, Lou VARVERIS, “TOGAF: Establishing Itself As the Definitive
Method for Building Enterprise Architectures in the Commercial World”. Available:
http://www.developer.com/java/ent/article.php/3374171/TOGAF-Establishing-
Itself-As-the-Definitive-Method-for-Building-Enterprise-Architectures-in-the-
Commercial-World.htm
[9] The Open Group. Welcome to TOGAF® Version 9 an Open Group Standard. [En
línea] [Citado el: 15 de 05 de 2015.] http://www.opengroup.org/architecture/togaf9-
doc/arch/index.html.
[10] Intelligent Transportation Society of America. Available: http://www.itsa.org/
84
[11] Intelligent Transport System. ITS España. Available:
http://www.itsspain.com/itsspain/
[12] Technical Committee on Networks Operations. ITS Handbook. Available:
http://road-network-
operations.piarc.org/index.php?option=com_content&task=view&id=38&Itemid=71
&lang=en
[13] SIT – Sistema Inteligente de transporte. Secretaría Distrital de Movilidad
de Bogotá. Available: http://www.movilidadbogota.gov.co/?sec=59
[14] Klaus BANSE, Luis Felipe HERRERA, Juan Pablo MUÑOZ, “Diseño de
Sistemas de Gestión de Tráfico Adaptativos”. Available: http://infosit-
colombia.com/.
[15] Sussman, Joseph M. “Transportation operations: an organisational and
Institutional Perspective”. Diciembre 2001
[16] The Open Group. The Open Group Architecture Framework. Introducción a
ADM (Architecture Developer Method). [En línea] [Citado el: 17 de 04 de 2015.]
http://www.togaf.info/togaf9/togafSlides9/TOGAF-V9- M3-Intro-ADM.pdf.
[17] Robertson, D.I. and R.D. Bretherton (1991) “Optimizing Networks of Tarffic
signals in real time – The SCOOT method”, IEEE Transactions on vehicular
technology, Vol. 40, No 1.
[18] Sosa, A, Koga J, “Desarrollo Urbano y Movilidad en America Latina” 2011.
[19] Luis Felipe HERRERA, “Modelo de prestación de servicios ITS de valor
agregado”, Tesis doctoral. 2011.
[20] Klaus BANSE, “Instalación de semáforos especiales para el transporte
público”. Available: http://www.sit-colombia.com/200911%20KBANSE%20-
%20Andinatraffic.pdf
[21] The Open Group. The open group (Merking standards work). [En línea]
[Citado el: 08 de 04 de 2015.] http://www.togaf.info/togaf9/togafSlides9/TOGAF-
V9-M2-TOGAF9- Components.pdf.
[22] Klaus BANSE, Robert MIRANDA, “Cost benefit analysis of ITS
deployments – Case study: Implementation of an adaptive traffic control system
for the City of Cartagena de Indias, Colombia (Project phase 1)”. Available:
85
http://www.sitcolombia.com/200909%20KBANSE%20-
%20ITS%20International.pdf
[23] Luis Felipe HERRERA, @Enfoques Bigdata para la planificacion de
transporte. Caso: Creación automática de la matriz origen/destino para transporte
público”. Revista ANDINATRAFFIC. Edición No. 11.
[24] Yuli Gabriela YARCE MARÍN, Sandra Milena Serna Mora, “Método para
estimar el factor de equivalencia vehicular a motocicletas. Aplicación en la ciudad
de Medellín”. Revista ANDINATRAFFIC. Edición No. 11.
[25] Jairo BASTIDAS, “¿Es nuestro Sistema de gestión de movilidad
inteligente?”. Siemens S.A. Revista ANDINATRAFFIC. Edición No. 11.
[26] Iasa Spain chapter – Visión general a TOGAF. Recuperado de
https://www.youtube.com/watch?v=IkwhohbBwG0 el 20 de ebero de 2015
[27] Daniel BENHAMMOU, “Data Collection: Affordable Real-Time Traffic
Adaptive Control”. Revista ANDINATRAFFIC. Edición No. 11.
[28] Klaus BANSE, “Los beneficios de la modernización de sistemas de control
y manejo de tráfico mediante el uso de tecnologías de ITS”. Available:
http://www.sitcolombia.com/201112%2005%20uy%20mvd%20its.pdf
[29] Klaus BANSE, “Necesidad y Estrategias para el Fortalecimiento
Institucional de la Administración Publica en el tema ITS”, Available:
http://www.sitcolombia.com/201105%2031%20pe%20seminario%20its%20peru.p
df
[30] Klauss BANSE, “Protocolos ITS para sistemas de semaforización”,
Available:http://www.sitcolombia.com/201109%2029%20co%20pso%20avante%2
0protocolos.pdf
86
87
GLOSARIO DE TERMINOS
1. ADM: Architecture development method (Método de desarrollo de la arquitectura).
2. ArcGIS: Es el nombre de un conjunto de productos de software en el campo de
los Sistemas de Información Geográfica o SIG.
3. Corredor vial: Conjunto de dos o más rutas que se conforman con una finalidad
específica.
4. ETB: Empresa de Telecomunicaciones de Bogotá.
5. Grupo guía: Grupo de funcionarios de la Secretaría Distrital de movilidad encargados
de contribuir a la mitigación de impactos negativos que generan sobre el componente
movilidad y la correcta dinámica del tráfico, tanto problemas operativos y
afectaciones viales en general, como aspectos conductuales de los usuarios de las
vías, mediante la Intervención temporal en la Gestión del Tráfico, acciones de tipo
Informativo en vía, atención a situaciones de emergencia y contingencia de la
movilidad.
6. Incidente: un incidente es toda falla o degradación de un servicio o equipo que está
operativo o en producción; una interrupción total o parcial de un servicio o equipo.
Cualquier evento que no es parte de la operación estándar de un servicio o equipo y
que causa, o puede causar interrupción o degradación del mismo.
7. NUSE: El Sistema Integrado de Seguridad y Emergencias NUSE 123 permite la
unificación de todos los números de seguridad y emergencias del Distrito Capital en
uno solo, e integra en una única plataforma tecnológica la recepción de las llamadas
y el despacho de los Recursos por parte de las Agencias de manera coordinada. La
sigla NUSE significa “Número Único de Seguridad y Emergencias”.
8. OIS: Oficina de información sectorial.
9. Plan Maestro de Movilidad: El Plan Maestro de Movilidad establece programas,
proyectos y metas, a corto, mediano y largo plazo, con un horizonte de 20 años. El
PMM da respuesta a las necesidades de movilidad y al uso racional y eficiente de los
15.348 kilómetros carril que componen la malla vial de Bogotá.
88
10. Plan de Manejo de Tránsito: Plan de Manejo de Transito ante al SDM es el que se
debe implementar durante la afectación del espacio público o privado abierto al
público, con el fin de plantear las estrategias para el manejo temporal del tráfico,
cierres y desvíos viales, generado acciones que permitan garantizar un ambiente
seguro, limpio y ágil para conductores, pasajeros, peatones, personal de obra y
vecinos del lugar, garantizando la seguridad vial y minimizando la congestión
vehicular.
11. PMV: paneles de mensajes variables.
12. PMT: Planes de manejo de tránsito que incluyen estudios de tránsito, cierres viales,
señalización y semaforización.
13. Requerimiento de software: capacidad del software, necesaria para que el usuario
del sistema resuelva un problema o alcance un objetivo20.
14. Requerimientos Funcionales: estos requerimientos expresan como el sistema debe
comportarse con determinadas entradas y condiciones.
15. Requerimientos No funcionales: expresan algunos de los atributos del sistema o
del ambiente del sistema, como por ejemplo:
Usabilidad: describe la facilidad con la que un sistema puede ser aprendido y
operado por los usuarios.
Soportabilidad: habilidad del sistema de ser fácilmente modificado, reparado o
adaptado.
16. SDM: Secretaría Distrital de Movilidad.
17. TOGAF: The Open Group Architecture Framework.
18. UD: Universidad Distrital Francisco José de Caldas.
19. UMV: Unidad de mantenimiento vial.
20
Managing Software Requerimients a unified Approach (Leffingwell Widrig Editorial Addison Wesley)
89
Anexos
A. Anexo: Objetivos e insumos que los describen
Número de Política
Política Pública Reglamento Objetivo / Principio Documento
Política 1 Código Nacional de Tránsito Terrestre
Ley 769 de 2002
Seguridad de los usuarios
RUNT
Política 1 Código Nacional de Tránsito Terrestre
Ley 769 de 2002
Calidad / comodidad RUNT
Política 1 Código Nacional de Tránsito Terrestre
Ley 769 de 2002
Oportunidad RUNT
Política 1 Código Nacional de Tránsito Terrestre
Ley 769 de 2002
Cubrimiento RUNT
Política 1 Código Nacional de Tránsito Terrestre
Ley 769 de 2002
Libertad de Acceso RUNT
Política 1 Código Nacional de Tránsito Terrestre
Ley 769 de 2002
Plena Identificación RUNT
Política 1 Código Nacional de Tránsito Terrestre
Ley 769 de 2002
Libre Circulación RUNT
Política 1 Código Nacional de Tránsito Terrestre
Ley 769 de 2002
Educación RUNT
Política 1 Código Nacional de Tránsito Terrestre
Ley 769 de 2002
Descentralización RUNT
Política 1 Código Nacional de Tránsito Terrestre
Ley 769 de 2002
Orientación a prevención y asistencia técnica y humana de usuarios en vías
RUNT
Política 1 Código Nacional de Tránsito Terrestre
Ley 769 de 2002
Preservación medio ambiente
RUNT
Política 1 Código Nacional de Tránsito Terrestre
Ley 769 de 2002
Protección del uso común del espacio público
RUNT
90
Política 1 Código Nacional de Tránsito Terrestre
Ley 769 de 2002
Énfasis en población vulnerable : peatones, discapacitados físicos y mentales.
RUNT
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Movilidad sostenible Política
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Movilidad competitiva
Política
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Prioridad del peatón Política
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Transporte público eje estructurador
Política
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Racionalización vehículo particular
Política
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Integración modal Política
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Movilidad inteligente Política
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Movilidad socialmente responsable
Política
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Movilidad orientada a resultados
Política
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Fortalecimiento Institucional
Estrategia Regulación y control
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Financiamiento para la sostenibilidad del sistema
Estrategia Regulación y control
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Implantación planes de seguridad vial
Proyectos
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Implementación del SIMUR
Proyectos
91
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Recurso Humano de control y vigilancia para labores preventivas
Medios de control y vigilancia
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Función de control y vigilancia incluye labores de detección de infracciones
Medios de control y vigilancia
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Equipos tecnológicos deben generar piezas probatorias unificadas
Características del control de tráfico por medios tecnológicos
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Equipos tecnológicos deben enfocarse en infracciones de grave riesgo para personas y cosas
Características del control de tráfico por medios tecnológicos
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Equipos tecnológicos deben enfocarse para detectar vehículos no autorizados del serv. Público
Características del control de tráfico por medios tecnológicos
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Racionalización de recursos de semaforización
Racionalización de recursos de semaforización
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Centralización de la información a través de centro de control maestro
Características del SIT
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Lectura y transformación directa de la información del sistema de movilidad
Características del SIT
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Interactuar con diferentes medios de comunicación
Características del SIT
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Vehículos de control y vigilancia ayudar para proveer información en tiempo real para usuarios y otros para apoyar Política de
Características del SIT
92
prevención
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Información a usuarios en tiempo real
Características del SIT
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Diseño de un SIT como sistema de comunicaciones que garantiza flujo de información.
Proyectos de la logística de movilidad
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Implementación de un SIT como sistema de comunicaciones que garantiza flujo de información y administrador de la información.
Proyectos de la logística de movilidad
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Diseño de un manual de señalización para vías urbanas.
Proyectos de la logística de movilidad
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Implantación sistema de señalización cuya tecnología sea compatible con el SIT (Señales en T. Real)
Proyectos de la logística de movilidad
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Implantación sistema para evaluación permanente del impacto de medidas de regulación especial
Proyectos de la logística de movilidad
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Campañas intensivas de educación ciudadana dirigidas a los actores de la movilidad e incentivar autorregulación
Proyectos de la logística de movilidad
93
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Fortalecimiento del marco de regulación de cada uno de los componentes del sistema de movilidad
Proyectos de la logística de movilidad
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Control operativo integral en campo
Proyectos de la logística de movilidad
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Inventario , diseño e instalación y disposición de la señalización
Proyectos de la logística de movilidad
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Estructuración técnica, jurídica y financiera de los proyectos del SIT.
Proyectos de la logística de movilidad
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Estudio Factibilidad de implantación de la fase peatonal y de ciclistas en intersecciones semaforizadas
Proyectos de la logística de movilidad
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Elaboración de un manual de diseño geométrico para vías urbanas
Proyectos de la logística de movilidad
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
Articular en forma eficiente y competitiva los subsistemas vial, transporte y regulación y control de tráfico con implementación de tecnologías apropiadas
Alcance de Movilidad Inteligente respecto al POT
Política 2 Plan Maestro de Movilidad
Acuerdo Distrital 130 de 2004
Proveer a la administración central, descentralizada y localidades para identificar condición, movilidad, dinámica, expansión, procesos, proyectos…
Infraestructura datos espaciales
94
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
y necesidades de la ciudad en áreas urbana y rural, para disponer de elementos georeferenciados…
Política 2 Plan Maestro de Movilidad
Decreto 319 de 2006
que permitan a las autoridades atender a la ciudadanía y conseguir toma decisiones en beneficio de sus habitantes.
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Mejorar la productividad de ciudad y región con acciones coordinadas sobre subsistemas vial, transporte y regulación y control
Política de Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Garantizar proyectos eficientes, seguros y económicos.
Política de Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Generar un sistema de transporte de pasajeros urbano regional integrado y a la organización de …
Política de Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
carga para mejorar su competitividad en mercados nacionales y e internacionales
Política de Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Sistema de movilidad y otros 3 (Equipamientos, espacio público construido y sistemas generales de servicio público)
Estrategia de ordenamiento para distrito: Estructura funcional
95
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Sistema de movilidad actúa de modo interdependiente con estructura socioeconómica y espacial por red de centralidades
Estrategia de ordenamiento para distrito: Sistema de movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
y garantiza la movilidad y conexión entre centralidades y tejidos residenciales que gravitan a su alrededor
Estrategia de ordenamiento para distrito: Sistema de movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
A nivel rural conecta los poblados rurales y ares de actividad existentes con su interior y la ciudad
Estrategia de ordenamiento para distrito: Sistema de movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Estructurar el ordenamiento urbano regional.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Articular en forma eficiente y competitiva los subsistemas vial, de transporte y de regulación y control del tráfico.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Conectar las terminales de transporte y de carga interurbano en emplazamientos que permitan la articulación eficiente de los diversos modos de transporte.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Consolidar el área urbana
Objetivos del sistema Movilidad
96
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Contener la conurbación de Bogotá con los municipios vecinos mediante una conectividad eficiente con la red de ciudades.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Mejorar la productividad sectorial.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Apoyar las operaciones que buscan aumentar la productividad y competitividad de la región Bogotá Cundinamarca mejorando la conectividad interna de Bogotá y con las ciudades de la red, y de la región con los mercados nacional e internacional.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Mejorar los niveles de accesibilidad hacia y desde los sectores periféricos de Bogotá.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Mejorar la gestión operacional de la red vial y del subsistema de transporte, con el fin de optimizar su utilización.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Fortalecer la autorregulación y los sistemas de con trol y vigilancia del tráfico vehicular.
Objetivos del sistema Movilidad
97
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Reducir los niveles de contaminación ambiental por fuentes móviles. E incorporar criterios ambientales para producir un sistema de movilidad ecoeficiente.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Disminuir los tiempos de viaje y los costos de operación vehicular.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Reducir los flujos de tráfico de pasajeros y de carga en la zona urbana con destino a otras ciudades de la región y el país.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Incrementar la seguridad vial y disminuir los índices de accidentalidad mediante una señalización correcta y una norma técnica de diseño de cruces entre ciclo rutas, la red peatonal y la vehicular. Se creará con la Secretaría peatonal y la vehicular. Se creará con la Secretaría de Tránsito y el IDU un sistema de revisión y atención inmediata de la señalización y de seguridad en puntos críticos de accidentalidad
Objetivos del sistema Movilidad
98
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Realizar y cofinanciar con el sector público y privado regional y nacional proyectos que permitan mejorar la conectividad entre el Distrito Capital, la Región, el país y el exterior.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Coordinar con las entidades responsables de la planeación, operación y control, las políticas fiscales, de inversión y policivas, que respondan a los objetivos de un sistema regional de movilidad competitivo y articulado.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Mejorar la accesibilidad y conectividad entre las distintas centralidades, el centro de Bogotá y la red regional de ciudades.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Organizar las rutas de transporte público urbano tradicional (buses, busetas y colectivos), para evitar sobre recorridos, excesos en las frecuencias y la concentración de rutas en los mismos corredores viales.
Objetivos del sistema Movilidad
99
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Articular e integrar de manera eficiente las ciclo rutas, las rutas de transporte público, las rutas troncales y el transporte regional y nacional
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Articular los diversos modos de transporte con el Aeropuerto El Dorado.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Garantizar la inversión en mantenimiento vial y la sostenibilidad del sistema.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Regular el estacionamiento en vía y fuera de vía, en función de la oferta y la demanda y fortalecer los mecanismos de control y la vigilancia al estacionamiento ilegal en espacio público.
Objetivos del sistema Movilidad
Política 3 Plan de Ordenamiento Territorial de Bogotá, Distrito Capital
Decreto 190 de 2004
Atender las áreas urbanas con mayores deficiencias viales mediante corredores de movilidad local.
Objetivos del sistema Movilidad
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 - 2016
Acuerdo Distrital 489 de 2012
Prioridad así: peatones; ciclistas; transporte masivo sobre el vehículo particular; introducción de la energía eléctrica en el transporte masivo
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 - 2016
Acuerdo Distrital 489 de 2012
Mejorar movilidad con sistema de transporte público masivo con equidad, calidad,
100
mas limpio y seguro.
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 – 2016
Acuerdo Distrital 489 de 2012
El sistema integrado de transporte será intermodal, es decir, incluye todas las formas, integra lo urbano, rural y regional; con las redes de ciclo rutas, la actual red férrea, los cables aéreos; complementado con la promoción de medios más sostenibles como caminar o desplazarse en bicicleta.
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 – 2016
Acuerdo Distrital 489 de 2012
Permitirá incrementar el uso de la bicicleta en la ciudad.
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 – 2016
Acuerdo Distrital 489 de 2012
Identificará puntos de integración donde se requiere interconexión entre los diferentes modos y medios de transporte para asegurar nodos de conexión al interior del sistema urbano.
101
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 - 2016
Acuerdo Distrital 489 de 2012
fortalecer la estrategia de ordenamiento territorial del Distrito, en coherencia con la perspectiva regional; a reconocer las diferentes necesidades de los grupos poblacionales, especial del derecho a la movilidad en garantizar la seguridad y accesibilidad de los ciudadanos en condición de vulnerabilidad
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 - 2016
Acuerdo Distrital 489 de 2012
La infraestructura para el desarrollo urbano promoverá la transparencia en la contratación, evitando la concentración en pocos contratistas de las obras públicas. Por el contrario, se permitirá la libre competencia y la inclusión de proponentes de diferentes niveles de acuerdo con la magnitud y escalas de intervención en la ciudad.
102
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 – 2016
Acuerdo Distrital 489 de 2012
generarán incentivos en aquellas propuestas que contengan el manejo y reciclaje de escombros en el lugar de intervención, así como la inclusión de nuevos materiales y tecnologías amigables con el ambiente, que mejoren los tiempos de ejecución de las obras en la ciudad.
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 – 2016
Acuerdo Distrital 489 de 2012
En los proyectos de infraestructura se garantizará las condiciones de accesibilidad a los ciudadanos en especial a personas con discapacidad y grupos etarios tanto en el proceso constructivo, como en el proyecto definitivo, de manera que se facilite el acceso de todos los ciudadanos a las infraestructuras y servicios de la ciudad
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 – 2016
Acuerdo Distrital 489 de 2012
La interacción entre los ciudadanos y el Programa de Movilidad Humana es fundamental y deberá ser permanente.
Proyectos Prioritarios: Informando y Participando
103
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 - 2016
Acuerdo Distrital 489 de 2012
se formularán proyectos asociados con tecnología y producción de información los cuales en su estructuración incorporan componentes enfocados a la creación o mejoramiento de los canales de comunicación, uso de programas libres e interacción que buscan fortalece r el vínculo entre la Secretaría y la ciudadanía en general
Proyectos Prioritarios: Informando y Participando
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 - 2016
Acuerdo Distrital 489 de 2012
se fortalecerán las acciones de modernización, expansión y mantenimiento del sistema integral de control del tránsito
Proyectos Prioritarios: Red de Soporte para la prestación de servicios
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 - 2016
Acuerdo Distrital 489 de 2012
la óptima operación e implementación de los dispositivos de control de tránsito tales como señales y semáforos
Proyectos Prioritarios: Red de Soporte para la prestación de servicios
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 - 2016
Acuerdo Distrital 489 de 2012
uso adecuado delas vías en el momento de una intervención mediante los Planes de Manejo de Tráfico ya sea por la realización de obras en redes de servicios públicos o de infraestructura
Proyectos Prioritarios: Red de Soporte para la prestación de servicios
104
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 – 2016
Acuerdo Distrital 489 de 2012
un efectivo control en vía y generar procesos que permitan mejorar yo optimizar los servicios de trámites de tránsito.
Proyectos Prioritarios: Red de Soporte para la prestación de servicios
Política 4 Plan de Desarrollo Distrital "Bogotá Humana 2012 – 2016
Acuerdo Distrital 489 de 2012
prestación de servicios para la movilidad humana debe ser integral, la Administración Distrital mejorará y afianzará canales y dispositivos de comunicación, información y orientación en procesos administrativos que le permitan al ciudadano acercarse al sector y dirimir conflictos legales o fiscales que pueda tener pendientes con la ciudad.
Proyectos Prioritarios: Red de Soporte para la prestación de servicios
Política 5 Plan Nacional de Desarrollo 2010 - 2014
Ley 1450 de 2011
promoverán el goce efectivo del derecho de acceso a todas las personas a la información y las comunicaciones, dentro de los límites establecidos por la Constitución y la Ley, a través de Tecnologías de la Información y las Comunicaciones y se abstendrán de establecer barreras, prohibiciones y restricciones que impidan dicho acceso
Accesibilidad a servicios de TIC.
105
Política 5 Plan Nacional de Desarrollo 2010 – 2014
Ley 1450 de 2011
Conjunto de soluciones tecnológicas informáticas y de telecomunicaciones que recolectan, almacenan, procesan y distribuyen información, y se deben diseñar para mejorar la operación, la gestión y la seguridad del transporte y el tránsito.
Sistemas inteligentes de tránsito y transporte -sit
Política 6 Estructura organizacional y las funciones de la Secretaría Distrital de Movilidad
Decreto 567 de 2006
Funciones
Política 7 Generales SIT Gestionar de forma integral todos los factores medibles que afecten o intervengan en las condiciones movilidad en un territorio.
Objetivos Generales
Política 7 Generales SIT Disponer de información para viajes en un territorio definido, a través del uso de datos actualizados, en línea y en tiempo real de los diferentes sistemas de transporte que operan e interactúan en el mismo.
Objetivos Generales
Política 7 Generales SIT Dar respuestas más rápidas a incidentes y emergencias utilizando dispositivos de detección a través de medios electrónicos.
Objetivos Generales
106
Política 7 Generales SIT Mejorar la situación de congestión, a través del monitoreo continuo de las condiciones de circulación, controles de acceso, sincronización de semáforos y otros dispositivos en vía.
Objetivos Generales
Política 7 Generales SIT Propender por una mayor fluidez en la circulación, a través de diversas estrategias como de pago electrónico (peajes, estacionamientos y otros)
Objetivos Generales
Política 7 Generales SIT Propender por una mayor seguridad vial, a través de la incorporación de dispositivos en vehículos que permitan la entrega de información para gestionar mejor las vías.
Objetivos Generales
Política 7 Generales SIT Tener un mejor control de las diferentes flotas, a través del monitoreo remoto de las flotas y comunicación con conductores.
Objetivos Generales
107
Política 7 Generales SIT Promover una mayor efectividad en la gestión de flotas de carga, suministrando sistemas automatizados de control de vehículos comerciales que permitan conocer la ubicación automática de vehículos y de la carga, los pagos electrónicos de peaje y combustible y el control de conductores.
Objetivos Generales
Política 7 Generales SIT Mejorar las condiciones de medioambiente en Bogotá, a través de la integración de dispositivos (sensores) ambientales en las vías y vehículos con la gestión de condiciones de circulación.
Objetivos Generales
Política 7 Generales SIT Obtener información estructurada y organizada sistémicamente para la generación de estrategias, la formulación de proyectos y la definición de políticas que propendan por mejorar las condiciones de movilidad en el territorio.
Objetivos Generales
Política 7 Generales SIT beneficios sociales, que afectan no solo a los usuarios del transporte sino también a toda la sociedad
Beneficios
108
Política 7 Generales SIT beneficios a individuos, que son gozados principalmente por usuarios, operadores y gestores de la infraestructura
Beneficios
Política 7 Generales SIT Incentivos adicionales, que no son directamente relacionados con la movilidad, pero sí con la industria del contexto en el que se desarrollan.
Beneficios
B. Anexo: Principios de Arquitectura
Contexto de gobierno en línea
Para las entidades estatales colombianas, desde el Ministerio de las TICs se ha
planteado un marco de referencia de arquitectura de TI dentro del programa de Gobierno
en Línea21 estableciendo los siguientes principios de arquitectura en cada uno de sus
dominios:
A. Principios de Negocio del Gobierno en Línea de Colombia.
Orientación a la satisfacción del Ciudadano
Modelo de prestación de servicios sostenible, basado en el equilibrio de la
demanda y la oferta
Acceso equitativo y multicanal
21
Gobierno en línea colombiano es un programa liderado por el Ministerio de TICs para normalizar y elevar el grado de apropiación de las Tics en las entidades estatales: http://programa.gobiernoenlinea.gov.co para habilitar iniciativas como dar apertura a datos públicos, Implementar la iniciativa cero papel, automatizar trámites y servicios, crear ventanillas únicas, abrir espacios de participación, fortalecer los medios de comunicación bidireccional con el ciudadano.
109
Colaboración y co-creación teniendo como base la transparencia y el marco
normativo
Innovación
B. Principios de Datos del Gobierno en Línea de Colombia.
Calidad
Lenguaje común
Gestión Integral del ciclo de vida de los datos
Protección de Información
Apertura
C. Principios de Aplicaciones del Gobierno en Línea de Colombia.
Orientación a una arquitectura basada en servicios
Independencia de la plataforma
Soporte Multicanal
Seguridad
Cumplimiento de estándares
D. Principios de Tecnología del Gobierno en Línea de Colombia.
Costo/Eficiencia
Adaptabilidad
Cumplimiento de Estándares
Neutralidad Tecnológica
Alineados con esta base de principios y directrices se enmarcan los principios para la
práctica de la AE en el SIT.
Base conceptual definida por TOGAF para los principios de arquitectura
“Los principios de arquitectura están relacionados al trabajo de arquitectura. Reflejan el
nivel de consenso a través de la organización y encarnan el espíritu y pensamiento de los
principios organizacionales.”22
22
Tomado del Libro TOGAF V.9.1. Capítulo 23 Sección 1.
110
Los principios de Arquitectura pueden categorizarse en principios que rigen el proceso de
la Arquitectura Empresarial, lo que afecta el desarrollo, mantenimiento y uso de la
arquitectura en la organización y los principios que rigen la aplicación de la arquitectura.
A. Características de los principios de arquitectura
Los principios de Arquitectura definen las normas y directrices generales que guían el
diseño y la evolución de las arquitecturas. Son el reflejo de un nivel de consenso
entre los diversos elementos de la empresa, y constituyen la base para la toma de
futuras decisiones.
Cada principio arquitectura está claramente relacionado los objetivos de negocio y los
elementos conductores o motivadores principales de la práctica de la AE.
a. Componentes de los Principios de Arquitectura
Cada principio tiene asociado un fundamento, presenta las implicaciones
tanto para promover la comprensión y la aceptación de los propios
principios, como su utilización.
Componentes de la definición de los principios:
Nombre que representa la esencia de la de la guía, propendiendo que sea
de fácil recordación.
Enunciado claro sin ambigüedades que comunica la regla fundamental y
de manera inequívoca.
Justificación, la razón fundamental que resalta los beneficios de la
adhesión al principio, utilizando la terminología de la organización, la
relación con otros principios, y las intenciones en relación con una
interpretación equilibrada. Incluso, si es pertinente, describir situaciones
en las que un principio tendría prioridad o más peso que otro para la toma
de decisiones.
b. Desarrollo de los principios de arquitectura
Típicamente los principios de arquitectura son desarrollados por los arquitectos
empresariales en conjunción con los stakeholders y aprobado por el comité de
Arquitectura Empresarial.
111
Los principios de arquitectura están cobijados por los principios organizacionales.
Deben ser claramente rastreables y articulados para que guíen la toma de
decisiones. Se eligen de tal forma que aseguren el alineamiento de la arquitectura
y la implementación de la arquitectura objetivo con la visión y las estrategias del
negocio.
Un buen conjunto de principios se basa en las creencias y valores de la
organización y se expresa en un lenguaje que la empresa entiende y utiliza.
Es recomendable establecer pocos principios orientados hacia el futuro, y éstos
deben ser apoyados y defendidos por la alta dirección. Los principios
proporcionan una base sólida para la toma de decisiones de la arquitectura,
formulación de políticas, procedimientos y normas, y el apoyo a la resolución de
situaciones contradictorias.
c. Criterios que distinguen a un buen conjunto de principios:
En el marco de referencia de TOGAF 9.1 los principios de Arquitectura Empresarial
se distinguen por ser:
Comprensibles: Los postulados pueden ser captados y entendidos por las
personas en toda la organización rápidamente.
Robustos: Contemplan el cumplimiento de las necesidades/requerimientos de
todos los involucrados para que las decisiones de pertinencia sobre las
arquitecturas propuestas o los planes, políticas y normas de obligatorio
cumplimiento cuenten con unas bases sólidas sobre las cuales se
fundamenten las soluciones.
Completos: Cubre el panorama posible de situaciones donde sea aplicable.
Consistentes: Son coherentes entre sí y obedecer a un propósito general. Se
expresado de manera que permite un equilibrio de las interpretaciones. Cada
palabra en la definición de un principio se elige cuidadosamente para permitir
una interpretación consistente y a la vez flexible.
Estables: Son duraderos, y a la vez capaces de adaptarse a los cambios en el
entorno. Si en algún momento es necesario ajustar o cambiar un principio,
esta modificación pasará por un proceso establecido de gestión cambios o
ajustes, ya sea para incluir, suprimir o alterar los principios después de haber
sido ratificados inicialmente por un comité que tenga el criterio para valorar el
impacto de esos cambios.
112
d. La aplicación de los Principios de Arquitectura
Los principios de Arquitectura se utilizan para recoger las verdades
fundamentales acerca de cómo la entidad utilizará y desplegara sus recursos en
los diferentes dominios.
Los principios tienes diferentes maneras de utilizarse:
Para proveer un marco de trabajo dentro del cual la organización puede
iniciar a hacer decisiones conscientes respecto a la AE y los proyectos que
implementan las arquitecturas destino.
Como guía para establecer los criterios de evaluación relevantes,
ejerciendo fuerte influencia sobre la lección de productos, soluciones o
arquitecturas de solución en las etapas posteriores de gestión del
cumplimiento a la Arquitectura Empresarial.
Como conductores para definir los requerimientos funcionales de la
arquitectura.
Como una entrada para valorar tanto implementaciones existentes y
portafolios estratégicos, como para el cumplimiento con las arquitecturas
definidas.
Las justificaciones puestas dentro un principio de arquitectura resaltan el
valor al negocio, de implementaciones consistentes con el principio y
proveen guía cuando haya que tomar decisiones con objetivos o
conductores conflictivos entre sí.
Las declaraciones de implicaciones dentro de un principio de arquitectura
delinean, para la organización, las principales tareas, recursos y costos
potenciales de seguir el principio.
Como una entrada valiosa para futuras iniciativas de transición y
actividades de planeación.
Los principios de Arquitectura Empresarial deben ser gestionados por la SDM
para que a través de ellos haya una gobernabilidad de la Arquitectura
Empresarial, ya que muchos serán los involucrados en su ciclo de vida.
113
Principios de Arquitectura Empresarial
A. Primacía de los principios
a. Enunciado del principio:
Los principios de la Arquitectura Empresarial del SIT aplican a todas las
áreas y dependencias de los ejercicios de AE que el SIT desarrolle en sus
diferentes fases.
b. Justificación:
La práctica de la Arquitectura Empresarial en el SIT facilitará el logro de
las metas y objetivos estratégicos del proyecto.
c. Implicaciones:
El SIT debe incorporar la capacidad para la práctica de la AE, donde los
principios de la Arquitectura Empresarial informan, guían y nutren sus
esfuerzos de atención a las necesidades de la Secretaría abordadas
desde la AE.
B. Alineamiento estratégico
b. Enunciado:
Todas las fases del proyecto deben estar alineadas con los planes
estratégicos y objetivos del SIT.
c. Justificación:
La problemática asociada a esa primera etapa de la puesta en marcha de
un Sistema Inteligente de Transporte se sintetiza teniendo en cuenta que
el principal producto de la fase actual es un artefacto de software el cual,
pese a que tiene un componente importante de hardware (semáforos,
sensores, paneles, infraestructura, entre otros), su motor central de
ejecución se desarrolla por el funcionamiento del software, que
indudablemente es lo que hace inteligente al sistema propuesto. Pero al
analizar el proyecto que se está desarrollando hoy, desde la perspectiva
del proceso de desarrollo de software (comprendido en cinco etapas:
inicio, diseño, codificación, pruebas y puesta en funcionamiento) se
identifica de forma evidente un gran gap entre la fase de inicio y la de
114
diseño. Esto ocurre porque la Secretaría Distrital de Movilidad no presenta
de forma detallada los requerimientos, y el diseño propuesto por ETB
involucra principalmente operarios e infraestructura y deja de lado el
componente inteligente, acción que no permitiría el mejoramiento del
tráfico en la ciudad y en general ninguno de los objetivos que la SDM
espera para el SIT.
d. Implicaciones:
Conformar en la organización el equipo de Arquitectura Empresarial del
proyecto SIT que propenda por el cumplimiento de este principio.
C. Respetar los estándares organizacionales y cumplimiento de los marcos
normativos vigentes.
a. Enunciado:
Los ejercicios de Arquitectura Empresarial que se desarrollen en la
primera fase del SIT sean concebidos desde su origen cumpliendo los
estándares y normas de la organización. Las mejores prácticas de gestión
empresarial y de gestión pública y con los lineamientos y regulaciones del
sector.
b. Justificación:
Establecer que ejercicio de la Arquitectura Empresarial asegure la
integridad, la evolución planificada, y actualización de las arquitecturas a
la luz, las mejores prácticas de gestión establecidas como estándares
organizacionales y cumpliendo con los marcos normativos vigentes.
c. Implicaciones:
Implementar el Comité de Arquitectura Empresarial en la SDM para que
asegure el cumplimiento de los estándares organizacionales y marcos
normativos vigentes (Legal, Normas, Estándares, Resoluciones,
Regulaciones) en los ejercicios de Arquitectura Empresarial que se lleven
a cabo para el SIT.
115
Principios de arquitectura de negocio
A. Cumplimiento de la Ley
a. Enunciado:
Los procesos empresariales que implementa el SIT cumplen con todas las
leyes, políticas y regulaciones vigentes.
b. Justificación:
La política de la SDM es cumplir con las leyes, políticas y regulaciones.
Dicha disposición no impedirá la mejora de procesos de negocio que
conduzcan a cambios en las políticas y regulaciones
c. Implicaciones:
La SDM debe tener en cuenta el cumplimiento de las leyes,
reglamentos y políticas para la recolección, retención y gestión de
datos en sus sistemas de información.
Capacitación, comunicación, acceso y cumplimiento a las reglas.
La eficiencia, la necesidad y el sentido común no pueden ir en
contravía del cumplimiento de las leyes.
Los cambios en la ley y/o en las normas pueden conducir a cambios en
los procesos o aplicaciones.
B. Calidad de los servicios
a. Enunciado:
Los Servicios que se presta el SIT deben cumplir con los más altos
parámetros de calidad, expresada en sus acuerdos de niveles de servicio.
b. Justificación:
La calidad de los Servicios debe ser un factor que identifique al SIT y por
lo tanto debe ser un tema principal en el momento de tomar decisiones de
crecimiento, selección de alternativas y proyectos candidatos a
optimización de procesos.
116
c. Implicaciones:
Adoptar un estándar que oriente las decisiones de calidad de los servicios
de la secretaría, y en concreto del Sistema Inteligente de Trasnporte.
C. Alineamiento a los procesos de negocio de las iniciativas de TICs.
a. Enunciado:
Los proyectos o iniciativas de las áreas funcionales con componentes
de TICs, deben estar alineados con los procesos de negocio
pertinentes.
b. Justificación:
La administración de los requerimientos de los grupos de interés
(Concerns) en los ejercicios de arquitectura que adelante el SIT deben
guiar la arquitectura de las aplicaciones y componentes tecnológicos
del software y no al revés, es decir, que no sean las restricciones del
software las que delimiten los servicios ofrecidos.
La infraestructura técnica y arquitectura de software son facilitadores y
habilitadores de los procesos de negocio.
c. Implicaciones:
La justificación de las inversiones en componentes tecnológicos deben
obedecer a las necesidades de los procesos de negocio.
Las soluciones tecnológicas deben habilitar los procesos, trámites y
servicios de la organización y hacerlos más ágiles y con mejor
trazabilidad y no al revés.
D. Maximizar los beneficios para el cumplimiento de la misión para el SIT
a. Enunciado:
Las decisiones de gestión de la información en el SIT se hacen para
proporcionar el máximo beneficio para el cumplimiento de su misión como
un todo.
117
b. Justificación:
Las decisiones tomadas desde una perspectiva global del SIT tienen un
mayor valor a largo plazo que las decisiones tomadas desde cualquier
punto de vista organizativo en particular. El máximo retorno de la inversión
exige que las decisiones de gestión de información en el SIT deban estar
en concordancia con los conductores del negocio del SIT y con sus
prioridades. Ningún grupo minoritario redundará en detrimento del
beneficio del conjunto
c. Implicaciones:
Lograr el máximo beneficio requiere cambios en la manera en la que la
información se planifica y gestiona. La tecnología sola no traerá consigo
este cambio.
A medida que surgen las necesidades, las prioridades deben ser
ajustadas. Un Comité de Arquitectura Empresarial debe tomar estas
decisiones.
E. Continuidad del Negocio
a. Enunciado:
Los servicios ofrecidos por el SIT se continúan prestando aún en medio de
eventos de carácter catastrófico.
b. Justificación:
La confiabilidad y credibilidad de la SDM, específicamente del SIT, y sus
sistemas de información dependen de la correcta y continua ejecución de
los servicios ofrecidos.
c. Implicaciones:
La fiabilidad es una característica esencial que debe cumplir la operación
y los sistemas de información con la infraestructura subyacente que los
soporta.
La protección es fundamental contra los ataques de denegación de
servicio, virus y otras actividades maliciosas que tienen el potencial de
interrumpir la disponibilidad de los sistemas de información.
118
Definir un nivel aceptable de servicio acorde con los requerimientos del
SIT.
El acceso al servicio de información por parte del ciudadano en
modalidad 7x24x365 será fundamental.
F. Orientación a servicios
a. Enunciado:
La estructuración del negocio se basa en un diseño de los servicios que
reflejan las actividades encomendadas en el marco jurídico, las cuales
comprenden los procesos de negocio del SIT.
b. Justificación:
La orientación a servicios ofrece agilidad empresarial y flujo de información
sin fronteras.
c. Implicaciones:
La representación de servicios utiliza descripciones de negocio para
proporcionar contexto (es decir, de procesos de negocio, el objetivo, la
política de Estado, la interfaz de servicio y el componente de servicio)
La orientación a servicios ubica requerimientos únicos sobre la
infraestructura y las implementaciones deben utilizar estándares abiertos
para realizar interoperabilidad.
Las implementaciones son específicas del entorno. Las mismas están
limitadas o habilitadas por el contexto y deben ser descritas en ese
contexto.
Principios de arquitectura de aplicaciones
La arquitectura de aplicaciones y la de datos están inmersas dentro de la arquitectura de
sistemas de información
119
A. Facilidad de uso
a. Enunciado:
Las aplicaciones son fáciles de utilizar. La tecnología subyacente es
transparente a los usuarios, de forma tal que pueden concentrarse en
sus labores y no en los aspectos tecnológicos.
b. Justificación:
Entre más requiera el usuario de entendimiento de la tecnología
subyacente, para realizar sus labores, es menos productivo. La
facilidad de uso es un incentivo positivo para el uso de las
aplicaciones. Anima a los usuarios a trabajar dentro del ambiente de
información integrado en vez de buscar alternativas aisladas y
desintegradas. La mayoría del conocimiento requerido para operar un
sistema debe ser similar al requerido para operar cualquier otro, lo
cual hace que el entrenamiento sea mínimo y el riesgo de usar
inapropiadamente un sistema es bajo.
c. Implicaciones:
Determinar una presentación estandarizada para las aplicaciones.
Desarrollar el conjunto de criterios de usabilidad para las aplicaciones.
C. Basadas en componentes
a. Enunciado:
La arquitectura de las aplicaciones se basa en componentes que cumplen
tareas específicas y que pueden ser integrados en diferentes escenarios
b. Justificación:
La estructuración en componentes de las aplicaciones facilita el camino
para la reutilización de funcionalidades ya programadas y probadas.
Las arquitecturas basadas en componentes allana el camino hacia la
reutilización de los activos de software que la organización va agregando
a su arquitectura. Se obtiene un mayor retorno de la inversión, ya que un
120
mismo componente puede atender a varias actividades que requieran la
misma funcionalidad.
c. Implicaciones:
Definir el ciclo de vida de los componentes dentro de la organización.
Adoptar, para la organización, políticas de gobernabilidad de los
componentes.
Establecer estándares para la definición de los contratos de los
componentes.
Contar con herramientas que apoyen la gestión del catálogo de
componentes durante todo su ciclo de vida.
Las decisiones de adquisición de productos comerciales (COTS) tendrán
en cuenta los estándares adoptados para cumplir con este principio.
D. Interoperabilidad
a. Enunciado:
La arquitectura de las aplicaciones contempla la interacción automática
entre los sistemas de información internos y externos, tanto para cumplir
sus funciones como para apoyar a los otros sistemas en el cumplimiento
de las suyas.
b. Justificación:
La interoperabilidad facilita el intercambio de información entre la
organización y con la otras entidades gubernamentales de orden nacional
e internacional.
La interoperabilidad, adecuadamente estructurada, hace más eficiente la
operación, pues los costos se pueden distribuir entre las partes que
interactúan, evitando tareas dobles y duplicidad de recursos.
c. Implicaciones:
Definir los principios y estándares de la interoperabilidad propios para la
organización.
Los acuerdos de intercambio de información y servicios estarán en
conformidad a esos principios y estándares.
121
Adoptar, para la organización, políticas de gobernabilidad de la
interoperabilidad.
E. La arquitectura de las aplicaciones son: extensibles, escalables y adaptables.
a. Enunciado:
La arquitectura de los sistemas de información debe ser extensible, es
decir, ser susceptible de ampliación funcional de manera interna o vía
interoperabilidad con otros sistemas de información. Escalable: poder
crecer en capacidad de volúmenes de atención, a través del tiempo.
Adaptable: permitir variaciones a su alcance funcional sin tener que re-
estructurarse completamente.
b. Justificación:
La mejora continua y el dinamismo propio de los procesos de negocio
deben ser habilitados oportunamente y a costos razonables por la
arquitectura.
El software debe ser adaptable fácilmente a la arquitectura y permitiendo
así adaptarse a los cambios en los procesos de negocio.
c. Implicaciones:
Los sistemas de información creados o incorporados a la organización
deben cumplir con estos atributos, para ser integrados dentro del conjunto
de aplicativos. Pues esos atributos bajan los riesgos asociados a la
perdurabilidad y sostenibilidad de los mismos.
Efectuar revisiones de cumplimiento a las políticas de arquitectura de
sistemas de información, desde los estudios de factibilidad y en el evento
de identificar no conformidades, los potenciales proveedores las
resolverán en sus ofertas, para poder ser tenidos en cuenta.
El crecimiento de la demanda de los servicios de los sistemas de
información debe estimarse en cuanto a volúmenes y requerimientos de
infraestructura, contemplando alternativas de crecimiento en su
capacidad sin implicar la descontinuación de los componentes
tecnológicos.
122
Adoptar, para la organización, políticas de gobernabilidad de la
interoperabilidad.
Principios de arquitectura de datos
La arquitectura de datos junto con la de aplicaciones está inmersa dentro de la
arquitectura de sistemas de información
A. El dato es un activo organizacional
a. Enunciado:
Los datos son considerados un activo de la organización, que genera
valor y como tales son gestionados y custodiados.
b. Justificación:
La información es un recurso clave para poder operar una organización y
ayudar a interpretar la realidad del desempeño de la misma. La toma de
decisiones está apoyada en los datos que maneja, y por tanto se requiere
que estos puedan ser recuperados en cualquier momento, de forma
íntegra y en el tiempo requerido.
Dada esa naturaleza de “valor” que tienen los datos, estos entonces
deben ser gestionados para establecer su propiedad, dónde están, quién
los maneja, quién los modifica.
Los datos son uno de los activos valiosos de la organización y por ende
son accesibles, administrados, asegurados y compartidos con
confidencialidad por las áreas que la requieran.
Los funcionarios participan de una u otra forma con los datos, ya sea en la
definición, administración, custodia y seguridad de la información.
c. Implicaciones:
Elaborar las políticas de seguridad de la información para la
organización.
Sensibilizar a las personas de la organización, de estas políticas para que
se genere conciencia de su responsabilidad y valor que tiene la
información que se genera a partir de los datos.
123
Deben existir “Administradores de Datos” con la autoridad y los medios
para gestionar los datos de los que sean responsables.
Se debe hacer la transición cultural de pensar en la "propiedad de los
datos" a pensar en la "buena gestión de datos”
El papel del “Administrador de Datos” es crítico ya que datos obsoletos,
incorrectos o inconsistentes pueden afectar negativamente la toma de
decisiones en el SIT.
Parte de la función del “Administrador de Datos” es garantizar la calidad
de los datos. Los procedimientos deben ser desarrollados y utilizados
para prevenir y corregir errores en la información y mejorar los procesos
que producen información errónea. La calidad de los datos tendrá que ser
medida.
B. El dato se comparte
a. Enunciado:
Los usuarios tienen acceso a los datos necesarios para llevar a cabo sus
funciones, por lo tanto, los datos se comparten a través de las funciones
empresariales y las organizaciones.
b. Justificación:
El acceso oportuno a datos precisos es esencial para mejorar la calidad y
eficiencia de la toma de decisiones en el SIT. Es menos costoso
mantener datos en un solo repositorio, a través del cual se compartan,
que mantener los datos duplicados en múltiples repositorios. La velocidad
de recogida de datos, creación, transferencia y asimilación es impulsada
por la capacidad de la organización para compartir de manera eficiente
datos de distintas fuentes de información a través del SIT y con sus
actores externos
c. Implicaciones:
Diseñar y planificar el intercambio de datos deseado y cumplir con un
conjunto común de políticas, procedimientos y normas que rigen la
gestión de datos y el acceso tanto a corto como a largo plazo.
124
Desarrollar modelos de datos estándar, elementos de datos y otros
metadatos que definen el entorno compartido y desarrollar un sistema de
almacenamiento de estos metadatos para facilitar su acceso
Invertir en software capaz de colaborar con el intercambio de datos entre
Sistemas de Información al interior del SIT y sus componentes, y hacia el
exterior, con los actores convenidos.
Adoptar y aplicar las políticas comunes de acceso a datos y directrices
para los desarrollos de nuevos sistemas de Información para asegurar
que los datos en las nuevas aplicaciones siguen estando disponibles para
el medio ambiente compartido y que los datos en el entorno compartido
pueden continuar siendo utilizados por los nuevos sistemas
Adoptar los métodos y herramientas comunes para la creación,
mantenimiento y acceso a los datos compartidos a través del SIT.
Los datos disponibles para el intercambio tendrán que ser definidos por
todos los usuarios que los usan para ejecutar sus tareas.
Este principio de intercambio de datos continuamente "se cruza con" el
principio de la seguridad de los datos. En ningún caso el principio de
intercambio de datos provoca que la confidencialidad de los datos se vea
comprometida.
C. El dato es accesible
a. Enunciado:
La información es accesible para que los usuarios puedan realizar sus
funciones.
b. Justificación:
El acceso amplio a los datos conduce a la eficiencia y eficacia en la toma
de decisiones y ofrece una respuesta oportuna a las solicitudes de
información y prestación de servicios. El uso de la información debe ser
considerado desde una perspectiva empresarial para permitir el acceso de
una amplia variedad de usuarios. El personal optimiza el uso del tiempo y
la consistencia de los datos mejora.
125
c. Implicaciones:
Accesibilidad implica la facilidad con que los usuarios obtienen
información
La manera en que la información se accede y se muestra debe ser lo
suficientemente adaptable para satisfacer una amplia gama de usuarios y
sus métodos de acceso correspondientes
El acceso a datos no constituye la comprensión de los datos. El personal
debe tener cuidado de no malinterpretar la información
El acceso a los datos no necesariamente garantiza que el usuario tenga
derecho a modificar o revelar los datos
D. El dato es seguro
a. Enunciado:
La SDM asegura la integridad, la confidencialidad, el control de acceso, la
auditabilidad de sus datos más sensibles.
b. Justificación:
La SDM es responsable por la seguridad de su información, habilitando
los requerimientos de flexibilidad para su acceso y protegiendo el valor de
sus datos críticos sin exponerlos a riesgos de filtración o alteración.
c. Implicaciones:
Generar una política de gestión de la seguridad en los datos
La seguridad debe estar diseñada en los elementos de datos desde el
comienzo, no es una cualidad que se agregue posteriormente.
Los sistemas, datos y tecnologías deben estar protegidos de accesos y
manipulaciones no autorizadas.
La información más sensible debe estar protegida contra alteraciones
inadvertidas o no autorizadas, por sabotaje, o desastres.
Principios de arquitectura de tecnología
Los principios para la arquitectura en el dominio de tecnología, cubre los elementos o
componentes del software de base, infraestructura de servidores y dispositivos de
telecomunicaciones
126
A. Cambios basados en necesidades del SIT
a. Enunciado:
Los cambios a aplicaciones y tecnología se harán solamente en respuesta
a necesidades del SIT.
b. Justificación:
Las necesidades del SSITerán el real motivador de cambio tecnológico. La
tecnología no se cambia por sí misma, sin antes determinar el valor
generado para el proyecto.
Los cambios en procesos, aplicaciones y tecnologías existentes y la
incorporación de nuevas soluciones tecnológicas solo serán realizados en
respuesta a las necesidades del proyecto y con un proceso formal de
gestión de cambios.
c. Implicaciones:
Los cambios en tecnología responderán a una necesidad de negocio
documentada y aceptada.
Desarrollar procesos para la gestión del cambio que implementen este
principio.
B. Interoperabilidad tecnológica
a. Enunciado:
Tanto el software como el hardware deben ajustarse a los estándares
adoptados que promueven la interoperabilidad de los datos, las
aplicaciones y la tecnología.
b. Justificación:
La conformidad en los recursos de software y hardware a los estándares
adquiridos por la SDM mantienen la consistencia de la arquitectura de
tecnología, su gestión, su integración.
127
c. Implicaciones:
Los estándares serán respetados a menos que se presenten razones de
peso que requieran la implementación de una solución no estándar.
Establecer un proceso para la gestión de los estándares adoptados por la
SDM, donde se examinen, revisen periódicamente y se evalúen las
posibles excepciones a tomar con respecto a la no aplicación de algún
estándar.
C. Consideración a estándares del mercado
a. Enunciado:
Las Innovaciones y estándares del mercado son considerados en el
diseño de la arquitectura tecnológica tanto del software como de la
infraestructura de base.
b. Justificación:
La arquitectura de la tecnología aprovecha los avances y los estándares
abiertos y presentes en la industria para ofrecer un ambiente
interoperable, escalable y adaptable de TI que apoya y sostiene los
servicios y procesos de la Secretaría.
El avance y agilidad tecnológica debe ser considerado pues varía en un
lapso de 3 a 5 años y puede aportar mayor eficiencia, seguridad y
estabilidad a la arquitectura de tecnología.
c. Implicaciones:
La Arquitectura de la tecnología debe permitir la innovación y flexibilidad
dentro de su marco para, mejorar la prestación de servicios y la
implementación reducida y costos de soporte.
Se debe estar efectuando una revisión del panorama tecnológico de los
componentes tecnológicos y de la solución para poder identificar y
valorar la pertinencia de las innovaciones.
Related Documents
