4.planest-10 - Aspectos Avanzados de Estrategia de Tecnología de Información Ii

FACULTAD DE INGENIERÍA Y ARQUITECTURA
Aspectos Avanzados de
Estrategia de
Tecnología de Información II
Planeamiento Estratégico
Profesor Percy Diez Quiñones

Agenda
• Introducción: ¿Existe una arquitectura • Modelo de Compromiso
ideal o cualquiera sirve? • Gobierno de TI
• Base Estratégica Organizacional • Actividad: Diagnóstico de Matriz de
• El Modelo Operacional Arreglos de Gobierno
• Actividad: Identificación del Modelo • Ciclo de Vida de la Tecnología
Operacional de Talibank • Actividad: Estado de la Tecnología de
• Arquitectura Empresarial de TI Talibank
• Arquitectura Empresarial por tipo de • Especialidades y Responsabilidades
Modelo Operacional Primarias de Arquitectura
• Actividad: Diagrama Núcleo de Talibank • Actividad: Aplicación de Responsabilidades
• Etapas evolutivas de la Arquitectura Primarias de Arquitectura en Talibank
Empresarial • Arquitectura Empresarial de TI y el PETI
• Gestión durante la evolución de la AE • Repaso Final
• Actividad: Etapas Evolutivas de Talibank
Introducción:
¿Existe una arquitectura ideal o
cualquiera sirve?
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.
La Casa Winchester
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?
• ¿Hubiera sido conveniente tener un arquitecto a cargo? ¿Por qué?
• ¿Sirvió la arquitectura implementada para SU propósito?

Base Estratégica Organizacional
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

Las que mejor se
operaciones núcleo
desempeñan,
(core), con el fin de
integran tecnología
lograr agilidad en el
con procesos para
negocio y un
ser eficientes y
crecimiento
confiables
sostenible
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
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
Modelo operacional
BEO - Disciplinas clave
Modelo Operacional
Nivel necesario de integración y

estandarización de procesos de Una empresa con diferentes
negocio para entregar bienes y líneas de negocio, podría estar
servicios a los clientes. Contiene altamente o poco integrada y
el acuerdo de cómo se operará la estandarizada
organización
La integración, se refiere a que La estandarización, se refiere a

los procesos tengan una cara que diferentes unidades realizan
común a los clientes desde el los procesos de la misma
inicio al fin, manejando la manera. Esto crea eficiencias,
necesidad de manejar los pero limita la personalización.
mismos datos entre diferentes Ej.:
unidades de una organización. •Implementación corporativa de SAP.
Ej.: Caso de pago a fuerza de ventas de
Banco, AFP o Aseguradora
•Movistar: Telefonía Fija, TV y Móvil
•Grupo Interbank: Plaza Vea, Oeschle,
Interbank, Tu Entrada, Bembos
Arquitectura
BEO - Disciplinas clave: Empresarial
Arquitectura Empresarial
Este objetivo de largo plazo, se logra a

través de la ejecución de diversos
Consiste en la organización proyectos en una hoja de ruta que debe
estructurada, documentada y formal de Provee una vista de largo plazo (TO BE) habilitar elementos de la arquitectura y
los procesos del negocio y la de los procesos, sistemas y tecnologías, no sólo atender necesidades del
infraestructura de TI, que refleja los en comparación con la situación actual negocio del corto plazo (ROADMAP)
requerimientos de integración y (AS IS) •Riesgo: Proyecto apurado por fechas, pocos
estandarización del Modelo Operacional recursos para dedicar a temas de largo plazo, etc.
•Mitigación: Arquitectura es un stakeholder,
indicadores organizacionales por temas de
Arquitectura
AS IS + ROADMAP = TO BE
2021 2022 2023 2024 2025 2026 2027
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
Modelo de
BEO - Disciplinas clave: Enlace
Modelo de Enlace = Gobierno de TI
Puede ser
Este modelo permite implementado como
influenciar sobre las • Reuniones de revisión,
Es el mecanismo con decisiones en seguimiento y decisión
el que el negocio se proyectos para • Revisión de
alinea con los promover la documentación
• Lineamientos o reglas
proyectos de TI implementación de concretas
requerimientos de • Políticas o guías
Arquitectura • Principios o grandes
marcos de referencia
El gran problema en TI: Interoperabilidad
Datos de la Organización
Datos
Aplicaciones
Plataformas
Tecnológicas
Redes y Servicios de Infraestructura

Diagnóstico de un mal BEO
1. Poco control de activos de TI: contratos no gestionados, muchos proveedores, complejidad
tecnológica, obsolescencia tecnológica, aplicaciones redundantes, diversidad tecnológica, etc.
2. Diferentes partes de la compañía dan diferentes respuestas a las mismas preguntas de usuario con
respecto a alguna información de la organización
3. Implementar un requerimiento regulatorio es un esfuerzo mayor, requiriendo mucho sponsorship e
inversiones en infraestructura
4. El negocio carece de agilidad. Cada nueva iniciativa se siente como si empezara de cero
5. TI es consistentemente percibido como un cuello de botella
6. Hay diversos procesos de negocios haciendo la misma actividad en toda la organización, cada uno
con diferentes aplicaciones
7. La información que se requiere para tomar decisiones claves sobre productos y clientes, no está
disponible
8. Un parte importante del trabajo de algunas personas, consiste en sacar información de un sistema,
manipularla e ingresarla en otro sistema
9. La dirección, gerencia o jefaturas prefieren no discutir la agenda de TI
10. No se sabe si la organización está obteniendo buen valor de TI
El Modelo Operacional
El Modelo Operacional
El modelo operacional
es el nivel necesario
Un modelo
de integración y
operacional permite la
estandarización de
implementación
procesos de negocios
rápida de iniciativas
para la entrega de
estratégicas
bienes y servicios a los
clientes
Sin embargo, el
modelo operacional Por ello, el modelo
fallará al soportar operacional es una
iniciativas que son elección de las
inconsistentes con las estrategias que serán
premisas que lo soportadas
definieron
Dimensiones del Modelo Operacional
Estandarización Integración
◼ Define exactamente cómo será ejecutado ◼ Enlaza los esfuerzos organizacionales a
un proceso homogéneo, través de información compartida, dentro
independientemente de quién lo esté de procesos de punta a punta o a través de
llevando a cabo o dónde se realice múltiples procesos
◼ Beneficios:
◼ Beneficios:
 Eficiencia, coordinación, transparencia y agilidad
 Eficiencia (volumen de atención y productividad)  Mejora del servicio al cliente
 Predictibilidad en la organización  Mejor información para toma de decisiones
 Simplifica el flujo de información en una
◼ Desventajas: organización
 Limitan la innovación en cada unidad
 Para implementarlo, podría requerirse poner un
◼ Desventajas:
sistema estándar de calidad inferior a sistemas  Definición de estándares de datos (formato)
existentes (costo, dificultad, gestión del cambio)  Definición de un diccionario de datos (términos)
 Se incurre en tiempo para estas definiciones
◼ Por ejemplo:
 Procesos de compras en diferentes unidades ◼ Por ejemplo:
 Información de cuentas de ahorros accesible al
solicitar un crédito en un banco
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)

Tipos de Modelos Operacionales (2 de 2)
Coordinación Unificación
Integración de Información de Negocios

▪ Clientes, productos o proveedores compartidos ▪ Los clientes y proveedores pueden ser locales o globales
▪ Impacto en transacciones de otras unidades de negocio ▪ Procesos de negocios integrados globalmente con apoyo de
▪ Operacionalmente funciones o unidades de negocios sistemas empresariales
únicas ▪ Las unidades de negocios tienen operaciones similares o que se
▪ Gestión de negocios autónoma
Alto
traslapan
▪ La unidad de negocios controla el diseño de procesos ▪ Administración centralizada
▪ Datos compartidos ▪ Dueños de procesos de alto nivel diseñan procesos
▪ Consenso para diseñar los servicios de infraestructura TI; estandarizados
decisiones sobre aplicaciones TI hechas en las unidades ▪ Bases de datos con información del negocio manejadas
de negocios centralizadamente
▪ Las decisiones sobre TI se toman centralizadamente
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 nivel
▪ Unidades de negocios operacionalmente únicas ▪ Unidades de negocios operacionalmente similares
Bajo
▪ Gestión del negocio autónoma ▪ Líderes de las unidades de negocios autónomos, con influencia
▪ La unidad de negocio favorece el control antes que el limitada en los procesos
diseño de procesos ▪ Control centralizado sobre el diseño de procesos
▪ Pocos datos estándares entre las unidades del negocio ▪ Definiciones de datos estandarizados, pero la propiedad de la
▪ La mayoría de las decisiones de TI se toman en las información es local con algunas definiciones centralizadas
unidades de negocios ▪ Servicios de TI gestionados centralizadamente
Bajo Alto
Estandarización de Procesos de Negocios
Arquitectura Empresarial de TI
Arquitectura Empresarial es la La clave para hacer una buena AE es

organización lógica de procesos de • Identificar los procesos, especialmente los claves
(“capacidades” del negocio) Para su implementación la organización
negocios e infraestructura de • Mapear los datos principales, compartidos, la debe entender su Modelo Operacional
tecnología de información, que refleja metadata organizacional o modelo de datos
y usar su arquitectura empresarial para
los requerimientos de integración y corporativo
• Identificar las tecnologías principales y troncales mejorarlo continuamente
estandarización del modelo operacional
• Identificar las interfaces de canales (usuarios
de la organización internos, clientes de la organización)
Modelo Operacional = Expectativas de integración y

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

tecnología que componen las operaciones centrales
Diagrama Núcleo de Arquitectura Empresarial
Análogo a los planos de un nuevo
edificio, la Arquitectura Empresarial se Objetivos del Diagrama Núcleo
plasma en diagramas, principios,
políticas y elecciones y definiciones • Permite entender de manera
tecnológicas común la AE
• Permite debatir y ajustar la AE,
facilita las discusiones
El diagrama principal que describe de • Muestra en alto nivel los
manera macro e integral la Arquitectura procesos clave, datos y
Empresarial es el Diagrama Núcleo
tecnología que constituye la
Arquitectura
• Clarifica los requerimientos
Sin embargo, otros diagramas para llevar a cabo la AE
complementarán y detallarán el trabajo • Comunica la visión de
(datos, integración, estándares y procesos de y TI de la
plataformas, hw/sw, etc.) organización
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.
Arquitectura Empresarial por tipo
de Modelo Operacional
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

Diagrama Núcleo de Unificación
Tecnologías de Automatización
Requerido
Captar clientes
Opcional
Tecnologías de
Procesos de
Integración
Reclamo de clientes Negocios
App Movil
Clientes Datos
Proveedores Asistente Virtual
Productos
Empleados Tecnología
SAP ERP Web
Oracle CRM
Salesforce Call Center Canales
Vender producto
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.)
Diagrama Núcleo de Diversificación
Tecnología
Plataformas Tecnológicas
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
Diagrama Núcleo de Coordinación
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
Diagrama Núcleo de Replicación
Etapas evolutivas de la
Cuatro etapas de la evolución de la AE
Silos de negocios Tecnología estandarizada

•Las organizaciones maximizan las •Busca eficiencias en TI a través
necesidades de negocios o de la estandarización de
funcionales de unidades tecnología, centralizando la
individuales gestión tecnológica
Núcleo optimizado Modularidad del negocio

•Incrementa la estandarización de •Se definen “módulos de
procesos e integración de negocios”, que son grupos de
información basándose en el funciones desacopladas que
Modelo Operacional permiten recomponer procesos,
logrando estandarización y
particularización configurable o
paramétrica. Es básico para
lograr mayor “agilidad del
negocio”
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 por
16%
25% unidad de negocios
36%
Porcentaje de Inversión en TI
Sistemas
32% 34%
corporativos
21%
18%
35% 33% Infraestructura

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

14%
11%
0%
12% 48% 34% 6%
% Empresas en la etapa
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
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

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
Tecnología estandarizada - Esquema
ERP ERP ERP ERP
CRM CRM CRM CRM
CORE CORE CORE CORE
BD /
DWH
Correo, File Server, Intranet, Otros
Hardware
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
Núcleo optimizado - Esquema
ERP
CRM CRM
CORE CORE CORE
Correo, File Server, Intranet, Otros
Hardware
Base de datos
Servicio Proceso estándar
compartida
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
Para nuevas soluciones
1. Reusa
2. Compra
3. Construye
Modularidad de negocios (Microservicios, SOA, BPM, Component Model)
Consumidores Canal 1
Aplicación 1 Canal 2 Canal 3 Aplicación 2
de Servicios
Seguridad
Procesos
Seguridad
Servicios
Seguridad
Proveedores
Descripción de cada Etapa de la Evolución de la AE
(Consolidado)
Silos de negocios Tecnología estandarizada

• La organización enfoca sus inversiones en TI en dar soluciones a • Las inversiones en TI son a nivel de la organización
problemas particulares y diferentes de las unidades de negocios • Las organizaciones en esta etapa intentan reducir las tecnologías o
• Podría haber servicios compartidos como centros de datos, pero sólo plataformas que tienen
para posteriormente aprovechar esto de manera separada • Menos plataformas significan menos opciones de infraestructura,
• Existen pocos o ningún estándar de TI aplicaciones, proveedores, etc.
• Las inversiones de TI se basan en la reducción de costos por unidad • El énfasis de la unidad de negocios cambia de innovación a costos y
de negocios preservación de estándares
• Cada unidad de negocio compra aplicaciones de manera individual • Es clave una gestión centralizada de los estándares
para satisfacer necesidades propias • La estandarización reduce riesgos y costos de servicios compartidos
• Los sistemas satisfacen al 100% las necesidades de cada unidad de (soporte, mantenimiento, compras) y da confiabilidad,
negocios predictibilidad, seguridad y optimización del tiempo
• No se ponen restricciones de TI a las unidades de negocios, por lo • Las unidades de negocios buscan hallar la mejor solución tecnológica
que éstas explotan su innovación al máximo de acuerdo a los estándares existentes: La mejor opción funcional
• Esto crea aplicaciones que no pueden interactuar entre sí podría ser rechazada si no cumple los estándares
• Modificar aplicaciones, incluso cambios pequeños, puede ser • Muchas organizaciones en esta etapa promueven estandarización y
demorado, costoso y riesgoso compartición de información, usualmente implementando un
• Esta etapa obstruye la integración y estandarización de procesos de Datawarehouse; sin embargo, los datos transaccionales siguen
negocios separados
Núcleo optimizado Modularidad de negocios
• Las organizaciones se mueven de una vista particularizada de datos y • Permite agilidad en el negocio, a través del uso de módulos reusables
aplicaciones a una vista integral (corporativa) • Es necesario tener documentados los procesos del negocio y hacer
• TI minimiza la redundancia de datos, dando acceso democrático a la análisis profundos para identificar esos módulos
información operacional o transaccional • Las unidades de negocios pueden recomponer sus procesos basados
• El uso de interfaces estándares se incrementa en los módulos reusables o usar interfaces de usuarias dinámicas que
• Se empieza a estandarizar procesos de negocios permiten usar la variedad funcional disponible
• Cambios básicos a los procesos de negocios o información, suele ser • La estandarización se mantiene y se extiende a interfaces y procesos
más difícil, pero construir nuevos productos y servicios en la • Las organizaciones en esta etapa deben descubrir las oportunidades
tecnología ya existente suele ser más rápido estratégicas que deben modularizar y permitir reusar en esta etapa
Gestión durante la evolución de la
AE
Prácticas de gestión para evolucionar la arquitectura
Introducción
Diversas prácticas de Esto aplica a los roles Menos del 70% de

gestión facilitan el formales: arquitectos de empresas han establecido
desarrollo de capacidades proyecto, responsables de equipos de arquitectos a
de TI y cambios en el procesos, Comité de tiempo completo (datos
proceso de negocio proyecto, etc. de EEUU)
Prácticas de gestión por fase de la evolución de la Arquitectura
Empresarial
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 que guían la arquitectura

 empresarial
Liderazgo del negocio de los equipos de

proyectos
Supervisión de la arquitectura empresarial

 por ejecutivos senior
Program Managers de TI
Evaluación post-implementación
Proceso de investigación y adopción tecnológica
Equipo de arquitectura a tiempo completo

Prácticas de gestión de la fase Silos de Negocios
Casos de Negocios
• Descripción: Consiste en realizar un análisis completo y minucioso de los beneficios y costos
esperados en los proyectos de TI
• Estructura de un caso de negocios:
• Necesidad del proyecto, contexto, entorno y • Costo
• Directos e indirectos
antecedentes • Personas internas a la organización
• Descripción de lo que requiere que haga el • Inversiones y gastos (durante la vida del proyecto:
proyecto, diferenciando la solución o producto depreciación, amortización y otros)
que implementará el proyecto de lo que logrará • Gastos de mantenimiento después de la vida del
esta solución o producto para la organización proyecto
• Quiénes deben realizar, ejecutar o implementar • Beneficios
• Quiénes se beneficiarán interna o externamente a la
el proyecto y sus stakeholders organización
• Planteamiento de la forma en la que se hará el • Beneficios cuantitativos (ganacias, comisiones,
proyecto: proveedores, esfuerzo interno, intereses, utilidad) y cualitativo (mejora de la
metodologías o modelos, consultorías, productividad no medible, mejora de la infraestructura
adquisiciones, etc. –alta disponibilidad, tiempo de respuesta-, estabilidad
• Implicancias legales, regulatorias, de seguridad, operativa, satisfacción de pedidos legales y
regulatorios, transparencia, reputación, otros)
auditoria y de privacidad (de la empresa o de • Tiempos requeridos para implementar el proyecto y empezar
sus clientes) a obtener resultados
• Problemas potenciales y riesgos iniciales • Flujo de caja o modelo financiero de inversión-gasto
Prácticas de gestión de la fase Silos de Negocios
Metodología de proyectos estandarizada
• Descripción: Implementar un enfoque disciplinado y consistente para convertir el concepto del
proyecto en un proceso de negocio mejorado
• Existen diversos enfoques de Project Management, como el Tradicional, Cadena Crítica,
Extremo, Cadena de Eventos, PRINCE2, Basado en Procesos, etc. El enfoque Tradicional más
conocido es el promovido por el PMI
Prácticas de gestión de la fase Tecnología Estandarizada
Comité de Gobierno de TI
• Descripción: Consiste en conformar un comité con directores, gerentes o ejecutivos
clave, para que se reúnan periódicamente para conocer los principales eventos que
ocurren en TI, la relación negocios-TI y determinar prioridades estratégicas
• En este comité deben participar
• Responsables de más alto nivel de las líneas de negocios principales de la empresa
• Responsable de los aspectos financieros y presupuestales de la organización
• Responsable de la gestión de los riesgos
• Las principales cabezas de TI
• Algunas atribuciones que tiene este comité
• Aprobar el presupuesto monetario anual de TI, tanto en monto como en composición (es decir a qué
unidad de negocio debe destinarse cuánto)
• Aprobar la distribución de recursos humanos de TI para atender a las diferentes unidades de
negocios (esto conlleva a aspectos de capacitación y especialización)
• Dar prioridad a los proyectos solicitados por las unidades de negocios
• Validar y aprobar cualquier cambio importante a lo planificado y presupuestado de TI: Nuevos
proyectos, cambios en alcance o costos de proyectos en curso, etc.
Gestión presupuestal centralizada para aplicaciones empresariales
• Descripción: Las aplicaciones empresariales, aquellas que dan beneficios y soportan a
diversas unidades de negocios, se convierten en activos claves y en un estándar de la
empresa, por lo que se requiere reservar y controlar su inversión centralizadamente
• Una aplicación empresarial es aquella que representa una capacidad clave del negocio
• Para un banco, puede ser su Core Banking que le maneja las cuentas y créditos
• Para una fábrica de computadoras puede ser su MRP (Materials Resource Planning) que le ayuda a
estructurar sus pedidos y la fabricación
• Para un hotel puede ser su CRM (Customer Relationship Management) que maneja la relación con
los clientes, programas de lealtad, etc.
• Para una empresa de bebidas (gaseosa, cerveza) puede ser un SCM (Supply Chain Management) que
le ayudará a estructurar su cadena logística de suministro y distribución
• Usualmente las aplicaciones empresariales son adquiridas y consideradas world class, lo
que significa que incorporan las mejores prácticas del mundo, al incorporar
funcionalidades recurrentes solicitadas por clientes a lo largo de varios años
Proceso de renovación de la infraestructura
• Descripción: Consiste en la reserva y gestión de recursos (monetarios y humanos) para proyectos que
tienen como fin mantener a las tecnologías de la organización actualizadas y evitar su obsolescencia
• La actualización tecnológica debe contemplar tanto software, como hardware y comunicaciones,
enfocadas por los frentes de desarrollo, operaciones, seguridad, auditoria y riesgos
• Existen diversas formas de mantener actualizada la tecnología
• Software: Service packs, fixes, patches, releases, upgrades, soporte y mantenimiento anual
• Hardware: Disco, memoria y actualizaciones de procesadores en función a aspectos de consumo de CPU, volumen
transaccional y otros aspectos
• Comunicaciones: Ancho de banda, contingencia
• Las razones para actualizar pueden ser varias
• Desarrollo: Nuevos lenguajes de programación más potentes que aceleren el desarrollo, pérdida de soporte de
lenguajes antiguos, falta de conocimiento de lenguajes antiguos en el mercado (proveedores o nuevos empleados)
• Operaciones: Software con fallas, software sin soporte técnico, software sin capacidades de alta disponibilidad,
contingencia o recuperación ante desastres
• Seguridad: Vulneración de seguridad por hackers, elevación del nivel de seguridad
• Auditoria y riesgos: Falta de monitoreo, falta de mecanismos para dejar alertas tempranas
Proceso de cumplimiento formal de estándares y lineamientos de
arquitectura
• Descripción: Es un proceso para asegurar que los nuevos proyectos adopten los estándares y
lineamientos de arquitectura
• Los nuevos proyectos deben considerar
• Usar infraestructura de hardware, comunicaciones y software base estándar
• Seguir principios de arquitectura en cuanto a diversos aspectos de TI relacionados a: canales, servicios,
procesos, información, seguridad, operaciones
• Seguir procesos formales de evaluación y adquisición de soluciones tecnológicas (paquetes)
• Los estándares y lineamientos de arquitectura se definen de acuerdo a las capas o
componentes definidos en el Diagrama Núcleo
• Canales: Uso de canales estándares, interfaz de usuario, presentación de información
• Servicios: Reutilización de componentes existentes e implementar nuevos servicios reusables
• Procesos: Implementar flujos fácilmente modificables y lógica de negocio paramétrica
• Información: Diferenciar información operacional y de gestión (o analítica), definir el uso adecuado en
cuanto a volúmenes y recurrencia (momento), usar metadata estándar
• Seguridad: Usar sistemas de seguridad de la organización, cumplir con las políticas de seguridad de
acuerdo a lo requerido para el proyecto
• Operaciones: Dejar una solución que se pueda mantener (bajar y subir servicios, dejar logs para
monitoreo, dejar documentación de los componentes, etc.)
Arquitectos en equipos de proyectos
• Descripción: Consiste en incorporar a Arquitectos de Proyectos en los equipos de
los proyectos de TI que se realicen, quienes asegurarán que se incorporen los
estándares de arquitectura e identifiquen y releven las excepciones que son
necesarias aceptar
• Los arquitectos de proyectos deben ser

• Con experiencia en el desarrollo, puesta en marcha y/o operación de soluciones de TI
• Con profundo conocimiento del ecosistema de TI de la empresa
• Con profundo conocimiento de los estándares y lineamientos de arquitectura
• Con amplio conocimiento de metodologías de desarrollo, gestión de proyectos, operaciones
y arquitectura que use su organización
• Capacidad de sustento de su propuestas tecnológicas que genere
• Investigador y capaz de pasar con facilidad del análisis al diseño, del detalle a la síntesis
• Buenas relaciones con diversas personas de TI y capacidades de indagación, manejo de
relaciones personales, negociación
Proceso de excepción de arquitectura
• Descripción: Es un proceso formal para identificar las excepciones a los estándares y lineamientos de
arquitectura que agregan valor al negocio
• La implementación de estándares y lineamientos muchas veces requiere recursos considerados

“adicionales”
• “Seguir las reglas tiene un costo”
• Ej.: El software que es perfecto para una unidad de negocios podría estar en Visual Basic 6; sin embargo, el estándar en
la empresa es .NET. ¿Cuánto esfuerzo y tiempo se requiere para realizar la migración y cumplir con el estándar?
• Esta situación genera una pugna entre TI y la unidad de negocio, dado que los recursos asignados a la
unidad son escasos y con ellos tiene que subvencionar a arquitectura. Otro factor importante es el
tiempo adicional en el que se debe incurrir para esperar a que se cumpla con el estándar o lineamiento
• En este contexto, es posible identificar excepciones temporales o permanentes que generen valor al
negocio en el corto plazo
Centralización de estándares
• Descripción: Consiste en definir y mantener un equipo de gestión de estándares, un
grupo de técnicos expertos en identificar estándares apropiados y reconocer cuándo
actualizarlos o descontinuarlos
• Los estándares se definen en

• Hardware: PCs, servidores, plataformas de hardware estándares
• Comunicaciones: Equipos de comunicaciones, tipo de redes, contratos con Telcos
• Software: Software base (sistemas operativos, mail server, DB server, etc.), software de oficina o
productividad, software especializado para la empresa (núcleo o de apoyo)
• Las consideraciones para actualizar o descontinuar un estándar son

• Aceptación en la industria de TI, popularidad y grado de uso, ya que está correlacionado con el nivel
de soporte, evolución de la tecnología, actualizaciones por problemas y seguridad, conocimiento de
profesionales en el mercado, cadena de distribución de proveedores, etc.
• Capacidades requeridas por la empresa, en cuanto a alcance y eficiencia (rapidez de
implementación, costos)
• Consideraciones del proveedor contratado: soporte, actualizaciones, maduración
Prácticas de gestión de la fase Núcleo Optimizado
Dueños de procesos
• Descripción: Consiste en definir un único responsable para cada proceso
clave del negocio
• La persona responsable del proceso o “dueño” del proceso tiene como

encargos
• Definir el alcance del procesos, su inicio y fin y sus objetivos como valor para el
negocio
• Validar y aprobar las actividades que forman parte del proceso así como los roles
que las ejecutarán
• Identificar y validar métricas e indicadores de gestión (para monitorear el proceso),
e indicadores de desempeño (para medir el valor que el proceso le da al negocio, ya
sea en cuanto a generación de ingresos o reducción de costos)
• Tomar las decisiones finales alrededor de cambios importantes en el proceso
Principios que guían la arquitectura empresarial
• Descripción: Consiste en definir y poner en práctica principios que definen
decisiones importantes de TI para la organización
• Principio sugeridos por TOGAF (The Open Group Architecture Framework)
Principios de Negocios Principios de Datos
▪ Primacía de los principios ▪ Los datos son un activo

▪ Maximizar el beneficio para la empresa ▪ Los datos están compartidos
▪ El manejo de la información es ▪ Los datos son accesibles
preocupación de todos ▪ Los datos son confiables
▪ Continuidad de negocios ▪ Vocabulario común y definiciones de datos
▪ Aplicaciones de uso común ▪ Seguridad en los datos
▪ Cumplimiento de la ley
▪ Responsabilidad de tecnología
▪ Protección de la propiedad intelectual
Principios Técnicos
▪ Cambios basados en requerimientos

Principios de Aplicaciones ▪ Gestión del cambio responde
adecuadamente
▪ Independencia de la tecnología ▪ Controlar la diversidad tecnológica
▪ Facilidad de uso ▪ Interoperabilidad
Liderazgo del negocio de los equipos de proyectos
• Descripción: Ejecutivos de alto nivel se mantienen informados de los beneficios
esperados en los proyectos de TI y participan en los procesos de comunicación y
toma de decisiones de la gestión de proyectos
• Es clave que los usuarios participantes tengan al menos 3 roles

• Sponsor: Ejecutivo de alto nivel que vende el proyecto en la organización, lo representa y
ayuda a resolver problemas y mitigar riesgos de mayor complejidad. Debe asegurarse que el
proyecto logre el beneficio esperado para el negocio
• Líder Usuario: Ejecutivo de nivel intermedio que toma las decisiones finales en cuanto al
alcance del proyecto. Es el responsable directo de la forma y fondo de la solución de TI que
está siendo implementada
• Usuario definidor: Uno o más usuarios encargados de analizar las necesidades y problemas,
así como diseñar el alcance o funcionalidad que debe tener la solución de TI. Son
responsables de que la solución funcione de acuerdo a lo esperado
Supervisión de la arquitectura empresarial por ejecutivos senior
• Descripción: Revisión periódica, en un alto nivel, de las iniciativas de arquitectura
empresarial. Adicionalmente, se diseñan incentivos para animar la adopción de
arquitectura
• Los ejecutivos senior deberían ser los mismos que conforman el Comité de
Gobierno de TI, incluyendo al gerente general, director general o presidente de
la empresa
• La información que deben revisar los ejecutivos debe ser principalmente

• Principales avances en proyectos o iniciativas por periodo
• Hallazgos y principales decisiones de arquitectura realizadas y por realizar
• Indicadores de estándares, adopción tecnológica, habilitación de la arquitectura en
proyectos, reducción de complejidad tecnológica, etc.
Program Managers de TI
• Descripción: Los Program Managers tienen la responsabilidad de coordinar diversos
proyectos para identificar su integración y minimizar la redundancia
• Un programa puede ser

• Un conjunto de proyectos interrelacionados que aportan a un objetivo estratégico del negocio
• Un conjunto de proyectos agrupados debido a economías de escala y sinergias posibles en la gestión
de recursos, stakeholders, proveedores, estrategia de ejecución, arquitectura, etc.
• Temporal o permanente
• Los beneficios de incorporar program managers para beneficiar la arquitectura pasa por
• Identificación e implementación de sinergias dentro del programa (infraestructura técnica,
economías de escala en software comprado o desarrollado, enfoque integral, largo plazo,
presupuesto, proveedores)
• Aseguramiento del uso de los procesos y de las mejores prácticas en gestión de proyectos,
incluyendo el uso de estándares y lineamientos de arquitectura
• Identificación e incorporación de lecciones aprendidas en la gestión, con lo que se puede identificar
posibilidades de optimizar la arquitectura tecnológica
Prácticas de gestión de la fase Modularidad de Negocios
• Descripción: Es la herramienta que permite comunicar en un alto nivel, y
en un solo diagrama, los requerimientos de integración y estandarización
que necesita la empresa
• (Revisado anteriormente.)
Evaluación post-implementación
• Descripción: Es un proceso formal para identificar, documentar y comunicar las lecciones
aprendidas de cada proyecto
• No es algo que se realice sólo al final del proyecto; se requiere levantar información del
aprendizaje durante todo el proyecto
• La información de lecciones aprendidas incluye:

• Solución de problemas técnicos
• Historial de nuevos riesgos que de hecho se convirtieron en eventos, el porqué ocurrieron y cómo se
realizó su identificación, cuál fue su impacto y la forma en la que los enfrentó
• Historia de eventos que afectaron los tiempos y costos
• Problemas específicos de calidad
• Cotizaciones
• En general debe indicarse cada evento relevante y como se solucionó, y el conjunto completo
debe incorporarse a la base de datos de lecciones aprendidas de la empresa
Proceso de investigación y adopción tecnológica
• Descripción: Es un proceso formal para identificar las nuevas tecnologías que podrían tener un
impacto significativo en la empresa
• El proceso de investigación y adopción tecnológica, así como las personas que ejecutan ese
proceso, no realizan investigación por pura curiosidad científica. Parten de metas
preestablecidas que deben buscarse, de tal manera que los proyectos de investigación estén
enfocados
• Metas típicas en un proceso de investigación y adopción tecnológica

• Mejorar productos y servicios de la empresa
• Crear nuevos productos
• Mejorar métodos de producción
• Llevar a los procesos de la organización a un nuevo nivel de eficiencia y efectividad
• Reducir costos
• Diferenciarse de la competencia y liderazgo tecnológico
• Prever cambios en el entorno organizacional: clientes, gobierno, proveedores, empleados
Equipo de arquitectura a tiempo completo
• Descripción: Equipo de personas dedicadas permanentemente a tareas de
arquitectura empresarial, de tal manera que rápidamente estén disponibles para
dar soluciones estratégicas a necesidades tecnológicas del negocio
• El arquitecto TI es un
• Practicante de la tecnología Gestión Gestión del
• Constructor de consensos Técnica Negocio
• Orientado a los resultados
• Un generalista de TI y un experto en
tecnología
• Un diseñador de alto nivel
Arquitecto
Empresarial
• Define la forma, función y adecuación para una de TI
solución de TI propuesta
• El arquitecto TI guía o influye notablemente en

• El Jefe de Proyectos
• El constructor o desarrollador de la
solución
• Los expertos de productos o tecnología Diseño y
• El cliente o usuario final de la tecnología Desarrollo de
• Otros stakeholders Sistemas
Gobierno de TI
Gobierno de TI
“Liderazgo, estructuras organizacionales y

procesos que aseguran que la TI de una
organización sostenga y extienda las
estrategias y objetivos de dicha
organización.”
IT Governance Institute
Modelos de Gobierno de TI y herramientas relacionadas
Herramienta / Marco de Sirve principalmente para Aporta en el Gobierno de TI en
trabajo / Modelo
ITIL – Information Gestionar Servicios de TI, La Calidad de TI es el nivel de alineamiento
Technology enfocándose en los procesos de entre los servicios de TI y las necesidades del
Infraestructura Library negocios y las disciplinas clave para negocio
entregar y gestionar servicios con
una alta calidad
COBIT – Control Gestionar prácticas para la Definir diversos aspectos que TI debe
Objectives for seguridad y control de TI gestionar a través de procesos
Information and Related
Technology
CMM/CMMi – Capability Definir y refinar el proceso de Alinea el desarrollo de software con los
Maturity Model desarrollo de software de una objetivos y alcances dados por el negocio.
Integration organización Además, se evalúa la madurez de la
organización en función con el cumplimiento
de los procesos de CMMI
ISO 17799 / 27000 Series Estandarizar la seguridad de Punto de referencia central para proveer
información a través de controles y diversos controles necesitados para la mayoría
buenas prácticas de situaciones en donde se utilice TI para las
empresas comerciales
IT Governance Review Diseñar un sistema de gobierno de Plantea un alineamiento de TI al negocio a
and Assessment TI ad hoc para una organización través de un modelo estructurado e integrado
a la estrategia del negocio
Premisas sobre Gobierno de TI
Los stakeholders del negocio tienen Los ejecutivos de TI se alinean con el Dependiente de la variedad del portafolio
diferentes expectativas de TI negocio de diferentes maneras. Siempre de TI, las organizaciones desarrollan
•En algunas organizaciones TI es visto como un hay “algo” que es Gobierno de TI diferentes estilos de gobierno
proveedor interno de tecnología que debe dar •La habilidad de los jefes, gerentes o ejecutivos de TI •Las organizaciones suelen tener Sistemas de Registro
soporte a aplicaciones y equipos para relacionarse con el negocio es clave (transaccionales, operacionales) y Sistemas de Enlace
•En otras organizaciones TI es co-creador de las •En las organizaciones de alto desempeño, el CIO (innovación, canales web, BI, analíticos)
capacidades clave (relacionadas a los procesos clave) (Gerente de Sistemas o Jefe de Sistemas), juega el •Si TI administra poco de los Sistemas de Enlace, su
y busca optimizar el uso de TI a través de toda la doble role de administrador de TI y arquitecto del rol será visto más operativo y menos estratégico
organización negocio
Las empresas que mejor se desempeñan en TI…
Establecen una
forma de rendir
Aprenden de cada
cuentas para los
Clarifican las Miden y manejan el implementación,
cambios
estrategias del gasto realizado por volviéndose
organizacionales
negocio y el rol de TI y el valor que adeptos a compartir
que requieren
TI en lograrlas reciben a cambio y reutilizar activos
implementar
de TI
nuevas capacidades
de TI
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
Gobierno Corporativo y Activos Clave
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
Gobierno de TI
Gobierno de TI o IT Governance es…
Especificar quién toma decisiones y

cómo se rinde de cuentas para lograr el
comportamiento deseable en el uso de
TI
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?
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 X
Negocios
Monarquía de
TI
2. ¿Quién Feudal
debe tomar
estas Federal
decisiones?
Duopolio
Anarquía
Desconocido
Conceptos de la Matriz de Arreglos de Gobierno de TI
Define las necesidades del negocio
Define los Determina los para aplicaciones de TI compradas o
requerimientos de servicios desarrolladas, de unidades o
integración y compartidos y corporativas
Define el rol de TI estandarización habilitadores de TI
en el negocio 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 (sin TI) Infraestructura
de TI de TI Aplicaciones TI
de TI
Arquetipo de Negocios
Especialistas
de TI (sin
Negocios) 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
1. ¿Qué decisiones deben ser
tomadas para asegurar una
gestión y uso efectivo de TI?
Decisiones claves del Gobierno 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 de TI, incluye técnicas para
implementar los Necesidades de aplicaciones justificación y aprobación
requerimientos de negocios de negocios de proyectos
y técnicos sobre Especificaciones sobre las
estandarización e necesidades del negocio para
integración aplicaciones de TI compradas
o desarrolladas internamente
Temas más importantes por cada
Decisión Clave de TI (1 de 3)
Principios de TI Arquitectura Empresarial de TI

•¿Cómo relacionar el Modelo Operacional a principios de TI para guiar la toma de •¿Cuáles son los procesos de negocios núcleo de la empresa? ¿Cómo éstos están
decisiones? interrelacionados?
•¿Cuál es el rol de TI en el Modelo Operacional? •¿Qué información es importante en estos procesos? ¿Cómo debe estar integrada esta
•¿Cuáles son los comportamientos deseables de TI? (Operacional, Estratégico, etc.) información?
•¿Cómo se financiará TI, centralizadamente a nivel empresa o por cada unidad de •¿Qué capacidades técnicas deberían estandarizarse en toda la empresa para ganar
negocios? 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?
Infraestructura TI Necesidades de Aplicaciones de Negocios

•¿Qué servicios de infraestructura son los más críticos para mantener operando el Modelo •¿Cuáles son las oportunidades del mercado y de los procesos de negocios para nuevas
Operacional de la empresa? aplicaciones empresariales?
•¿Qué servicios de infraestructura deberían ser implementados a través de toda la •¿Cómo se puede mapear las necesidades del negocio con los estándares de arquitectura?
empresa? •¿Cuándo una necesidad del negocio justifica una excepción a los estándares de
•¿Cuáles son los requerimientos de acuerdo de nivel-de-servicio (SLA Service Level arquitectura?
Agreement) de esos servicios? •¿Quién se responsabilizará de los gastos de los proyectos e instituirá cambios
•¿Cómo deberían ser cotizados y contratados los servicios de infraestructura de TI? organizacionales para asegurar valor?
•¿Cuál es el plan para mantener la tecnología actualizada? •¿Qué experimentos estratégicos deberían realizarse? ¿Cómo debería ser medido su éxito?
•¿Qué servicios de infraestructura deberían ser tercerizados (outsourcing)? •¿Qué aplicaciones deben ser construidas o compradas?
•¿Qué aplicaciones deben ser corporativas/empresariales y cuáles no?
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ánto se debe gastar en TI??
• ¿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 (corporativos) y bottom-up (unidad de negocios) para balancear
la estandarización e innovación?
Arquetipos de Gobierno de TI para toma de decisiones
Estilo ¿Quién toma la decisión o provee insumos para ello? 2. ¿Quién debe tomar estas
decisiones?
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 (voz, no voto)
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. Representa a toda la organización
Duopolio de TI Ejecutivos y gerentes de TI con otros grupos del negocios o

relacionados a procesos
Anarquía Cada usuario individual o grupos pequeños

3. ¿Cómo serán tomadas y
monitoreadas estas
Principales Mecanismos de Gobierno de TI decisiones?
Grado de Efectividad
Tipo Mecanismo
uso (sobre 5)
Comité de ejecutivos o gerentes de más alto nivel (sin TI) 90% 3.5
Comité de jefes o gerentes de TI con participación de gerentes del negocio 85% 3.8
Equipos de procesos con miembros de TI (analistas u otros roles) 85% 3.4

Estructuras para Administradores de relación Negocios-TI (brokers de negocios, broker de 82% 3.9
Toma de sistemas, asesores)
Decisiones
Consejo de TI, que comprende ejecutivos del negocio y de TI (se trata sólo 70% 3.7
temas de TI)
Comité de Arquitectura 65% 3.1
Comité de Aprobación de Capital (o de Presupuesto o de Finanzas o de 55% 3.1
Productividad o de Eficiencia)
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
Mecanismos de Alto Impacto pero difíciles de implementar
Mecanismo Objetivos Comportamiento deseable Comportamiento no deseable
Comité de ejecutivos o Vista integral del negocio por Inclusión fluida de TI en el TI es ignorado
gerentes de más alto nivel parte de TI negocio
Comité de Arquitectura Identificar y definir estándares Toma de decisiones en TI TI es visto como un policía y
y tecnologías estratégicas dirigida por el negocio que hace demorar las
decisiones
Equipos de procesos con Tener una vista de procesos Gestión de procesos de Estancamiento de las
miembros de TI (analistas u usando TI y otros activos punta a punta habilidades funcionales
otros roles) efectivamente
Comité de Aprobación de Considerar TI como otra Inversión prudente de TI y Parálisis por análisis; proyectos
Capital (o de Presupuesto o inversión diferenciar enfoques para pequeños pueden no tener
de Finanzas o de diferentes tipos de aprobación formal
Productividad) inversión
Acuerdos de nivel de servicio Especificar y medir el servicio Oferta y demanda de Gestionar sólo SLAs, no las
(SLAs) de TI servicios de TI gestionadas necesidades del negocio
profesionalmente
Chargeback Recuperar los costos de TI del Uso responsable de TI Cuestionamiento sobre los
negocio cargos y demanda adulterada
Monitoreo formal del valor Medir las inversiones de TI y Hace visible: objetivos, Separa TI de otros activos; foco
del negocio de TI contribuir al valor de negocio, beneficios y costos en dinero no en valor
frecuentemente usando un
balanced scorecard
7 Características de empresas que manejan un buen Gobierno de
TI
Amplio Estrategias de
Amplia cantidad de involucramiento de negocios
jefes y gerentes gerentes de más diferenciadas entre Poco cambio
pueden describir el alto nivel en unidades de interanual en el
Gobierno de TI Gobierno de TI negocios Gobierno de TI
Difusión del Objetivos claros Pocos o ningún

modelo de para inversiones de usuario
Gobierno de TI a TI: reducción de desalineado y
través de comités, costos, mejorar mayor cantidad de
anuncios formales servicio al cliente, excepciones
de gerentes, proveer aprobadas
portales, etc. información de formalmente
gestión, ampliar
comunicación al
cliente, etc.
Conceptos de Ciclo de Vida
Ciclo de Vida de la Tecnología clásico (TLC)
100
Ciclo de vida de Productos (PLC)
101
Ciclo de Vida de la Adopción Tecnológica
102
Gartner Hype Cycle
103
Gartner Hype Cycle – Interpretación
104
Hype Cycle y Ciclo de Vida de la Adopción Tecnológica
105
Factores clave en el Ciclo de Vida Tecnológico:
Riesgo y Conocimiento
106
Las nuevas tecnologías deben ser adoptadas con mayor velocidad
107
Ciclo de Vida de la Tecnología
Ciclo de Vida de una Tecnología
Máximo Aprovechamiento
Pico de
Evaluación y Selección Expectativas
(Modelo / Producto /
Proveedor) Mantenimiento y Soporte
Estabilización
Operativa
Expectativa Crecimiento de
Expectativas Estabilización para
Producción Desuso /
Obsolescencia
Investigación
Decepción Remplazo
requerido
Estabilización App / Solución

TIEMPO
EN EVALUACION / PRE USO EN USO DENTRO DE LA EMPRESA
Investigación
• Identificación de necesidades del negocio Evaluación y Selección
Pico de
Expectativas
• Ver maduración del diseño organizacional

Estabilización
• Estructura Crecimiento de
Expectativas
Estabilización para
Operativa
•
Puestos Obsolescencia
•
Investigación
Indicadores Decepción Remplazo

requerido
• Roles Estabilización
•
TIEMPO
Procesos
• Enlaces
• Identificar requerimientos de automatización
• Investigar paradigmas, tendencias, soluciones del mercado
• Proveedores
• Gartner, Forrester, IDC, McKinsey, PWC, etc.
• Empresas de referencia
Crecimiento de expectativas
• Información en medios de Evaluación y Selección

Pico de
Expectativas
prensa, revistas y medios (Modelo / Producto /

audiovisuales Crecimiento de
Expectativas
Estabilización
Operativa
• Información por Internet

Obsolescencia
Investigación
Decepción Remplazo
requerido
• Ofrecimientos de vendedores, Estabilización
proveedores, consultores
TIEMPO
• Pruebas de concepto o pilotos

financiados por empresas dueñas
de productos
• “Casos de éxito” generados por
vendedores
Evaluación y Selección
• Se debe tener un proceso formal de Pico de

selección cualitativa y cuantitativa

• Se puede elegir el modelo de trabajo

Estabilización
Operativa
Crecimiento de
Expectativas
Desuso /
(BPM, SOA, MDM, etc.), el producto

Producción
Obsolescencia
Investigación
(suite Websphere, Netweaver, Decepción Remplazo

requerido
Teradata, etc.) o el proveedor (IBM, Estabilización
TIEMPO
Microsoft, Oracle, SAP, etc.)

• 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.
Pico de expectativas
• Ocurre cuando existe una Evaluación y Selección

Pico de
Expectativas
asociación entre la necesidad del (Modelo / Producto /

usuario (demanda) y la oferta que Crecimiento de

Expectativas
Estabilización
Operativa
aparentemente cubre un Producción Desuso /

Obsolescencia
Investigación
producto, modelo o proveedor Decepción Remplazo

requerido
• Siempre a este enganche le falta

Estabilización
TIEMPO
la realidad que da una

implementación y la complejidad
de los detalles
Decepción
• Ocurre cuando la necesidad del Máximo Aprovechamiento
usuario (demanda) y la oferta REAL Evaluación y Selección

Proveedor)
Pico de
Expectativas
del producto, modelo o proveedor

Mantenimiento y Soporte
encuentran divergencias
Estabilización
Operativa
Crecimiento de
Expectativas
• Típicamente el producto no cubre

Obsolescencia
Investigación
Decepción Remplazo
todo o parte de las expectativas o requerido
los detalles no satisfacen Estabilización
TIEMPO
completamente
• Otros aspectos asociados al
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
Estabilización para producción
• Esta es una etapa crítica e inevitable en toda
Pico de
implementación tecnológica (Modelo / Producto /

• Típicamente se omite de cualquier plan de proyecto Crecimiento de

Estabilización
Operativa
Expectativas
• Esta etapa incluye estabilización del hardware, de

Obsolescencia
telecomunicaciones, software base, software Investigación

Decepción Remplazo
principal, parámetros, base de datos e información requerido
(incluyendo migraciones o transferencias de Estabilización
información), implementación del monitoreo, TIEMPO
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
Máximo aprovechamiento
• En esta etapa el usuario Evaluación y Selección

Pico de
Expectativas
aprovecha al máximo la solución (Modelo / Producto /

• Los usuarios pasan por una curva

Estabilización
Operativa
Crecimiento de
Expectativas
Obsolescencia
de aprendizaje inicial, para luego Investigación

Decepción Remplazo
requerido
tener su máxima productividad Estabilización
• La infraestructura soporta bien la

TIEMPO
carga transaccional, volumen de

información, flexibilidad, etc.
Mantenimiento y soporte
• Ocurre cuando se requiere Pico de

corregir, complementar o mejorar Evaluación y Selección

Proveedor)
Expectativas
un aspecto de la solución Crecimiento de

Expectativas
Estabilización
Operativa
• El mantenimiento suele ser

Obsolescencia
Investigación
Remplazo
proactivo o reactivo
Decepción
requerido
Estabilización
• El soporte suele ser reactivo TIEMPO

Estabilidad Operativa
• Ocurre cuando la solución presenta Máximo Aprovechamiento
problemas técnicos que producen Evaluación y Selección

Proveedor)
Pico de
Expectativas
inestabilidad
Estabilización
• Inestabilidad implica: lentitud,

Operativa
Crecimiento de
Expectativas
Obsolescencia
interrupción total o parcial, Investigación

Decepción Remplazo
problemas funcionales, errores, requerido
procesamiento incorrecto, Estabilización
TIEMPO
problemas de visualización, pérdida

de información, vulnerabilidades de
seguridad
• La inestabilidad puede ser manejada
por incremento de infraestructura o
del soporte, pero esto suele tener
un límite
Desuso/obsolescencia
• Ocurre cuando la solución pierde Pico de

vigencia debido a Evaluación y Selección

Proveedor)
Expectativas
• Estabilidad operativa inviable Crecimiento de

Expectativas
Estabilización
Operativa
•
Falta de escalabilidad funcional Producción Desuso /

Obsolescencia
•
Investigación
Deja de cumplir el fin del negocio Decepción Remplazo

requerido
• Escasez de personas que conozcan Estabilización
TIEMPO
la solución
• Pérdida de soporte del proveedor
dueño o creador de la solución
• Imposibilidad de mantenimiento o
correcciones
Reemplazo requerido
• Una vez que se consolida la Pico de

obsolescencia, se inicia un nuevo Evaluación y Selección

Proveedor)
Expectativas
ciclo de vida Crecimiento de

Expectativas
Estabilización
Operativa
Obsolescencia
Investigación
Decepción Remplazo
requerido
Estabilización
TIEMPO
Actividad: Ciclo de Vida de la Tecnología (RESPUESTA)
Pico de
Estabilización
Operativa
Expectativa Crecimiento de
Expectativas Estabilización para
Obsolescencia
Investigación
Decepción Remplazo
ZOLE 2.0 requerido
Estabilización
TIEMPO
Actividad: Ciclo de Vida de la Tecnología (RESPUESTA)
ZOLE
VERICUCHA
Pico de
Proveedor) Mantenimiento y Soporte NAMICHAN
CONEGOR
BPMBIZ
Estabilización
Operativa
Expectativa Crecimiento de SHANSHA-X
ZOLE 2.0
Expectativas SIGOONO Estabilización para SHUSHUPE
Producción SISIFO Desuso /
Obsolescencia
TUPACPLUS OLDCAN
Investigación
Decepción Remplazo
requerido
Estabilización
TIEMPO
Especialidades y
Responsabilidades Primarias de
Arquitectura
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
Dimensiones clásicas de Arquitectura Empresarial
CANALES
PRESENTACIÓN 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
Dominio: es un frente del negocio
Los dominios representan

Un dominio puede ser una
fronteras dentro del negocio
unidad del negocio, una El dominio puede contener
que pueden ser traducidas
Un dominio representa un especialidad del negocio, un organización, Los dominios pueden tener
rápidamente a estructuras
agrupamiento lógico dentro producto o grupo de perfiles/puestos/roles, otros dominios dentro, a los
tangibles. Pueden ser
de una organización, que sirve productos, un cliente o indicadores, procesos, que también se les puede
concebidas como zonas de
para poder enfocarse en él. grupo/segmento de clientes, definiciones de denominar sub-dominios
responsabilidades del negocio
una empresa dentro de una productos/clientes, etc.
y mapeados a objetivos de la
organización, etc.
organización.
Dominios dentro de una organización
Dominio de
Productos
Financieros
Dominio de
Gestión Dominio de
Humana Créditos
Dominio de
Tarjeta de
Créditos
Dominio de
Gestión de
Compensaciones
Dominio de
Dominio de Gestión de
Gestión de Desempeño
Capacitación
Descripción de especialidades de Arquitectura Empresarial de TI
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 de
escritorio
Arquitectura de 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
• Gestiona los estándares de TI (definición, publicación, casos especiales)
Arquitectura de Estándares, • Gestiona las iniciativas de renovación tecnológica
Renovación Tecnológica y • Administra el índice de complejidad
• Administra los portafolios de TI: Estándares, aplicaciones, servicios, procesos,
Gestión de 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 (multidominios) de
Corporativa diversas unidades de negocios o empresas del negocio
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

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
tecnológicas de negocios
RP03
RP05 Planificación Arquitectural de Proyectos
RP07 RP02 RP12 RP06 Investigación tecnológica
RP07 Evaluación y selección de tendencias,
RP05
RP01 RP04 RP11 tecnologías y proveedores
RP06 RP09 RP08 Adopción tecnológica
RP08 RP10
RP09 Gestión de Dimensión de TI
RP13
RP14 RP10 Alineamiento arquitectural evolutivo
RP15 RP11 Evaluación, diagnóstico y acciones para
RP16
renovación tecnológica y obsolescencia
RP17
RP12 Evaluación, diagnóstico y acciones para
Arquitectura de Proyectos RP05 estabilización operativa
RP01 RP02 RP03 RP10
RP04
RP13 Gestión de la complejidad tecnológica
RP11 RP12 RP14 Gestión de Estándares de TI
RP15 Gestión del Portafolio de activos de TI
Arquitectura de Estándares, Renovación
RP13 RP14 RP15 RP07 RP16 Gestión del Programa de Arquitectura TI
Tecnológica y Gestión de Portafolio TI
RP17 Comunicaciones y Evangelización
RP17
Arquitectura de Dimensiones RP06 RP08 RP09
Programa de Arquitectura RP16
Arquitectura Experta / Corporativa

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

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
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 AÑO ACTUAL AÑO ACTUAL + AÑO ACTUAL + AÑO ACTUAL +
1 2 3
• Es común que las iniciativas tengan interdependencias
Proy 1 Proy 3 Proy 5
• Se debe planificar
HOY para el corto plazo y largo plazo FUTURO
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
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”
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.
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.)
RP07: Evaluación y selección de tendencias,
tecnologías y proveedores
• 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.
RP08: Adopción tecnológica
• Procedimientos que permiten adaptar una tecnología para el uso de la

empresa •
 Gobierno
Visión y Misión •
 Lineamientos técnicos
Niveles de servicio
• •
• Esta adaptación
Alcance Requerimientos de monitoreo
• debe considerar:
Objetivos Clave • Gestión del uptime y performance
• Principios guía • Gestión de la contingencia y recuperación ante desastres
• Hoja de ruta de la evolución de la tecnología • Requerimientos de soporte
• Requerimientos que puede cubrir y escenarios • Políticas de seguridad
• Estándares de interfaz de usuario
 Roles y responsabilidades • Administración de metadata
• •Definición de roles (¿Qué roles hay?) • Lineamientos de desarrollo
• Competencias, conocimientos y capacitación requerida de • Lineamientos de pruebas
los roles
• Asignación de roles (¿Quién efectúa qué rol?)  Procedimientos generales
• Responsabilidad (Matriz RACI) (¿Qué responsabilidades • Crear nuevos elementos
tienen que existir?) • Otorgar accesos
• Cambios en la organización de TI y del negocio • Ampliar infraestructura
• Proveedores y expertos externos • Pasar a producción
• Efectuar soporte post-producción
 Infraestructura
• Hardware
• Software
• Comunicaciones
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.)
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.
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
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
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.)
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. En
algunas situaciones, se considera como estándar procesos o procedimientos definidos
en la implementación de metodologías o marcos de trabajo.
• La gestión de estándares implica la administración de los siguientes componentes:
• Portafolio de estándares. Lista y descripción de estándares para cada dimensión
• Creación, publicación y difusión de normas y lineamientos para uso de los estándares
• Auditoria de estándares. Revisión programada y aleatoria del uso de estándares y aplicación de
procedimientos.
• Diagnósticos para optimización de estándares. Permite detectar necesidades de renovación o
cambio del estándar. Este punto incluye reuniones periódicas con los principales proveedores para
conocer los ciclos de vida de sus tecnologías, próximos cambios de versión, nuevos parches,
requerimientos tecnológicos, condiciones de reducción o pérdida del soporte, entre otros
• Autorización de excepciones a los estándares. Permite contar con un procedimiento pre establecido
para resolver situaciones relacionadas a la necesidad de implementar una tecnología no estándar
debido a que el negocio lo requiere.
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
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
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
ACTIVIDAD
Aplicación de Responsabilidades Primarias de Arquitectura en

Talibank (40 minutos)
• Conformar grupos / Tiempos: Discusión y elaboración = 20” / Exposiciones
= 20” RP01 Descubrimiento del negocio
RP03
• De acuerdo a lo revisado en el Caso Talibank:

RP02 Diagnóstico de la maduración del negocio
RP07 RP02 RP03Elija
Hoja de3 unidades
ruta del negocio de Talibank y
RP12
para cada una determine 3 RPs que podríanRP04serEvaluación

RP01 RP04 tecnológicas de negocios Sustente cada
aplicadas.
RP05
y selección de soluciones
RP11
caso. RP06
RP08
RP05
RP06
RP09
Planificación Arquitectural de Proyectos
RP10
Investigación tecnológica
RP13
RP14 RP07 Evaluación y selección de tendencias,
RP15 tecnologías y proveedores
RP16
RP17
RP08 Adopción tecnológica
RP09 Gestión de Dimensión de TI
Arquitectura de Proyectos RP05 RP10 Alineamiento arquitectural evolutivo
RP01 RP02 RP03 RP10
RP04
RP11 RP12 renovación tecnológica y obsolescencia
Arquitectura de Estándares, Renovación
RP13 RP14 RP15 RP07 estabilización operativa
Tecnológica y Gestión de Portafolio TI
RP13 Gestión de la complejidad tecnológica
RP17
Arquitectura de Dimensiones RP06 RP08 RP09
RP14 Gestión de Estándares de TI
Programa de Arquitectura RP16
RP15 Gestión del Portafolio de activos de TI
RP16 Gestión del Programa de Arquitectura TI
Arquitectura Experta / Corporativa RP17 Comunicaciones y Evangelización
Arquitectura Empresarial de TI y el
PETI
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
FACULTAD DE INGENIERÍA Y ARQUITECTURA
Aspectos Avanzados de
Estrategia de
Tecnología de Información II
Planeamiento Estratégico
Profesor Percy Diez Quiñones
FIN DE LA PRESENTACIÓN

4.planest-10 - Aspectos Avanzados de Estrategia de Tecnología de Información Ii

Cargado por

Información del documento

Descripción original:

Título original

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

4.planest-10 - Aspectos Avanzados de Estrategia de Tecnología de Información Ii

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA Y ARQUITECTURA

Profesor Percy Diez Quiñones

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

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

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

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

Deben reconocer sus

Las mejores empresas convierten a sus

La Base Estratégica Organizacional, es la

Llegar a un BEO es evolutivo

Define límites estratégicos

Define capacidades clave Actualiza y evoluciona la

Base Estratégica Organizacional

• Procesos de negocios clave

Nivel necesario de integración y

La integración, se refiere a que La estandarización, se refiere a

Este objetivo de largo plazo, se logra a

Proy 1 Proy 3 Proy 5

BEO - Disciplinas clave: Enlace

Modelo de Enlace = Gobierno de TI

Redes y Servicios de Infraestructura

• 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)

Integración de Información de Negocios

Arquitectura Empresarial es la La clave para hacer una buena AE es

Modelo Operacional = Expectativas de integración y

Arquitectura Empresarial = Procesos claves, datos y

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

Baja estandarización y baja integración

Un extremo de la diversificación es la falta total de Arquitectura Empresarial (unidades totalmente

Baja estandarización y alta integración

El foco es compartir información

Alta estandarización y baja integración

Raramente se ve información, dado que es poco compartida

Silos de negocios Tecnología estandarizada

Núcleo optimizado Modularidad del negocio

Silos de Tecnología Núcleo Modularidad de

35% 33% Infraestructura

17% 18% Datos compartidos

CRM CRM CRM CRM

CORE CORE CORE CORE

Hardware Hardware Hardware Hardware

CRM CRM CRM CRM

CORE CORE CORE CORE

CORE CORE CORE

Correo, File Server, Intranet, Otros

• Permite agilidad en el negocio, a través del uso de módulos reusables

Silos de negocios Tecnología estandarizada

Diversas prácticas de Esto aplica a los roles Menos del 70% de

Gestión presupuestal centralizada para

Proceso de cumplimiento formal de estándares

Arquitectos en equipos de proyectos

Proceso de excepción de arquitectura

Principios que guían la arquitectura

Liderazgo del negocio de los equipos de

Supervisión de la arquitectura empresarial