jueves, 24 de septiembre de 2015

Avanzado mas con Lego Serious Play

Han pasado ya 2 meses desde que tomé el taller de Lego Serious Play con Robert Rasmussen, aún sigue mi cerebro con la programación que hizo en casi 40 horas sobre como usar el método.


Durante este tiempo, he podido ya llevar a cabo tres talleres de Lego para distintos enfoques. 

No puedo aterrizar del todo los nombres de las organizaciones donde he trabajado, pero ahí les va un poco la narración de la experiencia.

  • Definr un modelo de innovación en una organización de gobierno. El foro fue mucha gente de Tecnología de Información. Se obtuvo un modelo de innovación que va a dar pauta a empezar a detallar los componentes identificados
  • Definir la estrategia de ecommerce de una empresa. El foro fue gente de mercadotencia, ventas, logística, almacenes, directores. Se obtuvo un modelo de negocio, complementando con el Liezno de Model de negocio (Business Model canvas) 
  • Definir la visión de arquitectura de una empresa. El foro fue gente de administración financiera y de TI. Se uso la técnica de TOGAF de Business Scenario. 
En todos los talleres, tuve que dedicar un tiempo a inducir a los equipos en el uso de Lego así como enseñarlos a compartir sus modelos. Aquí está el manual del kit de Arranque de LSP

De todos los talleres, el reto mas interesante es cuando como habilitador logras que el equipo obtenga un modelo común y resultado de todas las ideas. Es un hito tener la integración del equipo y a partir de ese momento se vuelve mas divertido para todas los participantes el continuar construyendo modelos.

La mente humana es sorprendente así como cada persona es un nicho de sorpresas. Gracias a LSP se puede conocer a cada persona y escuchar su óptica. 

Como habilitador, cambia mucho la perspectiva sobre como trabajar con equipos de personas.

En resumen, ha sido muy satisfactorio este modelo de trabajo y con muchas sorpresas

Por cierto, en el transcurso de estos dos meses me he acabado el inventario de Legos genéricos y duplo de Juguetibici y Juguetron. He dejado a varios niños sin un potencial y divertido juguete..


domingo, 20 de septiembre de 2015

Computo en la nube o de como empieza el reinado de los servicios

Hace más de dos decadas, el autor de este artículo, Gustavo De la Cruz, estudiaba y devoraba la arquitectura de CORBA y marcos de objetos distribuidos similares (COM, SOM y otras decenas de tecnologías similares) con el fin de lograr un esquema de aplicaciones integradas a través de objetos. En esos tiempos los lenguajes Orientados a objetos eran C++, Objective C, Smalltalk, Eiffel y todos prometian una pronta integración entre ellos.  SUN Microsystems tenía un proyecto muy fuerte entre manos para revolucionar el computo distribuido. Estoy hablando de inicios de la decada de los 90.

La arquitectura se basaba en servicios comunes para lograr la persistencia, ciclo de vida, concurrencia, seguridad, eventos, transacciones y un sin fin de servicios que parecía el paraíso de los programadores para hacer aplicaciones distribuidas basadas en objetos. El protocolo unificador era IIOP y parecia que nadie iba a poder igualar esta labor, ni Microsoft con su COM.

En esos tiempos este era mi libro de referencia y lo leía casi todos los días



Y llego Java, y los jovenes proyectos acabaron devorando a los viejos proyectos de CORBA. Aunque al principio Java fue un lenguaje excelente para implementar CORBA, en ese momento también el uso del protocolo HTTP como el gran transportador de mensajes síncronos entre aplicaciones y elevando el nivel de estandarización y la capacidad de exponer objetos no solo en redes privadas, sino via la naciente Internet. Así se unió al modelo multicapa, una capa adicional, de 3 a 4 capas, la capa de Web.

Muchos saben ya la historia, salió J2EE (hoy JEE) y muchos servicios de CORBA vieron su simil, Transacciones y ciclo de vida se volvieron EJBs, Persistencia EJB de entidad, Naming a JNDI y con eso se elevó el nivel de reuso de servicios. Y si, los programadores ya teniamos las herramientas para hacer la magia que tanto soñabamos con objetos. Llegó la epoca del servidor de aplicaciones. Decenas de compañías te ofrecían en el JavaONE su producto, empresas que ya no figuran. Podría decir que los únicos sobrevivientes de esos tiempos que ahora veo con una particular nostalgia de mi epoca de juventud adulta, son WebLogic, Websphere y JBoss, TomCat (es un appserver ??)  donde se pueden edificar arquitecturas de despliegue que pueden usar procesamiento de manera escalable y formando clusters.

En esos tiempos, los que eramos arquitectos de software, con un pequeño nivel de soberbia, no pensabamos tanto en el hardware. Al final, la magia de la portabilidad permitia que el diseño pudiera ejecutarse en cualquier tipo de computadora que soportara la JVM y podiamos confiar que la ingeniería del JIT se podía encargar de ejecutar de manera optima el código...

Esta arquitectura aun es la reina en muchos ambientes de aplicaciones empresariales. Hemos educado a las nuevas generaciones a confiar sin cuestionar la magia de los servidores de aplicaciones. De igual manera, el mundo  Microsoft .NET hizo lo similar y aprovechó las lecciones dolorsamente aprendidas en temas de desempeño para simplificar el modelo de aplicaciones con objetos distribuidos.

Llegó la revolución de la simplificación, 2003, cuando Rod Johnson y varios más cuestionaron el enfoque de utilizar/desperdiciar recursos de computo y volvieron a los Plain Old Java Objects.  Se dieron arquitecturas livianas, corriendo con TomCat y rompiendo la ortodoxia de que todo era un EJB.

Los clusters de Weblogic o Websphere seguían teniendo sentido para aplicaciones que necesitaban de escalabilidad y de manera mágica se hacia la migración y manejo de las fallas, así como unir al cluster una JVM más. Así es el estado de los actuales servidores de aplicaciones y se han optimizado con esquemas de base de datos en memoria o caché (Terracota, Coherence)

La última complicación del lado del mundo Java fueron sus JSF, con el intento de hacer componentes web reutilizables, pero con demasiado énfasis en que todo lo resuelve el servidor.

Y el resurgimiento de Javascript, dado que el navegador ya no es una pieza tonta de software que solo desplegaba HTML e imágenes, sino toda una gama de componentes para visualizar, almacenar, comunicar que ahora es HTML5, CSS3 y Javascript y donde el procesamiento se puede hacer en la computadora cliente que ya tiene capacidades respetables.

Agregado a la aparición de aplicaciones móviles que muchas veces tienen que trabajar fuera de línea; todo ha llevado que los servicios distribuidos tienen una clara definición de que es lo que deben de hacer y estandarizados a través de modelos basados en REST o intercambio con JSON.

Esto ha llevado a una nueva variante de implantar los servicios. Muchos usando software abierto. Modelos de base de datos donde ya no solo es SQL la única opción, distribución de la carga de trabajo usando esquemas de mensajes asíncronos y capacidades para analizar grandes volumenes de datos usando procesamiento distribuido.

El hardware se ha vuelto un "commodity" y los procesadores, almacenamiento y redes se pueden manejar por decenas y abaratando los modelos de computo distribuido e implantar masivamente servicios de software que están reemplazando al modelo de servidores de aplicaciones pero usando directamente las capacidades del hardware "virtualizado".

Como dije, hace un par de decadas no era el hardware el modelo primordial al diseñar la arquitectura, hoy en día es fundamental y la escalabilidad y tolerancia a fallas ya no es tanto de un sistema operativo o de un middleware, sino de mecanismos que permiten replicar imagenes virtuales sobre múltiples procesadores y almacenamiento y con la capacidad de resistir a fallas. Ya nadie queda impactado si un nodo de computo tiene un problema, puede ser reemplazado por uno similar y  en cuestión de segundos o minutos.

Todo esto es lo que se llama computo en la nube. Al final es lo que narro, muchos servicios disponibles con un pool de recursos casi infinito de procesadores, almacenamiento y redes y disponible de manera ubicua a través de Internet.

Nunca he comprobado esta teoria, pero presiento que la manera como se están solucionando los diversos temas relacionados con ofrecer un servicio de la nube viene desde lo aprendido por muchos en sus clases de sistemas operativos o  ambientes distribuidos, de un sistema operativo llamado Amoeba, que nacio de la escuela de Andrew Tanenbaum. El siguiente diagrama muestra la arquitectura y vean que el pool de procesadores es lo que ahora se llama computo elástico. Los invito a leer los libros de Tanenabaum en esta materia y se van a ver sorprendidos que hace 20 años ya las ideas actuales estaban definidas


A lo que voy de toda esta historia es que el momento que estamos viviendo de computo en la nube es el momento de madurez de un tipo de computo que fue concebido como objetos y que se transformo a servicios que son ubicuos, portables, interoperables y con la capacidad de explotar hasta el "tuetano" las capacidades de virtualización de hardware.

Hoy mucha gente está preocupada sobre la nube, que implica.  Puesto de manera simplificada es poner en Internet tus aplicaciones. Ese puede ser el primer foco de usar una nube pero no es el mejor en términos de arquitectura por que es llevarse todo lo que tienes bien y mal en los sistemas empresariales y no usar el total potencial de la tecnología de la nube. Muchos aún se preocupan por subir el servidor de aplicaciones, clusters, la complejidad de un RDBMS en la nube. Como primer paso quizá está bien pero ...

Es importante que los especialistas de TI se abran y entiendan el estado actual del arte de la tecnología. Ya  no hay un solo lenguaje de progamación, ya no hay una plataforma que predomine, la guerra de CPUs (CISC vs RISC) o de sistemas operativos (Windows vs UNIX-Linux)  se acabó y hubo ganadores que ni siquiera pueden ya cantar victoria. 

Lo que se debe aprovechar es la riqueza y variedad potencial de los servicios distribuidos que se ofrecen y usarlos por sus caracteristicas (disponibilidad, confiabilidad, capacidad, seguridad, portabilidad e interoperabilidad) y ya no ponerse en modo ortodoxo si es de un fabricante o una tecnología en particular. En este momento, la visión inicial de los objetos distribuidos como componentes reutilizables (o de re uso) ya es un hecho pero no es el resultado del esfuerzo de un fabricante o grupo (como era DCE o CORBA) sino de la apertura del software abierto y que ha sido adoptado por cuestiones técnicas y no comerciales y se han vuelto estándares de facto.

Asi que si en el servicio existe una arquitectura MEAN o JEE o .NET, o con servicios NoSQL o Hadoop o Spark o RabbitMQ o AMQ, con Windows o Linux; no es preocupante la variedad tecnológica, es bueno dejar la libertad y creatividad a los arquitectos y programadores del software y garantizando los requerimientos técnicos y el nivel de calidad de servicio; y controlar (gobernar) a través de buenas definiciones de arquitectura empresarial y estándares la enorme variedad de tecnologías. 

Pensar entonces como servicios de plataforma es el enfoque, o lo que se conoce como Platform as a Service (PaaS)  es lo que permite explotar el modelo de encapsular la complejidad. 

La siguiente presentació de Slideshare, Pizza as a Service,  ayuda a entender el modelo de la nube. Muchos de los lectores ya usan SaaS, dado que tienen una dirección de correo electrónico personal basada en algun servicio (Gmail, Outlook, Yahoo?) 

Empezando a pensar en el futuro. Hoy grandes empresas ofrecen las nubes. Tiene buenos puntos por que podemos delegar la pizza y administrar a través de niveles de servicios. Pero la contraparte es que se sigue concentrando el procesamiento en grandes cúmulos controlados por grandes empresas, lo cual es contrario a la filosofia de Internet.

Voy a repetir (en español) lo que un articulo de SUN sobre JXTA dice al respecto:

"The Internet was founded on a simple vision: to build a highly decentralized and resilient worldwide network infrastructure that would scale and that could resist any denial-of-service attacks" 

"Internet fue creado con una visión simple: constituir una infraestructura de red  de alcance mundial y que es altamente descentralizada y resilente  que puede escalar y resistir cualquier denegación del servicio"

JXTA, que es una tecnología que siento aún no se comprendió, y la última obra de Bill Joy en SUN, tuvo la visión de tomar P2P como el siguiente paso. Yo identifico que en la epoca del IoT, JXTA tiene mucho por decir.

Analizando la arquitectura de JXTA, nos lleva a un nivel adicional de procesamiento. Se construyen redes virtuales de peers encima de la infraestructura estática de la actual Internet. 


Pienso entonces, algún dia también las nubes se van a volver "commodity" y tendremos la libertad de usar nubes públicas abiertas (open cloud computing?) para constituir nuestros servicios personalizados o de una empresa. La nube se va convertir en una red de Peers y que de manera dinámica se van a enlazar. Espero en unos años leer esta entrada y ver que tanto atine a predecir sobre este tema.

Por mientras, si es importante considera el computo en la nube, identificar su beneficio a nivel de negocio, el cual siempre es hacia la agilidad de tener soluciones tecnológicas para lograr innovación y realización de la estrategia. Quien no tome esta oportunidad, va a quedar muy rezagado para el siguiente paso. No teman en cambiar los viejos paradigmas de procesamiento. No mas servidores de aplicaciones, no más grandes clusters, los servicios de la nube ya tienen la capacidad para dar el modelo equivalente.

Quien tenga el valor de hacer este cambio, ya está adelantando buenos pasos. Diria, está innovando ...

Esperando comentarios ...



martes, 15 de septiembre de 2015

La poesia del arcoíris


I am no poet, but if you think for yourselves, as I proceed, the facts will form a poem in your minds.~ Michael Faraday
A la ciencia se le acusa de ser fría y poco romántica, de sustituir la belleza que el arte le otorga a los objetos por una monótona y simple descripción de su funcionamiento. El poeta ingles John Keats, menciona que Newton había destruido la poesía del arcoíris al reducirlo a un prisma. Sin embargo, existe más belleza al comprender nuestro alrededor, el comprender el arcoíris, poder replicarlo y utilizar estos descubrimientos para seguir revelando más secretos de la naturaleza.

Mi objetivo en esta entrada es tomar el concepto de arcoíris que Keats considera ya carente de poesía, explicar su importancia en descubrimientos posteriores y regresarle su belleza a través de la ciencia.

Este tema se ha abordado previamente, Richar Dawkins en su libro Unweaving the Rainbow, justamente utiliza la frase de Keats para describir como la ciencia no destruye si no que encuentra la poesía en los patrones de la naturaleza. Así mismo la serie Cosmos describe con mayor profundidad el concepto de luz y la interconexión de sus descubrimientos. De dicha serie me basaré para tomar los ejemplos.

Empecemos pues con el fenómeno del arcoíris. Newton descubrió que la luz era la mezcla de todos los colores del arcoírirs. Cuando choca con gotas de agua o en el caso de su experimento con un prisma, cambia de dirección el rayo, debido a que cada color tiene una longitud de onda distinta, este cambio de dirección o refracción es distinto para cada color, lo cuál ocasiona que se separen y nuestro ojo pueda notar los colores, a este fenómeno lo llamo espectro de luz.

En este momento tal vez piensen que en efecto le acabo de quitar la belleza al arcoíris con esta explicación, pero lo que nos acaba de decir el arcoíris, es como funcionan los colores en la naturaleza. Cuando la luz choca con un objeto, este absorbe cierta longitud de ondas y las demás las rebota, nuestros ojos captan esa luz y gracias a ella podemos aprecias desde un hermoso atardecer, hasta los ojos de la persona que amamos. En lo personal me gusta pensar que el color de los objetos es la unión de todos los colores menos el que muestra, porque el que muestra es la luz que rebota.   

Tiempo después ya con el conocimiento que la luz era la mezcla de todos los colores y con el conocimiento empírico del calor que produce la luz,  William Herschel se pregunto si existía un color que calentaba más que los demás. Esta pregunta que muchos considerarían absurda o de respuesta obvia, generó una nueva forma de entender a la luz. Su experimento consistía en dejar pasar un rayo de luz por un prisma para así proyectar un espectro de luz, en cada color del espectro puso un termómetro y abajo del color rojo puso otro termómetro como control. Al hacer las mediciones se dio cuenta que el termómetro de control era el que había registrado una mayor temperatura, acababa de descubrir un nuevo tipo de luz, invisible para nuestros ojos, pero la sentimos como calor, la luz infrarroja.

Con este descubrimiento comprendimos que la luz va más allá de nuestro rango de visión, abriendo la posibilidad a contemporáneos como Faraday, quien logró unir la electricidad, el magnetismo y la luz. Gracias a estos descubrimientos existen las telecomunicaciones. Podemos comunicarnos con nuestros seres queridos, enterarnos de sucesos a lo largo del mundo de forma inmediata, explorar el cosmos y comunicar nuestras ideas y sentimientos, como nunca lo había hecho otra especie antes.


Posterior a Herschel, Joseph Fraunhofer experimentaba con prismas y lentes, durante sus experimentos colocó un prisma en un extremo de un telescopio y observo a través del otro, lo cuál generó un fenómeno muy extraño, el espectro de luz producido por el prisma presentaba lineas negras verticales, que cortaban a lo largo el espectro. No entendía a que se debían estas lineas y el misterio tardo cien años en ser resuelto.

Los electrones en los átomos van cambiando de orbital dependiendo de su nivel energético, para subir de orbital necesitan luz y para bajar producen luz. Si se tiene una fuente de luz de un extremo y una forma de observar el espectro de luz, como lo es el telescopio con el prisma, del otro lado y colocamos por ejemplo un átomo de hidrógeno en medio podremos observar cuando el electrón usa la luz para el cambio de orbital, el resultado es una linea negra en la longitud de onda en la cual interactúa el electrón. Es una firma atómica única de cada elemento. Por lo tanto si conoces el espectro de luz que chocó con un objeto puedes saber que elementos existen ahí.

Este descubrimiento fue el padre de la astrofísica y hasta la fecha lo utilizamos para revelar el universo y su composición.

El arcoíris lejos de perder su belleza al ser entendido, gano más. La próxima vez que observe un arcoíris recuerde como se forman los colores de las flores, del atardecer, de la naturaleza, de la persona que ama, que la luz no es solo lo que vemos y  gracias a eso podemos utilizarla para romper las barreras de tiempo y espacio, comunicarnos con seres queridos, explorar el universo y que gracias a el podemos entender el cosmos, la historia que tiene que contarnos, nuestro lugar en el y hasta en algún momento encontrar nuestro nuevo hogar, todo gracias a gente que miro más allá de lo obvio y se decidió a resolver los secretos del arcoíris.

La ciencia es un poema por si solo, el más hermoso poema, que nos muestra lo que fue, lo que es y lo que será, nos hace conectarnos con todo a nuestro alrededor, desde la partícula más pequeña, hasta la estrella más masiva. Es un lenguaje universal en el que nosotros dejamos de ser el centro del universo y nos volvemos un simple espectador, "los hechos van formando un poema en tu mente".

Referencias:
 Crédito imagen.
 Título: Rainbows, over Malmesjaur in Moskosel, Lappland Sweden july 14 2009, 7:15 PM
Autor: Jerry MagnuM Porsbjer
Sitio: www.magnumphoto.se
Licencia: GNU Free Documentation License