El Rol del Arquitecto de Software

1 Tabla de Contenido

1 Tabla de Contenido ...............................................................................................................................

2
2 Introducción ..........................................................................................................................................
3
3 El Arquitecto de Software .....................................................................................................................
4
4 Mapa Conceptual ..................................................................................................................................
7
5 Características de un Arquitecto de Software, por Peter Eeles de IBM ...............................................
8
6 El Rol del Arquitecto de Software según el Software Engineering Institute.........................................
9
7 El Rol del Arquitecto de Software según Rational Unified Process - RUP...........................................
11
8 El Rol del Arquitecto según SUN SL-425 .............................................................................................
13
9 El Rol del Arquitecto Microsoft ...........................................................................................................
14
10 El Papel del Arquitecto según Bredemeyer Consulting .................................................................. 18
11 Conclusiones ................................................................................................................................... 21
12 Bibliografía ...................................................................................................................................... 22
 2 Introducción

Hay quienes objetan vehementemente el uso de los términos "arquitecto" y "arquitectura" en el

dominio del software. Hoy en día, este término es utilizado para sistemas, productos, negocios y
otros términos informáticos. Así como no tiene sentido ver una casa como un puñado de madera,
clavos y ladrillos, tampoco tiene sentido ver el software como un puñado de bits o incluso líneas de
código, tenemos que ver estructuras más grandes, los cuartos, el flujo de las personas entre ellos,
las columnas, el techo. Si podemos entender el sistema según sus partes, podremos modelar
sistemas cada vez más grandes.

De la misma manera que ocurre con la Arquitectura de Software, existen múltiples definiciones
sobre el rol de los arquitectos de software. Se podría incluso citar una definición por autor. En
general esto puede ser causado porque se ubica a los arquitectos en el contexto de una
organización en particular, con las propias necesidades y requerimientos de esa organización. La
realidad parece indicar que es poco probable que se pueda dar una definición de arquitecto
transversal a cualquier organización, y definir un estereotipo de arquitecto que especifique cuáles
son sus responsabilidades y habilidades necesarias dentro de un proyecto. Lo que sí es posible es
defiŶiƌ pƌototipos de aƌƋuiteĐtos ͞a ŵuy gƌaŶdes ƌasgos͟ y apliĐaƌ Đada uŶo de estos aƌƋuetipos eŶ
una situación en particular, dependiendo del contexto de la empresa, del proyecto y del equipo de
trabajo.

El papel del arquitecto ha estado presente desde el inicio de la vida del hombre en la tierra, desde
la prehistoria existían los Arquitectos, aunque no hubieran sido llamados de esa manera, y es que
para hablar de un Arquitecto tenemos que necesariamente hacer referencia a su significado
etimológico. La palabra Arquitecto nos llega de los griegos, quienes bautizaron tal papel con la
palabra ἀǏχLjτέljτων(architécton) que define al director de una construcción. Esta palabra proviene
de la unión de dos raíces muy fuertes ἀǏχόǐ(archós), que significa guía y τέljτων(técton) que
significa constructor. Pero al español llegó gracias a los romanos que llamaron Architectus, a los
grandes guías de las impresionantes y avanzadas obras civiles del imperio mas grande del mundo
antiguo.

¿Cual es pues el papel del Arquitecto de Software que ha heredado el honor de tan noble
asociación?. Este trabajo presenta un conjunto de definiciones provenientes de las fuentes mas
representativas en el ámbito del software y algunas de ellas recomendadas como punto de
referencia específicamente para el tema de arquitectura de software.
 3 El Arquitecto de Software

Los arquitectos diseñan estructuras que encajen con las necesidades humanas. Las estructuras
pueden ser ensambladas con palos y piedras o software de computadora y hardware, pero el rol
del arquitecto continúa siendo el mismo. Los arquitectos están la mayoría del tiempo escuchando
los clientes, entendiendo a profundidad sus necesidades y recursos, investigando y documentando
ordenadamente, creando una visión practica de una estructura y creando un mapa de la misma. Así
como se construye una estructura, el arquitecto interviene en favor del cliente, asegurando que el
resultado sea fiel al plan y guiando la visión del resultado entre la tempestad de los cambios en el
diseño, las crisis y las ambigüedades.

Abogar por el cliente es la piedra angular del rol del arquitecto. Para lograr el rol de un verdadero
abogado, el arquitecto necesita un extenso repertorio de elementos de diseño en un aspecto de
elección libre de cualquier atadura. Un arquitecto deja de ser un verdadero apoyo al cliente si se
encuentra atado a un conjunto de tecnologías, herramientas o metodologías, restringiendo así las
soluciones disponibles al cliente. Los estilos arquitectónicos individuales y las preferencias emergen
y son impuestas, como siempre han sido, por el cliente, pero estas deben corresponder a los
refinamientos y discernimiento de una mente entrenada, no las elecciones forzadas por los límites
de la educación o la experiencia. Quien ha sido constructor toda su vida, no importa que talentoso
sea, no necesariamente tiene el perfil de un arquitecto. Al que tiene un cincel en la mano, todo
parece convertírsele en roca.

Las palabras significan cosas. Un arquitecto es un Arquitecto, no un ingeniero, no un programador,

no un científico, no un webmaster o un director de proyecto. La palabra Arquitecto es distinta en el
negocio de la construcción. En la construcción de software, muchos se apropian de la importancia
del título, pero fallan en representar bien el rol. El arquitecto construye no desarrolla. Los edificios
no son desarrollados. Desarrollar es hacer crecer, evolucionar y descubrir. Los arquitectos ven en
perspectiva la construcción, no guían el desarrollo. Teóricamente, el desarrollo es infinito y esa es
una lección que ya deberíamos haber aprendido.

Presentar la profesión del Arquitecto de software implica definir una actividad, pero sin limitarla.
Los programadores, ingenieros, diseñadores y en general todos los profesionales de la construcción
tendrán roles muy diversos y sus esfuerzos efectos mayores. De igual forma que los
arquitectos/constructores en el negocio de la construcción, los arquitectos de software pueden
interpretar un papel doble, cada uno con tareas claras y expectativas concretas. Esta claridad
permite investigaciones, libros, herramientas y metodologías que puedan ser enfocadas a un
proceso arquitectónico específico. Los clientes entenderán cada vez más los roles y la secuencia en
la que aparecen durante la construcción de software, llegarán incluso a tener los planos del
sistema.
Las siguientes fases definen el papel del arquitecto en el proceso de construcción de software,
conceptualmente siguiendo las fases de la construcción y los servicios arquitectónicos descritos por
el Documento del Instituto Americano de Arquitectura B163 (AIA por sus siglas en inglés). Estas
fases aplican a todos los proyectos de construcción de software, incluyendo aquellos que usan
métodos iterativos o incrementales. Muchos profesionales de software han sacado una analogía de
la construcción de edificios para describir su proceso, ya que ella es una analogía verdadera
entendible por los clientes. Esta analogía primaria encierra la respuesta a las crisis en la
construcción de software y le dará forma a su futuro.

 Prediseño

En esta fase el Arquitecto escucha y entiende el alcance del proyecto, los puntos claves del
diseño según el cliente, los requisitos y las expectativas. El arquitecto también estudia el
contexto del proyecto -la empresa entera de la que hace parte el proyecto-. Los recursos del
cliente son determinados (los financieros y los intelectuales), y los problemas y necesidades que
el cliente desea resolver. El arquitecto identifica las posibles soluciones disponibles usando
tecnología y cambios organizacionales, administrativos o de producto. Con la interacción del
cliente y el arquitecto, comienza a tomar forma una dirección administrativa refinando su
entendimiento hasta que una visión compartida emerge. Luego un presupuesto y cronograma
general son definidos.

 Análisis del Dominio

El arquitecto se sumerge profundamente en el contexto y documenta el dominio para el cual el

sistema será construido, y aprende el detalle de cada uno de los requisitos del cliente. Los
comportamientos deseados del sistema son definidos. El arquitecto determina el entorno
tecnológico del cliente y alcance de las interacciones que requiere realizar. El glosario y los
conceptos claves del dominio son adecuadamente definidos.

 Diseño Esquemático

El arquitecto prepara diseños de tipo arquitectónico que muestran las características del
dominio y la estructura tecnológica. Se definen los puntos claves de la interfaz gráfica (la
apariencia y sensación del sistema). En este punto se construyen prototipos si son necesarios.
Se estiman los riesgos de la migración.

 Desarrollo del Diseño

El arquitecto continúa con la profundización el detalle del tipo de solución a generar y refina
cada vez más los artefactos. Todos los documentos, glosarios y diseños generados son
finalizados en esta etapa, esto implica la muy importante validación del cliente.

 Documentación del Proyecto

El arquitecto se concentra en los requisitos que se construirán el sistema. Se documenta el tipo

de proceso de construcción a desarrollar, los roles de los miembros del equipo y las secuencias
de trabajo a realizar. Se escribe la guía de construcción y la guía de pruebas. El arquitecto
especifica las herramientas y las metodologías si es necesario. Todos estos y otros detalles que
se necesiten por aquellos que van a construir el sistema, son definidos en esta parte.
  Selección y Contratación (staffing)

El arquitecto acompaña la identificación y selección de los constructores o desarrolladores

concretos del sistema. Para proyectos que son subcontratados, se solicitan ofertas a los
contratistas y potenciales participantes, el arquitecto toma parte activa en la elección de los
oferentes. Los detalles de los costos del proyecto, las secuencias de trabajo y la firma de los
contratos, también son asistidos por el arquitecto.

 Construcción

La supervisión del arquitecto durante la construcción del producto asegura que la visión del
cliente sea entendida y ejecutada correctamente. El arquitecto revisa los diseños detallados de
la construcción, analiza problemas, evalúa nuevos requisitos y plantea modificaciones cuando
son necesarias. El arquitecto diseña los cambios aceptados, calcula el impacto global en diseño y
costo, y define la secuencia de cambios que tienen que ser generados, para luego participar en
las actividades de pruebas y revisiones de usuario final para asegurarse que cumplan con la
expectativas del cliente.

 PostConstrucción

El arquitecto acompaña al cliente con la puesta en producción y la migración al nuevo sistema.

El arquitecto puede, si así lo desea, vincularse con la capacitación de los operadores y usuarios
del nuevo sistema. Posterior a esto, el arquitecto asiste al cliente en temas relacionados con
garantías y aplicación de procedimientos de mantenimiento. Y cuando todo ha finalizado el
arquitecto y el cliente se reúnen para recordar las dificultades y los triunfos; hacen una gran
fiesta en un restaurante Mexicano, cantan con el mariachi para todos los desarrolladores,
empleados, clientes y directivos vinculados al proyecto, para así reírse en frente de todos
aquellos que constantemente dijeron que no podía hacerse y ahora permanecen mudos entre
1
los invitados sorbiendo sus margaritas .

1
Worldwide Institute of Software Architects
4. Mapa conceptual
5 Características de un Arquitecto de Software, por Peter Eeles de IBM

El arquitecto es una persona, equipo u organización responsable por la arquitectura

del sistema (IEEE 1471)

 Es un líder técnico. El arquitecto tiene competencias técnicas y de liderazgo, debe tener la

autoridad para tomar decisiones técnicas, ayuda a armar el equipo y a organizar el trabajo,
además constantemente comunica el valor de lo que se está haciendo.

 El rol puede ser llenado por un equipo con un líder claro. No siempre una persona tiene todas
las ĐoŵpeteŶĐias. UŶ ͞EƋuipo es uŶ peƋueño gƌupo de geŶte ĐoŶ ĐoŵpeteŶĐias complementarias
y comprometidos con el propósito, y con enfoques comunes por los que soŶ ŵutuaŵeŶte
ƌespoŶsaďles͟.

 El arquitecto entiende el proceso de desarrollo de software. El arquitecto debería tener

conocimiento del proceso de desarrollo, ya que este garantiza que todos los miembros del
equipo rabajen de manera coordinada. Un buen proceso define las funciones claramente. Dado
que el arquitecto participa a diario con muchos de los miembros del equipo, es importante para
el arquitecto entienda sus funciones y responsabilidades. A diario los desarrolladores apoyan su
trabajo en el arquitecto preguntando cómo hacer tal cosa, por lo tanto, existe una clara
coincidencia entre el papel del arquitecto y el papel de gestor del proyecto.

 EŶtieŶde el doŵiŶio del ŶegoĐio. UŶ doŵiŶio es uŶ ͞áƌea de ĐoŶoĐiŵieŶto o aĐtiǀidad

caracterizada por un conjunto de conceptos y terminología entendida por los profesionales del
áƌea͟ y peƌŵite iŵagiŶaƌ ƌeƋuisitos ͞pƌoďaďles͟ y aŶtiĐipaƌ Đaŵďios.

 Tiene conocimiento tecnológico, pero no necesariamente experticia profunda. Dado que la

tecnología cambia con cierta frecuencia, es esencial que el arquitecto se mantenga actualizado
con los cambios tecnológicos.

 Tiene competencias de diseño.

 Tiene suficiente competencia de desarrollo como para comunicarse con el equipo.

 Es un buen comunicador.

 Toma decisiones.

 EŶtieŶde la ͞polítiĐa͟ de la eŵpƌesa.

 Es un negociador, debe explicar a stakeholders del proyecto las consecuencias de sus

opciones o alternativas de arquitectura.
6 El Rol del Arquitecto de Software según el Software Engineering Institute

¿Cuales son las responsabilidades, competencias y conocimientos de un Arquitecto de Software?.

Para responder a esta pregunta, desde hace unos cuantos años el SEI (Software Engineering
Institute) ha estado recopilando comentarios de las personas sobre las responsabilidades de un
arquitecto de software. Este es un compendio, en el que se resaltan los aspectos más comúnmente
citados (todas las respuestas individuales y sus autores pueden ser consultadas en el sitio web del
SEI) y que a continuación enumeramos:

 Elaborar la arquitectura correcta para solucionar el problema o necesidades del cliente.

 Definir y documentar la solución elaborada. Asegurarse que todos los involucrados la estén
utilizando y la estén utilizando bien.

 Asegurarse que se aplica en etapas de manera coordinada de tal forma que toda la
organización pueda apropiarse de ella antes de que sea completada.

 Asegurarse de que la arquitectura de software sea acorde con el sistema deseado.

 Actuar como el embajador de la propuesta arquitectónica.

 Hacer que la gerencia la entienda hasta el nivel necesario.

 Asegurarse de que el modelamiento sea correctamente realizado.

 Conocer cuales cualidades sistémicas, como el rendimiento, deben alcanzarse y en que

medida.

 Responder sobre las inquietudes relacionadas con la selección de herramientas y ambientes

de desarrollo.

 Identificar e interactuar con los interesados en el proyecto para asegurarse que sus
necesidades son satisfechas.

 Asegurarse que la arquitectura no es solamente la correcta para la operación del sistema,

sino que además es la correcta para su soporte y evolución.

 Resolver conflictos y ayudar a generar acuerdos.

 Solucionar problemas de tipo técnico.

 Mantener la moral, tanto en el interior del grupo de arquitectura como al exterior. Esto
último es realizado proponiendo un diseño compacto cuando se requiera y entregando
presentaciones y materiales que le permitan a todas las personas en la organización saber
que se encuentran en el camino correcto.
 Entender y planear las rutas de evolución del sistema, diseñar un plan que guíe la adopción
de nueva tecnología.

 Gerenciar las estrategias de identificación y mitigación de los riesgos asociados con la

arquitectura.
7 El Rol del Arquitecto de Software según Rational Unified Process - RUP

El arquitecto de software tiene la responsabilidad general de conducir las principales decisiones

técnicas, expresadas como la arquitectura de software. Por lo general, esto incluye la identificación
y documentación de la arquitectura de los aspectos importantes del sistema, incluidos los
requisitos, diseño, implementación y despliegue, es decir, las vistas del sistema.

El arquitecto se encarga también de proporcionar la justificación de estas decisiones, buscar el

equilibrio entre los stakeHolders participantes, haciendo disminuir los riesgos técnicos, y
garantizando que las decisiones sean comunicadas, validadas y adoptadas efectivamente.

El Arquitecto de Software debe poseer la madurez, visión y la experiencia que permite comprender
los problemas de manera rápida y tener un juicio crítico cuando existe información incompleta, por
ejemplo. Más concretamente, el arquitecto de software, o miembros del equipo de arquitectura,
deben combinar estas capacidades:

 Experiencia en el dominio del problema, a través de una profunda comprensión de los

requisitos, y el dominio de la ingeniería de software. Si hay un equipo, estas cualidades se
pueden propagar a través de los miembros del equipo, pero al menos un arquitecto de
software debe tener la visión global del proyecto.

 Liderazgo con el fin de gestionar el esfuerzo técnico a través de los diversos equipos, y
tomar las decisiones acordes aun bajo presión. Para ser eficaz, el arquitecto de software y el
jefe de proyecto debe trabajar en estrecha colaboración. El arquitecto de software debe
tener la autoridad para tomar decisiones técnicas.

 Comunicación para ganar confianza, para persuadir, motivar, y guiar. El arquitecto de

software no puede conducir por decreto, sólo con el consentimiento del resto del equipo
del proyecto. El arquitecto de software debe ganarse el respeto del equipo del proyecto, del
director del proyecto, del cliente, y la comunidad de usuarios, así como el equipo de
gestión.

 Orientación por objetivos y pro-actividad con un implacable enfoque en los resultados. El

arquitecto de software es la fuerza impulsora detrás del proyecto, no un soñador o
visionario. La carrera de un exitoso arquitecto de softǁaƌe es uŶa laƌga seƌie de ͞optiŵas͟
decisiones adoptadas en la incertidumbre y bajo presión. Sólo los que puede centrarse en
hacer lo que hay que hacer tendrán éxito en este entorno del proyecto.

Desde el punto de vista de expertos, el arquitecto de software también debe abarcar el Papel de
Diseñador, sin embargo, a diferencia del diseñador, el arquitecto de
software:

 Tiende a ser un generalista en lugar de un especialista, a sabiendas de muchas tecnologías

de alto nivel en lugar del nivel de detalle.
El Arquitecto de software es un rol en un proyecto de desarrollo de software, el cual se realizan
varias actividades y se tienen responsabilidades como se muestra en el siguiente gráfico
 8 El Rol del Arquitecto según SUN SL-425

El aƌƋuiteĐto de softǁaƌe, segúŶ “UN MiĐƌosysteŵs ͞AƌĐhiteĐting and Designing J2EE Applications
SL-ϰ2ϱ͟, deďe Đuŵpliƌ ĐoŶ las siguieŶtes ĐaƌaĐteƌístiĐas y ƌoles.

 Visualiza el comportamiento del sistema.

 Crea los planos para el sistema.
 Define el modo en que los elementos del sistema trabajan en conjunto.
 Distingue entre los requisitos funcionales y no funcionales del sistema.
 Se encarga de la integración de los requisitos no funcionales en el sistema.
 El arquitecto comunica el diseño del sistema a otros miembros del equipo.
 El arquitecto es un miembro de un equipo de desarrollo.

Una de las definiciones de la arquitectura de software considera que la arquitectura es un proceso

creativo, como tal puede tener aspectos positivos y negativos. Los Arquitectos deben tratar de
equilibrar la creatividad con la ciencia en forma de modelos, marcos, y patrones.

Para construir una arquitectura, el arquitecto utiliza lo siguiente:

 Fundamentos de Arquitectura.
 Experiencia: Las mejores prácticas, Marcos, patrones y (Expresiones Idiomáticas)Idioms.

Un arquitecto crea una arquitectura con los siguientes objetivos en mente.

 Modularidad.
 La protección y la exposición.
 Componentes Extensibles.
 Funciones y responsabilidades.
 Contratos.
 Comportamiento Adaptable.
 9 El Rol del Arquitecto Microsoft

Microsoft clasifica los arquitectos de la siguiente forma:

 Enterprise Architect/Chief Architect: El arquitecto Empresarial es el responsable de la

ejecución de la visión del CIO y la estrategia de TI. Incluye la definición de programas
estratégicos, la selección de plataformas tecnológicas adecuadas, y proporcionar
orientación para las implementaciones. El arquitecto Empresarial ayuda al CIO a asegurar
que las inversiones en TI están alineados a la estrategia de negocio, y a proporcionar
ventaja competitiva para la organización. La persona también es responsable para definir
las normas y directrices, y los lineamientos de gestión para adaptar la aplicación a las
normas definidas y directrices. En algunas organizaciones, esta tarea se fusiona con la del
CIO.

 Solution Architect: El arquitecto de Soluciones es el responsable de la ejecución de un

programa estratégico de TI. Esto incluye la definición de la solución arquitectónica para el
programa, la selección de plataformas tecnológicas acordes a la estrategia de la empresa,
comunicación con el equipo de trabajo, y la toma de decisiones sobre cuestiones técnicas
durante la ejecución del proyecto. Generalmente tiene que mediar entre las empresas y
equipos de tecnología y otros grupos. En algunas organizaciones, este papel se define
simplemente como "arquitecto". El puesto de alto nivel tiene el título de "Arquitecto
Líder͟.

 Technical Architect: El arquitecto técnico es por lo general un especialista en una

tecnología particular. Esta persona tiene conocimiento experto de la tecnología y las
funciones de la misma, los componentes que la integran, y comprende los puntos fuertes y
las limitaciones de la tecnología. Esta persona es responsable de determinar la aplicabilidad
de la tecnología, para definir la mejor arquitectura posible utilizando una tecnología en
particular, y también para guiar al equipo en la aplicación de la solución. En general, del
arquitecto técnico se espera conocer las distintas herramientas de proveedores en el
ámbito de la tecnología, las últimas tendencias en el mercado, de arquitectura y diversas
alternativas para aplicar la solución.

La siguientes gráfica muestra la relación entre estos tres roles con la tecnología y la estrategia de
la organización.
Además existen los,

 Infrastructure architects. El arquitecto de Infraestructura es responsable de las decisiones

del área de infraestructura, de mantener el entorno de TI y los usuarios finales, y de
comunicarse constantemente con los ingenieros que mantienen áreas específicas de la
infraestructura. Se encargan de crear una arquitectura que cumple con los acuerdos de
niveles de servicio de las necesidades de los empresarios y apoya las aplicaciones y
soluciones que se requieren para operar en el día a día de las empresas.

MiĐƌosoft eŶ su pƌogƌaŵa de ͞AƌƋuiteĐto MiĐƌosoft͟ considera algunas características comunes a

todos los arquitectos independiente del tipo de arquitecto. Algunas de estas características son:

 Poseer fuerte visión para los negocios: Consiste en entender los costos de capital operacional y
considerar cada uno de estos mientras se crea la solución. Leer estados financieros, tener
conversaciones con funcionarios financieros y tener una comunicación acertada con los dueños
de negocios para justificar los proyectos y calcular el rendimiento de un proyecto.

 Pensamiento visionario: Durante la participación en un proyecto, el arquitecto debe considerar

y proyectar la tecnología en el futuro, visionando los cambios que se producen en los negocios
de los clientes, y la mejor manera de aprovechar las ventajas de la solución tecnológica actual
en el futuro.

 Investigar nuevas tecnologías: El arquitecto debe estar en continua investigación de nuevas

tendencias en tecnología, arquitectura de TI y las aplicaciones empresariales.
 Comprender Frameworks arquitectónicos y las mejores prácticas: Los arquitectos entienden
cuáles son los Frameworks de arquitectura y empresariales y su valor en un proyecto. Los
arquitectos seleccionan y usan metodologías en los proyectos, entienden el funcionamiento de
Frameworks y cómo la solución será desarrollada, y el comportamiento antes y después del
despliegue. Entienden el ciclo de vida de un proyecto y de una solución.

 Seguir y divergir a la vez: Cuando se trabaja en un entorno particular o en un proyecto

especifico, los arquitectos deben tener la capacidad de personalizar o modificar Frameworks y/o
las metodologías utilizadas para lograr una solución a un problema o requisito de negocio.

 Poder para desarrollar rápidamente profundo conocimiento en una tecnología: Ganando

profundidad en múltiples tecnologías anteriores, el arquitecto puede asociar o transferir la
capacidad de aprender otros métodos para investigar y para ganar rápidamente experiencia en
nuevas tecnologías.

 Pueden trabajar con ambigua o incompleta información: Los Arquitectos deben colaborar en el
proceso de indagación de la información para llegar a una solución, pero pueden empezar a
trabajar con información limitada y conforme el proyecto progresa, tomar decisiones de
compensación o equilibrio con el fin de mantener una solución que cumpla con los objetivos, y
continuar satisfaciendo las exigencias de negocio que al principio fueron identificadas. Sin
embargo el arquitecto debe saber claramente si con la información limitada puede empezar a
trabajar sin poner en riesgo el proyecto mas adelante por cambios drásticos o si el proyecto
debe suspenderse antes de recopilar información mínima para empezar las tareas, es
importante el trabajo conjunto de todo el equipo de proyecto en este aspecto.

Microsoft posee un programa de certificación de Arquitectos (Microsoft Certified Architect

Program), el cual sirve para identificar a los mayores expertos en Arquitectura TI del sector. Se
trata de arquitectos que pueden utilizar múltiples tecnologías para resolver problemas
empresariales y ofrecer cifras y parámetros a los negocios para ayudarles a determinar el éxito o el
fracaso de los proyectos que dirigen.

A continuación presentamos también las Competencias de un arquitecto según Microsoft

.
En esta pirámide, la experiencia y cualidades de liderazgo constituyen los pilares fundamentales del
rol del arquitecto. También se necesita perspicacia técnica, buenas habilidades de comunicación,
entender el dominio del problema antes de diseñar una solución y la capacidad de gestión.

El arquitecto de software debe tener una mentalidad estratégica, es decir, la habilidad de ver las
cosas a 50.000 pies de altura, a un nivel estratégico, abstraerse de la complejidad operativa. Se
trata de adoptar una visión más amplia.

Muchos recursos educativos y las certificaciones están disponibles para alcanzarlas. Además los
arquitectos con experiencia, son otra fuente importante de recursos, ya que la información por sí
sola es insuficiente para el desarrollo de muchas habilidades necesarias. Los aspirantes a los
arquitectos deben considerar muchos factores a la hora de hacer carrera, desde los tipos de
proyectos para el acceso a los mentores o expertos. La arquitectura es exigente pero gratificante
profesión, sino que tiene determinación y una buena planificación para desarrollar plenamente sus
habilidades y madurar en el papel.
 10 El Papel del Arquitecto según Bredemeyer Consulting

Pude definirse de manera simplona que un Arquitecto es aquel que hace Arquitecturas y sus
responsabilidades se restringen a hacer bien su trabajo. Esto pude incluir articular la visión
arquitectónica con las necesidades del cliente, conceptualizar y experimentar con diferentes
estrategias arquitectónicas; crear modelos, componentes y documentos de especificación de
interfaces.

Sin embargo, cualquier arquitecto experimentado sabe que el papel no solo encierra estas tareas
de tipo técnico, sino que existen otras de un carácter más diplomático y estratégico por un lado y
por otro lado tareas de consultoría y asesoría. Un sentido coherente del negocio y una adecuada
estrategia tecnológica son necesarias para vislumbrar la arquitectura que solucionará los
problemas del cliente, dados los objetivos y restricciones al arquitecto en la organización. Las
actividades en esta área incluyen la escucha activa a los interesados del proyecto para entender de
manera profunda sus intereses y las metas a satisfacer, implica también crear mapas tecnológicos y
estrategias de diferenciación, a la par con la realización de afirmaciones sobre tendencias
tecnológicas y sus consecuencias en la estrategia técnica del proyecto y la arquitectura planteada.

El arquitecto (o equipo de arquitectura) necesita tener empatía con una variedad de grupos de
interesados en el proyecto, incluyendo la gerencia a diferentes niveles, analistas de negocio o de
ventas y sobre todo los desarrolladores. El arquitecto necesita balancear su participación con la
necesidad de tomar en cuenta las múltiples opiniones de su equipo de trabajo. Mientras más
amplio horizonte tenga la arquitectura, mas ajustada será a la optima. El arquitecto tiene que pasar
por encima de muchas "Políticas Organizacional" para lograr convencer a muchos interesados en el
proyecto, para comunicar extensivamente y trabajar con diversas redes de personas que influyen
en el éxito de la arquitectura.

Pero lograr "vender" la arquitectura no es suficiente. Todos los que estén vinculados con su
implementación necesitan entenderla. Los documentos tipo "ladrillo" son famosos por ser
excelentes "recogedores de polvo". La participación temprana de los desarrolladores más
experimentados trae buenas ideas en el proceso de definición de la arquitectura y también crea un
amplio entendimiento de los deseos de los desarrolladores y el costo de su implementación.

Adicionalmente para proyectos grandes, puede ser bastante útil crear tutoriales que expliquen
cuales fueron las decisiones que llevaron a proponer la arquitectura objetivo, ya que durante los
diversos ciclos de construcción es necesario realizar ajustes.
El arquitecto también es un mentor y un entrenador, trabajando con los desarrolladores para
motivarlos cuando los retos aparecen, sobretodo cuando tienen un amplio impacto o son críticos
para el éxito del sistema. Más allá, el arquitecto no sólo debe liderar su equipo y la comunidad de
desarrolladores sino que debe liderar y motivar la organización completa en la dirección técnica
adecuada.

¿Quien es adecuado entonces para el papel de Arquitecto?, pues, muy frecuentemente el

convertirse en "Arquitecto" es una promoción ofrecida a los desarrolladores muy hábiles en un
esfuerzo por retenerlos. Desafortunadamente no todos los técnicos superdotados tienen el talento
y las competencias que los hacen buenos arquitectos. Aún así, el título genera expectativas, en el
"arquitecto" y en el resto de la organización, de las responsabilidades asociadas con el cargo. Esto
puede generar un montón de conflictos para una persona fuertemente orientada a la parte técnica,
que repentinamente se ve enfrentada con políticas empresariales y exigencias de una
comunicación efectiva y fluida. Los mejores arquitectos entonces, son expertos en tecnología que
infunden respeto en la comunidad técnica, también son buenos estrategas, excelente diplomáticos,
consultores, asesores y líderes.

Para desarrollar en 1995 un taller en Hewlett-Packard sobre arquitectura, Bredemeyer Consulting

estudió muchos proyectos arquitectónicos, revisó literatura al respecto e incluso estudió el proceso
la Arquitectura de edificios. Tal sería el inicio de una larga relación con cientos de arquitectos de
diferentes campos de la industria que le han permitido a esta empresa consultora un
entendimiento profundo de la arquitectura y del proceso Arquitectónico como tal.

Basados en este entendimiento, y mirando las tendencias actuales de la arquitectura, se ha podido

establecer un Marco de Trabajo se han identificado varias áreas de actividad criticas o dominios de
competencia, que aparecen definidamente en el papel de arquitecto. Estos son Tecnología,
Estrategia Organizacional, Política Empresarial, Asesoría y Liderazgo. Cada uno de ellos tiene sus
propios elementos de conocimiento, actividades y características personales que hacen de un
arquitecto ser exitoso en cada uno de dichos aspectos. Estos elementos pueden ser agrupados
según apunten a las competencias del Saber, del Saber Hacer y del Saber Ser. El siguiente cuadro
muestra como se relacionan entre si estos elementos.
 ¡;; Unders1and \i'r
1technicalissuesare Proiotypefexperimen:fsimura e Pra.:t<:alfpragrat<:
o
C5 key to sucoess
e ardieuraldoeurnel'll! rn 1ful
<: Oeve'opment rne--:hods anc ll'ld presentaions
Tolerant of aml:iguity,willing to
& modeling
e
r...t""nrl.'lt.•lyoti<.fm-;:atiiT.; back·
tr;110rk, mu"l """ ddinn<.
fl<. Take a system vie
Good at vortina1an abs1'ac1!evel
sctta:lon1ee11M¡Ues 1
8UicJ ·uv;te<J adlf.ISO( reratiOnsnps corvnlt:ed10 ahers suocess

Constúing frameworks Unders1a1dwhat he:lewant Empat:rwi. c.approachable

.:111'\d needfrom !:he: :clt:1eo!ure
An tffec:ive change agent process

-"
.:J Help devtlopers se@ the va\beot the sawy
it.....h...,. ;: nrt t;:II'V{ hrl\\
" use ilsuccessMy
A good mentor.teacher

e ' Mentor jllliorarchiteets

YCM organ.-,zatbn's lnflntncebusiness strategy Visbnary

businessstrategy
Tr.lln*'!ebu ine:....,tcgy into ·eoh En1repreneuri: l
an0 rat.onale
>- .-.:alvis:«'and stra'!tgy

"'
YCMoompet icn(procructs strategies
9 l 1Jnrt,.r<.b,rt Nl<1. n"""';: nrt
anO prooesws:
tl! m;:rk..r trends
¡¡; YCM company'business practx:es
Capbncustomer.ot9.)niza.tona!
and businessrequiremerrs on the
architectu'e

Wto the key pbyers are inthe Corrwnuncae.oomi'I'U'1icate. 00!'1· AJñ to se@ fron and se1te I'I'Mt':pi le
"o Otga· municae viewpoi'tls
' niz.aton
thWit, t lti:1\Yclllo,, illfÁ.PI:I-..:"" Cv1 fAA:I II ...1111 <l
V\l' "'l U III:')' W<lll., W.h lAbilo"".tiiU
penonal Sel the ViSion.kHP he uldt.o:. AmbW.ous and
visionave
ro driven Pa-:ient and
¡; Take andre1ake the pusl eof all
no1
cri&:almuenoers ofihe
architedUre grd..ect Res3tn1
·e
Sensifve o wh re the powr6 and
g Yoorself Se ! eamoone:xt
hoY. 1flows¡,yourorganizlion

"' (vison) Make

You and oh.:erssee youasaleada

Ch;;risma&:and a-edíb.'.e
deciisions (s1ick)
Yoube!ei ve ij c n and shodd be
8uicf teans don:.and thai 'JOU canlead the
a. Mnt v;: t,:.
ef.ott
:E
You are oommited.de<fcaled. p-
"; as- siorate
¡';
 11 Conclusiones

El término Arquitecto de Software se ha convertido en el título de moda en toda empresa de

sistemas o con un área propia de sistemas, aunque es común que muchas de las tareas relevantes
de un proyecto puedan ser perfectamente resueltos con desarrolladores experimentados, sin tener
la necesidad de contratar un arquitecto. Muy frecuentemente se tiende a confundir estos dos
perfiles, que son abismalmente diferentes. También es importante notar la diferencia entre los
͞guƌúes teĐŶológiĐos͟ y los ǀeƌdadeƌos aƌƋuiteĐtos. Estas ĐuestioŶes auŵeŶtan la confusión
existente sobre qué es un arquitecto y cuáles se supone tendrían que ser sus responsabilidades.

El rol del arquitecto es un rol crítico en los proyectos, se focaliza en la calidad de servicio y lidera el
proceso de definición y la implementación de la arquitectura. El arquitecto reutiliza
implementaciones de arquitecturas exitosas, frameworks y patrones de diseño y no es un
diseñador en un proyecto. Un Arquitecto es un facilitador, no toma decisiones unilaterales,
irracionales, evita riesgos en los proyectos y agrega valor.

A diferencia de un programador, el Arquitecto de Software debe dominar la mayor cantidad de

tecnologías de software y prácticas de diseño, para así poder tomar decisiones adecuadas para
garantizar el mejor desempeño, reuso, robustez, portabilidad, flexibilidad, escalabilidad y
mantenibilidad de las aplicaciones. Estas decisiones sobre la estructura y dinámica de la aplicación
son plasmadas en una notación formal estandarizada como lo es UML.

Como base, el rol de los arquitectos suele comprender las tareas de: definición de las vistas de la
arquitectura de una aplicación, dar soporte técnico-tecnológico a desarrolladores, clientes y
expertos en negocios, conceptualizar y experimentar con distintos enfoques arquitectónicos, crear
documentos de modelos y componentes y especificaciones de interfaces, validar la arquitectura
contra requerimientos, suposiciones y además tener una dosis de estrategia y política, o sea, ser,
en parte, un consultor.
 12 Bibliografía

WORLDWIDE INSTITUTE OF SOFTWARE ARCHITECTS. Role of the Software Architect [en línea]
<http://www.wwisa.org/wwisamain/role.htm> [citado en 15 de Junio de 2008]

CARNEGIE MELLON UNIVERSITY. What Are the Duties, Skills, and Knowledge of a Software Architect?
[en línea] <http://www.sei.cmu.edu/architecture/arch_duties.html> [citado en 16 de Junio de 2008]

MICROSOFT CORPORATION. What Architect Job Roles Are Recognized By the Microsoft Certified
Architect Program? [en línea]
<http://www.microsoft.com/learning/mcp/architect/specialties/default.mspx> [citado en 11 de Julio de
2007]

IBM SOFTWARE GROUP. Characteristics of a Software Architect [en línea]

<http://www.ibm.com/developerworks/rational/library/mar06/eeles/> [citado en 15 Marzo 2006]

BREDEMEYER. Architect Competency Framework [en línea]

<http://www.bredemeyer.com/pdf_files/ArchitectCompetencyFramework.PDF> [citado en 16 de Junio
de 2008]

Architecting and Designing J2EE Applications (SL-425), Training Courses, Sun Education Services

pdf. The Role of an Architect, the Architecture Journal by Amit Unde, Edicion #15. Page 7-9.

Role: Software Architect, Documentation Rational Unified Process Version 7.0, Copyright (C)
IBM Corporation 1987, 2005.