domingo, 19 de enero de 2014

Mal entendiendo el manifiesto agil

Hace ya muchos años, en febrero de 2001, 17 referentes de lo que en ese momento se llamaban las metodologías "lightweight" (livianas) se reunieron en un resort (lugar extraño, pero no voy a meterme en ese tema) para acordar los lineamientos de la nueva rama metodológica de IT.

Una de las cosas que hicieron, fue sacar la mote de livianas a la metodología, y llamarlas ágiles. Para mi, ese fue un primer paso para eliminar uno de los primeros malentendidos de dichas metodologías. Llamarlas livianas hacen pensar que son mas fáciles de implementar, o que sirven para proyectos de juguete y no en serio, como las metodologías tradicionales. Por otro lado, llamarlas ágiles demuestra el principal objetivo de esta forma de trabajar: enfocarse en el aprendizaje y adaptación continua, de manera colaborativa con el ambiente.

Luego de horas de charla (y me imagino que también comida y alguna que otra cerveza) definieron 4 guías generales, acompañados de 12 principios, que formaron las bases del crecimiento futuro de las metodologías.

Actualmente, muchos años después, las grandes compañías se atreven a pensar en sumar estas metodologías "novedosas" a sus proyectos. Esto es una buena noticia, pero muchas veces se malentienden los lineamientos o los principios ágiles, lo que lleva al fracaso al corto plazo (en el mejor de los casos), o al largo plazo (lo que se relaciona con mucho tiempo y dinero perdido).

En mi opinión, parte de esos malentendidos se da por la naturaleza humana de buscar siempre el camino mas simple, y no adentrarse demasiado en lo que produce ese camino o en entender completamente lo que se hace. Como dice Douglas McGregor, en su teoría X, el ser humano es vago por naturaleza. No estoy completamente de acuerdo con esto, pero creo que muchas personas (en la lectura del manifiesto ágil se da claramente), paran de investigar o ahondar mas un tema cuando descubren alguna teoría que sirve para fundamentar su pensamiento.

Para explicar mi opinión, primero transcribiré los lineamientos del manifiesto ágil:

  1. Individuos e interacciones sobre procesos y herramientas
  2. Software funcionando sobre documentación extensiva
  3. Colaboración con el cliente sobre negociación contractual
  4. Respuesta ante el cambio sobre seguir un plan 
Luego de los cuales se encuentra la siguiente frase: "Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.". En ningún lado dice que debemos desechar los elementos de la derecha, y solo aplicar los de la izquierda. Pero muchos lo entienden de esa manera, solo porque la parte izquierda puede verse, desde el punto de vista de muchos, como lo único que debe hacerse en un proyecto IT. Y eso no es ágil. Eso es un fracaso.
¿Porque se da esto? Porque los que afirman que son agilistas ya que no documentan, no siguen procesos y no tienen un plan, no siguieron leyendo mas profundamente sobre el manifiesto ágil. 
Debajo de los párrafos anteriormente transcritos, se encuentra un link hacia la explicación de la historia del manifiesto (about the manifest). Seguramente esta página tiene muchas menos lecturas que la principal (tal vez sea un problema para muchos que dichos párrafos sean escritos solo en ingles), y eso explica el fracaso de muchos proyectos mal llamados ágiles. 
Voy a transcribir un párrafo de dicho texto:
"The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.". Y lo voy a traducir por si ese es el problema:
"El movimiento ágil no es anti-metodología. De hecho, muchos de nosotros quieren devolverle credibilidad a la palabra metodología. Queremos volver a tener un equilibrio. Nosotros adherimos al modelado, pero no al hecho de almacenar algún diagrama en un repositorio corporativo. Adherimos a la documentación, pero no a cientos de páginas nunca mantenidas y raramente utilizadas. Planificamos, pero reconocemos los límites de planificar en ambientes cambiantes.".

Creo que si este párrafo estuviera junto a los lineamientos base, los rechazos a las metodologías ágiles serían mucho menores.
Las metodologías ágiles no se tratan de no tener procesos ni herramientas, sino de tener los que ayuden a los individuos y sus interacciones a ser mas fluidas, eficientes y eficaces. O sea, que ayuden a hacer lo correcto en el menor tiempo posible.
Las metodologías ágiles no se tratan de no tener documentación, sino de documentar lo relevante para comprender el código, que el mismo sea mantenible a futuro y que este siempre actualizada, para ser útil.
Las metodologías ágiles no se tratan de no tener un contrato con el cliente. Se debe tener la visión del cliente para poder tener un proyecto exitoso desde el principio, pero dicha visión no debe usarse como el mantra del proyecto, que nunca puede ser modificado. El alcance, los requerimientos y las necesidades van a cambiar durante el proyecto, debemos aceptarlo y no rechazarlo mediante un contrato y control de cambios.
Por último, usando metodologías ágiles, se planifica, y de una manera mucho mas eficiente que las metodologías tradicionales. Se planifica de a poco, haciendo que cada paso sea seguro. Preguntale sino a un project manager tradicional, cuando va a terminar. Si es sincero, te va a decir que no sabe. Lo mismo pasará con un Product Owner o un Scrum master, por ejemplo, pero luego de tres iteraciones se irá animando a brindar alguna visibilidad mas certera. 

Y seguro, en el segundo caso el plan será mas cierto y fácil de seguir.




domingo, 12 de enero de 2014

Por que leer Lean Startup, de Eric Ries


Hace unos días termine de leer el libro "Lean Startup" de Eric Ries. Es un libro que busca transmitir una filosofía de management no tradicional, basada en los aprendizajes de metodologías de origen japones como Lean y Just In Time.
No es un libro para que lean solo aquellos que quieran comenzar su propia empresa - o startup, sino que lo primero que hace es hacer entender que todos somos emprendedores, ya sea iniciando nuestro propio emprendimiento independiente, o trabajando en una gran empresa multinacional.
Es un libro realmente muy interesante, que no se queda solo con la teoría, sino que muestra como llevarlas a la práctica y nos deja algunos casos donde su implantación fue un éxito.
En los próximos párrafos, voy a transmitir algunos de los conceptos que, segun mi opinión, son los mas importantes, y por los cuales recomiendo invertir el tiempo en leerlos del propio autor.
En primer lugar, los 5 principios de Lean Startup:

  1. Los emprendedores están en todos lados. O sea, no importa que trabajemos por nuestra cuenta o en una multinacional, todos los que trabajamos para crear nuevos productos y servicios somos emprendedores.
  2. El entrepreneurship es management. El "emprendedorismo" es una nueva disciplina, que debe existir en toda compañía.
  3. Aprendizaje validado. Las startups existen para aprender como generar un negocio sustentable. Esto se logra realizando experimentos, midiendo y aprendiendo.
  4. Build-Measure-Learn (Hacer-Medir-Aprender). Este es el ciclo de aprendizaje continuo que se debe llevar adelante, para realmente esforzarse en el producto indicado.
  5. Contabilidad de la innovación. No nos debemos olvidar de demostrar el progreso, priorizar y gestionar nuestros esfuerzos en la innovación.
Un punto que me pareció muy importante - y que es parte del core del libro, viene del principio 4 y 3. Lo mas importante es aprender, no importa si lo que produzcamos tiene éxito o no en el mercado al que apuntamos. Debemos "perdonar el error la primera vez, y asegurarnos de que no vuelva a suceder". Esto se logra realizando un MVP - Minimun Viable Product, creado en base a hipótesis iniciales, el cual nos permita - mediante mediciones de valor- validar dichas hipotesis, y nos brinde información para seguir en el camino planteado, o cambiar la ruta hacia un nuevo obejtivo, manteniendo la visión mientras sea necesario. Esta forma de trabajar asegura que vamos a usar nuestra capacidad - muchas veces escasa - en desarrollar el producto que realmente se requiere.

Nombre en el párrafo anterior que, para crear un MVP - el cual debe servir para validar lo que queremos, y tiene que ser lo mas simple posible-, es necesario tener hipótesis que el mismo siga. Estas hipótesis marcan como el producto se supone que creará valor, y como irá creciendo una vez establecido. Debemos tener claro estos dos puntos, y establecer una manera clara de medir la innovación y el aprendizaje generado mediante métricas base asociadas a cada hipótesis o assumption, que permita demostrar claramente y de manera no ambigua como se crea valor, y como se va creciendo. Si las métricas están bien definidas (y no son vanity metrics-enfocadas en un aspecto parcial del problema), nos va a permitir establecer cuando perseverar, o cuando cambiar el rumbo.

Debemos definir bien las métricas asociadas a nuestras hipotesis, teniendo en cuenta la regla de las tres A, para que las mismas sean:
  • Accionables. O sea, que deben demostrar claramente una causa y efecto.
  • Accesibles. Los datos deben ser accedidos por todos los involucrados en el producto, de la manera mas simple posible.
  • Auditables. Se debe poder tracear la información que generó las métricas, para defender cuando decimos que el proyecto va bien, o va mal y debemos cambiar el rumbo.
Volviendo a que el MVP sea lo mas simple posible. Es importante asegurarnos que vayamos avanzando en el desarrollo deproducto de a pasos cortos (small batches), que produzcan iteraciones de creación-medición-aprendizaje. Por eso, debemos ir planificando mejoras pequeñas, pero medibles y que nos permitan aprender y definir los siguientes pasos.

Algunas otras prácticas o herramientas que me parecieron interesantes:
  • Enfocarnos en tener un MVP simple, y validarlo con usuarios finales, en un ambiente real, aunque cuidado. Lo mas adecuado es realizar estas validaciones midiéndolas por poblaciones de usuarios (cohortes), lo que nos permitirá tener una visión mas acabada de nuestra situación.
  • Tener al aprendizaje sobre nuestro producto como primer objetivo, y dejar para una segunda instancia la optimización. Para un ingeniero o diseñador este punto es muy difícil, pero es vital mantenerlo en práctica.
  • Realizar pruebas de diferentes versiones de productos a diferentes poblaciones, comparando las métricas entre los diferentes grupos de clientes. Pueden ser mediante tests A/B, pruebas green-blue servers, etc.
  • Técnicas como continuous integration y continuous deployment permiten acelerar el ciclo de creación-medición-aprendizaje, mediante la automatización, que lleva a la eliminación de desperdicios (tiempos muertos), y el foco en esforzarse para crear valor en lugar de realizar tareas repetitivas.
  • KANBAN nos permite tener siempre visible la capacidad de nuestros equipos, y el flujo de actividades, haciendo mas simple encontrar puntos de mejora y aumentar la productividad general.
  • Debemos generar una organización adaptativa, que evolucione constantemente y no se quede congelada. Una herramienta para lograr esto, es ejecutar el ciclo de "5 porque" (five whys) cuando nos encontramos con un problema, para llegar a la raiz del mismo. Muchas veces, un problema que parece técnico - solución simple y superficial, en realidad esta dada por un problema sistémico y asociado a personas.
Esto fue solo un resumen de lo que a mi me parece mas importante del libro, pero es muy recomendable meterse a lleno, leerlo e implementar sus prácticas (Algo que voy a hacer, y luego comentar mis aprendizajes).


jueves, 2 de enero de 2014

Frases desmotivantes que se mal usan para motivar

Hoy tuvimos un almuerzo muy interesante con el equipo, esos donde se dan charlas al mediodía que muchos logran solo que sucedan a la noche, e incentivados por algunas sustancias prohibidas o no tanto. Pero no, estábamos sobrios, despiertos y con ganas de filosofar.

Entre tantos temas, surgió uno muy interesante: ¿que frases escuchamos, nos contaron o se ocurren que puede decir un lider, queriendo motivar, pero que logra totalmente lo contrario? A continuación, el compendio resultante, que se va a traducir en un "cubo de des-motivación":


  1. "Recorda: sos prescindible". Esta frase es terrible. Logra desmotivar hasta la persona mas motivada de un equipo. No tiene costado positivo alguno.
  2. "Es bueno tener actualizado tu perfil de linkedin". Tal vez esta frase halla sido utilizada con un lado positivo, el de enfrentar una posible futura crisis estando preparados, sin que nos agarre desprevenidos. Pero muchos (me incluyo) lo pueden tomar para el otro lado: Somos prescindibles
  3. "Si se puede mejorar, aun no lo terminaste". Horrible mensaje. Buscar la perfección a todo costo nunca puede llevar a nada bueno. Desgasta el equipo y no se logra ningún objetivo. 
  4. "Quedate trabajando... nadie te espera". Puff, malisima desde la primera a la última letra. No imagino una persona que pueda verse líder dando mensajes de este estilo.
  5. "No se puede ser el mejor en todo, y menos en lo que haces". No solo te insultan y te tratan de inutil, sino que dicen que lo que haces no tiene sentido. Aunque hay que ser sincero, saca presión ;).
  6. "¿Lindas las vacaciones? Ahora a trabajar, te faltan 350 días para las próximas". Esto puede ser un muy mal chiste de bienvenida de vacaciones, pero puede generar un pico de presión (y depresión) post-vacaciones que origina un espiral de malos augurios.
Actualización 3/1/14: Algunos agregados que me fueron pasando:
7. "No dejes para mañana lo que podes hacer hoy, posiblemente mañana no haga falta, o no estes para hacerlo". Esta pega bajo, muy bajo.
8. "Descansa en las vacaciones, te espera un año bien cargadito". Esta no solo no motiva, sino que te caga las vacaciones.

Seguramente existirán muchas mas, muy malas, tal vez sin mala intensión, pero muy hirientes y contraproducentes.

Seamos cautos con la comunicación, es lo mas importante.

PD: Gracias al equipo por los aportes!

lunes, 25 de noviembre de 2013

De que hablamos cuando hablamos de DevOps

Como todo nuevo término de la industria IT, DevOps tiene muchas implicancias y significados, dependiendo de los intereses, historia y conocimientos de quienes lo definan, y a quienes lo comuniquen.

Muchos pueden pensar a DevOps como una serie de herramientas para cambiar la forma de gestionar la operación de los sistemas y su relación con las áreas de desarrollo, mientras otros pueden definirlo como una serie de prácticas para extender las prácticas de desarrollo ágiles (SCRUM, KANBAN) hacia las áreas de operaciones. Otros, los escépticos, pueden decir que son un montón de gente loca intentando cambiar el mundo, y que obviamente fracasaran porque lo que funciona en este mundo es la previsibilidad, monitoreo y gestión de prácticas tradicionales como ITIL, y que lo propuesto por DevOps lo único que traerá es mas caos. Por último, están quienes creen que es un nuevo área de la organización IT que viene a salvarnos de todos nuestros problemas (estos últimos para mi son los mas errados).

Para mi, no es ninguna de todas las definiciones anteriores, y al mismo tiempo todas. Me gusta definir a DevOps basándome en un paper de Mandi Walls (Building a DevOps Culture), como un  movimiento cultural combinado con una serie de prácticas de desarrollo de software soportadas por herramientas que juntas habilitan a un desarrollo mas rápido (o a fallar mas rápido mas seguido). Por lo que es muy importante tener en cuenta que implementar un cambio a un nivel que mejore nuestra capacidad de entregar software de calidad mas seguido no es algo que pueda ser realizado de un día para el otro, y requiere su tiempo de maduración y soporte de la organización completa (o al menos aquellas áreas impactadas).

DevOps no es algo nuevo (Patrick Debois acuñó el término en 2009, mientras organizaba la primer DevOps conference en Bélgica), sino que es un muy buen blend entre prácticas maduras con enfoques novedosos para enfrentar desafíos comunes en la entrega y operación de soluciones de software. Mezcla la visión de desarrollo (no solo los desarrolladores, sino también testers y QA) y operaciones (incluyendo no solo a los operadores, sino también a administradores de sistemas, DBA), poniendo foco en la colaboración y feedback constante para soportar la mejora contínua de la forma de trabajo.

Según cuenta Michael Hüttermann en su libro DevOps for Developers, DevOps abarca numerosas actividades y aspectos:

  • Cultura: Las personas son mas importantes que los procesos y herramientas. Hay que tener siempre en cuenta que el software es hecho por personas y para personas. Debemos buscar la forma de ser felices haciéndolo, y hacer felices a los que obtienen el resultado de nuestro trabajo.
  • Automatización: Es esencial obtener feedback rápido y minimizar los errores en tareas repetitivas.
  • Medición: Se debe encontrar una forma única de medir, acompañado por incentivos de calidad y compartidos (o al menos alineados).
  • Compartir: Es imprescindible crear una cultura en la que las personas compartan ideas, procesos y herramientas.
Hablamos entonces de cambiar la cultura de dos áreas históricamente enfrentadas (desarrolladores vs operadores) para que se vean como un único equipo (con objetivos alineados), compartiendo información y apoyados en la medición continua y automatización de tareas que no aportan valor para mejorar el día a día de su trabajo, y paso a paso, como diría el Tolo Gallego.

¿Como podemos entonces emprender este cambio cultural para poder trabajar mejor? Debemos enfocarnos en generar una nueva cultura, con base en los siguientes pilares:
  • Comunicación abierta, donde nadie tenga miedo a participar y decir su opinión, y donde la decisiones sean tomadas de manera global, con responsabilidad compartida entre todos. Basta de ocultar información para sacarse de encima problemas.
  • Incentivos alineados, tal como lo comenta Michael Hütterman y tal como lo nombré en párrafos anteriores.
  • Responsabilidad alineada. Debe quedar en claro que la responsabilidad de un área no termina cuando culminó su porción de tarea y la pasó la pelota al siguiente pipe en el pipeline de desarrollo. La responsabilidad de todos los involucrados termina cuando se alcanzó el nivel de aceptación acordado entre TODOS.
  • Respeto. Todos deben respetarse. Puede ser que no se quieran (ya eso va de la mano de los sentimientos de cada uno), pero es vital que cada uno reconozca el valor del otro en el pipeline completo.
  • Confianza. Esto si es realmente desafiante. Los desarrolladores deben confiar en que lo que los encargados de operaciones les indican sobre el funcionamiento en producción, y estos últimos deben confiar en que lo que desarrollo produce es lo mejor dadas las circunstancias, y trabajar en conjunto para llegar a los objetivos planteados en conjunto.
Tenemos que tener en cuenta que algo es seguro: No es posible refactorizar una persona o resetearla tal como lo podemos hacer con las aplicaciones o los servidores. Se trata de un cambio interno de las personas, y debemos encontrar la forma de trabajar con los pre-conceptos, experiencias pasadas y prejuicios, para transformar la energía negativa actual en el combustible del cambio.

domingo, 4 de marzo de 2012

Creando infografías

Por cuestiones que no vienen al caso, tuve que pensar en como comunicar gráficamente muchos datos, métricas e indicadores, para que un auditorio no técnico comprenda claramente lo que se quería comunicar.

Esa tarea era algo desconocido para mi, ya que me gusta ver y analizar infografías, pero nunca puse a pensar como comunicar muchos datos de manera simple. Fué un gran desafío para mi.
En primer lugar pensé cuales eran las variables que quería mostrar (las cuales eran muchas), y luego vino la parte mas creativa, pensar como acomodar la información y luego la parte mas práctica, como llevarlo a una imagen.

Con respecto a como acomodar la información, caí en la cuenta de que lo que quería mostrar era la relación entre elementos (nodos), e indicar de alguna manera gráfica el peso que tenía esa relación entre los mismos. Además, debía indicar algunas otras métricas relacionadas a cada nodo. Por lo que decidí acomodar los nodos y sus relaciones como grafos, y que las relaciones mostraran con el grosor el peso que tenían. Para llegar a esto no fue que me dormi y al levantarme se me había ocurrido, sino que sumé mi lectura asidua de infografías a la búsqueda activa en http://vi.sualize.us. Es muy bueno para buscar inspiración (creo fervientemente que la creatividad no es mas que acomodar de otra manera ideas existentes).

Para terminar, la parte práctica la llevé a cabo con la herramienta de diseño open source Inkscape (descargable de http://inkscape.org). Después de probar varias alternativas open source al Photoshop y Corel Draw, me quedé con esta, por la cantidad de posibilidades que brinda, y la versatilidad de uso que tiene. Realmente es muy buena. La única contra, es que solo permite exportar a png, pero no es algo que me moleste demasiado.

En conclusión, tuve un día en que me puse el gorro de diseñador gráfico y realmente la pase bastante bien.

jueves, 9 de febrero de 2012

NLTK - Bitácora - La instalación

Gratamente motivado por un proyecto que estoy encarando, estoy aprendiendo NLTK (Natural Language Toolkit), una serie de herramientas de Python enfocadas en el procesamiento informático del lenguaje natural, siendo este el lenguaje que utilizamos los humanos para comunicarnos.
¿Para que me sirve procesar el lenguaje natural utilizado por los humanos? En el extremo simple, para contar la cantidad de veces que se repite una palabra o frase. En el extremo mas complejo, para lograr una comprensión de lo que se quiere transmitir con una porción de texto, y lograr conclusiones o acciones sobre dicha comprensión.
Sin meterme demasiado mas sobre la explicación del procesamiento del lenguaje natural (haré un post cuando tenga una comprensión mayor del tema), paso a comentar los pasos que hice hasta ahora.
Instalé las librerías y herramientas necesarias para poder trabajar con NLTK. Seguí las instrucciones de la documentación pública del toolkit (http://www.nltk.org/download), por lo que el primer paso, la instalación, fue dado.
Ahora, solo resta ponerse a aprender en base a ejemplos, para ir haciendo cosas mas complejas a futuro.

domingo, 8 de enero de 2012

¿Cual es el tamaño ideal de un equipo de arquitectura empresarial?

Según estuve leyendo en Gartner, establecen que según sus investigaciones el tamaño ideal de un equipo de arquitectura empresarial va inicialmente entre un 2% y un 4% del número total de personas que forman parte del área de IT de una empresa. No me cierra de esa frase que supone que Enterprise Architecture es solo IT, cuando tiene una gran relación con la tecnología, eso es cierto, pero también tiene mucho de estrategia y conocimiento del negocio.
No creo que se pueda establecer una relación tan clara y fuerte entre el tamaño de un equipo de EA y el área de IT, en primer lugar por lo antedicho, y en segunda instancia porque es necesario tener en cuenta muchas variables que son propias de cada organización, entre las que se me ocurren:
  • El alcance que el área de EA tiene en la organización, ya que no es lo mismo un área que solo se encargue de definir la estrategia de la arquitectura aplicativa, que aquella que tenga dentro de sus funciones la definición de la estrategia de negocio, la arquitectura tecnológica y aplicativa y la definición de tendencias del mercado.
  • El nivel de madurez de la organización, ya que si la organización ejerce una planificación estratégica ordenada, se requiere menos esfuerzo de arquitectura para llevarla adelante.
  • El presupuesto alocado por la organización para las iniciativas de arquitectura hará crecer o decrecer la cantidad de personas que formen el grupo de EA.
  • La madurez en la gestión de los proyectos, y la facilidad para hacer que cada proyecto tenga dependencia de las definiciones de EA definirá el nivel de esfuerzo requerido, y por ende la carga de trabajo que hará aumentar o decrecer al equipo.
Es necesario tener en cuenta muchas cuestiones para definir el tamaño del equipo, y no creo que exista una receta para definirlo. Pero creo que un buen comienzo es la definición de las actividades que realizará el equipo de arquitectura, los entregables que brindará y el nivel de servicio que se espera dar al resto de la organización. En base a esto, sumado a la cantidad de proyectos en ejecución y planificados y el nivel de participación, la tarea de definir el tamaño y capacidad de un equipo de arquitectura no es muy distante a la definición de un equipo para un proyecto cualquiera.

Organización de un equipo de EA

Una buena manera de establecer la organización de un equipo de arquitectura empresarial es tener en cuenta las funciones que debe cumplir el área, el valor que dicha función le brindará a la empresa, y la relación con los procesos de la empresa (como el ciclo de vida de desarrollo o el proceso de planificación estratégica).
Según lo veo, las funciones que cumple un área de arquitectura empresarial se pueden resumir en las siguientes:
  • Definición, que cubre la creación y establecimiento de políticas, estándares y guías base, que son el entregable para ordenar la estrategia de arquitectura de los diferentes proyectos de la organización.
  • Control, asegurando que los proyectos cumplan las políticas, estándares y guías base, y detectando la necesidad de cambio de dichos entregables definidos (ya que los mismos deben evolucionar y no quedar estancos). Esta función debe entregar un reporte del cumplimiento, excepciones o evoluciones necesarias.
  • Acompañamiento de los diferentes proyectos, cumpliendo la función de consultor en cualquier etapa de los proyectos IT, y guiando sobre el cumplimiento de las políticas, estándares y guias base establecidas. Obtiene también información de los proyectos como retroalimentación al repositorio de información de arquitectura y a la planificación arquitectural. No solo se participa como un consultor que aporta conocimientos técnicos, sino también de estrategia y de negocio.
  • Transferencia de conocimiento a todos los stakeholders de la organización o a quien requiera contar con los conocimientos generados por el área de arquitectura. Estos conocimientos no solo están relacionados a lo definido por la función de definición, sino también a lo que al área de EA conozca por su participación en todos los proyectos o la investigación sobre tendencias.
  • Investigación, que es una función mas que importante, ya que sienta las bases de los conocimientos necesarios para permitir una evolución constante de la arquitectura para brindar siempre el valor requerido.
  • Velar por que los activos generados por arquitectura (relacionados a arquitectura aplicativa, arquitectura de datos, arquitectura técnica, etc.) se encuentren actualizados y sirvan para la función que fueron creados, representar el cúmulo de información necesario para conocer el estado actual y establecer el estado futuro de la arquitectura.
Luego, es necesario mapear cada una de estas funciones a los procesos organizacionales, determinando claramente el valor que la función de EA le brindará a la o las etapas relacionadas. De esa forma, se comunicará claramente a los stakeholders el valor brindado (también es importante encontrar la forma de medir el retorno y el valor generado).
Teniendo estas funciones como base y el mapeo con los procesos organizacionales, se cuenta con una base para planificar la organización del equipo, establecer la cantidad de personas que deben formar el equipo de arquitectura, y comunicarlo a las personas adecuadas para la ejecución del plan de EA.

jueves, 1 de diciembre de 2011

Sobre la impresión de fotos y el poder de las redes

Esta semana tuve una experiencia interesante. Todo empezó hace seis meses, cuando compré en Groupon una promo para imprimir 50 fotos digitales a un muy buen precio, en Megaphoto.
Obviamente, recién recordé hacer el pedido menos de un mes antes de que se venciera el cupón, y porque me avisó Groupon. Entonces elegi las fotos, e hice el tan esperado pedido. Ahí empezó la historia.
Luego de esperar 5 días (el tiempo en que Megaphoto atiende los pedidos de sus clientes según su sitio) Me informan que los pedidos de Groupon se atienden con 15 días de demora en lugar de 5. OK, acepté las nuevas opciones (en realidad no vi la letra chica del cupon). Por cuestiones que no vienen al caso, el pedido cumplió un mes, y yo aún no tenía mis fotos. ¿Que hice? Me puse en contacto con Megaphoto vía mail, obteniendo una respuesta bastante inesperada. Su excusa fué que no podían haber previsto que el 45% de los pedidos por Groupon fueran hechos el último mes, por lo que tenían un retraso y el pedido estaría en esa semana. Otra vez, me mordí los labios y espere.
Esta semana fué que mi paciencia colapsó, e hice uso de una herramienta sobre la cual siempre utilicé para informarme o para estar en contacto con amigos y conocidos, pero nunca para reclamar: Facebook y Twitter. Escribí en el muro de Megaphoto copiando a Groupon, y publique mis quejas en twitter mencionando a Megaphoto y Groupon. A la hora tuve la respuesta de groupon interesado en saber cual era mi problema, y Megaphoto recién respondió a Facebook al día siguiente de la publicación, pero eliminando la misma (la respuesta vino por mail directo a mi, y luego un llamado telefónico). Finalmente hoy ya tengo las fotos en mi poder.
No se que hubiera pasado de no ser por mi incursión en las redes sociales para quejas, pero lo que si se es que resultó mi acción tal como esperaba, sacando algunas conclusiones interesantes de todo esto:
  • Siempre ver las letras chicas de los cupones, sea cual sea su proveedor
  • Confiar en Groupon, su atención es realmente muy buena
  • No confiar en Megaphoto
  • Cuando tengo que hacer un reclamo, usar las redes sociales. Nada hiere mas a una empresa que su reputación social.
  • Si tengo una empresa en algún momento, y la misma tiene perfil social, nunca eliminar las quejas de mis clientes. Responder por el mismo canal que hicieron el contacto. Megaphoto actuó muy mal eliminando el comentario (parece que solo dejan las publicaciones que hablan bien de ellos)

domingo, 22 de mayo de 2011

Mecanismos de integración

En la publicación anterior escribí sobre los puntos a tener en cuenta a la hora de definir una integración entre sistemas. Ahora, voy a comentar, desde mi punto de vista y experiencia, los diferentes mecanismos que existen para resolver esta cuestión, y cual es la relación entre estos y los atributos de calidad anteriormente mencionados.
Antes de empezar, voy a dividir los mecanismos, solo por claridad en la comunicación, entre mecanismos puntuales y masivos. Los primeros son aquellos mecanismos que permiten intercambiar información entre un sistema y otro en forma puntual, digamos de una interacción a la vez (por ejemplo, la solicitud del alta de un cliente, o la consulta de tweets ingresados por un usuario el último mes). Los segundos permiten la integración entre dos sistemas intercambiando grandes volúmenes de información. Los primeros generalmente son utilizados para interacciones online, mientras que los segundos son utilizados para integración batch. Los primeros son generalmente sincrónicos (o el usuario los ve de esa manera), mientras los segundos son naturalmente asincrónicos.
Ahora, una vez establecida esta división, transcribiré en resumidas cuentas cada uno de los mecanismos.

Mecanismos puntuales
Web Services
Los web services son un mecanismo de integración basado en una colección muy amplia de protocolos y estándares, basados todos sobre los mismos estándares sobre los que funciona la web (aunque existen implementaciones de los mismos sobre tecnologías de mensajería). El principal protocolo y estándar en el que se basa es SOAP (Simple Object Access Protocol), que define el formato en que se intercambia la información, dividiendolo básicamente entre header (cabecera que permite configurar el transporte), y el body (que contiene los datos a transmitir). Otro estándar importante es WSDL (Web Service Description Language), que define la estructura del mensaje, estableciendo los tipos de datos, campos y estructura de información a transmitir, sumado a UDDI (Universal Description, Discovery and Integration) para el registro de servicios web.
Con el paso del tiempo, se sumaron otros estándares al stack, para cubrir diferentes funcionalidades o atributos de calidad. De esta forma, tenemos por ejemplo WS-Security, WS-Reliablemessaging, o WS-transaction, que cubrieron aspectos que fueron dejados de lado por la definición inicial de SOAP, aunque agregándole complejidad.
Desde mi punto de vista, es una buena alternativa para interoperabilidad en ambientes heterogéneos, siempre y cuando nos basemos en el estándar SOAP sin ningún adicional del stack WS-*, ya que estos últimos no fueron implementado de la misma forma por todos los vendors. Aunque, si los sistemas a integrar son desarrollados en la misma tecnología y vendor tecnológico, el uso del stack WS-* soluciona diferentes cuestiones que son necesarias tener en cuenta.
Con respecto a la relación con los atributos de calidad, si se aplican bien los conceptos de WS, este mecanismo de integración se encuentra muy a favor de la coherencia semántica, unificación de mensajes y reusabilidad (heredado de la orientación a servicios). En lo que respecta a interoperabilidad, esto es una promesa, que no siempre es bien cumplida y en diferentes ocasiones presenta sus dificultades. El rendimiento de las integraciones se ve menguado debido a lo verboso de los mensajes (se estima que del total de un mensaje WS, solo el 30% representa datos con significado funcional). En lo que respecta a robustez, escalabilidad, facilidad de administración y disponibilidad, los mismos dependerán mucho de las plataformas donde se implementen los servicios (ESB, Application Server, Web Server). En lo que respecta a los tests, tener el contrato (WSDL) separado de la implementación permite crear servicios "mockeados" que implementen la funcionalidad necesaria para realizar los tests, mientras que los contratos pueden verse como auto-documentados, un beneficio que da XML y el estándar WSDL a este tipo de integraciones.

Cuando utilizarlo:Debido a la carga en cuanto a performance, lo utilizaría en aquellos casos en los que se requiera seguridad, trazabilidad, y cuando la performance no sea un requerimiento fuerte. Si se requieren interfaces autodocumentadas, es la opción por la que se debe ir. También es apto en aquellos desarrollos donde se requieran facilidad de pruebas.

REST
Este mecanismo de integración, cuyas siglas significan REpresentational State Transfer, aparece como una alternativa a los web services, para integraciones basadas en la arquitectura WEB y HTTP como transporte. Es muy utilizado por los grandes jugadores de la WEB 2.0 (Facebook, Google, Twitter y otras lo utilizan para sus APIS).
REST presenta las integraciones basado en los recursos de los sistemas (principal diferencia con respecto a los web services, que se basan en funcionalidades), basándose en la arquitectura HTTP, e implementando los siguientes principios:
  • Identificación de recursos a través de URIs (Uniform Resource Identifier)
  • La manipulación de los recursos se realiza a través de sus representaciones, utilizando los métodos HTTP de manera explícita (GET - consultar un recurso, POST - crear un recurso, PUT - modificar un recurso, DELETE - eliminar un recurso), y basándose en la información obtenida de la representación de los recursos.
  • Mensajes auto-descriptivos, de forma tal que cada mensaje tenga la información necesaria para procesarlo (por ejemplo, estableciendo su MIME type y gestión de cache)
  • La hypermedia se usa como motor de gestión de estado. Si bien es un mecanismo de integración stateless (sin estado), la interacción entre consumidor y proveedor se realiza a través de hyperlinks o hypertext presente en la representación.
Como se basa en un estándar ampliamente aceptado (HTTP), intercambiando mensajes JSON (Java Script Object Notation), XML o YAML(Yet Another Markup Language), una de sus principales ventajas son la interoperabilidad, reusabilidad, unificación de mensajes y coherencia semántica (heredados de la orientación a servicios), sumado a un gran soporte de la escalabilidad (heredado de HTTP). Representa una gran mejora en lo que respecta a performance comparado con los web services, ya que disminuye la cantidad de datos innecesarios y sin significado de negocio. Otra vez, la robustez, facilidad de administración y disponibilidad, los mismos dependerán mucho de las plataformas donde se implementen los servicios (web server). La seguridad es una de sus falencias, ya que como mecanismo básico tiene lo soportado por HTTPS (Secure HTTP), requieriendo agregados como proxies o firewalls para mayor complejidad (por ejemplo, un appliance de HW como Datapower podría cubrir estos requerimientos). El formato de mensaje, si bien no es tan autodocumentado como en el caso de web services, da un cierto soporte a la documentación y comunicación, siempre y cuando se establezcan criterios claros entre las partes.

Cuando utilizarlo: Este mecanismo es una muy buena alternativa a web services. Es fácil de usar cuando los recursos del sistema proveedor están claramente identificados, y no se tengan grandes requerimientos en cuanto a seguridad, trazabilidad y transaccionabilidad (ya que agregar estas características complejizarían el desarrollo). Si lo que se requiere es performance e interoperabilidad, es una excelente alternativa.

XML over HTTP
Este mecanismo se podría ver como un subconjunto de REST, ya que se basa en HTTP como transporte, y para la definición de los datos sensibles al negocio se establece XML para representar los mismos.
La única diferencia entre REST y este mecanismo, es que no cumple los principios establecidos por REST, ya que por ejemplo las interfaces o servicios expuestos pueden no estar representados como recursos, ni hacer uso de URIs para identificarlos.
También puede verse como una simplificación de los Web Services, ya que si bien utilizan XML para la transmisión de datos, no supone la carga de SOAP y WSDL.
Tiene, entonces, una mejor performance que los web services, pero no cuenta con la ventaja de ser autodocumentado, ya que no se requiere un estándar de definición de protocolos, y los mensajes muchas veces son definidos previamente entre las partes. La interoperabilidad estará dada, mientras se mantengan los acuerdos entre las partes, pero nada de los protocolos estándar utilizados juega en contra de esta calidad.
Otra vez, la robustez, facilidad de administración y disponibilidad, los mismos dependerán mucho de las plataformas donde se implementen los servicios (web server, application server).
La seguridad estará dada por las plataformas subyacentes, mientras que la claridad de documentación y comunicación no es una característica de este mecanismo.

Cuando utilizarlo: No recomendaría utilizarlo, ya que es una versión mala de REST. En caso de aparecer como una alternativa, evaluaría seriamente el uso de REST antes que este.

RSS
RSS (Really Simple Sindication), es básicamente un estándar XML para sindicar o compartir contenidos en la WEB. Su principal uso es la difusión de información a usuarios que se subscriben a una fuente de contenidos.
Su principal uso es la lectura de noticias o novedades en sitios web o blogs, mediante herramientas "agregadoras" (web browsers, Google reader, Bloglines).
La arquitectura que implementa este mecanismo es básicamente un publish-subscribe, en el cual un ente publica información, que interesa a uno o mas consumidores, los cuales no son conocidos por el publicador.
Es muy útil para sistemas que requieran compartir información multimedia, o solo-texto, a diferentes aplicaciones implementadas en diferentes tecnologías, y desconocidas. No es simple realizar este tipo de integraciones, pero existen frameworks como RSS 2.0 (en C#), o RSS Framework (en PHP).
No es un mecanismo que este acorde a la comunicación entre personas o documentación, y cuyo soporte a la performance, disponibilidad, robustez dependerán del tipo de desarrollo implementado.
Por su poca o nula políticas de seguridad, debe usarse en aquellos casos en que la información sea pública y poco sensible.

Cuando utilizarlo: Implementarlo en aquellos casos donde se quiera dar a conocer información que no requiera demasiada seguridad, y que interesa a diferentes consumidores desconocidos, distribuidos en internet.

LDAP
LDAP (Lightweight Direct Access Protocol), permite en su utilización mas común la comunicación con un directorio de identidades, utilizando esta integración para autenticación y autorización.
Pero, por la forma de estructuración basada en una entidad principal, diferentes roles o características de dichas entidades, y dependencia entre entidades, es muy útil en algunos casos. Por ejemplo, en una empresa proveedora de internet, podría tenerse una estructura por ubicación geográfica (AMBA, NORTE, SUR), dentro de cada uno podría establecerse una división por tipo de cliente (gran cuenta, individuo), de los cuales se desprenderían los diferentes servicios que tiene activo el cliente, para su uso por la red, o los sistemas de CRM. ¿como se conectarían estos sistemas con el repositorio? a través de LDAP.
Tiene un uso muy acotado a ciertas funcionalidades, pero es bueno tenerlo en cuenta para no realizar un desarrollo importante teniendo herramientas que puedan resolver la problemática. Las herramientas van desde componentes software pagos (Microsoft Active Directory, Oracle Identity Management) a aplicación gratuitas (Microsoft ADAM, open LDAP).
Es aplicable solo a intranet, debido a la simpleza del protocolo. Las calidades de tiempo de ejecución dependerán de la solución de directorios seleccionada, mientras que las calidades de comunicación no son muy bien implementadas.

Cuando utilizarlo: En aquellos casos en que se requiera implementar una funcionalidad basada en una entidad, que permita establecer una estructura jerárquica centrada en la misma, estableciendo características en dicha entidad, implementar un motor LDAP y realizar la integración mediante dicho protocolo.

Sockets TCP
El protocolo TCP basa su fortaleza en la conexión de sistemas a bajo nivel, siendo uno de los protocolos fundamentales de internet. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el orden en que fueron transmitidos.
Al ser un protocolo de bajo nivel, las funcionalidades que soporten las calidades de tiempo de ejecución deben implementarse desde cero, siendo una solución poco simple de desarrollar. No es una buena solución para cuestiones asociadas al diseño de interfaces (salvo un gran esfuerzo de estandarización y acuerdos entre los participantes), ni para documentación.
Es uno de los mecanismos que mejor performance tiene, siempre y cuando el mensaje a enviar sea simple y no verboso (recordemos que los web services, por debajo, hacen uso de TCP).
La interoperabilidad puede verse como un fuerte, ya que este protocolo es aceptado por aplicaciones que van desde C o C++ hasta Ruby, .NET o Java.

Cuando utilizarlo: Cuando se requiera integraciones simples entre diferentes sistemas, sin requerimientos de seguridad, y cuando la performance sea una necesidad imperiosa.

CORBA
CORBA (Common Object Request Broker Architecture) es un estándar que permite el desarrollo de sistemas distribuidos facilitando la integración mediante invocación a métodos remotos, siendo los sistemas orientados a objetos.
Definido por el OMG (Open Management Group), establece las APIs, los protocolos y mecanismos necesarios para asegurar la interoperabilidad entre aplicaciones. Básicamente lo que hace es transformar la especificación de los servicios en cada tecnología a un IDL establecido y estandar, realizando las transformaciones necesarias. Existen implementaciones estándares para ADA, C, C++, Smalltalk, Java, Python, Perl y Tcl. Existen también proyectos como Remoting.Corba, que intenta integrar aplicaciones .NET con CORBA, o Corba-Ruby para aplicaciones en Ruby.
Su gran fuerte y objetivo es la interoperabilidad, aunque ya no se ve mucho en los nuevos desarrollos, ya que producen un detrimento de la performance y no siempre es tan independiente como se dice de la tecnología subyacente.
Produce dependencia entre las aplicaciones, ya que hace que un sistema conozca los objetos de otro sistema, lo que no es nada bueno para las calidades de diseño, y en tiempo de ejecución tiene diferentes cuestiones que depende de la tecnología en la que se encuentre implementada cada una de las aplicaciones involucradas.

Cuando utilizarlo: Cuando exista una aplicación CORBA que deba integrarse con otros sistemas.

Otros mecanismos
Existen otros mecanismos, que por su poca importancia, o implementaciones no vale la pena bajar a detalle. Estos son por ejemplo Etch, creado por CISCO como un reemplazo a los web services, sin demasiado éxito; o DCOM (Distributed Component Object Model), tecnología propietaria de Microsoft ampliamente usada en VB 6, caida en desuso en nuevas implementaciones.

Mecanismos masivos
Una problemática que se tiene a la hora de decidir utilizar este tipo de integraciones es la definición de cual es el volumen de información que me hace utlizar un medio masivo y cuando usar un online. A los efectos prácticos, vamos a decir que cuando la necesidad de obtener la información es puntual, o puede deberse a una única operatoria de negocio en un corto lapso de tiempo, y cuando dichas operatorias pueden darse desde diferentes fuentes - o usuarios, en un mismo momento, utilizaremos medios puntuales. En cambio, cuando las solicitudes o información provenga en un mismo momento, en forma masiva y en bloques, utilizaremos mecanismos masivos.

ETL
ETL (Extract, Transform and Load) se refiere al proceso implementado para extraer información de una fuente de datos, transformarla, reformatearlos, limpiarlos e introducirlos en otro medio de almacenamiento (DataMart, base de datos, archivos).
Es ampliamente usado en DataWarehouse, pero es muy útil para realizar integraciones que requieran un movimiento de un volumen grande de información.
Desde el punto de vista de diseño son buenas alternativas, ya que se pueden reutilizar los componentes de extracción, transformación y carga, sirviendo los mismos para definir diferentes flujos de integración, aunque hace que sea necesario conocer la estructura de datos de los sistemas origen y destino, lo que hace muy grande el acoplamiento. La performance dependerá de la forma en que se implemente, siendo muy buenas estas soluciones para asegurar robustez, seguridad, disponibilidad e interoperabilidad.
En cuestiones de diseño no es tan bueno, ya que pocas soluciones son auto-documentadas.
Existen en el mercado diferentes soluciones que implementan este tipo de integraciones, como Informática PowerCenter, Oracle WareHouse Builder, o Microsoft SQL Integration Services.

Cuando utilizarlo: Cuando se requiera integración mediante movimiento masivo de información entre diferentes plataformas heterogéneas utilizando diferentes fuentes de datos, y en los que no sea inconveniente el acoplamiento entre sistemas (cabe aclarar que las soluciones de ETL del mercado tienen la capacidad de desarrollar conectores, lo que minimiza el acoplamiento).

Mecanismos híbridos
Colas / Mensajería

Un sistema de mensajería permite la comunicación entre aplicaciones de forma indirecta. Esto se logra mediante el envío de mensajes a un administrador de mensajes, al cual están asociadas las aplicaciones, y es este último quien se encarga de administrarlos y distribuirlos según diversas configuraciones.

N

o es necesario especificar una aplicación de destino a la hora de enviar mensajes, sino que especifica el nombre de una cola.

Una aplicación puede tener una o mas colas de entrada y una o diversas colas de salida.

No es necesario preocuparse por de la tecnología existente en la aplicación destino, o si la aplicación destino no se encuentra disponible (en el caso de los mensajes asincrónicos), sino que el motor de colas se encarga de reenviar el mensaje si la misma se encuentra detenida o bien de iniciarla dependiendo del caso.

Un mensaje consta de dos partes básicas: el header (que contiene información de control que facilita el funcionamiento del administrador), y la data (información a intercambiar entre las aplicaciones).

En la implementación básica, una aplicación entrega un mensaje al administrador (motor) de mensajería, el cual mantiene el mensaje vivo hasta que llegue su tiempo de expiración, o hasta que el consumidor del mensaje lo tenga en su poder.

La integración vía mensajería se basa en la robustez mediante la persistencia de los mensajes enviados, la gestión de prioridades de entrega (por defecto, el mecanismo de entrega es FIFO, pero existen formas de adaptarlo), o expiración de los mensajes (ya que los mismos no pueden estar presentes en la infraestructura del administrador por siempre).

La implementación de colas de mensajería aseguran un bajo acoplamiento entre los sistemas (ya que implementa un modo de comunicación asincrónico, siendo el administrador quien se encargue de entregar el mensaje), al mismo tiempo que asegura la interoperabilidad (siempre y cuando se utilicen motores de colas estándares, estándares de facto o con conectores multi-tecnológicos, como IBM MQ, o implementaciones JMS como ActiveMQ o RabbitMQ).

Las calidades relacionadas a diseño dependerán del buen criterio que se implemente para crear las integraciones, lo mismo que sucede con las cuestiones de comunicación. No es una solución buena para el test.

Existen diferentes motores en el mercado, pasando de los propietarios (Microsoft MSMQ), a los estándares "de facto" (IBM MQ, Oracle AQ), y los estándares tecnológicos (Rabbit MQ, Apache Active MQ).


Cuando utilizarlo: Siempre que se pueda, y cuando el manejo de mensajería asincrónica no sea una contra (ya que, por ejemplo, se requiera conocer en el momento la entrega del mensaje y su respuesta). Tener en cuenta las tecnologías involucradas para seleccionar el motor de colas.


Archivos
La integración a través de archivos es una de los mecanismos mas utilizados desde hace ya mucho tiempo. Se basa en el acuerdo entre las partes involucradas acerca del contenido y formato del archivo, para que luego el proveedor de la información genere un archivo basado en el mismo ante cada necesidad de integración, y lo deposite en un repositorio pre-acordado. Luego, el o los consumidores de la información proceden a la lectura, interpretación, y actuación en consecuencia de la información contenida.
Este mecanismo de integración permite manejar la independencia entre aplicaciones, siempre y cuando los datos involucrados en los archivos no incluyan información relacionada a la implementación de un determinado sistema, y asegura la robustez y disponibilidad de la información (aunque la interoperabilidad esta asegurada). La seguridad es manejada a través de permisos en los repositorios, y mecanismos de encriptación (como PGP - Prety Good Privacy). No es bueno para documentación, ya que no es un mecanismo auto-documentable, salvo en los casos en que se utilicen estándares de integración masiva, como por ejemplo EDIFACT (Estandar desarrollado por la ONU para intercambio de documentos comerciales).

Cuando utilizarlo: Siempre que se pueda usar un ETL, lo priorizaría ante este mecanismo. En caso de no poder utilizarse ETL (por costos, por ejemplo), usarlo en cualquier integración masiva que no pueda reemplazarse por colas.

Base de datos
No voy a explayarme mucho sobre el uso de una base de datos para integrar varias aplicaciones. Solo voy a decir que, si bien es simple de realizar (ya que la conexión a base de datos es lo segundo mas estandarizado luego de los archivos), y que es un mecanismo robusto y seguro, no recomiendo su uso, ya que genera una dependencia muy fuerte entre los sistemas involucrados, hecho que luego es muy difícil de cambiar. Cualquier integración que se piense a través de base de datos, se puede reemplazar por los mecanismos antedichos.