EGSI-08 - Arquitectura Empresarial de TI(1)

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

Arquitectura Empresarial de TI

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 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 Responsabilidades Primarias de Arquitectura en Talibank



Arquitectura Empresarial de TI y el PETI



Repaso Final

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 herramientas con las que cuenta AETI para definir y articular una hoja de ruta tecnológica para una empresa moderna

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

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 estratégicas

Iniciativas estratégicas



Define límites estratégicos

Modelo operacional Aprendizaje y mejora continua

Define requerimientos de integración y estandarización

Arquitectura Empresarial

Define capacidades clave

Establecimiento de prioridades

Actualiza y evoluciona la arquitectura

Modelo de Enlace Base Estratégica Organizacional • Procesos de negocios clave • Infraestructura de TI

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

BEO - Disciplinas clave: A rquitectura E mpres arial

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

AS IS + ROADMAP = TO BE

2012

HOY AS IS

2013

Proy 1

Proy 3

2014 Proy 5

Proy 1 Proy 2 Proy 3 Proy 4 Proy 5

FUTURO TO BE

Proy 2 Proy 4

1. 2. 3. 4. 5.

2015

HOJA DE RUTA ROADMAP

BEO - Disciplinas clave: Modelo de E nla nlacc e ( G obi obier erno no de T I )

Modelo de Enlace



Es el mecanismo mecanismo con el que el negocio se alinea con los proyectos de TI



Este modelo permite influenciar sobre las l as 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

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 





 

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



El Modelo Operacional

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

Dimensiones del Modelo Operacional Estandarización 

Define exactamente cómo será ejecutado un proceso homogéneo, independientemente de quién lo esté llevando a cabo o dónde se realice



Beneficios:







Eficiencia (volumen de atención y productividad)



Predictibilidad en la organización

Integración 

Enlaza los esfuerzos organizacionales a través de información compartida, dentro de procesos de punta a punta o a través de múltiples procesos



Beneficios:

Desventajas:



Eficiencia, coordinación, transparencia y agilidad



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 un sistema estándar de calidad inferior a sistemas existentes (costo, dificultad, gestión del cambio)



Simplifica el flujo de información en una organización



Por ejemplo: 

Desventajas: 

Definición de estándares de datos (formato)



Definición de un diccionario de datos (términos)



Se incurre en tiempo para estas definiciones

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

 Clientes, productos o proveedores compartidos s o  Impacto en transacciones de otras unidades de i c negocio o Operacionalmente funciones o unidades de  g o negocios únicas e t N l  Gestión de negocios autónoma A  La unidad de negocios controla el diseño de e d procesos  Datos compartidos n ó  Consenso para diseñar los servicios de i c infraestructura TI; decisiones sobre aplicaciones TI a hechas en las unidades de negocios m r Diversificación o f n I

e d n ó i c a r g e t n I

 

o j a B



   

Pocos o ningún clientes y proveedores compartidos Transacciones independientes Unidades de negocios operacionalmente únicas Gestión del negocio autónoma La unidad de negocio favorece el control antes que el diseño de procesos Pocos datos estándares entre las unidades del negocio La mayoría de las decisiones de TI se toman en las unidades de negocios

 

    

Replicación  

   



Bajo

Los clientes y proveedores pueden ser locales o globales Procesos de negocios integrados globalmente con apoyo de sistemas empresariales Las unidades de negocios tienen operaciones similares o que se traslapan Administración centralizada Dueños de procesos de alto nivel diseñan procesos estandarizados Bases de datos con información del negocio manejadas centralizadamente Las decisiones sobre TI se toman centralizadamente

Pocos, si los hay, clientes compartidos Transacciones independientes agregadas en un alto nivel Unidades de negocios operacionalmente similares Líderes de las unidades de negocios autónomos, con influencia limitada en los procesos Control centralizado sobre el diseño de procesos Definiciones de datos estandarizados, pero la propiedad de la información es local con algunas definiciones centralizadas Servicios de TI gestionados centralizadamente

Alto


Arquitectura Empresarial 





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

Diagrama Núcleo de Arquitectura Empresarial 

Análogo a los planos de un nuevo edificio, la Arquitectura Empresarial se plasma en diagramas, principios, políticas y elecciones y definiciones tecnológicas



El diagrama principal que describe de manera macro e integral la Arquitectura Empresarial es el Diagrama Núcleo



Sin embargo, otros diagramas complementarán y detallarán el trabajo (datos, integración, estándares y plataformas, hw/sw, etc.)

Objetivos del Diagrama Núcleo • Permite entender de manera común la AE • Permite debatir y ajustar la AE, facilita las discusiones • Muestra en alto nivel los procesos clave, datos y tecnología que constituye la Arquitectura • Clarifica los requerimientos para llevar a cabo la AE • Comunica la visión de procesos de y TI de la 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 integ ració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.



C anales 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 S A D A R T N E

Canales clave

Procesos clave

Datos Compartidos

Tecnologías de Integración

Tecnologías de Automatización Automatización Requerido Opcional Tecnologías de Integración A R U T C E T I U Q R A

Procesos de Negocios Datos

Tecnología

Canales

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 infraestructur a de TI (hardwar (hardware, e, software, centros de datos, outsourcing, BPOs, negociaciones o compras centralizadas, helpdesk, etc.)

Diagrama Núcleo de Diversificación S A D A R T N E

Tecnolog ecnologías ías

Procesos

Datos

Canales

Requerido Opcional

A R U T C E T I U Q R A

Tecnología

Procesos de Negocios Datos

Plataformas Tecnológicas

Tecnología

Canales

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 S A D A R T N E

Canales

Datos

Tecnologías

Procesos

Requerido Opcional Procesos A R U T C E T I U Q R A

Datos

Tecnología

Canales

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 S A D A R T N E

Procesos

Tecnologías

Datos

Canales

Requerido Opcional Procesos A R U T C E T I U Q R A

Datos

Tecnología

Canales

Actividad: Diagrama Núcleo de Talibank

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

Etapas evolutivas de la Arquitectura Empresarial

Cuatro etapas de la evolución de la AE 

Silos de negocios 



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 



Las organizaciones maximizan las necesidades de negocios o funcionales de unidades individuales

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

Evolución de la Arquitectura Empresarial Evolución de la Arquitectura

Silos de Negocios

Tecnología Estandarizada

100%

Núcleo Optimizado 16%

Modularidad de Negocios 15%

25% 36%

I T n e n ó i s r e v n I e d e j a t n e c r o P

32% 21%

Sistemas corporativos

18%

40%

35%

33%

35%

11%

0%

34%

Aplicaciones especializadas por unidad de negocios

12%

14%

48%

17%

34%

% Empresas en la etapa

18%

6%

Infraestructura compartida (hw/sw)

Datos compartidos

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, 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 Unidad 1

Unidad 2

Unidad 3

Unidad 4

ERP

ERP

ERP

ERP

CRM

CRM

CRM

CRM

CORE

CORE

CORE

CORE


Hardware

BD / DWH

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 Unidad 1

Unidad 3

Unidad 2

Unidad 4

ERP

CRM

CRM

CORE

CORE


Hardware

Base de datos

CORE

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

Modularidad de negocios ~ SOA Consumidores de Servicios Seguridad

Procesos Seguridad

Servicios

Seguridad

Proveedores

Aplicación 1

Canal 1

Canal 2

Canal 3

Aplicación 2

Gestión durante la evolución de la AE

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)

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

Gobierno 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 de TI

Gobierno Corporativo

Otros stakeholders

Shareholders Directorio

Suministro de información

Monitoreo

Equipo Ejecutivo Senior

Comportamiento deseable

Estrategia Activos clave

Activos Humanos

Activos Financieros

Activos Físicos

Activos de Propiedad Intelectual

Mecanismos de Gobierno Financiero (comités, presupuestos, etc.)

Activos de Información y de TI

Activos de Relacionamiento

Mecanismos de Gobierno de TI (comités, presupuestos, etc.)

Gobierno de Activos Clave

Gobierno de TI o IT G overnance 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

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?

Gobierno de TI

2. ¿Quién debe tomar estas decisiones?

3. ¿Cómo serán tomadas y monitoreadas estas decisiones?

La Matriz de A rreg los de G obierno 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 Principios de TI

Arquetipo Monarquía de Negocios Monarquía de TI


Feudal Federal Duopolio Anarquía Desconocido

Arquitectura de TI

Estrategias de Infraestructura de TI

Necesidades de Aplicaciones de Negocios

Inversión de TI

Conceptos de la Matriz de A rreg los de G obierno de TI Define los requerimientos de integración y estandarización

Define el rol de TI en el negocio

Gerentes del más Alto Nivel

Define las necesidades del negocio para aplicaciones de TI compradas o desarrolladas

Decisión Principios de TI

Arquetipo

Especialistas de TI

Determina los servicios compartidos y habilitadores de la TI

Arquitectura de TI


Escoge las iniciativas a financiar y cuánto gastar


Monarquía de Negocios

Cada unidad de negocios toma decisiones independientes

Monarquía de TI Feudal

Centro corporativo y las unidades de negocios con o sin involucración de TI

Federal Duopolio

TI y otro grupo (líderes de unidades de negocios o los gerentes de más alto nivel) Individuos aislados

Anarquía Desconocido

Dentro de la matriz se indica quién toma qué decisión, con los comentarios o aclaraciones que se requiera

Inversión de TI

Decisiones claves del Gobierno de TI

1. ¿Qué decisiones deben ser 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

Organización de datos, aplicaciones e infraestructura definida en un conjunto de políticas, relacionamientos y elecciones técnicas para implementar los requerimientos de negocios y técnicos sobre estandarización e integración

Servicios de TI centralizados, coordinados y compartidos que proveen las bases para las capacidades TI de la organización Necesidades de aplicaciones de negocios

Especificaciones sobre las necesidades del negocio para aplicaciones de TI compradas o desarrolladas internamente

Inversiones de TI

Decisiones sobre cuánto y en qué realizar inversiones de TI, incluye técnicas para justificación y aprobación de proyectos

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?




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?


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áctic as 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?

Arquetipos de Gobierno de TI para toma de 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

Principales Mecanismos de Gobierno de TI

Grado de uso

Efectividad (sobre 5)

Comité de ejecutivos o gerentes de más alto nivel

90%

3.5

Comité de jefes o gerentes de T I con participación de gerentes del negocio

85%

3.8

Equipos de procesos con miembros de TI (analistas u otros roles)

85%

3.4

82%

3.9

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 o de Productividad)

55%

3.1

Seguimiento a proyectos de TI y recursos consumidos

95%

3.4

90%

3.2

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

85%

2.9

Oficio del CIO u Oficina de Gobierno de TI

82%

3.6

Portales e intranets de TI

78%

2.9

Tipo

Estructuras para Toma de Decisiones

Procesos de Alineamiento

Enfoques de Comunicación

3. ¿Cómo serán tomadas y monitoreadas estas decisiones?

Mecanismo

Administradores de relación Negocios-TI (brokers de negocios, broker de sistemas, asesores)

Acuerdos de nivel de servicio (SLAs)

Anuncios realizados por gerentes

Actividad: Diagnóstico de Matriz de Arreglos de Gobierno

ACTIVIDAD

Diagnóstico de Matriz de Arreglos de Gobierno 

Conformar grupos






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



Discusión y elaboración 40”



Exposiciones

20”


Principios de TI

Arquetipo Monarquía de Negocios Monarquía de TI Feudal Federal Duopolio Anarquía Desconocido

Arquitectura de TI



Inversión de TI

Ciclo de Vida de la Tecnología

Ciclo de Vida de una Tecnología Evaluación y Selección (Modelo / Producto / Proveedor)

Crecimiento de Expectativas

Pico de Expectativas

Máximo Aprovechamiento Mantenimiento y Soporte Estabilización Operativa

Estabilización para Producción

Desuso / Obsolescencia

Investigación

Remplazo requerido

Decepción

Estabilización

TIEMPO

Investigación 



Identificación de necesidades del negocio Ver maduración del diseño organizacional 

Estructura



Puestos



Indicadores



Roles



Procesos



Enlaces



Identificar requerimientos de automatización



Investigar paradigmas, tendencias, soluciones del mercado 

Proveedores



Gartner, Forrester, IDC, McKinsey, PWC, etc.



Empresas de referencia

Máximo Aprovechamiento Evaluación y Selección (Modelo / Producto / Proveedor)

Pico de Expectativas Mantenimiento y Soporte

Estabilización Operativa Crecimiento de Expectativas



Investigación

Remplazo requerido

Decepción

Estabilización

TIEMPO

Crecimiento de expectativas 

Información en medios de prensa, revistas y medios audiovisuales



Información por Internet



Ofrecimientos de vendedores, proveedores, consultores





Pruebas de concepto o pilotos financiados por empresas dueñas de productos “Casos de éxito” generados por vendedores






Investigación

Remplazo requerido

Decepción

Estabilización

TIEMPO

Evaluación y Selección 





Se debe tener un proceso formal de selección cualitativa y cuantitativa Se puede elegir el modelo de trabajo (BPM, SOA, MDM, etc.), el producto (suite Websphere, Netweaver, Teradata, etc.) o el proveedor (IBM, 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.






Investigación

Remplazo requerido

Decepción

Estabilización

TIEMPO

Pico de expectativas 



Ocurre cuando existe una asociación entre la necesidad del usuario (demanda) y la oferta que aparentemente cubre un producto, modelo o proveedor Siempre a este enganche le falta la realidad que da una implementación y la complejidad de los detalles






Investigación

Remplazo requerido

Decepción

Estabilización

TIEMPO

Decepción 





Ocurre cuando la necesidad del usuario (demanda) y la oferta REAL del producto, modelo o proveedor encuentran divergencias Típicamente el producto no cubre todo o parte de las expectativas o los detalles no satisfacen 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






Investigación

Remplazo requerido

Decepción

Estabilización

TIEMPO

Estabilización para producción 

Esta es una etapa crítica e inevitable en toda implementación tecnológica



Típicamente se omite de cualquier plan de proyecto



Esta etapa incluye 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.



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






Investigación

Remplazo requerido

Decepción

Estabilización

TIEMPO

Máximo aprovechamiento 





En esta etapa el usuario aprovecha al máximo la solución Los usuarios pasan por una curva de aprendizaje inicial, para luego tener su máxima productividad La infraestructura soporta bien la carga transaccional, volumen de información, flexibilidad, etc.






Investigación

Remplazo requerido

Decepción

Estabilización

TIEMPO

Mantenimiento y soporte 





Ocurre cuando se requiere corregir, complementar o mejorar un aspecto de la solución El mantenimiento suele ser proactivo o reactivo






El soporte suele ser reactivo Investigación

Remplazo requerido

Decepción

Estabilización

TIEMPO

Estabilidad Operativa 





Ocurre cuando la solución presenta problemas técnicos que producen inestabilidad Inestabilidad implica: lentitud, interrupción total o parcial, problemas funcionales, errores, procesamiento incorrecto, 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






Investigación

Remplazo requerido

Decepción

Estabilización

TIEMPO

Desuso/obsolescencia 

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






Investigación

Remplazo requerido

Decepción

Estabilización

TIEMPO

Reemplazo requerido 

Una vez que se consolida la obsolescencia, se inicia un nuevo ciclo de vida






Investigación

Remplazo requerido

Decepción

Estabilización

TIEMPO

Actividad: Estado de la Tecnología de Talibank

ACTIVIDAD

Tecnología de Talibank (40 minutos) 

Conformar grupos






Tiempos







Discusión y elaboración

20”



Exposiciones

20”


De acuerdo a lo revisado en el Caso Talibank: 

Identifique 10 tecnologías de Talibank, 5 de ellas aplicaciones. Pueden ser en uso o en evaluación; incluso estar al mismo tiempo



Mapéelas en el ciclo de vida



Identifique siguientes acciones requeridas de acuerdo al ciclo de vida



Sustente el mapeo y las siguientes acciones


Crecimiento de Expectativas

Investigación


Estabilización Operativa Estabilización para Producción

Desuso / Obsolescencia Remplazo requerido

Decepción

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

Canal 1

Canal 3

Canal 2

Canal 4

Canal 5

PROCESOS

SERVICIOS

N O I C A M R O F N I

APLICACIONES / PROVEEDORES DE INFORMACIÓN DWH DMs

INFRAESTRUCTURA

Servicio 1

Servicio 2

Servicio 3

Servicio 4

Servicio 5

Servicio 6

Servicio 7

Servicio 8

Clientes

Productos / Servicios

Empleados

Proveedores / Logística

Windows

+ Intel

Unix / Linux

zOS Host

Aplicación 1

Aplicación 2

Aplicación 3

Aplicación 5

Aplicación 6

Aplicación 7

Midrange

Oracle, DB2, SQL Server, Otros .NET, Java, Web Dev, COBOL, otros

WS, REST, MQ, etc.

Aplicación 4

Aplicación 8

Performance Escalabilidad Alta disponibilidad Contingencia Recuperación ante desastres

I N T E G R A C I Ó N

S E G U R I D A D

O P E R A C I O N E S : A D M I N I S T R A C I Ó N / C O N T I N U I D A D O P E R A C I O N A L

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

Dominios dentro de una organización

Dominio de Productos Financieros Dominio de Créditos

Dominio de Gestión Humana

Dominio de Tarjeta de Créditos

Dominio de Gestión de Compensaciones

Dominio de Gestión de Capacitación

Dominio de Gestión de Desempeño

Descripción de especialidades de Arquitectura Empresarial de TI Especialidad

Arquitectura de Dimensiones Arquitectura de Estándares, Renovación Tecnológica y Gestión de Portafolio TI

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 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) Gestiona las iniciativas de renovación tecnológica Administra el índice de complejidad Administra los portafolios de TI: Estándares, aplicaciones, servicios, procesos, infraestructura, información, seguridad, operaciones, etc.

• •

Arquitectura de Dominios

• • • •

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

Programa de Arquitectura

•

Gestiona los proyectos y requerimientos solicitados por arquitectura

•

Asesora y define la estrategia tecnológica para soluciones horizontales (multidominios) de diversas unidades de negocios o empresas del negocio

Arquitectura Experta / Corporativa

Especialidades de Arquitectura en el Ciclo de Vida de la Tecnología


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

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



Es común que las iniciativas tengan interdependencias



Se debe planificar para el corto plazo y largo plazo

AÑO ACTUAL HOY AS IS

AÑO ACTUAL + 1

Proy 1

Proy 3

Proy 1 Proy 2 Proy 3 Proy 4 Proy 5

Proy 5

AÑO ACTUAL + 3 FUTURO TO BE

Proy 2 Programa A

1. 2. 3. 4. 5

AÑO ACTUAL + 2

HOJA DE RUTA ROADMAP

Proy 4

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:  

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 uso de estándares tecnológicos de software, hardware y telecomunicaciones

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 l a empresa



Esta adaptación debe considerar: Gobierno



• • • • • • 

Visión y Misión Alcance Objetivos Clave Principios guía

• • • •

Niveles de servicio

• • • • • •

Requerimientos de soporte

Hoja de ruta de la evolución de la tecnología Requerimientos que puede cubrir y escenarios Roles y responsabilidades

• •Definición de roles (¿Qué roles hay?) • Competencias, conocimientos y capacitación requerida de los roles

• Asignación de roles (¿Quién efectúa qué rol?) • Responsabilidad (Matriz RACI) (¿Qué responsabilidades tienen que existir?)

• Cambios en la organización de TI y del negocio • Proveedores y expertos externos 

Lineamientos técnicos



Infraestructura

• Hardware • Software Comunicaciones

Requerimientos de monitoreo Gestión del uptime y performance Gestión de la contingencia y recuperación ante desastres Políticas de seguridad Estándares de interfaz de usuario Administración de metadata Lineamientos de desarrollo Lineamientos de pruebas Procedimientos generales



• • • • •

Crear nuevos elementos Otorgar accesos Ampliar infraestructura Pasar a producción Efectuar soporte post-producción

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



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

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

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 RP02

RP03 RP07

RP12

RP02

RP01

RP04

RP06

RP05

RP11 RP09 RP10

RP08

RP05 RP06 RP07

RP13 RP14 RP15 RP16 RP17


RP05

RP01

RP02

RP11

RP12

RP14

RP15

RP03

RP10

RP04

Arquitectura de Dominios Arquitectura de Estándares, Renovación Tecnológica y Gestión de Portafolio TI Arquitectura de Dimensiones

RP06

RP08

RP13

Programa de Arquitectura Arquitectura Experta / Corporativa

RP07

RP16

RP08 RP09 RP10 RP11 RP12

RP17

RP09

RP03 RP04

RP13 RP14 RP15 RP16

ACTIVIDAD

Descubrimiento del negocio Descubrimiento Diagnóstico de la maduración del negocio Hoja de ruta del negocio Evaluación y selección de soluciones tecnológicas de negocios Planificación Arquitectural Arquitectural de Proyectos Investigación tecnológica Evaluación y selección de tendencias, tecnologías y proveedores Adopción tecnológica tecnológica Gestión de Dimensión de TI Alineamiento arquitectural evolutivo Evaluación, diagnóstico y acciones para renovación tecnológica y obsolescencia Evaluación, diagnóstico y acciones para estabilización operativa Gestión de la complejidad tecnológica Gestión de Estándares de TI Gestión del Portafolio de activos de TI Gestión del Programa de Arquitectura TI

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

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

EGSI-08 - Arquitectura Empresarial de TI(1)

Recommend Documents