La palabra Crisis, escrita en Chino, comparte un
caracter con la palabra Oportunidad. No es así
por casualidad

 No  es un secreto para nadie que el mundo se encamina a una recesión impulsada, esta vez, no por Brasil o Asia o Rusia sino por la primera economía mundial. Si se frena la locomotora (nos guste o no, es la primera unidad del convoy), los vagones que eran arrastrados inevitablemente van a perder impulso (nuevamente, nos guste o no)

Curiosamente en medio de estas crisis es cuando, usando un poco de inteligencia, podemos ver el lado bueno en los cambios de contexto. Como la fábula del burro que iban a sacrificar y para eso habían hecho un foso, lo habían tirado al fondo y pensaban enterrarlo vivo: el burro logro salir del foso porque en la medida que la tierra que tiraban se iba asentando, hacía pie en ésta

En el artículo que te linkeo acá, Gartner predice que en la medida que el parate económico de la primer superpotencia (la única hoy, bah) el outsourcing (tercerización) de servicios de software va a aumentar en forma considerable. El que la venía mirando con cariño, se va a decidir en la medida en que necesite mantener sus servicios de software (si es posible, incrementarlos para -en la crisis de demanda- mejorar la calidad de su oferta). El que ya estaba tercerizando y conoce las ventajas en lo que a reducción de costos se refiere, probablemente quiera cerrar un cachito más la brecha. Y finalmente, el que hasta ahora no pensaba en tercerizar, si empieza a estar con el agua al cuello quizás al menos comience a explorar esta alternativa (algo es algo)

Gartner predice que India primero y China después van a ser los grandes polos de atracción de tercerizadores. Latinoamérica no sale mencionada, no en el informe de Gartner al que yo no tuve acceso, sino en la nota que lo destaca

De todas maneras, si la montaña no viene a Mahoma, habrá que ir a la mountain no más... A preparar esas brochures en inglés. Primer mundo: allá vamoooooosssssssss!!!!!!!

 Semanas  atrás liberamos la edición 15 del Architecture Journal (on line, revista en papel y reader). El tema de este trimestre es El Rol del Arquitecto, que es algo que siempre da que hablar. Más allá de cualquier tema que podamos cubrir de arquitectura de software (SOA, SaaS, O/R-M, etc) el éxito de un enfoque arquitectónico no lo va a dar por sí solo su diseño sino las habilidades del arquitecto en transmitir una idea en forma convincente, generar adhesión y lograr apoyos (tanto de arriba -léase guita- como de abajo -mano de obra leal que haga lo que los planos decían-)

Al fin y al cabo, como decía el dicho, de carne somos y eso vale tanto para los arquitectos como para los que tienen que lidiar con ellos en el día a día (jefes de proyecto, gerentes de TI, desarrolladores, operadores, DBAs, jefes de seguridad informática, etc)

Por esta razón hemos liberado un nuevo foro de discusión sobre el Rol del Arquitecto. La consigna del mismo no es debatir temas de arquitectura en general (onda "qué me conviene, ADO.NET o NHibernate?") -eso ya tiene su foro- sino lo que vendrían a ser nuestros soft skills como liderazgo, apertura intelectual, capacidad de aprendizaje y evolución, etc

Te recomiendo que afiles tus conocimientos de inglés y te pegues una vuelta. Se han armado unos debates bastante interesantes ("debe un arquitecto programar? cuánto?", "cómo lidiar con el jefe cuando nos fuerza a hacer la arquitectura contemplando cosas que nunca hubieramos elegido?", "por qué no se puede ser arquitecto apenas se sale de la facu?")

Y muchas otras

Oíme, haceme caso. No gastés guita en psicólogo y vení a discutir de estos temas al foro. Como es de esperar, minitas no va a haber pero en eso al menos no estabas mejor en el psicólogo

 
Parálisis de Diseño? Implementación Precoz? Consulte al Dr. Diegumoff

 Recibí  una consulta interesante de Jorge, un lector del blog, docente de la carrera de computación científica en la Universidad de Ciencias Informáticas (Cuba). Preferí -previa autorización de él- llevar el caso en forma abierta, de modo que todos puedan dar su visión al respecto

Estimado Jorge, el caso que se te planteó es de esas típicas discusiones donde todas las partes involucradas parecen tener algo de razón, lo que vuelve muy complicado de determinar quién está en errado y quién no

Es muy probable que si afirmamos que sólo al arquitecto le cabe definir la plataforma de desarrollo, los sistemas operativos sobre los que la solución va a correr, elegir el IDE, etc, estemos equivocados. No obstante, sería falso también decir que al arquitecto no le cabe ningún rol en las decisiones a tomar en esos primeros puntos de la lista

La mano es así: arquitectos los hay con distinto nivel jerárquico, esto basado en su background, antigüedad en la empresa donde trabajan, antigüedad en la industria del software, etc. Asimismo, tenemos arquitectos de soluciones (que son los que vienen de haber programado durante varios largos años) y arquitectos de infraestructura (aquellos a los que les tocó instalar y mantener servidores, redes, puestos clientes y periféricos durante un lapso no menor)

Es muy raro -aunque no imposible- que te topes con alguien que la tenga clara en desarrollo y a la vez la tenga clara en infraestructura. Cuando te digo "tenerla clara en ambas cosas" no me refiero a saber Java y ser capaz de instalar Linux, sino a ser capaz de diseñar soluciones que corran en una plataforma definida por ellos y que la cosa escale así de repente todos los usuarios se decidieron a dar enter al mismo tiempo

Seguramente que lo que dijo el profe pueda parecer exagerado si se lo vamos a asignar, dado un proyecto x de misión crítica, a una sola persona aunque lo probable es que sean definiciones a resolver entre dos o quizás más. Lo que sí me atrevo a asegurar es que varias de estas personas van a ostentar el rol de arquitecto (o arquitecto jefe, que es más bien un arquitecto que no participa en un proyecto dado sino que toma decisiones que afectan a todos los proyectos de la organización). Lo más probable es que estos arquitectos sean, algunos "de soluciones" (desarrollo) y otros "de infraestructura"

Si tengo que contar por mi caso personal (yo soy arquitecto de soluciones), hubo proyectos a los que me sumé y ciertas decisiones ya habían sido tomadas (S.O., Lenguaje de Programación, etc) y otras que aún quedaban "por tomar". Para aquellas que aún estaban pendientes, como te contaba, no es que me tiraban toda la responsabilidad de la decisión a mí solo, sino que yo integraba un comité junto con otras personas

La mayoría de las veces, tal como tú lo sugieres, tuve voz pero no voto. Es decir, podía dar mi opinión pero la decisión quedaba en manos de alguien con "poder de compra", sobre todo en aquellos casos en que la decisión implicase adoptar un producto con un modelo de licenciamiento lucrativo (que haya que pagar para poder usarlo, bah). Debo confesar acá que me frustraba que a veces mi opinión fuese ignorada (me carcomía la duda de para qué me convocaban a esos comités si luego iban a hacer lo que les pareciera. Pero, en fin, volviendo al punto y como cierre, no es que me tocara toda la responsabilidad a mí pero sí al menos una participación en la maduración de las ideas y los rumbos a tomar

Sin duda alguna que, no obstante, el grueso del proyecto lo iba a dedicar a "Estilos y Patrones Arquitectónicos", el último punto que mencionó el profe y con el que sí estuviste de acuerdo

Saludos por la tierra del Ron