Desde junio de 2017 tuve la oportunidad de contactar a la comunidad de Rust en la Ciudad de México.
Coincidió en el momento donde me tomé un pequeño tiempo para entender lenguajes como Haskell y Erlang.
Rust es un lenguaje para programación de sistemas, tipo de programación que normalmente se hace en lenguaje C/C++ y haciendo llamadas al núcleo (kernel) del sistema operativo.
A diferencia de C/C++, permite al programador a enfocarse a los problemas de la programación de sistemas y evita que se pierdan en temas como el manejo de apuntadores, memoria,
La sintaxis de Rust es similar a C/C++, pero introduce nuevas características para que el programador pueda ir controlando el tiempo de vida de las variables y también definir tipos de datos.
Rust tiene en su diseño todo lo necesario para el manejo de memoria, concurrencia.
Rust no tiene un recolector de basura (garbage collector) y controla el manejo de la memoria a través de un concepto que se llama préstamo (borrowing)
Rust también utiliza un sistema de tipos (inspirado en el lenguaje Haskell) y utiliza el concepto de tratos (traits) y maneja inferencia de tipos.
Soporta conceptos de programación funcional tales como closures
Para la programación concurrente, permite identificar muchos de los posibles errores a través del compilador, y que le llama fearless concurrency
Para tener mayor detalle del lenguaje, la página Web de Rust contiene bastante documentación y tutoriales
domingo, 3 de septiembre de 2017
domingo, 25 de junio de 2017
Programar y TI no se trata de hipsters
Curiosamente, en estas últimas semanas me he topado con el concepto de que hay plataformas y lenguajes hipsters. Al principio pensé que era mas en términos de broma y analogía, pero muchos si lo toman en serio.
Lo primero es que programar no se trata de poses ni tiene que ver con la "cultura contemporanea"
La simple idea de programación y TI hipster me lleva solo a entender que la gente que dice eso, sólo están tratando de hacer como que programan y como que entienden y lo hace para su "startup" y se llena de muchos términos técnicos que no entienden y ni siquiera saben su orígen; pero que a muchos de ellos no les lleva a algún camino a largo plazo.
Programar no es de millenials, ni de hipsters, ni de ninis, ni todas las definiciones que son tan usadas en las "redes sociales". Como que cualquier actividad humana y que se hace con el espíritu de crear, el hecho de programar es poner el ingenio de la persona para resolver un problema o mostrar un concepto o manipular información.
Los lenguajes de programación, que los que se auto nombran hipsters de TI, creen que son el resultado de una revolución para el cambio. No es por ahí, obedece mas a una evolución mas que una revolución. Y por esto me dedico en esta entrada, a recordar como hemos llegado a esto.
Cada generación cree que tiene un lenguaje de programación que de a verdad va a solucionar los problemas. En su momento, los que vivieron la aparición de Pascal así vieron reflejado el requerimiento de poder pensar de manera modular sus soluciones. Y llego C y muchos vieron que la necesidad de tener un lenguaje con un mínimo de sintaxis, alto desempeño y portable, y fue la respuestas para la programación de sistemas. Por varios años así fue, en revistas como Dr. Dobbs o Byte (cuando era una referencia digna de respetar), todos planteaban soluciones a diversos problemas. Solo que en esos tiempos, no se decían hippies o algo así.
Vino después la ola de programación orientada a objetos, resultando en un C++ que de repente complicaba la sintaxis, mientras otros lenguajes como Smalltalk, Eiffel, Modula, Objective C llegaron a implantar el enfoque de manera elegante. Un resultado que conozco como la cumbre de ese enfoque, es la plataforma de NeXT que hoy ni esos llamados hipsters tienen en la mente, pero cuyas ideas las usan prácticamente todo el día en sus dispositivos inteligentes.
La capacidad de los sistemas operativos para ayudar que los lenguajes de programación tuvieran la capacidad de cargar de manera dinámica bibliotecas de código fuente, abrió la pauta para tener módulos de software cambiantes y donde el polimorfismo se podía explotar al máximo. De ahí salieron las DLL ( en 16 o 32 bits y que son segmentos de código ejecutable) o los .so en plataformas UNIX.
No basto esto, por que el modelo cliente-servidor ya ofrecía la promesa de dividir el procesamiento del código fuente de aplicaciones en por lo menos en dos computadoras. Al principio empezó con Llamadas a Procedimientos Remotos (RPC) y que aprovechó la empresa Sun Microsystems que hasta su eslogan era "la red es la computadora". Sin embargo, el mundo de los programadores orientados a objetos también quizo tener su enfoque de objetos distribuidos, y nació CORBA y DCOM; que hoy pocos se han de acordar, salvo los que los usaron en la práctica.
En ese momento, era ya complicado el hacer labores de programación en lenguajes como C++. Y llegó en ese momento un lenguaje orientado a objetos que seguía la corriente de C pero mas simple en sintaxis que los primeros esfuerzos. Me refiero a Java, si aquel cuya versión alfa podía ser utilizado en 1995 y que de manera acelerada fue adoptado por una generación "joven" (si, en esos tiempos teníamos 25 a 35 años de edad los que empezamos dicha adopción) y en un abrir y cerrar de ojos, Java se utilizó para implantar con éxito lo que no se pudo con los antecesores. Mientras la gran parte de la comunidad de programadores estabamos ciegos en pensar todo con Java, afortunadamente lenguajes como Python o Ruby estaban dando pasos hacia lo que viene.
Java aún sigue siendo uno de los más utilizados y que se enseñan en las Universidades. Al mismo tiempo, apareció un lenguaje cuya estabilidad dependía de la carrera por conquistar a los usuarios de Internet, me refiero a Javascript, y que por varios años no fue pensado como opción y del lado de Java o C# se prefería realizar la manipulación dinámica del HTML y engordar un poco más al servidor, de ahí marcos de trabajo como Struts hasta llegar al frankestein llamado JavaServerFaces.
Con el fin de la carrera de los navegadores, JavaScript se vio beneficiado y tuvo estabilidad, al mismo tiempo que la implantación de HTML5 se hizo viable. Pero el estado era un modelo de arquitectura de servidor con componentes complicados (si, JEE me refiero a ti y a tus EJBs de entidad).
Aún, los primeros intentos de aplicaciones móviles, estaban con este enfoque, aún recuerdo Java MicroEditon y sus midlets, y donde el poder de procesamiento de los dispositivos móviles era nada, frente a lo que hoy tenemos.
Aunque Java se puso a dieta, gracias a los esfuerzos de la comunidad de Spring, el lenguaje se volvía cada vez menos intuitivo, presionado también por que C# lo supero. Java 5 tomo el concepto de Generalidad, anotaciones, pero ya no era lo mismo que en 1995.
Llegó la era de XML como formato para lograr la interoperabilidad y como cualquier tecnología, tuvo sus abusos. Los "hipsters" de esos tiempos no avanzaban si no podían abrir una etiqueta (es broma). Se conjunto con SOA (mal entendido como WebServices)
Mientras, Ruby on Rails mostró una buena lección a la comunidad Java (que algunos no la entendieron del todo bien y crearon Grails) y se mostró que un enfoque ligero es más poderoso que el estándar de J2EE. Agregar que Java cayó en las manos de Oracle.
Llega 2011, y con ello ya suena el término de computación en la nube y las aplicaciones móviles cambien el enfoque ante la aparición de plataformas como iOS, Blackberry (RIP) y Android. Quedan obsoletos los planteamientos de plataformas de Java (y me refiero al Application Development Framework de Oracle), mientras que en un giro inesperado, Microsoft si reacciona y empieza a adoptar los principios de programación que la comunidad está fuertemente impulsando.
Al mismo tiempo que los métodos ágiles son cada vez utilizados (y a veces mal utilizados) para enfocarse a tener soluciones de valor, le tecnología de hardware ayuda a que el software aproveche el poder de virtualización de procesamiento, almacenamiento y redes. El concepto de cliente-servidor, se puede llevar al máximo, y de hecho esa relación cliente-servidor, se vuelve par-a-par (P2P y no hablo de Napster). Pequeños componentes de código fuente se pueden asignar a una unidad (virtualizada) de procesamiento y con mínimos recursos, de hecho se generan imágenes mínimas o contenedores. Es lo que se le llama microservicios (algunos dicen que es la evolución de SOA, pero no es cierto).
Agregado que hoy tenemos lenguajes con un enfoque menos complicado que Java o C#. Muchos de ellos influenciados por lenguajes funcionales (Haskell por ejemplo) ; o lenguajes como Go o Rust. Mientras tanto, Java 8 y superior siguen estando cada vez más complicados.
¿Y hoy dicen que usar microservicios, nube, agilidad, lenguajes no tan conocidos es hipster? Es una equivocación.
En el JavaOne del año 2001, Sun Microsystems anuncia JXTA, una plataforma P2P.
Lo primero es que programar no se trata de poses ni tiene que ver con la "cultura contemporanea"
La simple idea de programación y TI hipster me lleva solo a entender que la gente que dice eso, sólo están tratando de hacer como que programan y como que entienden y lo hace para su "startup" y se llena de muchos términos técnicos que no entienden y ni siquiera saben su orígen; pero que a muchos de ellos no les lleva a algún camino a largo plazo.
Programar no es de millenials, ni de hipsters, ni de ninis, ni todas las definiciones que son tan usadas en las "redes sociales". Como que cualquier actividad humana y que se hace con el espíritu de crear, el hecho de programar es poner el ingenio de la persona para resolver un problema o mostrar un concepto o manipular información.
Los lenguajes de programación, que los que se auto nombran hipsters de TI, creen que son el resultado de una revolución para el cambio. No es por ahí, obedece mas a una evolución mas que una revolución. Y por esto me dedico en esta entrada, a recordar como hemos llegado a esto.
Cada generación cree que tiene un lenguaje de programación que de a verdad va a solucionar los problemas. En su momento, los que vivieron la aparición de Pascal así vieron reflejado el requerimiento de poder pensar de manera modular sus soluciones. Y llego C y muchos vieron que la necesidad de tener un lenguaje con un mínimo de sintaxis, alto desempeño y portable, y fue la respuestas para la programación de sistemas. Por varios años así fue, en revistas como Dr. Dobbs o Byte (cuando era una referencia digna de respetar), todos planteaban soluciones a diversos problemas. Solo que en esos tiempos, no se decían hippies o algo así.
Vino después la ola de programación orientada a objetos, resultando en un C++ que de repente complicaba la sintaxis, mientras otros lenguajes como Smalltalk, Eiffel, Modula, Objective C llegaron a implantar el enfoque de manera elegante. Un resultado que conozco como la cumbre de ese enfoque, es la plataforma de NeXT que hoy ni esos llamados hipsters tienen en la mente, pero cuyas ideas las usan prácticamente todo el día en sus dispositivos inteligentes.
La capacidad de los sistemas operativos para ayudar que los lenguajes de programación tuvieran la capacidad de cargar de manera dinámica bibliotecas de código fuente, abrió la pauta para tener módulos de software cambiantes y donde el polimorfismo se podía explotar al máximo. De ahí salieron las DLL ( en 16 o 32 bits y que son segmentos de código ejecutable) o los .so en plataformas UNIX.
No basto esto, por que el modelo cliente-servidor ya ofrecía la promesa de dividir el procesamiento del código fuente de aplicaciones en por lo menos en dos computadoras. Al principio empezó con Llamadas a Procedimientos Remotos (RPC) y que aprovechó la empresa Sun Microsystems que hasta su eslogan era "la red es la computadora". Sin embargo, el mundo de los programadores orientados a objetos también quizo tener su enfoque de objetos distribuidos, y nació CORBA y DCOM; que hoy pocos se han de acordar, salvo los que los usaron en la práctica.
En ese momento, era ya complicado el hacer labores de programación en lenguajes como C++. Y llegó en ese momento un lenguaje orientado a objetos que seguía la corriente de C pero mas simple en sintaxis que los primeros esfuerzos. Me refiero a Java, si aquel cuya versión alfa podía ser utilizado en 1995 y que de manera acelerada fue adoptado por una generación "joven" (si, en esos tiempos teníamos 25 a 35 años de edad los que empezamos dicha adopción) y en un abrir y cerrar de ojos, Java se utilizó para implantar con éxito lo que no se pudo con los antecesores. Mientras la gran parte de la comunidad de programadores estabamos ciegos en pensar todo con Java, afortunadamente lenguajes como Python o Ruby estaban dando pasos hacia lo que viene.
Java aún sigue siendo uno de los más utilizados y que se enseñan en las Universidades. Al mismo tiempo, apareció un lenguaje cuya estabilidad dependía de la carrera por conquistar a los usuarios de Internet, me refiero a Javascript, y que por varios años no fue pensado como opción y del lado de Java o C# se prefería realizar la manipulación dinámica del HTML y engordar un poco más al servidor, de ahí marcos de trabajo como Struts hasta llegar al frankestein llamado JavaServerFaces.
Con el fin de la carrera de los navegadores, JavaScript se vio beneficiado y tuvo estabilidad, al mismo tiempo que la implantación de HTML5 se hizo viable. Pero el estado era un modelo de arquitectura de servidor con componentes complicados (si, JEE me refiero a ti y a tus EJBs de entidad).
Aún, los primeros intentos de aplicaciones móviles, estaban con este enfoque, aún recuerdo Java MicroEditon y sus midlets, y donde el poder de procesamiento de los dispositivos móviles era nada, frente a lo que hoy tenemos.
Aunque Java se puso a dieta, gracias a los esfuerzos de la comunidad de Spring, el lenguaje se volvía cada vez menos intuitivo, presionado también por que C# lo supero. Java 5 tomo el concepto de Generalidad, anotaciones, pero ya no era lo mismo que en 1995.
Llegó la era de XML como formato para lograr la interoperabilidad y como cualquier tecnología, tuvo sus abusos. Los "hipsters" de esos tiempos no avanzaban si no podían abrir una etiqueta (es broma). Se conjunto con SOA (mal entendido como WebServices)
Mientras, Ruby on Rails mostró una buena lección a la comunidad Java (que algunos no la entendieron del todo bien y crearon Grails) y se mostró que un enfoque ligero es más poderoso que el estándar de J2EE. Agregar que Java cayó en las manos de Oracle.
Llega 2011, y con ello ya suena el término de computación en la nube y las aplicaciones móviles cambien el enfoque ante la aparición de plataformas como iOS, Blackberry (RIP) y Android. Quedan obsoletos los planteamientos de plataformas de Java (y me refiero al Application Development Framework de Oracle), mientras que en un giro inesperado, Microsoft si reacciona y empieza a adoptar los principios de programación que la comunidad está fuertemente impulsando.
Al mismo tiempo que los métodos ágiles son cada vez utilizados (y a veces mal utilizados) para enfocarse a tener soluciones de valor, le tecnología de hardware ayuda a que el software aproveche el poder de virtualización de procesamiento, almacenamiento y redes. El concepto de cliente-servidor, se puede llevar al máximo, y de hecho esa relación cliente-servidor, se vuelve par-a-par (P2P y no hablo de Napster). Pequeños componentes de código fuente se pueden asignar a una unidad (virtualizada) de procesamiento y con mínimos recursos, de hecho se generan imágenes mínimas o contenedores. Es lo que se le llama microservicios (algunos dicen que es la evolución de SOA, pero no es cierto).
Agregado que hoy tenemos lenguajes con un enfoque menos complicado que Java o C#. Muchos de ellos influenciados por lenguajes funcionales (Haskell por ejemplo) ; o lenguajes como Go o Rust. Mientras tanto, Java 8 y superior siguen estando cada vez más complicados.
¿Y hoy dicen que usar microservicios, nube, agilidad, lenguajes no tan conocidos es hipster? Es una equivocación.
En el JavaOne del año 2001, Sun Microsystems anuncia JXTA, una plataforma P2P.
Hace dos años, platicando con un amigo, le decía que si haciamos una revisióna lo que definió el equipo de Bill Joy, este modelo sirve tanto para microservicios e IoT. Ni siquiera existía el concepto de hipster.
En conclusión, creo demuestro que decir que TI o programación es hipster, solo es una muestra de que la persona que lo dice le falta un poco de preparación y de experiencia (como dice Stallone, te hace falta mas box), y solo muestra que está ignorando el pasado. Si el lector de esta entrada, después de controlar el enojo que le estoy haciendo pasar, le recomiendo vaya a consultar libros de texto de Tannenbaum (como el de arquitectura de computadores, sistemas operativos, ambientes distribuidos) o libros de C, UNIX de los grandes, entre otros, donde desde ahí se hablan de muchas ideas que por fortuna la tecnología hoy ya nos habilita.
Y si eres alguien que han querido impresionar con el termino hipster en TI, por favor, usa algo de lo que aquí expreso y trata de argumentar contra esa falacia. Hoy en día lo que necesitamos es que los que estamos en el ámbito de TI seamos serios y al mismo tiempo creativos y alejarnos de poses.
martes, 14 de marzo de 2017
Aprovisionando ambientes AWS con Ansible
En recientes fechas se nos encomendó la misión de optimizar costos y el uso de recursos de Amazon Web Services utilizados para el despliegue y operación de aplicaciones de uno de los clientes principales de InnBit.
Esta reestructura fue vista como una oportunidad para implementar mejoras en la forma de trabajo con AWS que habíamos estado teniendo. Un punto muy particular es el aprovisionamiento de ambientes que implica lanzar una nueva instancia de EC2, actualizar paquetes, instalar dependencias, configurar el ambiente y desplegar la aplicación para dejar todo listo para que esté disponible para su uso.
Todos los pasos descritos con anterioridad son repetitivos y son propensos a ser automatizados por lo que se decidió incluir la herramienta Ansible para facilitar las tareas de aprovisionamiento y despliegue así como reducir posibles errores y el tiempo que se empleaba para poner a punto las aplicaciones.
Ansible
Ansible es una herramienta de código abierto escrita en python para la automatización y orquestación de tareas
A diferencia de otras soluciones similares, no requiere la instalación de agentes remotos pues su funcionamiento es mediante la ejecución remota de comandos mediante mecanismos como ssh o Windows Remote Managment.
Los comandos son definidos en archivos de texto en formato YAML y permite realizar ejecuciones de comandos repetibles y distribuidas en varios nodos.
Caso de uso
Durante 2016 se desarrollaron aplicaciones que estuvieron en producción casi todo el año. Cuando concluyó este, dichas aplicaciones también terminaron su ciclo debido al fin por el cual fueron construidas. Aún así el cliente solicitó que se mantuvieran activas para fines demostrativos.
Por ciertas razones, en su momento se reservó una instancia EC2 con las siguientes características
- Red Hat Enterprise Linux
- Reservada hasta el 20 Junio de 2017
- t2.medium
De acuerdo a los datos de uso y pruebas, se estima que esta instancia sería capaz de manejar de 3 a 4 aplicaciones con baja demanda. De este modo se determinó que la instancia RHEL sería aprovechada para hospedar las aplicaciones con propósito demostrativo.
Para facilitar la configuración y puesta en marcha de varias aplicaciones en un mismo servidor se decidió generar imágenes docker con cada una de las aplicaciones. Estas imágenes serían almacenadas en el registro de contenedores de EC2 (EC2 Container Registry, ECS) donde estarían disponibles para la ejecución de contenedores.
Otro beneficio de utilizar docker es el redireccionamiento de bitácoras. Anteriormente, para revisar una bitácora era necesario ingresar al servidor y explorar los archivos mediante comandos de Linux para procesamiento de texto. Conforme se incrementa el número de servidores y la incorporación de servidores surge la necesidad de concentrar las bitácoras en un solo punto de modo que la detección de errores y solución de problemas sea más ágil.
Docker ofrece un controlador que permite captar la bitácoras generadas por las aplicaciones dentro de los contenedores y enviarlas al servicio CloudWatch el cual incorpora una funcionalidad para concentrar bitácoras y explorarlas.
Todo el proceso desde la instalación de dependencias hasta la ejecución de las aplicaciones en forma de contenedores fue definido mediante un proyecto Ansible quedando el panorama como se muestra en la imágen.
Proyecto Ansible
Para intentar mantener ordenado y simple el proyecto, se ha organizado de la siguiente manera.
Inventario y Archivos de recursos
El inventario es el archivo de nombre hosts, el cual contiene un grupo de servidores con la ubicación de la instancia RHEL en Amazon.
En la carpeta resources/yum se guardan definiciones de repositorios para instalar los paquetes nginx y docker de acuerdo a la documentación de ambos productos. La idea es que estos archivos sean copiados, utilizando Ansible, a la instancia remota en la ubicación adecuada.
En la carpeta resources/env se guardan archivos con las variables de ambiente requeridas por las aplicaciones. En este punto se pretende nuevamente copiar estos archivos de configuración al servidor y leerlos mediante docker al momento de lanzar los contenedores.
Playbooks
Los playbooks son archivos en formato YAML donde se definen todos los comandos que serán ejecutados en el servidor.
Se separaron las tareas de instalación y configuración de acuerdo al paquete y/o aplicación para mantener compactos los archivos.
nginx.playbook.yml. Instalación típica de NGINX para RHEL, en este caso se utilizó ansible para copiar el archivo ./resources/yum/nginx.repo con la ubicación de paquetes actualizados para la instalación.
awscli.playbook.yml. Instalación de la linea de comandos de AWS. Este se utilizará para la interacción con EC2 Container Registry.
docker.playbook.yml. Instalación y configuración de Docker de acuerdo a la documentación oficial. De igual modo que el anterior, se actualizó la definición de repositorios mediante el archivo ./resources/yum/docker.repo que es copiado al servidor para posteriormente realizar las tareas de actualización de paquetes. Al final se genera el grupo docker y se define al usuario ec2-user como miembro de modo que pueda ejecutar comandos docker sin permisos de super usuario.
cop13.playbook.yml. Ejecución de contenedor docker a partir de una imagen alojada en EC2 Container Registry. Esta imágen contiene una aplicación Ruby on Rails que será ejecutada en el puerto 3000 del contenedor. Mediante ansible, además de lanzar el contenedor, también se establece la correspondencia de puertos (3000:3000), el archivo con las variables de entorno requeridas y el redireccionamiento de bitácoras a CloudWatch.
igf.playbook.yml. Ejecución de un segundo contenedor docker a partir de otra imagen alojada en ECR. La ejecución del contenedor es similar al anterior con pequeñas diferencias como la imagen que se toma, el puerto del servidor que se redirecciona al contenedor (3100:3000), las variables de entorno y el destino de bitácoras dentro de CloudWatch.
rhel-demo-server.playbook.yml. Este archivo incluye referencias ordenadas a los demás archivos de modo que permite mantener la secuencia lógica con las cuales se van a ejecutar las instrucciones.
Conclusiones
Al final los archivos de ansible permitieron la puesta en marcha de las aplicaciones partiendo de una instancia nueva de EC2. Como ventaja estos archivos permiten la replicación automatizada de este ambiente en nuevas y diferentes instancias.
Estos scripts también son propensos de ser incluidos en un conducto de entrega y despliegue contínuo, pero será tema de otra entrada del blog.
domingo, 15 de enero de 2017
Innbit en 2017
Pues ya estamos en el 2017, para muchos temido por las condiciones políticas, económicas y sociales.
Pero no hay que parar el trabajo y seguir contribuyendo en una mejora continua en el día a día de las organizaciones.
En 2016, Innbit tuvo experiencias muy gratas utilizando Lego Serious Play en conjunto con enfoques como Design Thinking, Arquitectura Empresarial, Administración de proyectos e Innovación.
En el uso de arquitectura empresarial y TOGAF hemos ido más allá de lo teórico y hemos podido aterrizar para definir métodos para incorporar computación en la nube, aplicaciones móviles, ciencia de datos; pero con un principio fundamental; que cualquier adopción de estas tecnologías siempre estén alineadas al negocio.
En el tema del desarrollo de soluciones móviles el modelo que nos ha servido es el uso de marcos de trabajo híbridos, tales como Ionic y backends basados en AWS, Bluemix con Ruby on Rails o Node.js. Nuestros tiempos de entrega han mejorado y han permitido cumplir con los requerimientos de negocio de nuestros clientes.
En el contexto de computación cognitiva hemos implementado aplicaciones con los APIs de IBM Watson para poder clasificar el conocimiento de expertos en un dominio del conocimiento.
Hemos logrado certificaciones en nubes como AWS, Bluemix y Azure.
En el tema de Internet of Things, hemos utilizado Arduino y Raspberry Pi para un control inteligente del medio ambiente, captación de información e integración con diversos gadgets.
En 2017 nuestro objetivo es continuar con la misión de utilizar tecnologías de información innovadoras con el fin de crear soluciones para obtener ventaja competitiva.
¿ Cómo es que vamos a cumplir este objetivo?
Primero, hemos definido cinco tipos de productos que ayudan desde el momento que la organización quiere adoptar la innovación como el motor para cambiar su modelo de negocio hasta poder operar y posicionar una solución innovadora.
Estamos trabajando en formalizar los métodos para la adopción de tecnologías de nube, aplicaciones móviles, ciencia de datos y API Web; bajo un enfoque de arquitectura empresarial.
Buscamos la aplicación en industrias del sector financiero, salud, diversión y servicios de consumo, para cubrir las necesidades de automatización de la cadena de valor.
Seguimos adoptando los estándares del OpenGroup y sumaremos a TOGAF, Archimate; el estándar de IT4IT, con la finalidad de apoyar a las áreas de Tecnología de Información en implantar una cadena de valor que les permita adoptar el modelo de servicios y apoyándose de tecnología para proveer tecnología.
Nuestra ruta del 2017 es:
En la historia de Innbit nos hemos dado cuenta que nuestro modelo de innovación consiste en tomar necesidades o problemas que aparecen en las organizaciones que quieren utilizar la tecnología de información para solventar problemas de negocio pero dando un enfoque hacia el resultado. Esto nos ha llevado a combinar conceptos que al principio parecían dispares.
Tenemos en este 2017 en seguir ese enfoque de innovación pero hacia llegar ya a los sectores de la industria mexicana y explorar nuevos modelos de negocio. Parte del desafío es que en México logremos generar una industria para ofrecer trabajo a los mexicanos y disminuir la dependencia de la inversión extranjera.
Pero no hay que parar el trabajo y seguir contribuyendo en una mejora continua en el día a día de las organizaciones.
En 2016, Innbit tuvo experiencias muy gratas utilizando Lego Serious Play en conjunto con enfoques como Design Thinking, Arquitectura Empresarial, Administración de proyectos e Innovación.
En el uso de arquitectura empresarial y TOGAF hemos ido más allá de lo teórico y hemos podido aterrizar para definir métodos para incorporar computación en la nube, aplicaciones móviles, ciencia de datos; pero con un principio fundamental; que cualquier adopción de estas tecnologías siempre estén alineadas al negocio.
En el tema del desarrollo de soluciones móviles el modelo que nos ha servido es el uso de marcos de trabajo híbridos, tales como Ionic y backends basados en AWS, Bluemix con Ruby on Rails o Node.js. Nuestros tiempos de entrega han mejorado y han permitido cumplir con los requerimientos de negocio de nuestros clientes.
En el contexto de computación cognitiva hemos implementado aplicaciones con los APIs de IBM Watson para poder clasificar el conocimiento de expertos en un dominio del conocimiento.
Hemos logrado certificaciones en nubes como AWS, Bluemix y Azure.
En el tema de Internet of Things, hemos utilizado Arduino y Raspberry Pi para un control inteligente del medio ambiente, captación de información e integración con diversos gadgets.
En 2017 nuestro objetivo es continuar con la misión de utilizar tecnologías de información innovadoras con el fin de crear soluciones para obtener ventaja competitiva.
¿ Cómo es que vamos a cumplir este objetivo?
Primero, hemos definido cinco tipos de productos que ayudan desde el momento que la organización quiere adoptar la innovación como el motor para cambiar su modelo de negocio hasta poder operar y posicionar una solución innovadora.
Estamos trabajando en formalizar los métodos para la adopción de tecnologías de nube, aplicaciones móviles, ciencia de datos y API Web; bajo un enfoque de arquitectura empresarial.
Buscamos la aplicación en industrias del sector financiero, salud, diversión y servicios de consumo, para cubrir las necesidades de automatización de la cadena de valor.
Seguimos adoptando los estándares del OpenGroup y sumaremos a TOGAF, Archimate; el estándar de IT4IT, con la finalidad de apoyar a las áreas de Tecnología de Información en implantar una cadena de valor que les permita adoptar el modelo de servicios y apoyándose de tecnología para proveer tecnología.
Nuestra ruta del 2017 es:
- Enero. Lanzamiento de la nueva imagen de nuestro sitio Web con enfoque a explicar nuestros servicios
- Febrero. Impartición de diversos talleres de habilitación en metodologías de PMP, TOGAF, IT4IT, IoT combinado con Lego Serious Play. Aún hay lugares disponibles
- Marzo. Publicación de nuestros métodos de transformación tecnológica utilizando el enfoque arquitectura empresarial.
- Abril. Publicación de aplicaciones móviles de Innbit en iTunes y PlayStore
- Mayo. Evento de innovación en nuestras instalaciones con el objetivo de identificar proyectos de emprendimiento
- Junio y Julio. Eventos tipo hackaton para desarrollo de soluciones basadas en nube, aplicaciones móviles, ciencia de datos, IoT
- Agosto. Lanzamiento de nuestro cuarto de innovación, un lugar donde demostraremos la combinación de IoT, nube, ciencia de datos, redes sociales
- Septiembre. Segundo evento de innovación en nuestras instalaciones
- Octubre. Lanzamiento de reclutamiento para la primera generación de becarios Innbit
- Noviembre. Lanzamiento de productos de innovación de Innbit
En la historia de Innbit nos hemos dado cuenta que nuestro modelo de innovación consiste en tomar necesidades o problemas que aparecen en las organizaciones que quieren utilizar la tecnología de información para solventar problemas de negocio pero dando un enfoque hacia el resultado. Esto nos ha llevado a combinar conceptos que al principio parecían dispares.
Tenemos en este 2017 en seguir ese enfoque de innovación pero hacia llegar ya a los sectores de la industria mexicana y explorar nuevos modelos de negocio. Parte del desafío es que en México logremos generar una industria para ofrecer trabajo a los mexicanos y disminuir la dependencia de la inversión extranjera.
Suscribirse a:
Entradas (Atom)