5.

Mejores prácticas para el análisis, construcción y gestión de Arquitecturas Empresariales

(Metodologías, Frameworks
Modelo de Zachman
DoDAF
TOGAF
Gartner (GEAF)
Otras mejores prácticas o frameworks
6-. BABOK , ITIL, COBIT, DAMA y su Relación con Arquitectura Empresarial

Ya teniendo claro que una Arquitectura Empresarial, es una práctica continua dentro de las
organizaciones que descifra las relaciones que existen entre todos sus componentes: Personas,
Aplicaciones, Tecnología, etc., y que entre sus objetivos principales se encuentran: Entender la
complejidad de la empresa, alinear los objetivos estratégicos de la organización, con cada uno
de los componentes de la misma y además estar preparados para gestionar el cambio. Ahora es
importante conocer que Marcos de referencia existen para aplicar estrategias de Arquitectura
Empresarial dentro de las organizaciones.

Surge entonces el concepto de Framework de Arquitectura Empresarial, el cual es la estructura

lógica, a través de la cual se clasifica, se organiza y se describen cada uno de los componentes
de la organización, de los que ya hablábamos en la definición de Arquitectura Empresarial. A
través de esta descripción, es entonces que los líderes de las compañías pueden tomar
decisiones, consolidar Ti, aplicar estrategias de control, de gestión de cambio, y de mejoras, que
los lleven a cumplir con los objetivos estratégicos de la organización.

Existen varios Frameworks que ofrecen unas directrices, y guías para aplicar estrategias de
Arquitectura Empresarial en las organizaciones. Podríamos clasificar los Frameworks según su
naturaleza, o tipo de empresa a la que están dirigidos, a continuación algunos ejemplos:

* Frameworks privados: – EA IBM Framework – SAP EA Framework – IAF Capgemini – EA Oracle

Framework, entre otros
* Frameworks Semipropietarios: – Zachman EA Framework, EA3 Cube
* Frameworks Open: – TOGAF: The Open Group Architecture Framework
* Framworks para Organizaciones Estatales: -FEAF: Federal Enterprise Architecture Framework,
DODAF

https://es.wikipedia.org/wiki/Marco_de_Trabajo_Zachman

Modelo Zachman
El Modelo Zachman es un marco o modelo de referencia (framework) de Arquitecturas
empresariales creado por John A. Zachman en 1984 y publicado por primera vez en el IBM
Systems Journal en 1987. Es uno de los marcos de trabajo más antiguos y de mayor difusión en la
actualidad.

Los inicios de los Frameworks de Arquitectura Empresarial se dan gracias a la visión de John
Zachman, cuando en los años 80’s vislumbró que con el incremento de la complejidad de los
Sistemas de Información, era necesario desarrollar una estructura lógica a través de la cual se
pudiese clasificar, controlar e integrar todos los componentes de un sistema de información1. Es
decir que en sus inicios el Framework de Arquitectura Empresarial, era más en sí un Framework de
Arquitectura de Sistemas.

Con el pasar de los años, este Framework se fue afinando y surgió el concepto de Arquitectura
Empresarial, y por consiguiente surge también el concepto de Framework de Arquitectura
Empresarial. Esto surge de las analogías que Zachman realizaba acerca de la Arquitectura, en
diferentes campos de acción, es decir para Zachman el dibujo de una Arquitectura, es la
transcripción de los requisitos de un dueño. Entonces por qué no revisar si ese dibujo de
Arquitectura era aplicable a todo?.

Las características más relevantes del Framework de Zachman, desde que fue concebido como
un Framework de Arquitectura de Sistemas de Información, hasta ahora que es concebido como
un Framework de Arquitecturas Empresariales, son su constante búsqueda de la descripción de
cada componente, a través de interrogantes, y desde diferentes puntos de vista.

Zachman entonces, describe en su Framework a la Empresa, como una matriz de 6 x 6, en donde

cada columna, es la representación de un aspecto de la empresa, definido a través de
preguntas: ¿Qué?, ¿Cómo?, ¿Dónde?, ¿Quién?, ¿Cuándo?, y ¿Por qué? Luego en las filas, se
representan los puntos de vista, contextuales, conceptuales, Lógicos, físicos y detallados. Estos se
pueden ver como los puntos de vista de los diferentes actores dentro de la organización: el
planeador, el dueño, el diseñador, el constructor. Describiendo así cada componente de la
organización.

Cada celda que se forma entonces de la intersección entre las columnas y filas, se convierte en
la descripción de un aspecto de la empresa según un punto de vista determinado. Zachman no
propone su marco como una metodología, sino como una estructura, pues define a la
metodología como un proceso, y obviamente una estructura no es lo mismo que un proceso,
pues es precisamente para el, la estructura es quien define al proceso. Para Zachman los
procesos basados en una estructura serán predecibles, mientras que los que no, solo
dependerán de la habilidad del practicante.

Este esquema de Zachman, permite que se vea a la empresa de una manera ordenada, de tal
manera que se pueda describir y analizar fácilmente. Esto ayuda además que quien esté
concentrado en un área, por ejemplo el de los Sistemas de Información, se puedan concentrar
en sus objetivos específicos, pero que siempre tenga a la vista el contexto general de la
empresa, y por consiguiente los objetivos generales de la misma.

Dado que las empresas, cada día crecen más, se vuelven más complejas, por lo tanto un
Framework de Arquitectura Empresarial, se podría convertir en una ventaja competitiva para una
organización.
La razón del empleo de esta forma de clasificación fue que ambas clasificaciones se utilizan de
una manera empírica para las representaciones descriptivas (arquitecturas) de edificios, aviones u
otros productos comerciales de gran complejidad; de tal forma se asegura que este Framework es
la estructura fundamental de una Arquitectura Empresarial, ya que contiene un set de
representaciones relevantes para la descripción de una Arquitectura.

De una forma específica podemos decir que este Framework es una ontología, una teoría que
establece la existencia de un conjunto estructurado de componentes esenciales para un objeto en el
cual las expresiones explícitas de éstas son básicas e incluso obligatorias para la creación,
operación y cambios de los mismos.1

Zachman no es una metodología para la creación de la implementación (o instanciación) del

objeto en cuestión sino la ontología para la descripción del objeto; por el contrario, una
metodología es una descripción para la elaboración de un proceso. El Framework de Zachman
describe un modelo integral de la infraestructura de la información de la empresa desde seis
perspectivas: planificador, propietario, diseñador, constructor, subcontratistas, y el sistema de
trabajo. No hay ninguna orientación sobre la secuencia, proceso o aplicación del marco. La
atención se centra en garantizar que todos los aspectos de una empresa están bien organizados y
muestra relaciones claras que garanticen un sistema completo, independientemente del orden en el
que están establecidos.

Principios Fundamentales

Los principios fundamentales que guían la aplicación del Framework de Zachman incluyen los
siguientes aspectos:

1. Un sistema completo que puede ser modelado por representación de las respuestas a las
siguientes preguntas: ¿Por qué, quién, qué, cómo, dónde y cuándo?
 2. Los seis puntos de vista de captura de todos los modelos críticos para el desarrollo del sistema.
3. Las restricciones para cada perspectiva son aditivos; las de una fila inferior se suman a los de las
filas de arriba para ofrecer un creciente número de restricciones.
4. Las columnas representan abstracciones diferentes en un esfuerzo por reducir la complejidad de
un modelo único que se construyen.
5. Las columnas no tienen ningún orden.
6. El modelo de cada columna debe ser único.
7. Cada fila representa una perspectiva única.
8. Cada celda es única.
9. La lógica inherente es recursiva.

DODAF

DoDAF evolucionó en los EE.UU, la primera versión DoDAF fue desarrollado en la década de
1990 bajo el nombre de framework de arquitectura C4ISR. La primera versión oficial v1.0
C4ISR Architecture Framework, fue lanzada el 7 de junio de 1996. Desde principios de 1995
el subsecretario del Departamento de Defensa, encamino todos sus esfuerzos en definir y
desarrollar un mejor medio en el proceso de asegurar que las capacidades de C4ISR fueran
interoperables y que al mismo tiempo satisfagan las necesidades de los combatientes. El
esfuerzo continuo desarrollado resultó en diciembre de 1997 en la segunda versión, C4ISR
Architecture Framework v2.0.

En agosto de 2003 la v1.0 DoDAF fue lanzada, debido a la reestructuración del Framework
v2.0 C4ISR para ofrecer mejor orientación, descripciones de productos, e información
complementaria en dos volúmenes de un libro escrito. Se amplió la aplicabilidad de los
principios y prácticas de arquitectura de todos los interesados y no sólo a la comunidad C4ISR.

Esta versión aborda el uso de arquitecturas integradas, las políticas del Departamento de
Defensa y el Federal, el valor de las arquitecturas, las medidas de la arquitectura, los procesos
de apoyo a la decisión del Departamento de Defensa, las técnicas de desarrollo, técnicas de
análisis, y la CADM v1.01, y se dirigió hacia un enfoque basado en el repositorio, haciendo
hincapié en elementos de datos de arquitectura que integran productos.

MARCO DODAF
El framework de referencia DoDAF proporciona un marco fundamental para el desarrollo y la
representación de un denominador común para el entendimiento, la comparación y la
integración de las arquitecturas a través de fronteras organizativas, conjuntos y
multinacionales. Este marco establece definiciones de elementos de datos, reglas y relaciones
y un conjunto básico de productos para el desarrollo coherente de los sistemas integrados, o
arquitecturas federadas.

Estas descripciones de arquitectura pueden incluir familias de sistemas (FOS), sistemas de

sistemas (SOS), y las capacidades de red centralizada para interoperar e interactuar en el
medio ambiente que no es de combate.
 En este framework se contemplan todas las principales armas de EE.UU. y del Departamento
de Defensa, las adquisiciones del sistema de tecnología de información en busca de desarrollar
y documentar una arquitectura empresarial (EA) con las vistas previstas en el DoDAF. A pesar
de que está claramente destinada a los sistemas militares, DoDAF tiene una amplia
aplicabilidad en los sectores privado, público y voluntarios de todo el mundo, y representa uno
de un gran número de sistemas de marcos de arquitectura empresarial.

El propósito de DoDAF es definir conceptos y modelos que pueden utilizarse en los 6 procesos
básicos del DoD(Departamento de defensa):

1) Capacidad de Integración y Desarrollo (JCIDS)

2) Planificar, programar, presupuestar y ejecutar (PPBE)

3) Adquisición de Sistemas de Defensa (DAS)

4) Ingeniería de Sistemas (SE)

5) Planificación Operativa (OPLAN)

6) Capacidad de manejo de la cartera (CPM)

Además, DoDAF tiene como objetivos principales:

 Establecer formas de arquitectura en función de los objetivos adecuados.

 Aumentar la utilidad y la eficacia de arquitecturas a través de un modelo de datos riguroso
por lo que las arquitecturas pueden ser integradas, analizadas, y evaluadas con más
precisión.
 La meta de DoDAF “es lograr que las descripciones arquitecturales desarrolladas
por diferentes comandos, servicios y agencias sean compatibles y que se
interrelacionen”.

Los administradores del Departamento de Defensa, como los dueños del proceso,
especifican los requisitos y controlan el desarrollo de arquitecturas dentro de sus
áreas de autoridad y responsabilidad. Seleccionan a un arquitecto con un equipo
de desarrollo de arquitectura para crear la arquitectura conforme con los requisitos
que definen.

Uno de los objetivos de DoDAF es presentar la información de una manera que

sea comprensible para los tipos de interesados que participan en el desarrollo,
entrega y mantenimiento. Lo hace mediante la división del espacio del problema
en partes manejables, de acuerdo con el punto de vista de las partes interesadas.

Sin embargo, hay que destacar que DoDAF “está fundamentado sobre la creación
de un modelo coherente de la empresa para permitir una toma de decisiones
eficaz. Los aspectos de presentación no deben exagerar la presentación pictórica,
a expensas de los datos subyacentes”40.

FRAMEWORKS DE ARQUITECTURA EMPRESARIAL, DIFERENCIAS ENTRE VERSIONES Y

AUTORES
Por: Erika María González Escobar Publicado el 27 de noviembre de 2.010
TOGAF, es uno de los Frameworks de Arquitectura empresarial más reconocidos en el mercado,
desarrollado por The Open Group, desde el año de 1995. TOGAF se presenta como un método
detallado y un conjunto de recursos, para el desarrollo de una Arquitectura Empresarial dentro
de las organizaciones.
Desde sus inicios TOGAF ha tenido varias versiones, las más recientes son la TOGAF 8, y TOGAF 9,
las cuales difieren entre si, en varios aspectos.
TOGAF 8, en escencia va en la búsqueda de cumplir con la definición de Arquitectura
Empresarial, y para lograrlo, se divide en 4 partes:
1. Introduction: Explica conceptos claves de TOGAF
2. Architecture Development Method: ADM, es la descripción paso a paso del desarrollo de la
Arquitectura Empresaral
3. Enterprise Continuum: Es el repositorio de los activos de la Arquitectura
4. Resources: Conjunto de herramientas y técnicas disponibles para aplicar la Arquitectura
Empresarial.

En el 2.009 con TOGAF 9, el Framework ya no se compone de 4 partes principales sino de 7. Es

acá donde empieza a diferir la nueva versión del Framework con respecto a la anterior. Se
conservan las dos primeras partes, pero las siguientes se modifican:
3. ADM Guidelines and Techniques: Colección de guías y técnicas para ser usadas en el ADM
4. Architecture Content Framework: Describe los Artefactos de la arquitectura TOGAF
5. Enterprise Continuum & Tools: Herramientas adecuadas para el desarrollo de la Arquitectura
6. TOGAF™ Reference Models: Provee unos modelos de referencia.
7. Architecture Capability Framework: Capacidades de la organización para establecer la
Arquitectura.

Una de las diferencias más significativas entre las dos versiones, es que consideran estilos de
Arquitectura tales SOA, que es una Arquitecura Orientada a Servicios, la cual la tienen en cuenta
como factor clave, para lograr la integración de los sistemas de la organización. TOGAF 9
establece entonces a SOA como un recurso estratégico que va de la mano con el Framework,
para obtener los beneficios esperados de la Arquitectura Empresarial.

TOGAF, al igual que el Framework de Zachman, buscan representar, y describir a la organización,

con el claro objetivo, de que todos los componentes de una organización trabajen en función
de Alinear sus propios objetivos, con los objetivos estratégicos de la organización.

Los Frameworks de estos dos autores coinciden además en una serie de entregables Sin
embargo entre los dos Frameworks existen marcadas diferencias:

Zachman claramente dice que su Framework no es una metodología, que es una estructura1.
TOGAF concibe su framework, como un método.

Zachman describe a la empresa en una matriz, a través de unos puntos de vista, y unos
interrogantes, TOGAF se centra más en los procesos de la empresa, y la describe a través de 4
vistas o Arquitecturas.

Con Zachman no existe una dirección establecida en el proceso para la aplicación de la

arquitectura. El objetivo es asegurarse de que todos los aspectos de una empresa estén
cubiertos y mostrar las relaciones que asegurarán un sistema completo sin importar el orden en el
cual se establecen. Mientras que con TOGAF si tienes requisitos previos para trabajar en la
arquitectura.

Será el Arquitecto de Empresa el que decida cuál Framework desea utilizar, como

TOGAF
The Open Group Architecture Framework[1]

Framework Open
Autor: The Open Group

Este framework de arquitectura empresarial fue desarrollado por The Open Group, su
nombre TOGAF proviene de las siglas (The Open Group Architecture Framework). Su
primer desarrollo se dio en 1995 basado en TAFIM (’Technical Architecture Framework
for Information Management’) . Es una herramienta para asistir en la aceptación, producción,
uso y mantenimiento de arquitecturas empresariales ,basandose en un modelo de proceso
iterativo soportado por buenas prácticas y un conjunto reusable de activos arquitecturales
existentes.

La primera versión de TOGAF fue desarrollada en 1995, basada en TAFIM -Technical Architecture
Framework for Information Management- del Departamento de Defensa de los Estados Unidos
La última versión es TOGAF 9.0 publicado en Enero de 2009.

Es un framework de EA que se puede complementar y ser usado en unión con otros frameworks
que son más específicos en algunos sectores como Gobierno, Manufactura,
telecomunicaciones, Defensa y Finanzas.

TOGAF Architecture Development Method (ADM), es el método en el que TOGAF desarrolla sus
arquitecturas dirigidas hacia las necesidades del negocio.

Principales componentes de TOGAF

– ADM (Architecture Development Method): Provee un número de fases para el desarrollo de la

arquitectura basada en un ciclo
, provee una narrativa para cada fase, que permite describir cada fase en términos de objetivos,
enfoque, entradas, fases y salidas. Las entradas y salidas proveen una definición de la estructura
del contenido del framework y los entregables, provee resúmenes para gestionar el
cumplimiento de requisitos

ADM de TOGAF

Cada una de las fases de este ADM, tiene sus propios entregables.

Los productos de TOGAF, se agrupan en 3 categorías:

– ENTREGABLE: es el producto de trabajo que esta contractualmente definido y que es revisado,
acordado y firmado por los actores. La unión de estos entregables forma un proyecto.

– ARTEFACTO: es un producto de trabajo más granular que describe una arquitectura desde un
punto de vista. Ejemplos: diagrama de red, especificación de un servidor, una especificación de
un caso de uso. Se subdivide en: Catalogos (listas de cosas), Matrices (relaciones entre cosas) y
Diagramas (pinturas de cosas)

– BLOQUE CONSTRUCTIVO: representa un componente (potencialmente reusable) de negocios,

de tecnología de información, o una capacidad arquitectural que combina otros bloques
constructivos. Los bloques constructivos pueden ser definidos a varios niveles: ABBs (Architecture
Building Blocks) típicamente describen la capacidad requerida en la forma de SBBs (Solution
Building Blocks) que representan componentes que son usados para implementar una
capacidad requerida

TOGAF se puede ver en 4 grandes grupos:

 En primera instancia TOGAF se enfoca en torno a la arquitectura empresarial,

comprendiendo sus 4 arquitecturas: arquitectura de negocio, arquitectura de
datos, arquitectura de aplicación y arquitectura de tecnología.

Método de Desarrollo de Arquitectura (ADM).

 Continuum Empresarial.

 Repositorio de la Arquitectura.

Por otra parte la Arquitectura Empresarial basada en TOGAF conduce a detallar el

mejor plan estratégico para su organización incluyendo sus cuatro dimensiones
negocio, aplicaciones, datos y tecnología.

Las 4 arquitecturas que TOGAF refiere para la arquitectura de una empresa son:

 Arquitectura de Negocio

 Arquitectura de Aplicación

 Arquitectura de Datos

 Arquitectura Tecnología

Figura 7. Arquitecturas de TOGAF

 Arquitectura de negocio: define estrategias, estructura, procesos y
gobernabilidad.

 Arquitectura de información: se basa en la descripción de la estructura de

los datos y en el manejo de ellos.

 Arquitectura de aplicación: bases para cada uno de los sistemas y su

relación con el negocio.

 Arquitectura de tecnología: se basa en la estructura de software y hardware

incluyendo área de comunicaciones y soporte.
https://mdc.org.co/que-es-la-arquitectura-empresarial/

Tabla 4. Identificación de Ventajas y Desventajas de los Frameworks

estudiados
 Framework Ventajas Desventajas
Zachman  Es relativamente sencillo,  Zachman dice que su
pues una persona de la
framework no es una
empresa lo puede aplicar metodología, sino una
sin ser especialista. estructura. “The Zachman
Framework™ IS NOT a
 No está relacionado con
methodology”42.
una herramienta en
especial, permitiendo ser  Es limitante al momento
implementado en de ampliar la AE. Pues
cualquier enfoque. no tiene definido un
futuro sobre la AE.
 Su matriz al tener 36
combinaciones permite  No proporciona un paso
llegar a detalles más a paso para la creación
profundos. de la arquitectura.

 Puede ser implementado  Es un framework que no

para el desarrollo de un especifica los modelos a
sistema, sin enfocarse a desarrollar en cada
AE. celda.

 Las partes interesadas  Criticado por el número

tiene su perspectiva de de celdas que posee,
acuerdo a los enfoques. considerado una
limitante en algunos
 Las preguntas resuelven casos.
la perspectiva de manera
 No es equilibrado, la
detallada. matriz muestra la lógica
de los artefactos para la
 La fácil comprensión de
la matriz permite que AE únicamente.
adaptarse a otros
 La información pública
42
ZACHMAN INTERNATIONAL frameworks.
ENTERPRISE ARCHITECTURE: John Zachman's
sobre cada una de Concise
las
Definition of The Zachman Framework™ [en linea] < http://www.zachman.com/about-the-zachman-
 Se especifican los roles
framework > [citado el 30 de Julio de 2014]
celdas es poca.
dependiendo la
perspectiva que se esté
trabajando.
Tabla 4. (Continuación)

TOGAF  The Open Gorup  Al tener su modelo ADM,

menciona que su no asegura una
framework es un método, clasificación de los
es desarrollado por artefactos.
variedad de personajes
expertos en el tema.  No tiene especificación
de roles en las fases.
 Es sencillo en su
vocabulario generando un  El uso es con fines no
comerciales, para una
lenguaje común.
organización debe ser
 Contiene estándares
recomendados. con licencia.

 Proporciona información
sobre otras herramientas
para complementar fases.
 Presenta un continuum
empresarial, para el futuro
de la AE.

 Relaciona la división de la
AE en las 4 arquitecturas
DoDAF  Aparentemente
generando únicomayor
en  Este framework está
su empleo entre
interacción de los "puntos
ellas. especialmente indicado
de vista operacionales". para grandes sistemas
 En Colombia el gobierno lo
 Los
toma puntos
como marcode vistade con integración e
ofrecen información interoperabilidad.
referencia para las
general y detalles  Esta claramente
entidades públicas.
enfocado a sistemas
específicos orientados a
los interesados dentro del militares.
dominio.  En Colombia no se conoce
de su aplicación a nivel
 Lograr resolver un
problema específico a general.

través de los puntos de  Generalmente los

expertos en el framework
vista asociados.
son trabajadores del
Fuente. El autor.  Integra 8 vistas en su
última versión, permitiendo departamento de
defensa.
abordan temas como las
Gartner Enterprise Architectural Framework GEAF.

La metodología Gartner Enterprise Architectural Framework considera que la arquitectura

empresarial trata de reunir componentes: dueño de negocio, especialistas en información e
implementadores de tecnología. Si una organización logra unir estas tres características y
unirlos con una visión común que impulse el valor del negocio, se reflejará con éxito.

Sin embargo para que en una organización funcione una metodología de arquitectura
empresarial, se requiere un gran compromiso y disposición de la organización para realizar
cambios si son necesarios. Compromiso que debe ser liderado por los altos mandos de las
organizaciones, con el objetivo de reducir los costos y la complejidad de los sistemas TI.

GARTNER FRAMEWORK
https://chae1700911004.wordpress.com/2015/09/26/marcos-referencia-arquitectura-
empresarial-dragon1-gartner-framework-federal-enterprise-architecture/

Para GARTNER la arquitectura empresarial es el proceso de traducir la visión y estrategia

de negocio en un cambio empresarial efectiva mediante la creación , la comunicación y la
mejora de los principios y modelos clave que describen el estado futuro de la empresa y
permiten su evolución.

GARTNER ve la arquitectura empresarial como un proceso continuo que implica evaluar el

estado actual de la arquitectura, la definición de los objetivos de la empresa y como estos
pueden ayudar a la compañía ha construir un estado futuro.

El marco de trabajo de Gartner es utilizado para construir una visión consolidada de la

empresa que se alinea con las necesidades de negocio.

COMPONENTES GARTNER FRAMEWORK

Descripción Detallada de los Componentes

GARTNER recomienda que los arquitectos principales y sus equipos establezcan y

desarrollen el proceso de arquitectura empresarial usando seis fases principales. Estas fases
pueden variar en funcion de los problemas que están tratando resolver y las decisiones que
esta tratando de tomar.
Estrategia y Plan : obtener un acuerdo sobre los principales problemas a resolver; realizar
la documentación del programa de Arquitectura Empresarial y desarrollar una descripción
del estado futuro a alcanzar, definir los requisitos, principios y modelo de ese estado
alcanzable.

Evaluar el Estado Actual: identifique su nivel actual de madurez estratégica y arquitectura

empresarial; recopile información existente que describa sus capacidades empresariales y
tecnológicas, practicas,modelos de procesos formales,datos y sistemas.

Evaluar las Competencias: realizar una identificación presupuestaria de personal y otros

requisitos para preparar el negocio y realizar un análisis de la estrategia. Revisar los
mecanismos presupuestarios establecidos y los procesos utilizados en las organizaciones
empresariales para la planearon estratégica e identificar que se puede refinar en ellos.

Obtener la Aprobación: Aprovechamiento de la documentación realizada en la fase

1,Traer expertos en negocios y TI juntos como parte de un ejercicio de planificación y
proporcionar a los ejecutivos de negocio y de TI un plan formal, Desarrollar los requisitos y
evaluar los resultados.

Implementar: Analizar los resultados de la planificación estratégica y evaluar en que se

debe realizar mas esfuerzas para llenar las brechas de la arquitectura empresarial.
Desarrollar planes de inversión utilizando casos de negocios que surgieron de la
arquitectura empresarial. Presentar los resultados a las partes interesadas y a los lideres
parea obtener planes de inversión aprobados.

Operar y evolucionar : Mejorar y perfeccionar sus esfuerzos. Con el tiempo, el estado

futuro se articulará en mayor detalle.

Cobit https://chae20151170101262.wordpress.com/category/cobit/

COBIT es un marco de referencia y un juego de herramientas de soporte que permiten a la

gerencia cerrar la brecha con respecto a los requerimientos de control, temas técnicos y
riesgos de negocio, y comunicar ese nivel de control a los Interesados (Stakeholders).
COBIT permite el desarrollo de políticas claras y de buenas prácticas para control de TI a
través de las empresas. COBIT constantemente se actualiza y armoniza con otros
estándares. Por lo tanto, COBIT se ha convertido en el integrador de las mejores
prácticas de TI y el marco de referencia general para el gobierno de TI que ayuda a
comprender y administrar los riesgos y beneficios asociados con TI. La estructura de
procesos de COBIT y su enfoque de alto nivel orientado al negocio brindan una visión
completa de TI y de las decisiones a tomar acerca de la misma.
Los beneficios de implementar COBIT como marco de referencia de gobierno sobre TI
incluyen:
• Mejor alineación, con base en su enfoque de negocios
• Una visión, entendible para la gerencia, de lo que hace TI
• Propiedad y responsabilidades claras, con base en su orientación a procesos
• Aceptación general de terceros y reguladores
• Entendimiento compartido entre todos los Interesados, con base en un lenguaje común
• Cumplimiento de los requerimientos COSO para el ambiente de control de TI
 COBIT
El COBIT es precisamente un modelo para auditar la gestión y control de los sistemas de
información y tecnología, orientado a todos los sectores de una organización, es decir,
administradores IT, usuarios y por supuesto, los auditores involucrados en el proceso.

El COBIT es un modelo de evaluación y monitoreo que enfatiza en el control de negocios y la

seguridad IT y que abarca controles específicos de IT desde una perspectiva de negocios.
Las siglas COBIT significan Objetivos de Control para Tecnología de Información y Tecnologías
relacionadas (Control Objectives for Information Systems and related Technology). El modelo es el
resultado de una investigación con expertos de varios países, desarrollado por ISACA (Information
Systems Audit and Control Association).
COBIT, lanzado en 1996, es una herramienta de gobierno de TI que ha cambiado la forma en que
trabajan los profesionales de tecnología. Vinculando tecnología informática y prácticas de control,
el modelo COBIT consolida y armoniza estándares de fuentes globales prominentes en un recurso
crítico para la gerencia, los profesionales de control y los auditores.

COBIT
Se aplica a los sistemas de información de toda la empresa, incluyendo los computadores
personales y las redes. Está basado en la filosofía de que los recursos TI necesitan ser
administrados por un conjunto de procesos naturalmente agrupados para proveer la información
pertinente y confiable que requiere una organización para lograr sus objetivos.

Misión del COBIT

Buscar, desarrollar, publicar y promover un autoritario y actualizado conjunto internacional de
objetivos de control de tecnologías de la información, generalmente aceptadas, para el uso diario
por parte de gestores de negocio y auditores.

BENEFICIOS COBIT
 Mejor alineación basada en una focalización sobre el negocio.
 Visión comprensible de TI para su administración.
 Clara definición de propiedad y responsabilidades.
 Aceptabilidad general con terceros y entes reguladores.
 Entendimiento compartido entre todos los interesados basados en un lenguaje común.
 Cumplimiento global de los requerimientos de TI planteados en el Marco de Control Interno de
Negocio COSO.

Estructura
La estructura del modelo COBIT propone un marco de acción donde se evalúan los criterios de
información, como por ejemplo la seguridad y calidad, se auditan los recursos que comprenden la
tecnología de información, como por ejemplo el recurso humano, instalaciones, sistemas, entre
otros, y finalmente se realiza una evaluación sobre los procesos involucrados en la organización.
"La adecuada implementación de un modelo COBIT en una organización, provee una herramienta
automatizada, para evaluar de manera ágil y consistente el cumplimiento de los objetivos de control
y controles detallados, que aseguran que los procesos y recursos de información y tecnología
contribuyen al logro de los objetivos del negocio en un mercado cada vez más exigente, complejo y
diversificado.
Publicado en Arquitecturas Empresariales, Cobit, Empresa

Deja un comentario

Etiquetas: arquitecturas empresariales, cobit, empresa, isaca, principios

Otras mejores prácticas o frameworks

6-. BABOK , ITIL, COBIT, DAMA y su Relación con Arquitectura Empresarial

¿Qué es el BABOK?
http://www.angellozano.com/que-es-el-
babok/
A N G E L L O Z AN O
Experto en Metodologías de Gestión y Desarrollo Software

31 marzo, 2015 / by Author Angel Luis Lozano Sánchez

ejecución.
El propósito primordial de la Guía BABOK es definir la profesión del Análisis de
Negocio. El BABOK define un punto de referencia para los Analistas de Negocio
con el fin de discutir el trabajo que realizan y asegurar que se tiene las habilidades
necesarias para ejecutar la función de manera efectiva. Del mismo modo, el
BABOK define las competencias y conocimiento que se deberían esperar de un
profesional experimentado y que las personas que trabajan con analistas de
negocio deberían conocer. El BABOK es el marco de referencia que describe las
tareas del Análisis de Negocio que deben de ser ejecutadas con el fin de entender
cómo una solución ofrecerá valor a una organización. Las formas que toman esas
tareas, el orden en que son ejecutadas, la importancia relativa de las tareas y otros
aspectos pueden variar, pero cada tarea contribuye de alguna forma, directa o
indirectamente al objetivo general.

Propósito de la Guía BABOK®

El propósito principal de la Guía BABOK® Guide es definir la profesión del Análisis de Negocio y proveer
un conjunto de prácticas comúnmente aceptadas. Esto ayuda a los profesionales en definir y discutir las
habilidades necesarias para desarrollar en forma efectiva el trabajo de Análisis de Negocio. La Guía
BABOK® Guide ayuda a las personas que trabajan con o emplean a los Analistas de Negocio a entender
las habilidades y conocimientos que deberían esperar de un profesional entrenado.

El Análisis de Negocio es una profesión amplia en la cual los Analistas de Negocio podrían trabajar en
distintos tipos de iniciativas en toda la empresa. Los profesionales pueden emplear distintas
competencias, conocimientos, habilidades, terminología y actitudes para desarrollar el trabajo de
Analista de Negocio. La Guía BABOK® Guide es un marco común para todas las perspectivas,
describiendo las tareas de Análisis de Negocio que son realizadas para analizar un cambio en forma
apropiada o evaluar la necesidad de un cambio. Las tareas pueden variar en forma, orden o importancia
para cada Analista de Negocio o para una iniciativa en particular.

Las seis Áreas de Conocimiento en que se divide este documento describen la práctica del Analisis de
Negocio que puede ser utilizada dentro de los límites de un proyecto o a través de la evolución de la
empresa o un ambiente de mejora continua.

1.2. ¿Qué es el Análisis de

Negocio?
Análisis de Negocio es la práctica de habilitar el cambio en una empresa al definir las
necesidades y recomendar soluciones que entreguen valor a los interesados. El Análisis de
Negocio permite a una empresa articular las necesidades y la razón del cambio y diseñar y
describir soluciones que puedan entregar valor.
 El Análisis de Negocio se realiza en una variedad de iniciativas dentro de una empresa.
Las iniciativas pueden ser estratégicas, tácticas u operacionales. En Análisis de Negocio
debe ser realizado dentro de los límites de un proyecto o como parte de las actividades de
mejora continua y evolución de la empresa. Puede utilizar para entender el estado actual, definir
el estado futuro y determinar las actividades requeridas para moverse del estado actual al
estado futuro.

Análisis de Negocio puede realizarse desde diversas perspectivas tales como agile, business
intelligence, information technology, business architecture y business process management. Una
perspectiva puede pensarse como un lente a través del cual el profesional del Análisis de
Negocio visualiza sus actividades en el contexto. Una o varias perspectivas pueden
aplicarse en una iniciativa y las perspectivas nombradas en esta guía no representan todos
los contextos del Análisis de Negocio o el conjunto completo de las disciplinas de Análisis de
Negocio.

1.3. ¿Quién es un Analista de

Negocio?
Un Analista de Negocio es cualquier persona que realiza las tareas de Análisis de Negocio
descriptas en la Guía BABOK® Guide sin importar el título que tenga en su trabajo o su rol en
la organización. Los Analistas de Negocio son responsables por descubrir, sintetizar y analizar la
información desde una gran variedad de fuentes en la organización, incluyendo herramientas, procesos,
documentación e interesados. El Analista de Negocio es responsable de elicitar las necesidades de los
interesados (lo cuál frecuentemente implica investigar y clarificar sus deseos expresados) para
determinar las causas subyacentes.

Los Analistas de Negocio juegan un rol en alinear las soluciones diseñadas y entregadas con las
necesidades de los interesados. Las actividades que un Analista de Negocio realiza incluyen:

 Entender los problemas y metas de la organización,

 Analizar necesidades y soluciones,

 Trazar estrategias,

 Dirigir el cambio,

 Facilitar la colaboración de los interesados.

ITIL https://metodologia.es/itil/
METODOLOGÍA
Metodologías para el desarrollo y mantenimiento de software y sistemas de
información 2 4 J U L I O , 2 0 1 7 P O R A U R E L I O G A N D A R I L L A S

La Biblioteca de Infraestructura de Tecnologías de Información (o ITIL, por sus

siglas en inglés) es un conjunto de conceptos y buenas prácticas usadas para la
gestión de servicios de tecnologías de la información, el desarrollo de tecnologías
de la información y las operaciones relacionadas con la misma en general. ITIL da
descripciones detalladas de un extenso conjunto de procedimientos de gestión
ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las
operaciones de TI. Estos procedimientos son independientes del proveedor y han
sido desarrollados para servir como guía que abarque toda infraestructura,
desarrollo y operaciones de TI.

https://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

Information Technology Infrastructure

Library
Ir a la navegaciónIr a la búsqueda

La Biblioteca de Infraestructura de Tecnologías de Información (o ITIL, por sus siglas en

inglés) es un conjunto de conceptos y buenas prácticas usadas para la gestión de servicios de
tecnologías de la información, el desarrollo de tecnologías de la información y las operaciones
relacionadas con la misma en general. https://consultantsfactory.com/itil-online-training-
certification da descripciones detalladas de un extenso conjunto de procedimientos de gestión
ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de
TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para
servir como guía que abarque toda infraestructura, desarrollo y operaciones de TI.

Historia[editar]
Aunque se desarrolló durante los años 1980, ITIL no fue ampliamente adoptada hasta
mediados de los años 1990. Esta mayor adopción y conocimiento ha llevado a
varios estándares, incluyendo ISO/IEC 20000, que es una norma internacional cubriendo los
elementos de gestión de servicios de TI de ITIL. ITIL se considera a menudo junto con otros
marcos de trabajo de mejores prácticas como la Information Services Procurement
Library (ISPL, ‘Biblioteca de adquisición de servicios de información’), la Application Services
Library (ASL, ‘Biblioteca de servicios de aplicativos’), el método de desarrollo de sistemas
dinámicos (DSDM, Dynamic Systems Development Method), el Modelo de Capacidad y
Madurez (CMM/CMMI) y a menudo se relaciona con la gobernanza de tecnologías de la
información mediante COBIT (Control OBjectives for Information and related Technology).
El concepto de gestión de servicios de TI, aunque relacionado con ITIL, no es idéntico: ITIL
contiene una sección específicamente titulada «Gestión de Servicios de TI» (la combinación
de los volúmenes de Servicio de Soporte y Prestación de Servicios, que son un ejemplo
específico de un marco ITSM). Sin embargo es importante señalar que existen otros marcos
parecidos. La Gestión de Servicio ITIL está actualmente integrado en el estándar ISO
20000 (anterior BS 15000).
ITIL se construye en torno a una vista basada en proceso-modelo del control y gestión de las
operaciones a menudo atribuida a W. Edwards Deming. Las recomendaciones de ITIL fueron
desarrolladas en los años 1980 por la Central Computer and Telecommunications
Agency (CCTA) del gobierno británico como respuesta a la creciente dependencia de las
tecnologías de la información y al reconocimiento de que sin prácticas estándar, los contratos
de las agencias estatales y del sector privado creaban independientemente sus propias
prácticas de gestión de TI y duplicaban esfuerzos dentro de sus proyectos TIC, lo que
resultaba en errores comunes y mayores costes.
ITIL fue publicado como un conjunto de libros, cada uno dedicado a un área específica dentro
de la Gestión de TI. Los nombres ITIL e IT Infrastructure Library (‘Biblioteca de infraestructura
de TI’) son marcas registradas de la Office of Government Commerce (‘Oficina de comercio
gubernamental’, OGC), que es una división del Ministerio de Hacienda del Reino Unido.
En abril de 2001 la CCTA fue integrada en la OGC, desapareciendo como organización
separada.1
En diciembre de 2005, la OGC emitió un aviso de una actualización a ITIL,2 conocida
comúnmente como ITIL v3, que estuvo planificada para ser publicada a finales de 2006;
habiendo sido realizada en junio de 2007. Se esperaba que la publicación de ITIL versión 3
incluyera cinco libros principales, concretamente: Diseño de Servicios de TI, Introducción de
los Servicios de TI, Operación de los Servicios de TI, Mejora de los Servicios de TI y
Estrategias de los Servicios de TI, consolidando buena parte de las prácticas actuales de la
versión 2 en torno al Ciclo de Vida de los Servicios.
Uno de los principales beneficios propugnado por los defensores de ITIL dentro de la
comunidad de TI es que proporciona un vocabulario común, consistente en un glosario de
términos precisamente definidos y ampliamente aceptados. Un nuevo glosario ampliado ha
sido desarrollado como entregable clave de ITIL versión 3.
Otros modelos: CMMI para el desarrollo de software y s3m,3 para el mantenimiento del
software

Certificación[
Los particulares pueden conseguir varias certificaciones oficiales ITIL. Los estándares de
calificación ITIL son gestionados por la ITIL Certification Management Board (ICMB) que
agrupa a la OGC, a itSMF International y a los dos Institutos Examinadores existentes: EXIN
(con sede en los Países Bajos) e ISEB (con sede en el Reino Unido).
Existen tres niveles de certificación ITIL v2 para profesionales:

1. Foundation Certificate (Certificado Básico): acredita un conocimiento básico de ITIL en

gestión de servicios de tecnologías de la información y la comprensión de la
terminología propia de ITIL. Está destinado a aquellas personas que deseen conocer
las buenas prácticas especificadas en ITIL.
2. Practitioner's Certificate (Certificado de Responsable): destinado a quienes tienen
responsabilidad en el diseño de procesos de administración de departamentos de
tecnologías de la información y en la planificación de las actividades asociadas a los
procesos.
3. Manager's Certificate (Certificado de Director): garantiza que quien lo posee dispone
de profundos conocimientos en todas las materias relacionadas con la administración
de departamentos de tecnologías de la información, y lo habilita para dirigir la
implantación de soluciones basadas en ITIL.
No es posible certificar una organización o sistema de gestión como «conforme a ITIL», pero
una organización que haya implementado las guías de ITIL sobre Gestión de los Servicios de
TI puede lograr certificarse bajo la ISO/IEC 20000.
La versión 3 de ITIL, que apareció en junio de 2007, cambió ligeramente el esquema de
Certificaciones, existiendo certificaciones puentes, se definen 3 niveles:

1. Basic Level (Equivalente a ITIL Foundation en v3)

2. Management and Capability Level (Equivalente a los niveles Practitioner y Manager en
ITIL v2)
3. Advanced Level (nuevo en v3)
Historia y precursores de ITIL[editar]
Lo que actualmente se conoce como ITIL versión 1, desarrollada bajo el auspicio de la CCTA,
se tituló Government Information Technology Infrastructure Method (‘Método de Infraestructura
de la Tecnología de Información del Gobierno’, GITM) y durante varios años terminó
expandiéndose hasta unos 31 libros dentro de un proyecto inicialmente dirigido por Peter
Skinner y John Stewart. Las publicaciones fueron retituladas principalmente como resultado
del deseo (por Roy Dibble de la CCTA) de que fueran vistas como una guía y no como un
método formal, y como resultado del creciente interés que había fuera del gobierno británico.
Muchos de los conceptos principales de gestión de servicios no surgieron dentro del proyecto
inicial de la CCTA para desarrollar ITIL. IBM afirma que sus Yellow Books (A Management
System for the Information Business, ‘Un sistema de gestión para el negocio de la
información’)45 fueron precursores clave. Según IBM:
A principios de los años 1980, IBM documentó los conceptos originales de Gestión de Sistemas en una
serie de cuatro volúmenes titulada A Management System for Information Systems (sic). Estos
ampliamente aceptados yellow books [...] fueron aportaciones claves para el conjunto originales de libros
de ITIL.
Otras publicaciones de IBM y comentarios de los autores de ITIL aclaran que los yellow
books fueron cruciales para el desarrollo del Servicio de Soporte pero que el volumen de
Entrega de Servicios no tomó prestado de ellos hasta tales extremos.

Críticas a ITIL[editar]
ITIL ha recibido críticas de varios frentes. Entre ellas:

 El hecho de que muchos defensores de ITIL parecen creer que es un marco holístico y
completo para el gobierno de TI.
 Su tendencia a convertirla en una religión.
Como señala Jan van Bon (autor y editor de muchas publicaciones de Gestión de Servicios de
TI):
Hay mucha confusión sobre ITIL, procedente de todo tipo de malentendidos sobre su naturaleza. ITIL,
como afirma la OGC, es un conjunto de buenas prácticas. La OGC no afirma que dichas mejores
prácticas describan procesos puros, ni tampoco que ITIL sea un marco diseñado como un modelo
coherente. Eso es lo que la mayoría de sus usuarios hacen de ella, probablemente porque tienen una
gran necesidad de dicho modelo.6
El columnista CIO Magazine Dean Meyer también ha expuesto algunos puntos de vista
cautelosos sobre ITIL,7 incluyendo cinco trampas típicas tales como «convertirse en esclavo
de definiciones desactualizadas» y «dejar que ITIL se convierta en religión». Como Meyer
señala, ITIL «no describe el abanico completo de procesos necesarios para ser líderes. Se
centra en [...] gestionar servicios actuales.»
La calidad de los volúmenes de la biblioteca se considera desigual. Por ejemplo, van
Herwaarden y Grift señalan que «la consistencia que caracterizaba los procesos de soporte al
servicio [...] se pierde en gran medida en los libros de entrega de servicio.»8
Todas estas manifestaciones acerca de ITIL provienen de compañías que en un momento
dado han logrado entender que para alcanzar objetivos de manera clara es necesario realizar
ciertas prácticas que cumplan con ese objetivo y los resultados demostrados son benéficos
para quien los desarrolla y para quien hace uso de este entorno.

Information Technology Infrastructure Library

(Itil)
ITIL son las siglas de una metodología desarrollada a finales de los años 80"s por iniciativa
del gobierno de los Estados Unido, específicamente por la OGC u Oficina Gubernativa
de Comercio Británica (Office of Goverment Comerce). Las siglas de ITIL significan
(Information Technology Infrastructure Library) o Librería de Infraestructura de Tecnologías
de Información.
Esta metodología es la aproximación más globalmente aceptada para la gestión de servicios de
Tecnologías de Información en todo el mundo, ya que es una recopilación de las mejores
prácticas tanto del sector público como del sector privado. Estas mejores prácticas de dan en
base a toda la experiencia adquirida con el tiempo en determinada actividad, y son soportadas
bajo esquemas organizacionales complejos, pero a su vez bien definidos, y que se apoyan
en herramientas de evaluación e implementación.

El objetivo de usar ITIL en Managed Services

ITIL como metodología propone el establecimiento de estándares que nos ayuden en el control,
operación y administración de los recursos (ya sean propios o de los clientes). Plantea hacer
una revisión y reestructuración de los procesos existentes en caso de que estos lo necesiten (si
el nivel de eficiencia es bajo o que haya una forma más eficiente de hacer las cosas), lo que nos
lleva a una mejora continua.
Otra de las cosas que propone es que para cada actividad que se realice se debe de hacer
la documentación pertinente, ya que esta puede ser de gran utilidad para otros miembros del
área, además de que quedan asentados todos los movimientos realizados, permitiendo que toda
la gente este al tanto de los cambios y no se tome a nadie por sorpresa.
En la documentación se pone la fecha en la que se hace el cambio, una breve descripción de los
cambios que se hicieron, quien fue la persona que hizo el cambio, así como quien es el que
autorizo el cambio, para que así se lleve todo un seguimiento de lo que pasa en el entorno. Esto
es más que nada como método con el que se puede establecer cierto control en el sistema de
cambios, y así siempre va a haber un responsable y se van a decir los procedimientos y cambios
efectuados.
Soporte de Servicio
El libro de Soporte de Servicio (Servicie Support, ITIL V2) se ocupa de asegurar que el Usuario
tenga acceso a los servicios apropiados que soporten las funciones de negocio. Los temas que se
tratan en el libro incluyen los siguientes Procesos:
 Gestión del Incidente
 Gestión del Problema
 Gestión de Configuración
 Gestión del Cambio
 Gestión de la Entrega
 Centro de Servicio al Usuario ( Función )
Provisión de Servicio
El libro de Provisión de Servicio analiza qué servicio requiere el negocio del proveedor
(entendiendo como proveedor la organización interna o externa que provee el servicio de TI),
para ofrecer un soporte adecuado a los Usuarios o Clientes de negocio. El libro cubre los
siguientes temas:
 1. Gestión del Nivel de Servicio: Este se encarga de evaluar el impacto del cambio en los
niveles de servicios y debe asegurar el cumplimiento de los SLAS en vigor en si se debe
asegurar que el objetivo final del cambio sea la mejora en calidad del servicio
 2. Gestión Financiera de Servicios TI: esta puede proponer cambios que disminuyan
los coste de la mantenimiento de la infraestructura TI
 3. Gestión de la Capacidad: este puede evaluar RFCs cuyo objetivo sea adecuar la
capacidad ti de la organización a las exigencias de los SLAstambién debe evaluar el impacto
de los cambios y evaluar las cargas a las que la infraestructura TI se vea sometida por razón
de estos
 4. Gestión de la Continuidad del Servicio de TI: Este debe vigilar que los cambios
realizados no afecten a los planes de contingencia.
 5. Gestión de la Disponibilidad: este se encargar monitorizar el proceso de cambio para
asegurar un mínimo impacto de este en la disponibilidad de los sistemas críticos. Aunque la
mejora en la disponibilidad de los servicios TI pueden ser el origen de una RFC
Procesos de cambio
 Monitorizar y dirigir todo el proceso de cambio.
 Registrar, evaluar y aceptar o rechazar las RFCs recibidas.
 Convocar reuniones del CAB, excepto en el caso de cambios menores, para la aprobación de
las RFCs y la elaboración del FSC.
 Coordinar el desarrollo e implementación del cambio.
 Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.
ITIL nos puede ayudar a que las cosas se puedan hacer de una manera más eficiente, ya que lo
que se propone es que se adopten ciertas métricas y procedimientos que otros proveedores de
IT adoptaron y que gracias a ellas son catalogadas como mejores prácticas.
organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son
independientes del proveedor y han sido desarrollados para servir como guía que abarque toda
infraestructura, desarrollo y operaciones de TIL.

Historia
Aunque se desarrolló durante los años 1980, ITIL no fue ampliamente adoptada hasta
mediados de los años 1990. Esta mayor adopción y conocimientoha llevado a varios estándares,
incluyendo ISO/IEC 20000, que es una norma internacional cubriendo los elementos de
gestión de servicios de TI de ITIL. ITIL se considera a menudo junto con otros marcos
de trabajo de mejores prácticas como la Información Servicios Procurement Library (ISPL,
"Biblioteca de adquisición de servicios de información"), la Application Services Library (ASL,
"Biblioteca de servicios de aplicativos"), el método de desarrollo de sistemas dinámicos (DSDM,
Dynamic Systems Development Method), el Modelo de Capacidad y Madurez (CMM/CMMI) y
a menudo se relaciona con la gobernanza de tecnologías de la información
mediante COBIT (Control OBjectives for Información and related Technology).
El concepto de gestión de servicios de TI, aunque relacionado con ITIL, no es idéntico: ITIL
contiene una sección específicamente titulada «Gestión de Servicios de TI» (la combinación de
los volúmenes de Servicio de Soporte y Prestación de Servicios, que son un ejemplo específico
de un marco ITSM). Sin embargo es importante señalar que existen otros marcos parecidos. La
Gestión de Servicio ITIL está actualmente integrado en el estándar ISO 20000 (anterior BS
15000).
ITIL se construye en torno a una vista basada en proceso-modelo del control y gestión de las
operaciones a menudo atribuida a W. Edwards Deming. Las recomendaciones de ITIL fueron
desarrolladas en los años 1980 por la Central Computer and Telecommunications Agency
(CCTA) del gobierno británico como respuesta a la creciente dependencia de las tecnologías de
la información piezas clave para el desarrollo y evolución de las compañías, deben estar bien
definidas y gestionadas, creando un alineamiento entre estas y las organizaciones que las
utilizan.
A finales de los 80 nació ITIL (Information Technology Infrastructure Library), que se ha
convertido en un estándar de facto mundial para la Gestión del Servicio de las Tecnologías de la
Información, proveyendo un conjunto cohesionado de mejores prácticas que abarcan tanto el
sector público como el privado.
ITIL
Es la metodología más reconocida a nivel mundial para la definición de todos los procesos
relacionados con la administración de IT. Pertenece al OGC (Office of Government Commerce),
previamente conocido como CCTA (Central Computer and Telecommunications Agency), un
departamento del gobierno del Reino Unido, y fue desarrollado durante fines de los 80.
Según se indica en su versión 2, ITIL describe todos los procesos necesarios para organizar la
Gestión del Servicio de las TI con vistas a garantizar los niveles de servicio acordados entre la
organización de TI y sus clientes. Estos procesos están focalizados en las mejores prácticas que
pueden ser utilizadas de formas distintas para adaptarse a las diferentes necesidades.
Recientemente ha salido a la luz la versión 3 (mayo 2007) que revisa profundamente la versión
anterior dirigiendo en esta ocasión su mirada a los servicios ofrecidos y su "ciclo de vida",
siendo su principal objetivo la alineación con las líneas estratégicas de la organización . Da un
especial énfasis a activo que supone las TI para la organización
Si bien hemos definido que es ITIL y a que afecta, no hemos definido el concepto de Gestión de
Servicio de las Tecnologías de la Información. Este concepto podemos definirlo como un
conjunto especializado de capacidades organizacionales para proveer de valor a los clientes en
forma de servicios (a través de las tecnologías de la información).
Por lo que siendo capaces de gestionar mejor los servicios proveídos por parte de las
Tecnologías de la Información a la sociedad, estamos mejorando la misma, haciéndola más
competitiva.

COBIT
El COBIT es precisamente un modelo para auditar la gestión y control de los sistemas de
información y tecnología, orientado a todos los sectores de una organización, es decir,
administradores IT, usuarios y por supuesto, los auditores involucrados en el proceso.
El COBIT es un modelo de evaluación y monitoreo que enfatiza en el control de negocios y
la seguridad IT y que abarca controles específicos de IT desde una perspectiva de negocios.
Las siglas COBIT significan Objetivos de Control para Tecnología de Información y Tecnologías
relacionadas (Control Objectives for Information Systems and related Technology). El modelo
es el resultado de una investigación con expertos de varios países, desarrollado por ISACA
(Information Systems Audit and Control Association).
COBIT, lanzado en 1996, es una herramienta de gobierno de TI que ha cambiado la forma en
que trabajan los profesionales de tecnología. Vinculando tecnología informática y prácticas de
control, el modelo COBIT consolida y armoniza estándares de fuentes globales prominentes en
un recurso crítico para la gerencia, los profesionales de control y los auditores.
COBIT
Se aplica a los sistemas de información de toda la empresa, incluyendo los computadores
personales y las redes. Está basado en la filosofía de que los recursos TI necesitan ser
administrados por un conjunto de procesos naturalmente agrupados para proveer la
información pertinente y confiable que requiere una organización para lograr sus objetivos.
Misión del COBIT
Buscar, desarrollar, publicar y promover un autoritario y actualizado conjunto internacional de
objetivos de control de tecnologías de la información, generalmente aceptadas, para el uso
diario por parte de gestores de negocio y auditores.
BENEFICIOS COBIT
 Mejor alineación basada en una focalización sobre el negocio.
 Visión comprensible de TI para su administración.
 Clara definición de propiedad y responsabilidades.
 Aceptabilidad general con terceros y entes reguladores.
 Entendimiento compartido entre todos los interesados basados en un lenguaje común.
 Cumplimiento global de los requerimientos de TI planteados en el Marco de Control
Interno de Negocio COSO.
Estructura
La estructura del modelo COBIT propone un marco de acción donde se evalúan los criterios de
información, como por ejemplo la seguridad y calidad, se auditan los recursos que comprenden
la tecnología de información, como por ejemplo el recurso humano, instalaciones, sistemas,
entre otros, y finalmente se realiza una evaluación sobre los procesos involucrados en la
organización.
"La adecuada implementación de un modelo COBIT en una organización, provee una
herramienta automatizada, para evaluar de manera ágil y consistente el cumplimiento de los
objetivos de control y controles detallados, que aseguran que los procesos y recursos de
información y tecnología contribuyen al logro de los objetivos del negocio en un mercado cada
vez más exigente, complejo y diversificado.

Conclusiones
Si bien COBIT es un marco general, su flexibilidad y versatilidad nos permite adaptarlo a
cualquier tipo y tamaño de empresa, realizando una implementación gradual y progresiva
acorde a los recursos disponibles y acompasando la estrategia empresarial.
Si bien aún no es requerido formalmente en forma regulatoria, es un estándar de facto en
toda Latinoamérica y es una fuerte recomendación en los ámbitos financieros .Es parte de
la misión de ISACA, la divulgación de COBIT y apoyo en la implementación como forma de
promover la eficiencia y buena gestión de los procesos de tecnología que nos permita
compararnos y mejorar día a día en pos de la concreción de los Objetivos de Negocio. En el
futuro, continuaremos viendo el crecimiento de COBIT en sus facetas de administración
y dirección de los recursos de tecnología. Aparecerán nuevas herramientas de la
familia de productos COBIT y nuevos recursos con los cuales mejorar la administración. Se
continuará refinando el producto en sí, mejorando la calidad de sus referencias cruzadas, su
relacionamiento con otros modelos, estándares y normas. Se procurará institucionalizar y
mejorar la calidad de las versiones en otras lenguas y, sin duda, continuará el esfuerzo
fundamental del ITGI en la difusión del uso de esta importante base de dirección.

Bibliografía
 http://www.monografias.com/trabajos31/metodologia-itil/metodologia-itil.shtml
 https://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library
DAMA

http://informatica.blogs.uoc.edu/2016/12/19/data-governance/

Universidad Oberta de Cataluña – Blog Informatica ++

Data Governance
by josé ramón | Dic 19, 2016 | Business Intelligence, Dirección de las TIC, Recurso, Sistemas de
información | 0 comments
El trabajo con datos bajo diferentes nombres (business intelligence, big data, data science, data
analytics, data governance y más) es una nueva función dentro de la empresa, que apareció en la
segunda mitad del siglo XX, pero que se ha consolidado en este siglo y que ya no desaparecerá.
Hablamos de la gestión del dato, como lo hacemos de la gestión de los recursos humanos, las finanzas o
el marketing. Tiene sus reglas de admisión, sus programas de formación, sus especialidades, sus
métodos, sus costumbres y sus gremios. Es ya una profesión, con muchas especialidades. Algunos de
estos expertos, se dedican al gobierno de los sistemas de datos, es decir, la organización, los
procedimientos y la administración y documentación de los sistemas de datos dentro de organizaciones
normalmente grandes.

GRÁFICA: La Rueda de la Gestión de Datos.

DAMA Internacional es la sociedad que agrupa a la comunidad de practicantes de la gestión de datos,
define los estándares de la profesión y proporciona certificados de aptitud, si pasas (y pagas) un examen.
Fue fundada en Los Angeles a finales de los 1980. DAMA gestiona un manual de buenas prácticas, el
DMBoK o Data Management Body of Knowledge, del que se puede descargar una versión corta
gratuitamente aquí. Las siglas recuerdan al estándar de gestión de proyectos, el PMBoK, bastante más
popular y al que hemos dedicado en este blog unas cuantas entradas. Según el DMBoK, “la gestión de
datos consiste en el desarrollo, la ejecución y la supervisión de planes, políticas, programas y prácticas
para controlar, proteger, servir y aumentar el valor de los activos de datos e información” que poseen las
empresas. Como se ve, se trata de un concepto paraguas, en el que caben los que administran bases de
datos, los auditores de la calidad o los desarrolladores de aplicaciones; pero, al contrario, no entrarían los
analistas de negocio ni los analistas y científicos de datos.
Como también ocurría con el PMBoK, no trata de lo que la gente hace (diseñar, construir, analizar,
presentar, preservar… para tomar decisiones), sino de los procedimientos, las reglas y los documentos
 que se tienen que cumplir para hacerlo. Lo piden los reguladores, Sarbanes-Oxley, Basilea II, etc. Está
pensado para la conservación, no para la decisión. Es una parte del gobierno corporativo. Para algunos,
resulta un poco aburrido: “El que escribió la metodología”, dije una vez, “no estaba en el cliente”.
Igual que el PMBoK, el DMBoK se organiza en torno a ocho áreas de conocimiento o competencias
temáticas:
 la gestión de la arquitectura de datos, que incluye el modelo de datos y su relación con el resto de
la arquitectura de empresa (John Zachman es presidente honorario de DAMA). Me gusta ésto.
 el desarrollo de datos (data development), que quiere decir el modelado de datos y el diseño de las
bases de datos.
 la gestión de la seguridad: estándares, clasificación, administración, autenticación y auditoría.
 dos áreas dedicadas a la gestión de los metadatos; me gusta –lo que quieren decir los datos para el
negocio, escondidos entre los códigos y etiquetas es donde reside el valor.
 el almacén de datos y la inteligencia de negocio que ahora llamamos “convencional”, pero que es la que
la mayoría de las empresas utilizan: la arquitectura, el diseño, la construcción, la explotación y sus
disciplinas asociadas (formación, soporte al usuario, control y fine tuning). Es también el escalado y la
integración de algoritmos y soluciones nuevas.
 la gestión de contenidos y documentos; a mí me gusta que esté aquí, otra gente no está de acuerdo.
Los big data, que necesitan trabajar sobre diferentes fuentes y códigos y realizar minería de textos y de
sentimientos la han vuelto a poner de moda.
 y la gestión de la calidad del dato: especificaciones, análisis, medición y mejora continua. O sea, el
cariño y el cuidado de lo que verdaderamente importa.
En Europa, como suele pasar, se ha creado un estándar propio que pone la atención en la calidad de los
datos. Es el Corporate Data Quality Management (CDQM), promovido por la European Foundation for
Quality Management y la Universidad de Saint Gallen. El CDQM se organiza en torno al ciclo de
gestión propio de cualquier función empresarial (la estrategia, la organización, los procesos, los
métodos…). El modelo europeo CDQM propone cinco estadios de evolución o estadios de madurez del
gobierno corporativo de datos que, como en otros inventos de la EFQM, permite autoevaluarse y
establecer una hoja de ruta de mejora.
El gobierno de los datos (data governance), que es el objetivo de estos modelos, ha dado lugar en las
organizaciones grandes a vicepresidentes, directores y comités para el gobierno de datos; incluso en
algunas empresas cotizadas forma parte del área de auditoría en el propio consejo de administración.
Algunos proponen una figura de Chief Data Officer (CDO) para las organizaciones grandes y, sin ir más
lejos, el primer ejecutivo de la tecnología de la empresa se llama el Chief Information Officer (CIO), o
sea el responsable de la información…
 Vengo de escuchar a Atish Banerjea, que acaba de ser nombrado CIO de Facebook, después de serlo de
NBCUniversal y de Pearson. La AIS, la gente de mi especialidad, le acaba de otorgar el premio
“Leadership Excellence Award”. Banerjea nos pedía a los académicos que formemos desde el grado a
expertos en ciberseguridad y en gestión y tecnologías de datos.
La UOC forma expertos en la gestión de datos y en las tecnologías de Business Intelligence y Big Data
en un Máster, que tiene dos itinerarios diferenciados (Análisis de Datos y Tecnologías), dos posgrados y
seis especialidades.

https://medium.com/data-management-en-espa%C3%B1ol/que-es-data-management-
e3e625ac974a

Que es Data Management?

Una Actividad Estratégica
Durante los últimos años hemos visto como los volúmenes de
datos han sido incrementados en las organizaciones, hoy en día
todos los movimientos que hacemos son registrados por
nuestros teléfonos inteligentes, sensores, logs de páginas web,
coordenadas de posicionamiento y hábitos de compras. La
competencia entre empresas está empezando a enfocarse más
en la experiencia de los usuarios que en los productos en si.
Ante este panorama abrumador de volúmenes de datos,
distintas fuentes, velocidad y formas surge el Data
Management.

Esta nueva disciplina es también conocida como un proceso de

negocios de alto nivel. Consiste en diferentes sub-procesos:

· Planificación y ejecución de

· Políticas, prácticas y proyectos que

· Adquieren, controlan, protegen, entregan y refinan el valor de

 · Los activos de datos e información

La misión de esta función es dar respuesta a las necesidades de

información de todos los sectores de la empresa en términos de
disponibilidad, seguridad y calidad de información.

Los objetivos estratégicos de la función de Data Management

son:

· Entender las necesidades de información de la empresa.

· Capturar, almacenar, proteger y asegurar la integridad los

activos de información.

· Continuamente mejorar la calidad de los datos e información

incluyendo:

· Exactitud de los datos.

· Integridad de los datos

· Integración de la información

· El tiempo de captura y presentación de los datos

· La definición de los datos.

· Asegurar la confidencialidad

· Maximizar el valor de los activos de datos.

Data Management es la conjunción de las distintas funciones

de manejo que propone DAMA International para garantizar el
manejo de datos corporativos.
Figura 1 — Funciones de Data Management (® DAMA
International)
El entorno actual presenta una combinación confusa de términos, métodos, herramientas,
opiniones y euforia. Para que madure la profesión de la gestión de datos, necesitamos
estándares profesionales:

Términos y definiciones estándar

Funciones, procesos y prácticas estándar
Roles y responsabilidades estándar
Entregables y métricas estándar

Estos estándares y mejores prácticas les facilitarán a los profesionales de la gestión de

datos, desempeñar su función en forma más eficaz. Asimismo, nos ayudarán a
comunicarnos mejor con nuestros compañeros de equipo, gerentes y ejecutivos. Los
ejecutivos en particular necesitan entender muy bien y valorar la gestión de datos, de tal
forma que puedan respaldar, patrocinar y proveer de personal a la función de gestión de
datos.

DAMA, por sus siglas en Inglés de la Asociación para la Gestión de Datos, es la principal
organización mundial para los profesionales en la gestión de datos. DAMA International
y la Fundación DAMA desarrollan estándares para esta profesión.

Funciones de la Gestión de Datos

Las nueve Funciones de la Gestión de Datos son:

Gobierno de Datos – planeación, supervisión y control en la gestión y uso de datos
Arquitectura, Análisis y Diseño de Datos – modelación y especificación de datos
Gestión de la Base de Datos – diseño de la base de datos, implementación y soporte
Gestión de la Seguridad de los Datos – asegurando privacía, confidencialidad y

acceso apropiado
Gestión de la Calidad de los Datos – definiendo, controlando y mejorando la calidad
de los datos

Gestión de Datos de Referencia y Maestros – administrando versiones maestras y

copias

Gestión del Almacenamiento de Datos e Inteligencia de Negocio – permitiendo

informes y análisis

Gestión de Documentos, Registro y Contenido – gestionando datos fuera de las bases

de datos

Gestión de Meta Datos – integrando, controlando y proporcionando meta datos

Arquitectura,
Análisis y
Gestión de Diseño de
Datos
Meta Datos

Gestión de
Documentos,
Registro y Gestión de la
Contenido
Base de Datos

Gobierno de

Datos
Almacenamiento
de los Datos e
Inteligencia de
Negocio Gestión de la
Seguridad de los
Datos

Gestión de los Gestión de la

Datos de Calidad de los
Referencia y Datos
Maestros
 Figura 2 Las nueve Funciones de la Gestión de Datos

El diagrama de arriba, muestra solo las nueve funciones y su secuencia de presentación

inicia al centro y luego girando en el sentido de las manecillas del reloj alrededor del
círculo, desde la posición 1:00 horas a la posición 11:00 horas. El diagrama abajo
proporciona una orientación general del alcance de cada función.

Resumen Funcional del DAMA-DMBOK©

Esta sección presenta el resumen de funciones, sub-funciones y actividades. Las

funciones y sub-funciones son tituladas sin frases sustantivas, mientras que las
actividades son tituladas con frases verbales. Además, cada actividad es categorizada en
uno de los siguientes cuatro grupos de actividad.

Cada actividad es categorizada según pertenezca a uno de los cuatro Grupo de Actividad:
Actividades de Planeación (P) Actividades que definen la dirección estratégica y
táctica para otras actividades de la gestión de
 datos. Las actividades de Planeación pueden ser
ejecutadas en forma recurrente.

Actividades de Control (C) Actividades de supervisión ejecutadas en forma

continua.

Actividades de Desarrollo (D) Actividades emprendidas dentro de proyectos y

reconocidas como parte del ciclo de vida del
desarrollo de sistemas (CVDS), creando
entregables de datos a través del análisis, diseño,
construcción, pruebas e implantación.

Actividades Operacionales (O) Actividades de servicio y soporte ejecutadas en

forma continua.

El grupo Data MAnagement (DAMA) está formado por miembros del departamento de Arquitectura de
Computadores. Miembro desde 2005 de Tecnio, una iniciativa de ACCIO (Agencia por la Innovación y
la Internacionalización de las empresas catalanas, de la Generalitat de Cataluña), está reconocido por el
Gobierno catalán como grupo de investigación consolidado.

El trabajo de este grupo está centrado en la investigación y la transferencia de tecnología en el ámbito de

la gestión y la recuperación de grandes volúmenes de datos, la calidad de la información y la exploración
de los datos.
Analizar cada una de estas funciones servirá para entender como
esta disciplina se está convirtiendo en estratégica, incluso la
figura del CDO (del inglés Chief Data Officer) se ganó un lugar
en la mesa de directorio de las empresas más grandes.