Guia Practica para EA

Una guía práctica
Arquitectura Empresarial Federal
Jefe de Información del Consejo Oficial
Version 1.0
de febrero de de 2001
Prefacio
Una arquitectura empresarial (EA) establece la hoja de ruta en todo el Organismo para lograr la misión de la Agencia ?? s un rendimiento óptimo
a través de sus procesos de negocio dentro de una eficiente tecnología de la información (TI). En pocas palabras, las arquitecturas
empresariales son planos ?? ?? para definir de manera sistemática y completamente una organización actual ?? s (línea de base) o entorno
deseado (objetivo). arquitecturas empresariales son esenciales para la evolución de los sistemas de información y el desarrollo de nuevos
sistemas que optimizan su valor misión. Esto se logra en términos lógicos o comerciales (por ejemplo, misión, funciones de negocio, flujos de
información, y sistemas ambientes) y técnicas términos (por ejemplo, software, hardware, comunicaciones), e incluye un plan de secuencia para
la transición desde el entorno de línea de base para el objetivo ambiente.
Si se define, mantenido, y aplicado efectivamente, estos planos institucionales ayudar en la optimización de las interdependencias e
interrelaciones entre ?? s de una organización de negocios y operaciones de la TI que soportan las operaciones subyacente. La experiencia de
la Oficina de Administración y Presupuesto (OMB) y la General Accounting Office (GAO) ha demostrado que sin una completa y forzada EA, las
agencias federales corren el riesgo de los sistemas de compra y construcción que son duplicadas, incompatibles, e innecesariamente costoso
de mantener e integrar.
Para EA sean útiles y proporcionan valor de negocio, su desarrollo, mantenimiento y puesta en práctica deben ser tratados eficazmente. Esta
guía proceso paso a paso está destinado a ayudar a los organismos en la definición, el mantenimiento y la implementación de las EA,
proporcionando un enfoque disciplinado y riguroso a la gestión del ciclo de vida de EA. Se describen las principales áreas de gestión de
programas de EA, a partir de la estructura de gestión y los controles sugeridos de organización, un proceso para el desarrollo de una arquitectura
de referencia y de destino, y el desarrollo de un plan de secuencia. La guía también describe EA mantenimiento y aplicación, así como la
supervisión y control. En conjunto, estas áreas proporcionan un modelo recomendado para una gestión eficaz de EA.
Fondo
Reflejando el consenso general en la industria que los grandes esfuerzos de desarrollo de sistemas complejos y de adquisición, deben guiarse
por las EA explícitos, el Congreso requirió Agencia Federal para los Directores de desarrollar, mantener y facilitar arquitecturas de sistemas
integrados con la aprobación de la Ley Clinger-Cohen 1 en 1996. Además orientación, la OMB ha publicado que requiere inversiones en sistemas
de información de la agencia para ser compatible con arquitecturas Federal, agencia y oficina. Otras orientaciones OMB dispone que el
contenido de las arquitecturas empresariales Agencia. 2 Del mismo modo, el Jefe Oficial de Información del Consejo, el Departamento del
Tesoro, el Instituto Nacional de Estándares Tecnología (NIST), y Gao, han desarrollado marcos de arquitectura o modelos que definen el
contenido de las arquitecturas empresariales. 3
1 Ley Pública 104-106, Sección 5125, 110 Stat. 684 (1996).

2 OMB Circular A-130, Gestión de Recursos de Información Federal, 30 de noviembre de 2000.
3 Arquitectura Empresarial marco federal, Versión 1.1, Federales del Consejo, de septiembre de 1999 los Directores de TI; Tesoro Enterprise
Architecture Framework, Versión 1, el Departamento del Tesoro, 3 de julio de 2000; el Instituto Nacional de Estándares y Tecnología Modelo
arquitectónico ?? s Empresa, se hace referencia en el NIST Special Publication 500 a 167, Direcciones gestión de la información: el reto de la
integración; y Planificación Estratégica de la Información: Marco de Diseño y Desarrollo de arquitecturas de sistemas ( GAO / IMTEC-92-51, junio de
1992).
iii
Una guía práctica para Federal Enterprise Architecture Prefacio
Esta guía se basa en, complementa y está directamente relacionada con el marco de la GAO Tecnología de la Información de Gestión de Inversiones
(ITIM) 4 que fue desarrollado para proporcionar una estructura común para la discusión y la evaluación de las prácticas de control de la inversión de TI
(CPIC) la planificación del capital y en las agencias federales. ITIM mejora la anterior guía de gestión de inversiones Federal de TI mediante la
ampliación de selección / control / Evaluar el enfoque, por mandato de la Ley Clinger-Cohen, en un marco de crecimiento y madurez. 5 También está
directamente vinculado al Marco de Arquitectura Empresarial Federal.
La necesidad de esta Guía
Si bien estos marcos y modelos proporcionan una valiosa orientación sobre el contenido de las arquitecturas empresariales, literalmente no hay F
Fmi
mi
rere
mi
mi r l orientación
r un l de cómo gestionar con éxito el proceso de creación, modificación y
utilizando la arquitectura de la empresa. Esta orientación es de crucial importancia. Sin ella, es muy poco probable que una organización puede
producir con éxito una EA completa y aplicable para la optimización de sus sistemas ?? el valor del negocio y el desempeño de la misión. Por
ejemplo, el desarrollo eficaz de una completa EA necesita un compromiso corporativo con el patrocinio de la alta dirección. El desarrollo de la
arquitectura de la empresa debe ser manejado como un proyecto formal por parte de una entidad de organización que es responsable por el
éxito. Dado que la EA facilita el cambio basado en el entorno empresarial cambiante de la organización, el arquitecto es el agente de cambio
principal organización ?? s. La aplicación efectiva requiere el establecimiento de la conformidad del sistema con la arquitectura, así como la
evaluación continua y la vigilancia del cumplimiento. La renuncia de estos requisitos puede ocurrir sólo después de un análisis cuidadoso,
minucioso y documentado. Sin estos compromisos, responsabilidades y herramientas, es grande el riesgo de que los nuevos sistemas no
cumplen con las necesidades del negocio, serán incompatibles, tendrán un mal desempeño, y costarán más para desarrollar, integrar y mantener
que se justifica.
Conclusión
Los procedimientos descritos en esta guía representan los principios fundamentales de la buena gestión de EA. Dado que la guía no es una talla única
para todos proposición, agencias u organizaciones deben adaptar sus recomendaciones y medidas para adaptarse a sus necesidades individuales. Le
animamos a considerar estos procesos de EA y las mejores prácticas cuidadosamente antes de buscar otros enfoques.
Una versión electrónica de esta guía se encuentra disponible en la siguiente dirección de Internet: http://www.cio.gov.
Si tiene preguntas o comentarios sobre esta guía, por favor, póngase en contacto con Rob Thomas C. II al (703) 921 a 6425, por correo electrónico a rob.c.thomas@customs.treas.gov
, O por correo a:
Servicio de Aduanas de los Estados

Unidos 7681 Boston Boulevard,
Springfield, VA 22153
4 Tecnología de la Información de Gestión de Inversiones: un marco para evaluar y mejorar la madurez del proceso
(GAO / AIMD-10.1.23, Proyecto de Norma, 2000).

5En el cuadro Seleccione fase, los costos y los beneficios de todos los proyectos disponibles son evaluados y se selecciona la cartera óptima de los proyectos.
Durante la fase de control, la cartera se supervisa y se aplica medidas correctivas cuando sea necesario. En la fase de evaluación, implementan proyectos son
revisados para garantizar que se están produciendo los beneficios esperados y los ajustes se hacen en su caso.
iv
créditos
Este documento fue elaborado por el Grupo de Trabajo Arquitectura Federal (FAWG) bajo la dirección estratégica de la empresa y el
Comité de Interoperabilidad Tecnología de la Información Emergente (EIEITC) del Consejo Federal funcionario de información. Las
siguientes personas han contribuido a la consecución de esta Guía.
Nombre Título Agencia

Rob C. Thomas, II Dir., Tech. Y arco. Grupo, Jefe de Arquitectura Servicio de Aduanas de EE.UU.
Randolph C. Hite Dir., Sistemas de Información Tecnología Cuestiones General Accounting Office
Ray Beamer Científico Senior Principal La Corporación MITRE
William H. McVay Analista Principal de Políticas Oficina de Administración y Presupuesto
Elaine Ward, Ingeniero principal La Corporación MITRE

Keith Rodas Jefe de Tecnología General Accounting Office
Mary Lou Collins Ingeniero líder La Corporación MITRE
George Brundage Arquitecto en jefe Departamento del Tesoro de EE.UU.
scott Bernard Consultor en administración Booz-Allen & Hamilton, Inc.

Lester diamante Subgerente General Accounting Office
Michael A. Tiemann Dir., Arch. Y Stnds. Div., Arquitecto Jefe Departamento de Energía de EE.UU.
Thomas P. Cullen analista de Políticas Servicio de Aduanas de EE.UU.
William Lew Subdirector Técnico General Accounting Office

John Anderson Ingeniero principal La Corporación MITRE
Daryl Knuth Arquitecto de información Servicio de Aduanas de EE.UU.
Barbara de Scott analista de gestión Departamento de Educación de EE.UU.
Paul J. Paradis analista de gestión Departamento de Energía de EE.UU.
naba Barkakati Subdirector Técnico General Accounting Office

Kathy Sowell Ingeniero líder La Corporación MITRE
Wayne Shiveley Científico Superior en Informática Oficina Federal de Investigaciones
v
vi
Tabla de contenido
Prefaceiii
1. Introducción................................................. .................................................. ...................................... 1

1.1. Propósito................................................. .................................................. ..................................... 1
1.2. Alcance................................................. .................................................. ........................................ 1
1.3. Audiencia ................................................. .................................................. .................................. 1

1.4. Organización del documento ................................................ .................................................. ............ 2
1.5. Como usar esta guia............................................. .................................................. ................. 3

1.6. Documentos relacionados ................................................ .................................................. ................... 4
2. Definiciones, controladores y Principios .......................................... .................................................. ...... 5
2.1. Empresa arquitectura definida ............................................... .................................................. 5

2.2. Los usos y beneficios de la arquitectura empresarial ........................................... ........................... 5
2.3. Legislación y otras Orientación .............................................. .................................................. 6 ..

2.4. Principios de Arquitectura ................................................ .................................................. .............. 7
2.5. El Ciclo de Vida Empresa .............................................. .................................................. ........... 8

2.6. El Proceso de Arquitectura Empresarial .............................................. ............................................. 9
3. Programa de iniciar Arquitectura Empresarial .............................................. ........................................ 11
3.1. Ejecutivo obtener la aceptación y apoyo ........................................... ........................................... 11

3.1.1. Garantizar la Agencia Cabeza aceptación y apoyo .......................................... ......................... 11
3.1.2. Emitir una Empresa Política de Arquitectura Ejecutivo ............................................ .......... 11
3.1.3. Obtener apoyo de la Alta Dirección y unidades de negocio ....................................... 12
3.2. Establecer Estructura de Gestión y Control ............................................. .............................. 13
3.2.1. Establecer un Comité de Revisión Técnica ............................................. ...................... 14
3.2.2. Establecer un Consejo de Inversión de Capital ............................................. .......................... 14
3.2.3. Establecer un Comité de Dirección Ejecutiva de EA ............................................ .............. 14
3.2.4. Designar arquitecto jefe ............................................... ................................................ 14
3.2.5. Establecer una Oficina de Gestión de Programas de Arquitectura Empresarial ............................ 15
3.3. Arquitectura Empresarial Programa de Actividades y Productos ............................................ ............ 17

3.3.1. Desarrollar un Plan de Estrategia y Comunicaciones de Marketing de EA .................................. 17
3.3.2. Desarrollar un Plan de Gestión de Programas EA ............................................ .................... 18
3.3.3. Iniciar el desarrollo de la arquitectura de la empresa ............................................ ....... 18
4. Definir un proceso de Arquitectura y enfoque .......................................... .................................... 21

4.1. Definir el uso previsto de la Arquitectura ........................................... .................................. 22
4.2. Definir el alcance de la Arquitectura ............................................ ............................................ 22
4.3. Determinar la profundidad de la Arquitectura ............................................ ...................................... 22
4.4. Seleccionar los productos adecuados EA .............................................. ................................................. 23

4.4.1. Seleccione los productos que representan el negocio de la empresa .................................... 23
4.4.2. Seleccione los productos que representan Agencia activos técnicos ........................................... 24
4.5. Evaluar y seleccionar un marco ............................................. ................................................ 24

4.5.1. Arquitectura Empresarial marco federal .............................................. .................. 25
vii
Una guía práctica para Federal Enterprise Architecture Contenido
4.5.2. DoD C4ISR arquitectura marco .............................................. ............................ 27

4.5.3. Tesoro Arquitectura Empresarial Marco .............................................. ................ 28
4.6. Seleccionar un conjunto de herramientas de EA .............................................. .................................................. ................. 30
5. Desarrollar la arquitectura de la empresa ............................................ .................................................. 33

5.1. Recopilar información ................................................ .................................................. ................. 34
5.2. Generar productos y poblar EA Repositorio ............................................ ........................... 35

5.2.1. Elementos de la construcción de la arquitectura de línea de base ............................................ ............. 36
5.2.2. Elementos de la construcción de la arquitectura destino ............................................ ................ 36
5.2.3. Revisar, validar y refinar los modelos ........................................... .............................. 38
5.3. Desarrollar el plan de secuencia .............................................. .................................................. ... 38
5.3.1. Identificar las brechas ................................................ .................................................. .............. 39
5.3.2. Definir y diferenciar Legacy, migración, y nuevos sistemas ................................. 39
5.3.3. Planificación de la migración ............................................... ................................................. 40
5.4. Aprobar, publicar y divulgar los productos de EA ......................................... ...................... 41
6. Uso de la arquitectura de la empresa ............................................ .................................................. ........ 43
6.1. Integrar la EA con CPIC y Procesos SLC .......................................... ............................. 43

6.1.1. Capacitar al personal de ................................................ .................................................. .......... 45
6.1.2. Establecer procesos de aplicación y procedimientos ............................................. .......... 45
6.2. Ejecutar el Proceso Integrado .............................................. .................................................. . 47

6.2.1. Iniciar un nuevo y Seguimiento de Proyectos ........................................... ................................ 47
6.2.2. Ejecutar los Proyectos ............................................... .................................................. .... 51
6.2.3. Completar el Proyecto ............................................... .................................................. ... 52
6.3. Otros usos de la EA ............................................. .................................................. ................. 54
7. Mantener la arquitectura de la empresa ............................................ ................................................ 55

Mantener la arquitectura de la empresa a medida que evolucione la empresa .......................................... .............. 55
7.1.1. Reevaluar la arquitectura de la empresa periódicamente ............................................. .......... 55
7.1.2. Manejo de los productos para reflejar la realidad ............................................. ................................ 56
7.2. Siga examinando las propuestas de EA Modificaciones ........................................... .................. 57
8. continuamente el Control y supervisar el programa Enterprise Architecture ................................. 59

8.1. Lograr la necesaria controles de gestión del programa de EA están en su lugar y funcionando ............. 59
8.2. ......................................... identificar donde las expectativas del programa de EA no se están cumpliendo ....... 59
8.3. Tomar medidas apropiadas para abordar las desviaciones ............................................ ........................ 60
8.4. Asegurar la mejora continua ............................................... ............................................... 60
9. Resumen ................................................. .................................................. ........................................ 63
Apéndice A: Funciones y responsabilidades EA ........................................... ................................................ sesenta y cinco
Apéndice B: Glosario .............................................. .................................................. ............................... 67
Apéndice C: Acrónimos .............................................. .................................................. ............................ 71
Apéndice D: Ejemplo de arquitectura Productos ............................................ ............................................ 73
D.1. Las declaraciones de misión y visión .............................................. .................................................. . 73
viii
Una guía práctica para Federal Enterprise Architecture Contenido
D.2. Diccionario información ................................................ .................................................. ........... 73

D.3. Concepto de Operaciones (CONOPS) Gráfico ........................................... .................................. 74
D.4. Los modelos de actividad y árboles .............................................. .................................................. ........ 76
D.5. Uso empresarial Modelo Caso .............................................. .................................................. ......... 78
D.6. Clase Modelo ................................................ .................................................. ............................ 81

D.7. Modelo de Estado ................................................ .................................................. ............................. 82
D.8. Diagramas de nodo de conectividad ............................................... .................................................. ... 83
D.9. Matriz de Intercambio de Información ............................................... .................................................. 86 ..
D.10. Organigrama................................................ .................................................. .................. 87

D.11. Interfaz de Sistemas Descripción y Diagrama de Conectividad ............................................ ........... 88
D.12. Perfil normas ................................................ .................................................. ..................... 89

D.13. Modelo Técnico de Referencia ............................................... .................................................. ..... 90
Apéndice E: Ejemplo de principios de la arquitectura ............................................ ........................................... 93
Apéndice F: Bibliografía .............................................. .................................................. ........................ 97
Apéndice G: El Marco Zachman ............................................ .................................................. 101
ix
Lista de Figuras
Figura 1. Función de los Principios de Arquitectura ........................................... .................................................. ....... 7

Figura 2. El ciclo de vida de la empresa ........................................... .................................................. ................ 8
Figura 3. El Proceso de Enterprise Architecture ........................................... .................................................. 9
Figura 4. nocional Organización EA ............................................ .................................................. ............. 13
Figura 5. La profundidad y el detalle de la arquitectura ......................................... .................................................. 21
Figura 6. Estructura de los Componentes FEAF .......................................... .................................................. 26
Figura 7. FEAF Arquitectura Matrix ............................................ .................................................. ............ 26
Figura 8. DoD C4ISR Marco ............................................ .................................................. ............... 27
Figura 9. DoD C4ISR productos ............................................ .................................................. ................... 28
Figura 10. La arquitectura marco Tesoro empresa .......................................... ......................... 29
Figura 11. Productos TEAF ............................................. .................................................. .......................... 30
Figura 12. Ejemplo Enfoque para el Desarrollo EA .......................................... ....................................... 33
Figura 13. Gráfico de sistemas de migración ............................................ .................................................. ............ 40
Figura ......................................... 14. Proyecto IMP / Arquitectura Marco de Evaluación ......................... 44
Figura 15. Gestión de Arquitectura ............................................. .................................................. .......... 45
Figura 16. Definir nuevo y Seguimiento de Programas / Proyectos ...................................... .................................. 48
Figura 17. ejecutar programas / Proyectos ........................................... .................................................. ........... 51
Figura 18. Evaluar los programas / proyectos ........................................... .................................................. .......... 53
Figura 19. Arquitectura de la Empresa Transición ............................................ ................................................ 56
Figura 20. factores claves de éxito ............................................ .................................................. .................... 61
Figura 21. DoD Battlespace Concepto de Operaciones gráfico ......................................... ............................ 74
Figura 22. Servicio de Aduanas de los Estados Unidos Concepto conformidad con el comercio de Gráfica de Operaciones ............................... 75
Figura 23. Genérico IDEF Actividad Modelo ........................................... .................................................. ...... 77
Figura 24. Aduanas de Estados Unidos, ACS, Árbol Actividad ........................................ .................................................. 77 ..
Figura 25. Aduanas de Estados Unidos, conformidad con el comercio, UML Actividad Modelo ...................................... ................... 78
Figura 26. Aduanas, Comercio Cumplimiento ?? externa, UML Diagrama de casos .................................. 79
Figura 27. Aduanas, Comercio Cumplimiento ?? interna, UML Diagrama de casos .................................. . 79
Figura 28. Aduanas de Estados Unidos, conformidad con el comercio, declaramos mercancías, UML especificación de casos de uso ................... 80
Figura 29. Aduanas de Estados Unidos, Cumplimiento Comercial, Comercial Vista, UML Diagrama de clases ........................... 81
Figura 30. Aduanas de Estados Unidos, conformidad con el comercio, Carrier, Diagrama de estado UML .................................... ......... 82
Figura 31. Aduanas, ACS, Sistemas de Aduanas, el Diagrama de Conectividad Nodo .................................... 84 ..
Figura 32. Aduanas, ACS, N 2 Gráfico................................................. .................................................. . 85
Figura 33. Diagrama de nodo de conectividad de la Fuerza Aérea de EE.UU. ......................................... .................................... 86
Figura 34. Organización Genérico Chart ............................................ .................................................. ......... 88
......................................... Figura 35. Interfaz de sistema genérico Descripción Diagrama de conectividad ......... 89
Figura 36. Normas Tabla de perfiles ............................................ .................................................. ............... 90
Figura 37. EE.UU. Aduanas Technical Reference Model .......................................... ...................................... 90
Figura 38. Genérico TRM Dominio y Definiciones sub-dominio y componentes ..................................... 91
Figura 39. El Zachman Marco Matrix ........................................... ................................................. 102
x
Lista de mesas
Tabla 1. Funciones y responsabilidades EAPMO ........................................... .................................................. 17

Tabla 2. Criterios Marco Selección ............................................ .................................................. ........ 25
Tabla 3. Criterios de selección de herramientas ............................................ .................................................. ................... 31
Tabla 4. Arquitectura de referencia y objetivos diferenciadores .......................................... .............................. 35
Tabla 5. Objetivos de EA Revisión ............................................ .................................................. ............................ 50
Tabla 6. Ejemplo información lógica matriz de intercambio .......................................... ............................... 87
xi
1. Introducción
1.1. Propósito
El propósito de este documento es proporcionar una guía a las agencias federales en la iniciación, desarrollo, uso y mantenimiento de
una arquitectura empresarial (EA). Esta guía ofrece un fin de extremo a procesar para iniciar, implementar y mantener un programa
de EA, y describe los papeles necesarios y las responsabilidades asociadas a un programa de EA con éxito.
Un EA establece la hoja de ruta en todo el Organismo para lograr la misión de la Agencia ?? s un rendimiento óptimo a través de sus
procesos de negocio dentro de una eficiente tecnología de la información (TI). En pocas palabras, las arquitecturas empresariales son planos
?? ?? para definir de manera sistemática y completamente una organización actual ?? s (línea de base) o entorno deseado (objetivo).
arquitecturas empresariales son esenciales para la evolución de los sistemas de información, el desarrollo de nuevos sistemas, y la inserción
de las nuevas tecnologías que optimizan su valor misión. Mientras que algunas agencias tienen arquitecturas empresariales en su lugar, otros
no. Para las agencias que ya tienen un EA en su lugar, esta guía debe ser adaptado a estas agencias ?? necesariamente. Para los
organismos más pequeños, una versión simplificada de la guía debe ser creado para apoyar las necesidades de la Agencia.
1.2. Alcance
Esta guía se centra en los procesos de EA, los productos y las funciones y responsabilidades. Aunque esta guía aborda el ciclo de vida de la
empresa, se describe en detalle cómo los procesos de EA relacionados con la ingeniería de la empresa, gestión de programas y la planificación
del capital y los procesos de control de la inversión (CPIC).
La amplitud y profundidad de la información que aquí se presenta se deben adaptar a su organización. Algunos ejemplos se
presentan en los apéndices, y las referencias a material complementario se incluyen en el texto o bibliografía. Siéntase libre para
individualizar estos ejemplos, según sea necesario.
1.3. Audiencia
Esta guía está destinada principalmente a los arquitectos de la Agencia Federal encargados de la generación y la
institucionalización de la EA. Este documento proporciona una guía a las agencias que actualmente no cuentan con EA y aquellos
que pueden beneficiarse de la mejora de sus métodos de EA para el desarrollo y mantenimiento. Para Agencias sin un EA, este
documento es una guía útil para el jefe de la agencia y el Oficial Jefe de Información (CIO) para educar y obtener el compromiso de
las partes interesadas clave en el establecimiento de un EA eficaz.
Esta guía también está dirigido a los participantes CPIC proceso [por ejemplo, juntas de revisión de inversión, y la Oficina de Administración y
Presupuesto (OMB)], así como los participantes del proceso de ingeniería de la empresa y la gestión de los programas (por ejemplo, los gerentes
de programas / proyectos, ingenieros de sistemas, aplicaciones arquitectos, desarrolladores de sistemas, administradores de configuración, los
gestores de riesgos, e ingenieros de seguridad).
Aunque la guía se refiere específicamente a las funciones y responsabilidades de los principales actores en el proceso de desarrollo de la
arquitectura, sino que también es un manual para cualquier persona que necesita saber más sobre el proceso de EA. Independientemente de su
función o responsabilidad ?? si usted tiene la responsabilidad exclusiva para el desarrollo de EA o es un miembro de un equipo de arquitectura
?? si usted está involucrado en el ciclo de vida de la empresa, esta guía es para usted.
1
Una guía práctica para Federal Enterprise Architecture Introducción
1.4. Organización del documento
El documento está organizado de la siguiente manera:
Sección 1: Introducción Define el propósito, alcance, el público y

organización del documento.
Sección 2: Definiciones, controladores y Presenta el contexto para el proceso de EA, es decir, los principios y
Principios los conductores legislativos, y define la, implementación y desarrollo
de la arquitectura proceso de mantenimiento.
Seccion 3: Programa de iniciar Define los pasos de procedimiento del programa de EA para iniciar el
Arquitectura Empresarial programa, la organización típica de EA, y los productos de la EA.
Sección 4: Definir un proceso de Define un proceso para la construcción de una arquitectura

Arquitectura y Enfoque empresarial y describe los marcos federal desarrollados.
Sección 5: Desarrollar la Proporciona los pasos de procedimiento para el desarrollo de arquitecturas de

Arquitectura referencia y objetivos y un plan de secuenciación.
Empresarial
Sección 6: Utilice la arquitectura de la Demuestra cómo el proceso de EA interactúa con la planificación del
empresa capital y el control de la inversión y con el Ciclo de Vida de Sistemas.
Sección 7: Mantener la Discute los procesos y procedimientos para mantener los productos de EA
arquitectura de la en todo el proceso del ciclo de vida.
empresa
Sección 8: Continua Control y Proporciona directrices para garantizar los procesos de EA y prácticas
supervisar el programa están siendo seguidos y remedios y acciones correctoras aplicadas
de EA cuando sea necesario.
Sección 9: Resumen Presenta aspectos más destacados de la guía EA y proporciona

recomendaciones finales para el inicio y la ejecución de un
programa de EA con éxito.
Apéndice A: Funciones y EA Proporciona una descripción concisa de los roles y responsabilidades del
Responsabilidades personal clave para el desarrollo de EA, implementación y mantenimiento.
Apéndice B: Glosario Proporciona una definición de los términos utilizados en este

documento.
Apéndice C: Acrónimos Proporciona una lista de todos los acrónimos utilizados en este
documento.
D Apéndice: Ejemplo Proporciona productos de muestra EA esenciales y de apoyo.

Arquitectura
Productos
2
Apéndice E: Muestra Describe muestras de los principios de la arquitectura esenciales que son un
Principios de punto de partida en el proceso de la arquitectura.
arquitectura
Apéndice F: Bibliografía Proporciona una lista de los principales documentos utilizados durante el
desarrollo de esta guía y otra documentación de la fuente informativa.
Apéndice G: El Zachman Presenta un resumen de los antecedentes y la descripción del marco

Marco de referencia Zachman y su aplicación a la arquitectura empresarial.
1.5. Como usar esta guia
Esta guía es un ?? how-to ?? Manual para los arquitectos de la Agencia Federal y las partes interesadas en el inicio, desarrollo, uso y
mantenimiento de las EA. Para encontrar una respuesta a su necesidad o pregunta específica, por favor consulte la tabla siguiente para ver
las preguntas más frecuentes. Estas y muchas otras preguntas son respondidas a lo largo de la guía.
Pregunta Sección
1. ¿Por qué desarrollar una EA? 2.0
2. ¿Cuáles son los principales beneficios de la utilización de un EA? 2.0
3. ¿Cuáles son las autoridades legislativas y mandatos para el uso de una 2.0
EA?
4. ¿Cuál es el ciclo de vida empresarial? 2.0
5. ¿Qué es una arquitectura de línea de base? 2.0
6. ¿Qué es una arquitectura objetivo? 2.0
7. ¿Qué es un plan de secuencia? 2.0
8. ¿Cómo funciona el proceso de EA se relacionan con el proceso de CPIC? 3.0
9. ¿Quién es responsable de las políticas de arquitectura? 3.0
10. ¿Quién es responsable de la EA? 3.0
11. ¿Cómo funciona un mercado del enfoque seleccionado a la alta 3.0

ejecutivos?
12. ¿Cuáles son los marcos y cómo puedo seleccionarla uno? 4.0
13. ¿Cómo se crea una arquitectura de referencia u objetivo? 5.0
14. ¿Cómo paso de la línea de base a la meta? 5.0
15. ¿Cómo se utiliza la EA dentro del proceso CPIC para justificar 6.0
las inversiones en tecnología de la información?
dieciséis. ¿Cómo se relacionan con los procesos de arquitectura otra empresa 6.0
actividades de ingeniería?
17. ¿Cómo se asegura un arquitecto gerente o solicitud de proyecto 6.0

la alineación de la EA al proponer un nuevo proyecto?
18. ¿Cómo se mantiene la EA en medio de los sistemas evolutivos 7.0

y los nuevos requerimientos del negocio?
19. ¿Cuáles son las funciones y responsabilidades cuando organizativas Apéndice A
3
Pregunta Sección
desarrollo y mantenimiento de un EA?
20. ¿Qué productos arquitectónicos se parecen? Apéndice D
21. ¿Cuáles son los principios arquitectónicos de EA? 2.0 y el Apéndice E
22. ¿Dónde puedo encontrar más información EA? Apéndice F y G
1.6. Documentos relacionados
• Marco de Arquitectura Empresarial Federal (FEAF), emitido por el Consejo Federal CIO, de fecha septiembre de 1999.
El FEAF proporciona una guía para el desarrollo, mantenimiento y facilitar las arquitecturas empresariales en el gobierno
federal.
• Arquitectura Guía para la Evaluación de alineación y, producido por el Consejo Federal CIO por el Grupo de Trabajo Arquitectura
Federal (FAWG), con fecha de octubre de 2000.
• Prácticas inteligentes en la planificación de capital, producido por el Comité de Dirección de TI FAWG y la planificación de capital y,
con fecha de octubre de 2000.
Junto con la GAO y la orientación de la OMB, estos documentos proporcionan orientación sobre la interacción e integración de los
procesos CPIC y EA. En conjunto, estos documentos describen los procesos CPIC y EA trabajan como un mecanismo de
gobierno para asegurar inversiones exitosas cambio y la información de la organización de tecnología (TI) para apoyar ese
cambio.
Véase el Apéndice F para obtener una lista completa de la documentación de referencia.
4
2. Definiciones, controladores y Principios
2.1. Arquitectura Empresarial Definido
terminología EA lleva muchas variaciones dentro de cada organización

Arquitectura empresarial • una base de información estratégica de
y en la gran variedad de literatura. Por lo tanto, los autores se han
activos, que define la misión, la información necesaria para llevar a
asentado en un conjunto coherente de las definiciones de los
cabo la misión y las tecnologías necesarias para llevar a cabo la misión,
principales términos utilizados en esta guía. La definición de
y los procesos de transición para la aplicación de las nuevas
tecnologías en respuesta a las necesidades de la misión cambiantes.
Arquitectura empresarial es la definición aprobado por el Consejo Una arquitectura empresarial incluye una arquitectura de línea de base,
Federal CIO y aparece en la versión de septiembre de 1999 de arquitectura objetivo, y un plan de secuenciación.
la FEAF. Aunque el término empresa se define en términos de
una organización, debe entenderse que, en muchos casos, la
empresa puede Transcend establecido límites de la
organización (por ejemplo, el comercio, la gestión de las
subvenciones, gestión financiera, logística).
Definiciones clave
Arquitectura • • la estructura de los componentes, su

interrelaciones, así como los principios y directrices que
Apéndice B contiene una lista de términos adicionales, sus
gobiernan su diseño y evolución en el tiempo.
definiciones, y la autoridad de origen.
Empresa • • una organización (o transversal

2.2. Los usos y beneficios de la empresa entidad organizativa) que soporta un ámbito de negocio definida y
Arquitectura misión. Una empresa incluye recursos interdependientes
(personas, organizaciones y tecnología) que deben coordinar sus
En general, las razones esenciales para el desarrollo de un EA funciones y compartir información en apoyo de una misión común
incluyen: (o conjunto de misiones relacionadas).
• Alineación ?? asegurar la realidad de la empresa en

marcha se alinea con la intención de la administración
arquitectura de línea de base • • el conjunto de productos que
?? s
retratar la empresa ya existente, las prácticas comerciales
• Integración ?? dando cuenta de que las reglas de actuales, y la infraestructura técnica. Comúnmente conocido como
negocio son consistentes en toda la organización, que el ?? tal cual ?? arquitectura.
los datos y su uso son inmutables, interfaces y el flujo

de información están estandarizados, y la conectividad y arquitectura objetivo • • el conjunto de productos que
la interoperabilidad son gestionados en toda la empresa retratar el futuro o estado final de la empresa, en general, capturado en
la organización ?? s pensamiento estratégico y planes. Comúnmente
conocido como el ?? A-Ser ?? arquitectura.
• Cambio ?? facilitar y gestionar el cambio a

cualquier aspecto de la empresa plan de secuenciación • • un documento que define la
estrategia para el cambio de la empresa desde la línea de base
• Hora de comprar ?? reducir el desarrollo de sistemas, actual a la arquitectura objetivo. Se horarios múltiples, simultáneas,
la generación de aplicaciones, plazos de modernización actividades interdependientes, e incremental generaciones que
y las necesidades de recursos evolucionará la empresa.
• Convergencia ?? esfuerzo hacia una cartera de Arquitectura Enterprise Products • • el

productos de TI estándar que figura en el modelo gráficos, modelos, y / o narrativa que describe el entorno
de referencia técnica (TRM). empresarial y el diseño.
5
Una guía práctica para Federal Enterprise Architecture Definiciones, controladores y Principios
Un EA ofrece beneficios tangibles para la empresa y los responsables de la evolución de la empresa. La EA puede:
• Captura de datos acerca de la misión, funciones, y la base de negocio de una manera comprensible para promover una
mejor planificación y toma de decisiones
• Mejorar la comunicación entre las organizaciones empresariales y las organizaciones de TI dentro de la empresa a través de
un vocabulario estandarizado
• Proporcionar puntos de vista de arquitectura que ayudan a comunicar la complejidad de los sistemas grandes y facilitar la
gestión de entornos amplios y complejos
• Centrarse en el uso estratégico de las tecnologías emergentes para mejorar la gestión de la empresa ?? s información e
insertar constantemente esas tecnologías en la empresa
• Mejorar la consistencia, exactitud, puntualidad, la integridad, la calidad, la disponibilidad, el acceso y el intercambio de TI

gestionados información en la empresa
• Apoyar los procesos de CPIC, proporcionando una herramienta para la evaluación de los beneficios, impactos y medidas de
inversión de capital y el apoyo a los análisis de alternativas, riesgos y compensaciones
• Resaltar las oportunidades para la construcción de mayor calidad y flexibilidad en las aplicaciones sin incrementar el
costo
• Lograr economías de escala, proporcionando mecanismos para el intercambio de servicios en toda la empresa
• Acelerar la integración de la herencia, la migración, y los nuevos sistemas
• Asegurar el cumplimiento legal y normativo. El propósito principal de un EA es informar, orientar, y constreñir las decisiones de la
empresa, especialmente los relacionados con las inversiones en TI. El verdadero reto de ingeniería de la empresa es mantener la
arquitectura como un recurso de autoridad principal para la planificación de TI de la empresa. Este objetivo no se cumple a través de la
política forzada, sino por el valor y la utilidad de la información proporcionada por la EA.
2.3. Legislación y otras Orientación
Dentro del gobierno Federal, numerosas normas y disposiciones regulan el desarrollo y ejecución de la política de TI. Estas directrices
se han establecido para mejorar la gestión de los planes estratégicos, mejorar las prácticas de adquisición de TI, TI justificar los gastos,
medir el rendimiento de TI, informe de resultados al Congreso, integrar las nuevas tecnologías, y gestionar los recursos de información.
La Ley Clinger-Cohen tiene cada organismo CIO responsable de desarrollar, mantener y facilitar la implementación de una
arquitectura técnica de la información. Orden Ejecutiva 13011, Tecnología de la Información Federal, estableció el Consejo
Federal CIO como el foro interinstitucional principal para mejorar las prácticas en el diseño, la modernización, el empleo, el
intercambio y el rendimiento de los recursos de información de la Agencia. Las secciones 1 a 3 del Consejo Federal CIO s ?? Arquitectura
Guía de Evaluación de Alineamiento y describir la reforma de TI y su evolución. La guía destaca orientación OMB dirigido a la
comunidad Federal, que se extendía más allá de la reforma de la Ley Clinger-Cohen. El Consejo Federal CIO comenzó a
desarrollar el Marco de Arquitectura Empresarial Federal en abril de 1998, de conformidad con las prioridades enunciadas en
Clinger-Cohen y lo emitió en 1999.
6
Fuentes adicionales de mandatos y controladores para EA incluyen:
• Ley de Eliminación de Trámites Gobierno (GPEA)
• Freedom of Information Act (FOIA) y Enmiendas de

• Rendimiento Gobierno Resultados Acta de 1993 (GPRA)
• OMB circulares A ?? 130 y A ?? 11
• GAO de orientación, hallazgos y recomendaciones
• los documentos del Consejo Federal CIO.
2.4. Principios de Arquitectura
Principios establecen la base para un conjunto de reglas y comportamientos para una organización. Hay principios que rigen el
proceso y los principios que rigen la aplicación de la arquitectura de EA. principios de arquitectura para el proceso de EA afectan el
desarrollo, mantenimiento y uso de la EA. principios de arquitectura para la implementación de EA establecen los primeros
principios y orientaciones de toma de decisiones relacionadas con el diseño y desarrollo de sistemas de información.
El arquitecto jefe, junto con el CIO y seleccionar los gerentes de empresas de la Agencia, define los principios de la arquitectura
que se asignan a la organización ?? s visión de TI y los planes estratégicos. Como se muestra en la Figura 1, los principios
arquitectónicos deben representar los requisitos y prácticas que se consideran bueno para la organización fundamentales.
Estos principios deben ser refinados para satisfacer las necesidades del negocio de representación. Debería ser posible
asignar acciones específicas, tales como el desarrollo de EA, las adquisiciones de sistemas, y la ejecución, a los principios de
la arquitectura. políticas deliberadas y explícitas en estándares orientados y directrices para el desarrollo e implementación de
EA se generan de acuerdo con los principios. Cada una de las fases del ciclo de vida de sistemas es apoyado por las acciones
requeridas por los principios de la arquitectura.
Planes Necesidades
Necesidades del
del negocio
negocio
Planes estrategicos
estrategicos
Vision
Vision IT,
IT,
requisitos
requisitos yy
Prácticas
Prácticas
principios
Trascendencia
Trascendencia ?? EA ?? Comportamiento
Comportamiento
Empresa
Políticas y Planificación y Control de

Ciclo de Vida de Sistemas
Lineamientos de EA Inversiones de Capital
?? Migración Sistemas ??
?? EA ?? Desarrollo EA ?? Selección de Proyectos ??
Tecnología de Inserción ??
Uso ?? EA Mantenimiento Control de Proyecto ?? Evaluacion
Operaciones de doble ?? Los planes
?? EA cumplimiento de proyecto ?? Retorno de la
de despliegue
inversión
Figura 1. Función de los Principios de Arquitectura
7
Apéndice E proporciona los principios de muestra de EA para su consideración como punto de partida, así como la razón de ser y el
impacto de la aplicación de cada principio. Cada Agencia debe aplicar, añadir, o modificar estos principios de la muestra. La formulación de
estas declaraciones de apoyo debe ser una parte esencial del esfuerzo de una Agencia ?? s para definir sus principios.
2.5. El Ciclo de Vida Empresa
El ciclo de vida de la empresa es el proceso dinámico e iterativo de cambiar la empresa a través del tiempo mediante la incorporación de
nuevos procesos de negocio, nuevas tecnologías, y nuevas capacidades, así como el mantenimiento y la disposición de los elementos
existentes de la empresa.
Aunque el proceso de EA es el tema principal de esta guía, no se puede hablar sin tener en cuenta otros procesos estrechamente
relacionados. Estos incluyen la ingeniería de la empresa y el ciclo de gestión del programa (más comúnmente conocido como el
ciclo de vida de desarrollo del sistema / adquisición) que ayuda en la ejecución de un EA, y el proceso de CPIC que selecciona,
controla y evalúa las inversiones. Suprayacente estos procesos son la gestión del capital humano y la gestión de seguridad de la
información. Cuando estos procesos trabajan juntos de manera efectiva, la empresa puede gestionar de forma efectiva como un
recurso estratégico y facilitador de procesos de negocio. Cuando estos procesos están sincronizados adecuadamente, sistemas
migran de manera eficiente de los entornos de tecnología de legado a través de desarrollos evolutivos e incrementales, y la Agencia
es capaz de demostrar su retorno de la inversión. La Figura 2 ilustra la interacción de los ciclos dinámicos e interactivos, ya que se
producirían en el tiempo.
Vid
a El Ciclo
o de
icl as
C
tem de Vida
is
d eS Ingeniería de la
Empresa
empresa
y gestión
de programas La migración de sistemas
Proceso
Modernización
de EA
Re
cu
hu rso Operaciones y Mantenimiento
ma s
no Proceso
s
CPIC
de
st ion
Ge ad
d
uri
seg
Figura Ciclo 2. La Empresa Vida
8
2.6. El Proceso de Arquitectura Empresarial
Como requisito previo para el desarrollo de cada arquitectura de la empresa, cada organismo debe establecer la necesidad de
desarrollar una EA y formular una estrategia que incluye la definición de una visión, objetivos y principios. La figura 3 muestra una
representación del proceso de EA. aceptación y el apoyo de la dirección deben ser establecidos y un equipo de arquitectos crean dentro
de la organización. El equipo define un enfoque y un proceso adaptado a las necesidades de la Agencia. El equipo de arquitectura
implementa el proceso de construir tanto la línea de base y el objetivo EA. El equipo de arquitectura también genera un plan de
secuenciación para la transición de los sistemas, aplicaciones y prácticas de negocio asociados afirmados sobre un análisis detallado
brecha. La arquitectura se emplea en la CPIC y los procesos de ingeniería de la empresa y la gestión de programas a través de
prioridad, proyectos incrementales y la inserción de las nuevas tecnologías emergentes. Por último, las arquitecturas se mantienen
gracias a una modificación continua para reflejar la línea de base actual de la Agencia ?? s y orientar las prácticas de negocio, objetivos
de la organización, visiones, la tecnología y la infraestructura.
sección 3.1
Ejecutivo
sección 3.2
obtener la
aceptación y Establecer
sección 7 apoyo Estructura y
Mantener la
arquitectura de la
Control de
empresa
Gestión
Control y Definir una

Control y
Supervisión
Supervisión arquitectura Sección 4
sección 6 Proceso y
Enfoque
arquitectura de la empresa
secuenciación utilizan la Desarrollar
Desarrollar el Plan de
Base
Objetivo Arquitectura
Desarrollar la Empresarial
sección 5.2
Arquitectura
sección 5.3 Empresarial
sección 5.2
Figura Proceso 3. La arquitectura de la empresa
9
10
3. Programa de iniciar Arquitectura Empresarial
La arquitectura de la empresa es un activo de la empresa que debe ser manejada como un programa formal. La ejecución exitosa del
proceso de EA es una tarea que requiere la gestión de todo el Organismo, la asignación de recursos, la continuidad y la coordinación.
Agencia ejecutivos de las líneas de negocio deben trabajar en estrecha colaboración con el equipo de arquitectura Agencia para producir
una descripción de las operaciones de la Agencia ?? s, una visión del futuro, y una estrategia de inversión y tecnología para lograr las
metas definidas.
La experiencia demuestra que la obtención de la cooperación necesaria entre los ejecutivos de la agencia no es una tarea fácil. La
creación de un programa de EA exige un liderazgo sostenido y fuerte compromiso. Este grado de patrocinio y compromiso necesita el
buy-in del jefe de la agencia, el liderazgo por el CIO, y la pronta designación de un jefe de arquitectura.
3.1. Ejecutivo obtener la aceptación y apoyo
Obtener el compromiso ejecutivo para cualquier nueva iniciativa requiere el desarrollo de un modelo de negocio fuerte y un enfoque
de comunicación para transmitir eficazmente ese caso negocio. Desde el concepto de EA no se entiende intuitivamente fuera de la
organización CIO, el CIO debe crear una estrategia de marketing para comunicar el valor estratégico y táctico para el desarrollo de
EA para el director del organismo, otros altos ejecutivos de agencias y unidades de negocio.
3.1.1. Garantizar la Agencia Cabeza aceptación y apoyo
Sin aceptación por parte de la Agencia de cabeza, el CIO tendrá dificultades para mantener el patrocinio necesario deseada para
financiar e implementar sistemas y procesos mejorados. El CIO toma la iniciativa para que los conceptos y ganar el Jefe ?? s
Agencia de buy-in. Esto se puede lograr por:
• Aprovechando los casos de éxito de otras organizaciones del sector de agencias y privadas, así como la experiencia y el
conocimiento de los expertos de EA
• Utilizando ejemplos para demostrar cómo una EA puede proporcionar un modelo y hoja de ruta para los cambios
deseados o mejoras en el rendimiento de la misión y la responsabilidad
• Haciendo hincapié en los requisitos legislativos para el desarrollo, mantenimiento e implementación de un EA dentro del
sector federal.
Una vez que el CIO se aseguró el director del organismo entiende la necesidad de un EA, es importante asegurar el compromiso del
Jefe ?? s Agencia para ejercer el esfuerzo de la arquitectura. El CIO logra esto mediante la movilización de reconocimiento de la cabeza
?? s Agencia en la expresión de un apoyo claro, todo el Organismo. Esto establecerá un mandato para los ejecutivos de negocios y CIO
para apoyar el esfuerzo asignando el tiempo y los recursos necesarios. El CIO debe coordinar con el jefe de la agencia en la selección
de un ejecutivo de la Agencia para ser designado como el jefe de arquitectura. La experiencia demuestra que el CIO ?? s autoridad por
sí sola es insuficiente para hacer que el esfuerzo sea un éxito. Un mandato claro del jefe de la agencia es un requisito previo para el
éxito.
3.1.2. Emitir una política de empresa Arquitectura Ejecutivo
El CIO, en colaboración con el director del organismo, desarrolla una política basada en la Agencia ?? s principios de
arquitectura que rige el desarrollo, implementación y mantenimiento de la EA. La política de EA debe ser aprobado por el
director del organismo y, como mínimo, debe incluir:
11
Una guía práctica para Federal Enterprise Architecture Programa de iniciar Arquitectura Empresarial
• Descripción de la finalidad y el valor de una EA
• Descripción de la relación de la EA con la visión y los planes estratégicos de la Agencia ?? s
• Descripción de la relación de la EA para la planificación del capital, la ingeniería de la empresa y la gestión de programas
• La traducción de las estrategias de negocio en EA objetivos, metas y estrategias
• Compromiso de desarrollar, implementar y mantener un EA
• Identificación de cumplimiento de EA como un criterio para las inversiones nuevas y en curso
• Visión general de una política de ejecución
• prácticas de seguridad para incluir la certificación y acreditación
• Nombramiento del Jefe de Arquitectura y el establecimiento de un equipo central de EA
• Establecimiento de la Oficina de Gestión de Programas de EA (EAPMO)
• Establecimiento del Comité de Dirección Ejecutiva de EA (EAESC).
3.1.3. Obtener apoyo de la Alta Dirección y Unidades de Negocio
El compromiso y la participación de la Agencia ?? s equipos ejecutivos y de negocios de alto nivel son de vital importancia. El
CIO debe iniciar un programa de marketing para enfatizar el valor de la arquitectura y el apoyo y el compromiso de la cabeza ??
s Agencia. El equipo de altos ejecutivos y sus unidades organizativas son ambos actores y usuarios de la arquitectura. Por lo
tanto, el CIO invierte tiempo y esfuerzo para familiarizar al personal con lo que una EA es y cómo puede ayudar a alcanzar las
metas y los compromisos de la organización. A pesar de que el público objetivo varía entre las Agencias, la audiencia para los
departamentos debe incluir el Adjunto y Subsecretarios y los Subsecretarios y su personal clave. Para Agencias, el público
debe incluir el Adjunto y administradores, miembros de la Comisión o una oficina de los jefes.
El objetivo principal de la educación de los departamentos y organismos ejecutivos de alto nivel es el de obtener su consentimiento y el
compromiso a que sus organizaciones como participantes activos. La participación puede involucrar a los ejecutivos (o sus representantes)
en asistir a las sesiones de planificación, de comprometer recursos (personas y financiación) para tareas específicas, o convertirse en un
campeón o portavoz del esfuerzo. El mantenimiento de la participación y el apoyo de los ejecutivos clave es crucial para el mantenimiento de
un esfuerzo exitoso.
El arquitecto jefe debe crear un plan para obtener el apoyo de las unidades de negocio ?? s la empresa. Se recomienda que las
unidades de negocios establecen un "círculo interno" de los propietarios de dominios y expertos en la materia (SME). Este grupo de
liderazgo debe consistir en que los directores de unidades de negocio ?? propia ?? líneas de negocio específicas. Este grupo de
liderazgo debe ser capaz de comprender y comunicar las metas y objetivos de la empresa, y para pensar de forma creativa, con la
consideración de los presupuestos y otras limitaciones. Este grupo de directivos es responsable de asegurar que las capas de negocio
de la arquitectura están bien documentados, y que el plan de secuencia tiene sentido desde el punto de vista de la estrategia de negocio,
teniendo en cuenta los procesos automatizados y no automatizados tanto.
Una vez que la política de EA ha sido difundido, el Arquitecto CIO y jefe debe organizar y llevar a cabo una junta de inicio del
programa para explicar los EA metas, objetivos, procesos, productos y relaciones con las actividades del ciclo de vida de
desarrollo de sistemas, planificación de capital y el proceso de inversión, y otras actividades relacionadas. El objetivo de la
reunión inicial del programa es
12
promover el buy-in de los participantes del programa en los niveles medios y bajos de la organización. Después de varios de los
primeros productos de EA son desarrollados y analizados, los productos y el análisis deben ser diseminados a lo largo de la Agencia y
sus comunidades de interés para demostrar el valor de estos primeros resultados y lograr la máxima exposición de los beneficios de los
esfuerzos de desarrollo de EA.
3.2. Establecer Estructura y Control de Gestión
La Figura 4 ilustra una organización del programa nocional para gestionar,

controlar y supervisar la actividad de EA y el progreso. La organización muestra los
funcionales funciones, interrelaciones, y las líneas deseadas de comunicación. La Establecer Estructura y
estructura de la organización debe facilitar y promover el desempeño de los roles y Control de Gestión
responsabilidades de EA. Los papeles de la EAESC, Comité de Revisión Técnica
(TRC), y la Oficina de Gestión de Programas de EA son únicos para la introducción
del proceso de EA. Otras funciones, como control de calidad (QA), Gestión de la
Configuración (CM), Gestión de Riesgos (RM), de Seguridad, y la evaluación son
las funciones habituales de soporte de TI. Estas funciones se ampliaron para
incluir explícitamente responsabilidades relacionadas con la EA.
papeles EA deben ser evaluados basándose en el tamaño de la organización, la complejidad de la empresa y la arquitectura, y otros
factores para determinar eficazmente la correlación de roles asignados a personal. En una organización grande con complejos procesos
de negocio, un individuo puede ser responsable de una función específica. En las agencias u organismos más pequeños, un individuo
se le puede asignar varias funciones y responsabilidades.
Cabeza Agencia
Organización
EA Ejecutivo jefe de
Consejo de la personal
Comité Información
inversión de
Directivo Oficial capital
Organización línea de negocio Seguro de Comité de

calidad Revisión
Propietarios de Dominio Técnica
Expertos en la materia
Evaluación Gestión de riesgos
Arquitecto en jefe
equipo de gestión de programas de EA
Gestión de la
configuración
Oficina de Arquitectura del núcleo del
Figura 4. nocional Organización EA
13
3.2.1. Establecer un Comité de Revisión Técnica
El CIO debe Carta y designar un Comité de Revisión Técnica para gestionar la revisión de los proyectos candidatos y evaluar
la alineación del proyecto con la EA. Una vez que la EA se ha desarrollado y aprobado, la CVR evalúa cada inversión
propuesta por el cumplimiento de la arquitectura. La CVR informa de sus conclusiones y proporciona recomendaciones a un
Consejo de Inversión de Capital (CIC).
En todos los casos, la CVR determina y documenta los resultados y la explicación del motivo de sus acciones. La CVR
revisa un proyecto y evalúa si:
• El proyecto se alinea completamente con la EA
• El proyecto es necesario no se alinea con la EA y un curso alternativo de acción
• El proyecto no se alinea con la EA y una renuncia es aprobada. El TRC aprueba una renuncia sólo si los
efectos de la falta de alineación se entienden y aceptable. Con la aprobación de una renuncia, la CVR transmite a la
CIC que no se opone al proyecto propuesto.
3.2.2. Establecer un Consejo de Inversiones de Capital
El jefe de la agencia establece un CIC para lograr la toma de decisiones informada con respecto a los costos, beneficios, riesgos de opciones
alternativas de inversión y la alineación arquitectónica. El objetivo de la CIC es asegurar proyectos empresariales y la arquitectura de
aplicaciones son factibles desde el punto de vista de costes y beneficios. Los CIC comentarios proponen inversiones en TI y toma la decisión
final de financiación de inversiones. Se acepta propuestas de programas y proyectos que han sido evaluadas por la CVR y determina si estos
programas / proyectos encajan dentro de los objetivos presupuestarios y la financiación general de la empresa. Mientras que un proyecto puede
ser técnicamente alineado con la EA, el CIC puede rechazar la financiación de un proyecto debido a otras limitaciones externas o por razones
presupuestarias. CIC decisiones pueden requerir actualizaciones al plan de secuenciación.
3.2.3. Establecer un Comité de Dirección Ejecutiva de EA
El jefe de la agencia establece un Comité de Dirección Ejecutiva de EA para dirigir, supervisar y aprobar el programa de
EA y EA. El EAESC es responsable de la aprobación de la EA inicial, la aprobación de cambios significativos en la EA, y
se aprueba el Plan Programa de EA.
El EAESC debe ser cargada formalmente, con una silla designada o co-presidentes, y facultado para garantizar una dirección estratégica
para todo el Organismo, la supervisión y la autoridad de toma de decisiones para la EA. La carta de EAESC debe autorizar la silla o
co-presidentes de nombrar los miembros. Por la carta, el número de miembros EAESC debe consistir en participantes activos que
representan e incluyen todas las principales áreas de negocio Agencia y la tecnología. Para llevar a cabo eficazmente como un órgano de
toma de decisiones, es crucial que los miembros EAESC son líderes de alto nivel, con la autoridad para comprometer recursos y hacer y
hacer cumplir las decisiones dentro de sus respectivas organizaciones.
3.2.4. Nombrará Jefe Arquitecto
El CIO debe nombrar, con la aprobación del Jefe ?? s Agencia, un ejecutivo de la Agencia para servir como arquitecto jefe y
administrador de programas de EA. El arquitecto jefe es responsable de dirigir el desarrollo de los productos de trabajo y soporte
de entornos de EA. El arquitecto jefe sirve como la tecnología y la empresa líder de la organización de desarrollo, asegurando la
integridad de la
14
procesos de desarrollo de la arquitectura y el contenido de los productos de EA. El arquitecto jefe debe ser amigo y enlace con las unidades de
línea de negocio y garantizar que los procesos de unidad de negocio se hace hincapié en la EA. Del mismo modo, el arquitecto jefe es
responsable de asegurar que la EA proporciona la mejor información y orientación posible a los proyectos de TI y las partes interesadas, y que
los esfuerzos de desarrollo de los sistemas están correctamente alineados con los requisitos de las unidades de negocio.
En el papel de administrador de programas de EA, el arquitecto jefe tiene la responsabilidad de gestionar el programa de EA, con la
autoridad, responsabilidad y rendición de cuentas por el esfuerzo arquitectónico global. El Administrador de Programas es responsable
de la planificación, el personal y el éxito final del programa, incluyendo la adquisición de mantener la financiación, los horarios de
negociación, la entrega oportuna y precisa de los productos de EA, y el establecimiento de un entorno de apoyo adecuado que asegure
la correcta aplicación de estos bienes.
Las competencias básicas del Arquitecto Jefe incluyen experiencia en planificación estratégica y técnica, desarrollo de políticas, la
planificación y control de la inversión de capital, gestión del cambio, la ingeniería de sistemas y el diseño arquitectónico, la
reingeniería de procesos de negocio y gestión de programas a gran escala. Además, el jefe de arquitectura se vuelve completamente
familiarizados con los negocios de la Agencia ?? s y los entornos de TI. A medida que el líder técnico principal de este esfuerzo, el
arquitecto jefe debe ser un buen comunicador que puede salvar las diferencias culturales que existen a menudo entre las
organizaciones empresariales y sistemas, y facilitar la interacción y la cooperación entre estas dos culturas.
3.2.5. Establecer una Oficina de Gestión de Programas de Arquitectura Empresarial
El esfuerzo EA debe ser tratado como un programa formal con patrocinio completo a través del proceso de CPIC de la Agencia. Una
Oficina de Gestión de Programas de EA debe ser establecido para administrar, supervisar y controlar el desarrollo y mantenimiento de
la EA. El personal EAPMO incluye arquitectos experimentados. Los EAPMO identifica y realiza análisis de costos de los enfoques
alternativos para el desarrollo de la EA, y gestiona en la casa o en el exterior contratista EA trabajo de desarrollo. El EAPMO también
se encarga de determinar los recursos necesarios y la obtención de compromisos de financiación y recursos.
Un objetivo principal de la EAPMO y la EAESC es para asegurar el éxito del programa de EA. Cada fase del programa (es decir, el
desarrollo de EA, uso y mantenimiento) está sujeto a las políticas y procedimientos de la CIC para las decisiones de inversión.
3.2.5.1. Designación de personal clave
El CIO debe hacer la EA una responsabilidad explícita para aquellos individuos designados como la organización ?? s evaluadores,
Gerente de Riesgos, y el Administrador de configuración. El gestor de riesgos identifica, monitores, controles, y mitiga los riesgos del
programa de EA a la luz de los factores ambientales (por ejemplo, restricciones de trabajo, externos, y las limitaciones técnicas). El
Administrador de configuración asume la responsabilidad de gestión de la configuración de los productos de EA de la misma manera que
se impone la gestión de configuración en cualquier otra línea de base de la ingeniería.
El CIO debe establecer una organización independiente de control de calidad para llevar a cabo la evaluación de la EA. Este equipo debe informar
a la EAESC y asegurar que todo el programa establecido y se cumplan las normas y procesos del proyecto. Las fuentes potenciales de revisión se
incluyen los grupos externos de referencia, las entidades externas imparciales o no involucrados, o mediante la contratación de un tercero neutral
especializada en evaluaciones o validaciones. Dentro del gobierno federal, agencias pueden solicitar su Inspectores Generales de
15
realizar una revisión IV y V o contratar los servicios de una entidad sin ánimo de lucro, tales como fondos federales del Centro de
Investigación y Desarrollo (FFRDC).
3.2.5.2. Establecer equipo de arquitectura de la empresa Core
Al mismo tiempo, el director del organismo y lograr la propiedad CIO línea de negocio del esfuerzo, un equipo básico de expertos en TI,
especialistas de línea de negocio, y los técnicos deberían ser asignados para desarrollar el proceso y los procedimientos deseada
utilizado en todo el esfuerzo de desarrollo. Los participantes deben tener una comprensión del negocio actual y entorno técnico y los
objetivos de negocio estratégicos previstos en la EA. El equipo está formado por el arquitecto jefe; negocio, sistemas, datos,
infraestructura y sistemas de seguridad de alto nivel arquitectos. Este equipo debe estar bien conectado a tierra en el entorno existente y
preparado para documentar y desarrollar la EA que apoyará a las necesidades empresariales en evolución.
El equipo central de la arquitectura de TI debe incluir representantes de las aplicaciones de la Agencia, los datos y las organizaciones de
infraestructura. Los grupos de trabajo en equipo básicos específicos deben incluir los analistas de negocio, analistas de datos, los diseñadores de
sistemas, especialistas en seguridad y programadores de sistemas. A medida que el programa se pone en marcha, más recursos / los miembros
del equipo se añaden típicamente al equipo central arquitectura. El equipo central de estructura deberá contener los directores de programas con
dominio en el manejo de programas para toda la Agencia, así como iniciativas interinstitucionales.
El equipo central de EA es responsable de todas las actividades relacionadas con el desarrollo, implementación,
mantenimiento y gestión de la arquitectura. Esto incluye:
• El desarrollo de EA procesos, procedimientos y normas
• El desarrollo de arquitecturas de referencia y objetivos
• Desarrollar y mantener un repositorio de EA
• Realización de aseguramiento de la calidad, gestión de riesgos y gestión de la configuración
• Guiar el desarrollo de sistemas y los esfuerzos de adquisición
• La definición de medidas de rendimiento de EA.
La Tabla 1 proporciona un listado de los roles funcionales y las responsabilidades asociadas asignados a miembros del equipo central de EA. En
organismos más pequeños, algunos de estos roles y responsabilidades pueden ser compartidos, se dobló, o subcontratarse.
16
de de febrero de de 2001
Tabla 1. Funciones y responsabilidades EAPMO
Papel Responsabilidades
Las cabezas de los EAPMO, organiza y gestiona el equipo central de EA; dirige el desarrollo de
Arquitecto en jefe
la arquitectura de referencia y objetivo.
Proporciona estrategia de la arquitectura y la consulta de planificación al Arquitecto Jefe.

Consultor de Arquitectura de alto nivel
Los análisis y los procesos de documentos comerciales, escenarios, y el flujo de información.

Arquitecto de negocios
Análisis y documentación de sistemas, interfaces internas y externas, control y flujo de datos.

Arquitecto de aplicaciones
Los análisis y las relaciones de información de documentos de negocio (lógica y física) y

Arquitecto de información
asociados.
Analiza y entornos de sistemas documentos, incluyendo las comunicaciones de red, nodos, sistemas
Arquitecto de infraestructura operativos, aplicaciones, servidores de aplicaciones web y servidores de portal y middleware.
Supervisa, coordina y documenta los aspectos de seguridad de la EA, incluyendo el diseño,

Arquitecto de Sistemas de Seguridad operaciones, el cifrado, la vulnerabilidad, el acceso y el uso de procesos de autenticación.
Asegura que las políticas, guías y otros documentos dentro del repositorio de EA son claros,
Escritor técnico concisos, utilizable, y se ajustan a las normas de gestión de configuración.
Garantiza el cumplimiento de todos los estándares de programas y proyectos, procesos y prácticas establecidas.
Seguro de calidad
Identifica, monitores y controles de riesgos a la luz de los factores ambientales y las limitaciones.
Gestión de riesgos
Asegura que se identifican todos los cambios, seguimiento, supervisar y debidamente documentados.
control de configuración
3.3. Arquitectura Empresarial Programa de Actividades y Productos
3.3.1. Desarrollar un Plan de Estrategia y Comunicaciones de Marketing de EA
El propósito del plan de estrategia de marketing y comunicaciones es (1) para mantener los altos ejecutivos y unidades de negocio
continuamente informados, y (2) para difundir información a los equipos de gestión de EA. El personal del CIO ?? s, en
colaboración con el Arquitecto Jefe y personal de apoyo, define un plan de marketing y comunicación que consiste en (a) las
circunscripciones, (b) el nivel de detalle, (c) los medios de comunicación, (d) la retroalimentación del participante, (e) cronograma
de los esfuerzos de marketing, y (f) método de evaluación del progreso y aceptación. Es el CIO ?? s función de interpretar la visión
del Jefe ?? s Agencia y para reconocer las ideas innovadoras (por ejemplo, la creación de un gobierno digital) que puede
convertirse en factores clave dentro de la estrategia y plan de EA. Si los recursos lo permiten, el arquitecto jefe debe utilizar una o
todas de las siguientes herramientas para comunicarse con la comunidad de intereses:
Uno de los medios recomendados para la comercialización de la EA es una imprimación para informar a los ejecutivos y los grupos de interés
de la estrategia y el plan de negocio de las agencias de EA. La imprimación se puede utilizar para expresar la visión del Jefe ?? s Agencia para
la empresa y el papel de la EA en el cumplimiento de esa visión ?? por ejemplo, la creación de la base integrada para el gobierno en línea o los
procesos de negocio de racionalización y la tecnología.
17
La imprimación debe describir los principios de la EA y sus muchos beneficios como un agente de cambio en el logro de objetivos de la
organización (por ejemplo, servicios de negocios y la integración de las iniciativas) o como un recurso crítico para evaluar las opciones de
cambio como las necesidades de negocio y de tecnología evolucionan. La imprimación debe describir claramente las funciones y
responsabilidades de los altos ejecutivos y sus unidades organizativas en el desarrollo, implementación y mantenimiento de la EA. Es
importante que la imprimación incluyen secciones personalizadas que se relacionan directamente con un público específico de línea de negocio.
La imprimación debe demostrar los beneficios de un EA para las partes interesadas de la Agencia. Esto es particularmente importante ya que
muchos de los grupos de interés pueden ser necesarios para proporcionar los recursos especializados, apoyo y tiempo para el esfuerzo. Una
vez completada, la imprimación debe ser ampliamente distribuida en la Agencia y estará disponible en la página web de la Agencia. Debe ser
informado a todo el personal afectados por la introducción de la EA. materiales introductorios extraídas de la imprimación deben ser
incorporados en los programas de formación locales y todo el Organismo.
3.3.2. Desarrollar un Plan de Gestión de Programas de EA
Se desea un plan formal para la gestión de programas de sonido. El EAPMO crea un plan de gestión de los programas de EA (PMP) que
incluye una hoja de ruta para lograr las metas establecidas por el EAESC y planes de implementación para alcanzar dichos objetivos. El
plan debe incluir metas para el arquitecto jefe en el establecimiento de objetivos de arquitectura de todo el Organismo. Estos objetivos
deben ayudar al equipo de arquitectura de establecer y mantener arquitecturas de niveles inferiores que cumplan con la EA.
El PMP delinea planes y un conjunto de acciones a desarrollar, utilizar y mantener la EA, incluida la gestión de EA, control y
supervisión. Para facilitar el seguimiento de los procedimientos de costos, el cronograma y el rendimiento de datos, supervisión y
control debe ser desarrollado, documentado e implementado dentro del PMP. El PMP también debe incluir:
• Requisitos para el Administrador de programas de EA para identificar todas las necesidades de financiación, el gasto de
cronogramas / horarios y enlaces a las medidas de desempeño
• Una estructura de desglose del trabajo (EDT) que detalla las tareas y sub-tareas necesarias para adquirir,
desarrollar y mantener la arquitectura
• estimaciones de recursos para la financiación, la dotación de personal, la capacitación, los requisitos de espacio de
trabajo y las necesidades de equipo
• Plan de trabajo para la iniciación de los planes del proyecto
• Requisitos para la realización de la garantía de calidad, la gestión de riesgos, la gestión de la configuración y la

gestión de la seguridad
• Requisitos para el establecimiento y mantenimiento de un depósito de información EA.
3.3.3. Iniciar el desarrollo de la arquitectura de la empresa
Una vez que el EAPMO está en su lugar y el PMP se produce, el primero de los proyectos de arquitectura se pone en marcha. Hay
varias actividades periféricos asociados con el inicio de esta actividad. El proyecto inicial EAPMO ?? s hará lo siguiente:
• prácticas Instituto PMP
• Establecer procesos de desarrollo de EA y prácticas de gestión
• Capacitar a los participantes del proyecto de EA
• Construir productos de referencia EA
• Construir objetivo los productos de EA (posible)
18
• Crear el plan de secuenciación
• Poblar el repositorio de EA.
Las secciones 4 y 5 proporcionan las discusiones sobre los detalles del desarrollo de la EA.
19
20
4. Definir un proceso de Arquitectura y Enfoque
El siguiente paso en el proceso de EA es el establecimiento de un

proceso de EA y el enfoque. La EA se utiliza como una herramienta
para facilitar y gestionar el cambio dentro de la organización
Agencia. El alcance y la naturaleza de la Agencia y los cambios a
Definir un proceso de
realizar dictará el alcance y la naturaleza de la arquitectura que se
Arquitectura y Enfoque
desarrollarán. Mientras que la EA es una excelente herramienta para
gestionar entornos grandes y complejas, la profundidad y el detalle
de la EA debe ser adaptado a la empresa individual. Figura 5 ilustra
cómo la profundidad y el detalle en la EA varía no sólo con el
tamaño y complejidad de la empresa,
sino también los muchos tipos de riesgos asociados con el cambio. En cualquier caso, el alcance de la arquitectura de la empresa para
los puntos de vista estratégicos planificador y propietario de la empresa (según se define en el marco de la arquitectura seleccionada)
debe abarcar toda la empresa. La agencia va a entender las relaciones y dependencias entre sus líneas de negocio y así posicionarse
para tomar decisiones informadas sobre cómo abordar la definición de la profundidad y el detalle de EA para estas líneas de negocio. La
primera actividad en este proceso es determinar el uso previsto de la arquitectura. Se maneja el resto del proceso de desarrollo de EA.
Las actividades posteriores describen cómo alcance, caracterizar, seleccionar los productos de EA, construir y utilizar la EA.
Metas:
De hecho, antes el desarrollo de la EA, la Agencia necesita para evaluar y
?? Construir una arquitectura de referencia que
seleccionar un marco arquitectónico como guía. Esta sección describe varios representa la realidad
marcos candidatos que actualmente se utilizan dentro de la comunidad ?? Construir una arquitectura objetivo que
Federal. La selección de un marco depende de la finalidad de la EA y los representa la visión de negocio y estrategias de TI
productos a desarrollar. Además, se deben emplear un conjunto de
herramientas o un repositorio para el desarrollo y el uso de EA. La ?? Desarrollar un plan de secuencia que
herramienta elegida debe ser proporcional a los productos que se generen. describe una estrategia gradual para la transición
de la línea de base a la meta
?? Publicar un EA aprobado y plan de secuencia que son
accesibles por los empleados de la agencia
tamaño
Profundidad y detalle
Complejidad
Riesgo
Figura 5. La profundidad y el detalle de la arquitectura
21
Una guía práctica para Federal Enterprise Architecture Definir un proceso de Arquitectura y Enfoque
4.1. Definir el uso previsto de la Arquitectura
Arquitecturas deben ser construidas con un propósito específico en mente. Podría ser la reingeniería de procesos de
negocio, la adquisición de sistemas, sistema de los sistemas de migración o integración, formación de usuarios,
evaluación de la interoperabilidad, o cualquier otra intención. El propósito de la arquitectura está estrechamente ligado
al Plan de la organización ?? s Estratégica (s), una legislación como LCRG y Clinger-Cohen, y el apoyo del proceso
de inversión de capital. Antes de un arquitecto comienza a describir una arquitectura, la organización determina los
cambios en la arquitectura está destinada a facilitar, el tema (s) de la arquitectura está destinado a explorar, las
preguntas se espera que la arquitectura para ayudar a responder, y los intereses y perspectivas de la audiencia y
usuarios. Una consideración práctica importante es la determinación de los tipos de análisis que se van a realizar; es
decir,
El propósito de la EA puede, y es probable que, evolucionar con el tiempo para cumplir con los nuevos requisitos. El arquitecto
jefe debe asegurarse de que cualquier evolución EA, de hecho, cumple con los requisitos recién determinados. Esto aumentará la
eficiencia del desarrollo de la arquitectura y crear un mayor equilibrio en la arquitectura resultante.
4.2. Definir el alcance de la Arquitectura
Es de vital importancia que el desarrollo de EA se planteaba de un de arriba hacia abajo, de manera gradual, en consonancia
con las vistas arquitectónicas jerárquicos que son los bloques de construcción de marcos EA probados, incluyendo los
discutidos más adelante en esta guía. De este modo, es igualmente importante que el alcance de los puntos de vista de
negocio de nivel superior de la EA abarcan toda la empresa o agencia. Mediante el desarrollo de esta comprensión de toda la
empresa de procesos y reglas de negocio y las necesidades de información, flujos, y las ubicaciones, la agencia estará en
condiciones de tomar buenas decisiones acerca de si la empresa, y por lo tanto la EA, pueden ser apropiadamente
compartimentada. Sin hacerlo, las decisiones de alcance de la EA correr el riesgo de promover ?? estufa de hilo ??
operaciones y entornos de sistemas, y en última instancia, el rendimiento de la empresa sub-optimización y rendición de
cuentas.
• Pertinencia de las actividades, funciones, organizaciones, plazos, etc.
• ámbito empresarial (dominios intra e inter-agencias)
• escenarios operacionales, situaciones y áreas geográficas que han de considerarse
• beneficios económicos proyectados
• negocio proyectado y áreas de riesgo técnicos
• disponibilidad y capacidades de las tecnologías específicas durante el plazo meta proyectada (se aplica para apuntar
arquitectura única).
Definir el alcance conduce a los planificadores de los factores de manejo que contribuyan a estas determinaciones, incluyendo los recursos
disponibles para la construcción de la arquitectura, así como los recursos y el nivel de conocimientos técnicos disponibles para las tareas de
análisis y diseño del proyecto.
4.3. Determinar la profundidad de la Arquitectura
Se debe tener cuidado para juzgar el nivel de detalle adecuado para ser capturado en base al uso previsto y el alcance de la
EA y las decisiones ejecutivas se hagan con la EA. Es importante que un nivel constante e igual de profundidad puede
completar en cada vista y perspectiva. Si se omiten las características pertinentes, la arquitectura no puede ser útil. Si las
características son innecesarios
22
se incluye, el esfuerzo de la arquitectura puede resultar inviable dado el tiempo y los recursos disponibles, o la arquitectura puede ser
confuso y / o lleno de detalles que son superfluos. características de EA están influenciados por el enfoque: si la captura principalmente
la línea de base frente a la diana y viceversa. Es igualmente importante para predecir los futuros usos de la arquitectura de modo que,
dentro de las limitaciones de recursos, la arquitectura puede ser estructurada para acomodar sastrería futuro, la extensión o la
reutilización. La profundidad y el detalle de la EA debe ser suficiente para su propósito.
4.4. Seleccionar los productos adecuados EA
productos esenciales son los requeridos para todas las arquitecturas, mientras que el apoyo a los productos mayo que sea necesario para
cumplir con las necesidades de información específicas. Sólo aquellos productos de apoyo que retratan las características deseadas
deben construirse. Los productos requeridos deben ayudar a formular la selección de un marco productos esenciales
y un conjunto ?? los asociado.
de herramientas gráficos,
modelos, y / o narrativas que cada descripción
de la arquitectura debe incluir, para apoyar el
alcance y características de la EA.
Es esencial que el director de arquitectura de guiar la construcción del contenido

apoyo a los productos ?? los gráficos, modelos, y / o
técnico para satisfacer las necesidades de la EA, especialmente en el nivel deseado de
narrativas que puedan ser necesarios para explicar con
detalle necesario en los productos de trabajo. Si el contenido está en un nivel más detalle los productos esenciales o para abordar
demasiado alto de abstracción, puede que no sea lo suficientemente útil para orientar particulares extensiones de dominio o campo de
los proyectos y las revisiones. Si el contenido es demasiado detallada, puede ser difícil aplicación (por ejemplo, en tiempo real o consideraciones
de manejar. especiales de rendimiento).
4.4.1. Seleccione los productos que representan el negocio de la
Empresa
Como primer paso en la identificación y la creación de la definición del negocio, el

arquitecto jefe determina qué productos se pueden utilizar para proporcionar una ¿¿Modelo?? representaciones de la realidad: la
visión integrada de la actividad principal Agencia. Estos incluyen funcional, de información, actividades, relaciones y
información, los modelos de organización y. modelos funcionales o de proceso restricciones.
pueden estar representados en varias formas, incluyendo:
• Casos de uso
• Modelos de actividad / Árboles
• IDEF [Integrated Computer Aided Manufacturing ( yo LEVA) Def inition] modelos de procesos de
negocio
• Concepto de Operaciones (CONOPS)
• Modelos de estado.
modelos de información incluyen los modelos de clase y modelos de datos conceptuales. las combinaciones adecuadas de estos
modelos deben ser utilizados para representar participantes internos y externos de organización, actividades, entradas, salidas, flujo
de información, secuenciación, interrelaciones entre los datos y las interfaces externas. Los modelos abarcan la empresa y
representan la empresa a nivel estratégico. información y ejemplos de estos modelos adicionales se proporcionan en el Apéndice D.
La definición del negocio debe ser creado en las arquitecturas de referencia y objetivos y el plan de secuenciación. En la arquitectura de la
línea de base, que representa el estado actual de las operaciones comerciales y el intercambio de información dentro y fuera de la
organización. En el plan de secuencia, se
23
representa los cambios del negocio y mapas de los sistemas de planificación y mejoras en el negocio. En la arquitectura objetivo, que
representa las operaciones comerciales planificadas como se expresa en las estrategias de negocio y visiones.
4.4.2. Seleccione los productos que representan Agencia activos técnicos
El contenido técnico de la EA representa el patrimonio técnico de la Agencia. Se compone de los diseños físicos y lógicos de
las arquitecturas de referencia y objetivos. Como mínimo, este contenido incluye diseños de datos, aplicaciones e
infraestructura (incluyendo hardware, software y comunicaciones). Estos productos se identifican las necesidades de
información, aplicaciones de software / programas, middleware y la infraestructura física subyacente apoyar el entorno actual y
necesaria para apoyar el Concepto de Operaciones (CONOPS) para la empresa en su estado de destino.
EA productos creados para apoyar el contenido empresarial a menudo se extienden a representar el espacio de soluciones. Por lo tanto, muchos
de los modelos podrían ser reutilizados, extendida, y se hace referencia con el fin de definir la arquitectura técnica. El propósito de la arquitectura
técnica es asegurar que un sistema conforme satisface un conjunto específico de las necesidades y requerimientos del negocio. Proporciona las
directrices para la aplicación de sistemas técnicos para la creación de especificaciones de ingeniería y desarrollo de productos.
4.5. Evaluar y seleccionar un Marco
A medida que cada Agencia Federal embarca en esta etapa del proceso de la
Marco de referencia ?? una estructura lógica para la
arquitectura, se debe seleccionar un marco arquitectónico apropiado. Una serie de
clasificación y organización de la información
marcos bien establecidos se utilizan con éxito en todo el sector federal.
compleja.
Alternativamente, una agencia puede optar por desarrollar su propio marco,
aunque los costos, beneficios y riesgos de hacer lo que deben sopesarse frente a los riesgos de adoptar o adaptar un marco
existente. Mientras que las agencias federales varían ampliamente en su enfoque de desarrollo de la arquitectura e
implementación, los marcos establecidos permiten comparaciones y análisis en todas las agencias. Por lo tanto, se recomienda
que antes de una Agencia desarrolla un nuevo marco (si una agencia tiene un marco ordenado, debe ser empleada), se debe
investigar el uso de otros marcos desarrollados por el gobierno federal existentes.
Tres patrocinio federal (y comúnmente aceptada) marcos arquitectónicos se utilizan como marcos candidatos y con fines
descriptivos dentro de esta guía EA. Estos contienen productos de primera necesidad y de apoyo, y promover el
desarrollo de arquitecturas que son completa y comprensible, e integrable. Las organizaciones que se desarrollaron estos
marcos siguen adaptarlos para asegurar preceptos paralelas, principios y metodologías. Los marcos son:
• Marco de Arquitectura Empresarial Federal (FEAF)
• Departamento de Defensa (DoD) Comando, Control, Comunicaciones, Informática, Inteligencia,

Vigilancia y Reconocimiento (C4ISR) Marco de Arquitectura
• Tesoro Arquitectura Empresarial Marco (TEAF).
existen otros marcos de EA y se han utilizado en los programas de gobierno (por ejemplo, el Departamento de Agricultura
marco ?? s y el Instituto Nacional de Estándares y Tecnología [NIST] marco). Esta guía no aborda estos otros marcos
porque la mayoría de las organizaciones han estandarizado el FEAF, C4ISR, y TEAF para el desarrollo de EA. Además de
los marcos de EA, existen muchos procesos que pueden ser utilizados para apoyar el desarrollo marco, tal como
24
el Departamento de Energía ?? s sistemas de información corporativa arquitectura de hoja de ruta para la implementación de sistemas de
TI. Desde un proceso nocional se describe en esta guía, no se discuten otros procesos Agencia Federal de EA.
El uso de un marco EA asegura la uniformidad y la normalización al migrar y la integración de sistemas de información. El marco
seleccionado dependerá en el uso, el alcance y características deseadas de la arquitectura que ser desarrollado. La tabla 2 enumera
los factores más importantes a tener en cuenta.
Tabla 2. Criterios de selección Framework
áreas factores
• dirección reguladora y legislativa
Política • política de la agencia
• La compatibilidad necesaria con otro Organismo o política conjunta
• Contexto de la empresa ?? por ejemplo, subordinada a una empresa más grande, estrechamente relacionada con
otra empresa
Empresa • La experiencia con un marco particular,
• Mandatos y los conductores ?? por ejemplo, en comparación con énfasis en negocios de infraestructura u operativo contra
los problemas técnicos
• Prioridades, usos previstos y nivel de detalle deseado ?? por ejemplo, la modernización a gran
escala frente a entorno de TI estable
productos de EA
• Recursos y programar las restricciones sobre los esfuerzos de modelado
• La disponibilidad de productos de arquitectura existentes
Marcos incluyen conceptos que impulsan están creando los tipos de productos de arquitectura. Los productos, tanto
gráficos y textuales, capturan la información prescrita por el marco. productos equivalentes pueden ser sustituidas si el
nuevo producto tiene atributos similares o más amplias que el producto original. Esto se hace a menudo cuando los
métodos específicos (por ejemplo, de análisis y diseño a objetos) se prestan a técnicas de modelado particulares.
El uso de los marcos FEAF, C4ISR, o TEAF debe reducir sustancialmente el

Método ?? una manera prescrita de abordar un
proceso de desarrollo y acortará el tiempo para obtener un EA en su lugar y poner
problema en particular.
una Agencia en un camino para el éxito. Las secciones siguientes proporcionan
una breve descripción de los marcos FEAF, C4ISR, y TEAF.
4.5.1. Marco de Arquitectura Empresarial Federal
En septiembre de 1999, el Consejo Federal CIO publicó el Marco de Arquitectura Empresarial Federal, versión 1.1 para el desarrollo de
un EA dentro de cualquier agencia federal o por un sistema que trasciende múltiples límites entre organismos. Se basa en prácticas
comerciales comunes y diseños que cruzan las fronteras organizacionales. El FEAF proporciona un estándar duradero para el
desarrollo y la documentación de las descripciones de la arquitectura de áreas de alta prioridad. Proporciona una guía en la descripción
de arquitecturas para los segmentos funcionales múltiples organizaciones del Gobierno Federal. Estos segmentos arquitectónicos
federales constituyen colectivamente la EA Federal. Actualmente, la FAWG patrocina el desarrollo de productos de EA para el comercio
y conceder segmentos Federal de arquitectura.
25
Como se muestra en la Figura 6, la FEAF particiona una arquitectura dada en las arquitecturas de negocio, datos, aplicaciones, y
la tecnología. El FEAF actualmente incluye las tres primeras columnas del marco Zachman y la metodología de planificación
Spewak EA (véase el Apéndice G).
Figura 6. Estructura de los Componentes FEAF
Para la Empresa Federal, el Consejo Federal CIO busca desarrollar, mantener y facilitar la aplicación de un EA de nivel superior
predicada sobre la FEAF. Esta arquitectura sirve como punto de referencia para facilitar la coordinación eficiente y eficaz de los
procesos de negocio común, inserción de tecnología, flujos de información, los sistemas y las inversiones entre las agencias
federales. El FEAF proporciona una estructura para desarrollar, mantener e implementar entornos operativos de alto nivel y
apoyar la implementación de sistemas de TI. Como se muestra en la Figura 7, la FEAF se representa gráficamente como una
matriz 3x5 con tipos de arquitectura (datos, la aplicación, y tecnología) en un eje de la matriz, y perspectivas (Planner,
Propietario, Designer, Builder, y el subcontratista) en el otro . Los productos de EA correspondientes se enumeran dentro de las
células de la matriz.
Arquitectura Arquitectura de la Arquitectura

de datos aplicación tecnología
Perspectiva
Lista de Business Objects Procesos de Negocio Lista de ubicaciones de empresas
planificador
propietario
Modelo semántico Modelo de Procesos de Negocio Sistema de Logística de Negocios
Perspectiva
Perspectiva Geográfica arquitectura de

Logical Data Model Arquitectura de la aplicación Lista de
diseñador implementación del Sistema
constructor
Modelo de Datos Físico Diseño de sistemas Arquitectura tecnología
Perspectiva
subcontratista
Diccionario de datos programas Red de arquitectura
Perspectiva
Figura 7. FEAF Arquitectura Matrix
26
4.5.2. Marco DoD C4ISR Arquitectura
En diciembre de 1997, el Departamento de Defensa publicó su arquitectura marco C4ISR. Este marco se aplica a todas las ramas de
las fuerzas armadas e incluye los numerosos comandos principales y subordinados, las organizaciones de campo, y grupos de trabajo
dentro de cada servicio.
En el marco de arquitectura C4ISR, la vista operativa describe las tareas y actividades, elementos operativos y flujos de información
Needline ?? un requisito que es la
necesarios para llevar a cabo o para apoyar una operación. Se especifica la naturaleza del intercambio de información cada ??
expresión lógica de la necesidad de
needline s con suficiente detalle para determinar el grado deseado de interoperabilidad. los sistemas
transferir deentre
información visiónnodos.
identifica que los
sistemas de apoyo con el requisito. Se traduce el grado deseado de interoperabilidad en un conjunto de capacidades de sistema
necesarios, y compara las implementaciones actuales / postuladas con las capacidades necesarias. los vista técnico define los
criterios que rigen la ejecución de cada capacidad del sistema. Para ser coherente e integrada, una descripción de la arquitectura
debe proporcionar vínculos explícitos entre sus diferentes puntos de vista. La Figura 8 ilustra estos tres puntos de vista y sus
relaciones.
Operacional
Ver
Identifica Warfighter Relaciones y
Necesidades de Información
Pr uis
oc
re
es os d
q
In
am
fo
it
rm
de y
ie
o
nt
ac
nt
o
ie
ió
y
am
I
n
nt
ni
s
Te
to
es
er
ve bio
n
cn ati des
si
co
oc
ió
ca
le
i
qu
ac
ol
pr
s
m
es los
ca
o
Re
rm
de
p
de
gí idad
pa
fo
dl as a
a
de
es
ci
bi
In
de
y
bá
es
el
da
l
de
, N tem
si
v
al
ni
in
ca uev
o
od
bi
s
is
y
Lo
rn
de as
m
s
ee
n
te
e
rc
in
to tivid s d
te
es
In
e
on
ad
ci
ia
oc
c
,A
as
s
s
s
do
si
La
i
no
qu
Re
Las capacidades específicas detectados a
Ver unos niveles Satisfacer Técnico

InformationExchange y otros requisitos
sistemas operacionales Ver
Se relaciona capacidades y Normas prescribe
Características a las necesidades operacionales Los criterios técnicos que se rige y Convenciones
interoperable Implementación / Adquisición
de las capacidades del sistema
seleccionados
Figura 8. Marco de DoD C4ISR
La Figura 9 representa los productos de arquitectura esenciales y de apoyo C4ISR. Apéndice D proporciona ejemplos de productos
esenciales C4ISR.
27
todas Operacional sistemas Técnico

las Vistas Ver Ver Ver
Arquitectura
Información general y resumen
técnica
Información
Gráfico Descripción Perfil
Concepto de Operaciones
conectividad de alto nivel
Descripción nodo de
Diccionario
integrada
Matriz de
Intercambio de
Información
Systems
sistemas de Pronóstico
Relación de comandos
Comunicaciones estándares de
Gráfico
Descripción tecnología
Modelo actividad Los sistemas de matriz
Funcionalidad
Reglas de Operación
Descripción del
Modelo
sistema
Actividad operativa a la
Interface
Transición de estado
matriz de trazabilidad de
Descripción
función del sistema
Diagramas de sistemas de Información

seguimiento de eventos matriz de intercambio
Logical Data Model

la matriz Sistema
Evolución del Sistema

Descripción
pronóstico parámetros de
Rendimiento
Sistema de Transición
estadoReglas
sistemas del sistema
Tecnología modelo de
de eventos diagramas de
Sistemas de seguimiento
Datos físicos Modelo
Productos de trabajo esenciales Apoyando Productos de trabajo
Figura 9. DoD C4ISR Productos
4.5.3. Marco Tesoro Arquitectura Empresarial
En julio de 2000, el Departamento del Tesoro publicó el Tesoro Empresa Architecture Framework. El TEAF proporciona (1)
orientación a las oficinas de Hacienda en relación con el desarrollo y la evolución de la arquitectura de sistemas de
información; (2) un concepto unificador, principios comunes, tecnologías y estándares para los sistemas de información; y (3)
una plantilla para el desarrollo de la EA.
El TEAF describe un marco arquitectónico que soporta los procesos de negocio del Tesoro en términos de productos. Este
marco guía el desarrollo y rediseño de los procesos de negocio para varias oficinas con el fin de cumplir con los requisitos de
la legislación reciente en un entorno tecnológico que cambia rápidamente. El TEAF prescribe vistas arquitectónicas y delinea
un conjunto de productos nocionales para retratar estos puntos de vista. La Figura 10 ilustra el marco TEAF.
28
¿Cómo, dónde y cuándo
Funcional
Qué, cuánto, y
Con que frecuencia Información
Quien y porque
Organizativo
habilitador Infraestructura
Figura 10. El Marco Tesoro Arquitectura Empresarial
El TEAF ?? s funcionales, de información y de organización vistas Arquitectura Modelo colectivamente la organización ?? s procesos,
procedimientos, y las operaciones comerciales. Por la conexión a tierra de la arquitectura en el negocio de la organización, el TEAF define
los procedimientos de negocio principales y procesos empresariales. A través de sus modelos explícitos, una arquitectura basada en TEAF
permite la identificación y el razonamiento de las preocupaciones a nivel de sistema y Empresa- y decisiones de inversión.
El TEAF ofrece un concepto unificador, terminología común y los principios, normas y formatos comunes, un contexto normalizado para la
planificación estratégica y la formulación del presupuesto, y un enfoque universal para la resolución de cuestiones de política y de
gestión. En él se describe la empresa de arquitectura de sistemas de información y sus componentes, incluyendo la arquitectura ?? s
propósito, beneficios, características y estructura. El TEAF presenta varios puntos de vista arquitectónico y delinea varias técnicas de
modelado. Cada vista es apoyado con los gráficos, repositorios de datos, matrices, o informes (es decir, productos de arquitectura). La
Figura 11 muestra una matriz con cuatro puntos de vista y cuatro perspectivas. productos esenciales se muestran a través de las dos
primeras filas de la matriz. Es notable que el TEAF incluye un modelo de aseguramiento de la información Trust, el Modelo de Referencia
Técnica, y los perfiles estándares que los productos de trabajo esenciales. Estos no suelen ser abordados como componentes
estructurales críticos.
29
Funcional Información Organizativo Infraestructura

Ver Ver Ver Ver
Referencia
tecnica
Perspectiva Misión Visión Diccionario Organización EA Repositorio
Normas Modelo
planificador declaraciones información gráficos listados
de perfil
Modelo Interfaz de Sistema de

actividad Matriz de información Conectividad nodo
propietario Evaluación de Riesgo de Modelado de
de Exchange Descripción
Perspectiva Aseguramiento de Información Alto Nivel
Información del Modelo de (conceptual) (Conceptual)
Descripción
Aseguramiento de Confianza
(Nivel 1)
Procesos de Negocio / Matriz de Intercambio

Función Sistema de Información
Matriz (Lógico) Conectividad nodo System Interface
Perspectiva Modelado
Descripción Descripción
diseñador Diagramas de lógico
Model (Lógico) (Nivel 2 y 3)
seguimiento de eventos
Gráficos del estado físicos CRUD Matrices
System Interface
Matriz de Intercambio
Funcionalidad Conectividad nodo Descripción (Nivel 4)
constructor de Información Modelado
Descripción del (Física) Logical Data Descripción Sistema Rendimiento
Perspectiva físico
sistema (física) parámetros de la matriz
Los datos del modelo de datos
Productos de trabajo esenciales Apoyando Productos de trabajo
Figura 11. TEAF Productos
Uno de estos marcos debe proporcionar un medio para estructurar y organizar los productos de EA seleccionados lógicamente. Ahora, con el fin
de crear y mantener con eficacia los productos de EA, un conjunto de herramientas debe ser seleccionado.
4.6. Seleccionar un conjunto de herramientas de EA
Para aumentar la utilidad de cualquier arquitectura, es importante mantener la EA dentro de una herramienta interactiva de arquitectura.
Afortunadamente, hay muchas herramientas de arquitectura automatizados disponibles en el mercado hoy en día. La elección de la herramienta
se basarán en la organización necesidades ?? s en función del tamaño y la complejidad de su arquitectura. El arquitecto y la arquitectura del
equipo Jefe núcleo puede utilizar la suite de herramientas de oficina (por ejemplo, PowerPoint y Word Microsoft ?? s) y / o herramientas de
modelado (por ejemplo, Rational Rose por la Corporación racional, Arquitecto de Sistemas por Popkin, o por Marco Ptech).
Hay conjuntos de herramientas disponibles de proveedores líderes que pueden proporcionar la alineación con el marco elegido y productos
recomendados. criterios de la herramienta deben determinarse basándose en el uso previsto de la arquitectura, el alcance, niveles de integración
deseado y otros factores. Tabla 3 temas listas de candidatos para ayudar en la selección de herramientas. La lista se puede adaptar a un conjunto
específico de requisitos para la selección de herramientas. Una herramienta probablemente no va a cumplir con todos los requisitos. Por lo tanto,
se necesitarán una suite de herramientas o combinación de herramientas. Los productos de trabajo deben mantenerse en varios tipos diferentes de
medios tales como documentación en papel (reuniones de información e informes), archivos electrónicos en CD-ROM, documentos HTML en la
web y otros de Ingeniería de Software (CASE) y de desarrollo de herramientas asistidas por EA ordenador que proporcionar un sistema de gestión
de base de datos relacional.
30
Tabla 3. Criterios de selección de herramientas
área funcional criterios
• plataformas disponibles
• Soporte para marco elegido
• Soporte para métodos de modelado y técnicas ?? por ejemplo, análisis orientado a objetos
y diseño, IDEF, modelos de actividad, los modelos de clase, modelos de información
• Importar / Exportar capacidad
• Costo (inicial y de mantenimiento) y la concesión de licencias
• soporte del proveedor (por ejemplo, tiempo, costo)
• programa de entrenamiento, el costo, la duración
• Facilidad de uso
Desarrollo de productos de EA
• La integración de los productos generados ?? capacidad de integrar de referencia y objetivos
arquitecturas y productos de ingeniería de la empresa
• Capacidad, tamaño esperado, y la complejidad de los modelos
• Integrada y consolidada repositorio
• El soporte multi-usuario
• apoyo Meta-modelo (por ejemplo, capacidad de configurar y de modelo a medida elementos)
• ayuda RM / seguimiento de cuestiones
• apoyo CM
• soporte de control de calidad
• Capacidad de interoperar con otros productos de ingeniería de la empresa y las

herramientas de desarrollo / repositorios
• La trazabilidad de los requisitos y otros artefactos de ingeniería de la empresa
Mantenimiento de los productos de EA
• ayuda RM / seguimiento de cuestiones
• apoyo CM
• soporte de control de calidad
• Accesibilidad (por ejemplo, el software necesario, los requisitos de acceso)
• generación de documentación ?? sesiones de información e informes
La difusión de los productos de EA • Medios soportados (por ejemplo, CD-ROM, HTML)
• Los niveles de control de acceso (por ejemplo, de sólo lectura, lectura-escritura)
• El uso de enlaces de hipertexto
la estandarización de herramientas es una práctica recomendada. Esto demuestra rentable la hora de determinar la calidad de la arquitectura y
la alineación con la política de EA desde una perspectiva costo de adquisición y para la interoperabilidad consistente de los modelos.
31
32
5. Desarrollar la Arquitectura Empresarial
El siguiente paso es la construcción de los productos arquitectura basada

en el propósito de la arquitectura y el marco elegido. Este se compone de
los productos esenciales, productos de soporte (si es necesario), y
productos definidos individualmente (por ejemplo, tablas de información,
notas de la entrevista) impulsado por las necesidades y procesos
architecturespecific. Para facilitar la integración con otras arquitecturas, es
crucial para incluir todas las representaciones de las relaciones con los
componentes externos aplicables, es decir, las entidades fuera de la Desarrollar Base
agencia. Arquitectura Empresarial
Objetivo Desarrollar la
Arquitectura Empresarial
Puede ser útil, los recursos lo permiten, para llevar a cabo una prueba de principio de análisis en varias etapas del desarrollo de la
arquitectura. Por ejemplo, se podría realizar ejecuciones de prueba del proceso de desarrollo de EA utilizando subconjuntos cuidadosamente
seleccionados de las áreas a ser analizadas. El equipo central de la arquitectura debería garantizar que los productos son consistentes y bien
relacionados entre sí. Si los productos no se aplican y se rellenan de manera uniforme, el arquitecto y la arquitectura Jefe equipo central no
será capaz de comparar o contrastar los productos o realizar análisis exhaustivos.
Independientemente del alcance y la complejidad de las vistas a desarrollar, el equipo central de la arquitectura debe aplicar un enfoque
coherente para el desarrollo de las arquitecturas de referencia y objetivos. El enfoque seleccionado debe incluir (1) una fase de recogida
de datos, (2) la generación de productos preliminar, (3) etapas de examen y revisión, y (4) la publicación y la entrega de los productos de
arquitectura a un repositorio adecuado. La figura 12 muestra un proceso típico para el desarrollo de los productos de EA. Cada una de
estas actividades se describe con más detalle en las siguientes subsecciones.
Publicación y
Recopilación de datos Entrega
Literatura
Generar
y
Revisión y modificación informativa
Documentación
revisión Generación del y Presente
Mantenga
producto ideas en grupo
preliminar
sesiones
Independiente
Generar Revisar Publicar
de reuniones preliminares y SME
productos productos Arquitectura
y revisión y
preliminares con el fin Productos
Entrevistas validación
Conducta
entrenamiento entrevistas en
profundidad
individuales Poblar
Herramientas y
Familiarización
Repositorios
El
Figura 12. Ejemplo Enfoque para el Desarrollo EA
33
02 2001
5.1. recopilar información
El primer paso en el método de construcción es de identificar y recoger los productos existentes que describen la empresa, tal como existe hoy y
como se pretende mirar y operar en el futuro. La recolección de datos es el esfuerzo fundamental, inicial que implica la revisión de documentos,
puesta en escena de las sesiones de entrenamiento, y entrevistar a las PYME y los propietarios de dominios.
Toda la información y productos recogidos apropiada deben ser

Repositorio ?? un sistema de información utilizado para
colocadas en un repositorio EA electrónico centralizado. En el caso de la almacenar y acceder a información de arquitectura, las
arquitectura de línea de base, productos de la muestra a ser recogidos relaciones entre los elementos de información y
incluyen: productos de trabajo.
• funciones de negocio actuales y los flujos de información
• Los modelos de datos
• descripciones de las interfaces externas
• documentación de la aplicación y los sistemas existentes
• diseños técnicos, especificaciones e inventarios de equipo. En el caso de la arquitectura
objetivo, productos de la muestra a ser recogidos incluyen:
• procesos de negocio propuestos y el flujo de información
• Planes estrategicos
• Los planes de modernización
• Los documentos de requisitos.
Muchos de estos productos no existe o no representar con precisión la línea de base actual o entornos de destino propuestos. Si la
documentación no está presente, el equipo central de la arquitectura debe desarrollar una estrategia para crear la documentación
necesaria o decidir si hacer la inversión. En este caso, los entrevistadores tendrán que depender de las pymes comerciales o del sistema
en relación con el objeto y alcance de la actividad y las expectativas para su participación. Después de recoger una cantidad suficiente
de estos datos, el trabajo puede comenzar en la creación de los productos de EA y poblar el repositorio de EA.
Idealmente, los proyectos de productos arquitectónicos preliminares, se pueden generar en este momento sin participación de las PYME en
profundidad. Con el desarrollo de productos Strawman, los arquitectos pueden realizar una serie de sesiones de reflexión de las partes
interesadas y entrevistas en profundidad SME para solidificar los productos. El arquitecto jefe debe revisar y validar la lista de entrevistas
propuesto y asegurar la participación de las PYME a través de la comunicación con los propietarios de dominios. La comercialización y el
proceso de buy-in se describe en la Sección 3 se deben crear las condiciones para esa participación.
Puede ser útil para grabar estas entrevistas para referencia futura. Siempre haga un seguimiento para asegurar que la información de la
entrevista se interpreta correctamente. Una vez que se hayan completado las entrevistas iniciales, el equipo central de la arquitectura extrae
información de las entrevistas y luego refina los productos existentes en el repositorio de EA.
34
02 2001
5.2. Generar productos y poblar EA Repositorio
Algunos productos pueden ser creados durante la primera iteración del proceso de desarrollo de EA, mientras que otros pueden
ser creados durante las iteraciones posteriores en función de la estructura, procesos y métodos elegidos. Además, dependiendo
de si se está creando la línea de base o el objetivo, diversos factores afectarán el enfoque adoptado, el foco de los productos, y el
orden en que se generan productos. Estos diferenciadores clave se describen en la Tabla 4.
Tabla 4. Arquitectura de referencia y objetivos diferenciadores
Arquitectura línea de base Arquitectura de destino

Proceso Proceso se aplica el marco elegido. Proceso se aplica el mismo marco de línea de base.
Proceso se basa en gran medida en los manuales de la documentación, La documentación puede no existe o es probable que sea, por
por ejemplo, procesos y procedimientos existentes. ejemplo, varios documentos de visión y planificación inconsistentes.
Generación de productos se iniciará en la organización de TI, y Generación de productos comienza con la participación pesada
eventualmente extenderse a pymes comerciales para la por PYME de las unidades de negocio.
validación de los productos.
La ingeniería inversa es probable. Proceso de verificación El énfasis está en la ingeniería directa, basándose en los
de ese requisito y documentación de diseño refleja la esfuerzos de reingeniería de procesos de negocio y las
realidad. previsiones tecnológicas.
La información disponible ha sido estandarizada y Material producido originalmente para diferentes marcos de tiempo, por
normalizada como una base para el cambio. ejemplo, los planes de 1 año, los planes de 5 años, planes estratégicos,
se integra a una sola visión.
productos Los modelos se basan en la realidad. Los modelos se basan en suposiciones, planes y
necesidades reconocidas, entorno político, la tecnología
del futuro.
Los productos describen toda la empresa corriente a un nivel elevado Los productos describen una visión de toda la empresa. Un análisis
y coherente. Un análisis adicional, detalle basándose en áreas de adicional, detalle basándose en áreas de prioridad, por ejemplo, la
prioridad, por ejemplo, conocidos áreas problemáticas. modernización anticipado.
Describe manual de todas significativas y operaciones Explícitamente incluye legado, con las actualizaciones si se han
automatizadas. previsto, o si hay un cierre definitivo implícita de lo que existe
en la línea de base. También incluye planeado componentes
transitorios.
La consistencia, integridad, corrección puede ser Coherencia, la integridad puede ser validada.
validada.
Los productos están disponibles y controlada en un repositorio. Los productos están disponibles, vinculado a la arquitectura de
línea de base, y controlada en el
mismo repositorio que la arquitectura de línea de base.
La información contenida en la EA se expresa generalmente como una colección de productos interdependientes. El volumen
de información, así como el estilo de presentación de esa información a menudo es demasiado grande para un usuario a
comprender rápidamente. Además, los usuarios a menudo se centran en su área particular de preocupación y pueden pasar
por alto fácilmente las dependencias críticos que sus procesos o activos pueden tener en otros procesos y organizaciones en
la empresa. Por lo tanto, la creación de enlaces electrónicos entre la información interdependientes puede poner de relieve las
interdependencias y en gran medida mejorar la comprensibilidad de la información. El control de cambios es también
significativamente aerodinámico ?? mediante el establecimiento de los vínculos entre la información en su origen, se facilita el
análisis del impacto y las propuestas de cambio se puede evaluar con mayor facilidad.
35
El proceso de obtención de la empresa desde donde está hoy a donde quiere estar en el futuro necesita pensamiento formal y que se
centra en la optimización del rendimiento y la responsabilidad de toda la empresa. Este proceso de pensamiento se documenta con el
plan estratégico de la Agencia ?? s. Este documento define los objetivos de la misión y de largo alcance de la Agencia y se relaciona con
los planes de reingeniería y modernización de sistemas. Juntos, estos productos deben conducir la secuencia de arriba hacia abajo de
desarrollo de productos de EA.
5.2.1. Elementos de la construcción de la arquitectura de línea de base
En la construcción de la EA, un primer paso lógico está describiendo la corriente o "como es" estado. Este es un paso importante, ya que
permite el progreso futuro de medirse contra una línea de base. Se ha dicho que si usted no sabe dónde se encuentra que es difícil saber si
está en el camino hacia dónde se dirige. El establecimiento de un conjunto de productos arquitectónicos que describir y documentar el
estado actual de la empresa a partir de las funciones de negocio a la infraestructura de la tecnología crea el marco para el establecimiento
de un plan para avanzar hacia y medir el progreso contra una arquitectura objetivo.
El alcance del análisis de línea de base y la documentación resultante es crítica. Cuanto más grande sea la empresa, mayor es el
compromiso y el costo de un análisis integral, explícita, totalmente detallada y extremadamente precisa la línea de base. Para los
departamentos más grandes, hay métodos y técnicas, así como modelos, que facilitan un método de muestreo para producir las
líneas de base que son útiles y menos costoso. Medianas y pequeñas empresas puede elegir un inventario exhaustivo de los
procesos de negocio, aplicaciones y la infraestructura de la tecnología en el que operan. En ese caso, la arquitectura de referencia
es un inventario completo de las funciones de negocios, aplicaciones y problemas de software, la infraestructura y / hardware de la
tecnología de la empresa.
5.2.2. Elementos de la construcción de la arquitectura destino
La arquitectura de destino debe definir una visión de las futuras operaciones de negocios y tecnología de apoyo. Un plan a
largo plazo es absolutamente necesario. Una consideración clave es la determinación de la fecha del objetivo, hasta qué punto
en el futuro es la meta proyectada. Realización de una organización misión y visión ?? s necesita:
• Un enfoque en las áreas de negocio y la información que necesita con el mayor beneficio potencial para la empresa
• Desarrollo de modelos y herramientas que permitan a los tomadores de decisiones y al personal a reconocer mejor, comprender y
analizar los requisitos de información conceptuales
• La comprensión de toda la empresa de la gran imagen ?? ?? y la necesidad de información compartida
• Un reconocimiento de la información como recurso estratégico que se regule mediante arquitecturas como herramientas
• evaluaciones periódicas de los avances de la empresa ?? s hacia su entorno de destino
• La alineación con el plan estratégico de la empresa ?? s.
La arquitectura de destino describe la capacidad deseada y la estructura de los procesos de negocio de la empresa, las necesidades
de información, y la infraestructura de TI en algún momento en el futuro. Por lo tanto, la arquitectura objetivo se refiere a menudo como
la "A-Ser" o ?? Como planificada ?? arquitectura. La arquitectura objetivo puede incluir alternativas, opciones, y las incógnitas ?? esto
es aceptable. El proceso de EA se incógnitas ?? iterativos se rellenan con el tiempo.
36
Una arquitectura objetivo representa mejoras en una arquitectura de referencia existente que añadir una nueva funcionalidad para
apoyar las operaciones de negocio y proporcionar un mayor apoyo a las operaciones de negocio existentes. La arquitectura de
destino debe ser fiscal y tecnológicamente posible, mientras que estar basados en las necesidades de negocio de la organización.
Las realidades de los rápidos cambios tecnológicos requieren flexibilidad y capacidad de cambio en las arquitecturas objetivo: deben
proyectar no más de 3 a 5 años en el futuro.
Al igual que la arquitectura de referencia capta las prácticas comerciales existentes, funcionalidad, y los flujos de información, la
arquitectura objetivo refleja lo que la organización necesita desarrollar sus recursos de información. La arquitectura de destino
proporciona respuestas a estas preguntas básicas:
• ¿Cuáles son los objetivos de negocio estratégicos de la organización?
• ¿Qué información se necesita para apoyar el negocio?
• Qué Se necesitan aplicaciones para proporcionar información?
• ¿Qué tecnología se necesita para apoyar las aplicaciones? Las respuestas a

estas preguntas están basadas en los requerimientos de información de la Agencia ?? s, ya
su vez, las necesidades de información se basan en las prácticas de la organización ?? s de
Pronóstico tecnología ?? una descripción
negocios, funciones y operaciones. A medida que cambian las funciones de negocio,
detallada de las tecnologías emergentes y los
contenido de información y el flujo de información también cambian. previsiones de estándares de tecnología pertinentes a los
tecnología y estándares de información de perfiles puede identificar la necesaria para apoyar sistemas y procesos de negocio cubiertos en la
estos procesos de negocio cambiantes. Estas previsiones y perfiles estándares son Agencia ?? s EA.
requisitos previos necesarios para el desarrollo de la arquitectura destino. Dentro de la

arquitectura objetivo, estos productos se pueden reflejar en el producto TRM. Perfil normas ?? una especificación de
documentos, estándares de tecnología, los
protocolos y las definiciones.
Modelo de Referencia Técnica (TRM) ?? una

El desarrollo de una imagen de la organización futuros procesos de negocio e taxonomía que proporciona un conjunto coherente
información ?? s necesidades es fundamental para el éxito del desarrollo arquitectura de áreas de servicio, las categorías de interfaz, y
objetivo. Este punto de vista de negocio consiste en un conjunto de productos las relaciones para abordar la interoperabilidad y
arquitectónicos derivados de los planes de la agencia ?? s estratégicos, resultados de sistemas abiertos. La TRM integra las normas
reingeniería de procesos, planes de inversión de capital, y otra documentación de

planificación.
fil DHL F
La arquitectura objetivo debe:
• Reflejar la opinión de que el equipo ?? s EA sobre los futuros usos y características de la información dentro de la empresa
• Reflejar los requisitos de negocio de la organización ?? s revisión para centrarse en las oportunidades para automatizar los aspectos
del trabajo y / o el acceso a la información necesaria para realizar el trabajo
• Incorporar las previsiones de tecnología
• Especificar el nivel necesario de interoperabilidad necesaria entre las fuentes de datos y los usuarios de los datos
• Identificar la TI necesaria para soportar objetivo técnico de la empresa ?? s
• Reflejar los problemas presupuestarios y territoriales.
3-7
de febrero de 2001
5.2.3. Modelos de revisión, Validar y refinar
productos de arquitectura se presentan tanto para la revisión interna y SME. Después de una extensa revisión interna por el equipo central
de EA, el SME y el dominio propietarios evalúan los productos de EA para la exactitud e integridad. Esto se produce en varios puntos en el
proceso. Antes de entrevistas SME, altos miembros del equipo central de la arquitectura realizar una revisión "vistazo rápido". Esta opinión
sienta las bases para el proceso de entrevistas. Ayuda a los entrevistadores a formular una plantilla para enfocar las sesiones de
entrevistas. La siguiente revisión se produce después de que el equipo se ha actualizado y ampliado en el primer conjunto de productos.
Puede haber ciclos adicionales entrevista / examen antes de pasar a la revisión SME.
En la revisión de las PYME, los participantes en la revisión (es decir, arquitecto jefe, equipo central de la arquitectura, control de calidad, gestor de
riesgos, las PYME, los propietarios de dominios) determinan EA exactitud e integridad del producto. El gestor de riesgos puede proporcionar una
evaluación temprana de los riesgos de negocio, técnicos, de costos o de horario. Los productos a continuación, deben ser revisados según sea
necesario y se presentan al TRC y EAESC para la validación y aprobación final. Una vez aprobada, la arquitectura final (productos y modelos)
puede ser publicado, sesiones de información y documentación entregada, y las bases de datos adecuadas o herramientas de arquitectura
actualiza.
IV y V comentarios deben ser considerados en los hitos clave dentro del proceso de EA en función de los principales hitos de ingeniería
de la empresa, los hitos CPIC, y otros factores. Una vez que el modelo de EA y los productos resultantes se estabilizaron y validados,
es importante para responder a las recomendaciones del equipo (s) de validación. Si es necesario, el equipo central de la arquitectura
debería aumentar, evolucionar, o ampliar los modelos EA, tanto en alcance y detalle, de acuerdo con las recomendaciones.
5.3. Desarrollar el Plan de secuenciación
Los cambios necesarios para la transición desde el estado actual de la empresa

para los objetivos y las condiciones expresadas por la arquitectura de destino no se
pueden lograr en un solo paso cuántico. La evolución de la empresa desde su inicio
hasta la arquitectura objetivo necesita múltiples actividades interdependientes
concurrentes e incremental construye. La mejor forma de comprender y controlar Desarrollar la secuenciación
este complejo proceso evolutivo es mediante el desarrollo y el mantenimiento de un Plan
sistema de
hoja de ruta de migración o plan de secuenciación. El plan de secuencia debe proporcionar un proceso paso a paso para pasar de
la arquitectura de línea de base a la arquitectura de objetivo.
El plan de secuencia puede estar soportado por un conjunto de productos de arquitectura, similar a los productos de referencia y
arquitectura objetivo, generados por varios puntos intermedios en el tiempo entre los entornos de línea de base y de destino. La
sucesión de un punto en el tiempo a la siguiente, y en el marco de tiempo objetivo, establece una secuencia de migración.
Debido a que el plan de secuencia representa el entorno actual, así como los programas de desarrollo que están tanto
planificadas y en curso, se convierte en una herramienta principal para la gestión de programas y las decisiones de inversión.
Para seguir siendo actual y apoyar continuas mejoras coordinadas en toda la empresa, el plan de secuencia debe ser
mantenido y actualizado como el tiempo y las circunstancias.
38
Además de los requisitos específicos de desarrollo para los nuevos componentes de la arquitectura objetivo, el desarrollo del
plan de secuencia debe tener en cuenta una amplia variedad de insumos, incluyendo:
• Sostenimiento de las operaciones durante la transición
• Existente activos técnicos y los acuerdos contractuales
• Los programas de desarrollo en curso

• gestión anticipada y cambios en la organización
• Los objetivos de negocio y las prioridades operacionales (incluyendo la legislación y las directivas ejecutivas)
• Las prioridades del presupuesto y limitaciones.
5.3.1. identificar las brechas
El primer paso en la planificación de transición es el análisis de brecha ?? la identificación de las diferencias entre las arquitecturas de línea de
base y de destino en todos los productos de arquitectura relacionados. Diferencias críticas son las que afectan a la realización con éxito de la
misión de la empresa ?? s. En consecuencia, el análisis de las deficiencias también desarrolla las necesidades de los usuarios, determina las
limitaciones políticas y técnicas, y evalúa los riesgos de migración y viabilidad.
A través de análisis de las deficiencias, el equipo central de la arquitectura puede determinar los componentes que necesitan ser cambiado
para alcanzar el estado final deseado. La brecha entre las arquitecturas de referencia y objetivos es superada por una serie de
compilaciones incrementales que conducen al entorno de destino. El tamaño de los incrementos se basa en el tiempo total entre la línea de
base y de destino, las dependencias entre los programas y componentes de desarrollo, análisis de ruta crítica para actividades altamente
dependientes, las prioridades del negocio impulsado (por ejemplo, los mandatos legislativos y directivas ejecutivas), limitaciones en capital
humano capacidad de gestión de los proyectos incrementales y construye, que se espera retorno oninvestment de proyectos y construye, y
los riesgos. En general, el análisis de las deficiencias evalúa el estado de las oportunidades de los sistemas de legado, madurez de la
tecnología, adquisición,
5.3.2. Definir y diferenciar Legacy, migración, y nuevos sistemas
Legacy, la migración, y los nuevos sistemas constituyen los componentes técnicos para la transición al entorno de destino. Los sistemas
heredados y sus aplicaciones son los de operación actual y por lo general están gradualmente durante el despliegue de la arquitectura
objetivo. sistemas de migración y aplicaciones podrán estar en servicio actual, pero sin duda estarán en funcionamiento cuando la
transición comienza y desde hace algún tiempo en el futuro. Por lo tanto, pueden no ser representados específicamente en la
arquitectura objetivo. sistemas de migración también incluyen sistemas, bases de datos, interfaces, u otros componentes que pueden
ser introducidos y se usan para mantener las operaciones entre los sistemas actuales (y fase incremental) y el establecimiento de
componentes de la arquitectura objetivo temporalmente. Los nuevos sistemas y aplicaciones son aquellas que hayan sido absorbidas,
están en desarrollo, o están siendo desplegado. Se espera que entre en funcionamiento como parte del entorno de destino.
La clave para priorizar los proyectos es la secuenciación de la terminación de los sistemas, la eliminación gradual de la funcionalidad, y el
momento de la implementación de sistemas, la inserción de la tecnología, y la adición de nuevas funciones en la empresa. El equipo central
de la arquitectura de doble considera el funcionamiento de los sistemas de legado, junto con la primera puesta en marcha de nuevos
sistemas y la cuenta de este potencial en el plan de secuencia. El flujo ininterrumpido y gestión de datos, su uso tanto por el legado y los
nuevos sistemas, y su creación y distribución deben estar señalados en el plan de secuencia. La migración debe gestionarse de forma
incremental y perseguido por lo que el impacto de acontecimientos imprevistos
39
(Por ejemplo, problemas técnicos, retrasos fiscales, etc.) se reducirán al mínimo sobre el funcionamiento eficaz de la empresa.
Las decisiones sobre las inversiones secuenciados necesitan ser impulsados por los análisis de alto nivel sobre los costes respectivos, beneficios
y riesgos, así como las dependencias técnicas y funcionales secuenciales.
Una sección importante del plan de secuenciación es la evolución del sistema o la migración análisis capturado en un conjunto de tablas de
migración de sistemas, diagramas o gráficos. La Figura 13 ilustra un diagrama de migración nocional. Este tipo de gráfico ayuda a ilustrar cómo se
espera que los sistemas y aplicaciones para evolucionar entre las arquitecturas de referencia y objetivos. En general, un sistema evoluciona en
una de seis maneras:
1. Los sistemas actuales continúan en funcionamiento (Sistema D)
2. la funcionalidad del sistema existente es absorbida por otro sistema (Sistema A en el Sistema B)
3. sistema legado transiciones a la migración y evoluciona hacia un nuevo sistema (Sistema B en

Sistema X)
4. El sistema actual está prevista para una mayor evolución (Sistema C en el Sistema de Y)
5. Un nuevo sistema desarrollado durante la transición que se convierte en el sistema final permanente
(Sistema E)
6. Una fusión de los sistemas de funcionalidad legado y migración (Sistema de N en el Sistema de K y

luego absorbido en Sistema D).
Hoy Periodo de transicion Objetivo
Un sistema de
sistema B sistema B sistema X
sistema C Y sistema
sistema E sistema E
sistema D sistema D
sistema N sistema K
Figura 13. Gráfico de sistemas de migración
Una inserción de funcionalidad y secuenciado un plan de implementación detallado de los sistemas de TI se desarrolla en base a
las prioridades operacionales, la gestión de riesgos, y el retorno de la inversión.
5.3.3. Planificación de la migración
La tasa de modernización ??, es decir, la migración a la arquitectura objetivo ?? necesita ser planificada en incrementos
convenientes, manejables para acomodar la capacidad de organización ?? s para manejar el cambio. Comprender el nivel de
esfuerzo es necesario asignar y gestionar el trabajo con arreglo a la migración programada con hitos. Esto dependerá de los
sistemas de información propuestos
40
desarrollo o adquisición, las prioridades y la disponibilidad de los recursos, como el presupuesto, el personal y las limitaciones de tiempo.
La implementación de procesos de negocio cambió podría expresarse como iniciativas de programas con uno o más proyectos. Una
revisión de la colección de huecos entre las arquitecturas de línea de base y de destino determina que se necesitan mejoras,
modificaciones y sustituciones. análisis de la dependencia determina las alternativas disponibles para las actividades secuenciales y
concurrentes, y ayuda a determinar lo que se debe lograr en la que incrementar o iteración de proyectos. Proyectos serían entonces
ser definidos para implementar cada una de las iniciativas (o conjuntos de los mismos). Cada proyecto representa una división
lógica de trabajo que es más fácil de describir y gestionar desde el esfuerzo global y se asigna a un gerente de proyecto individual
con clara responsabilidad de su éxito.
El siguiente paso en el desarrollo de la ruta de migración se centra en el análisis de la dependencia y la consideración para el nivel deseado de
esfuerzo para cada uno de los proyectos. La interdependencia de los sistemas dentro de la empresa y las dependencias entre proyectos e
iniciativas es la fuerza impulsora principal en la determinación de la secuencia para la implementación de soluciones. La estimación del
esfuerzo y la duración de cada iniciativa proporciona información adicional al análisis de la dependencia que soporta análisis de la ruta crítica.
Después de considerar opciones que ofrece ventajas y desventajas de ser crítica frente a cambios no críticos, dando prioridad a mejoras clave
para satisfacer las prioridades de gestión de claves (como los mandatos legislativos o directivas ejecutivas), y la disponibilidad de suficiente
libertad de acción para reducir riesgos del cronograma, un plan borrador de la secuencia de la cartera de los proyectos se pueden crear.
refinamiento final del plan de secuencia implica la revisión y refinamiento para satisfacer las necesidades a corto plazo y las prioridades
potencialmente volátiles de las unidades de negocio dentro de las limitaciones financieras de la empresa. Las siguientes son algunas cuestiones
clave a considerar cuando se refina la estrategia:
• ¿Cuál es el potencial de compromiso de fondos para las fases iniciales de la migración?
• ¿Cuál es el potencial para el compromiso de fondos para la transición completa a la arquitectura objetivo?
• ¿Qué tan pronto las unidades de negocio ver los beneficios iniciales (es decir, mejoras operacionales o de retorno de la
inversión) del plan?
• ¿El plan de secuencia proporcionan mejoras incrementales a los usuarios del sistema para ayudar a sostener el
compromiso y el apoyo al programa?
• ¿Qué riesgos son inherentes al plan de secuencia actual? ¿Cómo van a ser mitigados?
• ¿Qué alternativas están disponibles actualmente si los fondos o recursos se retrasan? La modificación, mejora o
desarrollo de información pueden incluir aplicaciones, integración de datos e interfaces, así como la adquisición de la
plataforma de sistemas, personal, formación (o reciclaje), y el despliegue de sistemas. Debido a que casi todo el desarrollo
de sistemas implica el control y la transferencia de fondos, desarrollo de sistemas debe ser coordinada e integrada con la
gestión financiera. Además, interrelaciones e interdependencias ?? si la arquitectura, la organización y externa ??
necesidad de tener en cuenta en el plan de secuenciación.
5.4. Aprobar, publicar y divulgar los productos de EA
Después de la verificación y validación de los productos arquitectónicos, la gestión de la Agencia ?? s debería aprobar la estructura
general. Este paso incluye la aprobación de la EAESC, el CIO, arquitecto jefe, y ejecutivos de la agencia hasta e incluyendo el director
del organismo (por ejemplo, el secretario,
41
Comisionado, o directores). Cada Agencia incorpora sus propios procesos de aprobación para este ciclo.
Los ejecutivos de agencias, administradores y arquitectos deben tener fácil acceso a la información en la EA. Mediante la distribución de la
información en formato electrónico de sólo lectura, los ejecutivos y los gerentes pueden utilizar la información directamente, mientras que la
línea de base se mantiene controlada. Los ejecutivos y los gerentes deben utilizar la información para algo más que para fines de referencia
?? incorporándolo en comunicaciones, informes y directivas. los arquitectos de aplicaciones utilizan la información para analizar los
artefactos en contra de su propia realidad y la identificación de oportunidades de mejora. arquitectos de la empresa usan la información para
aplicar ?? qué pasaría si ?? análisis frente a la línea de base. Además, las versiones de formato de sólo lectura de la EA limitan el número
de personal capaz de hacer cambios y modificaciones en los productos, lo que facilita la carga de la gestión del cambio en la empresa en su
conjunto.
La EA documenta una amplia información sobre la Agencia. La consideración cuidadosa debe ser hecha a la distribución de esa
información. Aunque es posible que un EA puede no tener ninguna información confidencial, la agregación de la información puede
comprender un riesgo de seguridad. En las manos equivocadas, la recopilación de información de la empresa en la EA podría crear una
vulnerabilidad a la Agencia por proporcionar información suficiente para la infiltración y la interrupción. Parte de la información (o
combinaciones de los mismos) pueden necesitar ser controlada y visitada en una ?? necesidad-toknow ?? básicos (por ejemplo, los
modelos de red, factores de rendimiento críticos, las interfaces del sistema, etc.). El equipo central de la arquitectura considera qué clases
de usuarios de EA necesitarán qué información: contratistas, personal de gestión, y la Agencia suelen centrarse en áreas particulares de la
empresa, y por tanto sólo pueden necesitar subgrupos particulares de la EA. Un EA que incluye una visión completa de los detalles de los
sistemas y la infraestructura de la Agencia podría organizarse en niveles de detalle y se distribuye en un formato escalonado
correspondiente a las autorizaciones de seguridad y la necesidad de saber.
Architecting es un proceso continuo e iterativo que requiere la modificación y mantenimiento regular. Cada vez que el EA cambia,
es imperativo para actualizar los modelos de arquitectura. Una discusión detallada de mantenimiento de la arquitectura se presenta
en la Sección 7.
42
6. Utilice la arquitectura de la empresa
El uso de la EA para implementar nuevos proyectos ofrece un impacto positivo en la empresa. Si no se utiliza con éxito el EA, todo el
esfuerzo de desarrollo de este punto es en vano. En esta sección, el énfasis se desplaza a la integración de la utilización de EA a
través de múltiples actividades y grupos de la organización. El éxito depende de una gestión activa, arquitectos proactivas, y el
personal del proyecto receptivos. También depende de la integración del proceso de EA con otros procesos del ciclo de vida de la
empresa, en particular el proceso de CPIC.
El establecimiento de la EA captura el estado de la empresa y el plan para su futuro ??, literalmente, una instantánea de la empresa y sus
planes de mejora. Para la EA para proporcionar la base de información estratégica de activos según lo previsto, debería convertirse en una
herramienta crucial para apoyar las decisiones y la comunicación en la corriente principal de las operaciones diarias del negocio. La aceptación
y la aplicación de este activo en el paradigma operativo de la Agencia ?? s es un reto técnico y cultural.
La EA se gestiona como un programa que facilita el cambio agencia sistemática mediante la alineación de forma continua inversión en tecnología
y proyectos con necesidades de la misión de la agencia. La EA se actualiza continuamente para reflejar los cambios en las prioridades
operacionales y de inversión que puedan surgir debido a la legislación, las limitaciones presupuestarias, u otros impulsores de negocios. Es una
herramienta primordial para el control de la línea de base de la empresa, las decisiones interdependientes complejas y comunicación de esas
decisiones a las partes interesadas de la agencia. El plan de secuencia proporciona una guía fuerte para las agencias que toman las decisiones
para utilizar la forma que estimen proyectos propuestos. Si un proyecto no está representado en el plan de secuencia, ya sea que se le debe
negar la financiación, ya que no está alineado con la estrategia de la agencia que se concreta en la EA, o que se debe conceder una exención si
se trata de una desviación legítima impulsada por los cambios válidos en el entorno de la agencia ?? s que todavía no se han reflejado en la EA.
Cabe señalar que es crucial que la EA representan las estrategias y los imperativos actuales de la agencia en la mayor medida posible, ya que
cualquier retraso en la EA puede limitar la agencia ?? s capacidad para ejecutar con eficacia su misión hasta que se emita una renuncia o la EA
está adaptado. En los casos en que se haya concedido una exención, la causa de la renuncia debe ser examinado y cambios apropiados en la EA
considera si la causa representa una brecha válida y permanente en la EA. ya que cualquier retraso en la EA puede limitar la capacidad agencia
?? s para ejecutar con eficacia su misión hasta que se emita una renuncia o la EA está adaptado. En los casos en que se haya concedido una
exención, la causa de la renuncia debe ser examinado y cambios apropiados en la EA considera si la causa representa una brecha válida y
permanente en la EA. ya que cualquier retraso en la EA puede limitar la capacidad agencia ?? s para ejecutar con eficacia su misión hasta que se emita una renuncia o la E
6.1. Integrar la EA con CPIC y SLC Procesos
Gestión de las inversiones y de los sistemas de desarrollo / adquisición están estrechamente vinculados con los procesos de EA. 6 La
agencia sólo debe hacer inversiones que se mueven hacia la agencia de la arquitectura objetivo y estas decisiones de inversión
deben cumplir con el plan de secuenciación. La EA, CPIC, y SLC (ciclo de vida de los sistemas) se integran los procesos para
adaptarse mejor a la agencia ?? s organización en particular, la cultura y las prácticas de gestión interna. existen ciertas relaciones
básicas entre estas funciones y tienen un objetivo común: la gestión eficaz y eficiente de las inversiones en TI. El diálogo a través de
los procesos de CPIC, SLC, y EA es continuo, cooperativo, y facilitado por la agencia de compromiso con un proceso integrado. Los
detalles de esta relación entre los procesos de gestión y el proceso de planificación y control de la inversión de capital se discuten
en el Arquitectura Guía de Evaluación de Alineamiento y y el Prácticas inteligentes en Capital Planning documento. Gestión de
Inversiones Tecnología de la Información de la GAO ?? s
6 Como se discutió como el comienzo de esta guía, estos procesos también están vinculados con los procesos de gestión de seguridad de la información y los procesos
de gestión del capital humano. Los vínculos con estos dos últimos procesos, sin embargo, no se abordan explícitamente en esta guía.
43
15 de marzo de, de 2002
Una guía práctica para Federal Enterprise Architecture Utilice la arquitectura de la empresa
Marco de referencia proporciona un enfoque estructurado para la gestión de inversiones de TI que es consistente e integrada con los principios
de buenas prácticas de ciclo de EA y de la vida del sistema.
Cada agencia diseña su propio proceso de formulación del presupuesto CPIC estructuración y ejecución para asegurar que las inversiones
apoyan consistentemente las metas estratégicas. Todos los proyectos de TI deben alinearse con la misión de la agencia y apoyar las necesidades
de negocio agencia de minimizar los riesgos y maximizar los rendimientos a lo largo del ciclo de vida de la inversión ?? s. La arquitectura de
objetivo y el plan de secuencia proporcionan información para las tres fases del proceso de CPIC. En el cuadro Seleccione fase, la agencia
determina si la inversión propuesta cumple con los criterios de decisión de negocios. Para evaluar la alineación con el negocio de la inversión
propuesta, los tomadores de decisiones usan, por ejemplo, el caso de negocio, plan de adquisición y el plan del proyecto para determinar si la
inversión propuesta se alinea con el plan de secuencia y la arquitectura objetivo. En la fase de control, tomadores de decisiones monitor de
negocio y el cumplimiento técnica como se ha demostrado, por ejemplo, el caso de negocio actualizado, arquitectura de sistemas, diseño de
sistemas, y el programa de prueba. Además, la inversión debe ser monitoreado para asegurar la alineación continua con los objetivos estratégicos
y de negocio de la agencia ?? s, que pueden cambiar con el tiempo. En la fase de evaluación, los que toman las decisiones llevan a cabo una
evaluación final para determinar la conformidad técnica y estratégica con la EA. Los resultados, incluyendo los hallazgos de incumplimiento, deben
influir en la planificación estratégica para nuevos proyectos empresariales y de TI, lo que podría conducir a cambios en la EA. la inversión debe ser
monitoreado para asegurar la alineación continua con los objetivos estratégicos y de negocio de la agencia ?? s, que pueden cambiar con el
tiempo. En la fase de evaluación, los que toman las decisiones llevan a cabo una evaluación final para determinar la conformidad técnica y
estratégica con la EA. Los resultados, incluyendo los hallazgos de incumplimiento, deben influir en la planificación estratégica para nuevos
proyectos empresariales y de TI, lo que podría conducir a cambios en la EA. la inversión debe ser monitoreado para asegurar la alineación continua con los objetivos estraté
Las figuras 14 y 15 ilustran un ejemplo de un proceso de CPIC y gestión arquitectura desarrollada por el Servicio de Aduanas
(Aduanas) ?? el Proceso de Gestión de inversiones (IMP). Hay una discusión detallada de su IMP en el Aduanas de Estados
Unidos Enterprise Service Architecture Blueprint ( Agosto de 1999). Este marco permite el cumplimiento de la EA y la
gobernabilidad necesaria para su aplicación a las actividades de gestión del ciclo de vida empresarial.
Los proyectos son gestionadas y ejecutadas a través del ciclo de vida de desarrollo de sistemas / adquisición de la agencia ?? s. Cada agencia
puede tener su propio enfoque único para el ciclo de desarrollo de los sistemas / adquisición, pero ciertos elementos fundamentales, tales como
requerimientos, sistemas y arquitectura de software, el diseño y la prueba son comunes.
Proyecto Proceso de Inversión / Arquitectura Objetivo que se

Marco de evaluación App.Port /
Alineado por estrategia de TI Infra.
Evaluar la
Responder a los iniciativas
alineación de
cambios
empresariales negocios
Concepto propuesto (SELECCIONAR)
1 desarrollar
negocios Evaluar
Caso Business Case
La alineación aceptables
Propuesta
El cumplimiento Evaluar la Cuadro de Mando
(CONTROLAR) tecnología de la
de alineación Empresa
?? Definir ??
aceptables
2 Patrones de
conformidad
Construir ?? 3 diseño
Implementar ?? (SELECCIONAR)
Normas de
Funcionar TRM
proyecto de
inaceptable
inicialización
(EVALUAR) Informe Evaluación del
Evaluación cumplimiento
Evaluar el
El cumplimiento
cumplimiento de
4 Arquitectura Conformidad inaceptable alineación
inaceptable desaprobado
5
Los informes de auditoría de informe Arquitectura Arquitectura Roles
IRB
Evaluar Renuncia /
Solicitud de excepción Proceso
Figura 14. IMP / Arquitectura Proyecto Marco de Evaluación
44
Gestión de Tecnología de la Arquitectura
desaprobado
Evaluar la Normas de
tecnología de la TRM
conformidad Edición Renuncia /
Excepción
TRM contención
Informe Conformidad inaceptable de Exención

5 Aprobado excepción de una sola vez Bloquear
Iniciar la solicitud de exención / excepción
por TRC
Revisión
estándares
Eventos requeridos
?? Responder a la petición del usuario Realizar

(EAPMO) Conducta sobre Tecnología e
?? Responder a la dirección del mercado
normas Inserción
(EAPMO) contables Renovación
?? Responder a dirección vendedor disparadores 6 7

(Propietario de Dominio) ?? planificación Normas de
Enterprise Filter TRM
estratégica anual y
evento (EAPMO) ?? Realizar un seguimiento de las Estrategias
tecnologías emergentes
(EAPMO / DO / SME)
Estructura
TRM
Arquitectura Arquitectura Roles
Proceso
Gestión de la Figura 15. Arquitectura
Para que una agencia para implementar con éxito un proceso integrado como se describe en este documento se necesita formar a su
personal, definir y aplicar criterios de cumplimiento, y llevar a cabo revisiones integradas. Cada uno de estos aspectos críticos se
discute en las subsecciones que siguen.
6.1.1. Personal de tren
Es responsabilidad de la dirección ejecutiva agencia de la institucionalización de las estructuras de control para el proceso de
EA, así como para la agencia CPIC y procesos SLC. Para cada órgano de toma de decisiones, todos los miembros deben estar
capacitados, en su caso, en la EA, el proceso de EA, y la relación de la EA a la CPIC y SLC. formación específica, en varios
niveles de detalle, debe adaptarse al papel arquitectura del personal.
Cualquiera que pueda presentar una propuesta al Consejo de Inversión de Capital (CIC) ?? tales como administradores de dominio y
administradores de proyectos debe entender ?? el requisito de que las evaluaciones de EA. Para evaluar adecuadamente una propuesta de
inversión, el CIC necesita información específica. Los individuos que crean las propuestas de inversión deben estar capacitados, en su
caso, en los criterios y requisitos de presentación. Una formación adecuada preparará el personal para evaluar el cumplimiento y corregir
las deficiencias que existen antes de la presentación.
6.1.2. Establecer procesos de aplicación y Procedimientos
Los procesos y procedimientos que hacen cumplir la aplicación de la guía EA y las que aseguran su coherencia con la realidad ??
?? de la empresa son componentes críticos en EA institucionalización. Los procesos y procedimientos de EA implementar la
política de EA Ejecutivo (véase la Sección 3.1.2). La política de aplicación define las normas y procedimientos para determinar la
conformidad de los sistemas o proyectos con la EA y procedimientos para la resolución de los problemas de incumplimiento. Un
proyecto ?? s conformidad técnica y el horario se suele evaluar en términos de cómo se ajusta al contenido, intención y dirección
establecida por la EA.
45
Los procesos y procedimientos deben responder a las siguientes preguntas:
• Cómo y cuándo van a presentar los proyectos de planes de proyectos para ser revisado por el cumplimiento de EA?
• ¿Quién será el responsable de la evaluación del cumplimiento y / o justificación de la exención?
• ¿De qué manera el cumplimiento y el incumplimiento documentarse e informarse?
• ¿De qué manera las cuestiones pendientes de incumplimiento se resolverán y / o renuncias ser procesadas y aprobadas?
• ¿Quién será el responsable del tratamiento, que autoriza, y reevaluar las renuncias?
• ¿Cuál será el contenido y el formato de las presentaciones de renuncia?
• Si se concede una exención, ¿cómo lograr el cumplimiento de los proyectos en el futuro?
• ¿Cuáles son las consecuencias si un proyecto no conformes no se concede una exención (por ejemplo, restricciones de
financiación y / o despliegue)?
Los procesos y procedimientos deben, necesariamente, excepciones. En muchos casos, los sistemas existentes en la fase de
operación y mantenimiento deben concederse excepciones o exenciones de las normas técnicas y las limitaciones de la EA. La
alineación de algunos sistemas heredados con nuevas normas podría ser excesivamente costosa e introducir un riesgo adicional
para los usuarios de negocios. Además, es probable que ciertas iniciativas e innovaciones, como los esfuerzos de investigación y
pruebas-ofconcept, no cumplir con la EA. 7
6.1.2.1. Definir criterios de cumplimiento y consecuencias
Las condiciones de estudios de EA incluyen criterios de cumplimiento, las renuncias y los requisitos de presentación correspondientes. En el
caso de una propuesta no cumple con una solicitud de exención debe ser preparado y presentado formalmente al Comité de Revisión de la
Tecnología (TRC). La renuncia proporciona una justificación analítica y defendible de los cambios de diseño, las desviaciones
presupuestarias, y los impactos. La solicitud de exención incluye la identificación de los, y los impactos de productividad operacionales,
económicos de cualquier renuncia. Los impactos correspondientes de la renuncia no ser aprobado también deben ser proporcionados a la
TRC. La CVR recomienda a la aprobación del CIC o denegación de las solicitudes de exención. El CIC aprueba o rechaza las solicitudes de
exención en base a esta información.
La CVR aprueba la exención de acuerdo con la aplicación de proceso de la agencia ?? s. Cada exención que está aprobado presenta una
oportunidad para la retroalimentación en la EA y el proceso de EA. Por ejemplo, la necesidad de una renuncia puede indicar que la arquitectura
objetivo, el análisis de transición, y / o el plan de secuencia son demasiado limitando o demasiado rígidamente definidos. Además, los requisitos
que evolucionan rápidamente pueden hacer necesario revisar los planes existentes fuera del proceso normal de EA, ya que las renuncias pueden
indicar que el entorno de destino definido no refleja las necesidades de la agencia. También la necesidad de propuestas reelaboración puede
indicar problemas en la formación para el cumplimiento.
El proceso CPIC debe respetar la integridad del plan de secuencia, mientras que teniendo en cuenta el valor estratégico y táctico de todas las
propuestas que pasan por los puntos de control CPIC. Proyecto factores críticos de éxito se siguen cumpliendo. Este doble control de las
propuestas de proyectos se asegura de que todos los proyectos financiados se reúnen las condiciones necesarias para el éxito. Estas
condiciones incluyen, pero no se limitan a:
• Coherencia con la EA
7 Después de emprender el esfuerzo de investigación innovadora o no conforme y controlados adecuadamente durante su ejecución, puede convertirse
en un proyecto candidato a la consideración del EAESC y TRC. Tal proyecto así podría ofrecer cambios en la EA propuesto.
46
• Satisfacción de los costes de referencia del proyecto, programación, capacidad y compromisos de valor de negocio
• El cumplimiento de las políticas y directrices de gestión de inversiones de la agencia publicado
• El apoyo explícito por la dirección ejecutiva.
6.1.2.2. Configurar Comentarios Integrados
La CPIC Seleccionar, controlar y evaluar las fases requieren una revisión de las propuestas y el desempeño del proyecto siempre que se
contempla un cambio significativo o en etapas lógicas o puntos de decisión clave (KDPs) en el ciclo de vida de los sistemas. KDPs son puntos en
los que la administración debe adoptar medidas respecto del alcance del proyecto, el enfoque, la financiación, etc. aplicación de la EA se debe
aplicar en KDPs, cuando sea posible, ya que es en aquellos puntos que la alta dirección se reunirá para considerar las decisiones de inversión. Los
comentarios también pueden ocurrir periódicamente, por ejemplo, como parte de un ciclo de capital de planificación / presupuesto integrado. Dado
que la EA es una herramienta de gestión importante para el seguimiento y orientar el cambio dentro de la agencia, el resultado es importante para
programar una revisión para asegurar que las inversiones previstas se quedan en la fecha prevista, dentro del presupuesto, y alcanzar los objetivos
definidos. En adición, estas revisiones proporcionan la oportunidad para que el equipo de EA para comunicar cambios en la arquitectura objetivo y
plan de secuencia a la agencia en su conjunto, así como a los proyectos específicos que se verán afectados. Las desviaciones de cumplimiento
pueden ser abordados mediante la implementación de cambios en el proyecto o por una solicitud de exención.
6.2. Ejecutar el Proceso Integrado
El progreso hacia la arquitectura objetivo se logra a través de programas y proyectos. Nueva y seguimiento en proyectos son
(1) iniciado y seleccionada, (2) ejecutado y controlado, y (3) completaron y evaluados. Las siguientes secciones muestran el
flujo de información para cada una de estas tres fases CPIC con énfasis en la forma en la EA soporta todo el proceso.
6.2.1. Iniciar un nuevo y Seguimiento de Proyectos
Patrocinadores proponen proyectos en diferentes circunstancias:
• Se identifican nuevos proyectos y patrocinado basan en la interpretación del dominio propietario ?? s del plan de secuencia. Un
proyecto para llenar el vacío puede resultar en la reingeniería de procesos de negocio, desarrollo de TI, y / o cambiar a la
infraestructura.
• proyectos de seguimiento planeada se anticipan, pero todavía necesitan revisión por parte del CPIC y una evaluación de la
finalización de las dependencias en proyectos anteriores.
• Una necesidad de una mejora de arquitectura se identifica, por ejemplo, para incorporar un nuevo estándar o tecnología
identificada por el análisis de la arquitectura objetivo, hueco y de transición, y el plan de secuenciación.
• Un patrocinador puede iniciar un proyecto basado en una necesidad comercial o técnica que no se identifica en el plan de
secuencia. En este caso, una renuncia tiene que ser aprobado y el equipo de EA debe responder al considerar
modificaciones a la EA. Esto se basa sólo es posible en un proceso de renuncia y la aprobación formal incluyendo el
EAESC, CIC, y otros paneles a nivel ejecutivo.
La Figura 16 representa el flujo de información cuando se inicia un proyecto. Sirve como una guía a través del ciclo de preparación de
la propuesta, la alineación del proyecto propuesto con la EA, y tomar la decisión de financiar el esfuerzo. El flujo de información
garantiza que los requisitos se están abordando y que una implementación propuesta cumple con las expectativas y requerimientos.
47
Los directores de programas Consejo de

propietarios de dominios Decisión de lanzar, Condiciones
Inversiones
Arquitectos sel
(CIC)
proponer
ect
programas Proceso
y CPIC
Proyectos Requisitos de negocio
Necesita
Actualizaciones tecnológicas
EA repositorio /
Herramienta
Programa / Proyecto de propuesta de

los productos de EA Actualizaciones EA
evaluación EA solicitudes aprobadas
Propuesta de Programa / Proyecto de
Recomendaciones
evaluación de impacto EA y EA cambios
propuestos
Administrar EA
Evaluar / Align
EAESC
TRC
Arquitectos
Figura 16. Definir nueva y Seguimiento de Programas / Proyectos
6.2.1.1. preparar Propuesta
El patrocinador de un proyecto prepara una propuesta de conformidad con los requisitos de las agencias predefinidos. La propuesta presenta el
caso de negocio para el proyecto y define una solución de negocio utilizando información de la EA, así como de otras fuentes. Los requisitos de
negocio, que necesita, y la tecnología actualiza todos los alimentos para la definición del esfuerzo que se está planeado. los propietarios de
dominios y líderes de programas o proyectos a preparar la propuesta por:
• objetivos de mapeo en los requisitos y las relaciones entre los requisitos de alto nivel a los objetivos de negocio
• La documentación de un caso de negocios de alto nivel
• Proporcionar un estudio de costos
• La definición de una solución de modelo de negocio y determinar el nivel de impacto introduce en el entorno de TI
• Asegurando la razonabilidad de los riesgos, el tiempo y costo
• Asegurar que las implicaciones técnicas y comerciales a la organización se tratan. Los propietarios de dominio y los jefes
de programa o proyecto deben cumplir con los requisitos de información de proyectos de arquitectura y proporcionarán respuestas a
los criterios de cumplimiento en la documentación de la propuesta. Para la selección, se mostrarán que la inversión apoya la misión
de la agencia, que la inversión cumple con los criterios de negocio, y que es consistente con la arquitectura objetivo y un plan de
secuenciación. Si una inversión se desvía del plan de secuencia, el razonamiento de la desviación debe ser documentada.
48
El director de arquitectura de la arquitectura y el equipo puede asesorar líderes de programas / proyectos de desarrollo de casos /
solución de negocio. Contribuyen al desarrollo de propuestas de inversión y trabajan para facilitar el progreso a través de la CPIC.
Tienen un interés específico en asegurar que se financian proyectos identificados en el plan de secuencia, y de hecho pueden introducir
este tipo de proyectos. Para otros proyectos, van a apoyar a los líderes de proyectos en la iniciación y el desarrollo de propuestas.
6.2.1.2. Alinear el proyecto de la EA
El director de arquitectura de la arquitectura y el grupo realizan evaluaciones de propuestas. La Tabla 5 describe los tipos de evaluaciones
que se producen como los proyectos son sometidos a periódicas, iterativos EA comentarios. En la fase inicial de la definición y la selección
de un proyecto, el énfasis está en la alineación del negocio, solución caso de negocio, plan de secuenciación, y en un grado limitado, el
cumplimiento técnica. A medida que el concepto de sistema madura, negocio y cumplimiento técnico se tratan por igual. Los detalles de este
alineamiento con los procesos de negocio y CPIC se discuten en el Arquitectura Guía de Evaluación de Alineamiento y ( consulte el Apéndice
F para obtener una lista de referencia completa).
49
Tabla 5. Objetivos de EA Review
Tipo de comentarios EA Revisión Objetivo / Meta
Determinar si el proyecto propuesto se alinea con los planes estratégicos de la Agencia, metas y objetivos. El
objetivo de la revisión es asegurar que los resultados de negocio esperados del proyecto están alineados con
La alineación del negocio
el concepto de proyecto y de alto nivel de exigencias.
Examine la solución propuesta, en un nivel alto, para determinar el impacto introducida en el entorno
de TI de la organización ?? s. El objetivo de la revisión es asegurar que la solución propuesta es
solución de maletín de negocios
compatible tanto con el negocio y arquitectura técnica.
Determinar si la inversión propuesta es consistente con la secuencia y las prioridades en el

plan de secuenciación plan. El objetivo de la revisión es asegurar el progreso hacia la arquitectura destino.
Determinar si la arquitectura de la solución propuesta cumple con los estándares de la empresa, los
cumplimiento técnico diversos niveles de arquitectura, y metodologías. El objetivo de esta revisión es asegurar el
cumplimiento técnico de los proyectos de TI.
Tras la evaluación de la alineación del proyecto ?? s de la EA, los arquitectos pueden hacer recomendaciones y proporcionar apoyo para
traer propuestas no conformes al cumplimiento. En los casos en que se había solicitado una exención, los arquitectos pueden responder con
una evaluación independiente de la productividad, y los impactos operacionales, económicos de la renuncia.
6.2.1.3. Tomar la decisión de inversión (CPIC Seleccionar Fase)
El CIC es responsable de la evaluación de nuevas propuestas, y la supervisión de las inversiones en curso. Entre otros criterios, las
decisiones de la CIC se basan en las determinaciones que los proyectos propuestos presentados por los gerentes de negocios están
alineados con los planes estratégicos de la agencia, metas y objetivos. La propuesta de negocio y los resultados de las evaluaciones de
arquitectura, incluyendo exenciones, son revisados por los responsables de las decisiones de inversión. Las mismas condiciones y
consecuencias se refieren al seguimiento de proyectos y la financiación adicional.
En ciertas circunstancias, puede ser necesario para aprobar una propuesta que no se ajuste a la arquitectura de destino y / o el plan
de secuenciación. Las condiciones bajo las cuales se otorga una dispensa y los impactos, y la productividad económica de
funcionamiento de la renuncia son considerados en la decisión de inversión. Bajo la mayoría de circunstancias, cualquier propuesta
que no es compatible o de lo contrario no califica se le debe negar una renuncia. iniciativas no conformes pueden ser aprobados para
la investigación, desarrollo de conceptos, prototipos y otros fines. Estos esfuerzos pueden cuestionar los supuestos aceptados en la
actualidad en la EA y puede dar lugar a grandes avances que podrían mejorar significativamente la EA. Sin embargo, las condiciones
en que un proyecto puede proceder deben ser inequívoca y claramente se indica en la política de EA y deben ser documentados en
la decisión de inversión CIC ?? s. Una vez que el proyecto se ha actuado sobre, puede haber cambios en la EA o el requisito para
obtener detalles adicionales para mejorar la EA recomendado. La decisión de financiación tendrá un impacto en el plan de secuencia
y, potencialmente, la arquitectura destino y la transición análisis.
50
6.2.2. Ejecutar los Proyectos
Una vez que se recibe la financiación, el proyecto puede ser iniciado. La Figura 17 representa el flujo de información como los
ciclos de proyectos a través de los procesos de EA, SLC, y CPIC integrados. Un proyecto pasará a través de este ciclo varias
veces. Hay interacciones continuas entre los ejecutores del proyecto y la arquitectura, con mas revisiones formales en los hitos
establecidos.
Los directores de programas decisión de financiación para continuar, las

Consejo de
condiciones, las renuncias, la redirección
propietarios de dominios
Arquitectos
Co Inversiones
Manejo de
(CIC)
ntr
Programas Proceso
y Negocios y TI Prioridades ol CPIC
Proyectos Dependencias Arquitectura
Diseño y Restricciones
Requisitos propuestas Actualizaciones EA repositorio
EA Sistemas de Arquitectura y Diseño / Herramienta

del Programa / Proyecto Progreso
los productos de EA Actualizaciones EA
Programa / Requisitos de avance
del proyecto Sistemas de Arquitectura y
Recomendaciones de la Evaluación Diseño
Arquitectura
Administrar EA
Evaluar / Align
EAESC
TRC
Arquitectos
Figura 17. ejecutar programas / Proyectos
6.2.2.1. Administrar y efectuar Desarrollo de Proyectos
Los líderes de programa / proyecto usan la EA como orientación y las limitaciones de la arquitectura y diseño de sistemas de sistemas. El
objetivo de gestión del proyecto es asegurar que la solución propuesta es compatible con la EA. El proyecto ?? s requisitos, sistemas y / o
software de la arquitectura, el diseño y programa de pruebas se desarrollan utilizando los conceptos, las restricciones y las recomendaciones de
la EA. estrategias de migración de sistemas se pueden encontrar en el plan de secuencia.
El director de arquitectura de la arquitectura y el grupo contribuyen a proyectos de consultoría como arquitectos. Su papel en los requisitos y
las fases de diseño es proporcionar una guía a la unidad de negocio y sus equipos de proyectos sobre temas técnicos relacionados con la
arquitectura y las nuevas tendencias en la industria. Ellos hacen recomendaciones para las partes pertinentes de la EA (por ejemplo,
negocios, información, datos, aplicaciones, infraestructura, seguridad y estándares).
requisitos, los sistemas iniciales y / o arquitectura de software, y diseño dependen en gran medida los artefactos existentes de la
EA. A medida que avanza el proyecto, los productos son producidos que mejorar y ampliar el nivel de detalle en la EA. Estos
productos, generados de acuerdo con los requisitos SLC, son aportados y se incorporan en el repositorio de EA.
6.2.2.2. EA evolucionar con el Programa / Proyecto
Es responsabilidad del Arquitecto Jefe y el equipo central de la arquitectura, con la dirección de la EAESC, para mantener la
alineación de EA con la organización a medida que evoluciona. A lo largo de la fase de desarrollo / adquisición de un proyecto ??
s, el requisito es mantener la alineación de la
51
solución con la arquitectura de destino y un plan de secuenciación en evolución. El equipo de arquitectura revisa el negocio y solución
técnica a lo largo del ciclo de vida y asegura el cumplimiento de la EA. En las revisiones incrementales, las evaluaciones se llevan a
cabo para determinar si los productos del proyecto ?? s y documentación (el análisis funcional, el diseño general y el diseño detallado)
cumplir con los productos de EA que han sido aprobados a través de procesos de revisión anteriores. Los proyectos proporcionan
información adicional que se realiza el progreso. El objetivo es mantener la alineación del proyecto con la EA en todo el desarrollo para
evitar la construcción de sistemas que no cumplen con las necesidades de la organización ?? s.
Además de la arquitectura de sistemas y diseño específicos que la carne a cabo la EA en los niveles inferiores de detalle, los proyectos
proporcionan nuevas ideas a la EA para cambios en los incrementos de arquitectura de objetivo y de transición. La EA debe revisarse
periódicamente y sincronizado con el ciclo de vida de la empresa y las decisiones de inversión. El arquitecto jefe y el equipo de arquitectura
de incorporar esta información en el proceso de mantenimiento de EA. Véase el Capítulo 7 para una discusión más detallada sobre el
mantenimiento de EA.
6.2.2.3. Evaluar el progreso (Control de fase CPIC)
La fase de control CPIC asegura que la inversión está siendo administrado dentro de los costos, el cronograma y el diseño previsto y que la
inversión va a funcionar eficazmente dentro de la infraestructura técnica. desarrollo de sistemas y adquisición es inherentemente arriesgada.
Los gestores y los arquitectos proporcionan información de acuerdo con los requisitos de información para la evaluación de la arquitectura, y
esta información se utiliza como base para las decisiones sobre financiación continua, la imposición de limitaciones para el desarrollo, y la
posible reorientación de los esfuerzos técnicos. Este control se impone para gestionar y mitigar los riesgos. Las decisiones de inversión se
basan en el análisis de los informes de progreso, las evaluaciones de cumplimiento, y las desviaciones y exenciones para llegar a implicaciones
sobre el coste, el cronograma y el rendimiento.
6.2.3. Completar el proyecto
La mayoría de los proyectos son interdependientes en otros proyectos de desarrollo y sistemas heredados. Muchos son seguidos por incrementos
adicionales de capacidad o por las operaciones adicionales y los esfuerzos de mantenimiento (O & M). Casi todos están integrados con otros
sistemas cuando entren en funcionamiento. Cuando el proyecto esté terminado, hay una evaluación final de los impactos sobre el organismo, la
EA, las operaciones de la empresa, los sistemas futuros, y en consecuencia, las futuras decisiones de inversión y de financiación. La figura 18
representa el flujo de información sobre la terminación de un programa o proyecto.
52
Los directores de programas Consejo de

propietarios de dominios Evaluación
Inversiones
Arquitectos
(CIC)
Programas
completos Proceso
y Negocios y TI Prioridades CPIC
Proyectos dependencias
Arquitectura
Diseño y Restricciones Evaluar
EA repositorio /
Herramienta Requisitos de los sistemas de
Actualizaciones propuesta de EA Arquitectura y Diseño de Evaluación

plan de secuenciación
Arquitectura del sistema Actualizaciones EA
de Arquitectura, Diseño y aprobados
los productos de EA renuncias Recomendaciones Mejoras
requisitos
en los Procesos
Resultados de
prueba de diseño
Administrar EA
Evaluar / Align
EAESC
TRC
Arquitectos
Figura 18. Evaluar los programas / proyectos
6.2.3.1. entregar el Producto
Al final de un programa o proyecto, el sistema y los procesos de negocio actualizados se han integrado en el entorno. Un soporte de O
& M se define, se proporciona formación, y un conjunto completo de documentación se comunica al personal de operación y
mantenimiento. Se proporciona material para el repositorio de EA con el producto entregado, con el nivel de detalle apropiado para
representar la nueva arquitectura de la línea de base. Una estrategia de apoyo y despliegue se activa para operaciones paralelas o
llave en mano. Hay una transición desde el entorno de desarrollo / adquisición y gestión de la operación y el medio ambiente y la
gestión. En este momento se deben considerar las oportunidades para la reutilización de los productos de trabajo de este proyecto a
otros proyectos.
6.2.3.2. evaluar Arquitectura
El EAESC realiza una evaluación continua de la EA. Hay mucho que aprender mediante la evaluación de la medida en que
el proyecto ha cumplido con el plan de secuencia, basada en la arquitectura objetivo. La experiencia y las lecciones
aprendidas contribuyen a la solidez continua de los procesos de EA.
La evaluación final del proyecto con respecto a la arquitectura de la empresa implica la revisión del caso de negocio original, la aplicación
de las soluciones técnicas y de negocio, el plan de secuencia, y la disposición final de las renuncias. El resultado de la evaluación final es la
actualización de la arquitectura de línea de base con los cambios implementados en los procesos de negocio, productos de TI, el
despliegue, la tecnología y las operaciones. Los planes de secuenciación, arquitectura objetivo, y análisis de espacios / transición también
se actualizan para mostrar la finalización del programa / proyecto. Renuncias o bien ser permanentes o pueden ir acompañadas de planes
para el trabajo futuro. Otros resultados pueden influir en las prioridades y dependencias futuros en el plan de secuencia. Estos resultados
proporcionan lecciones aprendidas para la mejora de procesos y forman la base de casos de negocio para otros nuevos programas o
proyectos.
53
6.2.3.3. evaluar los resultados
El EAESC y CIC evaluar los resultados del programa / proyecto para el impacto de la EA y los procesos de negocio de la organización ?? s.
La CPIC Evaluar Fase muestra que la inversión cumple con los objetivos de rendimiento planificados e identifica las razones para la
actualización de la EA. Después de considerar los resultados de impacto a la EA, los trastornos que pueden haber exigido una exención
pueden resultar suficientemente dominante como para justificar la alteración de la EA para dar cabida a las futuras propuestas de inversión
con requisitos similares.
6.3. Otros usos de la EA
La EA proporciona información de guía y fuente de los requisitos de los analistas, diseñadores, ingenieros y planificadores de prueba para
hacer referencia y construir sobre material de la ejecución de sus responsabilidades. Los siguientes son ejemplos de usos de la EA fuera
del ciclo normal de proyecto:
• Incluso si una agencia no está involucrado en una importante actualización de TI, la EA es un recurso para la gestión de inventario,
mantenimiento de rutina y las consultas. Análisis de la arquitectura de línea de base puede identificar oportunidades para la
consolidación de los servicios de red, flotante o sitio software, licencias y economías de escala para equipos y servicios.
• La agencia puede utilizar la EA como una ayuda a la formación, a partir de sus gráficos y material descriptivo para la
instrucción en el negocio de la agencia o de la tecnología que está en uso o planificada.
• iniciativas de investigación y pruebas de concepto deben llevarse a cabo utilizando la EA como referencia. Los criterios para el
cumplimiento de EA deben ser considerados, pero no es obligatorio, en tales esfuerzos. La no aplicación permite la búsqueda
de innovaciones que podrían cambiar la EA, pero el alineamiento y el impacto de las desviaciones de arquitectura debe ser
incluido con los resultados de los experimentos.
• Las agencias pueden financiar proyectos de riesgo pequeños de baja fuera de la CPIC. gerentes de programas / proyectos
aún deben confiar en la EA como guía para la solución de negocios, arquitecturas, requisitos, y el diseño de su esfuerzo.
El cumplimiento de la EA facilitará la integración en la empresa, y la arquitectura de línea de base debe mantenerse al día
con sus productos.
• proyectos de operación y mantenimiento se basan en la arquitectura de referencia para el contexto. Las prioridades y decisiones de
operación y mantenimiento pueden ser influenciados por las arquitecturas plan de secuencia y de destino. Por ejemplo, un planificador
puede concluir que los sistemas de TI pronto-a-ser retirados-son más económicos con O mínimo y soporte M.
54
7. Mantener la arquitectura de la empresa
La EA es, por definición, un conjunto de modelos que describen colectivamente la empresa y su futuro. Su valor a las operaciones de
negocio es algo más que la gestión de decisiones de inversión de TI. La EA es la herramienta principal para reducir el tiempo de
respuesta para la evaluación del impacto, el análisis de equilibrio, la redirección de plan estratégico, y la reacción táctico. En
consecuencia, la EA debe mantenerse al día y reflejar la realidad de la organización de la empresa ?? s. A su vez, la EA necesita
mantenimiento regular y el mantenimiento ?? un proceso tan importante como su desarrollo original.
El mantenimiento de la EA debe llevarse a cabo dentro de los mecanismos de la estructura de aplicación y control de la
configuración de la organización. EA mantenimiento es responsabilidad del CIO, arquitecto jefe, y el EAPMO. El uso de un sistema
de procesos de supervisión y verificación independiente, el equipo central de la arquitectura evalúa periódicamente y se alinea la
EA a las prácticas cambiantes de negocios, perfiles de financiación, y la inserción de la tecnología. La EA debe permanecer
alineado a proyectos de modernización de la organización ?? s y viceversa. La gestión controla para llevar a cabo el mantenimiento
de EA son los mismos establecidos para iniciar el programa y el desarrollo de la EA.
7.1. Mantener la arquitectura de la empresa a medida que evoluciona la empresa
Si el EA no se mantiene al día, que se convertirá rápidamente ??

???? shelfware otro plan bienintencionado para la mejora de la
empresa. Tal vez aún más perjudicial, si el EA no puede encarnar
s estrategia más reciente de la agencia ?? puede limitar la
capacidad de la organización ?? s para cumplir con sus objetivos
y lograr su misión. La EA requiere una estructura organizativa y
proceso específico que asegurará la moneda de contenido de EA
en el tiempo. La EA debe reflejar el impacto de los cambios en
curso en función del negocio y de la tecnología en la empresa, ya
su vez, apoyar la planificación del capital
y gestión de inversiones en continuar con esos cambios. En consecuencia, cada componente de la arquitectura de la EA ?? línea de
base, arquitectura objetivo, plan de secuenciación, y todos los productos que los constituyen ?? necesidad de ser mantenido y se
mantiene precisa y actual.
7.1.1. Reevaluar la arquitectura de la empresa periódicamente
Periódicamente, es necesario volver a examinar la visión que llevó a la organización a este punto y para re-energizar esa visión
dentro de la Agencia. Continuamente, normalmente en conjunción con la CPIC, la EA debe ser revisado para asegurar que:
• La arquitectura actual o base refleja con precisión el estado actual de la infraestructura de TI
• La arquitectura objetivo refleja con precisión la visión de negocio de los avances de la empresa y la tecnología
apropiada que se han producido desde la última versión
• El plan de secuencia refleja las prioridades predominantes de la empresa y los recursos que de forma realista estará
disponible.
55
Una guía práctica para Federal Enterprise Architecture Mantener la arquitectura de la empresa
La evaluación debe generar una actualización de la EA y los correspondientes cambios en los proyectos dependientes. La línea de base
debe seguir reflejando las medidas adoptadas para poner en práctica el plan de secuencia y las medidas tomadas de otro modo para
actualizar el entorno heredado como la organización moderniza. La evaluación y actualización de EA deben ser administrados y programados
a su vez actualizar el plan estratégico y la Agencia proceso de selección de inversiones en el sistema.
7.1.2. Manejo de los productos para reflejar la realidad
Una Agencia es una entidad comercial que permanece sensible a los conductores de negocio (incluyendo nuevas leyes y directivas
ejecutivas), las tecnologías emergentes y las oportunidades de mejora. La EA refleja la evolución de la Agencia, y debe reflejar de
forma continua el estado actual (arquitectura de línea de base), el estado deseado (arquitectura objetivo), y las estrategias a largo y
corto plazo para la gestión del cambio (el plan de secuencia). La Figura 19 ilustra el tipo de cambios continuos que deben ser
ilustrado por el EA. En ningún momento una arquitectura objetivo específico jamás lograrse ?? con cada actualización iterativa de la
EA, los tres componentes que se muestran en la figura y la línea de tiempo se refunden. La arquitectura de destino es una visión del
futuro que evoluciona con antelación de que sea alcanzada.
Arquitectura línea de base

Estado de implementación
plan de secuenciación
Arquitectura de destino
Base Transición Objetivo
Figura 19. Arquitectura de la Empresa Transición
7.1.2.1. Garantizar la Dirección de Negocios y Procesos reflejan Operaciones
Una responsabilidad crítica para el programa de EA es monitorear los cambios en las operaciones comerciales que afectan a la
organización, los procesos de negocio, y la dirección estratégica de la empresa. Los cambios en los procesos de negocio que se iniciaron
mediante la mejora de procesos, cambio organizacional, o mandato, pueden reflejarse en los artefactos de negocio de la arquitectura de la
línea de base. gestión de unidades de negocio y sus PYMES deben informar cambios en sus organizaciones e iniciativas al arquitecto y la
arquitectura del equipo Jefe núcleo. En consecuencia, el arquitecto jefe asegura que el equipo central de la arquitectura está ganando
suficiente percepción de la evolución de las operaciones. Planes y expectativas pueden cambiar a medida que las prioridades cambian con
el tiempo ?? éstos pueden necesitar ser reflejada en las modificaciones a la arquitectura objetivo. turnos de prioridad y las realidades de
56
las limitaciones presupuestarias pueden necesitar ser reflejada en el plan de secuencia. Por lo tanto, el mantenimiento de EA será tanto reactivo
como proactivo.
7.1.2.2. Asegúrese de Arquitectura actual refleja la evolución del sistema
A pesar de la mejor planificación y gestión de los sistemas operativos de mantenimiento, la arquitectura y la infraestructura actual pueden
necesitar cambios imprevistos. A medida que cada nuevo sistema se despliega y cada sistema legado alcanza un hito de mantenimiento (por
ejemplo, la renovación de los contratos de mantenimiento), la línea de base para los actuales cambios de arquitectura. Además, los parches del
sistema deben ser introducidos con frecuencia o cambios en el diseño del sistema implementado para responder a las peticiones de alta
prioridad. Estos cambios deben reflejarse en los actuales artefactos de arquitectura.
7.1.2.3. Evaluar los requisitos de mantenimiento del sistema heredado contra el plan de secuenciación
A medida que la arquitectura actual evoluciona para reflejar la realidad de los sistemas heredados, la nueva información puede emerger que va
a cambiar los planes de mantenimiento y la posterior transición de organización y sistemas. Por ejemplo, los vendedores de sistemas pueden
dejar inesperadamente apoyar los componentes críticos de la infraestructura de la Agencia ?? s. acciones alternativas se deben sopesar las
decisiones y garantiza la sustitución de los componentes, el pago de la ayuda adicional contratista especializado, o el cambio de la estrategia
para la introducción gradual de otros componentes de la arquitectura objetivo. El coste total de propiedad del sistema en comparación con los
sistemas alternativos, así como la externalización, puede ser necesario considerar. Todas estas consideraciones, las alternativas y las
decisiones pueden alterar drásticamente el plan de secuencia.
7.1.2.4. Mantener el plan de secuencia como un Plan de Programa Integrado
El desarrollo del plan de secuencia está vinculada a los procesos de ingeniería de adquisición y de la empresa. El arquitecto trabaja en
colaboración con los directores que entienden los objetivos de negocio en evolución, así como las oficinas de gestión de programas
individuales que supervisan la adquisición y el desarrollo de nuevos sistemas de TI. El plan de secuencia debe ser mantenido, revisado y
validado y aprobado para reflexionar continuamente la misión y visión de la organización ?? s al igual que cualquier producto en el
paquete de la arquitectura y el plan. El plan de secuencia delinea el esquema de administración de TI para la inserción de los sistemas
de apoyo a la organización de las estrategias comerciales a largo plazo ?? s.
7.2. Siga examinando las propuestas de modificaciones de EA
Si bien el proceso de aplicación de la ayuda a asegurar que se sigue la orientación de EA, es razonable suponer que las prioridades
de nuevos negocios y tecnologías, las cuestiones de financiación, o desafíos proyecto no requerirá la modificación de los planes, las
líneas de base, y los productos incorporados en la EA. Las tecnologías emergentes continúan requerir cambios en la empresa.
Muchas de las consideraciones para los cambios en la EA son las mismas consideraciones que deben abordarse durante su
desarrollo. Además, los principios de la arquitectura deben ser abordados de manera continua.
Las propuestas de modificación de la arquitectura debe responder a las siguientes preguntas, entre otras:
• ¿Cómo apoya la propuesta de modificación de la organización en la explotación de TI para aumentar la eficacia de sus
componentes de la organización?
• ¿Cómo afecta el intercambio de información y la interoperabilidad entre los componentes de la organización?
• ¿Cuáles son las implicaciones de seguridad? Por ejemplo, se necesitan las modificaciones certificación de
sistemas mejorados?
57
• ¿El uso modificación propuesta tecnologías probadas y conformes productos COTS para satisfacer los requisitos y
entregar servicios de TI? Son estas tecnologías y estándares relacionados en la corriente principal de la industria, lo que
reduce el riesgo de obsolescencia prematura?
• ¿La aceptación de esta posición propuesta de otras normas o productos para la obsolescencia? Si es
así, identificarlos.
• ¿Cuál es el impacto en la organización y sub-organizaciones si la propuesta no es aceptada? ¿Cuál es el

resultado del análisis de costes y beneficios?
• Lo que se verán afectadas las organizaciones o sistemas externos? ¿Qué medidas se tienen que tomar?
• ¿Cuál es el costo estimado programática general de los cambios propuestos incluyendo cambios a la EA y / o
reorientación de los proyectos dependientes?
• ¿Qué alternativas se han considerado y por qué se recomienda no?

• Lo que prueba, y por quién, se debe completar para implementaciones que resultarán de la aceptación de la
propuesta?
• ¿Cuál es la recomendación de la junta de control de cambios en la empresa? Las propuestas que solicitan modificaciones
a la EA deben abordar estas cuestiones de forma explícita. La propuesta debe ser presentada y revisada por la CVR (para su
revisión por el equipo arquitectónico y PYME) y se pasa al EAESC con una recomendación. En los casos en que la EAESC no puede
llegar a un consenso, un grupo de trabajo puede ser la tarea de investigar y proponer las acciones recomendadas.
58
8. Continua Control y supervisar el programa de arquitectura empresarial
El propósito del control de EA y la supervisión es garantizar que el desarrollo de EA, la implementación y las prácticas de
mantenimiento definidos en esta guía práctica y la orientación EA relacionados referencia en esta guía (por ejemplo, marcos EA) están
siguiendo, y para remediar las situaciones o circunstancias en las que no son y la acción se justifica. El control y la supervisión es una
función continua, realizadas de manera permanente durante todo el proceso del ciclo de vida de EA.
el control y supervisión eficaces es clave para asegurar el éxito del programa de EA. A través de ella, se reúne la información para los
tomadores de decisiones responsables para permitir el conocimiento de si el desarrollo de EA efectiva, implementación y mantenimiento de
las actividades se llevan a cabo y los objetivos del programa de EA se están cumpliendo los plazos y dentro de los presupuestos. Para ello,
el EAESC, el CIO, y el jefe de arquitectura deben estar alerta para medir y validar que se llevan a cabo las normas de procedimiento y
producto de EA definidos y que se hace referencia en esta guía. Para hacer menos, disminuye la probabilidad de éxito del programa.
8.1. Lograr la necesaria controles de gestión del programa de EA están en su lugar y Funcionamiento
En la Sección 3 de esta guía, la rendición de cuentas para el programa de EA fue asignado a la EAESC, el CIO y el arquitecto jefe.
También, a lo largo de esta guía, el proceso de EA y los estándares o controles que se deben utilizar para producir una EA completa,
bien definido, y útil de productos o bien se han definido o se hace referencia. (Por ejemplo, la guía especifica la necesidad de un plan
de gestión del programa al detalle lo que se hará, cuándo y a qué costo, así como la necesidad de establecer las funciones de apoyo
de gestión, como la gestión de configuración, gestión de riesgos, control de calidad, el control de cambios, etc. Además, la guía hace
referencia a los marcos de EA y herramientas que ayudan a definir el contenido de la EA.)
Conocer el grado en que estos controles se están aplicando de manera continua es crucial para mantener el programa en la
pista. Para ello, EAESC, el CIO y el arquitecto jefe buscarán respectivamente informes (orales y escritas, de rutina y ad hoc,
formales e informales) y llevar a cabo primeras revisiones de mano para obtener el nivel adecuado de visibilidad de lo que está
ocurriendo en el programa de vis-à-vis lo que se espera. Es responsabilidad de estas entidades responsables de definir qué
información necesitan, cuándo y con qué frecuencia lo necesitan, cuál debe ser la forma y contenido de la información, si debe
o no validado de forma independiente, etc. A través de esta información, la EAESC , el CIO, y el jefe de arquitectura pueden
posicionarse para saber si los controles de gestión de programas establecidos están en su lugar y funcionamiento.
8.2. Cuando se identifican las expectativas del programa de EA no se están cumpliendo
A través de sus respectivos informes y actividades de revisión, el EAESC, el CIO y el arquitecto jefe serán capaces de identificar lo que, en su
caso, no se están cumpliendo las expectativas del programa de EA. Por ejemplo, si la gestión de riesgos se ha implementado de manera
efectiva, las listas de riesgo del programa deben ser generados con regularidad que asignar un nivel de riesgo en función del impacto y
probabilidad, definir estrategias de reducción del riesgo, informe sobre los avances en la implementación de estas estrategias, y si el progreso
realizado con éxito es abordar el tema del riesgo. También, auditorías de configuración periódicas deben llevarse a cabo para asegurar que los
elementos de configuración EA se están definiendo, controlados, y reportados. El arquitecto EAESC, CIO, y el jefe también puede depender de
las revisiones independientes de la función de garantía de calidad o un agente de verificación y validación para informarles de las desviaciones
de las expectativas.
59
Estas desviaciones pueden ser, tales como omisión de las tareas de trabajo relacionadas con el plan de gestión del programa, los retrasos en la
finalización de las tareas de trabajo, o los costos adicionales para completar las tareas de trabajo; o pueden ser la gestión de la
función-relacionados, tales como no seguir los procedimientos de control de cambios, que no se adhiere al marco AE seleccionada, o no participar
PYME y los propietarios de dominios dentro de las áreas comerciales y técnicas.
8.3. Tomar medidas apropiadas para abordar las desviaciones
La administración debe tomar medidas rápidas y decisivas para corregir problemas en función de las prioridades establecidas. Ejemplos de
acciones incluyen la inyección de recursos adicionales (personas, herramientas o dinero), el establecimiento de planes de contingencia, y la
redefinición del propósito y alcance de EA, la introducción de falta o fortalecimiento de los mecanismos de control existentes, y una mayor
supervisión.
Cualquier cambio en los planes, proyectos y contenidos o / Arquitectura para hacer frente a las desviaciones deben ser capturados en
una pista de la documentación apropiada, y deben justificarse sobre la base de los costos, beneficios y riesgos. Los cambios deben ser
procesados a través de procesos de control de cambio establecidos y autoridad bordo. La documentación cambio debe caracterizar el
problema, solución y alternativas elegidas y rechazadas en función de las prioridades establecidas.
8.4. Asegurar la mejora continua
La figura 20 es una adaptación de una representación tradicional de los factores clave del éxito de la gestión de calidad total (TQM).
Esta cifra representa los mismos factores clave de éxito para architecting la empresa:
• El proceso de EA debe ser un elemento clave de soporte de las operaciones de la Agencia, y debería ayudar a la función
de las operaciones en el desempeño de su misión centrada en el cliente.
• architecting empresa exitosa no es simplemente una función de la organización de TI, pero necesita la participación
total de la empresa.
• la empresa eficaz arquitectura de las necesidades de la sociedad en red ??, ?? es decir, la comunicación y el intercambio de lecciones
aprendidas interna y externa.
El proceso óptimo EA no es un evento único, una sola vez, pero es continua y por lo tanto ofrece la oportunidad de mejora continua.
Para ello es necesario un control continuo con el monitoreo, reevaluación y refinamiento. A medida que la disciplina de architecting
la empresa entra en la corriente principal de operaciones de la Agencia, las lecciones se pueden aprender de los procesos que
funcionaron y las que no funcionan, y de organizaciones externas.
60
Operaciones y de
atención al cliente
Atención
empresa
Architecting
Mejora La
continua participación total
Redes de la sociedad
Figura 20. factores claves de éxito
La participación total responsabilidad hace que la mejora continua a todos ?? s. El papel central de EA ?? s en la evolución de la
empresa proporciona una excelente oportunidad para solicitar comentarios. Las lecciones aprendidas deben ser recogidos de los
propietarios de operación de negocios, equipos de EA, los equipos de desarrollo de proyectos y equipos de gestión de la inversión.
Una vez que la línea de base EA ha sido desarrollado, el equipo de arquitectura debe hacer un balance de las lecciones aprendidas y
comunicarlos a sus colegas y participar alta dirección con el fin de utilizarlos en la mejora del proceso o la propia EA. Además, la
retroalimentación y las lecciones aprendidas deben buscarse de otras agencias, organizaciones profesionales, empresas comerciales y
consultores.
61
62
9. Resumen
Esta Guía Federal de arquitectura de la empresa de desarrollo, mantenimiento y uso ofrece una práctica ?? de cómo hacerlo ?? manual
que ayudará a cualquier agencia federal en la iniciación, desarrollo y mantenimiento de un EA en conjunto con otros procesos de gestión. A
través de un conjunto ilustrativo de cómo ??-a ?? directrices y direcciones, el proceso de EA aparece en el contexto del proceso de gestión
del ciclo de vida empresarial, que consiste en procesos tales como la planificación estratégica integrada, el desarrollo del sistema /
adquisición, planificación y control de la inversión de capital, gestión del capital humano, y la gestión de seguridad de la información.
Aunque destinado principalmente a arquitectos agencia federal, la guía está estructurada para satisfacer las necesidades de todo el
personal de la Agencia, de la cabeza a la Agencia CIO y personal de la organización de línea.
La EA es, por definición, un modelo de empresa de la Agencia ?? s y su dirección futura. Su valor a las operaciones de negocio debe ser
más que una simple gestión de decisiones de inversión de TI. Los cambios dinámicos en la tecnología y las prácticas de negocio imponen
una mayor presión sobre una Agencia para responder más rápidamente a estos estímulos que nunca. La EA es la principal herramienta para
reducir el tiempo de respuesta para la evaluación del impacto, el análisis de equilibrio, la redirección de plan estratégico, y la reacción
táctico.
Aunque EA son requeridos por la dirección legislativa y normativa, deben ser desarrollados y utilizados por otras razones, también. Junto
con su importancia en el ámbito de planificación de capital y gestión de inversiones, EA proporcionan una instantánea en el tiempo de la
Agencia ?? s activos de negocios y tecnología. Ellos son el modelo para construir sobre la hoja de ruta ?? a sistemas y migración de los
negocios. Ellos ayudan a mitigar los factores de riesgo en la modernización de la empresa, identificar oportunidades de inserción de
tecnología innovadora, y los ejecutivos y gerentes de ayuda en la toma de decisiones clave en todos los niveles de la organización. Y
estos son sólo algunos de los beneficios de mantener una minuciosa EA.
El proceso de EA es a largo plazo, un esfuerzo continuo. Una vez desarrollado, la EA es un ser vivo ?? ?? entidad con muchas partes,
ya sea en forma de un documento, base de datos o repositorio, o página web. Para seguir siendo actual y del valor óptimo, esto ??
arquitectura viva ?? necesita atención continua y mantenimiento. Esto, a su vez, exige un compromiso con la organización de arriba a
abajo, ya que los recursos de la Agencia en el tiempo, el dinero, y la gente debe ser dedicado a la arquitectura de mantenimiento ?? s
para el largo plazo.
Como una Agencia comienza sus esfuerzos de EA, sus defensores arquitectura debe asegurar el compromiso corporativo y aceptación por parte
de los altos ejecutivos y todos los niveles de la organización. Sin la participación de toda la Agencia de arriba hacia abajo, el esfuerzo de la
arquitectura se enfrentará a una lucha cuesta arriba durante gran parte de su existencia. Por lo tanto, las etapas iniciales del esfuerzo de la
arquitectura necesitarán un extenso trabajo ?? obtener el compromiso y el respaldo, conectar a tierra la EA en un marco aprobado, y el
establecimiento de una estructura de arquitectura de funcionamiento dentro de la organización Agencia.
Como uno de los primeros pasos, arquitecto jefe de la Agencia ?? s debe conectar a tierra el esfuerzo de la arquitectura en un marco
establecido, si es posible, como se discute en la Sección 4 de esta guía. Los marcos principales ofrecen ejemplos adecuados, como el
FEAF, TEAF, y del Departamento de Defensa C4ISR Marco de Arquitectura discutido en esta guía, para marcos y metodologías. Como se
ha señalado, una serie de organismos utilizan variaciones de estos marcos. Si estos marcos existentes no cumplen con los requisitos de su
Agencia ?? s, desarrollar su propio marco; Sin embargo, tenga en cuenta también los recursos y el tiempo necesario para hacerlo.
63
Una guía práctica para Federal Enterprise Architecture Resumen
Hay que subrayar una vez más que se debe adaptar el contenido de esta guía para las necesidades de su propia organización ?? s: ??
sola talla no sirve para todos ?? es la regla para el desarrollo y mantenimiento de EA. La orientación de este documento puede ser
utilizado por todas las agencias federales independientemente de su tamaño y recursos, pero esta guía debe adaptarse apropiadamente.
Esta guía no pretende ser el ?? único camino ?? todas las organizaciones deben lograr el desarrollo de EA, sino más bien como una
sinopsis de las mejores prácticas ?? ?? Actualmente se emplea en varias agencias federales y empresas privadas. Por ejemplo, en las
organizaciones más pequeñas, múltiples funciones y responsabilidades pueden tener que ser asumida por un individuo, algunos de los
comités y grupos tendrá menos miembros, y, en general, la participación será en una escala más modesta. La EA en sí, los productos de
arquitectura, y el repositorio de datos asociada debe desarrollarse según sea apropiado para esa organización individual. No todas las
agencias tendrán el mismo nivel de detalle, ni las mismas representaciones gráficas. Sin embargo, todas las agencias tendrán que
asegurarse de que siguen un enfoque de arriba hacia abajo a la definición de sus respectivas arquitecturas, y que, como mínimo, los
puntos de vista de negocio de sus arquitecturas proporcionan una comprensión de toda la empresa de operaciones.
Por último, no sufrir solos! Tomar ventaja de la comunidad de arquitectura de los recursos disponibles ?? s. Una gran variedad de
recursos está a su disposición. Esta guía y varias de las otras referencias discutidas en el documento se pueden encontrar en la página
web del Consejo Federal CIO ?? s en
http://www.cio.gov . Muchos marcos de arquitectura están documentados en un extenso cuerpo de literatura y sitios web. Grupos
permanentes de trabajo se reúnen de forma regular, y hay numerosas conferencias anuales y seminarios sobre el tema. Véase el
Apéndice F para una lista de referencias de documentos relacionados y sitios web.
64
Apéndice A: Funciones y responsabilidades de EA
La matriz siguiente se resumen las funciones y responsabilidades funcionales necesarios para apoyar el desarrollo de EA, uso y mantenimiento.
Si los miembros
(compuesto)
Cabeza Agencia N/A EA establece como una prioridad en todo el Organismo; fleta un
Comité de Dirección Ejecutiva de EA (EAESC); política de
temas que regule el desarrollo, implementación y
mantenimiento de la EA.
Consejo de la inversión de capital (CIC) • Jefes Agencia / Revisa las principales inversiones en tecnología de información
Departamento y sus propuestas finales y toma la decisión final de financiación,
adjuntos selecciona proyectos, monitorea el progreso, y evalúa los resultados
• Jefes de Unidad División / negocio para la toma de decisiones de inversión.
• Alto funcionario de Presupuesto
• Oficial Superior de
Contratación
• Consejero legal
• CIO
• director de Finanzas
Arquitecto en jefe N/A Selecciona el equipo del proyecto de EA; trabajos con CIO para
desarrollar EA Primer y política de la arquitectura. Supervisa el
desarrollo de EA producto, uso y refinamiento. Sirve como propietario
del repositorio de EA y es responsable de la arquitectura plan de
secuenciación. Depende directamente del CIO.
Director de Información (CIO) N/A Participa y proporciona dirección estratégica a Comité de Dirección
Ejecutiva de EA (EAESC); mejora la comprensión y apreciación de la
cabeza ?? s Agencia para la EA; designa a un jefe de arquitectura;
mercados de los beneficios de un EA en todo el Organismo a otros
ejecutivos de la Agencia y las partes interesadas a través de foros de
colaboración; obtiene el compromiso de participación de los altos
directivos; e introduce medidas de ejecución.
Configuration Control Board (CCB) • Arquitecto en jefe Responsable de supervisar y controlar los cambios en la
• Los propietarios de dominio

EA después del desarrollo inicial.
Administrador de configuración N/A Responsable del mantenimiento y configuración de control de todos los
productos de EA.
Los propietarios de dominio • Los administradores unidad de negocio Proporciona las partes interesadas de alto nivel y el patrocinador
participación; trabaja con equipo de arquitectura en la inserción
normas y renovación, asigna recursos línea de negocio
(expertos en la materia [PYME]) y supervisa la revisión de
productos de arquitectura empresarial.
Arquitectura empresarial altos representantes de todas las Decide la estrategia, planificación y asignación de recursos
Comité de Dirección Ejecutiva organizaciones y relacionados con el desarrollo y la
65
Una guía práctica para Federal Enterprise Architecture Apéndice A: Funciones y responsabilidades de EA
Si los miembros
(compuesto)
(EAESC) misiones operacionales dentro de la mantenimiento de los productos de EA; aprueba la EA inicial;
agencia; puede incluir ejecutivos de alto proporciona dirección estratégica y asegura el apoyo
nivel (por ejemplo, los CIO) dentro de la corporativo; patrocinadores, opiniones y aprueba una
comunidad de negocios estrategia general de gestión de la arquitectura; aprueba
cambios significativos en la EA.
Office Enterprise Architecture • Arquitecto en jefe Provee para la gestión y control de las actividades de EA como
Management Program (EAPMO) • Arquitectura Equipo Central
un programa formal; crea y mantiene el plan de programa de
EA y los planes del proyecto de EA asociados; define las
tareas, recursos y horarios; prevé la gestión de programas,
seguimiento y control del desarrollo de productos de EA y el
mantenimiento.
Equipo de la empresa Arquitectura del • Arquitecto en jefe Responsable del desarrollo y perfeccionamiento de las arquitecturas
núcleo • Arquitecto de negocios empresariales y de aplicaciones y para poblar el repositorio de EA.
• Arquitecto de sistemas Desarrolla requisitos de las normas formales y gestiona los procesos
• Data Architect de arquitectura; proporciona orientación a otros equipos. Proporciona la
• Arquitecto de infraestructura administración de los procesos de EA; funcionarios de la agencia
• Arquitecto de seguridad
influencias de manera que se obtienen los recursos del proyecto /
• consultores de arquitectura de
retenido, las objeciones son adecuadamente manejados, se mantiene
alto nivel
el progreso, y una alta calidad, se establece un entorno de arquitectura
• Escritor técnico
utilizable.
Monitores y mide el efecto arquitectura ?? s en proyectos a

través de mediciones de procesos y productos.
Independiente de validación y Tercero neutral de la Agencia, Lleva a cabo las evaluaciones de la arquitectura de cumplimiento;
verificación del equipo (IV y V) Agencia externo o un contratista proporciona la garantía de calidad comprobación de la información del
programa (costo, horario, y los datos de rendimiento), así como la
correcta aplicación de la metodología de la arquitectura.
Aseguramiento de la Calidad N/A Asegura la calidad de todos los productos de arquitectura; participa en
sesiones de trabajo de arquitectura de productos y comentarios. Informa
directamente al CIO.
Administrador de riesgos N/A Identifica, monitores, controles y toma medidas para mitigar los riesgos
del programa de EA. Informa directamente al CIO.
Experto en la materia (SME) Los expertos del dominio desde dentro de Soporta Arquitecto Jefe y el personal en la documentación de los requisitos
la organización (una de cada unidad de de la misión o de negocio definidas y objetivos relacionados; apoya la
negocio); puede estar suplementado con definición de las políticas que los objetivos de negocio de impacto;
consultores externos Comentarios sobre productos repositorio de EA.
Comité de Revisión Técnica (TRC) • Los propietarios de dominio Evalúa la alineación del negocio, propuestas de solución, y la
• consultores de arquitectura de conformidad técnica; evalúa el cumplimiento arquitectura; evalúa
alto nivel solicitudes de exención / excepción; y lleva a cabo las normas de
• Arquitecto en jefe revisión.
• representantes Agencia /
Departamento técnicos y de
negocio
66
Apéndice B: Glosario
Término Fuente Definición

??¿¿Como es?? Arquitectura TEAF El estado actual de la arquitectura de una empresa ?? s (ver la arquitectura de
referencia).
??¿¿Ser?? Arquitectura TEAF El estado objetivo de la arquitectura de una empresa ?? s (ver la arquitectura de
destino).
Los artefactos arquitectónicos FEAF La documentación pertinente, modelos, diagramas, descripciones

y análisis, incluyendo un repositorio y estándares de referencia y
perfiles de seguridad.
Arquitectura Producto IEEE Std 610.12 La estructura de los componentes, sus interrelaciones, así como los
principios y directrices que gobiernan su diseño y evolución en el
tiempo.
Arquitectura Departamento de Defensa Conjunta 1-02 barUn marco o estructura que representa las relaciones entre todos los
elementos de la fuerza de tema, sistema, o actividad.
Arquitectura John Zachman Un conjunto de artefactos de diseño, o representaciones descriptivas, que

son relevantes para la descripción de un objeto tal que se puede producir a
los requisitos (calidad), así como mantuvo durante el período de su vida útil
(modificar).
Arquitectura Repositorio TEAF Un sistema de información utilizado para almacenar y acceder a la
información de arquitectura, las relaciones entre los elementos de
información y productos de trabajo.
Artefacto TEAF Una representación abstracta de algún aspecto de un sistema, componente o

vista existente o para-ser incorporado. Ejemplos de artefactos individuales son
un modelo gráfico, modelo estructurado, datos tabulares, y la narrativa
estructurada o no estructurada. artefactos individuales pueden ser agregados.
Arquitectura línea de base El conjunto de productos que presentan a la empresa existente, las prácticas
comerciales actuales, y la infraestructura técnica. Comúnmente conocido
como el ?? tal cual ?? arquitectura.
Arquitectura línea de base FEAF Representación de la ?? acumulada como- construido ?? o línea de base de la
arquitectura existente. La arquitectura actual tiene dos partes:
• La arquitectura empresarial actual, que define las necesidades de

negocio actuales que se reunió por la tecnología actual
• La arquitectura de diseño actual, que define los datos de la

implementadas, las aplicaciones y la tecnología utilizados para apoyar las
necesidades de negocio actuales.
Arquitectura de Negocios FEAF Un componente de las arquitecturas actuales y de destino y se relaciona con la
misión y objetivos Federal. Contiene el contenido de los modelos de negocio y se
centra en las áreas y procesos de negocio federales que responden a los
conductores de negocios. La arquitectura de negocio define los procesos
federales de negocio, flujos de información federales, y la información necesaria
para llevar a cabo las funciones de negocio.
Planificación y Control de OMB Un proceso de estructurar la formulación y ejecución del presupuesto y para
Inversiones de Capital (CPIC) asegurar que las inversiones apoyan consistentemente los objetivos estratégicos
Proceso de la Agencia.
67
Una guía práctica para Federal Enterprise Architecture Apéndice B: Glosario

Empresa TEAF Una organización que apoya un ámbito de negocio definida y misión.
Una empresa se compone de recursos interdependientes (personas,
organizaciones, y tecnología) que deben coordinar sus funciones y
compartir información en apoyo de una misión común (o conjunto de
misiones relacionadas).
Arquitectura Empresarial (EA) FEAF / TEAF Una base de información de activos estratégica, que define el negocio, la
información necesaria para operar el negocio, las tecnologías necesarias
para apoyar las operaciones de negocios, y los procesos de transición
necesarios para la implementación de nuevas tecnologías en respuesta a
las necesidades cambiantes del negocio. Se trata de una representación o
modelo.
Arquitectura empresarial John Zachman El conjunto de artefactos primitivos y descriptivas que constituyen la
infraestructura de conocimiento de la empresa.
Política de arquitectura empresarial Una declaración aplicable al desarrollo, implementación y
mantenimiento de la arquitectura de la empresa.
Arquitectura Enterprise Los gráficos, modelos, y / o narrativa que representan el entorno

Products empresarial y el diseño.
Ingeniería de la empresa Un enfoque multidisciplinario para definir y desarrollar un diseño
de sistema y la arquitectura de la organización.
Ciclo de Vida de la empresa TEAF La integración de los procesos de gestión, negocios, y el ciclo de vida de
ingeniería que abarcan la empresa para alinear TI con el negocio.
Marco de Arquitectura FEAF Un mecanismo de organización para la gestión del desarrollo, el

Empresarial Federal (FEAF) mantenimiento y la toma de decisiones facilitado de un EA Federal. El
marco proporciona una estructura para organizar los recursos federales y
para describir y gestionar las actividades federales de EA.
Marco de referencia FEAF Una estructura lógica para la clasificación y organización de la

información compleja.
Sistemas heredados TEAF Esos sistemas existentes y, o bien desplegados o en desarrollo en el inicio de
un programa de modernización. Todos los sistemas heredados se verán
afectados por la modernización, en mayor o menor medida. Algunos sistemas
se convertirán en sistemas de transición antes de que se retiraron. Otros
sistemas simplemente se retiró como sus funciones son asumidas por los
sistemas de modernización. Todavía otros serán abandonados cuando se
vuelven obsoletos.
Metodología TEAF Un enfoque documentado para la realización de actividades de una manera

coherente, consistente, responsable y repetible.
Modelo TEAF Representaciones de información, actividades,

relaciones y restricciones.
Principio TEAF Una declaración de la dirección o la práctica preferida. Principios
constituyen las reglas, limitaciones y comportamientos que una oficina
sea cierta en sus actividades diarias durante un largo período de
tiempo.
principios FEAF Un componente de la dirección estratégica. En términos de la arquitectura

empresarial federal, los principios son declaraciones que proporcionan dirección
estratégica para apoyar la visión federal, guiar las decisiones de diseño, servir
como una
68

desempate en la solución de conflictos, y proporcionar una base para disperso,
pero integrado, la toma de decisiones.
Repositorio TEAF Un sistema de información utilizado para almacenar y acceder a la

información de arquitectura, las relaciones entre los elementos de
información y productos de trabajo.
plan de secuenciación Un documento que define la estrategia para el cambio de la empresa

desde la línea de base actual a la arquitectura objetivo. Se horarios
múltiple, concurrente y actividades interdependientes e incremental
generaciones que evolucionará la empresa.
Metodología de Planificación Arquitectura Empresarial metodología formal para la definición de arquitecturas para el uso de la
EA Spewak Planificación, SH Spewak información en apoyo de la empresa y el plan de implementación de
esas arquitecturas desarrollado y publicado por Steven H. Spewak.
normas FEAF Un componente de la FEAF. Las normas son un conjunto de criterios (algunos
de los cuales pueden ser obligatorio), directrices voluntarias, y las mejores
prácticas. Ejemplos incluyen:
• Desarrollo de aplicaciones
• Gestión de proyectos
• gestión de proveedores
• Operación de producción
• Soporte al usuario
• Gestión de activos
• evaluación de tecnología
• Arquitectura de gobierno
• gestión de la configuración
• Resolución del problema.
Sistema IEEE Std 610.12 Una colección de componentes organizado para llevar a cabo una función
específica o conjunto de funciones.
Ciclo de vida del desarrollo de TEAF De orientación, las políticas y procedimientos para el desarrollo de
sistemas (SDLC) sistemas a lo largo de su ciclo de vida, incluyendo los requisitos, diseño,
implementación, pruebas, implementación, operaciones y mantenimiento.
Arquitectura de destino FEAF Representación de un estado futuro deseado o que se construirá ?? ?? para la
empresa en el contexto de la dirección estratégica. La arquitectura de objetivo
está en dos partes:
• Objetivo Negocio Arquitectura ?? define las futuras necesidades de
negocio de la empresa dirigidas a través de tecnologías nuevas o
emergentes
• Objetivo Diseño Arquitectura ?? define los futuros diseños utilizados para

apoyar las necesidades futuras del negocio.
Componentes EA Representación de un estado deseado para la totalidad o parte de la empresa

transitorias para un hito provisional entre la arquitectura de línea de base y la arquitectura de
objetivo. Un conjunto de tiempo de rodajas de modelos que representan los
incrementos en el plan de secuencia.
John Zachman, 1987 obra clásica sobre los conceptos de arquitectura de sistemas de
Zachman Framework
IBM Diario Artículo información que definen el concepto de un marco y proporcionan una
matriz 6x6 de puntos de vista y perspectivas de arquitectura con productos.
69
70
Apéndice C: Acrónimos
BPR
Reingeniería de procesos de negocio
C4ISR Comando, Control, Comunicaciones, Informática, Inteligencia, Vigilancia y

Reconocimiento Marco de Arquitectura
CASO Computer Aided Software Engineering
CBA Análisis coste-beneficio
CCB Junta de Control de cambio y la Junta de Control de Configuración
CD ROM Disk-Read Only Memory compacta
CIC Consejo de la inversión de capital
CIO Director de Información
CM Gestión de la configuración
CMM ® Modelo de Capacidad de Madurez ®
COE Entorno operativo común
CONOPS Concepto de Operaciones
COTS Comercial-off-the-shelf
CPIC Planificación y Control de Inversiones de Capital
CRUD Crear, leer, actualizar, eliminar
Departamento de Defensa Departamento de Defensa
PUNTO Departamento de transporte
EA Arquitectura empresarial
EAESC Comité de Dirección de Arquitectura Empresarial Ejecutivo
EAPMO Oficina de Arquitectura de Gestión de Programas de la empresa
EIEITC Comité de Tecnología de la Información Empresa Emergente interoperabilidad y
FAWG Grupo de Trabajo Arquitectura Federal
FEAF Marco de Arquitectura Empresarial Federal
FFRDC Fondo Federal de Investigación y Desarrollo Centro
FOIA Acta de Libertad de Información
GAO Oficina de Contabilidad del Gobierno
GPEA Ley de Gobierno de Trámites Eliminación
LCRG Gobierno Resultados Rendimiento Acta de 1993
HTML Lenguaje de marcado de hipertexto
ICAM Computer Aided Manufacturing integrada
ICOM Entradas, Controles, salidas y Mecanismos
71
Una guía práctica para Federal Enterprise Architecture D Apéndice: Ejemplo de arquitectura Productos
IDEF Computer Integrated Manufacturing Aided lenguaje de definición
IEM Matriz de Intercambio de Información
IER Requisito de Intercambio de Información
ESO tecnología Información
IV y V Verificación y validación independiente
KDP Punto de decisión clave (s)
NIST Instituto Nacional de Estándares y Tecnología
O&M Operaciones y mantenimiento
OMB Oficina de Administración y Presupuesto
PMP Plan de Gestión de Programas
PRA Ley de Reducción de Trámites
QA Seguro de calidad
RM Gestión de riesgos
SDLC Ciclo de vida de desarrollo de sistemas
SID Interfaz Descripción del sistema
SME Expertos en la materia)
TEAF Marco Tesoro Arquitectura Empresarial
TISAF Marco Tesoro Arquitectura de Sistemas de Información
TQM Total Quality Management
TRC Comité de Revisión Técnica
TRM Técnica Modelo de Referencia
UML Lenguaje de Modelado Unificado
USAF Fuerza Aérea de los Estados Unidos
WBS Estructura de desglose del trabajo
72
D Apéndice: Ejemplo de arquitectura Productos
D.1. Misión y Visión
La declaración de misión describe la carta de la empresa y el ámbito de trabajo de la empresa tiene que realizar. La
declaración de visión describe los factores críticos de éxito para lograr la misión de la empresa ?? s, incluyendo la
resolución de los problemas clave relacionados con el rendimiento actual de la misión. Las declaraciones de visión cubren
tanto aspectos de procesos de negocio de los aspectos empresariales y de TI.
Un esquema de muestra para este producto de trabajo incluye:
• Declaración de la misión de la organización
• Necesidades del consumidor
• Metas y objetivos de negocio

• Visión de negocio
• Cuestiones críticas para la empresa
• Factores críticos del éxito.
D.2. Diccionario información
Muchos de los productos arquitectónicos tienen una representación gráfica. Sin embargo, no hay información textual en la
forma de las definiciones y metadatos (es decir, datos sobre un artículo) asociados con estas representaciones gráficas. El
diccionario de información proporciona una fuente central para todas las definiciones y los metadatos, incluidos los que
pueden ser proporcionados por conveniencia dentro de otro producto también.
Como mínimo, el Diccionario de la información es un glosario con definiciones de los términos utilizados en la descripción de la
arquitectura dada. El diccionario de información consiste en la información de la tabla de atributos para todos los demás
productos de trabajo. El diccionario de información hace que el conjunto de productos de arquitectura independiente para que
pueda ser leído y entendido como un documento independiente sin referencia a otros documentos.
Cada elemento gráfico marcado (por ejemplo, icono, caja, o de la línea de conexión) en la representación gráfica de un
producto arquitectónico debe tener una entrada correspondiente en el Diccionario de la información. El tipo de
metadatos incluidos en el Diccionario información para cada tipo de elemento dependerá del tipo de producto
arquitectónico del cual se extrae el artículo.
73
D.3. Concepto de Operaciones (CONOPS) Gráfico
El concepto de alto nivel de Operaciones (CONOPS) gráfico es el más general de los productos de arquitectura y
el más flexible en formato. Se tiene la intención de retratar las actividades operacionales de la agencia (de la
empresa) en un solo gráfico. Este gráfico producto de trabajo proporciona una ilustración concisa de los negocios
de la empresa.
El CONOPS gráfico emplea iconos genéricos que se pueden adaptar, según sea necesario, y se utilizan para representar
diferentes clases de actores de la arquitectura. Los iconos se utilizan para representar los nodos (jugadores), misiones,
actividad o tareas, instalaciones, equipos, etc. El CONOPS gráfico muestra la secuencia de actividades e ilustra el flujo de
información. El gráfico también se puede retratar la distribución geográfica de elementos arquitectónicos.
La Figura 21 ilustra la naturaleza tridimensional de la zona de combate militar y los diferentes actores de los
componentes de tierra, mar, aire y espacio del entorno. Los componentes incluyen buques de guerra, tropas de
tierra y los equipos, bases aéreas, las baterías de misiles, aviones, satélites; y sus respectivas líneas de
comunicación también pueden ser retratados.
vector de estado
Figura 21. DoD Battlespace Concepto de Operaciones gráfico
74
Figura 22 capta el entorno operativo del Servicio de Aduanas de los Estados Unidos para el desempeño de su misión de
conformidad con el comercio. La figura muestra la importación de bienes y mercancías en los EE.UU. por mar, aire y tierra
modos de transporte. También muestra la inspección de los bienes y el rechazo de los envíos no válidos o ilegales. El
gráfico representa el desplazamiento de estos bienes a los eventuales consumidores. El gráfico muestra la colección de
derechos, tasas e impuestos y el flujo de ese dinero en el Tesoro de Estados Unidos. Aduanas también capta y recoge un
gran volumen de información estadística en sus puertos de más de 300 de entrada. La conformidad con el comercio
CONOPS gráfico muestra el flujo de esa información al Centro de Datos de Aduanas y de más de 100 otras agencias
gubernamentales.
Reglas y regulaciones
Federal
Importador / Broker
Estadístico
Datos
otro Gobierno
USCS Agencias del Banco de la Reserva
NDC
Las mercancías en el Puerto
consignatarios
Focalización y
Los consumidores
selectividad
Las mercancías despejados
Almacenadas
destruyó Examen e inspección
Perdidas
Los productos rechazados devueltos
Figura 22. Servicio de Aduanas de los Estados Unidos Concepto conformidad con el comercio de Gráfica de Operaciones
75
D.4. Los modelos de actividad y árboles
El modelo de actividad (también llamado Modelo de Procesos de Negocio) describe las funciones aplicables asociados
con actividades comerciales ?? s de la empresa, los datos y / o información que se intercambia entre las actividades
internas (intercambios), y los datos y / o información que se intercambia con otras actividades que están fuera del alcance
del modelo (intercambios externos). Modelos de actividad son de naturaleza jerárquica. Comienzan con una sola caja que
representa la actividad general y con carácter sucesivo a descomponer la actividad al nivel requerido para la arquitectura.
El modelo de actividad capta las actividades llevadas a cabo en un proceso de negocio o de la misión y las entradas, las salidas,
los controles, y mecanismos (ICOM) de esas actividades. Los mecanismos son los recursos que están involucrados en el
desempeño de una actividad. Controles, como la legislación o una regla de negocio, representan limitaciones en una actividad.
Los ICOMS se denominan restricciones de actividad, ya que cada restringe de alguna manera los procesos de negocio que está
siendo modelado. El modelo de actividad puede ser anotado con declaraciones explícitas de las reglas de negocio, que
representan las relaciones entre los ICOM. Por ejemplo, una regla de negocio puede especificar quién puede hacer qué en
determinadas condiciones, la combinación de entradas y controles necesarios, y los productos resultantes.
El Modelo de Actividad identifica el dominio misión de la modelo y el punto de vista reflejado por el modelo. descripciones
textuales de las definiciones de actividad y los flujos de negocios deben ser proporcionados, según sea necesario.
Anotaciones al modelo pueden identificar los nodos (ubicaciones de negocios), donde se desarrollan las actividades o los
costos (reales o estimados) asociados con la realización de cada actividad.
Ciertos modelos de actividad se crean mediante la fabricación IDEF (Computer-Aided Integrado ( yo LEVA) Def inition) técnica de
modelado. En esta técnica, las actividades se cronológicamente relacionados como los flujos de información a través del
proceso. Entradas se muestran entrando en la actividad de la izquierda, mientras que las salidas o resultados de la actividad se
muestran saliendo a la derecha. La Figura 23 proporciona un ejemplo de una Actividad Modelo IDEF. Los mecanismos (quién o
qué realiza la actividad) se muestran como flechas en la parte inferior de la actividad. Estos pueden ser personas, roles,
sistemas, programas informáticos, etc. Las flechas que entran desde la parte superior de las cajas de actividad son los
controles. Los controles son los parámetros que dirigen la actividad, tales como orientación o reglamentos de las
organizaciones superiores, y físico, tiempo, u otras limitaciones de recursos.
76
Restricciones sobre
la actividad
Entradas Recolectar
externas
datos
Procesar De salida (s)
Entrada (s) datos
Diseminar
Datos
Mecanismos (¿Quién
uso de Decisión o
o qué realiza la actividad)
datos acción
Mecanismos (¿Quién
o qué realiza la actividad)
Figura Modelo 23. Genérico IDEF Actividad
Un modelo de actividad también se puede representar en un formato de árbol. Como se muestra en la Figura 24, la actividad de más
alto nivel se representa como el primer nodo en el árbol. Las actividades de más bajo nivel llamados hojas son actividades que no se
descomponen más.
1.0 ACS
1.10 consulta
1.1 Mantener la información del sistema
1.9 Realizar Proyectos

1.1.3 Iniciar un Especiales
1.1.1 Definición de perfiles de usuario Bond 1.3 Procesamiento de manifiesto
1.1.2 Servicio de Información de 1.8 Procesamiento
referencia de ACS ANTIGUA

1.1.1.1 Administración de Aduanas no
participación 1.6
1.1.1.2 gestionar la participación de
1.3.1 Procesamiento de manifiesto 1.3.4 Procesamiento de pasajeros Procesamiento Fiador
Aduanas
Océano Manifiesto
1.3.2 Tratamiento de Aire

1.7 Procesamiento de derechos de propiedad intelectual
Manifiesto
1,5 de reintegro
1.3.3 Procesamiento de tren de
manifiesto
1.2 Importación
Entrada 1.2.1 1.2.6 Procesamiento de
Realización Reconciliación Procesamiento de 1,4 protesta
1.2.1.1 Procesamiento Procesamiento 1.2.4

1.2.1.4 En-Bond
de Datos de Entrada Declaración 1.2.5 Colecciones
Processing
1.2.1.3 Carga
1.2.5.1 Manual 1.2.5.2 proceso de
Procesamiento de liberación
Procesando pago pago electrónico
1.2.1.2 Frontera
1.2.2 Resumen de Entrada
Procesamiento de liberación
del archivo
Procesamiento 1.2.3
Liquidación
1.2.2.1 Entrada
1.2.2.3 1.2.2.4 Procesamiento Visa AD /
resumen de Procesamiento
CVD
Procesamiento
Tratamiento
1.2.2.2 Cuotas
Figura 24. Aduanas de Estados Unidos, ACS, Árbol Actividad
El modelo de actividad puede ser anotado con declaraciones explícitas de las reglas de negocio, que representan las relaciones
entre los ICOM. Por ejemplo, una regla de negocio puede especificar quién puede hacer qué en determinadas condiciones, la
combinación de entradas y controles necesarios, y los productos resultantes.
77
Modelos de actividad pueden ser representados en Unified Modeling Language (UML), un lenguaje de modelado estándar
adoptado por el Grupo de Gestión de Objetos para apoyar orientado a objetos de análisis, diseño y desarrollo. La Figura 25
representa un diagrama de actividad representado en UML.
Especialista entrada Especialista de importación Inspector (Oficina) puerto Inspector
Declara importador de entrada
La revisión y validación de entrada / Manifiesto
entrada / entrada de la revisión
archivos caso Carrier Manifiesto / Revisión Manifiesto
entrada o manifiesto rechazada

sellos inspector
liberación de papel
no hay problemas [de entrada y manifiesta OK]
aceptado
Aviso al importador y Carrier
Aplicar criterios de selectividad

liberar [a la llegada] sostener
Segunda revisión y validación
Entrada / Manifiesto
inspecciona
inspeccionar [a la llegada] mercancías
acción requerida
aprovechar
rechazar
liberar los bienes [OK]
comunicado de sellos
criterios aleatorios o selectividad se reunieron puerto inspector
Aviso al importador y Carrier
Figura 25. Aduanas de Estados Unidos, conformidad con el comercio, UML Actividad Modelo
D.5. Modelo de negocio Caso de Uso
Un Modelo de casos de uso puede describir cualquiera de los procesos de negocio o funciones de los sistemas en función del
foco de los esfuerzos de modelado. Un negocio de casos de uso Modelo describe los procesos de negocio de una empresa en
términos de casos de uso del negocio y los actores comerciales correspondientes a los procesos de negocio y los participantes
en la organización (personas, organizaciones, etc.). El modelo de casos de uso del negocio se describe en casos de uso
Diagramas y especificaciones de casos de uso. Además de representar a la participación empresarial y de proceso, el Diagrama
de casos también puede representar interrelaciones entre casos de uso como incluye y amplía las relaciones. Un Incluye
Relación representa inclusión o contención de casos de uso. Una relación extends representa variaciones o secuencias
alternativas o caminos más allá del curso normal de la acción.
Las siguientes figuras muestran casos de uso y diagramas de Especificaciones para el procesamiento de conformidad con el
comercio de Aduanas. La Figura 26 y la Figura 27 ilustran UML Los diagramas de casos y la Figura 28 muestra un caso de uso de
especificación.
78
TC_UC_37: Establecer cuenta

con Aduanas
Decisión de importar
TC_A1: Importador de TC_UC_8: Declarar mercancías
Grabar
TC_UC_2: Deberes Estimar / pago,

Tasas e impuestos
TC_UC_38: Aduanas de consultas
TC_UC_11: Hacer Inconveniente

Solicitud
TC_UC_10: Protesta del archivo
Figura 26. Aduanas, Comercio Cumplimiento ?? externa, UML Diagrama de casos
Las mercancías declaradas << extend >>

<< include >>
TC_UC_60: Entrada Proceso TC_UC_61: Captura y Revisión

TC_A3: Aduanas de EE.UU.
Información de importación / Envío
<< extend >>
TC_A13: vendedor de entrada
inspeccionar las mercancías

TC_A15: Aduanas
inpector
TC_A14: Importación
Especialista
TC_UC_63: Recoge derechos, tasas,

e impuestos TC_A16: OGA
Inspector TC_UC_62:
TC_A14: Importación
<< ex tienden >>
ist especial << include >>
<< extend >>
ry Liquidate Ent: TC_UC_66
Las mercancías Clasifica / Valor: TC_UC_64
<< extend >>
TC_UC_65: Desventaja Proceso

Solicitud del Importador
TC_UC_67: Protesta del Proceso

Importador
Figura 27. Aduanas, Comercio Cumplimiento ?? interna, UML Diagrama de casos
79
TC_A_1.0: Declarar mercancías
1. Visión de conjunto:
El importador del registro proporciona información acerca de una importación intención de Aduanas. Costumbres procesará la información y responder
a las comunicaciones que determina lo que el importador del registro va a hacer a continuación. El importador del registro corrige o completa la
transacción hasta que se sepa que los artículos serán o no serán liberados.
2. información característica
Caso de uso Nombre: declarar mercancías
Propietario: Mary Lou Collins

Versión Fecha de creación: 13 de diciembre de, el año 2000
Fecha última modificación: 19 de de diciembre de, el año 2000
Alcance: Cumplimiento comercial
Nivel: Estratégico
Actor Principal: Importador del registro

Actores secundarios: aduana
Las clases de enfoque: Las mercancías, de entrada, documentos de entrada, licencia, permiso, Visa, notificación de liberación
Evento de disparo: El importador del registro decide importar bienes.

Gol: Recibir la notificación de que los bienes han sido puestos en libertad.
3. Las condiciones previas:
1 Importador del registro ha hecho arreglos de transporte de los artículos.

2 Importador del registro está en buena posición con la aduana, por ejemplo, registrado, con licencia, bo
4. Escenario principal (Ruta normativo)
Paso Acción Descripción

1 Recopilar la información necesaria para una entrada (CF 3461 o 7501)
2 Reunir la documentación requerida por la aduana para acompañar la entrada.
5. Post-condiciones: 1
Aduanas registra la información de entrada

2 Importador de pago Registro ?? s reloj de vencimiento o 10 días para tartas de pago.
3 Bienes disponibles para la portadora para moverlos en los EE.UU.
6. Excepciones Escenario / Variaciones
Paso Variable Las posibles variaciones
1 Información necesaria Aduanas consulta de tarifas, tasas de cambio, números de casos AD / CVD,
4 Método de presentación Amplia gama de manual para alternativas altamente automatizados
7. Información relacionada
Prioridad:
Objetivo de rendimiento:
Frecuencia: Una vez por cada conjunto de elementos que puede ser liberada en un enlace de Ti
determinado por el importador o registro
Súper Caso de uso: Sub Caso de
Uso (s): Dependientes de casos de
uso: Entrada proceso
8. Diferencias arquitectura objetivo
Arquitectura línea de base Arquitectura de destino

Declaración es para una sola transacción de importación Declaraciones estarán asociados a una cuenta de pago de los derechos, tasas e
impuestos.
9. Problemas abiertos
ID de problema descripcion del problema
Figura 28. Aduanas de Estados Unidos, conformidad con el comercio, declaramos mercancías, UML de casos de uso Especificación
80
D.6. clase Modelo
Un modelo de clase es similar a un modelo de datos lógicos. En él se describe la información estática y las relaciones entre la
información. Un modelo de clase también describe los comportamientos informativos. Como muchos de los otros modelos,
sino que también puede ser usado para modelar diversos niveles de granularidad. Dependiendo de la intención del modelo,
un modelo de clase puede representar entidades del dominio de negocio o clases de implementación de sistemas. Un modelo
de dominio de negocios representa información clave del negocio (clases de dominio), sus características (atributos), sus
comportamientos (métodos u operaciones), y las relaciones (a menudo referida como la multiplicidad, que describe el número
de clases participan normalmente en la relación), y cardinalidad ( describe requerida o la participación opcional en la relación).
Cada clase, atributo, y la relación que aparece en el diagrama de clases se especifica o se define en una clase, atributo, o
especificación relación. En el caso de una relación, la especificación describe cómo cada clase participa en la relación.
Especificaciones más elaborada y detalle de la información que no puede ser representado en el diagrama de clases. La
figura 29 ilustra un diagrama de clases UML de negocios de Aduanas.
T_BC_02:
Teléfono
nombre
TradeAgent norte 1
dirección ID
TC_A3: Aduanas de EE.UU.
(De propietario / planificador de
T_BC_08: Comercio casos de uso)
Destinatario
T_BC_01: papel T_BC_04: CommercialContract
ImporterOfRecord
licenseNbr T_BC_06:
T_BC_05:
registrationNbr PurchaseOrder
Factura BlanketPurchaseAgreement
se realiza por isLicensed ()

isRegistered ()
T_BC_07:
En primer borrador completo - 14/12/00
TC_A1: Importador de
Record (de propietario /
planificador de Comercio casos
de uso)
Figura 29. Aduanas de Estados Unidos, Cumplimiento Comercial, Comercial Vista, diagrama de clases UML
81
D.7. Modelo de Estado
Modelos de estado son útiles en la comprensión y en representación complicados negocios o comportamientos del sistema a
través del tiempo. Un modelo de estado se puede utilizar para describir el comportamiento de un proceso específico de negocio,
funcionamiento de los sistemas, la clase de negocios o un tipo de sistema. modelado de estado no es una buena técnica para
describir las interacciones entre los procesos de negocio o clases. Otras técnicas tales como el modelado actividad o modelado
de interacción deben ser utilizados para este propósito.
Un modelo de estado UML comienza con un estado inicial representado como un punto sólido. estados intermedios se representan
como óvalos. El estado final se representa como un punto sólido dentro de un círculo. Las transiciones de estado se representan como
flechas entre los estados. La Figura 30 presenta una muestra Diagrama de estado UML Aduanas.
En espera de Transporte
[Bonded, contratado por el importador] ^ Coge los bienes
transporte
Bienes
llegado
pendientes de actividad ilegal / caducidad determinada

De transporte / bienes incautados
compensación
despejado
En Tránsito
Figura 30. Aduanas de Estados Unidos, conformidad con el comercio, Carrier, Diagrama de estado UML
82
D.8. Diagramas de conectividad de nodos
El diagrama de conectividad de nodo ilustra y describe el negocio de ubicaciones (nodos), el needlines entre
ellos, y las características de la información intercambiada.
El Nodo Conectividad Descripción puede ser producido a tres niveles:
• Conceptual Nodo Conectividad Descripción ?? un producto de trabajo esencial que describe los
prominentes, nodos de alto nivel
• Conectividad lógica Nodo Descripción ?? un producto de trabajo de apoyo que describe el diseño
que detalla todas las categorías y clases de nodos, pero no describe la implementación física o
ubicaciones de los nodos
• Conectividad nodo físico Descripción ?? un producto de trabajo de apoyo que describe la implementación
física y la ubicación de los nodos. Cada needline está representado por una flecha (que indica la dirección del flujo de
información), que está anotado para describir las características de los datos o información. Ejemplos de características
incluyen su contenido sustantivo; medios de comunicación (voz, imágenes, texto y formato de mensaje, etc.); requisitos de
volumen; la seguridad o la clasificación de nivel; oportunidad; y los requisitos para la interoperabilidad de los sistemas de
información. características de intercambio de información se muestran de forma selectiva, o de forma resumida, en este
diagrama y más exhaustivamente en la Bolsa de Matrix Información.
Es importante tener en cuenta que las flechas en el diagrama representan needline s solamente. Cada flecha indica que hay
una necesidad de algún tipo de transferencia de información entre los dos nodos conectados. Hay una relación de uno a
muchos entre needlines e intercambios de información; es decir, una sola needline flecha en el nodo de conectividad
Descripción es un paquete de múltiples intercambios de información individuales. Los intercambios de información
individuales se muestran en la Bolsa de Matrix información.
El diagrama debe ilustrar la conectividad con los nodos externos, es decir, nodos que no son estrictamente dentro del
alcance de la arquitectura, sino que actúan como fuentes importantes de información que necesitan los nodos dentro de la
arquitectura o importantes destinos para la información producida por los nodos dentro de la arquitectura. Estos needlines
externos deben ser etiquetados para mostrar la fuente externa o de destino, así como la información intercambiada.
puntos de vista funcionales / operacionales no están obligados a nombrar instalaciones físicas reales como nodos. puntos de vista
funcionales / operacionales en cambio pueden concentrarse en ?? virtual ?? linfáticos, que podría estar basado en roles de negocio
??. ?? Estos ?? virtual ?? los nodos no siempre serán capaces de integrarse directamente con los nodos reales (físicos) de otras
arquitecturas, pero podrían dar una idea Y sobre esto nodos físicos podrían ser capaces de asumir las funciones representadas.
Un nodo puede representar un papel (por ejemplo, un director de información de la Mesa); una organización (por ejemplo, US Secret
Service); un centro de negocio (por ejemplo, un Centro de Servicio del IRS específica); y así. La noción de ?? nodo ?? También variará
dependiendo del nivel de detalle dirigida por el esfuerzo de la arquitectura.
83
Las organizaciones pueden elegir para representar algunos nodos en términos físicos (es decir, la ubicación geográfica) si estos
nodos están destinados a permanecer ?? constante ?? en el análisis de la arquitectura,
por ejemplo, un esfuerzo para determinar las opciones de comunicación más rentables entre dos instalaciones. Por otro
lado, las organizaciones pueden elegir para representar los nodos mucho más genéricamente, o teóricamente, si toda la
práctica comercial está siendo analizada sin limitaciones impuestas por la arquitectura existente.
Para enfatizar el enfoque del análisis y para garantizar la comparabilidad y la integración a través de los esfuerzos, es importante
que cada organización documento cuidadosamente su uso del concepto de nodo ??".
Las actividades asociadas con un intercambio de información dada deben tenerse en cuenta de alguna manera para
proporcionar vínculos entre cada nodo y las actividades realizadas, y para vincular el Diagrama de conectividad de nodo
con el Modelo de Actividad. Cuando más de un nodo de conectividad Descripción está incluido en una descripción EA, el
equipo de arquitectura debe realizar el mapeo apropiado de conceptual a lógico y / o lógico a niveles físicos.
La Figura 31, la Figura 32 y la Figura 33 presentan ejemplos de nodo Diagramas de Conectividad.
TECS
APIS
SeaCat
AES
OBJETIVOS
PELLIZCOS
ACS
NCAP CAPPS
MATS ESFAS
ATS
AAT
GRIFO
Figura 31. Aduanas, ACS, Sistemas de Aduanas, Diagrama de conectividad de nodo
84
ABI 1a 2a 3a 4a 5a 6a 7a
AMS 8a 9a
Ent Suma /
1b 10 a 11a 12a 13a 14a 15a 17a 16a 18a 19a
EIP
2b ACH 20a
27b Recoger 21a 22a
3b 28b 23a 24a 25a

Entrada
29b LATÓN
4b 30b
Declaración
Cuota
ELVIS
Selección
23b 26a
de carga
Sumsel
31b 14b 32b Líquido
15b Reconcil
ENLACE
33b 17b AD / CVD
Retirarse
Doc Ret
6b 34b Protesta
7b 8b Enlazados
35b 9b 25b Manifiesto
36b Garantía
Interfaces internas ACS

Leyenda:
Leer Gráfico de N2 en el Rev 3 como de: 29
sentido horario Junio / 1500
Figura 32. Aduanas, ACS, N 2 Gráfico
Entonces 2 Gráfico simplemente representa un método alternativo para retratar la conectividad entre nodos operativos
de una empresa. Los nodos de la empresa se muestran como casillas de la diagonal de la carta. El flujo de
información entre los nodos se captura como intersecciones numeradas en los ejes vertical y horizontal. El gráfico se
lee en la dirección hacia la derecha. Por ejemplo, el flujo de información desde el sistema ABI al sistema ACH está
anotado en la 2a marcado intersección (por encima de la diagonal). El otro lado de esa interfaz ?? el flujo de
información desde el sistema de ACH al sistema ABI ?? está anotado en la 2b marcado intersección (por debajo de la
diagonal).
Los detalles o características de cada uno de estos flujos de información se presentan en la información que
acompaña Cambio de Matriz (IEM). Cada interfaz numerada en el Nodo Conectividad N 2 Gráfico se convierte en
una fila en el IEM. El intercambio de información se define a fondo y se describe en la IEM.
85
El Nodo Diagrama de conectividad representado en la Figura 33 ilustra el intercambio de información de alto nivel entre los nodos
principales de funcionamiento de la Fuerza Aérea de los Estados Unidos (USAF). En este nivel de detalle, sólo se ilustran las
conectividades, mínimos esenciales de la misión. Este gráfico es un código de colores para mostrar la conectividad necesaria para las
diversas áreas de la misión de la USAF. Estas zonas de misión y el código de color se presentan como una leyenda en la esquina
inferior derecha de la tabla.
Para: Los rangos de lanzamiento de
FEMA FAA RCC Allied GVT NCA NDOC NASA satélites, NU / CC, AFSPOC y SPADOC No DOD
A: JTF Cmd Ctr, y Teatro

A R0CCs / SOCCs
USTRANSCOM Y AIA OSC NMCC NAVSPOC DOD

USSTRATCOM Cmd Ctrs
cmd Ctr Para SOC, AIA OSC,

cmd Ctr AFSOC Comando ARSPOC
Ctr, y JTF Cmd Ctrs
A: Ctrs de
suministro Transporte Fuerza Aerea Agencias de usuarios
ops
N/T
A: AOC y AFSOC ICBM AFSCN Los sistemas de satélite
AFSPOC
Comando Ctr CC
A: Trans Ctrl Ctrs
LCC
AFFOR A: FAA RCC para la

SPADOC sensores CIA
TACC SATÉLITE
NASA
A: Teatro R/F INTERVALOS DE
para la
Comandos y JTF Rocc / LANZAMIENTO

NASA A: CIO
Movilidad
A: AOC SOCC ADOC
C.A MWC DMA
Instalaciones A: NSA y otras agencias Nat'l
A: NMCC, FAA RCC, Unified CMDS, JTF, JIC, WOC / SOC, AOC, MAJCOM y Teatro
Para: AFFOR R / F & ROCC /
medicas TALCE Cmd Ctrs
DIA
Los transportistas aéreos
SOCC
A: SOFs desplegado, JTF, JIC, y Teatro Cmd AIA OSC
A: TACC
Ctrs
ASOS / AFAC
Servicio
RAMCC CIO A: CIA
AWACS TACP NAIC AFIWC
comerciales
A: AFSOC,
Las unidades de
Desplegado AOC
ABCCC
defensa antiaérea AFSOC, Combate A: Teatro Cmd Ctrs y
A: Trans Cont. Ctrs
NSA A: DIA y DMA
USSTRATCOM C.A nacional Agencias AF MAJCOM Ops

y JSOTF JSTARS A: AOC
Ctrs Centros de Operaciones de Las agencias

A: JTF Cmd Ctr WOC /
Fuerzas servicio AFSOC nacionales
SOC A: AFP OSC la Fuerza Mgmt
A: CRC A: FMO
terrestre y desplegado A: TACC
/ FACP Ctrs A: AF MAJCOMs
cmd Ctr
CRE /
marítimo
FACP Fuentes wx
Declaración de trabajo 16a
maint Ctrs IWSM
Trans Ctrs de
Contratistas
AFSOC
a: AFIWC
Servicio Marítimo Terrestre Y obliga control Ctrs
A: Servicio Aéreo de Defensa y cmd Ctr
Fuerzas aliadas
352 SOG
Agencias de
Para: 352 y 353 Ctrs de
ops Ctrs
logística
SOG, USSOCOM,
JTF Cmd 353 SOG A:
suministro
A: NMCC TACC SOF A / C Operaciones de transporte
Ctr Unidades
(USAF / EE.UU.)
A: AOC
Teatro Cmd SOC A: AFSOC Comando Ctr Sistemas C4I Fuerza Aérea Integrada
A: Multi
usuarios Ctrs Fuerzas Las operaciones de combate Soporte Intel
USSOCOM JSOTF
Para: varios usuarios desplegadas SOF Movilidad Operaciones Misión de Apoyo del
A: AF MAJCOM Operaciones Ctrs, JIC Cmd Ctr
AIA OSC y USTRANSCOM Cmd Operaciones Espaciales Departamento de Defensa y
Ctrs las agencias externas
operaciones especiales Rev 3R, 24
de Julio 95 Conjunto o combinada (operado por AF)
Diagrama de Conectividad Nodo Figura 33. Fuerza Aérea de los EE.UU.
D.9. Matriz de Intercambio de Información
La matriz de intercambio de información documenta los requisitos de información de cambio (IERS) para un EA. IER
expresan las relaciones a través de tres entidades básicas (actividades, nodos de negocios y sus elementos, y el flujo de
información) y se centran en las características del intercambio de información, tales como el rendimiento y la seguridad.
IER identifican quien
intercambios qué información con quién, por qué la información es necesaria, y en qué manera. IER identificar los elementos
de información intercambiados entre los nodos de soporte de una actividad en particular. Se observaron atributos
relevantes del cambio. Los atributos específicos incluidos dependen de los objetivos del esfuerzo arquitectura específica,
pero pueden incluir el tipo de medio de información (por ejemplo, datos, voz y vídeo), la calidad (por ejemplo, la
frecuencia, la puntualidad y seguridad) y cantidad (por ejemplo, , volumen y velocidad).
El IEM puede ser producido a tres niveles:
• Información conceptual Cambio de Matriz ?? un producto de trabajo esencial que describe las
prominentes, intercambios de información de alto nivel entre los nodos prominentes
86
• Información lógica Cambio de Matriz ?? un producto de trabajo de apoyo que describe el diseño que
detalla todas las categorías y clases de intercambios de información, pero no describe la implementación
física de ellos
• Información Física Cambio de Matriz ?? un producto de trabajo de apoyo que describe las
características físicas de la implementación de los intercambios de información.
capacidades particulares como el nivel de seguridad de las comunicaciones también pueden ser capturados para cada
intercambio. Este producto de trabajo hace hincapié en las características lógicas y operativas de la información, es decir,
qué información es necesaria por quién, de quién, y cuándo. Tabla 6 ilustra un ejemplo de una entrada en el IEM lógico
de la EA Servicio de Aduanas. En la tabla, AIS es el sistema automatizado de la información en la fuente y el destino que
envía y recibe el intercambio de información y LISI es el nivel de Sistema de Información de Interoperabilidad. LISI se
escala de cero para una interfaz totalmente manual a cinco para una conexión totalmente electrónico.
Tabla 6. Ejemplo Matrix información lógica de Exchange
No. Fuente información de destinos asociados fuente Destino LISI

Medios de comunicación las
Evento de frecuencia de disparo de
Actividad AIS AIS interoperabilidad de transmisión
Cuestiones
DOT Declaración del Procesamiento Dos campos de datos

Importación de
208a aduana vehículo (Formulario de lanzamiento ACS MVII electrónico 3 Diario que faltan en la
(NHTSA) vehículos
HS-7) de carga transmisión
Mantener Actualizar
Tarifario datos
208b DOT
Aduanas (NHTSA) Sistemas de MVII ACS electrónico 3 los datos Según sea necesario Ninguna
Actualizaciones de datos
Información requeridos
El IEM no pretende ser una lista exhaustiva de todos los detalles contenidos en cada IER de cada nodo asociado con la
arquitectura. Eso sería demasiado detalle para una descripción de la arquitectura. Más bien, este producto de trabajo está
destinado a captar los aspectos más importantes de los intercambios de información seleccionados. Selección de los
detalles importantes de los intercambios de información depende de la finalidad de la descripción de la arquitectura.
El número de intercambios de información asociados con una arquitectura puede ser bastante grande, a pesar de que la matriz no
puede contener todos los detalles acerca de todas las IER. Para ayudar a comprender la naturaleza de los intercambios de
información, los desarrolladores y los usuarios de la arquitectura lo desea, puede ver los datos de la IER ordenados en múltiples
formas, como por misión promover, mediante el nodo, o por atributos. En consecuencia, usando una matriz para presentar información
que es limitante y con frecuencia no es práctico. Una base de datos de hoja de cálculo o relacional es muy adecuado para el formato
altamente estructurado de la IEM. En la práctica, las versiones de copia impresa de este producto deben limitarse a resúmenes de alto
nivel o subconjuntos de particular interés resaltados.
D.10. Organigrama
El organigrama ilustra las relaciones entre las organizaciones o recursos. Estas relaciones pueden incluir la
supervisión, las relaciones de coordinación (influencias y conectividad), y muchos otros, dependiendo de la finalidad
de la arquitectura. Es importante mostrar estos papeles fundamentales y las relaciones de gestión en una arquitectura.
Por ejemplo, las relaciones de supervisión pueden ser diferentes en diferentes circunstancias, que afectarán a las
actividades que se pueden realizar de manera diferente o por diferentes organizaciones. Diferentes relaciones de
coordinación pueden significar que se cambien los requisitos de conectividad. La Figura 34 muestra un ejemplo
genérico de un organigrama.
87
Organización de Relación
nivel superior jerárquica
Coordinación o de
otro tipo
especificado
Segundo nivel de la Segundo nivel de la

organización organización
Tercer nivel de la Tercer nivel de la

organización organización
Figura 34. Organización Genérico Chart
D.11. Interfaz de descripción de sistemas y el diagrama de conectividad
La descripción de interfaz de sistema (SID) representa las asignaciones de los sistemas y sus interfaces a los nodos y
needlines describe en el diagrama de conectividad de nodo. El Nodo Conectividad Descripción para una arquitectura dada
muestra nodos (no siempre se define en términos físicos), mientras que el SID representa los sistemas correspondientes a
los nodos del sistema.
El SID identifica las interfaces entre nodos, entre sistemas y entre los componentes de un sistema, dependiendo de las
necesidades de una arquitectura particular. Una interfaz de sistema es una representación simplificada o generalizada de
una vía de comunicaciones o red, representada generalmente gráficamente como una línea recta, con una etiqueta
descriptiva. Los pares de sistemas conectados o componentes del sistema a menudo tienen múltiples interfaces entre ellos.
El SID representa todas las interfaces entre los sistemas y / o componentes del sistema que son de interés para el
arquitecto.
Las descripciones gráficas y / o textos de apoyo para el SID deben proporcionar detalles relativos a las capacidades de
cada sistema. Por ejemplo, las descripciones de los sistemas de información deben incluir detalles relativos a las
aplicaciones presentes dentro del sistema, los servicios de infraestructura que soportan las aplicaciones, y los medios por
los cuales el sistema procesa, manipula, tiendas, y los intercambios de datos. La Figura 35 representa una muestra SID
Diagrama de Conectividad.
88
internodal Perspectiva
El nodo de borde a borde nodo SISTEMA SISTEMA internodal Perspectiva SISTEMA SISTEMA
1 2 1 2
De sistema a sistema
S SISTEMA S SISTEMA
M M
el nodo A OM 3 Nodo B OM 3 Nodo B
zC zC
rfa S rfa S
Inte M
M el nodo A Inte M
M
SISTEMA CO SISTEMA CO
z z
rfa rfa
1 te 1 te
In In
SISTEMA SISTEMA
2 Interfaz COMMS 2 Interfaz COMMS
Unid
Unid ir ecc
irecc iona
iona l SAT
l SA Inte COM
TCO rfaz
Inte M SISTEMA
rfaz SISTEMA
1
1
Conexión externa Conexión externa
SISTEMA
SISTEMA
El nodo C 4
El nodo C 4
intranodal Perspectiva intrasystem Perspectiva
COMUNICACIONES
TRATAMIENTO SISTEMA 1
NODOS
SISTEMA
DE OTRO
Interfaz
SISTEMA DE OTRO
2
1
CS1 / PS2
SISTEMA componente 1 componente 2
Inte
el nodo A
rfaz
S2
/P
S1 PS
zP 2/
rfa
Inte A OTRO
CS
componente 4 componente 3
2
RED DE COMUNICACIONES
SISTEMA
PROCESAMIENTO
SISTEMA
COMUNICACIONES
1
SISTEMA
2 componente 5
COMUNICACIONES PARA OTRO

RED NODOS
Figura 35. Interfaz de sistema genérico Descripción Diagrama de Conectividad
D.12. Perfil normas
Un Perfil de Arquitectura de Normas es el conjunto de normas que regulan la implementación y funcionamiento del sistema. En la
mayoría de los casos, especialmente en la descripción de arquitecturas con menos de un alcance de todo el departamento, la
construcción de un perfil de Normas consistirá en la identificación de las partes aplicables de documentación de orientación normas
existentes, la adaptación de aquellas porciones de conformidad dentro de la latitud permitido, y llenar los vacíos.
Este producto hace referencia a la arquitectura de las normas técnicas que se aplican a la arquitectura y cómo tienen que ser, o
han sido, implementadas. El perfil es de fase temporal para facilitar un proceso estructurado y disciplinado de desarrollo del
sistema y la evolución. Tiempo de eliminación gradual también promueve la consideración de las tecnologías emergentes y la
probabilidad de las tecnologías actuales y las normas se conviertan en obsoletos.
Un Normas tabla de perfiles (véase la Figura 36) documenta el uso de los siguientes elementos dentro de una empresa:
• normas o tecnologías de la industria
• , departamento, o las normas o tecnologías de la Oficina Federal
• Productos comerciales
• productos federal, departamento o una oficina.
89
Servicio de Área Estándar

Sistema operativo FIPS 151-1 Pub (POSIX.1) IEEE
P1003.2 FIPS Pub 119 (ADA)
Interfaz de usuario del software
Servicios de Ingeniería
Operaciones de cliente o FIPS Pub 158 (X-Window System) Computer
servidor de definición de Interface Humano del Departamento de
de Programación
objetos y Gestión
Defensa Guía de estilo FIPS Pub 158
núcleo Shell y Utilidades Lenguajes (X-Window System) Project Standard FIPS
127-2 bar (SQL) FIPS Pub 152 (SGML) FIPS
Datos de Gestión de la ventana del
Pub 161 (EDI) FIPS Pub 153 ( PHIGS)
Gestión de datos de Apoyar el diálogo de Gestión de
intercambio de datos Intercambio de datos Intercambio
Electrónico de Datos Gráficos
Gráficos
. . .
Figura 36. Normas Tabla de perfiles
D.13. Técnica Modelo de Referencia
Un modelo de referencia técnica (TRM) es una taxonomía que proporciona:
• Un conjunto coherente de áreas de servicio, las categorías de interfaz, y las relaciones utilizarse para hacer frente a
los problemas de interoperabilidad y sistemas abiertos
• entidades conceptuales que establecen un vocabulario común para describir mejor, comparar y
sistemas de contraste y componentes
• Una base (ayuda) para la identificación, comparación y selección de las normas existentes y
emergentes y sus relaciones.
La TRM organiza el perfil Normas y cualquier norma o tecnología documentos de previsiones. También puede organizar la
documentación de la infraestructura tecnológica. Con frecuencia, alguna combinación de los documentos organizados
utilizando la TRM se presentan en un solo documento. La figura 37 muestra las áreas de servicio del Servicio de Aduanas de
Estados Unidos TRM.
Entorno de usuario
Herramientas
estación de trabajo Productividad
Herramientas de análisis
Servicios de aplicación Servicios de datos
App Dev Servicios Gestión de Almacén de Gestión

Bases de datos
Env Web App documento. datos de datos.
Servicios de integración
middleware de flujo de trabajo comunicaciones Intercambio
Área de servicio
Servicios comunes
Sistemas Computación Servidores de

Dominio Red Seguridad
operativos distribuída aplicaciones
Infraestructura Gestión de energía.

Email Almacenamiento Voz
MGMT. tecnologías
Figura 37. EE.UU. Aduanas Technical Reference Model
90
dominios de la tecnología y subdominios se definen junto con papeles clave y puntos de contactos. Una estrategia de Arquitectura Técnica
se establece para cada sub-dominio, con las especificaciones y criterios de selección, que expondrá cómo van a utilizar los productos y
tecnologías. La Figura 38 ilustra la definición de dominio y sub-dominio se utiliza en la estrategia de planificación y como bloques de
construcción para ayudar a la planificación de proyectos. Los componentes se construyen para representar un conjunto de subdominios
que se utilizan conjuntamente para construir un componente funcional de la arquitectura.
Ejemplo
Área de servicio Servicios comunes

Dominio y Sub-dominio ?? definiciones
Dominio Sistemas operativos
?? Los roles clave y los POC
?? Presupuesto
?? criterios
Escritorio de OS / Cliente ?? beneficios
OS Mainframe
Subdominios
Sistemas Operativos de Red App /
Data Server OS
Ejemplo Componentes (colección

funcional de subdominios)
Componentes: Servidor de base de datos
Aplicación / OS Servidor de Datos Estrategia de planificación Subdominio productos
Base Táctico Estratégico Aplicación / OS Servidor de Datos NT, Solaris ...
Estrategia de Planificación subdominio

CA-Datacom,
tos DBMS empresariales
oduc
de pr Oráculo...
te gias
Estra
DBMS Gateways Oracle APPC ...
Base de Datos de Gestión de. Herramientas Oracle conjunto de herramientas ...
Message Oriented
MQ Series ...
middleware
Figura 38. Genérico TRM dominio y subdominio Definiciones y Componentes
91
92
Apéndice E: Principios de la arquitectura de ejemplo
Los siguientes principios de la arquitectura derivan de los muchos principios arquitectónicos identificados en la literatura arquitectura
disponible. Se presentan como un punto de partida en el proceso de la arquitectura. Cada organismo, con las necesidades y
requisitos únicos, primero debe considerar estos, a continuación, modificar, añadir o sustituir esta lista según sea apropiado para
sus propósitos.
1. Arquitecturas deben estar al alcance apropiadamente, planificados, y definen basándose en el uso previsto
de la arquitectura.
Razón fundamental: El esfuerzo de desarrollo de la arquitectura necesita dirección y orientación a satisfacer las expectativas de los usos
específicos de los productos finales de la arquitectura. pueden no ser necesarios modelos detallados para la toma de decisiones de alto
nivel; Del mismo modo, las arquitecturas simples, descriptivos pueden no proporcionar suficiente información para apoyar las decisiones
de ingeniería.
Trascendencia: La arquitectura debe ser generado con un propósito específico y para un público específico para asegurar que cumple
con las expectativas de sus grupos de interés previstos.
2. Arquitecturas deben cumplir con la ley tal como se expresa en los mandatos legislativos, ejecutivos
órdenes, regulaciones federales, y otras normas federales.
Razón fundamental: Las agencias federales deben cumplir con las leyes, normas y reglamentos. Sin embargo, esto no impide
mejoras en los procesos de negocio que conducen a cambios en las políticas y regulaciones.
Trascendencia: Las agencias federales deben ser conscientes de las leyes, reglamentos y políticas exteriores en relación con el
desarrollo de arquitecturas y la recolección, conservación, administración y seguridad de los datos. Los cambios en la ley (Ley
Clinger-Cohen) y cambios en la política (OMB Circular A ?? 130) pueden impulsar cambios en los procesos o aplicaciones
arquitectónicas.
3. Arquitecturas de facilitar el cambio.
Razón fundamental: En el rápido y cambiante entorno, las organizaciones necesitan herramientas para gestionar y controlar su negocio
y crecimiento técnico y el cambio. A medida que el ciclo de vida de desarrollo técnico se acorta, con las nuevas tecnologías sustitución
de los sistemas más antiguos cada 18 meses, las organizaciones requieren una arquitectura global para capturar su diseño de los
sistemas y el entorno operativo.
Trascendencia: El desarrollador de sistemas y el principal arquitecto debe garantizar la coordinación entre las inversiones en
tecnología y prácticas de negocio. Arquitecturas deben utilizarse en la función de evaluación del proceso de planificación de
capital y control de la inversión.
4. arquitecturas empresariales deben reflejar el plan estratégico de la Agencia ?? s.
Razón fundamental: La arquitectura de destino tiene el máximo valor cuando más estrechamente alineado con el plan de la organización
?? s estratégica y otra dirección a nivel corporativo, conceptos, y la planificación.
Trascendencia: La arquitectura objetivo debe ser desarrollado en conjunto con los planificadores estratégicos, así como el personal
operativo. Como los cambios de planes estratégicos, también lo hacen el ambiente futuro y la arquitectura destino.
93
15 de marzo de, de 2002
Una guía práctica para Federal Enterprise Architecture Apéndice E: Principios de Arquitectura de muestra
5. Arquitecturas cambian continuamente y requieren de transición.
Razón fundamental: La organización está en constante evolución hacia su futuro. Como hoy en día ?? s arquitectura transiciones
a la arquitectura objetivo, el objetivo se convierte en la arquitectura de referencia organización ?? s en algún momento en el futuro.
La arquitectura de línea de base se mueve continuamente y transiciones hacia la arquitectura objetivo.
Trascendencia: La arquitectura de destino es un conjunto laminación de productos, representando continuamente el medio ambiente
fuera de años. Como un componente de la planificación estratégica y la gestión del cambio, la arquitectura objetivo capta el entorno
futuro, incluyendo los requisitos de datos y sistemas de transiciones. El plan de secuencia es hoja de ruta de la organización ?? s de la
migración de sistemas.
6. arquitecturas de destino deben proyectar no más de 3 a 5 años en el futuro.
Razón fundamental: ciclos de vida de la tecnología actualmente están en la vecindad de 18 meses, y los nuevos productos de TI
aparecen en el mercado cada 18 meses. prácticas federales de adquisición están alineando a estos cambios rápidos, lo que significa
que una organización ?? s información de futuras necesidades y requisitos de infraestructura técnica están cambiando tan
rápidamente. En consecuencia, nadie puede predecir con exactitud qué prácticas de negocio prevalecerá 10 a 20 años en el futuro y
qué tipo de capacidades y los recursos de TI estará disponible.
Trascendencia: arquitecturas objetivo tendrá que ser revisado y actualizado periódicamente. El plan de secuenciación, que ilustra
puntos intermedios en el tiempo, puede llegar a ser más valiosa que las arquitecturas de destino.
7. Arquitecturas proporcionan procesos de negocio estandarizados y entornos operativos comunes

(COE).
Razón fundamental: Comunalidad mejora la interoperabilidad, reducción de costos, y la convergencia. Por ejemplo, la integración de
los modelos de actividad arquitectónicos y secuencia de funcionamiento Diagramas (en el lado del negocio) y el modelo de referencia
técnica y las previsiones de la tecnología (en el aspecto técnico) ayuda a establecer un COE dentro de las infraestructuras físicas y
lógicas de la organización ?? s.
Trascendencia: El arquitecto de sistemas y el principal arquitecto debe asegurar la coordinación entre las inversiones en
tecnología y prácticas de negocio. Un COE a tierra sobre las prácticas comerciales estándar produce estructuras de datos
mejoradas.
8. productos de arquitectura sólo son tan buenos como los datos recogidos de los expertos en la materia y
los propietarios de dominios.
Razón fundamental: El arquitecto no está investido de la información de la organización. Le corresponde al arquitecto para
recoger la información necesaria arquitectónica de los miembros de la organización que poseen el conocimiento de los procesos
de negocio y la información asociada. Estos expertos en la materia tienden a ser personal operativo, representantes de campo, los
desarrolladores de sistemas, diseñadores de software, etc. Los propietarios de dominio son los directivos responsables de las
áreas de negocio específicas.
Trascendencia: El desarrollo de la arquitectura puede ser un proceso lento, que depende del arquitecto ?? s acceso a
expertos en la materia y los propietarios de dominios. La validez de la arquitectura puede estar limitada por la exactitud de
los datos recogidos. Desarrollo de la
94
arquitectura es un proceso iterativo de la recopilación de datos y de entrevista para obtener la verificación y validez los controles de
los productos arquitectónicos.
9. Arquitecturas de minimizar la carga de la recopilación de datos, optimizar el almacenamiento de datos, y mejorar

acceso a los datos.
Razón fundamental: Los datos, como un activo corporativo, es clave para la visión de una organización ?? s, misión, objetivos, y la rutina
de trabajo diario. La forma más eficiente una Agencia recopila datos, almacena y recupera los datos, y utiliza los datos, el más productivo
de la Agencia. Información es poder.
Trascendencia: Los procesos de negocio son ideales para mejorar la simplificación del flujo y uso de los datos y la información. El
desarrollo de descripciones de conectividad de nodo de arquitectura, Intercambio de información matrices, y otros modelos de
información ayudará en el diseño de sistemas de gestión de datos mejoradas.
10. arquitecturas de destino deben ser utilizados para controlar el crecimiento de la diversidad técnica.
Razón fundamental: La rápida adopción de nuevos e innovadores productos de TI puede conducir fácilmente a la introducción de un
conjunto diverso de productos de TI que no siempre pueden ser totalmente compatible con la infraestructura existente de la empresa.
Esto requiere la selección y aplicación de tecnologías probadas en el mercado.
Trascendencia: La arquitectura objetivo debe ser utilizado en conjunto con la organización planes de inserción del proceso de
revisión de inversiones y tecnología ?? s. Basándose en la arquitectura como un componente integral de la toma de decisiones de TI
ayuda a controlar la introducción de productos incompatibles.
95
96
Apéndice F: Bibliografía
Beckner, SG, y ST Norman, Guía de desarrollo de la arquitectura de la Fuerza Aérea. MITRE Informe Técnico 98B0000074. Colorado
Springs, CO, 1998.
Jabalí, BH La construcción de la empresa Proyectos para arquitecturas de TI. Wiley Press ordenador. Nueva York, NY, 1999.
Cook, MA, Información de la empresa de construcción de arquitecturas: Reingeniería de Sistemas de Información.

Prentice Hall. Upper Saddle River, Nueva Jersey, 1996.
Departamento de Defensa, Grupo de Trabajo Arquitectura C4ISR, DoD C4ISR Arquitectura Framework, Versión 2.0, 18 diciembre de
1997.
Departamento del Tesoro, Jefe de Información del Consejo Oficial, Tesoro Arquitectura Empresarial Marco (TEAF),
Versión 1.0, 3 julio de 2000.
Departamento de Tesoreria, Información del Tesoro Arquitectura de Sistemas de Marco (TISAF), Oficina del Secretario
Adjunto de Sistemas de Información y Jefe de Información, 3 de enero de 1997.
Guía ejecutiva: Medición del rendimiento y la demostración de resultados de inversiones en TI. GAO / AIMD98-89. Marzo de 1998.
Federal Jefe de Información (CIO) del Consejo, Grupo de Trabajo Arquitectura Federal, Arquitectura Guía para la Evaluación de
alineación y, Octubre de 2000.
Director de Información Federal (CIO) del Consejo, Marco de Arquitectura Empresarial Federal (FEAF). La versión 1.1, Septiembre de
1999.
Director de Información Federal (CIO) del Consejo, de planificación de capital y Comité de Dirección de TI,
Prácticas inteligentes en la planificación de capital, Octubre de 2000.
Ley Clinger-Cohen de 1996 (anteriormente, la Ley de Reforma de la Gestión Tecnología de la Información [ITMRA]), Ley Pública 104-106. 10
Feb., 1996
Freedom of Information Act (FOIA). 5 USC §552, modificada por la Ley Pública 104-231, 110 Stat. 3048 (1996).
Ley de Eliminación de Trámites Gobierno (GPEA) de 1998. La Ley Pública 105-277, Título XVII. 21 de Oct
1998.
Ley de reducción de trámites Gobierno (PRA), de 1980, modificado 1996. Ley Pública 104-13, 44 USC Capítulo 35.
Gobierno Resultados Rendimiento Ley (GPRA) de 1993. La Ley Pública 103-58. 16 junio de 1993.
Tecnología de la Información Guía de evaluación de Inversión: Evaluación Riesgos y rendimientos. Una guía para la evaluación de las agencias
federales ?? La inversión de TI toma de decisiones. GAO / AIMD-10.1.13. Febrero de 1997.
97
de marzo de 15, de 2002
Una guía práctica para Federal Enterprise Architecture Apéndice F: Bibliografía
Tecnología de la Información de Gestión de Inversiones: Un Marco para la Evaluación y mejora de madurez.

GAO / AIMD-10.1.23. Proyecto de norma.
Circular OMB A ?? 11. Preparación y presentación de las estimaciones presupuestarias. 19 de julio de 2000.
OMB Circular A ?? 130. Gestión de Recursos de Información Federal. 30 de noviembre de 2000.
Rechtin, E., y MW Maier, La técnica de los sistemas Architecting. CRC Press. Nueva York, NY, 1997.
Sowa, JF, y JA Zachman, Ampliación y formalización del Marco de Sistemas de Información Arquitectura. IBM
G321-5488 publicación. IBM Journal, Vol. 31 (3). 1992.
Spewak, SH, Empresa planificación de la arquitectura. Wiley and Sons, Nueva York, Nueva York, 1992.
Sistemas de Ciclo de Vida de Desarrollo, Manual CEI 5500 ?? 07, Servicio de Aduanas de los Estados Unidos, octubre de 1998.
Thomas, R, II, RA Beamer, y PK Sowell, La aplicación civil del Departamento de Defensa C4ISR Marco de Arquitectura: Un Estudio de
Caso Departamento del Tesoro. Actas de 5 º Comando Internacional de Investigación y Control y Tecnología Simposio, Canberra, Australia.
Octubre de 2000.
Servicio de Aduanas de los Estados Unidos, Empresa Modelo de la configuración, Agosto de 1999.
Zachman, JA Un marco para Sistemas de Información Arquitectura. IBM Systems Journal.

Vol. 26 (3). 1987.
Zachman, JA El Marco de Arquitectura Empresarial: fondo, Descripción y utilidad. 1996.
Enlaces Internet / WEB
Consejo Superior de la Federación de Información

www.cio.gov
Grupo de Trabajo Arquitectura Federal

www.cio.gov/docs/interopeability.html
ArchitecturePlus
www.itpolicy.gsa.gov/mke/archplus/archhome.htm
Ley Clinger-Cohen
www.itpolicy.gsa.gov/mks/regs-leg/s1124_en.htm
Política de la administración Clinton sobre protección de infraestructuras críticas: Directiva de Decisión Presidencial
63, mayo de 1998.
www.ciao.gov/CIAO_Document_Library/paper598.html
Departamento de Defensa Modelo Técnico de Referencia, Versión 1.0 5 de noviembre de 1999.

www-trm.itsi.disa.mil
Departamento del Tesoro CIO

www.treas.gov/cio/
98
Digital Consulting, Inc. (DCI)

www.dci.com
Tecnología de la Información Arquitecturas de toda la empresa (EWITA)

www.ewita.com
Arquitectura Empresarial marco federal, Versión 1, Septiembre de 1999.

www.itpolicy.gsa.gov/mke/archplus/fedarch1.pdf
General Accounting Office, La evaluación de riesgos y devoluciones: Una guía para la evaluación de inversiones de TI toma de decisiones de las
agencias federales, Versión 1, GAO / AIMD-10.1.13, febrero de 1997.
www.gao.gov/policy/itguide/
General Accounting Office, Tecnología de la Información de Gestión de Inversiones: un marco para evaluar y mejorar la madurez del
proceso, Proyecto de Norma, Versión 1, GAO / AIMD-10.1.23, mayo de 2000.
www.gao.gov/special.pubs/10_1_23.pdf
General Accounting Office, Medición del rendimiento y Demostración de los resultados de Tecnología de la Información
Inversiones, AIMD-98-89, marzo de 1998.
www.gao.gov/special.pubs/ai98089.pdf
Administración de Servicios Generales de la Oficina de Tecnología de la Información

www.itpolicy.gsa.gov
IEEE 1471, Práctica Recomendada para descripción arquitectónica, información

PROYECTO garantía técnica Foro Marco
www.iatf.net
Tecnología de la Información del Sistema cartera de inversión (I-TIPS)

www.itips.gov
Los arquitectos Consorcio Internacional de Empresa y Arquitectura Centro

www.ieac.org
MetaGroup, Inc. de Stamford, CT

www.metagroup.com
grupo de administración de objetos

www.omg.org
Circular OMB A ?? 130, Gestión de Recursos de Información Federal, Revisado 30 de noviembre de 2000.
www.whitehouse.gov/OMB/circulars/a130/a130.html
OMB Memorando M-97-16, Información arquitecturas tecnológicas, 18 de Junio 1997.

www.whitehouse.gov/OMB/memoranda/m97-16.html
OMB Memorando M-00-07, incorporando y Seguridad en Sistemas de Información Financiación Inversiones 28 de febrero de 2000.
www.whitehouse.gov/OMB/memoranda/m00-07.html
99
OMB, Revisión propuesta de la OMB Circular No. A ?? 130, en Federal Register, Vol. 65, No. 72, 13 de abril de
2000, páginas 19933-19939
www.whitehouse.gov/omb/fedreg/rev-a130.pdf
Software Engineering Institute (SEI) Arquitectura Tecnología Página

www.sei.cmu.edu
Steven Spewak arquitectura de la empresa Home Page Planificación

www.eap.com
La Universidad de Stanford, Arquitectura Home Page Empresa

www.standford.edu/group/APS/arch/index.html
The Open Group Architecture Framework (TOGAF) Modelo de Referencia Técnica, la versión 5, 1999.
www.opengroup.org/togaf
Servicio de Aduanas de los Estados Unidos, Enterprise Architecture Blueprint, octubre de 1999.
www.itpolicy.gsa.gov/mke/archplus/eab.pdf
Servicio de Aduanas de los Estados Unidos, Guía de Introducción Modelo de Referencia Técnica, agosto de 1999.
www.itpolicy.gsa.gov/mke/archplus/trm.pdf
UML ?? Lenguaje de Modelado Unificado

www.omg.org/uml
Instituto para el Avance Marco Zachman

www.zifa.com
Febrero
100 de 2001
Apéndice G: El Marco Zachman
En septiembre de 1987, John Zachman publicó un artículo importante en el IBM Systems Journal
la identificación de lo que llamó ?? Un marco para la Arquitectura de Sistemas de Información, ?? a veces denominado
simplemente ?? El Marco Zachman ??. En este artículo se ha convertido en un estándar de facto para el desarrollo de la
arquitectura empresarial. De hecho, el Zachman Framework proporciona gran parte de las bases para el FEAF y los marcos de
varios departamentos federales y agencias.
Dos ideas clave se ilustran en el marco Zachman:
1. Hay un conjunto de representaciones arquitectónicas producidas durante el proceso de construcción de una

producto de ingeniería complejo que representa las diferentes perspectivas de los diferentes participantes.
2. El mismo producto se puede describir, para diferentes propósitos, de diferentes maneras, lo que resulta en
diferentes tipos de descripciones.
El Zachman Framework proporciona las vistas detalladas y sólidas necesarias de la arquitectura de la información de la empresa. En él se
esbozan seis vistas cada vez más detallados o niveles de abstracción para seis descripciones de arquitectura. Los niveles de abstracciones
son:
1. El planificador o Ballpark Ver
2. El propietario ?? s o Enterprise Modelo Vista
3. El diseñador ?? s o sistemas de modelos Ver
4. El constructor ?? s o Tecnología Modelo Vista
5. El Subcontratista ?? s o representación detallada Vista
6. La Empresa de Funcionamiento o real del sistema Vista.
Y los seis descripciones de arquitectura ?? y los interrogantes que las que responden ?? son:
1. La descripción de datos ?? Lo
2. La Función Descripción Cómo ??
3. La descripción de la red ?? Donde
4. La gente Descripción ?? Quién
5. El Tiempo Descripción Cuando ??
6. La motivación Descripción ?? Por qué.
En opinión Zachman ?? s, el único factor que hace su marco único es que cada elemento en cualquiera de los ejes de la matriz es
explícitamente distinguible de todos los demás elementos de ese eje. Las representaciones en cada celda de la matriz no son niveles
meramente sucesivas de aumento de detalle, pero en realidad son diferentes representaciones ?? diferente en su contexto, es decir, la
motivación, y uso. Debido a que cada uno de los elementos en cualquiera de los ejes es explícitamente diferente de los demás, es posible
definir con precisión lo que pertenece en cada celda.
La Figura 39 ilustra el Marco Zachman en un formato de matriz de 6x6. Los seis puntos de vista o niveles de abstracción son las filas de
la matriz, mientras que las descripciones arquitectónicas ?? las respuestas a la
101
Una guía práctica para Federal Enterprise Architecture Apéndice G: El Marco Zachman
interrogativos de la empresa ?? son las columnas. Cada una de las 36 celdas de la matriz representa un modelo o arquitectura del
producto descriptivo que forman los bloques de construcción de la EA.
DATOS Qué FUNCIO Cómo NETWOR Dónde peopl Quien HORA Cuando MOTIVATIO Por qué
SCOP Lista de procesos de Lista de Ubicaciones en el Lista de Lista de Eventos SCOP

(CONTEXTUA negocio negocio Importante para el al
(CONTEXTUA
planne ENTIDAD = Clase Función = Clase Business Nodo = Locatio Mayor Termina / Medios = Mayor autobús. Éxito planne
Personas = Mayor Tiempo = Mayor de negocios
Business crítico
por ejemplo Semántica Proceso por ejemplo Negocio por ejemplo Negocio por ejemplo, flujo de trabajo por ejemplo, Maestro por ejemplo Negocio Enterpris
Conceptua MODO
MODO (Enterpris comercial de las cosas a la
(CONCEPTUAL
= Lista comercial de negocios
owne owne
Ent = Negocio Reln = Lista Proc. = Negocio de E / S = Nodo = Business Link = Personas = trabajo = Organización Tiempo = = Ciclo de
Negocio Negocio Trabajo Negocios Negocio
por ejemplo lógica de datos por ejemplo, la solicitud por ejemplo Distribuido por ejemplo humano por ejemplo, procesamiento por ejemplo, reglas de negocio MODO
MODO acción final = negocio significa
Architectur SYSTE
SYSTE
(lógico)
(LÓGICO
Nodo = E / S (procesador,
Designe
Ent = Data = Datos Aplicación almacenamiento, Link = Línea Personas = Sistema de sucesos Fin = medios estructurales = Designe
Reln I / O = Proc usuario. = trabajo = Ciclo = tiempo de procesamiento =
MODO por ejemplo, datos físicos por ejemplo Sistema por ejemplo, Tecnología por ejemplo Presentación por ejemplo, control por ejemplo, la Regla TECHNOLOG
TECHNOLOG MODO
(FÍSICA
(FÍSICA
Nodo = Softwar Enlace = builde

builde Ent = Reln Ordenador Personas = trabajo = Fin = =
= E / S = Datos Proc. = Línea Pantalla Ciclo = componente de tiempo = Medios
detaile represen por ejemplo, datos p.ej por ejemplo, la Red por ejemplo, de Seguridad por ejemplo Timing por ejemplo, la Regla
detaile
represen
CIONES
(FUERA- (CONTEXTO
DE-OUT
sub
sub
Contracto = = Terminar
Ent = Reln Nodo = = Personas =
Contracto
= I / O = Control Proc. = Idioma Enlace trabajo = Ciclo = = Time Machine SubMeans
Enterpris FUNCTIONIN
FUNCTIONIN p.ej p.ej por ejemplo Architectur p.ej p.ej p.ej
Enterpris
John A. Zachman, Zachman Internacional (810) 231-0531
Figura 39. El Zachman Marco Matrix
Para más lecturas e información más detallada sobre el Marco Zachman, por favor referirse a cualquiera de las publicaciones
John Zachman ?? s, el Instituto de Zachman Marco Avance (ZIFA) sitio web (http://www.zifa.com), y un número de
publicaciones de otros autores tales como texto Melissa A. Cook ?? s, Edificio de información empresarial Arquitecturas:
Reingeniería de Sistemas de Información,
Prentice Hall, Upper Saddle River, Nueva Jersey, 1996. Véase el Apéndice F para obtener una lista de recursos relacionados.
102

Guia Practica para EA

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Guia Practica para EA

Uploaded by

Copyright:

Available Formats

Una guía práctica

Arquitectura Empresarial Federal

Jefe de Información del Consejo Oficial

1 Ley Pública 104-106, Sección 5125, 110 Stat. 684 (1996).

La necesidad de esta Guía

Servicio de Aduanas de los Estados

(GAO / AIMD-10.1.23, Proyecto de Norma, 2000).

Nombre Título Agencia

Elaine Ward, Ingeniero principal La Corporación MITRE

scott Bernard Consultor en administración Booz-Allen & Hamilton, Inc.

Thomas P. Cullen analista de Políticas Servicio de Aduanas de EE.UU.

William Lew Subdirector Técnico General Accounting Office

Barbara de Scott analista de gestión Departamento de Educación de EE.UU.

Paul J. Paradis analista de gestión Departamento de Energía de EE.UU.

naba Barkakati Subdirector Técnico General Accounting Office

1. Introducción................................................. .................................................. ...................................... 1

1.3. Audiencia ................................................. .................................................. .................................. 1

1.5. Como usar esta guia............................................. .................................................. ................. 3

2. Definiciones, controladores y Principios .......................................... .................................................. ...... 5

2.1. Empresa arquitectura definida ............................................... .................................................. 5

2.3. Legislación y otras Orientación .............................................. .................................................. 6 ..

2.5. El Ciclo de Vida Empresa .............................................. .................................................. ........... 8

3. Programa de iniciar Arquitectura Empresarial .............................................. ........................................ 11

3.1. Ejecutivo obtener la aceptación y apoyo ........................................... ........................................... 11

3.3. Arquitectura Empresarial Programa de Actividades y Productos ............................................ ............ 17

4. Definir un proceso de Arquitectura y enfoque .......................................... .................................... 21

4.4. Seleccionar los productos adecuados EA .............................................. ................................................. 23

4.5. Evaluar y seleccionar un marco ............................................. ................................................ 24

4.5.2. DoD C4ISR arquitectura marco .............................................. ............................ 27

5. Desarrollar la arquitectura de la empresa ............................................ .................................................. 33

5.2. Generar productos y poblar EA Repositorio ............................................ ........................... 35

5.4. Aprobar, publicar y divulgar los productos de EA ......................................... ...................... 41

6. Uso de la arquitectura de la empresa ............................................ .................................................. ........ 43

6.1. Integrar la EA con CPIC y Procesos SLC .......................................... ............................. 43

6.2. Ejecutar el Proceso Integrado .............................................. .................................................. . 47

7. Mantener la arquitectura de la empresa ............................................ ................................................ 55

7.2. Siga examinando las propuestas de EA Modificaciones ........................................... .................. 57

8. continuamente el Control y supervisar el programa Enterprise Architecture ................................. 59

8.4. Asegurar la mejora continua ............................................... ............................................... 60

9. Resumen ................................................. .................................................. ........................................ 63

Apéndice A: Funciones y responsabilidades EA ........................................... ................................................ sesenta y cinco

Apéndice B: Glosario .............................................. .................................................. ............................... 67

Apéndice C: Acrónimos .............................................. .................................................. ............................ 71

Apéndice D: Ejemplo de arquitectura Productos ............................................ ............................................ 73

D.1. Las declaraciones de misión y visión .............................................. .................................................. . 73

D.2. Diccionario información ................................................ .................................................. ........... 73

D.4. Los modelos de actividad y árboles .............................................. .................................................. ........ 76

D.5. Uso empresarial Modelo Caso .............................................. .................................................. ......... 78

D.6. Clase Modelo ................................................ .................................................. ............................ 81

D.8. Diagramas de nodo de conectividad ............................................... .................................................. ... 83

D.9. Matriz de Intercambio de Información ............................................... .................................................. 86 ..

D.10. Organigrama................................................ .................................................. .................. 87

D.12. Perfil normas ................................................ .................................................. ..................... 89

Apéndice E: Ejemplo de principios de la arquitectura ............................................ ........................................... 93

Apéndice F: Bibliografía .............................................. .................................................. ........................ 97

Apéndice G: El Marco Zachman ............................................ .................................................. 101

Figura 1. Función de los Principios de Arquitectura ........................................... .................................................. ....... 7

Tabla 1. Funciones y responsabilidades EAPMO ........................................... .................................................. 17

1.4. Organización del documento

El documento está organizado de la siguiente manera:

Sección 1: Introducción Define el propósito, alcance, el público y

Sección 4: Definir un proceso de Define un proceso para la construcción de una arquitectura

Sección 5: Desarrollar la Proporciona los pasos de procedimiento para el desarrollo de arquitecturas de