El arquitecto de software y hardware ¿Cuál sería el perfil?

Tal vez no debe conocer a super fondo el lenguaje, pero sí debe tener bastantes conocimientos en cuanto a la manera de estructurar aplicaciones, patrones de diseño, los frameworks más populares (y los no tan populares pero que puedan servir a un proyecto), tendencias, etc.

Y cuando digo que debe conocer los frameworks no me refiero a simplemente saber de la existencia de Spring o Hibernate por ejemplo, sino saber qué módulos tiene, qué hace, cómo lo hace, si es recomendable su uso, qué soporte hay tanto en comunidad como a nivel empresarial, hacia dónde va, en qué estado se encuentra actualmente (puede haber un framework muy bueno y estable pero que ya fue abandonado por su autor y por lo tanto no sería recomendable meterlo a proyectos que requieren mantenimiento a largo plazo porque en algún momento va a dejar de funcionar por cambios en JVM y cosas así, o bien se va a estancar todo el proyecto por no poder actualizar dicho framework). Lo mismo aplica para contenedores (que si JBoss, Glassfish, WebLogic, etc), sistemas operativos, versiones de Java, bases de datos, etc; debe saber las ventajas y desventajas de cada uno y saber cuál conviene en cada proyecto.

En mi opinión, también debe poder ayudar a programadores a encontrar problemas en su código, realizar optimizaciones, etc. Y debe ser quien defina los procedimientos para pruebas unitarias, de integración, de regresión, etc; para deployment, para entregas parciales, correcciones, mantenimiento...

Diseñar componentes y capas de una aplicación. (Documento de arquitectura)
Instalación y deployment (despliegue)
Armar ambiente de desarrollo y Línea de producción

En las fábricas de software, la línea de producción que es un entorno de trabajo que permite la integración continúa de código nuevo y cambios la aplicación.

Como manejador de versiones, compilación automática, Herramientas de estilo, Herramientas de revisión de código, Etc.

Y Si soporte a programadores.

Se sigue usando el concepto de fábrica de software? Pensé que ya estaba probado que eso no sirve. Todos los procesos del mundo no van a compensar la falta de talento. Necesitas tener buenos programadores, y si los tienes, no es necesario llevar las cosas como si fuera una línea de producción, porque no lo es.

La falta de talento no pude sustituirse con un proceso. (Aunque eso buscan varias metodologias)
En eso estoy de acuerdo.
Pero otros conceptos no son tan malos ¿No crees?

Los perfiles pueden variar ampliamente. Ejemplos de responsabilidades que pueden incluirse en el perfil de Arquitecto de SW:

- Planeación del portafolio de aplicaciones.
- Establecimiento y revisión de estándares.
- Habilitación del negocio a través de la tecnología.

De acuerdo con el modelo TOGAF. los perfiles pueden enfocarse en:

- Arquitectura de negocio: Motivación, organización, función.
- Arquitectura de sistemas de información: Datos y aplicación.
- Arquitectura tecnológica
- Realización de la arquitectura: Oportunidades, soluciones, planeación de la migración, gobierno
- Principios, visión y requerimientos de arquitectura.

En una organización grande, existen inclusive arquitectos con diferentes especialidades: Enterprise Architect, Solution Architect, Application Architect, Domain Architect. En realidad depende más bien de los requerimientos de tu organización.

Debo confesar que en México, lo que normalmente veo como perfiles de arquitecto, si le pusiera el título de Desarrollador Sr. no podría distinguir entre ambos. Creo además que cualquier Arquitecto fue alguna vez en su vida desarrollador sr.

Saludos

Javier Castañón

¿No sirve? Lo recordaré la próxima vez que me mencionen Pune, por ejemplo, que es una ciudad de la India de 3 millones de habitantes, que da empleo a 70,000 personas en el área de TI, la mayoría de ellas en fábricas de software.

Por cierto, no capto qué tiene que ver la falta de talento con ellas.

Saludos

Javier Castañón

Edit: Perdón, dice "la mayoría" y debe decir "muchas". La mayoría probablemente trabaje en centros de llamadas. Para el que tenga curiosidad, busque en Google los términos "software development offshore nearshore" para darse una idea del "vibrante" (como dicen los analistas) mercado de las fábricas de software.

De acuerdo a su experiencia específicamente un "arquitecto java" o al menos lo que una certificación "java arquitect" que debería saber o poder hacer
¿Esta apegado a lo que la industria del software necesita?

Por ejemplo la certificación de java de SUN me parece que es "programmer" parece que está enfocada a desarrollar la JVM no necesariamente a saber programar en java de acuerdo a lo que lo la industria del software necesita.

Por ejemplo se ven cosas como frameworks, sistemas de alta disponibilidad, escalables,
Como optimizar sistemas de mensajería JMS, Web Services

A veces las certificaciones no son lo que esperamos. Y luego uno se pregunta si vale la pena o no dicha certificación.

Saludos

Estoy de acuerdo contigo Javier, me parece que una fábrica es una forma más natural de hacer nuevo software y darle mantenimiento.
Los sistemas siempre están cambiando y así debe ser.
Es más flexible administrar muchas órdenes de trabajo de fábrica, que un ciclo completo.
Por otro lado en el cliente mantener una plantilla de desarrolladores y especialistas grande es más costoso y pesado que tener una parte interna de esa plantilla y un equipo en fábrica.
Se puede aprovechar más el tiempo y por lo tanto el costo.
Y la gente también se puede enfocar más ya sea en el negocio o en la tecnología.

Me encantaría que el gobierno y los corporativos en México se dieran cuenta de que trabajar offshore y nearshore es una llave para desarrollar el país, ya que le dan oportunidad a otras regiones de desarrollarse sin tener que centralizarlo todo.
Por desgracia solo algunos se han atrevido a probar esos esquemas y a tener esas ventajas.
Quedo muy claro cuando vino la contingencia de la influenza H1N1 que el trabajo remoto es factible y es una gran ventaja.

- Planeación del portafolio de aplicaciones.

Como dirían los españoles, matizo tu comentario.

En algún lugar encontré que la cartera de proyectos y aplicaciones es responsabilidad de la dirección o la gerencia.
(Esto puede variar de empresa en empresa)
Pero la implementación de tecnología en esa cartera es responsabilidad del arquitecto, y aquí es donde salen funcionalidades o aspectos comunes a todos los proyectos.

En algún lugar encontré que la cartera de proyectos y aplicaciones es responsabilidad de la dirección o la gerencia.
(Esto puede variar de empresa en empresa)
Pero la implementación de tecnología en esa cartera es responsabilidad del arquitecto, y aquí es donde salen funcionalidades o aspectos comunes a todos los proyectos.

:-)

El portafolio de *aplicaciones* no necesariamente es lo mismo que el portafolio de *proyectos*. En las empresas donde existe una función de Gobierno de Arquitectura, el portafolio de *aplicaciones* es dirigido o planificado a través de un "roadmap", el cual es desarrollado para conectar dos temas principales: el estado actual de la arquitectura y el estado futuro de la misma. El desarrollo de dicho "roadmap" o plan de aplicaciones es responsablidad de un tipo de arquitecto conocido como "Enterprise Architect".

El portafolio de proyectos por supuesto es responsabilidad de una Oficina de Proyectos, y una aplicación puede requerir varios proyectos para su construcción y mantenimiento.

Saludos

Javier Castañón

En abstracto, creo que en tanto te haga estudiar y aprender, cualquier certificación vale la pena. Tras echarle un vistazo al contenido del Sun Certified Enterprise Architect, lo veo muy apegado a lo que se usa en la industria.

La certificación valdrá la pena dependiendo más bien lo que esperes obtener de ella.

Saludos

Javier Castañón

Digamos que el arquitecto debe decidir los grandes temas de tecnología y entrar e detalle de implementación. Que tecnología se justifica, cuando meter un BUS por ejemplo y cual escoger.