lunes, septiembre 08, 2008

El Arquitecto de Software en versión española.

lunes, septiembre 08, 2008 por Martín

En muchos países europeos, US, Japón y otros, la figura de Arquitecto de Software está realmente valorada. Ser arquitecto de software es el paso natural para muchos desarrolladores senior, y requiere sobre todo experiencia y buenas capacidades de análisis, raciocionio y abstracción. Coding de Architecture es uno de los mejores blogs existentes sobre el trabajo de Arquitecto de Software y tiene varias entradas donde se define el scope de un arquitecto o el perfil que debería tener un arquitecto.

Entre las tareas de un Arquitecto de Software destacarían:

  • Definición de la arquitectura.

  • Selección del software.

  • Selección de la infraestructura.

  • Requisitos no funcionales.

  • Liderazgo.

  • Mentoring.

  • Metodología de los proyectos.

  • Proceso de desarrollo.

  • Prácticas y estándares.

  • Análisis de las tendencias en desarrollo de software.

  • Aporte de experiencia.

  • Participar en el desarrollo.



Esta lista está recogida en este fichero PDF y es probablemente el último de los puntos que he puesto el que causa más polémica, aunque bueno más o menos está aceptado que es un bueno que un arquitecto participe de alguna forma en el desarrollo, aunque el dedicar más del 30% de su tiempo a dichas tareas indicaría que hay algo que está iendo mal.

Viendo como trabajan las empresas en el extranjero y sobre todo el reconocimiento que se le tiene a arquitectos y desarrolladores senior, a uno no le deja de sorprender el encontrarse ofertas en España buscando Arquitectos de Software con experiencia de al menos un año programando en J2EE. O mismamente la siguiente lista de requisitos para un Arquitecto J2EE en Valencia:

Descripción de la oferta
Buscamos un arquitecto en las tecnologías Java/J2EE, para proyectos de primer orden y pioneros en el ámbito de desarrollo de software. El candidato seleccionado se responsabilizará de:
-Captura y análisis de requisitos técnicos y de negocio
- Análisis y diseño funcional y técnico de proyectos de desarrollo de software
- Definición y ejecución de planes de pruebas
- Desarrollo Java/J2EE
- Realización de la documentación técnica asociada al proyecto
- Impartición de formación a usuarios y técnicos implicados en el ámbito del proyecto


Es decir en este caso Arquitecto = consultor, business analyst, tester, programador, documentador y formador. En fin, que cualquier parecido con la realidad del mundo exterior a nuestro peculiar país es mera coincidencia. Aunque está claro que en muchas empresas sí se reconocen los puestos de desarrollador senior y arquitectos, lo cierto es que todavía son la mayoría las que desconocen completamente lo que es el mundo del desarrollo de software, sus perfiles, el trabajo que se debe realizar, los roles y responsabilidades, etc. El arquitecto de software no deja ser "el que controla" o "el que nos saca las castañas del fuego".

Así nos va.

comments

4 Respuestas a "El Arquitecto de Software en versión española."
Francisco Mesa dijo...
14:46

Llevo unos meses preguntándome si no es por falta de capitalización de los proyectos, lo que obliga a equipos pequeños (de 1 a más personas) en el desarrollo de aplicativos o la configuración del ecosistema de software.


Martín dijo...
22:46

La verdad es que no sé Paco. Pero yo esto ya lo he vivido cuando había más capitalización :) Pero bueno, tampoco es que haya visto mucho de ese dinero caer en los proyectos de software, con el software pasa algo especial, parece que el dinero siempre vierte para otros lados...


Francisco Mesa dijo...
23:12

Y no será que el software no se puede tocar, fácilmente "piratear", y que depende del esfuerzo de los que trabajamos detrás de él. ¿No será que nos valoramos poco o que aún no saben valorar la diferencia entre un Jaguar y un "pandereta"? Seguro que entendiste la diferencia.


Unknown dijo...
23:47

Buff! Lo de las ofertas de trabajo es un tema de otro mundo cuando estas en España.
Estoy de acuerdo en que un arquitecto deba picar código, pero no para implementar funcionalidades, sino para dictar las directrices que se deben seguir por los demás programadores con el fin de mejorar el mantenimiento, la lectura y las búsquedas dentro del código.