(Re)Definiendo Arquitectura de Software

 En  Quién necesita un arquitecto? Martin Fowler aborda el problema del sobreuso de la palabra arquitecto
 
Habrá realmente un sobreuso? Será que no nos ponemos de acuerdo con la definición? En el año 2002 tuve que encarar una búsqueda de arquitecto JEE (en aquel entonces se llamaba J2EE). Para ello armé un exámen multiple choice que ponía a prueba los conocimientos de los aspirantes, en tecnologías como JSP, EJB, RMI, etc. Uno de los aspirantes que falló al responder las preguntas se acercó a discutirme el enfoque que le dí al cuestionario:
-Un arquitecto no es alguien que domina a la perfección las API’s de J2EE: un arquitecto es alguien capaz de decidir acertadamente qué conviene en cada caso, si Windows DNA con COM+, si Linux con J2EE, si interfacear con una aplicación legacy en un mainframe, etc
 
Sabía que su definición de arquitecto no era descabellada, que él se había presentado a la búsqueda en tanto entendía esa acepción de la palabra arquitecto. No obstante yo tenía muy claro que en ese contexto, esa clase de arquitecto no me servía: se trataba de un proyecto J2EE en un banco español con importante presencia en América Latina y si había algo que ya estaba decidido era que la plataforma de desarrollo era J2EE. Definitivamente, lo que buscábamos era el mejor arquitecto de desarrollo que tuviese un profundo conocimiento de esta plataforma ya que iba a tener que tomar decisiones para evolucionar la aplicación en base a la maduración del estándar J2EE. De nada me servía que un día se levante y dijera ahora vamos a Delphi ya que la inversión fuerte se estaba haciendo en servidores de aplicación J2EE
 
Aquí se me puede detener para señalarme que lo que entonces yo precisaba era un desarrollador con profundísimos conocimientos de J2EE. Sin embargo eso sólo no me bastaba: de hecho el test se complementaba con preguntas sobre patrones de diseño y preguntas de arquitectura en general. Preguntas, en definitiva, que alguien que se sepa de memoria el estándar J2EE no necesariamente respondería acertadamente. Ese tipo de preguntas, en cambio, sí las podría responder tranquilamente un arquitecto .NET
 
Efectivamente el aviso publicado decía Arquitecto J2EE con lo que yo daba por zanjado el malentendido. Pero entonces, qué nombre lleva ese otro tipo de arquitecto, aquel que es capaz de decidir entre diversas tecnologías y plataformas? Qué otros tipos de arquitecto existen?
 
Me gusta especialmente un viejo artículo de Michael Platt (cómo pasa el tiempo: Julio de 2002!) en el que aborda los diversos tipos de arquitectura de software considerando distintas perspectivas
  • La perspectiva de más alto nivel es la de la Arquitectura de Negocio, que trata de entender a la organización en base a sus procesos de negocio, sus objetivos empresariales, las principales áreas de la organización y las relaciones entre todas estas partes. Esta arquitectura es claramente no técnica en términos de software, y es la que entienden desde el CEO hasta los analistas de negocio
  • Un nivel más abajo tenemos la Arquitectura de Aplicaciones, la cual mapea esos procesos de negocio de la perspectiva anterior en procesos de automatización o simplemente aplicaciones. Aquí no vamos a tener un arquitecto de aplicación para toda la perspectiva sino que más probablemente cada aplicación tenga su arquitecto. Claramente el CIO o alguien que él designe elegirá la plataforma para los procesos claves (en el caso de que no la elija él si es probable que se reserve la última decisión), y dentro de esa plataforma elegida seguramente hará falta conseguir un arquitecto con fuerte skill. Las decisiones y definiciones que se hacen en este nivel, si bien van a estar influenciadas por aspectos de negocio, van a estar basadas en aspectos técnicos, entendibles eminentemente en un conjunto que incluye al CIO en la cúspide y a los desarrolladores en la base
  • El artículo de Platt describe también dos perspectivas más, la de Información y la Tecnológica, de las cuales no vamos a ahondar aquí. Pero la última define el rol de Arquitecto de Infraestructura, encargado de aspectos no funcionales, transversales, tales como seguridad, comunicaciones, monitoreo y administración operacional

Se puede coincidir o no con la categorización que hace Platt, pero al menos sirve para terminar de entender que claramente en las organizaciones hay dominios de diferente profundidad tecnológica y de negocio. Dentro de cada dominio, siempre surgirá un rol capaz de realizar una interpretación holística del mismo. Este curioso personaje terminará ostentando el nombre de arquitecto 

Me despido hasta la próxima. Que empiece la discusión

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

3 respuestas a (Re)Definiendo Arquitectura de Software

  1. Juan Pablo dijo:

    Me parece que el nombre “Arquitecto” para un cargo en el área de TI es tan ambiguo como el de "gerente" en las áreas comerciales.En ambos casos uno no sabe con quien está tratando, si tiene poder de tomar decisiones, si es realmente el líder de un equipo, etc.Por eso prefiero llamar a mi “arquitecto” cómo líder técnico porque creo que refleja mas fielmente lo que él hace.

  2. Hans dijo:

    Desde hace un tiempo, he estado revisando lo que la propia industria del Software nos indica para llegar a una definición cercana de lo que significa el rol: ¿Será lo mismo un arquitecto para Microsoft que para Sun Microsystems, Bea o IBM?, ¿cuales debieran ser las condiciones comunes –si es que las hay- de cada uno de ellos? ¿Hacia que perfil de arquitectos apunta la industria?. Creo que un indicador para analizar cualitativamente las caracteristicas que debiera tener el rol, lo encontramos en los programas de certificación creados para tal fin. Revisé algunos que encontré en la Web:Sun Microsystems ofrece su programa de Sun Certified Enterprise Architect (http://www.sun.com/training/catalog/courses/CX-310-051.xml). De acuerdo a los objetivos que se plantean en él. Sun hace énfasis en un tipo de arquitecto que es capaz de interpretar una problema y que domina una especificación (J2EE) , patrones de diseño OO y notación UML – herramientas para abordar un caso de negocio con énfasis en que la solución será finalmente implementada en un set de especificaciones del Java Community Process.BEA por otra parte, divide su programa de certificación para arquitectos en dos grupos: Enterprise Architecture y SOA Enterprise Architecture (http://certification.bea.com/certification/arch_certification.jsp) lo cual viene a confundir más el panorama, aunque ambos plantean un foco en común: el conocimiento de la implementación concreta de BEA para la especificación J2EE, esto es finalmente, una plataforma: WebLogic. Revisando si para Microsoft existía algún programa similar, me encontré con el Microsoft Certified Architect http://www.microsoft.com/architecture/default.aspx?pid=share.certification&abver=FEEB2E89-4412-4C58-A7F8-9B2CA0E0BDAC este es un programa que esta por estos días en fase de piloto o marcha blanca y que por lo que se ve en la descripciones incluye una variedad de arquitectos clasificados por dominio: enterprise, infrastructure, solutions, academic y new architects. Al leer las descripciones más en detalle, resalta el hecho que a pesar de que tienen diferencias relativas al dominio de arquitectura propiamente tal, se describe un perfil de arquitecto con algunos soft-skills destacables (liderazgo, comunicación, empatía, etc), más orientado a la solución y no necesariamente dirigido a una única implementación o tecnología (lo cual representa un paso más arriba de las certificaciones MCSE en tecnologías concretas como .NET ).Ciertamente, la experiencia indica que aquella visión holística que nos comentas en tu blog, podría corresponder a cada uno de los perfiles aquí descritos. Concuerdo en que el discernir que tan aplicable sea uno u otro, dependerá del dominio en que se desenvuelva y no por ello serán más (o menos) arquitectos que otros.

  3. Fernando dijo:

    Hola, justamente creo que la palabra arquitecto la empleaste mal, vos necesitabas un desarrollador con basta experiencia, en muchos lugares, muchos arquitectos buscan apoyar sus decisiones en los desarrolladores más experimentados o con mas conocimiento, esto no desmerece la tarea del arquitecto es que siempre trabajan conjuntamente, un arquitecto si vamos al caso tranquilamente podría trabajar sin conocer lo que es una linea de código pero del dicho al hecho, ya saben el final. Otro situacion, que la vivo mas frecuentemente es que el arquitecto fisicamente no existe, sino que la “arquitectura” fue definida por los desarrolladores.

    Saludos

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s