domingo, 26 de junio de 2016

Lego Serious Play con PMBOK

El día miércoles 22 de junio 2016 tuve la oportunidad de impartir el taller de Administración de proyectos a través de métodos lúdicos con Lego Serious Play.

Esta taller fue el resultado de una idea de más de dos años, y que consiste en utilizar Lego para hacer los cursos de buenas prácticas (ITIL, TOGAF, PMBOK) y que de ahí me llevo a descubrir Lego Serious Play, De ahí tuve que esperar un año para tomar la certificación con Robert Rasmussen.

La duda que a los lectores les aparece es sobre como se combina Lego Serious Play con lo indicado por el PMBOK.

Lego Serious Play es utilizado cuando una pregunta tiene múltiples respuestas y se requiere obtener un consenso de diversas ópticas y personas. Su enfoque de que el 100% de los participantes estén activos en las sesiones de trabajo y que expresen sus ideas a través de bloques de Lego como metáforas



Si ustedes leen el PMBOK, muchos de los procesos mencionan que se utilice como técnica el juicio de experto y juntas.

Por tanto, las juntas y juicio de expertos pueden ser conducidos bajo el enfoque de Lego Serious Play y con la ventaja de que se involucra a todos y se puede vencer la típica idea de que las juntas de administración de proyectos son aburridas.

Voy a listar, de acuerdo a los grupos de procesos y áreas de conocimiento, algunos ejemplos en donde LSP se puede utilizar:


  • Inicio.  Identificar usuarios involucrados. Los asistentes modelan los usuarios interesados que identifican y su nivel de poder e interés.
  • Inicio. Elaborar acta constitutiva. Los asistentes acuerdan el objetivo, la visión de negocio, las restricciones
  • Planeación. Obtener requerimientos. Se utiliza un modelo de Lego Serious para acordar los requerimientos del producto
  • Planeación. Definir el alcance.  Elaborar una maqueta que defina al proyecto y el alcance
  • Planeación. Identiicar riesgos. Cada riesgo u oportunidad se puede concebir en términos de Lego Serious Play como eventualidad y narrados como metáfoaas que se pueden conectar a la maqueta que representa al proyecto y alcance. 
  • Monitero y Control. Realizar el control integral del cambio. Los participantes pueden utilizar la maqueta de Lego para analizar el impacto, explorando las diversas relaciones o contestando preguntas de tipo "Que  pasa si?"



Durante el taller que impartí, solicite a los asistentes que para inicio y planeación me utilizaran una maqueta de Lego Serious Play y le fueran agregando características adicionales, representado los usuarios involucrados, las funcionalidedes, los riesgos, criterios de calidad. Y cuando les pedi un cambio, utiilzar la maqueta para deliberar los cambios.

Dado que LSP permite entender en una maqueta de tres dimensiones, las relaciones, la complejidad, faciilita el entendimiento de varios conceptos y poder simularlos.

El reto que puse a los asistentes del taller fue la creación de un puente.
La foto que pongo aquí , fue el primer intento, que tuvo diversos detalles.


El proyecto se convirtió en hacer el puente, pero con una separación en dos vías e integrado con otras figuras de Lego - barco, carros - y que entregaran 7 videos representando diversas escenas.

Hubo varios descubrimeintos del equipo, desde que los administradores de proyectos aún seguian metiendose a la fabricación del puente, la comunicación y que muchas veces las instrucciones no eran entendidas, o los administradores de proyecto no iban midiendo el avance. Siempre reforazando a que se enfocarn a su modelo de Lego Serious Play que era su guia para el proyecto. 

Fue un ejercico de 8 horas, donde 2 horas se tuvieron que usar para habilitar a los quince asistentes en el uso de la metodología. Pero también fueron horas de trabajo muy efectivas, donde el tiempo paso rápidamente y de un equipo que fue heterogeneo, fue poco a poco conformandose y tomando sus roles. 

Fue una experiencia enriquecedora, cada vez que tengo la oportunidad de usar Lego Serious Play, es soprendente como cada participante concibe las ideas.

Como siempre digo, en los proyectos es fundamental el tema de las personas y la comunicación. Con Lego Serious Play, ambas areas de conocimiento son enfocadas de manera intríseca.

Al final, lo que quiero concluir es que la admnistración de proyectos no debe ser una actividad mecánica o aburrida, sino apasionante, donde el rol de administrador de proyecto debe poner de su parte innovador y riqueza humana para lograr los objetivos del proyecto.

 El adminstrador de proyecto debe ser un líder y gran comunicador. Debe usar de muchas herramienas que tenga a la mano. Una de ellas puede ser Lego Serious Play. El reto es que las personas que tomen el rol de adminstrador de proyecto rompan enfoques ortodoxos y busquen cambiar la óptica de trabajo para bien de los involucrados.

domingo, 29 de mayo de 2016

Agile Open MX 2016

El sábado 28 de mayo se llevó a cabo el evento Agile Open MX 2016, en éste se organizaron varias charlas, y talleres sobre temas de metodologías ágiles: Scrum, Extreme Programming, Lean, Kanban, Software Craftsmanship, frameworks, herramientas de desarrollo de software, y otros más.

Asistí a varias pláticas donde se manejaron temas desde los principios y valores del agilismo, pasando por el desarrollo profesional, cambio cultural de equipos, DevOps y hasta la práctica de la facilitación gráfica para la comunicación visual. Lo común en todas fue el reforzamiento de los principios, valores y prácticas del agilismo y coincidir con gente interesada en compartir experiencias propias y entablar conversación 

Aunque no llegué a tiempo para la ceremonia de apertura estuve en la del cierre en la que se realizó un ejercicio de retrospectiva de una sola palabra. “Divertido”, “Interesante”, “Increíble”, “Dinámico”, “Amoroso” y varias palabras más surgieron de los que asistimos para expresar nuestra emoción al respecto. 

Después tuvimos la agradable sorpresa de la llegada de Mike Beedle, uno de los firmantes del Manifiesto Ágil y dedicado promotor de Scrum, para cerrar el evento con una charla en la que destacó varias razones por las cuáles el agilismo debe ser una práctica de todos los días en las organizaciones del Siglo XXI. Un comentario de parte de Mike fue muy interesante: “Ir a tomar un curso para certificación o tomar un examen está bien pero dedicar todo un día de un fin de semana a la difusión del agilismo demuestra pasión por esto”. 

Es emocionante y prometedor escuchar de varios de los participantes como es que el agilismo se va filtrando a una variedad cada vez más amplia de organizaciones incluso en algunas que tradicionalmente se resisten al cambio. Éstas prácticas que hasta hace unos pocos años se veían con desconfianza y desdén son ahora la manera en las que las empresas buscan apoyarse para cambiar de acuerdo a la competencia de su industria y la demanda de sus clientes. Creí y sigo creyendo que ésta manera dinámica y adaptable es una mejor manera de construir productos o servicios y estos eventos y las personas que participan refuerzan esa confianza.

Una de las cosas curiosas del agilismo es la manera tan fácil de describirlo y la complejidad para ejecutarlo. Me parece que la dificultad radica en que se trata de una mentalidad, de una forma de hacer las cosas que es a la vez simple y obvia pero que es difícil describir en un texto o imágenes y que la mejor manera de entenderlo es ejercitarlo en el día a día. Práctica, práctica, práctica. Todos los días.

Una de las cosas que si quisiera cambiar es el uso de anglicismos o términos en inglés. Menos “spanglish” y más español. Puede que eso también sea una barrera de aceptación y sí es así hay que derribarla.

Se han estado organizando eventos mensuales que son difundidos a través de las redes sociales, vamos a estar al pendiente y buscar la manera de asistir y mejor aún de participar.

martes, 24 de mayo de 2016

Parrafo final del libro el Arte de Amar de Erich Fromm

Me atrevo a reproducir el último párrafo del Arte de Amar de Erich Fromm

Si el hombre quiere ser capaz de amar, debe colocarse en su lugar supremo. La máquina económica debe servirlo, en lugar de ser él quien esté a su servicio. Debe capacitarse para compartir la experiencia, el trabajo, en vez de compartir, en el mejor de los casos, sus beneficios. La sociedad debe organizarse en tal forma que la naturaleza social y amorosa del hombre no esté separada de su existencia social, sino que se una a ella. Si es verdad, como he tratado de demostrar, que el amor es la única respuesta satisfactoria al problema de la existencia humana, entonces toda sociedad que excluya, relativamente, el desarrollo del amor, a la larga perece a causa de su propia contradicción con las necesidades básicas de la naturaleza del hombre. Hablar del amor no es «predicar», por la sencilla razón de que significa hablar de la necesidad fundamental y real de todo ser humano. Que esa necesidad haya sido oscurecida no significa que no exista. Analizar la naturaleza del amor es descubrir su ausencia general en el presente y criticar las condiciones sociales responsables de esa ausencia. Tener fe en la posibilidad del amor como un fenómeno social y no sólo excepcional e individual, es tener una fe racional basada en la comprensión de la naturaleza misma del hombre.

A nuestros lectores les invito a reflexionar este párrafo y extrapolar en su vida actual. Busquen si no están perdiendo la oportunidad de Amar frente a trabajar, tener mucho dinero, o prestigio o anexas. Al final de este camino llamado vida, lo único que nos vamos a llevar es los momentos de amor. Todo lo material aquí se queda.

Existir para amar es el sentido de la vida de los seres humanos, es nuestra Naturaleza.

martes, 10 de mayo de 2016

Más poder a los devs - Microsoft Azure Dev Camp 2016

Hace un par de días tuvimos la oportunidad de participar en un Dev Camp enfocado en las tecnologías de Azure, la apuesta a la nube por parte de Microsoft; un servicio que incluye los productos ahora típicos en ofertas de nube: máquinas virtuales, infraestructura-estilo-datacenter, servicios administrados de bases de datos y soluciones de autenticación y seguridad, entre otros. A pesar de estar familiarizados con las ofertas básicas de otros proveedores, resultó ser un vistazo interesante a la perspectiva de un gigante de la tecnología, por mucho tiempo pensado como monolítico y acorbatado,  a los procesos y servicios comúnmente relacionados con las empresas más jóvenes y ágiles.

Aunque Azure es una propuesta con mucho tiempo gestándose, su relativa anonimidad es sorprendente (y esto lo digo como desarrollador primariamente de .Net). Durante nuestro día con Azure pudimos observar 3 servicios principales: servicios administrados de aplicaciones (Azure Web Apps), integraciones con dispositivos Internet-of-Things (Azure IoT Hub), y aplicación y creación de servicios de ciencia de datos (Azure Machine Learning).

Si hay algo que se puede decir sobre los productos de Microsoft donde la mayoría de las personas estarían de acuerdo, es que Visual Studio es una herramienta genial (mundo FOSS, espero pacientemente sus cartas al editor). Microsoft sabiamente ha casado las diferentes propuestas de su nube a su plataforma de desarrollo de una manera fluida y discreta, abstrayendo muchas de las consideraciones y suposiciones de una integración de este tipo para simplemente dejar al desarrollador desarrollar.

Azure Web Apps es un servicio interesante que permite aprovisionar, lanzar, probar y monitorear aplicaciones de todo tipo, directamente desde el ambiente de desarrollo. El proceso clásico de levantamiento y configuración de un ambiente que tantas veces se convierte en un agujero de tiempo para el equipo se convierte en una serie de clicks, elección de algunos nombres y uno o dos llenados de tazas de café. Con elecciones de lenguajes como C#, JavaScript, Java, PHP y Python, la habilidad de pasar de un ambiente dev/test a producción en 2 clicks e integración transparente con analíticos de medición y DevOps, simplifica enormemente nuestros procesos y permite que nos concentremos en entregar funcionalidad real (o leer Stack Overflow, sus kilometrajes pueden variar).

De la misma manera, Azure IoT Hub abstrae muchos de los dolores de cabeza usuales de la comunicación y administración de dispositivos distribuídos, como seguridad de comunicaciones, deshabilitación remota, administración de llaves, e incluso algunos mas recientes como analíticos y ciencia de datos. Una de las demostraciones incluyó el procesamiento de un video de webcam con visión computacional para detectar información general sobre el usuario final, tales como estado emocional general, género y perfil visual (lentes, barba), pasada directamente por un motor de Business Intelligence para generar gráficas y reportes tiempo real.

En el tema caliente de ciencia de datos y aprendizaje máquina, Azure Machine Learning experimenta con traer las cualidades drag-and-drop del software visual de Microsoft a métodos como entrenamiento, modelado, transformación de datos, regresión, clasificación y validación. Desde la interfaz web se pueden arrastrar módulos preconfigurados, importar código de R, correr simulaciones y despues convertir el proyecto en un servicio Web predictivo basado en los resultados, todo a través de una interfaz similar a Visio. Mi percepción de RStudio ha cambiado drásticamente después de esto, debo admitir.

En el plano personal, y además de lo ya mencionado arriba, fue bastante agradable ver que Microsoft ya despertó al Nuevo Orden Mundial y abraza muchas tecnologías FOSS, como Node, R, Cordova en el lado móvil y particularmente Linux y su ecosistema. Como desarrollador primordialmente en Windows, se me hace increible mantener mi ambiente IDE preferido pero poder incluír el vínculo con estas nuevas tecnologías tan poderosas con un mínimo de curva de configuración.
Claro está que como buen carro familiar, uno no puede ir tan rápido y tiene bolsas de aire por todos lados, y ciertamente a veces en vez de una vagoneta necesitas un trophy truck de offroad, un Fórmula 1 o un Bugatti sexy, cada proyecto tiene sus características particulares; creo que lo que más nos llevamos del evento es que hay varias maneras de apostarle a la nube y Microsoft en particular busca hacerlo a través de servicios transparentes basados en el evangelista mas poderoso: el desarrollador.

Youth de Paolo Sorrentino

Después de la ola de super producciones como Civil War, el domingo 8 de mayo fui a ver la película Youth.

No quiero hacer una sinopsis ni critica de toda la película.

Cabe destacar la actuación de Michael Caine y Harvey Keitel.

La película se desarrolla en su mayoría en un hotel spa de Suiza, donde de entrada las escenas visuales son bastante apreciables. Muestra a veces imágenes de gente mayor y como trata de preservar su cuerpo o de algunos jovenes pero cuyo espíritu ha envejecido antes.  De repente aparece un Maradona donde es una sombre de lo que fue.

Hay mucho que entender de la película. Michael Caine interpretando un compositor de música que ya se declaró retirado, con 80 años de edad pero aún con fortaleza física y mental, pero que durante todo el film se niega a volver a su antigua disciplina y poco a poco se descubre por qué.

Solo un evento que él no esperaba, se da cuenta de que en esta vida, nuestra obra no hay que atarla a las acciones de los demás, y nunca es tarde para crear.

He visto como mucha gente se ata a su esposo, papás, hijos para justificar su vida y su día a día y cuando algo no sale bien, paran o caen en una etapa de tristeza. Parte de la magia de existir es entender lo que somos y lo que podemos ofrecer, aunque sea lo más simple, por que a alguien más le ayudará tu obra.

También es reflexionar sobre la juventud, nuestro cuerpo.

 Hoy con el estilo de vida guiado por minuteros y eficiencias de productividad, dejamos para al rato el encontrar un equilibrio físico que garantice a un futuro que podamos soportar los efectos del tiempo y  ya no poder dar más por que la salud no lo permite.

Esta melodía-canción es con la que cierra la película .


Traten de ver la película, antes de que la desaparezcan de la cartelera, donde ha sobrevivido a 5 cines, frente a cientos que proyectan Civil War

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.