Critico y Consultor - Rasgos y Características del Arquitecto de Software - Parte 4

Crítico y Consultor
Es muy importante como crítico la habilidad para tener una mirada fresca e imparcial acerca de su propio trabajo, separando las personas del problema, aceptando críticas y buscando feedback constante que puede venir de cualquier rol. Es más que importante tener la voluntad para reconsiderar y volver atrás si es necesario las decisiones tomadas. Con respecto al rasgo de consultor, es muy importante a la hora de la construcción es muy importante al soporte y la educación sobre la arquitectura, las revisiones y el feedback para un posible cambio. Agunas de las características que salen, podrían ser las siguientes:
- Busqueda constante de feedback
- Tener la capacidad de reconsiderar decisiones previamente tomadas en base a una crítica
- Educador de la arquitectura
- Revisor de la implementación, que cumpla con lo que la arquitectura define

Con esto termino esta serie de posts sobre los rasgos del Arquitecto de Software. Cualquier opinión y sugerencia va a ser bienvenida.

Diseñador - Rasgos y Características del Arquitecto de Software - Parte 3

Diseñador
Este es uno de los rasgos diferenciadores, debido a que es sumamente necesario aunque no es suficiente. La creación o el diseño de la arquitectura es uno de las principales tareas del arquitecto a lo largo del proyecto por lo tanto es muy importante tener un criterio de diseño y evaluación de alternativas muy aceitado para poder articular dichas decisiones, utilización de principios y patrones, descomposición de módulos, alocaciones y sobre todos los trade offs necesarios para la construcción de la arquitectura. Quiero dejar claro que diseñar no es "documentar" en modelos, todo lo contrario, diseñar es la actividad de entender el problema y buscar a traves de las tácticas disponibles la mejor solución basadas, generalmente, en abtraciones, creatividad y reuso de soluciones anteriores (patrones). Las características asociadas al diseño las podemos catalogar de la siguiente manera:
- Creatividad, a la hora de buscar alternativas para solución de problemas y decisiones necesarias.
- Conceptualizador, esto está muy relacionado con los modelos mentales y la visión del arquitecto, pero básicamente es necesario entender el problema antes de tomar decisiones, y que la conceptualización esté lo mejor posible (que terreno pantanoso me he metido)
- Modelador, en esta característica está en juego la conceptualización (punto anterior) donde modelamos para representar la realidad (negocio, recursos, etc) y por otro lado la comunicación de lo decidido, aca se mezcla con lo que hablamos en el rasgo de traductor.
- Colaborador y Moderador, colaborar a la hora de resolver problemas y moderador para generar consenso en una reunión y búsqueda de compromiso, ya que es muy común tener reuniones con diferentes tipos de stakeholders y generalmente las decisiones son tomadas en un contexto donde la arquitectura es el centro o guía dicha decisión.
- Comunicador de conceptos y modelos.
- Perspectivas, es la habilidad para ver un problema y plantear diferentes soluciones y en cada una de ellas poder ver que impactos va a tener en el corto, mediano y largo plazo. Para este punto en particular recomiendo mirar la siguiente página de un método llamado, "análisis basado en perspectiva"

Traductor - Rasgos y Características del Arquitecto de Software - Parte 2

Traductor
Este es uno de los rasgos que más pongo énfasis durante la cursada de la materia, a la hora de comunicar el conjunto de decisiones que van materializando la arquitectura necesitan ser comunicadas y consensuadas con todos los stakeholders, no pueden ser presentadas de la misma manera, ni con el mismo lenguaje, ni con los mismos modelos a todos, el arquitecto debe asegurarse que cada tipo de stakeholder entienda la vista de arquitectura que tiene que entender con el lenguaje correcto, por lo tanto el arquitecto debe tener las siguientes características asociadas:
- Poliglota / Multi-lingual, para poder comunicar la misma arquitectura a diferentes stakeholders que poseen diferentes lenguajes.
- Analista, es importante estár al tanto del contexto que cada stakeholder se encuentra, que preocupaciones (concerns) posee.
- Capacidad de síntesis, esta característica puede ahorrar mucho tiempo en las reuniones del arquitecto, pudiendo guardar tiempo para otro tipo de actividades, esto no quiere decir ocultar nada sino comunicar lo justo y necesario.
- Generalista, el arquitecto debe ver siempre la "Big Picture", debe concertarse en las decisiones que guían la construcción de la aplicación trabajando y comunicando abstracciones, los detalles hay que dejarlos para los analistas del negocio y diseñadores/programadores.
- Identificar qué es lo relevante, qué tiene impacto que no, clasificar y priorizar
- Alta tolerancia a la ambigüedad, esto puede ayudar mucho a acortar el tiempo en las reuiones, las abigüedades son sanas, siempre y cuando no haya buena fe en el entorno de los stakeholders, pero mi recomendación es no invertir tiempo en discusiones que no aportan al proyecto, si un administrador de SCM le dice robustez a la latencia (response tiem), todo bien, no hay que enseñarle en medio de una reunión que lo que dice está mal, lo importante es poder manejar esa ambigüedad tener bien claro de que se está hablando, no discutamos temas de nomenclatura, lo que importa es el significado (Como dice Nico Passerini).
- Mentalidad abierta, esto no es exclusivo del arquitecto de software, aunque lamentablemente muchos cerecen de esta característica :(

Visionario - Rasgos y Características del Arquitecto de Software - Parte 1

Visionario
Ser Visionario para un arquitecto es poder definir esa idea de arquitectura, comunicarla y generar el compromiso para cumplirla. Para poder tener siempre esa visión y alinear al resto de los stakeholders es importante cumplir con las siguientes características:
- Escucha Activa, para el correcto entendimiento del negocio y las posibles críticas a las decisiones del arquitecto.
- Comunicación verbal, no verbal, oratoria y capacidad para modelar.
- Sagacidad Política, tengo que preguntarle a Gastón bien por que es esto, suena lindo.
- Liderazgo para la creación del team de desarrollo, movilización y motivación del mismo alineándolo detrás de la visión.
- Carisma para poder alinear al team detras de la visión (de la arquitectura a construir). Y es por eso que el carisma es tan importante en un Arquitecto, es ese grado de atracción y desenvolvimiento personal que permite agrupar y convencer personas para lograr algo, en este caso, para sumarse a la abstracción que el arquitecto propone construir.

Rasgos y Características del Arquitecto de Software

Hace un par de años, cuando arrancó la materia con Gastón Escobar definimos una serie de rasgos o características que debía tener el arquitecto de software, obviamente excluimos los temas técnicos y más que nada apuntamos a los skilles interpersonales y de liderazgo que todo arquitecto de software debería tener o intentar desarrollar, aquí los explico más detalladamente, separando en 4 posts:

• Parte 1 - Visionario
• Parte 2 - Traductor
• Parte 3 - Diseñador
• Parte 4 - Crítico y Consultor

Tagged

Leyendo el Blog de uno de mis mejores alumnos de APIT, Adrian Alonso (de quien espero que actualice su blog más seguido), me dí cuenta que me taggeo para que cuenta cinco cosas de mi que pocos conoce, por lo tanto aquí van:

• Muchos saben que me recibí en la UTN de Ing. en Sistemas, lo que nadie sabe es como llegué ahi. Como varios adolecentes, en la secundaria, estudian solo para zafar y pasar un buen momento, pero no era el caso de Ezequiel Issa, digamos, el Nerd de la clase al cual todos acudiamos a la hora de copiar la tarea que no habiamos hecho el día anterior, una muy buena persona que vivia para el colegio. El tema fue así, un Jueves de Agosto (1998), sentado al lado de el, obviamente, tratando de careatear la copiada de tarea y haciendome el amigo, le pregunte, "Che Hugo (por que le deciamos así), que vas a estudiar el año que viene, estamos en quinto año??" Y me dijo muy seguro, "Y mirá, a mi me gusta la computación, así que voy a estudiar en la mejor facultad de computación de la argentina, la UTN"?, "UT que????", le pegunté, y bueno, despues de contarme un poco sobre la facultad me convenció, no teniamos mucha idea de que era Sistemas, pero si que tenia que ver con la computadora, al otro día fui a anotarme, por que estaban llamando por apellido en esa fecha y desde 1999 al 2004, estuve estudiando en mi amada universidad, obviamente que al tiempo me dí cuenta que Sistemas no es Computación, por suerte, por que al ir entendiendo los Sistemas de Información me fui apasionando cada vez más, si hubiese sido una carrera de Computación, estoy seguro que no la hubiese terminado... ahora bien, que pasó con Ezequiel Issa?, al tiempo me lo encontré en el Laboratorio de Sistemas, creo que todavía sigue estudiando, creo que está por cuarto año..... Gracias Hugo!!!
• Tengo 3 hermanos, Gastón y María Victoria mayores (del matrimonio anterior de mi viejo) y una hermana llamada Barbara un año más chica que yo. Con Barby hablo todos los días y con los más grande, de vez en cuando, aunque me gustaría estar más en contacto.
• Hace unos meses que empecé a jugar al tenis, todavía no con profe, y el otro día, jugando al tenis con mi mujer en MDQ, sacando para el Set, maté un pajarito, si aunque no lo crean, una en un millon, vi cuando la pelota despedida de mi raqueta impactó en la cara el pajarito, y este cayó haciendo circulos en el aire, de no creer, todos los jugadores de otras canchas vinieron a ver la escena del crimen :)
• Desde que nací vivo en Buenos Aires, Villa del Parque principalmente y actualmente en Palermo, pero me encantaría poder vivir en una ciudad mucho más tranquila, como Mar del Plata (aka MDQ), creo que no es el momento, pero si lo tengo muy en mente principalmente pensando en la calidad de vida de mi(s) hijo(s), por ahora tengo uno pero me gustaría tener una más, a quien vamos a llamar Luz Brey, en caso de que salga nene y económicamente/sentimentalmente estemos preparados buscaremos otra vez :), no más de tres.
• Suelo ser muy tolerante con las personas y confio en la gente, pero lo que no puedo soportar, tanto en ambiente laboral como en lo personal, es la soberbia y la mentira, me general mucha bronca la gente que posee alguna de esas dos características y puedo ser muy duro (a veces desconozco mis actitudes con ese tipo de gente), debe ser por que siempre intento ser lo más transparente, sincero y humilde posible....
  

Ahora es mi turno de "taggear", y lo voy a hacer a: Gastón Escobar, Marisa Espinosa, Luciano Bello, Mercedes Caracotche, Gonzalo De Pedro (Gona) y Nicolas Passerini, espero que estos últimos dos publiquen su blog pronto...

Design & Programming Trends

Debido que en las próximas dos semanas recibimos visitas a IBM Argentina de India (1) y USA (3) para llevar a cabo unas sesiones de diseño y arquitectura para la nueva release del proyecto, me tomé el tiempo de poner a todo el team "on top" de las últimas tendencias (patterns, principios, tecnologías, etc) en lo que refiere a diseño y programación. Básicamente son las cosas que se vienen utilizando y desarrollando en la industria y tiene mucho sentido tenerlas en cuenta.
El mail lo mandé en ingles, pero bueh, cuando tenga un rato lo traduzco :) (mil disculpas para quienes no entiendan el idioma o mi ingles ladri)

• Test Driven Development has become as one of the best design technique and was the most acceptable XP practice. (plus Refactoring). UI Arg team had great result using it during R2. I have also gave a 2 hours course about it here. Finally I have also hear about Behavior Driven Development, it is a step beyond TDD.
• Inversion of Control Design Principle and Dependency Injection Pattern had become de facto technique to deal with dependencies and object life cycle. Spring Framework is example of how important is this technique. During R2 We were implementing IoC in some part of the UIFramework.
• Ruby On Rails web framework has impulsed a revolution against Big-Complex-HardToUse-HyperXMLConfigurable Java Web frameworks, Ruby On Rails gives different approach for Web Development, using principles like "Convention Over Configuration", "AJAX is part of the framework", "Flash Memory Context" and "Easy and Rapid web development"... those are important concepts, many Java Frameworks have been introducing something similar to RoR, i.e. Rife, Grails, AppFuse, Trails, xFramework, etc.
  
• Domain Driven Design (DDD) is a technique that reinforces the use of Object Oriented Design to solve domain problems and complexity.
• Web Flows this kind of frameworks allows to implement continuation concepts that gives the ability to keep track on double submitions and back buttons.
• RIA - Rich Internet Applications (AJAX).
• Defensive Code / Design By Contract. I think that we have to insist on this principle, mainly with Dependencies, there are interesting ways to solve this with Aspect Oriented Programing or using annotations (with Java 1.5)

Tengan en cuenta que es un Team de UI, por lo tanto está un poco acotado.

Se les ocurre algo más?

Es la Robustez un Atributo de Calidad?

Hace unas semanas, Juan Pablo Picasso (Socio de Andina Software y Profesor de TADP) envió un mail a una lista iniciando una discusión sobre que realmente es la Robustez. En este post explico lo que para mí es la robustez y por que.

Me inclinaría por una definición como la siguiente para la robustez:

"Es el grado de percepción/sensación que da una aplicación para responder a eventos no contemplados o que exceden los requerimientos no funcionales y que su respuesta permita medirse en parametros calculables, o sea, no ocurra un desastre"

No estoy seguro si se entendió, pero me gustaría dar algunos ejemplos. Si tenemos un NFR de Performance como el siguiente

"El sistema debe poder responder a 1000tx por Hora con un tiempo de respuesta menor a 5 segundos para las transacciones Tx1 y Tx2",

Podríamos pensar en que la robustez entraría en juego en casos en los cuales si hay 1001tx por hora el sistema responda de manera aceptable y que no se caiga Obviamente podriamos pensar que no se va a cumplir con los 5 segundos, pero tampoco que no se cumpla por mucho, o sea, que responda en 6 o un poco más... se entiende el ejemplo?
Lo mismo pasa con la robustez para los Atributos de Calidad No runtime, en donde vos tenes algun NFR de modificabilidad definido, por ejemplo:

"El sistema debe permitir la modificación de parámetros la interfaces X e Y a pedido del usuario y debe ponerse en producción en un tiempo de 40 días, incluyendo el analisis, diseño, desarrollo, testing y deploy",

Y si te llega algún Change Request, que pide dentro de la modificación de parámetros de las interfaces X e Y, y aparte agregar una exception, como notaran, la exception no está contemplada, en este caso la robustez entra en juego por el lado de esa misma sensación de que si no la habias contemplado el cambio se puede realizar bajo parametros decentes.

Por la tanto ya sea para Atributos de Calidad Runtime y No Runtime la robustez se podria pensar como ese grado de sensación ortogonal a cualquier tipo de Atributo de Calidad que mide el grade poder responder con parámetros decentes.

Esta es una conclusión personal después de haber discutido con varios profesionales sobre este tema. Principalmente con Gonzalo De Pedro y Nicolas Passerini.

Opiniones?