JavaOne 2015 - A sus 20 años -

En mi asistencia a Oracle Open World decidí incluir también al JavaOne.
Primero, era interesante volver a las acostumbradas platicas y segundo por que a los 20 años de cumpleaños de Java era atractivo ver como estaba la comunidad.

Arrancando el lunes y a diferencia del evento hermano, solo asignaron 2 hoteles. Un evento que llegó en el año 2000 a llenar los dos Moscone y con una comunidad internacional, ahora estaba reducido a una exposición con una sala menor a cualquiera del Oracle Open World y no mas de 20 salones de pláticas.

Mi primera pregunta, donde está la comunidad Java!!

Note que parte de esa comunidad estaba ya en el otro evento, y quizá ya no tanto como desarrolladores sino contro rol. De igual manera, aunque gran parte de la plataforma que se tenía en Oracle Open World al final se ejecuta sobre JVM pero ya es otro el giro.

Donde quedo la emoción de cuando se anunciaban mas APIs. Recuerdo en 1999 cuando llenamos la sala y oimos sobre EJB 1.1 o JMS 1.0 o JINI y probabamos de manera inmediata la tecnología.

Viejos tiempos dije y de ahi me di cuenta de otro hecho, la comunidad ya no es joven, ya no eramos esos programadores entre 20 y 30 años. Poca sangre joven note.  Y donde están esos programadores Java, se supone que hay bastante comunidad.

La respuesta está en una comunidad que por rollos legales y comerciales, para ORACLE es más innombrable que Voldermot

Si, Android, y muchos lectores me van a matar, pero si Java se sigue aprendiendo es por que la anti tesis de ORACLE le ha renovado vida.  
En el evento de JavaOne 2015 cero mención a Android. ORACLE aún sigue hablando de Java Micro Edition pero pues creo que nadie me discute que el tiempo ya dio su respuesta sobre lo que resulto con la idea de dispositivos moviles habilitados con Java. No fue ORACLE el ganador...

Que hay de Java 8? Bueno, ya saben, el intento de incorporar algunos elementos de progamación funcional al lenguaje, las tan citadas Lambda. Este ejemplo era muy tipico de ver ...

Si fuera el único mundo de programación Java quizá muchos dirian, que bien, pero esto ya tienen bastante tiempo con lenguajes como Ruby y como siempre he criticado en Java, siempre se ha temido dar ciudadania a expresiones que requiere el lenguaje. Expresiones regulares resulta demasiado complejo frente a lenguajes que si le dieron esa capacidad de ser ciudadanos de primer mundo en la sintáxis tales como Perl, Python, Ruby. Ahora pasa lo mismo con las lambdas. 

Después de 20 años, por fin se admite que el manejo de las rutas de clases o CLASSPATH necesita ser organizado. Era una crítica que hacian los detractores de la platforma. JDK 1.8 nos ofrece una herramienta llamada jdeps para amaestrar el mundo de los cientos de JAR y no vivir la pesadilla de ClassNotFoundException o peores. 

JavaFX, prefiero mejor no hacer comentarios en un mundo donde HTML5 ya resolvió muchos problemas de Interfaz de usuario.

JavaScript es soportado con el motor de ORACLE llamado Nashorn , no es impresionante si ya se conocia Mozilla Rhino. Pero espero que esto permita ver hacia un posible enfoque políglota del ambiente.

¿Que hay de JEE 7? Bueno,  está llegando un poco tarde a una película que ya lleva un tiempo avanzando. Mientras otras plataformas de programación están en busca de ambientes ligeros (ejemplo Sinatra con Ruby o Flask con Python) nuestro viejo conocido framework aun se niega a seguir dieta.  

Si, ya se tiene inyección de la dependencia, JPA ya converge con Hibernate. Aún siguen las discusiones para que usar Spring si ya JEE 7 cubre todo.  Ya se habla de generar microservicios (aunque aun falta mucho por entender de este estilo ). Pero aquí es donde empezaron mis dudas sobre Java hace años, la sobre especificación y la verdad atado a modelos de hace ya una decada que han demostrado no ser tan efectivos. No quiero un Node.js o Ruby ligero, pero creo que la comunidad de desarrollo ya sabe lo que implica programar aplicaciones en el backend y Java EE 7 aún necesita hacer algo para simplificar el tema.

JSF aún sigue seriamente considerado en la ruta de tecnología de JEE y veo de la comunidad ortodoxa aún el alejamiento hacia Javascript.  No quiero ser pesimista pero JSF temo que sufrirá el destino que Java FX a menos que se replantee. O qué sensación tienen al ver este diagrama de JSF 2.0 para entenderlo a fondo.

Nube, nube por doquier pero ... Les comparto esta presentación  y ésta del evento y ustedes juzgen sobre el tema. 

Su servidor no encontró respuestas sobre cual es la manera de diseñar aplicaciones Java para la nube y tenemos que agregar un poco la manera como ORACLE está enfocado el tema de nube y muchas veces no queda clara su estrategia en términos de PaaS  

Hubo temas donde se toco Scala como lenguaje funcional.

Una plática muy interesante desde la perspectiva de ingeniería donde se hizo una consola de juegos de los años 90 usando Raspberry Pi, impresion 3D y mucha electrónica y superando muchos obstaculos.  Estuvo Stephen Chin, quien es ORACLE Java Community Manager.

Internet of Things estuvo presente, pero aún me pregunto por que no han desenterrado el último regalo de ingeniería que nos dejo Biil Joy, JXTA.

El cierre del Vava one fue entretenido. Salvo que al inicio y mas con la cultura de EUA, nos cerrraron las puertas a los que llegamos un par de minutos tarde por falta de espacio.  Ya que pudimos pasar y con una cervez en mano por su error, pude ver un show preparado por la comunidad Java, la guio Stephen Chin, recorriendo en el tiempo estos 20 años con un Tardis tipo Dr. Who y con la aparición de James Gosgling y recuperando la tradición de aventar las playeras. Algunas bromas donde veo como la comunidad aun cree en ciertos principios como verdad única (JSF, JEE, un solo lenguaje, sintáxis cada vez complicada) 

Les comparto el video del Keynote del cierre. Aun me pregunto por que Brasil se nos adelanto como comunidad Java ... Creo que no nos enfocamos a unir la comunidad mexicana, que vaya que si sabemos del lenguaje pero cada uno en nuestro mundo. Se habló de Java para 2035 (y me quede pensando si yo estaría ahí a mis 63 años o si realmenta existiría un Java One 2035)  y ya saben, los niños, el futuro. Pense, quiero que las nuevas generaciones aprendan Java? 

En resumen, JavaOne 2015 fue una experiencia muy interesante, y más que fui en otra óptica, ya no quiero programar todo en Java y se que ese no es el camino. Extrañe a la comunidad joven (ahora en el mundo del desarrollo móvil o aplicaciones Web con Jscript) y también tuve nostalgia por aquellos tiempos donde el mercado Java daba para cientos de empresas que te mostraban tecnología.

Así que no es lo mismo los tres mosqueteros que 20 años después.  

Deseo que el lenguaje continue pero necesita evolucionar ya, necesita morir y renacer, como el ave fénix. A esto escribire otro articulo que se me ocurrió en el mismo evento.

Oracle Open World 2015

Hace un mes fue el evento de ORACLE Open World 2015 en la ciudad de San Francisco.

Para su servidor me dio la oportunidad de volver a visitar la bella ciudad de San Francisco despues de 11 años.

El domingo 25 empezó la acción en la tarde. ORACLE lleno todos los Moscone ( digase tres) mas cuatro hoteles. La cantidad de gente que se estaba inscribiendo y tomando su tipica mochila eran varios miles y de varias naciones.

ORACLE cerro la calle - Howard Street - para poner una explanda para que se pudieran ver los keynotes y tomar descanso, alimentos. 

Asi se vió la calle por 5 días

La estrategia de ORACLE fue tratar de mostrar a los asistentes que son una plataforma solida en temas de nube. Aquí empezo mi primer cuestionamiento al señor ORAC Larry Ellison donde en 2008 tuvo una ausencia de visión diciendo que era un término de moda y ahora en 2015 se esfuerza por vender la idea de que su empresa es la única que tiene una visión adecuada en términos de nube . La verdad al oir su platica (que por cierto la volvió a repetir igualita el miercoles de esa semana) sentí la sensación de oir conceptos ya usados por otros grandes en términos de computo en la nube, pero Mr. LE los vendia como si aparecieran la primera vez. La verdad su platica fue mas de mercadotecnia y no ofrecio ninguna óptica novedosa sobre el tema de Cloud Computing. 

De hecho basta con ver el sitio de la nube de ORACLE y ver que su catalogo de servicios apunta mas a SaaS y PaaS. IaaS es puesto en tres servicios. Pero lo que noto es que no hay una estrategia de integración de los servicios como lo hace AWS o Azure. Son servicios ofrecidos para que tome instancias y ya.  Me arriesgo con todos estos comentarios a perder a todos los fans de la empresa roja, pero si se ve que aún les falta por trabajar en una verdadera visión de nube.

En cuanto las platicas, hubo de todo, y era imposible abarcar todas, ya que iban desde las mas especializadas para sectores verticales (manufactura, retail, CRM, ERP, energía, finanzas), middleware, base de datos, hardware y nube.  Algunas si eran de contenido técnico adecuado y otras era para mostrar mas la solución. 

Me dio algo de gusto ver que muchos ingenieros de SUN y BEA siguen trabajando y de hecho son los más simpáticos , sencillos y claros de entender. 

En el estánd destinado a la tecnología de cómputo convergente estaban los equipos ExaData, ExaLogic, Exalytics entre otras. Llamó mucha la atención el SPARC M7 (si SPARC sigue vivo) con capacidades de hardware para base de datos  (mi profesor Jaime Porras de sistemas operativos y base de datos tuvo razón, el hardware va acabar sustituyendo a muchas funciones del sistema operativo y los DBMS) y la verdad es impresionante el grado de ingeniería aplicado.  Todos los ingenieros amablemente explicaban su tecnología y con paciencia resolvian dudas, como en los viejos tiempos de SUN Microsystems.

En el salón de exposición más grande, ORACLE puso una serie de demostraciones de la tecnología. En el mundo del RDBMS sigue la oferta de su tecnología de ORACLE 12c pero también está ya tomando una importancia preoponderante el mundo NoSQL. De todo tipo de modelos de base de datos - grafos, jerarárquica, espacial, columnar, en memoria, Hadoop, Spark, redes semánticas, llave valor, documental - y con verdaderos modelos de base de datos distribuidas (adios al ACID bienvenido el teorema CAP?).  

Adios al XML como estándar de intercambio de datos, JSON está predominando como un modelo simple y ligero.

Mi predicción es que al gigante rojo le falta muy poco para ofrecer de una manera integra el manejo de base de datos y su siguiente versión de maneajador de base de datos va a ofrecer soporte al mundo relacional y NoSQL

Big Data? BuzzWord? Hablar de procesamiento de TeraBytes en cuestión de segundos ya no es digno de caravanas mostrando respeto. Ya es una realidad que se necesiten capacidades computo y almacenamiento en el orden de PetaBytes y modelos nuevos de procesamiento aparecen, ya no solo el MapReduce de Hadoop, sino Spark quien ayuda a realizar este tipo de proezas.  

Ojo, para procesamiento estadístico de datos, el lenguaje R está siendo adoptado también por ORACLE y lo ofrece ya como parte de su pila tecnológica (agradezco que por fin se acabe la era de oscuridad generada por SPSS y SAS )

Datawarehouse ?? Si sigue sonando, yo creo cada vez se puede cuestionar el modelo propuesto por Inmon o Kimball donde estaba la seperación entre el mundo transaccional y el analítico. Pero ahora con esquemas flexibles, procesamiento más barato, diversos algortimos de manejo de datos, quizá hablar de un ETL resulte ya algo rancio.

WebLogic, al igual que Java, pues sigue el destino cruel de solo estar soportando lo de siempre pero no les puedo decir si hay algo impresionante. Creo que la nube va acabar matando a los servidores de aplicaciones y ahora los conviere en arquitecturas monolíticas (o no, lo que antes presumiamos como modular ahora es monolítico!!)

Por ahí me encontre todavía en un estánd una demostración de Tuxedo 12c, la navaja suiza del mundo cliente servidor y que insisto entendamos y respetemos por todo lo que dio de tecnologìa y que se sigue viendo en acción.

Solaris, aun existe pero no empiecen con ideas macabras de llevarlo al mundo x86

El mundo SaaS es impresionante la gama de soluciones que existen.  Larry casi casi dice que el no ve a SAP en la nube. 

Me percato de algo, en un par de años la necesidad de un DBA o especialista de middleware o Sysadmin de sistema operativo se va a ver reducida. Asi que a muchos colegas les aconsejo que vayan pensando mas en términos de soluciones de negocio, de entender más las necesidades de la industria vertical. La nube va a provocar que la infraestructura de software o middleware se vuelva un commodity. 

El trabajo estará en apoyara a los negocios a explotar los componentes tipo SaaS o para cuestiones especificas usar PaaS.

¿ Que hay de SOA o de BPM? Palabras tan usadas en eventos anteriores ahora ya no son recordadas por las áreas de ventas. SOA es una realidad ya, no tanto como fue concebido hace 10 años, pero ahora la plataforma PaaS y SaaS están llevando dicha visión a la realidad, pero un SOA implantado por los fabricantes de software mas que por las compañías mismas. Si alguien sigue estancado con la idea sobre SOA, reacccionen y agilicen el tema, ahi está ya en acción (registro UDDI ?? Para que?)

La lección de ORACLE Open World 2015 es que si es importante tomar en serio el tema de nube, si algunos quieren creer que son lideres pues adelante o quizá los mas escépticos como yo, analicen como están las piezas del juego. Mi opinion es que seamos multi lenguajes, multi nubes y los tecnológos empecemos más a entender el mundo de las soluciones verticales, la plataforma SaaS está a la distancia de un click al fin y acabo

Y Java ... esa es otra historia y si, tengo mas por escribir al respecto

p.d. El evento de cierre de ORACLE Open World fue agradable, no soy fan de Elton John pero si lo hicieron en grande

Servicios de desarrollo en la nube, ¿magia blanca o hechicería?

Como parte de la infraestructura de desarrollo del proyecto de HBit, nos hemos apoyado de algunos servicios en la nube para facilitar la labor de desarrollo sin tener que preocuparnos por la instalación, configuración, administración y mantenimiento de dichos servicios, lo cual representa una gran ventaja de por si.

Solo por mencionarlos, actualmente se ocupan los siguientes servicios que ofrecen ciertos beneficios.

• BitBucket. Repositorio de código privado y control de cambios y versiones, donde almacenamos y compartimos el código fuente de las aplicaciones.
• Codeship. Servicio de integración y despliegue continuo el cual se ocupa para la integración, ejecución de pruebas y despliegue del API REST consumido por las aplicaciones móviles. Básicamente utilizado para tomar el código del repositorio, ejecutar las pruebas unitarias y publicar los cambios en Heroku.
• Heroku. Ofrece un ambiente completo Ruby on Rails, para el despliegue del API REST con el plus de poder accederlo mediante una URL pública y HTTPs (requerido para el consumo de recursos en iOS 9).

Este esquema nos permite agilizar en gran medida el proceso de publicación de cambios en el API de modo que no tenga gran impacto en las actividades de desarrollo móvil, sin mencionar que con nuestra demanda actual podemos utilizar estos servicios sin costo.

Además de los beneficios mencionados que nos han llevado al uso de estos servicios, esta semana tuve una reflexión surgida a raíz de un pequeño incidente con el servicio de bitbucket, pues durante dos días algunas características ofrecidas por el servicio, que para nuestro caso rompía con el proceso automático de la publicación de cambios en Heroku.

En un principio se pensaba que era un problema de codeship, aunque revisando la página de estado del servicio (http://codeshipstatus.com), mencionaba sin mucho detalle que se trataba de un problema de los hooks de Bitbucket que disparan el proceso en codeship. 

A pesar de la deshabilitación de nuestro proceso automático de despliegue y la intermitencia del sitio web de bitbucket, el servicio núcleo de Bitbucket (control de versiones mediante git y mercurial) seguía siendo totalmente funcional por lo cual podíamos seguir compartiendo cambios de código. Además, utilizando las herramientas de línea de comandos de Heroku era posible seguir desplegando cambios aunque se tuviera que hacer de forma manual.

Leyendo la respectiva página de estado del servicio (http://status.bitbucket.org)  se podía conocer mayor detalle de lo que estaba ocurriendo con bitbucket. Dentro de los mensajes que me llamaron la atención podría mencionar: 

Update - We have a technician on-site to begin the process of physically routing around the failed network hardware causing the availability problems experienced over the past 48 hours. We will have some more intermittent instability as this work is being done. 

Oct 22, 18:30 UTC

 Al final de todo esto me quedaron las siguientes reflexiones.

¿Que tan valioso puede ser tener un equipo especializado y dedicado para cada tema?. De haber tenido un problema similar en un esquema  local que nuestro mismo equipo les de soporte, nosotros mismos hubiéramos tenido que resolver el problema. Esto seguramente nos hubiera distraído y retrasado en nuestra labor de desarrollo para rehabilitar el servicio. 

¿Que tan acertado es aceptar que se tiene un problema y hacerlo público? Quizá por cuestiones culturales, cuando hay un problema pareciera que se intenta ocultar a toda costa y negar su existencia para dar una apariencia pública de perfección. Esto creo que al final sale contraproducente para uno como consumidor pues el desconocer la problemática lo pone a uno en una situación de "dar palos de ciego". En cambio algo tan sencillo como el poder conocer rápidamente cual es el eslabón débil de la cadena, a través de una página pública, nos permitió reaccionar de manera más ágil y eficiente.

Pensando un poco a la ITIL (el cual ha sido un tema recurrente últimamente en Innbit), es interesante observar que al montar un proceso en una serie de servicios que ofrecen cierto nivel de servicio, nos permite continuar enfocados en nuestro trabajo a pesar de eventualidades.

Si nuestra aspiración es en algún momento poder ofrecer servicios de este estilo, creo que habrá que pensar en ir más allá de solo decir que vamos ha hacer un software o que lo vamos presumir con clientes. Quizá empezar a hacer una reflexión interna y cuestionarnos preguntas del tipo ¿como será la transición?, ¿como y quién lo va a operar?, ¿cómo podemos mejorar?... dicho probablemente en un cliche, "a la ITIL" o "mas o menos a la ITIL". Esto para que algún día alguien que ocupe algún servicio que lleguemos a ofrecer y que le ocurra algo similar a esta experiencia pueda decir que ofrecemos magia y otras cosas del diablo.

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..

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 ...

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

Innovación y estrategia -reflexión -

Una manera para explicar a las personas que toman decisiones sobre el concepto de innovación y que quizá tengan duda si este "buzzword" tiene sentido en una organización es explicarlo así:

• El mercado donde está la organización típicamente tiene múltiples competidores. En una manera tradicional, es enfrentarse cara a cara con los competidores y ver que gane el más fuerte. Creo que se ven las desventajas de este enfoque, por que no siempre el que gana es el mejor sino el que quiza tiene mas poder o influencia sobre su ambiente. Además que te lleva a estar siempre viviendo de la misma idea a perpetuidad y la historia ha mostrado que las organizaciones tarde o temprano se ven afectadas por cambios radicales en tecnología, en la sociedad (solo vean lo que ha pasado con las compañías que vivian de rentar películas , hoy pocas existen)
• La estrategia es romper las reglas (Rule Breaking Strategy) donde la compañía mejor se sale del sector sin presentar pelea a su reñida competencia y empieza a usar la innovación para ir contra la marea y con el objetivo de ...
• Crear un nuevo sector en el mercado. Ahora es el primero que tomo oportunidades que ni la competencia vió en el afan de seguir peleando en el mercado. Pero la compañía que se aventuró a innovar es la primera en un nuevo sector que ella misma creo y sobre el cual tiene control.  Esto es conocido como Blue Ocean Strategy (la liga de Wikipedia introduce al concepto o sino a leer el libro)

La siguiente figura muestra lo que acabo de narrar:

Lo que aconsejo a las organizaciones que quieren usar la innovación para obtener un valor de negocio, es que permitan al grupo encargado de cultivar dicha innovación que sea disruptivo. Es importante que la organización identifique que hay cierto momento en el cual se debe invertir, y posibilidades de fallo pero también de éxito. La paciencia es buena consejera para las organizaciones que apuesten a la innovación como un motor para transformarse. 

Lo que se debe cuidar es que en la organización quede bien definido el concepto de innovación, que no se vuelva un proceso burocrático, que permita la colaboración de personas de la organización sin discriminación y dejar que se usen métodos no tradicionales ( Lego Serious Play, Lienzos, post its).

La innovación tiene éxito cuando la organización aprende a utilizar lo que actualmente tiene en combinación con ideas, conceptos, técnicas, métodos y tecnología que lleven a nuevos caminos.

La innovación no se platica ni planea, se tiene que vivir, se tiene que aprender, se debe tener el valor de entender los fallos y capitalizar los éxitos. 

Primer taller LSP

Hoy 17 de agosto 2015, en un proyecto de Innbit se aplicó por primera vez la metodología de Lego Serious Play.

No deja de llamarme al atención la nobleza del enfoque y como los participantes se ponen seriamente a trabajar cuando arman sus modelos y cuando los explican siempre hay una señal de satisfacción y sonrisa hacia los demás

Esta es la primera entrada, de espero varias experiencias que tengamos en este tema

Ideas para productos ...

Usando el blog para tener la bitácora de como estamos plasmando ideas

De lo que están trabajando Ricardo, Alex y Mike, el actualmente llamado UberCare, que necesito sentarme un rato para ver con ustedes la arquitectura, se me ocurre también empezar a meter del lado backend la parte médica y explorar este software Health GNU y la versión demo que está para Docker y montarla en AWS y también desembuchar mi curso de HL7. Esta liga está interesante IoT HealthCare y me hace pensar en open hardware para IoT Healthcare... Pero necesitamos ir a habler con gente del ramo ... Más que hacernos ricos de manera inmediata por la App, es atraer la atención de consumidores masivos hacia innbit y que tengamos experiencia en el nicho de innovación. Sigo diciendo e insistiendo que el negocio es posiblemente por la información a recopilar.

Y de ahí, la metodología de emprendimiento es nuestro crisol para probar ...

De CoachBit, usar Lego Serious Play como punto de partida para nuestro enfoque de capacitación en TOGAF, PMP, ITIL, SCRUM, CMMI, HL7... Hacer videos y comics como parte de esta nueva idea que puede volar muy lejos ... De nuevo, la pasión por algo se convierte en innovación, lo que no logré hacer en la ULSA cuando fui profesor es realizable y como parte de mi trabajo!!

Y de CloudBit, trabajar fuertemente en ser la figura de integradores de la nube. La manera como están creciendo los servicios de la nube es impresionante y estamos llegando ya a la era donde se está exponiendo por fin componentes de software como servicio. Y tener una plataforma adecuada de administración del ecosistema de nubes

Y veo que el tema de inteligencia de negocio, a veces tan oscuro en ciertas áreas de TI, se puede llevar a una implantación de alto impacto usando tecnologías de nube como AWS o Azure. Empapandome de bibliografia desde Inmon y Kimball y de ciencia de datos; y de un eofuqe interesante de Cutter para agilizar el proceso de implantación y la idea de usar TOGAF y Lego Serious Play de nuevo aparece ...

Y la semana pasada que abuse virtualmente del buen chillicoder, dandole mucha información sobre el tema de software factories, para nuestro primer enfoque de ProduceMe. Como es costumbre nos damos cuenta que ya tenemos nuestra primera definición, usando DDD, BDD y TDD y apoyarnos de Ruby on Rails, justo en el momento en que chillicoder está convirtiendose al bando de Elixir ...

Veo que para lo que resta del 2015 en Innbit tenemos muchos puntos de trabajo.

Al final, para el inicio 2016 nuestra cartera sera fuerte, desde temas de enfoques de innovación, arquitectura empresarial, LSP, cloud computing, ciencia de datos y con logros interesantes.

Lo que siempre es bueno, es persistir en ideas, y agregar variantes.

¿Free Hardware?

The great revolution in the history of man, past, present and future, is the revolution of those determined to be free. ~ John F. Kennedy

En esta época se ha popularizado el término Open Source Hardware, debido al éxito de dispositivos como Arduino, tecnologías como la impresión 3D y movimientos como el Maker, sin embargo no se ha utilizado el término Free Hardware como en el caso del Software, donde se tiene tanto el término Open Source Software como el término Free Software.

Para poder hablar de  términos como Open Source Hardware(OSH) o Free Hardware, primero tenemos que entender las diferencias y similitudes entre Open Source Software(OSS) y Free Software.

El Free Software surgió como una respuesta al Proprietary Software, el cuál es software al que el usuario no tiene acceso más que a su interfaz, no puede modificarlo, distribuirlo y solo puede ser utilizado como lo concibió el programador. Lo que genera un nulo entendimiento del usuario al funcionamiento del programa, propiciando la integración de software malicioso, como lo son puertas traseras, espionaje y robo de información.

La palabra Free en Free Software se debe entender como libre y no gratis, “Think of ‘free speech,’ not ‘free beer.’”. El software considerado Free Software debe otorgar al usuario la libertad de correr el programa como lo desee, estudiar y cambiar el programa, tener acceso al código fuente y distribuir copias tanto del software original como el modificado por el usuario.

El OSS surgió como una forma de llevar el Free Software a las empresas, su término y condiciones son mucho más gentiles para un hombre de negocios. En este caso, el usuario también puede acceder al código fuente, modificarlo y distribuirlo, pero puede ser prohibida la distribución del código modificado.

En grandes rasgos se pueden distinguir, debido a que el Free Software toma como base la parte ética, las libertades que le otorga al usuario, sin embargo, el OSS se basa en la mejora continua del código, por medio de las modificaciones de la comunidad, en el OSS es muy común tener ambientes de trabajo, los cuales están diseñados para limitar las acciones que el usuario puede realizar con el código y para obtener las modificaciones hechas por el mismo.

El Free Software le da el poder al usuario, la comunidad técnica puede analizar y modificar el programa para proteger sus intereses, lo cuál beneficia hasta los usuarios no técnicos. El OSS le da el poder a la empresa, la cuál puede hacer caso omiso a las modificaciones o restringir el acceso al código.


Basándonos en esto podemos afirmar que todo programa Free Software es OSS, sin embargo no todos los programas OSS son Free Software.

Debido a la naturaleza del hardware, no se le pueden implementar las libertades del Free Software, sin embargo se pueden integrar a su diseño, como en el esquemático del circuito o los planos.

El diseño puede ser distribuido, modificado, etc, sin embargo el proceso de manufactura no depende del usuario, mínimo no al no técnico y aunque puedas fabricarlo, generalmente el costo será mucho más elevado, siendo muchas veces poco práctico.

También pueden existir empresas que tomen como base el diseño de un producto y crear uno propio con modificaciones que ha hecho la comunidad, pero siempre dependerá de estos distribuidores la funcionalidad que tenga el dispositivo. Es decir, por definición, lo vuelve más parecido al OSS o en este caso OSH.

Otro problema que existe en el hardware es la dependencia a circuitos integrados, como el caso de microprocesadores, los cuales ya tienen un firmware predefinido por la empresa, el cuál no puede ser modificado, este firmware puede contener software malicioso o restringir tus libertades.

Aunque existan estos problemas de definición, los diseñadores de hardware pueden basarse en las libertades del Free Software para diseñar el hardware y los usuarios técnicos pueden estudiar los diseños para prevenir a la comunidad de hardware malicioso, por más que no puedan controlarse todas las variables, aun así se puede crear OSH con un espíritu de Free Hardware.

Por más que en estos momentos no exista una licencia Free Hardware como tal, no quiere decir que en el futuro no pueda existir, la impresión 3D está abordando ramas como la electrónica, desde impresión de circuitos, hasta el ensamble de circuitos integrados y la biología, con estudios del ribosoma, con el cuál seriamos capaces de crear objetos, duplicarlos. En el futuro podríamos fácilmente imprimir dispositivos electrónicos, con los circuitos que queramos y con funciones personalizadas.

Debido a esto, las implicaciones del Free Hardware son reales y debemos diseñar con este pensamiento desde ahora.


Para terminar, quiero expresarles la gran importancia de entender la tecnología. La tecnología forma parte de nuestras vidas, desde la alarma que nos despierta, hasta la red social que vemos antes de dormir. Entre más ha crecido la tecnología menos entendemos como funciona y solo entendemos como utilizarla. Publicamos en redes sociales que roban nuestra información, tenemos puertas traseras en los sistemas operativos de nuestros celulares y computadoras, tenemos software espía en dispositivos que cuentan con cámaras, GPS y sistemas de mensajería y no nos molesta vivir  así, estamos más preocupados por el estatus que nos entrega, por tener el ultimo dispositivo y estamos entregando nuestra libertad poco a poco.

Así como la tecnología avanza en la impresión 3D, así avanzará en otras ramas, como lo es el Internet Of Things. Solo imaginen las implicaciones de tener sensores en cada rincón de tu casa y de la ciudad, los cuales no sabemos como funcionan, ni tenemos acceso a su código o diseño. En estos momentos podemos crear personalidades falsas en internet, podemos decidir que publicar o no, pero ¿qué sucede cuando vivir genera información? en mi opinión preferiría saber como funcionan esos dispositivos antes de integrarlos en mi vida diaria.

El Free Software/Hardware nos da poder, nos da libertad, por más que no entendemos como funciona la tecnología,  solo debemos escuchar lo que la comunidad técnica opina al respecto, ellos se cuidan entre si y de forma paralela lograremos entender más la tecnología y saber que es lo que realmente queremos y necesitamos en nuestras vidas.

Imaginen un mundo donde este nivel de transparencia existiera en todos los ámbitos, donde la comunidad de farmacólogos pudiera compartirnos libremente que medicamentos cumplen con sus especificaciones o donde la comunidad de abogados tuvieran acceso y pudieran compartirnos las bases de las decisiones políticas y sus implicaciones. Suena como una utopía, algo inalcanzable, pero al mismo tiempo ese poder tenemos en la tecnología y es nuestra decisión hacerla realidad.

Referencias:
 Crédito imagen "open source hardware logo inverse" http://papermint-designs.com/community/node/132

Lego Serious Play - un primer acercamiento

Del 9 al 12 de julio 2015 tuve la oportunidad de asistir al taller para habilitar en el uso del métdo de Lego Serious Play

Fueron días que demandaron mucha capacidad intelectual y física, y concluyendo el domingo, auque habia mucho cansancio, también existió mucha interacción entre todos los participantes y más que acabamos haciendo nuestro modelo Lego de como nos conformamos como equipo.

Esta es la foto de los últimos momentos de nuestro taller y les puedo decir que habia bastentes emociones positivas en el ambiente.

Es dificil de poder narrrar con lujo de detalle el método, no crean que es por que se los quiero vender, sino que parte del método es la vivencia y el uso que haces como persona del mismo.

Primero, por qué me inscribi en este curso?

Bien, pues antes del cursos ya estaba usando Lego como una técnica para temas de arquitectura empresarial o administración de proyectos y salir del cuadrado mundo de las presentaciones powerpoint. Ya había obtenido resultados interesantes.

El tener la técnica de manera no empírica era el paso natural y asumí el reto de estar un fin de semana completo. 

Lego Serious Play tiene muchos puntos a considerar y voy a destacar rápidamente:

• No hagas juntas o comités contigo mismo, modelo lo que te venga en mente en Lego y empezará a fluir las respuestas
• Planea-Ejecuta-Planea-Ejecuta- ....
• En un modelo tradicional de trabajo el 80% de las reuniones son aprovechadas por el 20% de las personas
• Se utiliza para cuando no existen respuestas predefinidas, a través de comportamiento colectivo se llega a una solución (enfoque abajo hacia arriba)
• Confía en tus manos, construye, reflexiona y comparte

En lo particular, para el tema de Arquitectura empresarial voy a empezar con la "innovación" de usar LSP con TOGAF para definir escenarios de negocio, o el modelo de negocio (mezclado con Business Model Canvas) o la propia arquitectura empresarial, los factores de transformación

Les presumo, para que les de envidia de la buena, es apasionante hacer este tipo de trabajo...

Algunas fuentes de ideas

Como hemos dicho en varios mensajes que generamos en Innbit, la innovación no es algo que se compre o se consiga de manera inmediata.
La innovación tiene fuentes de inspiración para crear ideas.

Reflexiones varias del Taller Aprendiendo a Innovar Innovando

En una entrada anterior de éste espacio se había ya hablado de la experiencia que tuvo el equipo de INNBIT al participar en el taller Aprendiendo a Innovar Innovando con Edgar Barroso dentro de la serie de conferencias y talleres de Cutter Consortium en la Ciudad de México.

El valor de éste tipo de entradas relacionadas a un taller de innovación, no reside en describir a detalle las dinámicas en sí mismas vividas, sino de compartir las conclusiones o reflexiones a las que se llegan a partir de una interacción de éste tipo.

Entrando en materia, el taller de Aprendiendo a Innovar Innovando nos sirvió como un espacio para validar ante otros asistentes algunos aspectos de nuestra labor en Mainbit referente al tema de Innovación que hemos abordado desde Febrero de 2014. Es un hecho que en momentos no estuvimos exentos de sentirnos aludidos en cuanto a malas experiencias se refería, pero también encontramos coincidencias positivas acerca de cómo llevar o sobrellevar nuestras actividades de innovación cómo equipo.

Ésta experiencia obtenida entre vivencias positivas y negativas definitivamente nos adelanta como organización en la ardua empresa de cambiar una mentalidad pasiva a una mentalidad innovadora al interior de un entorno corporativo, esto mediante la conceptualización de la innovación como una actividad viva y para nada como un concepto novedoso, lo novedoso en sí mismo es caer en cuenta que es una actividad necesaria. El compartir nuestras experiencias a otros asistentes cuando así había oportunidad de hacerlo nos demuestra a nosotros mismos la madurez en nuestras actividades y esfuerzos (hasta cierto punto dolorosos) por los que hemos tenido que atravesar inevitablemente. Al día de hoy podemos seguir escuchando y aprendiendo infinidad de cosas de personalidades como Edgar Barroso, pero me parece que también nosotros podemos empezar a compartir experiencias  a otras organizaciones, pero aún más importante y razón de existir de INNBIT, sabemos que cuando una organización se acerque a nosotros para pivotear o implementar actividades de innovación, con seguridad podemos brindar una mejor asistencia basada en dicha madurez.

En adelante comparto reflexiones de los puntos que más me llamaron la atención y que me gustaría compartir con el lector.

Desmitificación de la Innovación. Cuando tuvimos la oportunidad de acercarnos a los equipos de trabajo de Mainbit, me di cuenta de lo trillado que se escucha la palabra Innovación y del escepticismo que despertaba en nuestros oyentes al presentarnos como equipo o representantes de la Dirección de Innovación de Mainbit, y es que ésta palabra la encontramos como slogan por doquier. Me da la impresión, que así como los niños se han dejado de sorprender por los efectos especiales en el cine, lo mismo sucede cuando se les presenta una propuesta “nueva” relacionada a la innovación. Tanta publicidad, sobre todo en lo referente a tecnología, donde minuto a minuto o segundo a segundo, surge y se anuncia algo innovador, provoca que hoy en día un servicio o producto que se vende como tal, su impacto sea menor. Considero que Innovación no se debe de vender como una novedad, sino como una necesidad básica para lograr la TRANSFORMACIÓN en las organizaciones, tal como lo es el beber agua o comer adecuadamente para la supervivencia del ser humano en condiciones saludables.

“La teoría viene de la práctica” o “nadie ha aprendido a tocar piano leyendo un libro”. Es muy útil referirse a cierta bibliografía para poder sustentar o dar respaldo al valor de una actividad, pero en los últimos años en mi vida personal me he dado cuenta de que no hay reglas ni leyes absolutas, hay recomendaciones si, para evitar un posible dolor (físico - emocional), puede haber estadísticas pero siempre hay un margen de error y la posibilidad de nosotros caer en esa diminuta excepción. Es bueno tener la teoría como referencia, pero ésta no debe de marcar nuestro camino a seguir, para que andar por caminos ya antes transitados: la innovación, se construye a base de grandes excepciones a la regla.

Manifiesto / Decálogo. Desde el día que nos comunicaron que íbamos a tener un piso completo para materializar INNBIT como espacio de colaboración y que se iba a adecuar para tal fin (desde que estoy en Mainbit, cuando he tenido que asistir a alguna reunión de equipo, en lugar de decir que voy a trabajar, prefiero decir que voy a ir a colaborar) me ronda en la mente el colocar algún decálogo o listado de principios al ingresar a ese espacio y no por cumplirlos personalmente a cabalidad, sino por que debieran ser actitudes a las cuales aspiramos lograr en cada visita en aras de una mejor convivencia creativa. De momento y a partir del taller considero importantes los siguientes:

• COLABORACIÓN, como eje principal para lograr y consolidar/materializar la innovación en una organización.
• HUMILDAD, no por minimizar el conocimiento poseído, sino porque el ego ha demostrado ser siempre un obstáculo para la colaboración, a veces no sabemos si tratamos con el ego o con talento de una persona.
• MENTE ABIERTA, para encontrar soluciones o respuestas donde nadie más se ha molestado buscar.

Agentes de Innovación. En algún momento del taller se mencionó el término que cobra sentido en un contexto de Makers, Doers y Movers. Como agentes de innovación, podemos adoptar alguno de esos roles los cuales son complementarios. En INNBIT y en lo individual, cada uno de nosotros podría verse identificado con alguno de esos roles, pero como INNBIT en su conjunto podemos consolidar el término también de Habilitadores para otras organizaciones en las cuales nos permitan a nosotros ayudar a implementar la Innovación como una práctica necesaria y no como un producto en caja. Nuestra guía o “acordeón”, entre todas las metodologías que sabemos existen para mantener a las organizaciones en condiciones óptimas, es nuestro Proceso de Innovación, que si bien en principio Edgar Barroso mencionó que no hay proceso infalible para lograr la innovación exitosa, el valor de nuestro Proceso de Innovación, es precisamente que es NUESTRO y que se ha construido a base de nuestra experiencia y cuyo principal objetivo no es que sea Ley, sino guía en mitigar daños o dolores de cabeza durante la implementación de una idea que se piensa sustentable.

Incubadora de Innovación o  Innovation Platform as a Service (InnPaaS). Una vez desmitificada la palabra Innovación, y una vez sabiéndonos agentes de Innovación, Mainbit-INNBIT puede ser una plataforma de consolidación de innovación (InnPaaS, Innovation Platform as a Service, abusando de la actualidad de los temas de Cloud) con las metodologías y procesos provistos por INNBIT, la plataforma Cloud de CloudMagna, la fabricación de Hardware de Grupo ROM, inversión de Mainbit, etcétera. El gran problema es orquestar de manera eficiente todos los componentes para que la agilidad en su implementación sea su propio sello y valor del servicio y no caer en una falta de credibilidad en el mercado.

Las letras pequeñas en el etiquetado de Innovación. Ricardo mencionaba en el taller una frase que me pareció muy fuerte: “una cinta negra es una cinta blanca que no se rindió”. Y es que muchos hablan del beneficio de la práctica de la Innovación y todos, desde corporaciones en sus altos mandos hasta empleados, suelen comprar la idea, pero cuando se habla de las contraindicaciones, éstas siempre vienen en letras pequeñas y a veces ilegibles, por ejemplo:

• Entendimiento total, además de humanos, ¡mexicanos! y como nos cuesta decir “no entendí” por pena o vergüenza.
• Equipos pequeños. Solo limitando la experiencia a Innbit, se ha comprobado que un equipo pequeño y plural, alcanza un mejor entendimiento y por ende los objetivos planteados, en comparación al uso de las técnica fallidas de “juntos como apaches” o “no somos machos pero somos muchos”.
• NO darse por vencido, o peor aún, darse por vencido sin ni siquiera haberlo intentado.
• Cuestionar, más aún cuando se cuestiona de Status Quo.

Automotivación. Uno de los tópicos que se tocó brevemente pero no deja de ser de vital importancia es el de la MOTIVACIÓN. Como experiencia del equipo, en momentos se consideró que el principal motor de motivación era nuestro director, empezando por la dirección que debía de tomar el equipo mismo. Sin embargo empíricamente se aprende que una labor diaria individual es precisamente sentirse automotivado con las metas y objetivos que uno mismo se proponga y que a su vez se encuentren alineados a las metas y objetivos de dirección o de la organización. Aquí me viene a la mente la palabra LÍDER cuando se piensa que una de sus características es automotivarse y motivar al equipo que lidera. Podríamos entonces decir que un equipo de innovación debiera estar integrado por personas que cuenten con un cierto grado de liderazgo ya sea innato o por desarrollar.

Aún quedan algunas reflexiones y aprendizajes a desarrollar que me gustaría compartir más adelante. Espero que éste sea el primero de una serie de entradas de blog que puedan ser aprovechadas para realizar las cosas de una forma distinta y mejor y que su vez sean una ayuda para que los lectores puedan lograr sus objetivos.

Hasta el próximo texto.