sábado, 23 de abril de 2016

O Reilly Software Architecture Conference

La semana del 4 de abril tuve la oportunidad de asistir como asistente/oyente al evento de Software Architecture Conference en la ciudad de Nueva York.

El objetivo de este evento, es mostrar los principales tópicos en el contexto de arquitectura de software.

El primer día asistía a dos talleres prácticos, uno impartido por Thoughtworks, en el cual nos enseñaron como ir manejando una aplicación que iba desde el modelo monolítico de multicapa a un modelo de microservicios, llevando esto a conceptos de Continuous Delivery (CD), contenedores (Docker). Lo interesante de este taller fue que mostró que los microservicios no solo es el hecho de hacer un componente de software, sino que también se requiere la automatización de la infraestructura sobre la cual se ejecuta, así como tener un pipeline para llevar el ensamblado y despliegue en dicha infraestructura. Esto es muy importante, por que el desarrollo de software bajo este enfoque no sólo se limita a tener el bloque funcional, sino a también codificar la automatización de la infraestructura. En el ejemplo, usamos Go para manejar el tema de Continous Delivery.

Es interesante como el modelo de múltiples capas es calificado como monolítico. Y la verdad ya lo es. Hace 20 años, dada nuestra capacidad de recursos de cómputo, el modelo era útil e inclusive el dividir en varios componentes una aplicación era demandante en arquitectura física. Hoy ya no, con esquemas de virtualización y de nube una aplicación puede ser procesada en decenas o centenas de servidores.

El otro punto es que el concepto de servidor se está volviendo cada vez menos necesario. El servidor se está volviendo una unidad de procesamiento más, y lo mas importante, no hay que preocuparse por el número de instancias de procesamiento. Es lo que se conoce como serverless computing.

El segundo taller fue después del almuerzo y orientado a Java, y hablar de como integrar Spring con JEE o viceversa, en algunos lados he visto como unas guerras santas entre fanáticos de ambas visiones. Sabiamente los expositores nos explicaron los detalles de como lograr la convivencia de ambos enfoques.  A los que están contaminados aún con los cursos monolíticos, ortodoxos y arcaicos que dan en ORACLE de arquitectura JEE, les invito se vacunen y lean este libro.

En paralelo hubo otros talleres interesantes, uno de ellos se saturó, pero afortunadamente aquí están las láminas.

Al otro día,  se arrancaron con una serie de platicas (keynotes) bastante interesantes. Una de ellas, sobre Conversational Commerce, muy interesante.

Después, tome la conferencia sobre como en las carreteras de Noruega se está instrumentando para obtener diversas métricas.

La siguiente plática que tome, fue sobre Internet of Things y los diversos esquemas de integración y comunicación. MQTT , Watson, API management y usando BlueMix

Pasando entonces a la siguiente plática, sobre Domain Driven Data , que por cierto, me llama la atención como varios arquitectos aún no identifican el concepto de Domain Driven Design y que es un tema que se está mencionando de manera continua para el diseño de microservicios.  Aparecieron varios modelos de base de datos NoSQL y el concepto de Command Query Responsability Segregation (CQRS) . Dado el concepto de microservicios, lo que expusieron en esta platica es que ya la arquitectura depende de un solo repositorio de base de datos relacional, sino que puede existir diversos repositorios y de acuerdo al dominio del problema. Lo que si quiero hacer notar es que esto está llevando a un modelo de sistema distribuido donde el teorema CAP debe ser tomado en cuenta .

Mucha información en menos de un día, verdad? Y aún faltaban dos pláticas mas.

La plática sobre las mejores prácticas para implementar el modelo de arquitectura serverless (aún no me atrevo a dar la traducción en español) que dio el CEO de iron.io  . Lo interesante es que iron.io es una compañía que está apostando bastante al concepto de serverless computing , la idea de microcontainers, procesamiento masivo. Sala llena por cierto.

La última del día fue sobre como usar AWS Lambda para implantar una aplicación serverless .

Por cierto, si quieren tener una herramienta que les ayude a definir API Webs, revisen Swagger

Llegó el miércoles, el último día, mas keynotes.

El arquitecto de HomeDepot platicó la estrategia para ir hacia microservicios. Insisto, no es ahora poner en el mapa de trabajo de TI de las empresas el uso de microservicios, pero si están llegando a un nivel de madurez donde la complejidad de las aplicaciones están generando pesadillas tanto en la ejecución  como en tiempo de desarrollo, hay que pensar en un cambio.

Les pongo estas ligas de Martin Fowler, donde habla del concepto de microservicios y ojo,  las implicaciones. Por favor, comunidad de TI, no caigamos en buzzwords que luego generan los falso profetas (de manera típica, los archienemigos de los arquitectos, ventas).

Uno de ellos fue dado por el director de arquitectura de SalesForce y lo que destaco de esta plática es como la arquitectura se ve beneficiada por incluir conceptos como meta datos, la habilidad de combinar piezas de software y el tratar grandes volúmenes de datos.

Y el último keynote, muy interesante, la continua repetición del dolor en el desarrollo de software. Uno de los puntos, es que muchas organizaciones se la pasan gastando recursos en hacer mejoras que derivan en un impacto mínimo o nulo. Pongo la liga del libro de Janelle Klein. Yo diría, basta de IT Crowd way of life. Una manera responsable de pensar en TI

De ahí, ya la primera plática sobre Unikernels y donde empiezo a oír de Russell Pavlicek, quien busca adelgazar a las Virtual Machines para poder acelerar el tiempo de arranque de instancias, particionar los recursos de acuerdo a los microservicios y no desperdiciar recursos en cargar librerías y procesos innecesarios. Un enfoque es el que está haciendo la comunidad de Xen, con Mirage OS. Me gusto mucho el enfoque de Russell, práctico.

Otra plática, habla sobre como pensar la arquitectura como un sistema biológico.

Y lo que esperaba, ver a Adrian Cockfrot en vivo, quien ayudo a Netflix a poder soportar grandes escalas. Su plática fue sobre microservicios.

Continuado entonces una plática sobre la arquitectura de Netflix sobre nube (AWS) 

Y la última del evento, de nuevo fui a escuchar a Rusell Pavlicek, donde su plática fue sobre el tema de hipervisores.

En resumen, un evento interesante, lleno de diferentes enfoques de arquitectura de software, pero bastante orientado a lo práctico, no a lo abstracto.  Los expositores son conocidos en su ámbito, muchos de ellos autores de libros de O´Reilly.

No deja de ser apasionante el arte de la arquitectura de software; dado que todo este cuerpo de conocimiento, toca en lo personal como arquitecto, tratar de sintetizar, tomar decisiones para lograr cumplir con las expectativas técnicas de una solución.

El arquitecto de software no deja de seguir tecleando código o instalando/configurando. Es muy importante que conozca lo que implica sus soluciones.

Ojalá las generaciones actuales que luego se coronan de manera inmediata como arquitectos, entiendan que es una gran responsabilidad portar este titulo.







miércoles, 20 de abril de 2016

El modelo de Innovación de Innbit


En Innbit te ayudamos a que tu organización capitalice las ideas de sus recursos humanos para generar innovaciones a través de servicios de que den valor a tus clientes; utilizando un enfoque para dar certidumbre a los proyectos y apoyando con tecnología de vanguardia, con la visión de que dichos servicios tengan un alta diferenciación y ventaja competitiva

Para esto, tenemos un modelo de innovación y que es la manera para ir enfocando a tu organización en los primeros pasos para generar soluciones innovadoras.



El modelo consiste en hacer que tu organización conforme un equipo de personas que ya tienes como parte de tu Capital Humano y con la capacidad y la ansiedad de generar ideas. Es sorprendente, pero en muchas organizaciones la gente que es callada son las que tienen un mejor potencial pero que guardan silencio al identificar culturas ortodoxas o burocráticas. 

Para conformar al equipo de innovación, no basta con citarlos y ponerlos en un área de trabajo para ver como se les ocurren ideas.  Es muy importante que en una organización identifique el tipo de innovación a buscar. La innovación se puede dar al generar una nueva manera de otorgar los servicios a los clientes o por generar nuevas características sobre productos ya existentes; y es normal que detrás de un proceso burocrático o un producto con baja calidad esté la respuesta y una persona con talento de innovación identifica como una oportunidad (lo contrario es cuando las personas ven los errores pero solo se quejan y nunca proponen como cambiar) y empieza a proponer ideas que típicamente mezclan  dos o más conceptos que previamente no eran compatibles.

Piensen cuando tenemos que sufrir tiempos de espera en organizaciones que dan servicio, o cuando nos piden documentos para otra vez comprobar nuestra identidad, o cuando hablas a un centro de contactos y no saben nada de ti. En ese momento está una oportunidad de innovación.

Para que una idea se convierta en innovación, se debe llevar a dicha idea a que sea comercializable, que tenga consumidores que la utilicen y la hagan parte de su vida laboral o personal.  Muchos equipos de trabajo se quedan encantados y atrapados en su idea pero eso les impide ir a la fase de comercialización.

La formula de la innovación es igual a IDEA * COMERCIALIZACIÓN.  Si no hay comercialización, no es innovación.

Entonces, que pasos deben seguirse para llevar una Idea a transformarse en una innovación. 

El primer paso es hacer que las personas se conformen como un equipo y sepan a expresar sus ideas. Con la técnica de Lego Serious Play  (LSP) se logra integrar equipos de trabajo, permite que el 100% de los participantes aporte y colabore y al concluir las sesiones tienen una maqueta en 3D que representa via metáforas, la visión o estrategia o el producto o servicio. 

Una vez que el equipo de innovación se conformó, para cada Idea, debe someterla a estas preguntas:
  • ¿ Quién es tu cliente ?
  • ¿ Qué puedes hacer por tu cliente ?
  • ¿ Cómo van adquirir a tu producto o servicio ?
  • ¿ Cómo obtener dinero del producto ?
  • ¿ Cómo diseñar y fabricar a tu producto ?
En Innbit, en esta serie de pasos, también nos atrevemos a ser innovadores. Convertimos una disciplina que es  acusada de ortodoxa - Arquitectura Empresarial - y la enfocamos para que se contesten las preguntas anteriores y sumando también Lego Serious Play.

Al concluir, tenemos un modelo de empresa escalable y que se sustenta en tres pilares tecnológicos:

  • Consumibles Digitales que se traduce a Aplicaciones móviles, Gadgets (Internet of Things) y todo lo que permite entregar y enviar información a las personas
  • Servicios Digitales que se traduce a Servicios Web (o Web API) y que envuelven los procesos y lógica de negocio
  • Nube que se traduce a la infraestructura tecnológica (Computo, Almacenamiento) sobre el cual ejecutar a los servicios digitales
Y algo que es muy importante, como parte de una empresa que quiere innovar y es el hecho de aprovechar la información para identificar a tus clientes, hacer predicciones; utilizando técnicas de ciencia de datos
Inclusive, muchas organizaciones pueden vender sus volúmenes de datos para ayudar a identificar comportamiento o tendencias. Hoy siento que muchas organizaciones están ignorando el poder de la información que ya tienen a la mano y están desperdiciando TeraBytes al día. 

Entonces, innovar no es una ciencia oculta, es algo que de manera natural cualquier organización puede hacer y utilizando la tecnología de información como diferenciador.

En Innbit te podemos ayudar a dar los pasos que necesites, te acompañamos hasta donde tú desees. Por que nuestro trabajo es despertar al equipo de personas que transformen  a tu organización e inspirarles para que definan productos y servicios con Tecnología de Información de vanguardia.