La semana anterior conversaba acerca del tema a través de twitter  con un amigo agilista de Ecuador. Cuando él propuso esto, lo debatí fuertemente; ya que para este momento no concebía que un arquitecto de software pueda llevar la gran responsabilidad del PO. Mi temor estaba orientado a que podría dársele más énfasis a aspectos técnicos y tecnológicos que a satisfacer las necesidades funcionales y expectativas de negocio de nuestro cliente. Al final del día, no importa mucho si lo haces con .NET o Java, 3 capas o cliente-servidor, si el producto no es de calidad (según mi visión de calidad basado en el modelo Kano), sino representa utilidad para el negocio y las funciones diarias del cliente; sino deleita.

Durante esta semana (y mientras escribo este post) tuve la oportunidad de participar en un curso de arquitectura basado en la visión del IASA. He descubierto que estaba muy sesgado acerca del rol de un buen arquitecto de TI y un buen arquitecto de software, comprendiendo que un buen arquitecto buscar solucionar problemas de negocio apalancado en tecnología, algo fácil de decir pero muy complicado