EGSI-08 - Arquitectura Empresarial de TI

Estrategia y Gestión de los Sistemas de Información
Arquitectura Empresarial de TI
0
Agenda
 Introducción: ¿Existe una arquitectura ideal o cualquiera sirve?
 Base Estratégica Organizacional
 El Modelo Operacional
 Actividad: Identificación del Modelo Operacional de Talibank
 Arquitectura Empresarial de TI
 Arquitectura Empresarial por tipo de Modelo Operacional
 Actividad: Diagrama Núcleo de Talibank
 Etapas evolutivas de la Arquitectura Empresarial
 Gestión durante la evolución de la AE
 Actividad: Etapas Evolutivas de Talibank
 Modelo de Compromiso
 Gobierno de TI
 Actividad: Diagnóstico de Matriz de Arreglos de Gobierno
 Ciclo de Vida de la Tecnología
 Actividad: Estado de la Tecnología de Talibank
 Especialidades y Responsabilidades Primarias de Arquitectura
 Actividad: Aplicación de Responsabilidades Primarias de Arquitectura en Talibank
 Arquitectura Empresarial de TI y el PETI
 Repaso Final
1
Hoy debemos…
 Comprender en qué consiste Arquitectura Empresarial de TI (AETI)
 Entender la importancia de AETI para TI y para la empresa, desde el punto de

vista de gestión como de planeamiento estratégico
 Comprender las herramientas con las que cuenta AETI para definir y articular una
hoja de ruta tecnológica para una empresa moderna
2
Introducción:
¿Existe una arquitectura ideal o
cualquiera sirve?
3
La Casa Winchester
En Bay Arena, California, en el límite entre San José y Cupertino, existe una enorme
mansión conocida como la Casa Winchester. Fue construida entre fines del siglo XIX y
principios del XX por Sarah Winchester, quien heredó una gran fortuna de su esposo
gracias al negocio que él tenía en su compañía de rifles.
Conforme tenía más edad, la Sra. Winchester se volvía cada vez más excéntrica. Ella
indicaba ser asaltada por los fantasmas de gente desafortunada asesinada por los rifles
hechos por su esposo. Por ello, contrató a dos consejeros espirituales, a tiempo
completo, quienes le dijeron que continuaría viva mientras ella continuara construyendo.
Así, la construcción de la mansión se dio por cada hora, día, semana y año durante 38
años. Una nueva ala por allí, una torre por allá; cuartos remodelados docenas de veces.
Talleres, materiales y todas las cosas para construir estaban permanentemente allí. Se
gastó vastas cantidades de dinero en la casa.
En la actualidad, se hacen tours a la Casa Winchester. Son muy bellos los acabados de
los pisos, vidrio, porcelana y el trabajo en madera. Sin embargo, los puntos más
interesantes del tour son ver características de la casa como las escaleras que terminan
en un cielo raso, puertas y ventana bloqueadas por paredes, más pasadizos y
recibidores que salones y cuartos, chimeneas inservibles y muchos cuartos para el
mismo propósito.
4
La Casa Winchester
5
La casa Winchester: Preguntas
 ¿Cuál fue la motivación seguida en la construcción de la casa?
 ¿Qué principios o lineamientos de construcción se siguieron se siguieron?
 ¿Hubiera sido conveniente tener un arquitecto a cargo? ¿Por qué?
 ¿Sirvió la arquitectura implementada para SU propósito?
6
Base Estratégica Organizacional
7
Operaciones y Procesos Clave
 Las organizaciones que buscan controlar y lograr el mejor desempeño, deben

tener claro qué procesos son claves para ellas
 Deben reconocer sus operaciones núcleo (core), con el fin de lograr agilidad en
el negocio y un crecimiento sostenible
 Las que mejor se desempeñan, integran tecnología con procesos para ser
eficientes y confiables
8
Base Estratégica Organizacional (BEO)
 Las mejores empresas convierten a sus procesos en capacidades del negocio

 Capacidad = Lo que mejor sé hacer
 La Base Estratégica Organizacional, es la infraestructura de TI y los procesos de

negocios digitalizados, que permiten automatizar las capacidades de las
organizaciones
 Llegar a un BEO es evolutivo

 Grupo Ajegroup (Añaños)
 Gastón Acurio
 Grupo Interbank
9
BEO: Disciplinas clave
Iniciativas Iniciativas Iniciativas Iniciativas

estratégicas estratégicas estratégicas estratégicas
Define límites estratégicos
Modelo operacional
Aprendizaje
Define
Arquitectura Establecimiento
y mejora de prioridades
continua
requerimientos de
integración y
Empresarial
estandarización
Define capacidades clave Actualiza y evoluciona

la arquitectura
Modelo de Enlace
Base Estratégica Organizacional
• Procesos de negocios clave

• Infraestructura de TI
12
BEO - Disciplinas clave Modelo operacional
Modelo Operacional
 Nivel necesario de integración y estandarización de procesos de
negocio para entregar bienes y servicios a los clientes. Contiene el
acuerdo de cómo se operará la organización
 Una empresa con diferentes líneas de negocio, podría estar altamente
o poco integrada y estandarizada
 La integración, se refiere a que los procesos tengan una cara común
a los clientes desde el inicio al fin, manejando la necesidad de
manejar los mismos datos entre diferentes unidades de una
organización. Ej.:
 Movistar: Telefonía Fija, TV y Móvil
 Grupo Interbank: Plaza Vea, Oeschle, Interbank, Tu Entrada, Bembos
 La estandarización, se refiere a que diferentes unidades realizan los
procesos de la misma manera. Esto crea eficiencias, pero limita la
personalización. Ej.:
 Implementación corporativa de SAP. Caso de pago a fuerza de ventas de
Banco, AFP o Aseguradora
13
BEO - Disciplinas clave: Arquitectura
Empresarial
Arquitectura Empresarial
 Consiste en la organización estructurada, documentada y formal de los procesos
del negocio y la infraestructura de TI, que refleja los requerimientos de integración
y estandarización del Modelo Operacional
 Provee una vista de largo plazo (TO BE) de los procesos, sistemas y tecnologías,
en comparación con la situación actual (AS IS)
 Este objetivo de largo plazo, se logra a través de la ejecución de diversos

proyectos en una hoja de ruta que debe habilitar elementos de la arquitectura y no
sólo atender necesidades del negocio del corto plazo (ROADMAP)
 Riesgo: Proyecto apurado por fechas, pocos recursos para dedicar a temas de largo plazo, etc.
 Mitigación: Arquitectura es un stakeholder, indicadores organizacionales por temas de
Arquitectura
14
AS IS + ROADMAP = TO BE
2012 2013 2014 2015
Proy 1 Proy 3 Proy 5

FUTURO
HOY
TO BE
AS IS Proy 2
Proy 4
1. Proy 1 HOJA DE RUTA

2. Proy 2
3. Proy 3 ROADMAP
4. Proy 4
5. Proy 5
15
BEO - Disciplinas clave: Modelo de Enlace
Modelo de Enlace (Gobierno de TI)

 Es el mecanismo con el que el negocio se alinea con los proyectos de TI
 Este modelo permite influenciar sobre las decisiones en proyectos para promover
la implementación de requerimientos de Arquitectura
 Puede ser implementado como

 Reuniones de revisión, seguimiento y decisión
 Revisión de documentación
 Lineamientos o reglas concretas
 Políticas o guías
 Principios o grandes marcos de referencia
16
El gran problema en TI: Interoperabilidad
Datos de la Organización
Datos
Aplicaciones
Plataformas
Tecnológicas
Redes y Servicios de Infraestructura
17
Diagnóstico de un mal BEO
 Diferentes partes de la compañía dan diferentes respuestas a las mismas

preguntas de usuario
 Implementar un requerimiento regulatorio es un esfuerzo mayor,
requiriendo mucho sponsorship e inversiones en infraestructura
 El negocio carece de agilidad. Cada nueva iniciativa se siente como si
empezara de cero
 TI es consistentemente un cuello de botella
 Hay diversos procesos de negocios haciendo la misma actividad en toda
la organización, cada uno con diferentes aplicaciones
 La información que se requiere para tomar decisiones claves sobre
productos y clientes, no está disponible
 Un parte importante del trabajo de algunas personas, consiste en sacar
información de un sistema, manipularla e ingresarla en otro sistema
 La gerencia no quiere discutir la agenda de TI
 No se sabe si la organización está obteniendo buen valor de TI
18
El Modelo Operacional
19
El Modelo Operacional
 El modelo operacional es el nivel necesario de integración y estandarización

de procesos de negocios para la entrega de bienes y servicios a los clientes
 Un modelo operacional permite la implementación rápida de iniciativas

estratégicas
 Sin embargo, el modelo operacional fallará al soportar iniciativas que son

inconsistentes con las premisas que lo definieron
 Por ello, el modelo operacional es una elección de las estrategias que serán
soportadas
20
Dimensiones del Modelo Operacional
Estandarización Integración
 Define exactamente cómo será  Enlaza los esfuerzos
ejecutado un proceso homogéneo, organizacionales a través de
independientemente de quién lo esté información compartida, dentro de
llevando a cabo o dónde se realice procesos de punta a punta o a través
 Beneficios: de múltiples procesos
 Eficiencia (volumen de atención y  Beneficios:
productividad)  Eficiencia, coordinación, transparencia y
 Predictibilidad en la organización agilidad
 Desventajas:  Mejora del servicio al cliente
 Limitan la innovación en cada unidad  Mejor información para toma de decisiones
 Para implementarlo, podría requerirse poner  Simplifica el flujo de información en una
un sistema estándar de calidad inferior a organización
sistemas existentes (costo, dificultad, gestión  Desventajas:
del cambio)
 Definición de estándares de datos (formato)
 Por ejemplo:  Definición de un diccionario de datos
 Procesos de compras en diferentes unidades (términos)
 Se incurre en tiempo para estas definiciones
 Por ejemplo:
 Información de cuentas de ahorros accesible
al solicitar un crédito en un banco
21
Tipos de Modelos Operacionales (1 de 2)
 Las cuatro tipos de modelos operacionales, basándose en sus

dimensiones, son:
 Diversificación (baja estandarización, baja integración)
 Coordinación (baja estandarización, alta integración)
 Replicación (alta estandarización, baja integración)
 Unificación (alta estandarización, alta integración)
22
Tipos de Modelos Operacionales (2 de 2)
Coordinación Unificación
 Clientes, productos o proveedores compartidos  Los clientes y proveedores pueden ser locales o globales
Integración de Información de Negocios
 Impacto en transacciones de otras unidades de  Procesos de negocios integrados globalmente con apoyo
negocio de sistemas empresariales
 Operacionalmente funciones o unidades de  Las unidades de negocios tienen operaciones similares o
Alto
negocios únicas que se traslapan

 Gestión de negocios autónoma  Administración centralizada
 La unidad de negocios controla el diseño de  Dueños de procesos de alto nivel diseñan procesos
procesos estandarizados
 Datos compartidos  Bases de datos con información del negocio manejadas
 Consenso para diseñar los servicios de centralizadamente
infraestructura TI; decisiones sobre aplicaciones TI  Las decisiones sobre TI se toman centralizadamente
hechas en las unidades de negocios
Diversificación Replicación
 Pocos o ningún clientes y proveedores compartidos  Pocos, si los hay, clientes compartidos
 Transacciones independientes  Transacciones independientes agregadas en un alto
 Unidades de negocios operacionalmente únicas nivel
Bajo
 Gestión del negocio autónoma  Unidades de negocios operacionalmente similares

 La unidad de negocio favorece el control antes que  Líderes de las unidades de negocios autónomos, con
el diseño de procesos influencia limitada en los procesos
 Pocos datos estándares entre las unidades del  Control centralizado sobre el diseño de procesos
negocio  Definiciones de datos estandarizados, pero la propiedad
 La mayoría de las decisiones de TI se toman en las de la información es local con algunas definiciones
unidades de negocios centralizadas
 Servicios de TI gestionados centralizadamente
Bajo Alto
Estandarización de Procesos de Negocios 23

24
28
 Arquitectura Empresarial es la organización lógica de procesos de negocios e

infraestructura de tecnología de información, que refleja los requerimientos de
integración y estandarización del modelo operacional de la organización
 La clave para hacer una buena AE es

 Identificar los procesos, especialmente los claves (“capacidades” del negocio)
 Mapear los datos principales, compartidos, la metadata organizacional o modelo de datos
corporativo
 Identificar las tecnologías principales y troncales
 Identificar las interfaces de canales (usuarios internos, clientes de la organización)
 Para su implementación la organización debe entender su Modelo Operacional y

usar su arquitectura empresarial para mejorarlo continuamente
Modelo Operacional = Expectativas de integración y

estandarización entre unidades
Arquitectura Empresarial = Procesos claves, datos

y tecnología que componen las operaciones centrales
29
Diagrama Núcleo de Arquitectura Empresarial
 Análogo a los planos de un nuevo

edificio, la Arquitectura Empresarial se Objetivos del Diagrama
plasma en diagramas, principios, Núcleo
políticas y elecciones y definiciones
tecnológicas
• Permite entender de
manera común la AE
 El diagrama principal que describe de
manera macro e integral la Arquitectura
• Permite debatir y ajustar la
Empresarial es el Diagrama Núcleo AE, facilita las discusiones
• Muestra en alto nivel los
 Sin embargo, otros diagramas procesos clave, datos y
complementarán y detallarán el trabajo tecnología que constituye la
(datos, integración, estándares y Arquitectura
plataformas, hw/sw, etc.) • Clarifica los requerimientos
para llevar a cabo la AE
• Comunica la visión de
procesos de y TI de la
organización
30
Elementos del Diagrama Núcleo
 Procesos claves.- Define un conjunto estable de procesos que

representan las capacidades de la organización y que le permite
responder a oportunidades del mercado
 Datos compartidos.- Información clave que es consumida por los
procesos clave. Usualmente es información de clientes y productos,
aunque puede tener otros datos (empleados)
 Tecnologías de automatización e integración.- Software conocido
como middleware que permite integrar o conectar a las aplicaciones y
compartir información. La integración puede ser a nivel de
presentación (Portal), transacciones (EAI, ESB), procesos (BPM),
datos (MDM, CDI/PDI, EII), aplicaciones (business suites), etc.
 Canales clave.- Los canales o grupos de canales más importantes.
Canal=Punto de contacto con clientes, directamente o a través de
usuarios internos (empleados)
 Otros: Dimensiones, subcategorías o subclasificaciones, destacar
elementos claves, semáforos de status, códigos de colores, etc.
31
Arquitectura Empresarial por tipo
de Modelo Operacional
34
Diagrama Núcleo para Modelo de Unificación
 Alta estandarización y alta integración

 Se debe conectar tanto procesos como compartir información
 La misma tecnología se usa para procesos en diferentes unidades de negocios
 Los procesos son reusables
 Los datos son expuestos a través de servicios comunes de información
35
Diagrama Núcleo de Unificación
ENTRADAS
Tecnologías
Procesos Datos
Canales clave de
clave Compartidos
Integración
Tecnologías de
Automatización
Requerido
Opcional
Tecnologías de
Procesos de
Integración
Negocios
ARQUITECTURA
Datos
Tecnología
Canales
36
Diagrama Núcleo para Modelo de Diversificación
 Baja estandarización y baja integración

 Cada unidad de negocio ejecuta con cierta independencia, aunque pueden existir
oportunidades para compartir servicios en la organización
 El diagrama podría mostrar sólo los servicios de tecnología compartida, que
pueden ser bastante restrictivos o básicos
 Un extremo de la diversificación es la falta total de Arquitectura Empresarial
(unidades totalmente independientes, sin sinergias entre sí)
 Sin embargo, usualmente existe una mínima economía de escala en
infraestructura de TI (hardware, software, centros de datos, outsourcing, BPOs,
negociaciones o compras centralizadas, helpdesk, etc.)
37
Diagrama Núcleo de Diversificación
ENTRADAS
Tecnologías Procesos Datos Canales
Requerido
Opcional
Procesos de
Tecnología Negocios
ARQUITECTURA
Datos
Plataformas Tecnológicas Tecnología
Canales
38
Diagrama Núcleo para Modelo de Coordinación
 Baja estandarización y alta integración

 El foco es compartir información
 Se identifica la tecnología que permite a las partes interesadas acceder a esa
información
 No es tan necesario mostrar los procesos en el diagrama, dado que suelen ser
únicos; sin embargo, al menos un proceso o pocos que deben ser coordinados,
podrían ser representados
39
Diagrama Núcleo de Coordinación
ENTRADAS
Canales Datos Tecnologías Procesos
Requerido
Opcional
Procesos
ARQUITECTURA
Datos
Tecnología
Canales
40
Diagrama Núcleo para Modelo de Replicación
 Alta estandarización y baja integración

 Los procesos son estandarizados y son implementados con tecnología de
automatización: workflow, BPM
 La replicación de procesos permite escalar rápidamente al negocio en líneas de
productos similares o con poco cambios
 Los procesos se pueden identificar como categorías de servicios comunes, que
permiten a la organización atender nuevas oportunidades de negocios
 Raramente se ve información, dado que es poco compartida
 Se muestra tecnología que enlaza a los procesos o que los rodea permitiendo
compartirlos: business modules
41
Diagrama Núcleo de Replicación
ENTRADAS
Procesos Tecnologías Datos Canales
Requerido
Opcional
Procesos
ARQUITECTURA
Datos
Tecnología
Canales
42
43
Actividad:
Diagrama Núcleo de Talibank
44
ACTIVIDAD
Diagrama Núcleo de Talibank
 Conformar grupos
 Obtener sus materiales: plumones, papelógrafo y masking tape
 De acuerdo a lo revisado en el Caso Talibank:

 Diseñe el diagrama núcleo del modelo operacional TO BE de Talibank
 Incorporar todos los elementos del diagrama: proceso, datos, canales y tecnología de
integración
 Tiempos
 Discusión y elaboración 30”
 Exposiciones 20”
 Realizar la exposición al aula
45
46
Etapas evolutivas de la Arquitectura
Empresarial
47
Cuatro etapas de la evolución de la AE
 Silos de negocios
 Las organizaciones maximizan las necesidades de negocios o funcionales de unidades
individuales
 Tecnología estandarizada
 Busca eficiencias en TI a través de la estandarización de tecnología, centralizando la gestión
tecnológica
 Núcleo optimizado
 Incrementa la estandarización de datos y procesos basándose en el Modelo Operacional
 Modularidad del negocio

 Se definen “módulos de negocios”, que son grupos de funciones desacopladas que permiten
recomponer procesos, logrando estandarización y particularización configurable o paramétrica
48
Evolución de la Arquitectura Empresarial
Evolución de la Arquitectura
Silos de Tecnología Núcleo Modularidad de

Negocios Estandarizada Optimizado Negocios
Aplicaciones
100% 15% especializadas
16%
25% por unidad de
36% negocios
Porcentaje de Inversión en TI
Sistemas
32% 34%
corporativos
21%
18%
35% 33% Infraestructura

40%
compartida
35% (hw/sw)
17% 18% Datos

14%
11% compartidos
0%
12% 48% 34% 6%
% Empresas en la etapa
49
Silos de negocios
 La organización enfoca sus inversiones en TI en dar soluciones a problemas

específicos y especializados de las unidades de negocios
 Servicios compartidos como centros de datos, para aprovecharse de manera
separada
 Pocos o ningún estándar de TI
 Las inversiones de TI se basan en la reducción de costos por unidad de
negocios
 Cada unidad de negocio compra aplicaciones de manera individual para
satisfacer necesidades propias
 Los sistemas satisfacen al 100% las necesidades de cada unidad de negocios
 No se ponen restricciones de TI a las unidades de negocios, por lo que éstas
explotan su innovación al máximo
 Esto crea aplicaciones que no pueden interactuar entre sí
 Modificar aplicaciones, incluso cambios pequeños, puede ser demorado,
costoso y riesgoso
 Esta etapa obstruye la integración y estandarización de procesos de negocios
50
Silos de negocios - Esquema
Unidad 1 Unidad 2 Unidad 3 Unidad 4

ERP ERP ERP ERP
CRM CRM CRM CRM
CORE CORE CORE CORE
Correo, File Server, Correo, File Server, Correo, File Server, Correo, File Server,
Intranet, Otros Intranet, Otros Intranet, Otros Intranet, Otros
Hardware Hardware Hardware Hardware
51
Tecnología estandarizada
 Las inversiones en TI son a nivel de la organización

 Las organizaciones en esta etapa intentan reducir las tecnologías
 Menos plataformas tecnológicas significa menos opciones de infraestructura,
aplicaciones, proveedores, contratos, niveles de servicio, costos, etc.
 El énfasis de la unidad de negocios cambia de innovación a optimización de
costos y preservación de estándares
 Es clave una gestión centralizada de los estándares
 La estandarización reduce riesgos y promueve costos de servicios
compartidos (soporte, mantenimiento, compras) y da confiabilidad,
predictibilidad, seguridad y optimización del tiempo
 Las unidades de negocios buscan hallar la mejor solución tecnológica de
acuerdo a los estándares existentes: La mejor opción funcional podría ser
rechazada si no cumple los estándares
 Muchas organizaciones en esta etapa promueven estandarización y
compartición de información, usualmente implementando un
Datawarehouse; sin embargo, los datos transaccionales siguen separados
52
Tecnología estandarizada - Esquema

ERP ERP ERP ERP
CRM CRM CRM CRM
CORE CORE CORE CORE
BD /
DWH
Correo, File Server, Intranet, Otros
Hardware
53
Núcleo optimizado
 Las organizaciones se mueven de una vista particularizada de datos y

aplicaciones a una vista integral (corporativa)
 TI minimiza la redundancia de datos, dando acceso democrático a la
información operacional o transaccional, además de la de gestión
 El uso de interfaces estándares se incrementa
 Se empieza a estandarizar procesos de negocios
 Cambios básicos a los procesos de negocios o información, suele ser más
difícil, pero construir nuevos productos y servicios en la tecnología ya
existente suele ser más rápido
54
Núcleo optimizado - Esquema

ERP
CRM CRM
CORE CORE CORE
Correo, File Server, Intranet, Otros
Hardware
Base de datos
Servicio Proceso estándar
compartida 55
Modularidad de negocios
 Permite agilidad en el negocio, a través del uso de módulos reusables

 Es necesario tener los procesos del negocio documentados y hacer análisis
profundos para identificar esos módulos
 Las unidades de negocios pueden recomponer sus procesos basados en los
módulos reusables o usar interfaces de usuarias dinámicas que permiten usar la
variedad funcional disponible
 La estandarización se mantiene y se extiende y profundiza a más interfaces y
procesos
 Las organizaciones deben descubrir las oportunidades estratégicas para
modularizar y reusar
56
Modularidad de negocios ~ SOA
Consumidores
Aplicación 1 Canal 1 Canal 2 Canal 3 Aplicación 2
de Servicios
Seguridad
Procesos
Seguridad
Servicios
Seguridad
Proveedores
57
Gestión durante la evolución de la
AE
59
Prácticas de gestión para evolucionar la arquitectura
Introducción
 Diversas prácticas de gestión facilitan el desarrollo de capacidades de TI y
cambios en el proceso de negocio
 Esto aplica a los roles formales: arquitectos de proyecto, responsables de

procesos, Comité de proyecto, etc.
 Menos del 70% de empresas han establecido equipos de arquitectos a tiempo

completo (datos de EEUU)
60
Prácticas de gestión por fase de la evolución de la
Silos de Negocios Tecnología Estandarizada Núcleo Optimizado Modularidad de Negocios
Casos de negocios
Metodología de proyectos
 Comité de gobierno de TI
Proceso de renovación de la
infraestructura
Gestión presupuestal centralizada para
aplicaciones empresariales
Proceso de cumplimiento formal de
estándares y lineamientos de arquitectura
Arquitectos en equipos de proyectos
Proceso de excepción de arquitectura
Centralización de estándares
Dueños de procesos
 Principios
empresarial
que guían la arquitectura
Liderazgo del negocio de los equipos

de proyectos
 Supervisión de la arquitectura
empresarial por ejecutivos senior
Program Managers de TI
Diagrama Núcleo de Arquitectura
Empresarial
Evaluación post-implementación
Proceso de investigación y adopción
tecnológica
Equipo de arquitectura a tiempo completo
61
80
Gobierno de TI
91
Gobierno Corporativo o Empresarial consiste en proveer
una estructura de gestión para…
• Determinar objetivos
organizacionales
• Monitorear el desempeño para
asegurar que los objetivos son
atendidos
97
Gobierno Corporativo y Activos Clave Gobierno de TI
Gobierno Corporativo
Otros
Shareholders
stakeholders
Directorio
Monitoreo Suministro de
información
Equipo Ejecutivo Senior
Comportamiento
Estrategia
deseable
Activos clave
Activos de Activos de
Activos Activos Activos Activos de
Propiedad Información y
Humanos Financieros Físicos Relacionamiento
Intelectual de TI
Mecanismos de Gobierno
Mecanismos de Gobierno de TI
Financiero
(comités, presupuestos, etc.)
(comités, presupuestos, etc.)
Gobierno de Activos Clave
98
Gobierno de TI o IT Governance es…
Especificar los derechos de

decisión y el marco de rendición
de cuentas para alentar el
comportamiento deseable en el uso
de TI
99
El Gobierno de TI debe responder 3 preguntas clave
1. ¿Qué decisiones deben ser

tomadas para asegurar una gestión
y uso efectivo de TI?
2. ¿Quién debe tomar estas

Gobierno de TI decisiones?
3. ¿Cómo serán tomadas y

monitoreadas estas decisiones?
100
La Matriz de Arreglos de Gobierno de TI responde a las
dos primeras preguntas
1. ¿Qué decisiones deben ser tomadas para asegurar una gestión y uso
efectivo de TI?
Decisión
Necesidades
Estrategias de
Principios de Arquitectura de Inversión
Infraestructura
TI de TI Aplicaciones de TI
de TI
Arquetipo de Negocios
Monarquía
de Negocios
Monarquía
de TI
2. ¿Quién Feudal
debe tomar
estas Federal
decisiones?
Duopolio
Anarquía
Desconocido
101
Conceptos de la Matriz de Arreglos de Gobierno de TI
Determina los Define las necesidades del negocio
Define los servicios
requerimientos de para aplicaciones de TI compradas o
compartidos y desarrolladas
integración y habilitadores de la
Define el rol de TI estandarización
en el negocio TI Escoge las iniciativas
a financiar y cuánto
gastar
Gerentes del Decisión

Necesidades
más Alto Estrategias de
Principios Arquitectura de Inversión de
Nivel Infraestructura
de TI de TI Aplicaciones TI
de TI
Arquetipo de Negocios
Especialistas
de TI
Monarquía
de Negocios
Cada unidad de negocios Monarquía
toma decisiones de TI
independientes
Feudal Dentro de la matriz se indica quién
Centro corporativo y las toma qué decisión, con los
Federal
unidades de negocios con comentarios o aclaraciones que se
o sin involucración de TI
Duopolio requiera
TI y otro grupo (líderes
de unidades de Anarquía
negocios o los gerentes
de más alto nivel) Desconocido
Individuos aislados
o pequeños grupos No se tiene idea
102
1. ¿Qué decisiones deben ser
Decisiones claves del Gobierno de TI tomadas para asegurar una
gestión y uso efectivo de TI?
Principios de TI
Definiciones de alto nivel acerca de cómo es utilizado TI en el negocio
Infraestructura de TI
Arquitectura de TI Servicios de TI centralizados,
Organización de datos, coordinados y compartidos
aplicaciones e que proveen las bases para
infraestructura definida en las capacidades TI de la Inversiones de TI
un conjunto de políticas, organización Decisiones sobre cuánto y
relacionamientos y en qué realizar inversiones
elecciones técnicas para Necesidades de aplicaciones de TI, incluye técnicas para
implementar los de negocios justificación y aprobación
requerimientos de Especificaciones sobre las de proyectos
negocios y técnicos sobre necesidades del negocio
estandarización e para aplicaciones de TI
integración compradas o desarrolladas
internamente
103
Temas más importantes por cada
Decisión Clave de TI (1 de 3)
 Principios de TI
 ¿Cómo relacionar el Modelo Operacional a principios de TI para guiar la toma de
decisiones?
 ¿Cuál es el rol de TI en el Modelo Operacional?
 ¿Cuáles son los comportamientos deseables de TI?
 ¿Cómo se financiará TI, centralizadamente a nivel empresa o por cada unidad de
negocios?
 Arquitectura Empresarial de TI
 ¿Cuáles son los procesos de negocios núcleo de la empresa? ¿Cómo éstos están
interrelacionados?
 ¿Qué información es importante en estos procesos? ¿Cómo debe estar integrada
esta información?
 ¿Qué capacidades técnicas deberían estandarizarse en toda la empresa para
ganar eficiencias en TI y facilitar la estandarización e integración de procesos?
 ¿Qué actividades deben ser implementadas en la empresa para implementar la
integración de datos?
 ¿Qué opciones tecnológicas guiarán el enfoque de la compañía para iniciativas de
TI?
104
 Infraestructura TI
 ¿Qué servicios de infraestructura son los más críticos para mantener operando el Modelo
Operacional de la empresa?
 ¿Qué servicios de infraestructura deberían ser implementados a través de toda la empresa?
 ¿Cuáles son los requerimientos de acuerdo de nivel-de-servicio (SLA Service Level Agreement)
de esos servicios?
 ¿Cómo deberían ser cotizados y contratados los servicios de infraestructura de TI?
 ¿Cuál es el plan para mantener la tecnología actualizada?
 ¿Qué servicios de infraestructura deberían ser tercerizados (outsourcing)?
 Necesidades de Aplicaciones de Negocios

 ¿Cuáles son las oportunidades del mercado y de los procesos de negocios para nuevas
aplicaciones empresariales?
 ¿Cómo se puede mapear las necesidades del negocio con los estándares de arquitectura?
 ¿Cuándo una necesidad del negocio justifica una excepción a los estándares de arquitectura?
 ¿Quién se responsabilizará de los gastos de los proyectos e instituirá cambios organizacionales
para asegurar valor?
 ¿Qué experimentos estratégicos deberían realizarse? ¿Cómo debería ser medido su éxito?
105
 Priorización e Inversión de TI
 ¿Qué mejoras o cambios en los procesos son estratégicamente los más
importantes para la compañía?
 ¿Cuál es la distribución de los recursos en el portafolio actual de TI? ¿Es este
portafolio consistente con los objetivos de la empresa?
 ¿Cuál es la importancia relativa de lo general para toda la empresa con respecto a
las inversiones de cada unidad de negocios? ¿Las actuales prácticas de inversión,
reflejan su importancia relativa?
 ¿Cuál es el balance correcto entre proyectos realizados top-down y bottom-up para
balancear la estandarización e innovación?
106
Arquetipos de Gobierno de TI para toma de 2. ¿Quién debe tomar estas
decisiones?
decisiones
Estilo ¿Quién toma la decisión o provee insumos para ello?
Monarquía de negocios Un grupo de ejecutivos de negocios, gerentes o ejecutivos

individuales. Incluye comité de los gerentes en el que
podría participar el gerente de sistemas
Monarquía de TI Individuos o grupos de gerentes o ejecutivos de TI
Feudal Líderes de unidades de negocios, dueños de procesos

clave o personas delegadas por ellos
Federal Ejecutivos senior (C-level) y grupos de negocios, podría

incluir participantes adicionales
Duopolio de TI Ejecutivos y gerentes de TI con otros grupos del negocios o

relacionados a procesos
Anarquía Cada usuario individual
107
3. ¿Cómo serán tomadas y
Principales Mecanismos de Gobierno de TI monitoreadas estas
decisiones?
Grado de Efectividad
Tipo Mecanismo
uso (sobre 5)
Comité de ejecutivos o gerentes de más alto nivel 90% 3.5
Comité de jefes o gerentes de TI con participación de gerentes del 85% 3.8
negocio
Equipos de procesos con miembros de TI (analistas u otros roles) 85% 3.4
Estructuras
Administradores de relación Negocios-TI (brokers de negocios, 82% 3.9
para Toma de
broker de sistemas, asesores)
Decisiones
Consejo de TI, que comprende ejecutivos del negocio y de TI 70% 3.7
Comité de Arquitectura 65% 3.1
Comité de Aprobación de Capital (o de Presupuesto o de Finanzas 55% 3.1
o de Productividad)
Seguimiento a proyectos de TI y recursos consumidos 95% 3.4
Procesos de Acuerdos de nivel de servicio (SLAs) 90% 3.2

Alineamiento Monitoreo formal del valor del negocio de TI 60% 2.9
Chargeback 60% 2.8
Trabajar con jefes o gerentes que no siguen reglas de TI 90% 3.2
Enfoques de Anuncios realizados por gerentes 85% 2.9

Comunicación Oficio del CIO u Oficina de Gobierno de TI 82% 3.6
Portales e intranets de TI 78% 2.9
108
111
Actividad:
Diagnóstico de
Matriz de Arreglos de Gobierno
112
ACTIVIDAD
Diagnóstico de Matriz de Arreglos de Gobierno
 Conformar grupos
 Obtener sus materiales: plumones, papelógrafo y masking tape
 De acuerdo a lo revisado con los conceptos de Gobierno de TI:
 Elija una empresa
 Identifique las decisiones y los arquetipos existentes en esa empresa
 Construya una Matriz de Arreglos de Gobierno y coloque la información diagnosticada
 Al exponer describa cómo se aplica el gobierno en la empresa, usando como guía la matriz
 Tiempos Decisión
Necesidades
Estrategias de
 Discusión y elaboración 40” Principios Arquitectura
Infraestructura
de Inversión
de TI de TI Aplicaciones de TI
 Exposiciones 20” de TI
de Negocios
Arquetipo
Monarquía
de Negocios
Monarquía
de TI
Feudal
Federal
Duopolio
Anarquía
Desconocido
113
114
Ciclo de Vida de la Tecnología
115
Ciclo de Vida de una Tecnología
Máximo
Pico de Aprovechamiento
Evaluación y Expectativas
Selección (Modelo /
Producto / Mantenimiento y
Proveedor) Soporte
Estabilización
Operativa
Crecimiento de
Expectativas Estabilización para
Producción Desuso /
Obsolescencia
Investigación
Decepción Remplazo
requerido
Estabilización
TIEMPO
116
Investigación
 Identificación de necesidades del

negocio Pico de
Máximo Aprovechamiento
 Ver maduración del diseño Producto / Proveedor) Mantenimiento y Soporte
organizacional Estabilización
Operativa
Crecimiento de
 Estructura Expectativas
Estabilización para
Desuso /
Producción
Obsolescencia
 Puestos
Investigación
 Indicadores Decepción Remplazo
requerido
 Roles
Estabilización
 Procesos TIEMPO
 Enlaces
 Identificar requerimientos de
automatización
 Investigar paradigmas, tendencias,
soluciones del mercado
 Proveedores
 Gartner, Forrester, IDC, McKinsey,
PWC, etc.
 Empresas de referencia
117
Crecimiento de expectativas
 Información en medios de prensa,

revistas y medios audiovisuales Pico de
 Información por Internet Producto / Proveedor) Mantenimiento y Soporte
 Ofrecimientos de vendedores, Estabilización

Operativa
Crecimiento de
proveedores, consultores Expectativas

Obsolescencia
 Pruebas de concepto o pilotos Investigación

Remplazo
Decepción
financiados por empresas dueñas requerido
de productos Estabilización
 “Casos de éxito” generados por TIEMPO
vendedores
118
Evaluación y Selección
 Se debe tener un proceso formal

de selección cualitativa y Pico de
cuantitativa Selección (Modelo /

Producto / Proveedor) Mantenimiento y Soporte
 Se puede elegir el modelo de Estabilización

Operativa
trabajo (BPM, SOA, MDM, etc.), el Crecimiento de

Expectativas
Desuso /
Producción
producto (suite Websphere, Obsolescencia
Netweaver, Teradata, etc.) o el Investigación

Decepción Remplazo
requerido
proveedor (IBM, Microsoft, Oracle,

SAP, etc.) Estabilización
TIEMPO
 Cada selección marca la ruta de

habilidades, expertos en el
mercado, organización de TI,
manejo del frente usuario, ruta de
evolución tecnológica, etc.
119
Pico de expectativas
 Ocurre cuando existe una

asociación entre la necesidad del Pico de
usuario (demanda) y la oferta que Selección (Modelo /

aparentemente cubre un producto, Estabilización

Operativa
modelo o proveedor Crecimiento de
Expectativas
 Siempre a este enganche le falta la Obsolescencia
realidad que da una Investigación

Decepción Remplazo
requerido
implementación y la complejidad
de los detalles Estabilización
TIEMPO
120
Decepción
 Ocurre cuando la necesidad del

usuario (demanda) y la oferta Pico de
REAL del producto, modelo o Selección (Modelo /

proveedor encuentran divergencias Estabilización

Operativa
 Típicamente el producto no cubre Crecimiento de

Expectativas
Desuso /
Producción
todo o parte de las expectativas o Obsolescencia
los detalles no satisfacen Investigación

Decepción Remplazo
requerido
completamente
Estabilización
 Otros aspectos asociados al TIEMPO
producto, como la calidad de

servicio, los niveles de servicio, la
capacitación, el soporte, entre
otros, afectan la percepción de
satisfacción de necesidad
121
Estabilización para producción
 Esta es una etapa crítica e inevitable

en toda implementación tecnológica Pico de
 Típicamente se omite de cualquier Selección (Modelo /

plan de proyecto Estabilización

Operativa
 Esta etapa incluye estabilización del Crecimiento de

Expectativas
hardware, de telecomunicaciones, Obsolescencia
software base, software principal, Investigación

Decepción Remplazo
requerido
parámetros, base de datos e

información, implementación del Estabilización
TIEMPO
monitoreo, mecanismos de control y
depuración, políticas de backup,
alertas de niveles de servicio,
servicios de mantenibilidad, equipo
de soporte (1er, 2do y 3er nivel),
seguridad, etc.
 Este periodo puede ser de horas o
meses
 Se puede dar múltiples veces en el
ciclo de vida debido a cambios
importantes en la solución
122
Máximo aprovechamiento
 En esta etapa el usuario aprovecha

al máximo la solución Pico de
 Los usuarios pasan por una curva Producto / Proveedor) Mantenimiento y Soporte
de aprendizaje inicial, para luego Estabilización

Operativa
tener su máxima productividad Crecimiento de

Expectativas
Desuso /
Producción
Obsolescencia
 La infraestructura soporta bien la

Investigación
carga transaccional, volumen de Decepción Remplazo

requerido
información, flexibilidad, etc. Estabilización
TIEMPO
123
Mantenimiento y soporte
 Ocurre cuando se requiere

corregir, complementar o mejorar Pico de
un aspecto de la solución Selección (Modelo /

 El mantenimiento suele ser Estabilización

Operativa
proactivo o reactivo Crecimiento de

Expectativas
Desuso /
Producción
Obsolescencia
 El soporte suele ser reactivo

Investigación
Decepción Remplazo
requerido
Estabilización
TIEMPO
124
Estabilidad Operativa
 Ocurre cuando la solución

presenta problemas técnicos que Pico de
producen inestabilidad Selección (Modelo /

 Inestabilidad implica: lentitud, Estabilización

Operativa
interrupción total o parcial, Crecimiento de

Expectativas
Desuso /
Producción
problemas funcionales, errores, Obsolescencia
procesamiento incorrecto, Investigación

Decepción Remplazo
requerido
problemas de visualización,
pérdida de información, Estabilización
TIEMPO
vulnerabilidades de seguridad
 La inestabilidad puede ser
manejada por incremento de
infraestructura o del soporte, pero
esto suele tener un límite
125
Desuso/obsolescencia
 Ocurre cuando la solución pierde

vigencia debido a Pico de
 Estabilidad operativa inviable Selección (Modelo /

 Falta de escalabilidad funcional Estabilización

Operativa
 Deja de cumplir el fin del negocio Crecimiento de
Expectativas
 Escasez de personas que conozcan Obsolescencia
la solución Investigación
Decepción Remplazo
requerido
 Pérdida de soporte del proveedor

dueño o creador de la solución Estabilización
 Imposibilidad de mantenimiento o TIEMPO
correcciones
126
Reemplazo requerido
 Una vez que se consolida la

obsolescencia, se inicia un nuevo Pico de
ciclo de vida Selección (Modelo /

Estabilización
Operativa
Crecimiento de
Expectativas
Obsolescencia
Investigación
Decepción Remplazo
requerido
Estabilización
TIEMPO
127
128
Actividad: Estado de la Tecnología
de Talibank
129
ACTIVIDAD
Tecnología de Talibank (40 minutos)

 Conformar grupos  De acuerdo a lo revisado en el Caso Talibank:
 Identifique 10 tecnologías de Talibank, 5 de ellas
 Obtener sus materiales: plumones,
aplicaciones. Pueden ser en uso o en evaluación; incluso
papelógrafo y masking tape estar al mismo tiempo
 Tiempos  Mapéelas en el ciclo de vida
 Discusión y elaboración 20”  Identifique siguientes acciones requeridas de acuerdo al
 Exposiciones 20” ciclo de vida
 Sustente el mapeo y las siguientes acciones
Pico de
Estabilización
Operativa
Crecimiento de
Expectativas Estabilización para
Desuso /
Producción
Obsolescencia
Investigación
Decepción Remplazo
requerido
Estabilización
TIEMPO
130
Especialidades y
Responsabilidades Primarias de
Arquitectura
131
Dimensión: es un frente técnico
 Una dimensión representa un frente o ámbito de la tecnología de una organización
 Este frente contiene tecnologías, productos, lineamientos, estándares y

procedimientos de trabajo y operación concretos
 La dimensión se especializa en dar ciertos servicios tecnológicos a la Arquitectura

Empresarial resolviendo necesidades específicas
132
Dimensiones clásicas de Arquitectura Empresarial
CANALES Canal 1 Canal 2 Canal 3 Canal 4 Canal 5
OPERACIONES: ADMINISTRACIÓN / CONTINUIDAD OPERACIONAL

PROCESOS
INFORMACION
Servicio 1 Servicio 2 Servicio 3 Servicio 4
INTEGRACIÓN
SEGURIDAD
SERVICIOS
Servicio 5 Servicio 6 Servicio 7 Servicio 8
Productos / Aplicación 1 Aplicación 2 Aplicación 3 Aplicación 4

Clientes
APLICACIONES / Servicios
PROVEEDORES DE
INFORMACIÓN Aplicación 5 Aplicación 6 Aplicación 7 Aplicación 8
Proveedores /
Empleados
DWH Logística
DMs
Oracle, DB2, Performance

SQL Server, Escalabilidad
Windows Unix / zOS Mid-
INFRAESTRUCTURA + Intel Linux Host range
Otros Alta disponibilidad
.NET, Java, Contingencia
WS, REST,
Web Dev, Recuperación
MQ, etc.
COBOL, otros
ante desastres
133
Dominio: es un frente del negocio
 Un dominio representa un agrupamiento lógico dentro de una organización, que

sirve para poder enfocarse en él.
 Un dominio puede ser una unidad del negocio, una especialidad del negocio, un
producto o grupo de productos, un cliente o grupo/segmento de clientes, una
empresa dentro de una organización, etc.
 El dominio puede contener organización, perfiles/puestos/roles, indicadores,

procesos, definiciones de productos/clientes, etc.
 Los dominios representan fronteras dentro del negocio que pueden ser traducidas
rápidamente a estructuras tangibles. Pueden ser concebidas como zonas de
responsabilidades del negocio y mapeados a objetivos de la organización.
 Los dominios pueden tener otros dominios dentro, a los que también se les puede
denominar sub-dominios
134
Dominios dentro de una organización Dominio de
Productos
Financieros
Dominio de
Créditos
Dominio de
Gestión Dominio de
Humana Tarjeta de
Créditos
Dominio de
Gestión de
Compensaciones
Dominio de
Dominio de Gestión de
Gestión de Desempeño
Capacitación
135
Descripción de especialidades de
Especialidad Descripción
• Define la ruta a seguir con respecto a paradigmas, modelos y plataformas TI
• Evalúa y selecciona tecnología de sistemas operativos, software base y software
Arquitectura de de escritorio
Dimensiones • Evalúa y selecciona o diseña componentes tecnológicos
• Gestiona el ciclo de vida, obsolescencia y renovación tecnológica
• Define lineamientos tecnológicos
Arquitectura de • Gestiona los estándares de TI (definición, publicación, casos especiales)

Estándares, Renovación • Gestiona las iniciativas de renovación tecnológica
• Administra el índice de complejidad
Tecnológica y Gestión de • Administra los portafolios de TI: Estándares, aplicaciones, servicios, procesos,
Portafolio TI infraestructura, información, seguridad, operaciones, etc.
• Absuelve consultas y asesora a los usuarios de los dominios

• Mantiene actualizada la información de y se mantiene informado de los temas de
TI relacionados a los dominios de negocios
Arquitectura de Dominios • Investiga, evalúa y define la ruta tecnológica de los dominios de negocios
• Evalúa y selecciona tecnología de negocio relacionada a los dominios
• Evalúa y define el diseño macro de los requerimientos de negocios
• Gestiona la estabilidad operativa de la tecnología de los dominios
Arquitectura de Proyectos • Define la arquitectura y diseño macro de los proyectos grandes de TI
• Gestiona los proyectos y requerimientos solicitados por arquitectura

Programa de Arquitectura
Arquitectura Experta / • Asesora y define la estrategia tecnológica para soluciones horizontales
Corporativa (multidominios) de diversas unidades de negocios o empresas del negocio
136
Especialidades de Arquitectura
en el Ciclo de Vida de la Tecnología
Arquitectura de Proyectos
Arquitectura de Dominios
Arquitectura de Estándares, Renovación Tecnológica y Gestión de Portafolio TI
Arquitectura de Dimensiones
Programa de Arquitectura
Arquitectura Experta / Corporativa
137
Servicios ofrecidos por Arquitectura en el Ciclo de Vida
de la Tecnología: Responsabilidades Primarias (RP)
RP01 Descubrimiento del negocio
RP02 Diagnóstico de la maduración del
negocio
RP03 Hoja de ruta del negocio
RP04 Evaluación y selección de soluciones
RP03
tecnológicas de negocios
RP07 RP02 RP12 RP05 Planificación Arquitectural de
RP05
Proyectos
RP01 RP04 RP11 RP06 Investigación tecnológica
RP06 RP09 RP07 Evaluación y selección de tendencias,
RP08 RP10
tecnologías y proveedores
RP13
RP14 RP08 Adopción tecnológica
RP15 RP09 Gestión de Dimensión de TI
RP16
RP17
RP10 Alineamiento arquitectural evolutivo
RP11 Evaluación, diagnóstico y acciones
Arquitectura de Proyectos RP05 para renovación tecnológica y
RP01 RP02 RP03 RP10
RP04
obsolescencia
RP11 RP12 RP12 Evaluación, diagnóstico y acciones
para estabilización operativa
Arquitectura de Estándares, Renovación
RP13 RP14 RP15 RP07 RP13 Gestión de la complejidad tecnológica
Tecnológica y Gestión de Portafolio TI
RP14 Gestión de Estándares de TI
RP17
Arquitectura de Dimensiones RP06 RP08 RP09
RP15 Gestión del Portafolio de activos de TI
Programa de Arquitectura RP16
RP16 Gestión del Programa de Arquitectura
TI
Arquitectura Experta / Corporativa RP17 Comunicaciones y Evangelización
138
RP01: Descubrimiento del negocio
 Consiste en describir la situación actual (AS IS) y futura (TO BE) del negocio, que
puede consistir en uno o varios dominios afines
 Se debe identificar el tipo de modelo operacional AS IS y TO BE
 Se debe identificar los procesos clave y otros procesos utilizados por la unidad
 Se debe mapear la información utilizada por el negocio: datos, estructura, origen,

destino, transformación o enriquecimiento, entre otras variables
 Se debe describir el diseño organizacional del negocio: organigrama, puestos y

roles, procedimientos, indicadores, etc.
 Es realizado por un Arquitecto de Dominio
139
RP02: Diagnóstico de la maduración del negocio
 Permite identificar la preparación del negocio para estructurar un portafolio de

proyectos e iniciativas que le permita avanzar en una gestión ordenada de su
arquitectura tecnológica
 Se evalúa la existencia de un diseño organizacional integral (procesos,

organigrama, puestos, indicadores, etc.)
 Se revisa la existencia clara y definida de owners: procesos, información y líderes

usuarios
 Se verifica la existencia de patrocinadores que puedan presentar y sustentar

cambios en la arquitectura
 Se revisar la existencia de requerimientos y necesidades evolutivas definidas,

principalmente para el TO BE
140
RP03: Hoja de ruta del negocio
 Establece las acciones que se debe realizar para evolucionar la arquitectura

tecnológica entre el hoy (AS IS) y el futuro deseado (TO BE)
 Estas acciones toman usualmente la forma de proyectos, programas y portafolios
 Es común que las iniciativas tengan interdependencias
 Se debe planificar para el corto plazo y largo plazo
AÑO AÑO AÑO AÑO

ACTUAL ACTUAL + 1 ACTUAL + 2 ACTUAL + 3
Proy 1 Proy 3 Proy 5

FUTURO
HOY
TO BE
AS IS Proy 2
Proy 4
Programa A
1. Proy 1 HOJA DE RUTA

2. Proy 2
3. Proy 3 ROADMAP
4. Proy 4
5. Proy 5
141
RP04: Evaluación y selección de soluciones
tecnológicas de negocios
 Es un procedimiento que permite la indagación, evaluación y selección de
soluciones tecnológicas orientadas a resolver un problema o conjunto de
problemas concretos del negocio
 Este procedimiento es estructurado y formal
 Se cuenta con indicadores de duración del procedimiento, cantidad de

proveedores considerados, comité de adquisición y selección, etc.
 Se realiza diversos métodos de interacción con proveedores como RFQ, RFI,

RFP, conferencia de proveedores, demos, pruebas de concepto, pilotos,
prototipos, entre otros
 Una solución tecnológica de negocio resuelve las necesidades de uno o varios

dominios. Podría ser ERP, CRM, SCM, MRP, Retail Suite, Core Banking, etc. Son
conocidos también como soluciones “verticales”
142
RP05: Planificación Arquitectural de Proyectos
 Permite definir las consideraciones que debe tener un proyecto con respecto a
diversos aspectos de la arquitectura tecnológica
 El procedimiento que se aplica es un Architectural Fit (Encaje de Arquitectura) que

permite:
 Asegurar el uso de estándares tecnológicos de software, hardware y telecomunicaciones
 Identificar posibles intersecciones o redundancias parciales entre diferentes componentes
tecnológicos del ecosistema de TI y darles un tratamiento
 Definir las interfaces e interacciones entre los componentes del proyecto y componentes
existentes
 Asegurar el cumplimiento de los lineamientos de las dimensiones de la arquitectura
 Identificar, evaluar y aprobar excepciones al cumplimiento de la arquitectura
 En general, un Arquitecto de Proyecto asesora también en la gestión y estrategia

del proyecto, debido a la estrecha interdependencia entre una estrategia
tecnológica adecuada y un proyecto que resulta exitoso. Por ejemplo:
 Incorporar actividades para estabilización para producción. Considera estabilización del
hardware, de telecomunicaciones, software base, software principal, parámetros, base de datos
e información, implementación del monitoreo, mecanismos de control y depuración, políticas de
backup, alertas de niveles de servicio, servicios de mantenibilidad, equipo de soporte (1er, 2do
y 3er nivel), seguridad, etc.
143
RP06: Investigación tecnológica
 Permite realizar un análisis enfocado de la tecnología
 El análisis consiste en buscar fuentes de información y evaluar a detalle tanto

modelos específicos de investigación como armar modelos ad hoc:
 Proveedores
 Consultores especializados (IDC, Gartner, Forrester, otros)
 Internet
 El enfoque debe asegurar que lo investigación esté orientada a una necesidad

concreta e insatisfecha del negocio. Para esto, es importante comprometer la
presentación de los resultados de la investigación en algún foro relevante (comité,
reunión de gerentes, conferencia, seminario, etc.)
 La tecnología investigada podría ser un modelo de referencia (SOA, BPM, etc.),

una tecnología cross (Datawarehouse, ERP, etc.) o una tecnología ad hoc (data
appliance, discos NAS, software suite de operaciones de TI, etc.)
144
RP07: Evaluación y selección de tendencias,
 Luego de realizar la investigación de un modelo de referencia, una tecnología
cross u horizontal, una tecnología ad hoc o un proveedor, este procedimiento
permite evaluar y seleccionar la mejor opción, entre diversos candidatos, que
necesita la empresa
 A diferencia de la selección de una solución de negocios, en este caso se debe

considerar a toda la organización y realizar una hoja de ruta propuesta para el uso
de esta tecnología o proveedor
 También se debe realizar métodos de interacción con proveedores como RFQ,

RFI, RFP, conferencia de proveedores, demos, pruebas de concepto, pilotos,
prototipos, etc.
145
RP08: Adopción tecnológica
 Procedimientos que permiten adaptar una tecnología para el uso de la empresa

 Esta adaptación debe considerar:
 Gobierno  Lineamientos técnicos
• Visión y Misión • Niveles de servicio
• Alcance • Requerimientos de monitoreo
• Objetivos Clave • Gestión del uptime y performance
• Principios guía • Gestión de la contingencia y recuperación ante
• Hoja de ruta de la evolución de la tecnología desastres
• Requerimientos que puede cubrir y escenarios • Requerimientos de soporte
• Políticas de seguridad
 Roles y responsabilidades • Estándares de interfaz de usuario
• D
• efinición de roles (¿Qué roles hay?) • Administración de metadata
• Competencias, conocimientos y capacitación • Lineamientos de desarrollo
requerida de los roles • Lineamientos de pruebas
• Asignación de roles (¿Quién efectúa qué rol?)
• Responsabilidad (Matriz RACI) (¿Qué  Procedimientos generales
responsabilidades tienen que existir?) • Crear nuevos elementos
• Cambios en la organización de TI y del negocio • Otorgar accesos
• Proveedores y expertos externos • Ampliar infraestructura
• Pasar a producción
 Infraestructura • Efectuar soporte post-producción
• Hardware
• Software
• Comunicaciones
146
RP09: Gestión de Dimensión de TI
 Permite administrar los aspectos de una dimensión tecnológica (Canales,

Procesos, Servicios, etc.)
 Esto implica desde la definición de políticas y lineamientos, hasta la investigación

(RP06), evaluación y selección de tecnologías específicas para la dimensión
(RP07), así como su implementación (RP08)
 Para esta gestión se debe administrar un portafolio o inventario de todos los

componentes tecnológicos de la dimensión, tanto de los genéricos como de los
verticales o de negocio
 Por ejemplo, para la dimensión canales puede haber 10 aplicaciones de canal,

además de diversas tecnologías genéricas para manejo de canales (software de
portal, de gestión de contenido, de colaboración, etc.)
147
RP10: Alineamiento arquitectural evolutivo
 Permite hacer micro-architectural-fit en requerimientos de mantenimiento y soporte

a las aplicaciones existentes
 Con esto, se garantiza que cambios que parecieran menores o pequeños tengan
un impacto posterior negativo en el ecosistema de TI
 La clave de este procedimiento es la rapidez y concreción de la evaluación, debido

a que se suele contar con poco tiempo para hacer una análisis eficaz
 Además de llevar a cabo una verificación con las mismas premisas que el
architectural fit, se debe realizar una proyección tipo what if con respecto al
cambio que se quiere realizar: ¿qué pasaría si la información crece?, ¿qué
pasaría si impacta interfaces u otros componentes?, etc.
148
RP11: Evaluación, diagnóstico y acciones para
renovación tecnológica y obsolescencia
 Este procedimiento permite monitorear y activar acciones de renovación
tecnológica cuando se acerca o se llega a la obsolescencia tecnológica
 Obsolescencia tecnológica ocurre cuando la solución pierde vigencia debido a

 Estabilidad operativa inviable
 Falta de escalabilidad funcional
 Deja de cumplir el fin del negocio
 Escasez de personas que conozcan la solución
 Pérdida de soporte del proveedor dueño o creador de la solución
 Imposibilidad de mantenimiento o correcciones
 La mayor parte de las ocasiones la renovación tecnológica se puede programar

con tiempo, pero muchas veces no existe la posibilidad de atender requerimientos
preventivos de renovación
149
RP12: Evaluación, diagnóstico y acciones para
estabilización operativa
 Este procedimiento permite monitorear y activar acciones de mantenimiento o
renovación tecnológica cuando el componente tecnológico comienza perder su
estabilidad operativa
 Inestabilidad operativa implica

 Falta de accountability, transparencia o auditabilidad del componente
 Lentitud
 Problemas de visualización, en el caso que el componente tenga una interfaz usuaria
 Aparición de errores
 Problemas funcionales o procesamiento incorrecto
 Pérdida de información
 Interrupción total o parcial del servicio
 Vulnerabilidades de seguridad y otros aspectos relacionados al riesgo
150
RP13: Gestión de la complejidad tecnológica
 Permite monitorear un indicador agregado del estado de los componentes del

ecosistema tecnológico. De acuerdo a lo que muestre el indicador, se define
acciones que se toma en forma de proyectos o iniciativas concretas
 Se define como complejidad tecnológica aquellos factores que limitan o impiden

un aprovechamiento apropiado del ecosistema TI o que resulte en un exceso de
costos u horas hombre para su administración
 Causas de la complejidad tecnológica son

 Demasiados componentes tecnológicos
 Componentes tecnológicos redundantes
 Desconocimiento de cuántos componentes tecnológicos existe
 Interfaces duplicadas o en abundancia
 Aplicaciones en desuso que usan infraestructura de TI
 Software adquirido atrasado en varias versiones
 Personalización de software adquirido que impide su migración
 Pocos componentes reutilizables
 Pocos componentes con una infraestructura escalable, con buena performance y
adecuadamente gestionada (alta disponibilidad, contingencia, recuperación ante desastres,
etc.)
151
RP14: Gestión de Estándares de TI
 Permite administrar los estándares tecnológicos
 Existe estándares tecnológicos para cada dimensión (software, hardware y

comunicaciones), además existe estándares de programación y de operaciones
 La gestión de estándares implica la administración de un portafolio de estándares,

la publicación y difusión de normas y lineamientos para uso de los estándares,
hacer diagnósticos para renovación o cambio del estándar, autorizar excepciones
a los estándares, entre otras funciones
152
RP15: Gestión del Portafolio de activos de TI
 Representa un conjunto de procedimientos para gestionar los activos de TI
 Activos de TI son
 Software adquirido
 Componentes de hardware y comunicaciones
 Servicios de TI contratados (outsourcing, cloud, SAAS, etc.)
 Estándares
 Aplicaciones propias
 Para cada activo existe un ciclo de vida que es manejado en la gestión de

portafolio
153
RP16: Gestión del Programa de Arquitectura TI
 Debido a las diversas iniciativas de Arquitectura implementadas como proyectos,

se requiere una gestión integral y coordinada de todas, por lo que se necesita un
programa
 Este programa articula proyectos gestionados directamente por la unidad de

Arquitectura, como aquellas realizadas fuera, pero vinculadas a las iniciativas
 En el programa se gestiona todos los aspectos requeridos: alcance, cronogramas,

presupuesto, etc.
 Se realiza la planificación de los proyectos, su seguimiento y monitoreo, ejecución

y cierre
154
RP17: Comunicaciones y Evangelización
 Es clave que Arquitectura maneja un modelo de comunicación continuo y en todos

los niveles de la organización
 Si bien Arquitectura tiene un fuerte componente técnico, es también un asesor y

consultor del negocio, por lo cual deben existir estrategias y personas apropiadas
para difundir, absolver dudas, orientar y promover todos los aspectos que le
competen
 Además de la comunicación verbal, Arquitectura debe manejar abundante

información escrita, sobre todo lo relacionado a procesos, procedimientos,
normas, lineamientos, etc. Además, es clave manejar muy bien el aspecto visual,
a través del uso de gráficos, diagramas, infografías, tablas, etc.
 Es muy importante contar con una BD centralizada con datos de todos los
aspectos de Arquitectura, de tal manera que la información que se divulgue por
diversos canales sea consistente y completa
155
156
Actividad: Aplicación de
Responsabilidades Primarias de
Arquitectura en Talibank
157
ACTIVIDAD
Aplicación de Responsabilidades Primarias de
Arquitectura en Talibank (40 minutos)
 Conformar grupos / Tiempos: Discusión y elaboración = 20” / Exposiciones = 20”
 De acuerdo a lo revisado en el Caso Talibank: Elija 3 unidades de Talibank y para cada una
determine 3 RPs que podrían ser aplicadas. Sustente cada caso.
RP01 Descubrimiento del negocio

RP03
RP02 Diagnóstico de la maduración del
RP07 RP02 RP12 negocio
RP05
RP03 Hoja de ruta del negocio
RP01 RP04 RP11 RP04 Evaluación y selección de soluciones
RP06 RP09 tecnológicas de negocios
RP08 RP10
RP05 Planificación Arquitectural de Proyectos
RP13
RP14 RP06 Investigación tecnológica
RP15 RP07 Evaluación y selección de tendencias,
RP16
RP17
RP08 Adopción tecnológica
Arquitectura de Proyectos RP05 RP09 Gestión de Dimensión de TI
RP01 RP02 RP03 RP10
RP04
RP10 Alineamiento arquitectural evolutivo
RP11 RP12 RP11 Evaluación, diagnóstico y acciones para
renovación tecnológica y obsolescencia
Arquitectura de Estándares, Renovación
RP13 RP14 RP15 RP07 RP12 Evaluación, diagnóstico y acciones para
Tecnológica y Gestión de Portafolio TI
RP17
estabilización operativa
Arquitectura de Dimensiones RP06 RP08 RP09
RP13 Gestión de la complejidad tecnológica
Programa de Arquitectura RP16
RP14 Gestión de Estándares de TI
RP15 Gestión del Portafolio de activos de TI
Arquitectura Experta / Corporativa RP16 Gestión del Programa de Arquitectura TI
RP17 Comunicaciones y Evangelización
158
Arquitectura Empresarial de TI y el
PETI
159
Arquitectura y el PETI
 Proyectos de Negocios
 Define el Modelo Operacional y la Arquitectura Empresarial
 Define el Modelo de Compromiso con el negocio y el Gobierno de TI
 Arquitectura asesora, propone y define la ruta tecnológica o Roadmap para lograr los fines del
negocio
 Evalúa y selecciona la solución tecnológica apropiada
 Proyectos Internos de TI
 Proyectos de Estabilidad operativa
 Proyectos de Seguridad
 Evaluación y selección de soluciones y tendencias tecnológicas
 Adopción tecnológica
• Pruebas de concepto
• Pilotos
 Roadmap tecnológico
160
161
162
Repaso Final
1. ¿Qué indica el Modelo Operacional? ¿Para qué sirve diagnosticar el tipo de

Modelo Operacional?
2. ¿Qué abarca Arquitectura Empresarial?
3. ¿Qué muestra el Diagrama Núcleo?
4. ¿Cuál es la relación entre el Modelo de Compromiso y el Comité de Gobierno de

TI?
5. ¿Por qué es importante conocer el ciclo de vida de la tecnología?
6. ¿Cuál es la importancia de la estabilización operativa?
7. Dé ejemplos de obsolescencia tecnológica
163
164

EGSI-08 - Arquitectura Empresarial de TI

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

EGSI-08 - Arquitectura Empresarial de TI

Cargado por

Copyright:

Formatos disponibles

Estrategia y Gestión de los Sistemas de Información

 Comprender en qué consiste Arquitectura Empresarial de TI (AETI)

 Entender la importancia de AETI para TI y para la empresa, desde el punto de

 ¿Cuál fue la motivación seguida en la construcción de la casa?

 ¿Qué principios o lineamientos de construcción se siguieron se siguieron?

 ¿Hubiera sido conveniente tener un arquitecto a cargo? ¿Por qué?

 ¿Sirvió la arquitectura implementada para SU propósito?

 Las organizaciones que buscan controlar y lograr el mejor desempeño, deben

 Las mejores empresas convierten a sus procesos en capacidades del negocio

 La Base Estratégica Organizacional, es la infraestructura de TI y los procesos de

 Llegar a un BEO es evolutivo

Iniciativas Iniciativas Iniciativas Iniciativas

Define límites estratégicos

Define capacidades clave Actualiza y evoluciona

Base Estratégica Organizacional

• Procesos de negocios clave

 Este objetivo de largo plazo, se logra a través de la ejecución de diversos

2012 2013 2014 2015

Proy 1 Proy 3 Proy 5

1. Proy 1 HOJA DE RUTA

Modelo de Enlace (Gobierno de TI)

 Puede ser implementado como

Redes y Servicios de Infraestructura

 Diferentes partes de la compañía dan diferentes respuestas a las mismas

 El modelo operacional es el nivel necesario de integración y estandarización

 Un modelo operacional permite la implementación rápida de iniciativas

 Sin embargo, el modelo operacional fallará al soportar iniciativas que son

 Las cuatro tipos de modelos operacionales, basándose en sus

 Diversificación (baja estandarización, baja integración)

 Coordinación (baja estandarización, alta integración)

 Replicación (alta estandarización, baja integración)

 Unificación (alta estandarización, alta integración)

negocios únicas que se traslapan

 Gestión del negocio autónoma  Unidades de negocios operacionalmente similares

Estandarización de Procesos de Negocios 23

 Arquitectura Empresarial es la organización lógica de procesos de negocios e

 La clave para hacer una buena AE es

 Para su implementación la organización debe entender su Modelo Operacional y

Modelo Operacional = Expectativas de integración y

Arquitectura Empresarial = Procesos claves, datos

 Análogo a los planos de un nuevo

 Procesos claves.- Define un conjunto estable de procesos que

 Alta estandarización y alta integración

 Baja estandarización y baja integración

Tecnologías Procesos Datos Canales

Plataformas Tecnológicas Tecnología

 Baja estandarización y alta integración

Canales Datos Tecnologías Procesos

 Alta estandarización y baja integración

Procesos Tecnologías Datos Canales

Diagrama Núcleo de Talibank

 Obtener sus materiales: plumones, papelógrafo y masking tape

 De acuerdo a lo revisado en el Caso Talibank:

 Realizar la exposición al aula

 Modularidad del negocio

Silos de Tecnología Núcleo Modularidad de

35% 33% Infraestructura

17% 18% Datos

 La organización enfoca sus inversiones en TI en dar soluciones a problemas

Unidad 1 Unidad 2 Unidad 3 Unidad 4

CRM CRM CRM CRM

CORE CORE CORE CORE

Hardware Hardware Hardware Hardware

 Las inversiones en TI son a nivel de la organización