Profesor:
Sorey Bibiana García Zapata
Departamento de Informática y Sistemas UNIVERSIDAD EAFIT
Medellín 2008
Arquitectura de Software Docente: Raúl de Villa Cano.
1 Tabla de Contenido
2 Introducción
..........................................................................................................................................
3
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
Arquitectura de Software Docente: Raúl de Villa Cano.
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
definir prototipos de arquitectos “a muy grandes rasgos” y aplicar
cada uno de estos arquetipos en
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 ρχιτκτων(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 τκτων(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.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
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 un 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.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
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.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
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 los invitados sorbiendo sus
margaritas1.
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 competencias. Un “Equipo es un
pequeño grupo de gente con competencias complementarias y
comprometidos con el propósito, y con enfoques comunes por los que
son mutuamente responsables”.
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 trabajen 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.
Entiende el dominio del negocio. Un dominio es un “área de
conocimiento o actividad caracterizada por un conjunto de conceptos
y terminología entendida por los profesionales del área” y permite
imaginar requisitos “probables” y anticipar cambios.
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.
Entiende la “política” de la empresa.
Es un negociador, debe explicar a stakeholders del proyecto las
consecuencias de sus opciones o alternativas de arquitectura.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
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.
Arquitectura de Software Docente: Raúl de Villa Cano.
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.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
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 software es una larga serie de “optimas”
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.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
Hace más amplias las decisiones técnicas en el dominio de la
solución, y por lo tanto, debe tener amplio conocimiento y
experiencia, así como la comunicación y habilidades de liderazgo,
son fundamentales.
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.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
8 El Rol del Arquitecto según SUN SL-425
El arquitecto de software, según SUN Microsystems “Architecting and
Designing J2EE Applications SL-425”, debe cumplir con las
siguientes características y roles. 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.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
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.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
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.
Microsoft en su programa de “Arquitecto Microsoft” 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.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
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 .
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
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.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
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.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
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.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
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 “gurúes tecnológicos” y los verdaderos
arquitectos. Estas cuestiones aumentan 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.
Universidad EAFIT Especialización en Desarrollo de Software
Arquitectura de Software Docente: Raúl de Villa Cano.
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]
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]
<http://www.bredemeyer.com/pdf_files/ArchitectCompetencyFramework.PDF>
[citado en 16 de Junio
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.