Funciones Principales de un Arquitecto de Software

Me han preguntado recientemente cuales son las funciones de un Arquitecto de Software, termino que me suele hacer reír y que siempre digo que en menor y mayor medida casi todos somos un poco Arquitectos de Software, yo he recopilado estas funciones:

 

  • Arquitectura: Definición de arquitectura de los sistemas, vista física, vista lógica, principios de arquitectura, seguridad, etc.
  • Selección de Software: Pilas de aplicaciones, bases de datos, librerías, frameworks, estándares tecnológicos, etc.
  • Selección de Infraestructura: Sistemas Operativos, hardware, redes, sistemas de recuperación, etc.
  • Requisitos no Funcionales: Rendimiento, escalabilidad, seguridad, etc.
  • Liderazgo: Liderazgo Técnico, responsabilidad y autoridad, dirección de equipos, etc.
  • Coaching y Mentoring: Ayuda sobre problemas técnicos, ayuda en la evolución profesional, etc.
  • Metodología de Proyectos: Estructura de Proyectos, Metodologías (Waterfall, Scrum, RUP, XP…).
  • Procesos de Desarrollo: Control de versiones de código fuente, procesos de construcción, integración continua, automatización de pruebas y otros procesos y herramientas de desarrollo.
  • Prácticas y Estándares: Estándares de codificación y libros blancos, selección de herramientas, etc.
  • Diseño, Desarrollo y Pruebas: Diagramas UML, codificación, pruebas unitarias, etc.
  • Experiencia: Conocimiento sobre tecnologías y arquitecturas.
  • Estar al día en cuanto a tendencias tecnológicas: Agile, Web 2.0, SOA, Lightweight Java EE, etc.

 

Yo añadiría tener pasión por nuestra profesión, seguramente me he olvidado de muchas funciones, os animáis a completarlo?

19 comentarios sobre “Funciones Principales de un Arquitecto de Software”

  1. Si, estoy de acuerdo!… a la gente le resulta «raro» que el «hacer programas de ordenador» requieran un arquitecto…

    Yo lo de la pasión, lo pondría lo primero: pasión, ilusión, compromiso, mejora continua…
    Pero como todas estas cualidades emocionales no se pueden medir… lo resumiría en todo lo relacionado con la toma de decisiones que afecten a la arquitectura y servicios, rendimiento, construcción de alto nivel, gestión de la configuración, entorno y tecnología.
    No creo lo relacionado con la organización del equipo (metodología, gestión, seguimiento, planificación…) le afecte a este perfil.

  2. Os habeis dejado una que para mi es la eterna abandonada en todas las organizaciones y compañias, que es la capacidad de asumir responsabilidades, esta es una rara cualidad que en muy pocas ocasiones podemos observar y desde mi punto de vista una de las más valiosas.

    Es para tener en cuenta a una persona que diga:»Sí yo tomé esta decisión porque pensé que era la mejor, me confundí y pongo mi puesto a disposición por este error»

  3. Eduardo, lo que comentas es «lamentablemente cierto». Muchas veces el arquitecto no es responsable de las decisiones que toma y yo me he encontrado con los «supuestos arquitectos» (el término me molesta de sobremanera) que en lugar de asumir una responsabilidad responden con frases como: cuando analizamos la situación inicial no existia necesidad de ESO QUE ME CUENTAS, por lo que no es error del arquitecto.

    Yo sigo pensando, que es imposible definir las tareas de este perfil de trabajo; sino mirad lo complicadas que son las certificaciones de arquitectos en diferentes tecnologías.

    Saludos

    PD: releo el comentario y se nota que cada tanto tengo «encontronazos» con los arquitectos, ¿no?. Espero que nadie se ofenda jeje

  4. Creo que una cosa es lo que debes saber para desarrollar el puesto y otra muy distinta lo que tienes que hacer. Es cierto que DEBES SABER hacer todas las cosas que mencionas, totalmente de acuerdo, pero en el día a día no tienes que hacer todas esas cosas, para eso está el equipo con el que trabajas (programadores, dba’s, documentadores, testers, analistas, etc.). Aquí lo importante es que el trabajo se delega y la responsabilidad se comparte.

  5. Javier tienes toda la razón, debes saber hacer todas esas cosas pero sin un equipo no harias nada por muy arquitecto que te consideres

  6. «en lugar de asumir una responsabilidad responden con frases como: cuando analizamos la situación inicial no existia necesidad de ESO QUE ME CUENTAS, por lo que no es error del arquitecto»

    Oskar, añade tambien a la lista «Clarividencia, dotes de adivino».

  7. Por cierto, yo creo que has mezclado varios perfiles en esa lista. El arquitecto como tal, al menos en mi empresa, se dedica sobre todo a los 3 primeros puntos, y al penultimo.

  8. Yo creo que mezclas Arquitecto de Software, con Ingeniero de Software, con Director de Proyecto, con Manager de Equipo….

    El caso es que en la informática hemos pasado todos de ser programadores cobrando una pasta a ser un montón de títulos rimbombantes peleando por sobrevivir a fin de mes.

    Lo que hace falta es profesionalizar nuestro trabajo, dando calidad y rendimiento, y reivindicar con ello nuestra importancia… y que nos llamen programadores, informáticos o «pica teclas»

    Un saludo y buen blog!

  9. Estimado Oskar, definitivamente no tienes, o no sabes, el concepto fundamental de una arquitectrua de software para poder, o intentar, definir las funciones de un arquitecto de software.

    Como siempre, como todo el mundo, se habla mucho y se dice poco, sobre un tema tan crucial para el éxito de un proyecto de sistemas.

    Te recomiendo que utilices una analogía con el tema de construcción de inmuebles. Ahí tienes la función ideal de un arquitecto de software: el arquitecto.

    En la lista, escueta por cierto, dices cualquier cosa menos lo que realmente hace un arquitecto de software.

    Así como la visión es de un visionario, pues así la arquitectura es de un arquitecto.

    Te lo digo de esta otra forma. Todos somos, de alguna u otra medida, arquitectos de software. Claro que sí. Si solicitas un trabajo de arquitectura de software a tres «arquitectos de software», los tres te darán un trabajo que hace lo que tiene que hacer; es dricr, lograr el objetivo. Pero si «abres» la arquitectrua para ver cómo llegó al logro, cada uno de ellos, te darás cuenta realmente la diferencia.

    Unos creen que un «sistema robusto» es aquel que tiene mucho código, otros piensan lo contrario: cuanto más pequeño mejor. Otros creen que por que utilizan la última versión de la plataforma tecnológica, ya es el mejor, sin siquiera haber «digerido» la versión anterior.

    Existen «estilos» de cómo iniciar una trabajo de construcción de arquitectura de software. Hay quienes inician el proceso de construcción modelando la base de datos (que para mí es un horror). Otros inician revisando los documentos, formatos, etc. de la organización, y a partir de ello empiezan a diseñar el sistema. Otros inician entrevistando a los usuarios. Inclusive, y lo más triste, otros inician la construcción diseñando el sistema literalmente tal como el cliente lo dice.

    En realidad, todos aquellos «arquitectos de software» hacen los trabajos de arquitectura de software como ellos mismos creen que es.

    Para construir una arquitectura de software, hay que ser primero arquitecto. Así como para tener una visión, hay que ser visionario.

    Y lo que te falta en tu lista, es algo que tú (claro está, no eres arquitecto, por que no tienes la visión) no tienes de arquitecto: ES TENER LA IDEA DE UNA ARQUITECTURA DE SOFTWARE.

    Cuando tengas la idea de qué es una arquitectura de software, podrás considerarte arquitecto de software. Y cuando te consideres arquitecto de software, recién ahí podrás recopilar las funciones de un arquitecto de software.

    Y para concluir, así como te suele causar risa cuando te preguntan sobre las funciones de un arquitecto de software; así pues, me causas risa cuando crees saberlo.

  10. Considero que no existe la necesidad de ponernos tan agresivos por las simples diferencias de conceptos, en un tema, que para mi, es muy interesante, y a la vez muy nuevo para todos.
    Mi humilde opinion afirma que el listado de responsabilidades esta bien. Agregando sencillamente que el arquitecto es el visionario que ademas de dar soluciones mas rapidas y elegantes que un desarrollador, es capaz de identificar los picos de botella de los codigos, aplicaciones, o pilas de aplicaciones sin la necesidad en muchos casos de haber llegado a ellos. Se destaca tambien el arquitecto por el gran dominio en una o multiples herramientas, lo cual le permite un bagaje amplio y exquisito a la hora de dar soluciones. RESALTO A DEMAS LA ELEGANCIA TECNICA Y LA CLARIDAD CON LA QUE EL ARQUITECTO TRANSFIERE SUS CONOCIMIENTOS.

  11. Creo que están añadiendo algunas responsabilidades que no son competencias del arquitecto, como: Metodología de Proyecto, Procesos de Desarrollo y Selección de Infraestructura: Sistemas Operativos, hardware, redes, sistemas de recuperación.
    Primero la gestión de proyectos es responsabilidad del jefe de proyecto así como la elección y el control de la metodología de desarrollo.
    Con respecto a la infraestructura creo que eso es responsabilidad de las áreas de Administración de sistemas (SO), Redes. Y con respecto al hardware nada que ver con un arquitecto.

  12. Yo no voy a comentar mucho al respecto, menos en un sitio de ecépticos. ¿Cómo van a decir que no es necesario un arquitecto o que «todos somos arquitectos»? ¿Creen que tener «algo» de arquitecto ya es suficiente? Dios, hay que estar bien «fumado» para decir tales atrocidades… Suerte en esa filosofía.

  13. Pienso que un Arquitecto de software, es una persona que conoce de Desarrollo de Sistemas y desea ser el intermediador entre lo Conceptual y el desarrollo, algo asi como el interprete que aclarará la figura. PERO POR DIOS SIGUE SIENDO UN TRISTE INFORMATICO.

  14. Pues que quereis que os diga a mi me ofrecen ser arquitecto y no se de donde leen en mi curriculum que yopuedo llegar a serlo, ni siquiera se las funciones que debo acometer, pero si de mi curriculum ven que yo puedo hacer eso es que ser arquitecto no es dificil y ojo que no desmerezco a los arquitectos, pero para mi no es un termino que exista desde hace años es un termino nuevo para algo que ya haciamos todos en conjunto con el equipo o que hacia el jefe de proyecto cuando abordas un nuevo proyecto, pero lo que si tengo que decir es que esto se esta desmadrando, ahora ya no vale con saber java sino que tienes que conocer un «puto» framework para pasar una entrevista, vamos a ver seamos serios java seguira siendo java me a igual manejar una clase que un conjunto de clases tu quieres utilizar un framework perfecto que me va a costar 2 dias dominarlo? estamos pasando de ser programadores (cualquier lenguaje me da igual el que me pidan que lo aprendo) a ser codificadores en «el lenguaje que sea sin ir mas alla». Nada mas que decir

  15. Hice un trabajo en un banco y me enviaron al arquitecto de sw, para hacer su trabajo de contraparte tecnica. Despues de una larga explicación su VALIOSO APORTE FUE todo es con WEB SERVICES. lo peor del caso es que la herramienta por su naturaleza no requeria usar una arquitectura basada en servicios.

    Pero algo es cierto gana muy bien

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *