Este documento puede formar parte de la descripción de un servicio de arquitectura de sistemas.

1. Metodología para un Servicio de Arquitectura de Sistemas
de Información
Cuando se introduce un servicio de Arquitectura de Sistemas de Información, se debe tener muy en
cuenta la aproximación metodológica, entre otros, por los factores que se detallan a continuación.
Básicamente, se trata de un cambio cultural y los distintos equipos funcionales deben
aceptar una autoridad tecnológica no necesariamente ligada a una autoridad jerárquica. Se debe
introducir en la organización un nuevo término, la validación tecnológica de las nuevos proyectos.
El término validación tecnológica debe enfocarse de una manera positiva, es decir, como un
valor añadido que se aporta a los proyectos y que los enriquecen de cara al futuro, a un
mantenimiento y operación más sencillo y unificado. Esta validación tecnológica no hace que los
proyectos sean “mejores”, pero si que hace que estén mas alineados entre ellos y que converjan con
la estrategia tecnológica corporativa.
Hay una dependencia entre los equipos funcionales o verticales y el equipo de Arquitectura
que aportará una coherencia y un sentido global a la arquitectura corporativa de sistemas.
Se corre el riesgo de que el equipo de Arquitectura se convierta en un cuello de botella y
haga que la maquinaria del área de Tecnología avance más lentamente.
Los beneficios de un Servicio de Arquitectura horizontal o centralizado, no se verán en el
corto plazo, si no más bien, en el medio y, sobre todo, largo plazo. Es muy importante gestionar
adecuadamente las expectativas de la Dirección en ese sentido. El Servicio de Arquitectura es una
inversión.
Los componentes del equipo de Arquitectura serán expertos en aspectos tecnológicos muy
concretos, pero no tratarán de suplantar el conocimiento y tecnológico de los equipo verticales o
funcionales. La manera en que el propio Servicio de Arquitectura participe en los proyectos y
colabore con ellos, determinará, en buena medida, la eficacia del servicio.
Se debe planificar el momento en que el servicio de arquitectura debe empezar a aportar
valor en el ámbito de un área funcional o vertical. Los equipos funcionales pueden tener una
percepción negativa si se hace de una manera intrusiva y no planificada.
El tipo de colaboración del Servicio de Arquitectura con los equipos de proyecto será
diferente dependiendo del tipo de proyecto de que se trate. En los proyectos de despliegue de un
nuevo sistema y de reingeniería de sistemas existentes, la participación debe ser muy cercana y
desde la fase de iniciación del proyecto. En aquellos proyectos en que la integración con otros
sistemas no se vea afectada en más de un 10%, la colaboración será tangencial y a modo de

2. validación del diseño técnico.
La arquitectura debe definirse de manera clara, los estándares y guías deben estar publicadas
con detalle, pero en un lenguaje natural y que resulte comprensible fácilmente por las personas a las
que va dirigido. También deberán tener una introducción que aclare, para personas sin perfil
técnico, cual es el beneficio de la aplicación de esta guía o estándar.
Todos los equipos que vayan a verse afectados por las guías y estándares, deberán tener
tiempo de revisar y enviar comentarios previos a la aprobación y entrada en vigor del mismo.
También participarán en la revisión y comentarios, aquellos equipos que, aún no viéndose afectados
por una nueva guía o estándar, tengan una opinión que pueda ser relevante.
En general, se propone que todos los equipos del área de Tecnología tengan posibilidad de
revisar y expresar comentarios sobre todos las guías y estándares. Dependiendo de la relevancia del
equipo, sus comentarios tendrán un peso mayor o menor a la hora de la aprobación.