1. No category

CISS/CAOSA/WP/05/03
Uso Oficial
Conferencia Interamericana de Seguridad Social
Inter-American Conference on Social Security
13-Abr-2005
Español Or. Inglés
Cómo Mejorar la Arquitectura Administrativa y
Tecnológica de las Instituciones de Seguridad Social
en América
(Manual para Edificar una Arquitectura de la Empresa)
13 de abril, 2005
Para comentarios y sugerencias favor de contactar a Adriana Valle al correo electrónico
[email protected]
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
1
CISS/CAOSA/WP/05/03
I.
Introducción
Una Arquitectura de la Empresa (AE) constituye una guía básica para cualquier
organización que pretenda lograr su misión respectiva a través del óptimo desempeño de
sus procesos operativos centrales, dentro de un contexto eficiente de tecnologías de
información. La Arquitectura de la Empresa puede ser definida como un activo estratégico
para generar la información necesaria y para adoptar y adecuar las tecnologías requeridas
en la operación de la empresa, así como para fomentar el desarrollo de aquellos procesos
transitorios, indispensables en la implementación de nuevas tecnologías que respalden las
necesidades de cambio de la empresa en cuestión. El principal propósito de una AE es el
de informar, guiar, y restringir las decisiones de la empresa, en particular aquellas
relacionadas con las inversiones en tecnologías de información (TI).
La evolución de una arquitectura de TI puede seguir un proceso ordenado e incluso
fungir como base para las instituciones de seguridad social de cualquier tamaño, sin
importar su actual estatus en la curva de modernización. Así pues, el propósito de este
documento es describir las etapas que caracterizan el proceso de edificación de la AE. En
ese sentido, una ejecución satisfactoria del proceso de AE implicará un esfuerzo concreto
en materia de administración, asignación de recursos, continuidad del proyecto y
coordinación. Este manual retoma la Guía Práctica para la Arquitectura de la Empresa
Federal que publicó el Consejo Federal de Jefes de Informática del gobierno de los Estados
Unidos.
El interés de este documento radica en proveer a las instituciones de Seguridad
Social una explicación concreta de los procesos necesarios para desarrollar un programa
de AE. Asimismo, el documento pretende, primero, facilitar la información que requieren
los funcionarios de alto nivel encargados de tomar decisiones determinantes, sin caer en
un debate técnico innecesario; segundo, proveer el material adecuado para los distintos
programas de capacitación sobre el tema; y tercero, fungir como punto referencia y de
comparación para los administradores interesados. Un documento complementario al
presente plantea la importancia de la existencia de una AE, así como su relación con la
transformación organizacional de cualquier institución, y expone distintos casos de
estudio.
II.
Antecedentes
El concepto de Arquitectura de la Empresa adquirió importancia a partir de los
múltiples fracasos observados en los distintos proyectos de TI que se llevaron a cabo en
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
2
CISS/CAOSA/WP/05/03
las décadas de los ochenta y noventa. Desde entonces, el gobierno estadounidense se
percató de la importancia de que las instituciones federales contaran con una AE para
minimizar, e incluso evitar, el riesgo asociado a la compra o edificación de sistemas de TI
duplicados, incompatibles e innecesariamente costos, y que por lo mismo implican una
difícil manutención e integración. Por ende, en 1996, el Congreso de los Estados Unidos
promulgó la Ley Clinger-Cohen con el fin de forzar a los Jefes de las Oficinas de
Informática de las distintas Instituciones Federales a promover tanto el desarrollo como la
manutención de sistemas de TI integrados. Así pues, a finales de los noventa, se creó el
Programa de la Arquitectura de la Empresa Federal (AEF) con el propósito de establecer
criterios
homogéneos
para
el
desarrollo
y
la
adquisición
de
sistemas
de
TI.
Posteriormente, en febrero de 2002, inició el desarrollo de dicho programa con la
intención de definir y alinear las funciones de toda dependencia federal, así como proveer
el soporte necesario en TI mediante el establecimiento de modelos comunes. En ese
sentido, fue necesario identificar las oportunidades y circunstancias posibles para
reutilizar y redistribuir los activos de TI a través del gobierno federal y, por ende, reducir
el gasto en TI. En suma, el objetivo fundamental de toda arquitectura de la empresa es
proveer un servicio más orientado al ciudadano, maximizar las inversiones en tecnología e
impulsar el cumplimiento de las distintas misiones de cada una de las instituciones
federales.
III.
Inicia el Programa de Arquitectura de la Empresa
El primer paso en el establecimiento de la arquitectura de la empresa debe ser la
constatación, por parte de cada institución interesada, de la necesidad de desarrollar una
AE y, por ende, la formulación de una estrategia que incluya la definición de principios,
enfoques y objetivos. La Gráfica 1 muestra una posible representación del proceso de AE.
Gráfica 1
El Proceso de Arquitectura de la Empresa
Lograr
Participació
n y Apoyo
Establecer
Estructura
Administrativa
y de Control
1
2
Definir un
Proceso de
Arquitectura y
Una Estrategia
3
Desarrollar
la Arquitectura
de Arranque de
la Empresa
Desarrollar
la Arquitectura
Objetivo de
la Empresa
4
5
Desarrollar
El Plan de
Secuencia
6
Utilizar la
Arquitectura
de la Empresa
7
Mantener la
Arquitectura
de la Empresa
8
Fuente: CIO (2001).
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
3
CISS/CAOSA/WP/05/03
Las primeras dos etapas del proceso característico de AE corresponden a la
búsqueda de participación y apoyo así como al establecimiento de un equipo de
administración y monitoreo del mismo proceso. Una vez establecido, dicho equipo se
encargará, primero, de bosquejar el proceso de arquitectura y de formular la estrategia
asociada al mismo, segundo, de desarrollar la arquitectura de arranque de la empresa y,
tercero, de desarrollar la arquitectura objetivo de la empresa, funciones que corresponden
a las etapas III, IV y V respectivamente. Ambas arquitecturas incorporan el conjunto de
productos que representan tanto a la empresa actual (de arranque) como a la futura
(objetivo). En efecto, la arquitectura de arranque, que suele ser conocida como la
arquitectura “Tal-Cual” o “Como es”, describe la infraestructura técnica y las prácticas
operativas actuales. En cambio, la arquitectura objetivo, o arquitectura “A-Ser”, describe
las prácticas asociadas a la empresa futura o al final del proceso. Más adelante, en la etapa
VI, el equipo deberá encargarse asimismo del desarrollo de un plan de secuencia para la
transición de los distintos sistemas, aplicaciones y prácticas de operación que están
interrelacionados. Así pues, una vez establecida, la arquitectura de la empresa será
empleada en la planeación del capital y el control de la inversión (PCCI), función que
corresponde a la etapa VII, de tal manera que tanto la ingeniería de la empresa como la
administración del programa promuevan y adecuen la inserción de nuevas tecnologías.
Finalmente, la etapa VIII constituye el mantenimiento de la arquitectura a través de la
constante incorporación de objetivos, metas organizacionales, visiones, tecnologías,
infraestructura y prácticas operativas vigentes de arranque.
Cabe destacar que el proceso de AE implica un esfuerzo continuo, una vez que el
equipo logró migrar de manera exitosa de la arquitectura de arranque a la arquitectura
objetivo. En efecto, la dinámica asociada a los requerimientos operativos así como la
disponibilidad de nuevas tecnologías determinarán la redefinición de una nueva
arquitectura y, por ende, el reinicio del proceso de migración. En otros términos, la
arquitectura de la empresa se reinventa constantemente.
Etapa 1.
Obtener Participación y Apoyo
Es importante considerar que, una vez establecida la dirección del cambio, la
transformación del funcionamiento interno de la vieja organización hacia una moderna
arquitectura
TI-AE
implicará
un
esfuerzo
colectivo.
Aunque
solía
considerarse
erróneamente a la tecnología como la causante de dicha transformación, es la forma en
que la organización opera la que en realidad constituye el verdadero propulsor para lograr
una arquitectura moderna. Ahora bien, si los especialistas en tecnología logran incorporar
estos cambios, las posibilidades se multiplican. En efecto, los distintos casos analizados y
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
4
CISS/CAOSA/WP/05/03
expuestos en el primer documento de esta serie demuestran que ningún desarrollo
exitoso de una AE-TI puede deslindarse de la reestructuración general de la institución. En
otros términos, el proyecto fracasará si sólo se incorporan los esfuerzos técnicos.
Ciertamente, en el caso particular de proyectos de TI, los riesgos organizacionales
han demostrado ser más determinantes que los riesgos técnicos. En efecto, la calidad del
hardware, del software y de las redes de telecomunicaciones ha mejorado notablemente a
través de los años, lo que a su vez ha favorecido la comercialización de múltiples
productos y servicios. Lo que significa que son altamente estandarizados, y los usuarios
esperan de ellos que sean parte del ambiente de trabajo y de servicio de forma regular sin
que fallen. Es así como los trabajadores contemporáneos esperan tener acceso a Internet e
e-mail de forma rutinaria, de la misma confiabilidad con que esperan tener electricidad
para poder trabajar. La Tabla 1 muestra el resultado de una encuesta entre ejecutivos de
empresas involucradas en la implementación de sistemas de Administración de Recursos
de las Empresas (ERP, sistemas que usualmente requieren una definición adecuada de una
AE-TI y son parte de cambios importantes en la administración). Los resultados muestran
que los principales riesgos son de tipo “organizacional” y no de tipo técnico. Es justo decir
que si esta entrevista realizada en la década de los noventa se hiciera otra vez,
probablemente el riesgo organizacional sería percibido como incluso más importante y los
riesgos técnicos como incluso más pequeños.
Tabla 1
Riesgos en los Proyectos de Planeación de Recursos de las Empresas (ERP)
Técnicos
Negocio
Organizacionales
Muy bajo
10.5
4.5
1.5
Bajo
22.5
23.0
8.5
Moderado
39.5
32.5
18.5
Alto
15.0
26.0
37.5
Muy alto
11.5
14.5
35.0
Fuente: O’Leary (2000).
El lograr un compromiso ejecutivo para cualquier nueva iniciativa de AE-TI
requiere el desarrollo de un fuerte caso de negocios y una estrategia de comunicación para
difundirlo. Sin obtener la participación del Director de la Empresa, el Director de la Oficina
de Información (CIO) encontrará difícil mantener el patrocinio necesario para financiar e
implementar sistemas y procesos mejorados. Esto se puede lograr con las siguientes
acciones.
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
5
CISS/CAOSA/WP/05/03
− Utilizar casos exitosos de otros organismos públicos y privados así como de la
experiencia y conocimiento de expertos en AE.
− Utilizar ejemplos para demostrar como la AE puede proveer un diseño y una guía
básica para lograr los cambios deseados o mejoras en el desempeño de la misión y en la
rendición de cuentas.
Una vez que el CIO está seguro que el Director General comprende la necesidad de
una AE, es importante asegurar el compromiso del Director General para conseguir el
esfuerzo de arquitectura. El CIO debe coordinar junto con el Director General la selección
de un ejecutivo de la empresa para ser designado como Arquitecto en Jefe. La experiencia
demuestra que la autoridad del CIO por si sola no es suficiente para que la tarea sea
exitosa. Después de conseguir la participación y el apoyo, es necesario expedir la Política
Ejecutiva de Arquitectura de la Empresa. El CIO, en colaboración con el Director General,
desarrolla una política basada en los principios de arquitectura de la organización que
dirigen el desarrollo, la implementación y el mantenimiento de la AE. La política de AE
debe ser aprobada por el Director General y como mínimo debe incluir:
− Descripción del propósito y valor de una AE.
− Descripción de la relación de la AE con la visión y planes estratégicos de la
organización.
− Descripción de la relación de la AE con la planeación del capital, ingeniería de la
empresa y administración de programas.
− Translación de las estrategias de la organización dentro de las metas, objetivos y
estrategias de la AE.
− Compromisos para desarrollar, implementar y mantener una AE.
− Identificar a la AE como el único criterio a considerar para las nuevas y progresivas
inversiones.
− Visión general de una política de ejecución.
− Practicas seguras para incluir la certificación y acreditación.
− Compromiso del Arquitecto en Jefe y Establecimiento de un equipo central de AE
− Establecimiento de una Oficina para la Administración del Programa de AE (EAPMO).
− Establecimiento de un Comité de Dirección Ejecutiva de la AE (EAESC).
Es importante obtener apoyo de los funcionarios de alto nivel así como de las
unidades de negocios. El CIO y el Arquitecto en Jefe deben iniciar un programa de
mercadeo para enfatizar el valor de la arquitectura y el apoyo y compromiso del Director
General. Una vez que la AE ha sido diseminada, el CIO y el Arquitecto en Jefe deben
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
6
CISS/CAOSA/WP/05/03
organizar y conducir reuniones de arranque para explicar la metas de la AE, objetivos,
procesos, productos e interrelaciones con actividades de los sistemas.
Etapa 2.
Establecer una Estructura Administrativa y de Control
Es importante considerar que la arquitectura de la empresa forma parte de un
activo de la organización que debe ser manejado como un programa formal. La Gráfica 2
ilustra una organización nocional del programa para administrar, controlar y monitorear
las actividades y el progreso de la AE. La organización muestra las funciones,
interrelaciones y líneas de comunicación deseados. La organización debería posibilitar y
fomentar el desempeño de los papeles y responsabilidades de la AE.
Gráfica 2
Organización Nocional de la AE
Fuente: CIO (2001).
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
7
CISS/CAOSA/WP/05/03
Etapa 3.
Definir un Proceso de Arquitectura y una Estrategia
Tanto el alcance y naturaleza de la organización como los cambios a realizarse definirán a
su vez el alcance y naturaleza de la arquitectura a desarrollarse. Mientras que la AE es una
excelente herramienta para administrar ambientes grandes y complejos, la profundidad y
el detalle de la AE necesita hacerse a la medida de la empresa individual. La profundidad y
detalle de la AE varía no solo con el tamaño y complejidad de la empresa, sino también
con los muchos tipos de riesgo asociados con el cambio. Independientemente del alcance
de la arquitectura de la empresa, las opiniones de los directores de la empresa y de la
persona a cargo de la planeación estratégica deben comprender a la empresa en su
totalidad. La organización entenderá las relaciones y dependencias entre sus líneas de
negocios y así se posicionará ella misma para realizar decisiones informadas sobre como
aproximarse al detalle y profundidad de esas líneas de negocio acordes con la AE definida.
La primera actividad en este proceso consiste en determinar el uso que se pretende
de la arquitectura. Eso conduce el resto del proceso de desarrollo de la AE. Las actividades
subsecuentes describen como delimitar, caracterizar, seleccionar los productos de la AE,
construir y utilizar la AE.
Definir el uso deseado de la arquitectura
Las arquitecturas deben construirse con un propósito específico en mente. Puede ser una
reingeniería de procesos, adquisición de sistemas, integración o migración de un sistema a
otro, capacitación a los usuarios, evaluación de la interoperabilidad, o cualquier otro
propósito. El objetivo de la arquitectura está íntimamente ligado al plan o planes
estratégicos de organización, legislación y soporte del proceso de inversión en capital.
Definir el alcance y profundidad de la arquitectura
Es muy importante que el desarrollo de la AE sea llevado a cabo de arriba hacia abajo y de
manera incremental, de forma consistente con las opiniones jerárquicas de arquitectura,
que son los elementos fundamentales de estrategias probadas de AE. Al hacer eso, es
igualmente importante que el alcance de las opiniones sobre la AE de los niveles más altos
del negocio abarque a la empresa u organización en su totalidad. Al desarrollar este
entendimiento amplio sobre la empresa en cuanto a los procesos de negocio y sus reglas,
necesidades de información, flujos y ubicaciones, la organización estará posicionada para
hacer buenas decisiones acerca de si la empresa, y por lo tanto la AE, pueden ser
apropiadamente dividida en secciones.
Se debe tener cuidado al juzgar sobre el nivel apropiado de detalle a ser capturado
con relación al uso deseado y el alcance de la AE así como a las decisiones ejecutivas que
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
8
CISS/CAOSA/WP/05/03
serán hechas utilizando la AE. Es importante se de el mismo nivel de profundidad y
consistencia en cada una de las opiniones y perspectivas. Si características pertinentes son
omitidas, la arquitectura puede no ser útil. Por otro lado, si características innecesarias
son incluidas, el esfuerzo de arquitectura puede ser confuso o desordenado al incluir
detalles que son superfluos.
Seleccionar productos adecuados de AE
Existen “productos elementales” que son aquellos requeridos para todas las arquitecturas
y “productos de apoyo” los cuales pueden ser necesarios para cumplir con necesidades de
información
específicas.
Sólo
aquellos
productos
de
apoyo
que
describan
las
características deseadas deben de ser elaborados. Los productos elementales consisten de
gráficas, modelos, y/o relatos que cada descripción de arquitectura debe incluir para
sustentar el alcance y las características de la AE. Los productos de apoyo por su parte
consisten de gráficas, modelos y/o relatos que pueden necesitarse para favorecer la
elaboración de productos elementales o para dirigir la atención hacia un área o extender el
alcance.
Evaluar y Seleccionar una Estructura
Antes de realmente desarrollar la AE, la organización necesita evaluar y seleccionar una
estructura arquitectónica como guía. Una estructura es un sistema dentro del cual los
componentes importantes de una arquitectura y las interrelaciones entre estos
componentes son definidos. Una estructura ayuda a organizar la manera de pensar acerca
de la arquitectura, provee una descripción de los objetos de la arquitectura y ayuda a
asegurar que todas las personas involucradas en la empresa estén utilizando el mismo
conjunto de semánticas así como a presentarlas al grupo de personas interesadas en el
contenido de la arquitectura. Adicionalmente, una estructura provee un medio para
comunicar la arquitectura.
La estructura de la AE provee definiciones comunes y conceptos. Ayuda a
conseguir la participación y el apoyo. La AE muestra las relaciones entre los procesos del
negocio y los elementos tecnológicos, asegurando que exista coherencia entre todos los
elementos y que cada elemento del negocio pueda acotarse a su elemento correspondiente
en la arquitectura técnica y, de forma similar, que los elementos técnicos puedan ser
vistos como apoyos importantes a los requerimientos del negocio.
El uso de una estructura para la AE asegura uniformidad y estandarización cuando
se integran y migran sistemas de información. La estructura seleccionada debe depender
del uso que se le quiera dar, del alcance y de las características de la arquitectura que se
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
9
CISS/CAOSA/WP/05/03
desarrollará. Existen algunos criterios que deben ser considerados antes de elegir una
estructura, los cuales son:
− Una estructura debe ser consistente y estructurada.
− Debe dársele el enfoque de arriba hacia abajo desarrollar la arquitectura de forma
simple y natural.
− La estructura debe incorporar una variedad de términos en diferentes niveles de
abstracción.
− La estructura debe definir y posibilitar un proceso para desarrollar la arquitectura.
− La estructura debe describir los objetos que serán producidos durante el trabajo de
desarrollo de la arquitectura.
Otros criterios que son relevantes para la selección de una estructura se incluyen
en la Tabla 2.
Áreas
Política
Agencia
Productos
AE
Tabla 2
Criterios de Selección de una Estructura
Factores
−
Dirección legislativa y regulatoria.
−
Política de la organización.
−
Compatibilidad necesaria con otras agencias o políticas
conjuntas.
−
Contexto para la agencia –e. g. subordinada de otra gran
empresa, cercanamente relacionada con otra empresa.
−
Experiencia con alguna estructura en particular.
−
Mandatos y conductores –e. g. énfasis en los negocios contra
infraestructura o condiciones de servicio contra temas técnicos.
−
Prioridades, usos pretendidos y nivel deseado de detalle –e. g.,
modernización a gran escala contra un ambiente de TI estable.
−
Restricciones de recursos y de agenda sobre esfuerzos de
modelar.
−
Disponibilidad de productos de arquitectura existentes.
Fuente: CIO (2001).
Existen varias estructuras arquitectónicas que son del dominio público y existen
otras que han sido desarrolladas y promovidas por integradores de sistemas y
proveedores de tecnología. Algunas de estas estructuras que son del dominio público han
sido desarrolladas por el gobierno de los Estados Unidos y constituyen estructuras que
tienen una buena base, que actualmente son utilizadas a través de los diferentes
organismos federales en ese país. Estas estructuras pueden ser útiles para organizaciones
en otros países, ya que muchos de los temas son los mismos. Alternativamente, una
organización puede escoger desarrollar su propia estructura, a pesar de que los costos,
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
10
CISS/CAOSA/WP/05/03
beneficios, y riesgos en hacerlo deben ser valorados contra los riesgos en adoptar o
elaborar a la medida de cada organización una estructura existente.
Entre las estructuras más conocidas se encuentran las siguientes:
− POSIX 1003.23;
− The Open Group Architecture Framework (TOGAF);
− La Estructura Zachman;
− Estructura de la Arquitectura para la Empresa Federal (EAEF);
Algunas de estas estructuras se describen a continuación.
Estructura de la Arquitectura para la Empresa Federal
En septiembre de 1999, el Consejo Federal de la Oficina Principal de Información (CIO) de
los Estados Unidos publicó la Estructura de la Arquitectura para la Empresa Federal (EAEF)
Versión 1.1, con el fin de desarrollar una AE dentro de las organizaciones federales o para
un sistema que transcendiera límites interinstitucionales. La estructura está elaborada a
partir de
prácticas
de
negocio
y
diseños
comunes que
traspasan
los
límites
organizacionales. La EAEF provee un estándar permanente para desarrollar y documentar
las descripciones de arquitectura de áreas de alta prioridad. También provee de una guía
para describir arquitecturas para segmentos funcionales multiorganizacionales del
Gobierno Federal.
La Gráfica 3 muestra como son las separaciones de una arquitectura dada en
arquitecturas de negocios, información, aplicaciones y tecnología.
La EAEF actualmente incluye las primeras tres columnas de la estructura de
Zachman (1996) y de la metodología de planeación de una AE de Spewak.
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
11
CISS/CAOSA/WP/05/03
Gráfica 3
Estructura de los Componentes de EAEF
Fuente: CIO (2001).
Esta arquitectura sirve como punto de referencia para facilitar la coordinación
eficiente de procesos comunes de negocio, inserción de tecnología, flujos de información,
sistemas, e inversiones entre instituciones del Gobierno Federal. La EAEF provee una
estructura para desarrollar, mantener, e implementar ambientes operativos de alto nivel y
soportar la implementación de sistemas de TI. Como muestra la Gráfica 4, la EAEF se
representa como una matriz de 3x5 con tipos de arquitectura (Información, Aplicaciones y
Tecnología) en un eje de la matriz, y perspectivas (Planificador, Usuario, Diseñador,
Edificador y Subcontratista) en el otro eje. Los productos de AE correspondientes son
listados dentro de las celdas de la matriz.
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
12
CISS/CAOSA/WP/05/03
Gráfica 4
Matriz de la Arquitectura EAEF
Perspectiva del
planeador
Perspectiva del
usuario
Perspectiva del
diseñador
Perspectiva del
edificador
Arquitectura de
Información
Arquitectura de
Aplicaciones
Arquitectura
Tecnológica
Lista de Objetos del
Negocio
Lista de los Procesos de
Negocio
Lista de Ubicaciones del
Negocio
Modelo Semántico
Modelo del Proceso de
Negocios
Sistema Logístico del
Negocio
Modelo de Información
Logística
Arquitectura de
Aplicaciones
Arquitectura de
Despliegue Geográfico del
Sistema
Modelo de Información
Física
Diseño de Sistemas
Arquitectura Tecnológica
Diccionario de
Información
Programas
Arquitectura de Redes
Perspectiva del
subcontratista
Fuente: CIO (2001).
Seleccionar un Conjunto de Herramientas para la AE
Además de las estructuras, existen instrumentos o herramientas que apoyan la creación y
representación de objetos dentro de la estructura.1 Varios criterios para determinar el
potencial de estas herramientas incluyen su habilidad para describir, diagramar, clasificar
elementos y navegar dentro de la estructura.
Una herramienta arquitectónica interactiva ayuda a incrementar la utilidad de
cualquier arquitectura. Existen muchas arquitecturas automatizadas que están disponibles
en el mercado hoy en día. La elección de la herramienta debe estar basada con base en las
necesidades de la organización y en el tamaño y complejidad de la arquitectura.
Actualmente,
proveedores
líderes
en
el
mercado
ofrecen
conjuntos
de
herramientas que pueden proveer alineación con la estructura seleccionada y productos
recomendados. Los criterios para seleccionar el conjunto de herramientas deben
determinarse de acuerdo al uso deseado de la arquitectura, al alcance, a los niveles de
integración deseados y a otros factores. La Tabla 3 lista temas para ayudar en la selección
de estas herramientas. La lista puede hacerse a la medida del conjunto de requerimientos
1
Un objeto es una representación abstracta de algún aspecto de un sistema a edificarse o existente, de
un componente o perspectiva. Ejemplos de objetos individuales son modelos gráficos, tablas de información,
y relatos estructurados o no estructurados comúnmente llamados como la arquitectura “Como-Es”.
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
13
CISS/CAOSA/WP/05/03
específicos para la selección de herramientas. Puede darse el caso de que probablemente
una herramienta no cubra todos los requerimientos. Por lo tanto, un juego de
herramientas o una combinación de tarifas podrían ser más apropiados. Los productos de
trabajo deben ser conservados en múltiples y distintos tipos de medios tales como
documentación impresa (resúmenes y reportes), archivos electrónicos en CD, documentos
HTML en la red, y otras herramientas de ingeniería de software asistidas por
computadora, herramientas de desarrollo que provean un sistema de administración de
bases de datos relacionados.
La estandarización de herramientas es una mejor práctica recomendada, ya que es
costo-efectiva cuando se determina la calidad y alineación de la arquitectura con la
política de la AE desde una perspectiva de costo de adquisición y por la interoperabilidad
consistente de los modelos.
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
14
CISS/CAOSA/WP/05/03
Tabla 3
Criterios para la Selección de Herramientas
Áreas Funcionales
Desarrollo de
Productos de AE
Mantenimiento de
Productos de la AE
Diseminación de
los Productos de la
AE
Criterios
− Plataformas disponibles.
− Apoyo para la estructura seleccionada.
− Apoyo para las técnicas y métodos de modelado (e. g.,
análisis y diseño orientado en objetos, IDEF, modelos de
actividad, modelos de clase, modelos de información).
− Capacidad para Importar/Exportar.
− Costo (inicial y de mantenimiento) y licencias.
− Apoyo del proveedor (e. g. tiempo y costo).
− Calendario de capacitación, costo y duración.
− Facilidad de uso.
− Integración de productos generados (habilidad para
integrar las arquitecturas de arranque y la objetivo y los
productos de ingeniería de la empresa).
− Capacidad, tamaño esperado, y complejidad de los
modelos.
− Consolidación e integración del sistema para guardar
información.
− Apoyo multi-usuarios.
− Apoyo meta-modelo (e. g. habilidad para configurar y hacer
a la medida los elementos del modelo).
− Apoyo de RM/Seguimiento de temas.
− Apoyo de CM.
− Apoyo de PR (Preguntas y Respuestas).
− Habilidad para interoperar con otros productos de
ingeniería de la empresa y para desarrollar herramientas y
almacenes.
− Posibilidad de seguir los requerimientos y otros objetos de
ingeniería de la empresa.
− Traceability to requirements and other enterprise
engineering artifacts.
− Apoyo de RM/Seguimiento de temas.
− Apoyo de CM.
− Apoyo de PR (preguntas y respuestas).
− Accesibilidad (e. g. software necesario, requerimientos de
acceso).
− Generación de documentos (resúmenes y reportes).
− Información soportada (e. g. CD-ROM, HTML).
− Niveles de Control de Acceso (e. g. Sólo Lectura, LecturaEscritura).
− Uso de vínculos de hipertexto.
Fuente: CIO (2001).
Etapas 4 y 5. Desarrollar las Arquitecturas de Arranque y Objetivo
La arquitectura de arranque consiste en el conjunto de productos que retrata a la empresa
actual, sus prácticas de negocios y su infraestructura técnica. A esta arquitectura se le
conoce comúnmente como arquitectura “Como-Es”.
La arquitectura actual tiene dos
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
15
CISS/CAOSA/WP/05/03
partes: 1) la arquitectura de negocios actual, la cual define las necesidades de negocios
actuales que están siendo satisfechas por la tecnología actual; y 2) el diseño de
arquitectura actual, que define la implementación de datos, aplicaciones y tecnología
usada para apoyar las necesidades de negocios actuales. La arquitectura-objetivo es la
representación de la arquitectura futura deseada o “por-ser-construida” para la empresa
dentro del contexto de la dirección estratégica. Al igual que en la arquitectura de
arranque, la arquitectura-objetivo se divide en dos partes: a) la arquitectura objetivo de
negocios que define las necesidades de negocio futuras de la empresa a través de
tecnologías nuevas o emergentes, y b) el diseño de la arquitectura objetivo que define los
diseños futuros utilizados para apoyar necesidades de negocio futuras.
Consideraciones comunes en el desarrollo de la Arquitectura de Arranque y Objetivo
Para el desarrollo de la arquitectura de arranque y objetivo el primer paso es construir los
productos arquitectónicos basados en el propósito de la arquitectura y la estructura
elegida. Esto consiste en los productos esenciales, productos de soporte (si se necesitan), y
productos definidos individualmente (e. g., reportes informativos, gráficos, notas de
entrevistas) conducidos por necesidades y procesos específicos de arquitectura. Para
facilitar la integración con otras arquitecturas, es crucial incluir todas las descripciones de
las relaciones aplicables con componentes externos, esto es, entidades al exterior de la
agencia.
El grupo central de arquitectura debe aplicar un enfoque (aproximación)
consistente para el desarrollo de las arquitecturas de arranque y objetivo. El enfoque
seleccionado debe incluir (1) la fase de recolección de datos, (2) generación de productos
preliminares, (3) etapas de reseña y revisión, y (4) publicación y entrega de los productos
de arquitectura a un almacén apropiado. Un depósito es un sistema de información usado
para guardar y acceder información de arquitectura, relaciones entre elementos de
información, y productos de trabajo. La Gráfica 5 muestra un proceso típico para el
desarrollo de productos de una AE. Cada una de estas actividades está descrita en las
siguientes subsecciones.
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
16
CISS/CAOSA/WP/05/03
Gráfica 5
Estrategía Modelo para el Desarrollo de la AE
Recopilación
de Datos
Revisión de
Literatura y
Documentación
Publicación
y Entrega
Examen y Revisión
Generación
Preeliminar
de Productos
Ejecutar
Sesiones de
Grupo de
Fomento de
Ideas
Generate
Reuniones y
Entrevistas
Preliminares
Revisar
Productos
cuando sea
Necesario
Preliminary
General
Productos
Preliminares
Entrenamiento de
Famirialización
Generar Resumen
y Presentar
Conducir
Entrevistas
Individuales a
Fondo
Validación y
Revisión
Independiente
de SME
Publicar
Productos
de Arquitectura
Alimentar
Herramientas y
Repositorios
Fuente: CIO (2001).
Recolección de Información
La recolección de datos es el esfuerzo inicial crucial que involucra la revisión de
documentación, sesiones de escenarios y entrenamiento, y las entrevistas a Expertos
Encargados en la Materia (EAM) y dueños de dominio. Toda la información y productos
recolectados que sean apropiados deberán ser puestos en el depósito electrónico central
de AE.
En el caso de la arquitectura de arranque, los productos muestra que deben ser
recolectados incluyen:
− Funciones de negocios actuales y flujos de información
− Modelos de datos
− Descripciones externas de interfase
− Aplicaciones existentes y documentación de sistemas (inventario de aplicaciones)
− Diseños técnicos, especificaciones e inventario de equipo.
En el caso de la arquitectura objetivo, los productos muestra que deben ser
recolectados incluyen:
− Procesos de negocios propuestos y flujos de información
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
17
CISS/CAOSA/WP/05/03
− Planes estratégicos
− Requerimientos en documentos
Muchos de estos productos pueden no existir o pueden no representar
correctamente la arquitectura de arranque o los ambientes objetivo propuestos. Si falta
documentación, el grupo central de arquitectura debe desarrollar una estrategia para crear
la documentación necesaria o decidir si debe o no hacer la inversión. En este caso, los
entrevistadores tendrán que confiar en EAMs de negocios o de sistemas en lo que se
refiere al propósito y al alcance de la actividad y la expectativa de su participación.
Después de haber recolectado una cantidad suficiente de datos, el trabajo de crear
productos de AE y poblar el depósito de AE puede empezar.
Idealmente, en esta fase se pueden generar productos arquitectónicos en borrador
y preliminares sin la intervención profunda de EAM. Con el desarrollo de productos de
sustituto, los arquitectos pueden conducir una serie de sesiones de lluvia de idas con los
actores y entrevistas más profundas con los EAM para solidificar los productos. El
Arquitecto en jefe deberá revisar y validar la lista propuesta de entrevistados y asegurar la
participación de EAM vía comunicaciones con los dueños del dominio. Los procesos de
marketing y compra de los proyectos descritos con anterioridad deben haber preparado la
participación para esta etapa.
Puede ser útil grabar estas entrevistas para referencias futuras. Siempre es
importante hacer un seguimiento para asegurar que la información de la entrevista haya
sido interpretada correctamente. Una vez que las entrevistas iniciales han sido
completadas, el grupo central de arquitectura extrae información de las entrevistas para
afinar los productos existentes en el depósito de AE.
Generar Productos y Poblar el Almacén de AE
Dependiendo de la estructura, procesos y métodos elegidos, algunos productos pueden
ser creados durante la primera iteración del desarrollo de AE mientras que otros pueden
ser creados durante iteraciones posteriores. Adicionalmente, dependiendo de sí la
arquitectura de arranque u objetivo está siendo creada, varios factores afectarán la
aproximación tomada, el enfoque de los productos y el orden en que los productos son
generados. Estos diferenciadores clave se describen en la Tabla 4.
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
18
CISS/CAOSA/WP/05/03
Procesos
Productos
Tabla 4
Diferenciadores de la Arquitectura de Arranque y Objetivo
Arquitectura de Arranque
Arquitectura Objetivo
El proceso aplica a la estructura
El proceso aplica la misma estructura
elegida
que el arranque
El proceso depende
considerablemente en
documentación existente, e. g.
manuales de proceso y
procedimiento
Puede no existir la documentación o es
probable que sea inconsistente, e. g.
varios documentos de visión y de
planeación
La generación de productos
comenzará en la organización
de TU, y eventualmente se
extenderá a los EAMs de
negocios para validación de
productos
La generación de productos empieza
con una fuerte participación de los
EAMs de las unidades de negocios
Es probable la ingeniería en
reversa. El proceso necesita
verificación los documentos de
requisitos y diseño reflejan la
realidad.
El énfasis se pone en la ingeniería hacia
delante, se construye sobre los
esfuerzos de reingeniería de procesos
de negocios y pronósticos de
tecnología.
La información disponible se
estandariza y normaliza como
un fundamento para el cambio
El material originalmente producido
para diferentes plazos de tiempo, e. g.
planes de un año, planes de 5 años,
planes estratégicos, se integran bajo
una sola visión.
Los modelos son basados en la
realidad
Los modelos son basados en supuestos,
planes, necesidades reconocidas,
ambiente político, tecnología futura
Los productos describen la
totalidad de la empresa actual a
un nivel consistentemente alto.
Análisis adicional basado en
detalles en áreas prioritarias, e.
g. áreas con problemas
conocidos
Los productos describen una visión
para le empresa en su totalidad.
Análisis adicional en áreas prioritarias,
e. g. modernización anticipada
Describen todas las operaciones
relevantes manuales y
automatizadas
Explícitamente incluye el legado, con
actualizaciones si están planeadas, o
existe una desarme explícito de lo que
existe en el arranque. También incluye
componentes de transición planeados
Se puede validar la consistencia,
totalidad y exactitud.
Se puede validar la consistencia y la
totalidad
Los productos están disponibles
y están controlados en el
depósito
Los productos están disponibles,
ligados a la Arquitectura de Arranque y
controlados en el mismo depósito que
la Arquitectura de Arranque
Fuente: CIO (2001).
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
19
CISS/CAOSA/WP/05/03
Revisar, Validar y Refinar Modelos
Los productos de arquitectura son presentados para revisiones internas y de los EAMs.
Antes de las entrevistas a los EAMs, los miembros de mayor rango del grupo central de
arquitectura realizan una revisión “rápida” Esta revisión prepara la etapa para los
procesos de entrevistas. Ayuda a los entrevistadores a formular un formato para focalizar
las sesiones de entrevistas. La siguiente revisión ocurre después de que el equipo haya
actualizado y expandido el primer conjunto de productos.
En la revisión de EAMs, los participantes en la revisión (es decir, el Arquitecto en
Jefe, el grupo central de arquitectura, PR, Administrador de Riesgos, EAMs y dueños del
dominio) determinan la precisión y lo completo de los productos de la AE. El
Administrador de Riesgos puede proporcionar una evaluación temprana de los riesgos de
negocios, técnicos, de costos o de programación. Los productos deberán entonces ser
revisados completamente y presentados al RTC y Comité Ejecutivo de Vigilancia de la
Arquitectura de la Empresa (CEVAE) para validación y aprobación final. Una vez
aprobados, la arquitectura final (productos y modelos) podrá ser publicada, notas
informativas y documentación entregada y las bases de datos apropiadas o herramientas
arquitectónicas deberán actualizarse.
Aspectos Esenciales en la Construcción de la Arquitectura de Arranque
La construcción de la arquitectura de arranque permite el establecer un plan de avance y
medición del progreso contra la arquitectura objetivo. El alcance del análisis de arranque y
de la documentación resultante es crítico. En la medida en que la organización sea más
grande, el análisis de arranque deberá contener un mayor grado de compromiso y deberá
ser costeado detallada y explícitamente. Para áreas mayores, existen métodos y técnicas,
así como modelos que facilitan un acercamiento por medio de muestras para
proporcionar líneas de arranque que sean útiles y menos costosas. Organizaciones
pequeñas y medianas (quizá no el caso común de agencias de seguridad social, pero a ser
considerado por países pequeños) pueden escoger un inventario detallado de los procesos
de negocios, aplicaciones y la infraestructura en tecnología con la cual operan. En ese
caso, la arquitectura de arranque es un inventario detallado de las funciones del negocio,
aplicaciones y problemas del software, y la infraestructura en tecnología/hardware de la
empresa.
Esenciales en la Construcción de la Arquitectura Objetivo
La arquitectura objetivo debe definir una visión de las operaciones futuras del negocio y
de la tecnología de soporte. En ese sentido, un proyecto de largo plazo es absolutamente
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
20
CISS/CAOSA/WP/05/03
necesario. La tecnología objetivo describe la capacidad y la estructura deseada de los
procesos de negocios de la empresa, necesidades de información, y la infraestructura en
TI en algún punto futuro. La arquitectura objetivo puede incluir alternativas, opciones, e
imponderables--esto es aceptable. Los procesos de la AE son iterativos--las interrogantes
se van llenando con el tiempo. Una consideración clave es la determinación de la fecha del
objetivo, que tan a futuro es el objetivo proyectado. La realización de declaración sobre la
misión y visión de la organización necesita:
−
Un enfoque en las áreas de negocios o en necesidades de información con mayor
potencial de rentabilidad para la empresa.
− Desarrollar modelos y herramientas conceptuales que permitan a los tomadores de
decisiones y al personal mejorar en el reconocimiento, entendimiento y discusión de los
requerimientos de información.
− Un amplio entendimiento de la empresa en su conjunto y la necesidad de información
compartida.
− Reconocer que la información es un recurso estratégico que debe ser manejado usando
herramientas de arquitectura.
− Evaluación periódica del progreso de la empresa hacia el ambiente objetivo.
− Alineación con el plan estratégico de la empresa.
La arquitectura objetivo representa mejoras a la arquitectura existente de arranque
que adicionan nueva funcionalidad a las operaciones de negocios existentes. La
arquitectura objetivo debe ser fiscal y tecnológicamente realizable a la vez que aterrizadas
en las necesidades de negocio de la organización. La realidad del rápido cambio
tecnológico necesita flexibilidad y capacidad de cambio de las arquitecturas objetivo: éstas
deben proyectar no más allá de 3 a 5 años en el futuro.
Así como la arquitectura de arranque captura las prácticas de negocio existentes y
los flujos de información, la arquitectura-objetivo refleja qué necesita la organización para
evolucionar sus recursos de información. La arquitectura-objetivo provee respuestas a las
siguientes preguntas básicas:
− ¿Cuáles son los objetivos de negocios estratégicos de la organización?
− ¿Qué información es requerida para apoyar los negocios?
− ¿Cuáles son las aplicaciones necesarias para proveer información?
− ¿Cuál es la tecnología necesaria para dar soporte a las aplicaciones?
Las respuestas a estas preguntas yacen en los requerimientos de información de la
agencia, y en cambio, las necesidades de información se afirman sobre las prácticas de
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
21
CISS/CAOSA/WP/05/03
negocio de la organización, su funcionalidad y operaciones. En la medida en que cambias
los roles de negocios, el contenido y los flujos de información también cambian. Los
estándares del pronóstico y de la información del perfil tecnológico pueden identificar la
TI necesaria para sostener esto procesos de negocios cambiantes. Dentro de la
arquitectura-objetivo, estos productos pueden ser reflejados en el producto Modelo de
Referencia Técnica, que consiste en una taxonomía que provee un conjunto coherente de
áreas de servicio, categorías de interfase, y relaciones para enfrentar inoperatividad y
sistemas abiertos.
La arquitectura-objetivo debe:
− Reflejar el juicio del equipo de AE sobre usos futuros y características de la
información dentro de la empresa.
− Reflejar las revisiones de requerimientos de negocios de la organización para
enfocarse en las oportunidades de automatizar aspectos del trabajo y/o acceder a la
información necesaria para realizar el trabajo.
− Incorporar pronósticos de tecnología.
− Especificar el nivel necesario de inoperatividad necesario entre las fuentes de
información y los usuarios de datos.
− Identificar las TI necesarias para apoyar los objetivos técnicos de la agencia.
− Reflejar las inquietudes presupuestarias y territoriales.
Etapa 6.
Desarrollo del Plan de Secuencia
El camino hacia el plan secuencial u objetivo es un documento que define la estrategia
para migrar a la organización de la arquitectura de arranque a la arquitectura-objetivo.
Éste define y determina los cambios necesarios para la transición del estado actual de la
empresa a las metas y condiciones expresadas por la arquitectura-objetivo. Este proceso
involucra
múltiples
actividades
concurrentes
independientes
y
constituciones
incrementales. La mejor forma de entender y controlar este complejo y evolutivo proceso
es desarrollando y manteniendo un mapa de migración de sistemas o plan secuencial que
describe paso a paso este proceso.
En adición a al desarrollo específico de los requerimientos de los nuevos
componentes de la arquitectura-objetivo, el desarrollo del plan secuencial debe tomar en
cuenta una amplia variedad de insumos, incluyendo:
− Sostenimiento de las operaciones durante la transición.
− Activos técnicos existentes y arreglos contractuales.
− Programas de desarrollo actualmente en curso.
− Cambios anticipados en la administración y organización.
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
22
CISS/CAOSA/WP/05/03
− Metas de negocios y prioridades operativas (incluyendo legislación y directiva
ejecutiva).
Identificar Brechas
El análisis de brechas consiste en la identificación de diferencias entre las arquitecturas de
arranque y objetivo. El análisis de huecos desarrolla los requerimientos del usuario,
determina restricciones políticas y técnicas y evalúa los riesgos de migración y la
viabilidad.
A través del análisis de brechas, el grupo central de arquitectura puede identificar
los componentes que necesitan ser cambiados para lograr el estado final deseado. En
total, el análisis de brechas determina el estado de los sistemas legales, tecnología,
madurez, oportunidades de adquisición y realidad fiscal de la transición.
Definir y Distinguir entre Sistemas de Legado, de Migración y Nuevos
Los sistemas de legado, de migración y nuevos sistemas forman los componentes técnicos
del ambiente de transición al objetivo. Estos componentes técnicos incluyen hardware,
software,
periféricos,
lenguajes
de
desarrollo,
sistemas
operativos,
sistemas
de
computadora, protocolos de red, y telefonía. Un problema general en muchas
organizaciones es el hecho de que la mayoría de los sistemas se construyen
incrementalmente en lugar de surgir como un ambiente articulado.
Los sistemas de legado y sus aplicaciones son aquellos que se encuentran en
operación actual y que generalmente son desplegados durante el desarrollo de la
arquitectura-objetivo. Los sistemas y aplicaciones de migración pueden estar actualmente
en operación, pero con certeza estarán en operación cuando la transición comience y por
algún tiempo en el futuro. Por lo tanto, ellos pueden no estar específicamente
representados en la arquitectura-objetivo. Los sistemas de migración también incluyen
sistemas, bases de datos, interfaces u otros componentes que pueden ser introducidos y
temporalmente usados para mantener las operaciones entre el sistema actual (y la fase
incremental) y el establecimiento de los componentes de la arquitectura-meta. Las
aplicaciones y sistemas nuevos son aquellos que están siendo adquiridos, están bajo
desarrollo, o están siendo desplegados. Se espera que éstos entren en operación como
parte del ambiente objetivo.
El equipo central de arquitectura debe subrayar en el plan de secuencia el flujo
ininterrumpido y manejo de datos, el uso por ambos sistemas, el de legado y el nuevo, y
su creación y distribución para que la operación eficiente de la empresa esté garantizada.
El plan debe incluir los recursos, presupuestos, tareas de trabajo, secuencias,
dependencias y restricciones de tiempo de la empresa.
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
23
CISS/CAOSA/WP/05/03
Una sección importante del plan de secuencia debe ser la evolución del sistema o
análisis de migración capturada en un conjunto de tablas de migración, diagramas o
gráficos. La Gráfica 6 muestra un gráfico de migración nocional. Este tipo de gráficos
ayuda a ilustrar cómo se espera la evolución de los sistemas y aplicaciones entre las
arquitecturas de arranque y objetivo. Generalmente, un sistema evoluciona en una de las
siguientes maneras:
− Los sistemas actuales continúan en operación (Sistema D).
− La funcionalidad de los sistemas existentes es absorbida por otro sistema (Sistema A
en Sistema B).
− El sistema de legado transita a la migración y evoluciona en un nuevo sistema (Sistema
B en Sistema X).
− Se planea que el sistema actual evolucione todavía más (Sistema C en Sistema Y).
− Se desarrolla un sistema nuevo durante la transición para que se convierta en el
sistema permanente y final (Sistema E).
− Una fusión de la funcionalidad legada y los sistemas de migración (Sistema N en
Sistema K y después absorbido en Sistema D).
Gráfica 6
Gráfica de la Migración de Sistemas
Hoy
Sistemas Transitorios
Objetivo
Sistema A
Sistema B
Sistema B
Sistema C
Sistema Y
Sistema E
Sistema D
Sistema N
Sistema X
Sistema E
Sistema D
Sistema K
Fuente: CIO (2001).
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
24
CISS/CAOSA/WP/05/03
Etapa 7.
Utilizar la Arquitectura de la Empresa
Usar la AE para implementar proyectos nuevos proporciona un impacto positivo en
la agencia. La AE debe ser manejada como un programa que facilita los cambios
sistemáticos de
la agencia al alinear constantemente inversiones y proyectos en
tecnología con las necesidades de la misión de la agencia. La AE es actualizada
continuamente para reflejar cambios en las prioridades operacionales y de inversión que
puedan surgir debido a legislación, restricciones en el presupuesto u otras directrices del
negocio.
Para asegurar la construcción de un ambiente de TI completamente articulado y
estandarizado es importante el uso de AE para cualquier tipo de tecnología utilizada en la
organización. Algunas veces las decisiones sobre el estándar de la tecnología se basan en
tecnologías agrupadas dependientes e interrelacionadas, casi todos los proyectos son
interdependientes de otros proyectos en desarrollo y sistemas de legado. Muchos son
seguidos de incrementos adicionales de capacidad o de operaciones adicionales y
esfuerzos de mantenimiento. La elección de cierto sistema operativo dicta el protocolo en
red utilizado; la elección de cierto paquete para la Administración de las Relaciones con el
Cliente (CRM por sus siglas en inglés), y estrecha el campo de hardware sobre el cuál este
correrá. En estos casos, es importante reconocer y hacer explicitas las decisiones en
tecnología que se están haciendo fuera del área en consideración, para que el
agrupamiento de la tecnología pueda ser tratado en su totalidad.
Las decisiones en inversión y el desarrollo o adquisición de sistemas deben de
estar estrechamente ligados con el proceso de AE. La agencia sólo debe hacer inversiones
que la muevan hacia la arquitectura-objetivo y estas decisiones en inversión deben de
cumplir con el plan de secuencia. Las agencias deben diseñar se propio Plan de Control de
Capital e Inversión (PCCI) para el proceso de reestructurar la formulación y ejecución del
presupuesto para asegurar que las inversiones apoyan de forma consistente las metas
estratégicas de la agencia. Todos los proyectos en TI deben alinearse con la misión de la
agencia y apoyar las necesidades de negocio de la agencia así como minimizar el riesgo y
maximizar los rendimientos a lo largo del ciclo de inversión.
La arquitectura-objetivo y el plan de secuencia proveen información para las tres
fases del PCCI que consisten en selección, control y evaluación. En la fase de selección, la
agencia determina si las inversiones propuestas cumplen con el criterio de decisión de
negocios. Para evaluar la alineación entre el negocio y las inversiones propuestas, los
tomadores de decisiones, por ejemplo, el caso de negocio, plan de adquisición y el plan de
proyecto para determinar si la inversión propuesta se alinea con el plan secuencial y la
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
25
CISS/CAOSA/WP/05/03
arquitectura objetivo. En la fase de control, los tomadores de decisiones monitorean el
cumplimento técnico y de negocios como se demuestra en, por ejemplo, el caso de
negocios actualizado, arquitectura de sistema, diseño de sistemas y programas de prueba.
Adicionalmente, la inversión debe ser monitoreada para asegurar la alineación continua
con la estrategia y los objetivos de la agencia, los cuales pueden cambiar en el tiempo. En
la Fase de Evaluación, los agentes encargados de decidir realizan una evaluación final para
determinar el cumplimento técnico y estratégico con la AE. Los resultados, incluyendo
conclusiones de incumplimiento, deben influenciar la planeación estratégica de nuevos
negocios y proyectos de TI, los cuales podrían entonces derivar en cambios en la AE.
Etapa 8.
Mantener la Arquitectura de la Empresa
La AE debe reflejar el impacto de los cambios en curso en las funciones de negocio y de la
tecnología de la empresa, y llegado el momento, apoyar a la planeación estratégica y al
manejo de inversiones al estar al tanto con esos cambios. Consecuentemente, cada
componente de la AE (arquitectura de arranque, arquitectura-objetivo, plan de secuencia, y
todos los productos que los componen) necesita mantenimiento y ser conservado de
manera precisa y actualizada. Para esto es importante revaluar la arquitectura de la
empresa periódicamente para ver si la arquitectura de arranque refleja el estado actual de
la infraestructura en TI, si la arquitectura-objetivo refleja la visión de negocios de la
empresa, que los avances tecnológicos que hayan ocurrido desde el último lanzamiento
sean apropiados y si el plan secuencial refleja las prioridades predominantes de la
empresa y los recursos estén realmente disponibles.
El mantenimiento de la AE debe ser
llevado a cabo dentro de la estructura
ejecutiva y de los mecanismos de control y configuración de la organización. Utilizando
un sistema de procesos de vigilancia y de verificación independiente, el equipo central de
arquitectura periódicamente evalúa y alinea la AE a las prácticas de negocio que
generalmente se encuentran constantemente en cambio, perfiles de financiamiento,
e
inserción de tecnología. La AE debe mantenerse alineada a los proyectos de
modernización de la empresa y viceversa.
IV.
Mensaje Final
Este documento es una descripción general de cómo desarrollar un plan de AE.
Como puede inferirse, este proceso puede llevarse a cabo solo si existe un compromiso
permanente de la administración. Tres temas principales son los siguientes. Primero, las
organizaciones no pueden evadir la importancia de desarrollar una arquitectura de TI, y
independientemente de que estén concientes o no de ello. Por lo tanto, es preferible hacer
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
26
CISS/CAOSA/WP/05/03
a la arquitectura explícita. Incluso si el esfuerzo es modesto, la organización puede tener
ganancias del aprendizaje sobre donde está parada y hacia dónde va. Segundo, la
posibilidad de desarrollo de un plan de arquitectura es independiente del grado de
desarrollo de la organización o de los recursos presupuestarios de corto plazo. Es decir,
incluso un esfuerzo modesto puede establecer la etapa para un ambiente favorable en el
futuro. Y tercero, el plan de arquitectura debe ser desarrollado con un conocimiento
cercano de los objetivos organizacionales de la institución. Programas de reforma
ambiciosos de instituciones (como los que han tomado lugar en la seguridad social en
América), pueden mejorar la probabilidad de éxito con el apoyo de planes bien definidos
de arquitectura de TI, no sólo para las instituciones en lo individual, sino también para el
conjunto de instituciones involucradas en el proceso de protección social.
V.
Referencias
Federal Chief Information Officer (CIO) Council. A Practical Guide to Federal
Enterprise Architecture, Version 1.0 February, 2001
Federal Chief Information Officer (CIO) Council, Federal Architecture Working
Group, Architecture Alignment and Assessment Guide, October 2000.
Federal Chief Information Officer (CIO) Council, Federal Enterprise Architecture
Framework, Version 1.1 September, 1999
O’Leary, Daniel E. Enterprise Resource Planning Systems: Systems, Life Cycle,
Electronic Commerce, and Risk. Cambridge: Cambridge University Press, 2000.
Steven Spewak Enterprise Architecture Planning Home Page www.eap.com
Zachman,
J.
A.
The
Framework
for
Enterprise
Architecture:
Background,
Description and Utility. 1996.
Este documento es preliminar, se encuentra en fase de discusión, y no representa
los puntos de vista de la CISS o de alguno de sus miembros.
27
CISS/CAOSA/WP/05/03
Este documento es preliminar, se encuentra en fase de discusión,
representa los puntos de vista de la CISS o de alguno de sus miembros.
y
no
28