Guía de pros y contras del cloud-hosted vs. el cloud-based

Las aplicaciones cloud forman parte de nuestro día a día: Gmail, Slack, Salesforce… Según una encuesta reciente de CIMdata, casi el 80% de los fabricantes ya utilizan servicios basados en la nube. Aunque ERP y CRM son las soluciones empresariales más comunes en la nube, Cloud PLM está empezando a ser cada vez más frecuente.

Hoy en día, la mayoría de los PLM vendors se han subido al carro a la hora de ofrecer soluciones PLM cloud. Todos reconocen las ventajas innegables de las soluciones basadas en la nube: mayor escalabilidad, simplificación de la implementación, ahorro de costes al eliminar los gastos del departamento de IT y posibilidad de proporcionar un atajo hacia el ROI.

Teniendo este nuevo paradigma en cuenta, si estás considerando adoptar una solución PLM cloud, es necesario conocer las diferentes terminologías cloud que existen.

Es cierto que todas las soluciones cloud tienen en común que están disponibles en Internet y que ofrecen un modelo de suscripción, sin embargo existen diferencias notables entre ellas. Comprender cuáles son estas diferencias, te ayudará a tomar una mejor decisión de compra acorde a tus necesidades y el presupuesto del que disponga tu empresa.

En primer lugar, hay dos diferencias principales en el panorama del PLM cloud que debes comprender, y es esta la tarea que nos atañe hoy: Cloud-Hosted PLM y Cloud-Based PLM.

¿A qué nos referimos con Cloud-Hosted de PLM?

Básicamente, un PLM alojado en la nube (cloud-hosted) es una aplicación de software preexistente que se instala en un data centre en la nube, administrado por el proveedor en nombre del cliente. El proveedor proporciona su infraestructura como servicio (IaaS).

Este modelo de cloud sigue una arquitectura de arrendamiento única (single tenancy). Esto significa que una sola versión del software y la infraestructura de soporte sirven para un solo cliente. Cada cliente tiene su propia base de datos e instancia de software independiente.

¿Qué es el Cloud-Based de PLM?

La solución basada en la nube (cloud-based) significa que los proveedores han creado la aplicación PLM directamente en la nube, comenzando desde cero y utilizando una aplicación de software para abordar el servicio (SaaS). El modelo, los servidores, las bases de datos y el código que forman parte del software también son administrados y alojados por los proveedores de software (vendors).

En la solución cloud-hosted, los proveedores de software igualmente alojan los servidores, las bases de datos y el código que forman parte del software. En este modelo cada cliente comparte la aplicación de software, una única base de datos (single database) y los servidores. Sin embargo, los datos de cada cliente están aislados y se mantienen invisibles para otros clientes.

Una analogía que se usa a menudo para explicar la diferencia entre la arquitectura individual y la de múltiples inquilinos (single tenant vs multi tenant) es la del mercado inmobiliario. La primera opción propone alquilar tu casa en una calle compartida por otras casas privadas. La segunda, alquilar un apartamento en un edificio donde otras personas alquilan otros apartamentos. En esta última opción, los inquilinos pueden compartir el coste de mantenimiento, lo que lo hace más asequible.

Si deseas saber más sobre la diferencia entre el single tenant y el multi tenant hosting, puedes consultar este artículo.

En definitiva, ¿qué significa todo esto para tu empresa? En la siguiente tabla, resumimos cómo la elección de un modelo u otro afectará a la organización.

¿Cuál es la solución ideal para ti?

Como puedes ver, existen beneficios y desventajas para los sistemas single tenant y multi tenant. En última instancia, debe ser la empresa la responsable de tomar la decisión y decidir qué es lo más importante para su negocio y qué puede sacrificar.

La elección de la solución Cloud ideal dependerá de una variedad de factores: ¿Cuál es el coste derivado del primary driver(controlador principal)? ¿Es la seguridad un factor crítico para el tipo de datos que se están almacenando? ¿Tu solución PLM necesita mucha personalización? ¿Estás contento con el uso de un sistema de talla única? ¿Tu industria o país tiene restricciones regulatorias?

Si deseas saber qué solución PLM en la nube tiene una arquitectura single tenant o multi tenant, estate muy atento/a. Pronto publicaremos otro artículo para sumergirnos aún más en las soluciones cloud para PLM.

Las 8 cosas que aprendimos trabajando en remoto

Los que sabemos lo que es, somos conscientes de que trabajar en remoto supone un reto para cualquier organización. Y más aún si como en nuestro caso, la creación de la empresa se desarrolla de este modo, sin una experiencia de trabajo tradicional previa. Cada miembro de nuestro equipo vive y trabaja en una ciudad diferente, y los nuevos integrantes reciben la formación inicial de manera online.Trabajar en remoto es un reto, pero lo cierto es que si consigues que funcione, la productividad aumenta de manera exponencial. ¿Cómo hemos logrado convertir un aparente obstáculo en un ventaja? En el siguiente blogpost explicaremos el por qué del trabajo remoto en nuestra organización, y cómo esta circunstancia nos ha ayudado a obtener una estructura de trabajo perfectamente definida.

La era del trabajo en remoto

En un mundo tan interconectado como el nuestro, cada vez más empresas ven con buenos ojos la incorporación del trabajo remoto a sus plantillas. Este hecho, es todavía mucho más relevante si trabajas en el sector del PLM. Los que sabemos cómo funciona este mundo igualmente conocemos la dificultad que existe a día de hoy para la captación de talento. A veces das con el perfil adecuado pero vive a miles de kilómetros de tu oficina, y entonces el trabajo en remoto se convierte en la única posibilidad. Igualmente es frecuente la subcontratación de servicios como desarrolladores – por ejemploen países como India o Europa del este – o el contacto con clientes y proveedores de software que se encuentran lejos de nuestras fronteras. Estas cuestiones convierten la elección del trabajo remoto en una realidad mucho más cercana en nuestro sector que en otros.

Siguiendo esta línea, existe un dilema habitual: la comodidad de trabajar desde casa frente a la incomodidad de no tener al alcance los elementos disponibles en una oficina. Eso por no hablar de la percepción que todavía existe en muchas empresas de que permitir a sus trabajadores desarrollar su trabajo desde casa provocará una bajada en el rendimiento. El empresario en ocasiones teme que esta concesión de libertad se traduzca en pérdida de efectividad y de dinero. No obstante, la realidad es muy diferente y está comprobado que trabajar en remoto no solo trae efectos positivos para el activo humano de una empresa, si no también para sus cuentas.

¿Por qué trabajar en remoto?

Trabajar desde casa no es solo poder sentarte con el pantalón del pijama a responder emails. No es solo poder gestionar tus descansos de la manera que mejor se adapten a tu estilo de vida. No es solo picar entre horas o poder recoger los paquetes de Amazon. Es mucho más. El trabajo en remoto transforma la vida de las personas, haciéndolas dueñas de su propio tiempo. En nuestro caso, existe una flexibilidad total a la hora de distribuir las horas de trabajo siempre que sumen 40 horas a la semana. Si eres de los que prefieren madrugar, madrugas. Si durante las noches te sientes más inspirado para trabajar, puedes hacerlo. Por supuesto siempre respetando los horarios de las reuniones de equipo, sin las cuales todo lo anterior sería imposible.

Además el trabajo en remoto te permite algo que no se puede pagar con dinero:trabajar desde donde te de la gana. Mientras que cumplas con tu obligación de horas diarias de manera responsable, da igual que lo hagas desde tu piso en Frankfurt, una cabaña en Bali o el campo base del Everest.

El disponer de esta libertad de tiempo y espacio de trabajo se traduce en una completa mejora de la conciliación laboral y esto a su vez en empleados mucho más felices y más motivados.

Las claves del trabajo en remoto

Por tanto, si todo son ventajas ¿Por qué todavía existen muchas empresas que no confían en el trabajo remoto y siguen ancladas en viejos dogmas con horarios “mata-personas” de 9 a 7 de la tarde? Muy sencillo, porque no saben hacerlo. Para que un cambio de estas características funcione hay que hacer una correcta transición. Si con tus viejos métodos de trabajo decides de un día para otro que tus empleados van a trabajar en remoto, es posible que tu idea fracase.

Sin embargo, si te informas sobre qué funciona en otras empresas y cómo se está haciendo y anticipas estos cambios, terminará convirtiéndose en la mejor decisión que has tomado a nivel laboral. Tus empleados estarán más contentos, más implicados, su productividad crecerá y encima ahorrarás dinero.

A continuación te detallamos las 8 cosas que debes tener en cuenta sí o sí, si quieres adoptar el trabajo remoto en tu organización y que este sea un completo éxito.

1. Planificación del día

Punto vital y a mi juicio igual de importante trabajes desde casa o no. Clasificar tus tareas de más a menos importantes para poder darles más o menos prioridad es clave. Trabajamos con 3 tipos de tareas: Must, Intend y Like. Cada día cada miembro del equipo tiene planificadas una tarea Must, otra Intend y otra Like. La tarea Must es la tarea más importante, lo que significa que el no completarla habrá significado que tu día ha sido poco productivo. Si finalizas tu tarea Must pasas a tu tarea Intend, segunda en orden de prioridad. Y solo si finalizas esta pasas a Like, la menos relevante de todas.

2. Herramientas de gestión de tareas

En nuestro caso empleamos Asana como una parte fundamental de nuestro día a día. Asana es un software que facilita la planificación, la gestión y el seguimiento de las tareas de cada miembro del equipo. Gracias a esto, podemos tener acceso a los calendarios de tareas del resto de compañeros, agregarles y quitarles tareas, clasificarlas por proyectos… Otro punto clave es que contiene fechas tope que añadir a las tareas, lo cual facilita mucho la organización. Además es visualmente muy atractivo y fácil de usar. Sin duda, un imprescindible si trabajas en remoto.

3. Documentación de Procesos

Esta parte es fundamental cuando no tienes oficinas físicas y todo el trabajo se desarrolla en remoto. Los métodos de trabajo más importantes del día a día de cada persona deben quedar perfectamente documentados. Con esto facilitamos las nuevas incorporaciones al equipo y permitimos que el resto de compañeros puedan ayudarnos con mayor facilidad en cualquiera de nuestras tareas. Toda esta información debe estar volcada sobre una intranet a la que todos los miembros tengan acceso y puedan hacer búsquedas de todo tipo. Un ejemplo de esto sería, si un compañero se va de vacaciones y otro tiene que encargarse de una de sus funciones, puede acceder a la intranet para informarse sobre cómo se desarrolla la tarea exactamente.

4. Comunicación fluida

Cuando trabajas desde casa y llevas a cabo proyectos en común con otras personas, es fundamental la existencia de una comunicación fluida entre las partes. Para facilitar esto, existen herramientas como Slack que permite crear grupos a los que los diferentes miembros del equipo pueden acceder y comunicarse como si estuvieran en la misma oficina. Con Slack se pueden abrir conversaciones, preguntar y resolver dudas. Además se puede sincronizar con Asana para asignar a las conversaciones tareas específicas. El correo electrónico es la opción de la mayor parte de la gente, pero sin duda no es la más efectiva si trabajas en remoto. El empleo del tándem Asana-Slack te permite una comunicación total con tu equipo en la que no se echa de menos la oficina.

5. Reuniones semanales

Por supuesto, clave para mantener un contacto de todos los miembros de la organización. En estas reuniones se pone al día al resto del equipo del estado de las tareas que se tienen asignadas. Además se debaten estrategias futuras y se ponen en común los temas más importantes del momento. En Share PLM todos los martes y los viernes tenemos una reunión de estas características.

6. Contabilizar el tiempo

Cuando trabajas en una oficina y sabes que tienes que cumplir un horario estricto, no eres consciente del tiempo real que tardas en finalizar una tarea en concreto. En tu mente está solo la llegada del fin de la jornada para poder irte a tu casa. Cuando trabajas en casa y tienes una flexibilidad total, este hecho cambia. A veces es importante a la hora de planificar nuestro trabajo el saber cuántas horas tardamos en realizar determinadas tareas. Para ello, usamos Toggl, un contador de tiempo que se descarga directamente en la barra del navegador y que al igual que pasa con Slack, se puede sincronizar con Asana. Antes de iniciar cualquier tarea simplemente haces click en el botón para que comience a contabilizar el tiempo. Cuando acabe vuelves a hacer click para finalizar. Toggl nos ofrece una vista muy rápida sobre cuáles son las tareas a las que dedicamos más horas y cuáles a las que menos.

7. Café virtual

Como empresa con gran experiencia en el trabajo remoto, una de las cosas que más nos cuesta es tener lejos a nuestros compañeros. Y no hablamos solo de por las cuestiones de trabajo, si no por las personales. A veces trabajar tantas horas solo en casa se hace duro y echamos de menos las charlas de los lunes donde te cuentas el fin de semana, las pausas del café… Los momentos en los que podemos socializar y no solo centrarnos en el trabajo. En nuestro caso, todos los días realizamos una reunión que llamamos café virtual y a la que se puede asistir de manera opcional. Es siempre a primera hora de la mañana, y en ella charlamos durante unos 15 minutos acerca de todo tipo de temas fuera del trabajo. Es una excelente oportunidad para conocer un poco más al equipo cuando no tienes contacto físico diario.

8. Quedadas en persona

Si se puede, organizar una tema meeting a la que acuda todo el equipo de manera presencial puede ser una idea magnífica. En nuestro caso, solemos vernos 3 veces al año, y cada vez en una ciudad distinta (normalmente donde vive alguno de los miembros). El equipo pasa 2 o 3 días compartiendo puntos de vista, poniendo en común anécdotas de su día a día, y desarrollando una estrategia a seguir. El resultado es siempre muy positivo, haciendo que los trabajadores desarrollen lazos más fuertes. Sobre todo cuando al final del día, siempre cae alguna cerveza!

¿Y tú? ¿Trabajas en remoto? ¡Cuéntanos que soléis hacer tú y tu equipo para facilitar los procesos de trabajo!

¿Qué es el Blockchain, y por qué es importante para el PLM?

PLM Blockchain

Blockchain y Bitcoin, dos palabras de moda que están en boca de todos. Las hemos incorporado en nuestro lenguaje diario hasta el punto de que, si a estas alturas todavía no sabes lo que significan y quieres continuar manteniendo conversaciones sin miedo a parecer de otra época, ya estás tardando en ponerte al día.

Lo sé. Es probable que te suenen de aquella última conferencia a la que asististe, o se la hayas escuchado a aquel compañero de trabajo en la máquina de café. O quizás simplemente recuerdas haberlas leído en el periódico. Sea como sea, seguro que te sientes igual que nosotros ante su presencia: confundido y expectante por lo que esconde esta nueva tecnología “oscura y secreta” que parece haber llegado a nuestras vidas para quedarse.

Si queremos buscar una definición sencilla de lo que es Blockchain, podríamos decir que su función es la de trabajar como un “libro público” compartido del que dependen las criptomonedas como Bitcoin. Pero, si Blockchain es básicamente solo la tecnología subyacente a Bitcoin ¿por qué la gente está tan entusiasmada con el tema?

Porque en el fondo,Blockchain es mucho más que eso. La esfera PLM de las empresas está empezando a reconocer en el Blockchain la evolución a su manera de administrar los productos y sus flujos de información.

Blockchain posiciona al producto en el centro de la estructura de datos. Permite a las organizaciones que, aun teniendo diferentes modelos de datos, puedan colaborar entre ellas a lo largo de todo el ciclo de vida del producto. Y además de dicha colaboración, permite realizar auditorías y seguimientos manteniendo un hilo de datos no modificable.

Desenredando los hilos del Blockchain

En esencia, el Blockchain es una nueva forma de almacenar y administrar datos.Una manera más ilustrativa de entender esto es pensar en el  Blockchaincomo si fuese una base de datos que se puede utilizar para almacenar y compartir registros o datos de valor. La diferencia reside en que no es como una base de datos tradicionaldonde la información se almacena en una ubicación central.

Las bases de datos de Blockchain no se almacenan en una sola ubicación como sucede por ejemplo en un banco o usando una base de datos ubicada en la nube. La información generada con Blockchainse mantiene en los equipos individuales de las personas que utilizan dicha base de datos. Por eso, el Blockchain se describe habitualmente como un “libro de contabilidad”de datos distribuido y descentralizado.

Este «libro de contabilidad» es utilizado para realizar el seguimiento del intercambio de datos. En Blockchain, las transacciones de datos se empaquetan en bloques. Un «bloque» es un grupo de transacciones que se validan al mismo tiempo. Seguidamente, cada bloque se «encadena» al siguiente bloque, en orden lineal y cronológico, utilizando la criptografía. La criptografía es la base subyacente de la cadena de bloques. Se utiliza para firmar transacciones, autorizar los intercambios de valory mucho más.

El Blockchain permite a los consumidores y proveedores comercializar sin intermediarios, conectarse directamente y eliminar la necesidad de depender de un tercero.

Anatomía de blockchain

Cada blockchain se compone de una serie de bloques que contienen a su vez transacciones correctamente validadas.

Adentrémonos un poco más en cada uno de los componentes principales del Blockchain:

1. Las transacciones

Una transacción comercial es una transferencia valor, como por ejemplo, una transferencia de bienes, de dinero o de servicios entre dos partes. Cada transacción implica:

  • Un activo digital: La información vertida en un Blockchainpuede ser sobre cualquier cosa. Desde dinero, acciones o identidades,¡hasta inclusobienes digitales comoel arte o la música!
  • Remitente:Es la persona que desea enviar un activo digital. Para iniciar una transacción, el remitente sólo necesita saber la dirección de la persona a la que desea enviar la transferencia.

Receptor: La persona que recibe el activo digital.  Es necesario compartir la dirección Blockchain con el remitente cada vez que se vaya a realizar una transacción.

Autenticación de una transacción

Cada transacción debe ser verificada antes de que se le permita entrar en el Blockchain.

A menudo, el proceso de verificación se realiza mediante dos claves, una clave pública y una clave privada. Todo el mundo podrá ver la clave pública pero la clave privada es secreta.

Par de claves públicas y privadas

A ver cómo explicamos esto.

Blockchain utiliza PKI para autenticar las transacciones. Cada usuario deBlockchain tiene un par de clavesprivadas y públicas. Estas claves sirven para cifrar y/o firmar los datos. Las claves privadas están matemáticamente relacionadas con las claves públicas. Sin embargo, es imposible extraer una clave privada de una clave pública gracias al sólido código cifrado que dispone la clave privada.

Para comprender mejor cómo funcionan los pares de claves, vamosa imaginar que tenemos un buzón de correo. La clave pública es la dirección del buzón de correo. Una persona puede insertar cartas en el buzón, pero no puede recuperarlas.Debe usar su clave privada para abrir el buzón y recuperar las mismas.

Cifrar y descifrar es como bloquear y desbloquear el buzón de correo. Si alguien cifra («bloquea») una transacción de datos con su clave pública, solo usted puede descifrarla («desbloquearla») con su clave privada. Si cifra («bloquea») una transacción con su clave privada, cualquiera puede descifrarla («desbloquearla»). Esta acción es similar a una «firma digital».

En el mundo digital, podemos entender las clavescomo cadenas de texto con muchos dígitos. Puedes generar tus propias claves públicas y privadas utilizando esta herramienta online.

Una firma digital criptográfica

Las transacciones son autenticadas con firmas digitales. Una firma digital se crea con una función que depende tanto de la propia transacción como de la clave privada.

Puesto que la firma digital se crea conla clave privada personal, nadie puede generarla excepto tú. Además, al usar también datos de transacción para crear la firma, se garantiza que esta no pueda ser copiada.

Siempre que desees recibir una transacción, compartirástu clave pública con el remitente. El remitente bloquea el mensaje con su firma y su clave pública y a continuación, le envía la transacción. Por último, deberás comprobar la transacción con tu clave privada.

2. Los bloques

Como hemos visto, las transacciones en blockchain se almacenan en estructuras fijas llamadas «bloques».Las partes importantes de un bloque son:

  • Contenido:contiene una lista validada de transacciones.
  • Encabezado: contiene metadatos clave sobre un bloque. Hay cuatro conjuntos de metadatos en un encabezado:

– Un identificador de bloque: Para identificar un bloque utilizamos firmas digitales que se generan mediantefunciones hash criptográficas. ¿Pero qué son las funciones hash criptográficas?

Una función hash criptográfica es una especie de ‘firma’ para un archivo de texto o de datos. Una función hash es una función que convierte datos de cualquier tamaño en una cadena de datos de tamaño fijo.

Si la entrada es un solo número, un texto o un archivo digital, el hash resultante siempre generará una cadena de datos del mismo tamaño.

Convertir una cadena en una firma se denomina hash. La función “Hashing” tiene una particularidad: sólo va en una dirección.No puedescogerel hash resultante de longitud fija y volver a recrear la cadena. Las cadenas de bloques suelen utilizar una función hash SHA-256, la cual que genera una firma casi única de 256 bits (32 bytes).

Esta herramienta online de hash te permitirá generar el hash SHA256 para cualquier cadena de datos:

-El hash delbloque anterior: cada bloque incluye unvínculo del bloque anterior. Esta es la manera a través de la cual podemos acceder a todos los bloques anteriores en un Blockchain: están vinculados entre si y la base de datos conserva el historial completo de transacciones.

– Una raíz (Árbol Merkle): es una estructura de datos que condensa todas las transacciones del bloque. Un árbol Merkle se construye mediante pares de transacciones y hashes hasta que genere un solo hash.

El nodo en la parte superior del árbol de Merkle se llama raíz. Para llegar a una raíz de Merkle comenzaremos desde abajo. Para ello recopilaremos las transacciones mediante un algoritmo hash. Más tarde emparejamos esos hashes, los concatenamos y los generamos de nuevo. Y así sucesivamente hasta que nos quede un solo hash.

– Pruebas: Los bloques válidos contienen la respuesta a un problema matemático complejo creadosa partir de unafunción hash criptográficainmutable. La única manera de resolver este problema matemático es adivinar los números aleatorios que contiene cada bloque. De todas formas, no te apures. Exploraremos cómo funcionanestas pruebas un poco más adelante.

Si deseas explorar el contenido de un bloquepor ti mismo, echa un vistazo a uno de los bloques de la blockchain.info

3. La cadena de bloques o Blockchain

Todas las transacciones y bloques validados se incluyen en el Blockchain. Para confirmar los bloques que quedan pendientes, las cadenas de bloques utilizan un proceso llamado “mining” o minería.El Mining evita que se modifiquen los bloques anteriores, protege la neutralidad de la red y garantiza el consenso entre bloques.

Ahora vamos a explorar los principales actores que intervienen en el proceso de mining.

  • Los Miners o mineros: las solicitudes de transacción se envían a todos los equipos de la red para que puedan ser validadas. Estos ordenadores son llamados Miners. Los Miners validan nuevas transacciones y las registran en el Blockchain.

Para validar las transacciones, se debe resolver un complejo problema matemático basado en un algoritmo hash criptográfico. Este problema sólo se puede resolver adivinando los números. Cada miner en la red competirá para adivinar la solución al mismo.

  • La prueba de trabajo: La solución a este problema matemático se llama prueba del trabajo. Cuando se ‘resuelve’ un bloque, las transacciones contenidas en el bloque se consideran confirmadas.

El primer miner en resolver este problema matemático recibe una recompensa. Esto sucede porque el proceso de mininig que utiliza para averiguar estos números consume una gran cantidad de energía y electricidad de los equipos informáticos empleados para ello.

Intercambio de valor con blockchain

Imagina que has creado una API de PLM que recopila y envía datos de los sistemas CRM, ERP y PDM y quieres obtener la licencia y vender esta aplicación en el «mercado PLM» utilizando Blockchain. ¿Cómo hacerlo? Utilizando lo que se denomina Token.

Un token sirve para identificar digitalmente la API de PLM que has creado. Este token se almacena en un Blockchain y contiene un vínculo a la API de PLM, a su vez almacenado en algún lugar de la nube.

Todos los miembros del Blockchain pertenecientes al mercado PLM deben confirmar que la API les pertenece y que tiene licencia oficial. Si quiero comprar la API, firmo la transacción con el token de la API con la clave pública y la clave privada. Una vez que la red valida la transacción, se agrega a un bloque almacenado en la cadena de bloques, y la licencia de la API de PLM pasa a ser de tu pertenencia. Ahora puedes usarla libremente.Si alguien quiere comprobar la autenticidad de la licencia, puede volver al Blockchain y auditar la transacción.

PLM y blockchain: ¿qué nos depara el futuro?

Todavía es pronto para hablar de este asunto, pero el blockchain puede desempeñar un papel importante en el mundo PLM.Tiene la capacidad de facilitar las integraciones, simplificar las migraciones, permitir la colaboración y proporcionar un registro preciso de datos del «quién, qué, dónde y cuándo» durante todo el ciclo de vida de producto.

Además, promete conectar a las empresas cuyas aplicaciones, modelos de datos, sistemas de numeración de piezas y codificación son diferentes. El Blockchain pone al producto en el corazón de los sistemas y les permite centrarse exclusivamente en los datos que quieran compartir.

Otras oportunidades(la protección de los derechos de autor, la fabricación acumulativa, la gestión de suministros, la gestión de datos de IoT e incluso la sostenibilidad) se encuentran en el horizonte.

Aunque los proveedores de PLM actualmente no ofrecen aún nada fuera de sus sistemas y plataformas, muchas empresas, como Maersk,Toyota o Walmart están explorando diferentes formas de utilizar Blockchain en sus productos. Sin embargo, es probable que pase algún tiempo antesde que esta tecnología llegue a producción.

La tecnología aún está en pañales: la falta de estándares, la escalabilidad, la incompatibilidad entre diferentes cadenas de bloques,y la cantidad incalculable de recursos informáticos y energía utilizada a través del proceso de mining, son sólo algunos de los desafíos que Blockchain necesita alcanzar antes de convertirse en una tecnología de uso común.

PLM y APIs: ¿una relación con futuro?

API PLM

¿Qué es una API?

Pedir la cena desde el sofá de casa con tu tablet. Monitorizar tu actividad física diaria con una aplicación en tu smartphone. Reservar un asiento para la película que quieres ver esta noche en el cine. Todo esto sería imposible en un mundo sin API’s

Las APIs hacen posibles innumerables situaciones de nuestro día a día, y están detrás de gran parte de nuestra actividad online. Conectan negocios, aplicaciones, datos y dispositivos para que acciones como pedir una pizza, escuchar música mientras corres o comprar entradas para el cine con solo un clic, ya formen parte de nuestra realidad cotidiana.

Las siglas de API significanliteralmente Application Programming Interface (Interfaz de Programación de Aplicaciones). Las APIs permiten que las aplicaciones se comuniquen entre sí e intercambien información. Técnicamente hablando, son bloques de programas que facilitan el desarrollo y configuran las rutinas, protocolos y herramientas necesarias para interactuar con una aplicación.

¿Cómo funcionan las APIs?

Las APIs trabajan como bloques de construcción digitales que se unen para proporcionar una amplia variedad de características y funciones. Hay miles de APIs públicas que se pueden usar para hacer de todo, desde verificar una ubicación y recopilar información de redes sociales hasta autentificar usuarios.

Las empresas modernas no crean aplicaciones desde cero. Escogen y eligen entre las APIs disponibles para acelerar el proceso de desarrollo, mantener una arquitectura robusta y ofrecer la mejor experiencia al cliente.

Veamos un ejemplo para comprender cómo las empresas combinan las API para crear APPS.

Imagina que quieres crear una aplicación dentro del mundo de la hostelería que ayude a los usuarios a encontrar hoteles disponibles en su ubicación. El usuario selecciona dónde quiere quedarse y cuándo, y la aplicación proporciona una lista de hoteles disponibles en ese radio. Después, puede usar la aplicación para seleccionar y reservar la habitación que prefiera.

Pero ¿cómo construir esta aplicación usando APIs?

Una combinación básica de mapeo, calendario, autenticación y API de pago, serían los ingredientes principales:

La API de mapeo determina qué hoteles están cerca, mientras que la API de autenticación permite a los clientes leales iniciar sesión fácilmente y reservar una habitación rápidamente. El calendario API verifica la disponibilidad de habitaciones y las tarifas. Y finalmente, la API de pago permite a los usuarios reservar una habitación y liquidar su factura.

Comprender las API REST

REST significa Representational State Transfer y se refiere a un estilo arquitectónico que utiliza métodos HTTP y tecnologías web estandarizadas. Una API REST es un sistema donde los clientes usan una interfaz definida para interactuar con un servidor web a través del protocolo HTTP.

Existen otros tipos de API, como el Simple Object Access Protocol (Protocolo simple de acceso a objetos o SOAP) o Remote Procedure Call (Llamada a procedimiento remoto o RPC), pero REST ha alcanzado una gran popularidad en los últimos años. Esto se debe principalmente a que REST funciona bien, es altamente escalable, y además es fácilmente modificable y ampliable.

Para tener una idea de qué es una API REST y cómo funciona, pongamos un ejemplo. Imagina un café, un cajero y un cliente que quiera comprar un capuchino.

Así es como funciona nuestro café:

Cuando el cliente envía una solicitud (en este caso para obtener un capuchino), la API REST la recibe, identifica el recurso solicitado, atiende el recurso y lo manda de vuelta al cliente.

Anatomía de una API REST

Ahora que tenemos una ligera idea de cómo funciona una API REST, avancemos para analizar más de cerca sus componentes principales.

El cliente – Client

Los clientes son los consumidores de APIs. Pueden ser aplicaciones móviles, navegadores web o dispositivos IoT integrados.

La Solicitud - Request

Una solicitud REST tiene dos partes esenciales: un method y una URI+ body. En algunos casos, se pueden enviar headers (encabezados) para especificar la información sobre la solicitud. Si la solicitud está destinada a escribir nueva información en el sistema, se utiliza elbody para transmitirla.

El header principalmente permite a los usuarios acceder a un recurso. Los headerstambién se usan para establecer el formato de idioma y las preferencias de compresión.

El method es uno de los operadores HTTP estándar, y el URI apunta al recurso con el que desea interactuar. Las API RESTful usan métodos HTTP estándar para realizar cuatro operaciones esenciales:

  • GET – ver
  • POST – crear
  • PUT – editar
  • BORRAR – borrar

La URL es el identificador único para el recurso. Es como cualquier otra URL en internet, excepto que en este caso que se usa para describir el recurso en una aplicación.

Finalmente, la sección del body solo se envía para las transacciones de creación (POST) y actualización (PUT).

API

La APIs es la puerta de entrada al servidor donde se encuentran los recursos. Proporciona acceso a los recursos que la empresa quiere compartir. Una API bien diseñada define lo que puede proporcionar y cómo usarlo en un «contrato tipo». Los methods disponibles, los parámetros de consulta, el formato de respuesta, las limitaciones de la solicitud, el soporte de idiomas, etc. deben formar parte de ese contrato.

Las APIs también actúan como guardaespaldas de los recursos expuestos. Existen tres medidas de seguridad principales que utilizan la mayoría de las APIs: identificación, autenticación y autorización. Las claves API son códigos únicos que generalmente se utilizan para autentificar a los usuarios y administrar el acceso.

Bienes - Assets

Los recursos pueden ser data points, programas o servicios que una empresa posee y desea exponer. Son el pan y la mantequilla de cualquier API. El objetivo final de cualquier API es compartir activos o recursos. Los activos pueden ser cualquier cosa que una empresa quiera compartir, ya sean datos, servicios o ideas.

Respuesta - Response

Cada respuesta regresa del servidor con un status code (código de estado) que indica el éxito o el fracaso de la acción solicitada.

Las respuestas en las API REST suelen usar la notación de objetos JavaScript (JavaScript Object Notation- JSON). El formato JSON es compacto y fácil de transmitir en redes que trabajan lentas.

Volvamos a nuestro café para ver estos componentes API en acción. El cliente ordena un capuchino y el cajero crea un nuevo artículo: una orden. El cliente desea agregar azúcar extra a su pedido, por lo que el cajero lo actualiza. Cuando el cliente le pide al cajero que le diga el total, el cajero lee el pedido. De repente, el cliente se da cuenta de que se ha dejado la cartera en casa, por lo que cancela el pedido. Finalmente, el cajero elimina el artículo.

APIs en acción

Para comprender mejor cómo funcionan las APIs, veamos cómo trabaja una API en acción. Para ello utilizaremos una herramienta de administración de APIs llamada Apigee con la que visualizaremos las solicitudes y respuestas a estos ejemplos. Apigee es una plataforma que proporciona herramientas de diseño, administración y soporte de APIs.

Comencemos con una simple llamada a la API de Google. En este primer ejemplo, queremos desenterrar las coordenadas GPS de nuestra querida Madrid.

Method: GET – este es el método de lectura en HTTP.

URL: http://maps.googleapis.com/maps/api/geocode/json?address=Madrid – la URL apunta a la ubicación del recurso. Para los métodos GET, puede intentar escribir la URL en el navegador.

Body: ninguno – una solicitud GET no necesita un cuerpo (body), porque solo estamos leyendo un recurso del servidor.

Al enviar la solicitud anterior al servidor de Google Maps, obtendremos la latitud y longitud de Madrid:

Avancemos ahora y usemos la API de Twitter para enviar un tweet.

Primero, necesitamos autenticarnos con nuestra cuenta de Twitter para que sepa que la solicitud proviene de nosotros. Luego seleccionamos el método de actualización de estado POST de la API de Twitter y establecemos los parámetros.

Estoy enviando «Test tweet from Share PLM» desde Madrid, utilizando la latitud y la longitud como parámetros de entrada que recopilamos de la API de Google Maps. Continuamos y hacemos clic en enviar, y verificamos que el tweet se haya publicado correctamente.

En la respuesta, también obtenemos metadatos como id o estado sobre el tweet que acabamos de crear.

Luego podríamos continuar y eliminar el tweet que acabamos de crear usando el método «destruir» de la API de Twitter.

Como puedes ver, hay muchas APIs a las que podemos acceder y con las que entretenernos. La idea final es combinar varias APIs para crear aplicaciones y consumir datos de manera sencilla.

¿Se atreverá el PLM a saltar al mundo API?

Las APIs se han convertido en el sistema operativo de las empresas digitales, conectando sistemas y aplicaciones previamente aislados. Diseñadas para ser flexibles, ágiles y escalables, las APIs proporcionan una manera eficiente de construir los servicios digitales que los consumidores de hoy necesitan.

La economía API también tiene el potencial de transformar el escenario del PLM.

Las empresas pueden exponer sus servicios e información de productos a sus clientes. Pero también, internamente, pueden conectar aplicaciones y compartir datos centrales del sistema a través de las APIs. Por ejemplo, es posible desear crear aplicaciones internas que accedan a sistemas centrales para informes, inteligencia empresarial o visualización.

Los proveedores de software PLM pueden permitir que las empresas y los socios se conecten directamente a sus sistemas, facilitando las integraciones y exponiendo información y funcionalidad. Las API PLM pueden estar potencialmente abiertas para desarrolladores internos, partners o desarrolladores externos. Productos como Propel PLM, OnShape, Fusion 360, OpenBOM o Aras ya avanzan en esta dirección.

Incluso podría quedar un trozo del pastel para las startups dentro de la economía API… ¿Qué tal una forma completamente nueva de implementar PLM con APIs flexibles ondemand?

Bimodal PLM o cómo seguir el ritmo a la digitalización

Bimodal PLM

La necesidad por mantener el ritmo a la evolución digital ya ha impactado en el ámbito del PLM. Este hecho ha traído consigo una fuerte competencia que desafía las aplicaciones tradicionales de PLM y los métodos de gestión de proyectos.

En sistemas tradicionales, los datos del producto normalmente son gestionados“al por mayor”, con innumerables procesos que requieren del desarrollo de metodologías de testeo rigurosas. La realidad de estos sistemas es que no son capaces de adaptarse al ritmo del cambio de la tecnología y las necesidades de los clientes.

Esta falta de aplicaciones y procesos flexibles y versátiles, ha empujado a las organizaciones a buscar agilidad mediante “IT-Bimodal”.

El alza del IT-Bimodal

El término “IT-Bimodal” fue acuñado en 2014 por Gartner quien lo define como:

“… la práctica de gestionar dos modos independientes y coherentes de proveer IT, uno enfocado en la estabilidad y otro en la agilidad. El modo 1 es tradicional y secuencial, enfatizando la seguridad y la precisión. El Modo 2 es exploratorio y no lineal, primando la agilidad y la velocidad de entrega. El IT Bimodal es la única solución sostenible para los negocios en un mundo digital cada vez más disruptivo”

Bimodal PLM

Cuando hablamos de Bimodal, nos referimos a la práctica de gestionar dos modalidades de entrega distintos pero a la vez congruentes:

  • Modo 1, con enfoque en la predictibilidad; su objetivo primario es mantener el negocio operativo.
  • Modo 2, se concentra en explorar y su objeto es la innovación, experimentación y el aprendizaje.

La Bimodalidad aúna el IT tradicional de una organización (que requiere de cierta estabilidad y cuidado) con la innovación y la agilidad que requieren las competencias digitales de cara al cliente.

Habilitando la experimentación con el Modo 2

El IT Bimodal permite a las organizaciones testear nuevas tecnologías sin poner en riesgo la continuidad del negocio. Para ello se requieren dos equipos distintos con áreas de enfoque y prioridades bien definidas. El equipo del Modo 1 asegura que los sistemas core (centrales) corran de manera efectiva y eficiente, lo que le otorga al equipo del Modo 2 el espacio necesario para trabajar en soluciones innovadoras y centradas en los usuarios, que incrementen el compromiso y aporten valor al negocio.

Los aspectos clave para posibilitar la experimentación a través del Modo 2 son:

Bimodal PLM mode
  1. Experimentación y aprendizaje.

Una organización que impulsa la innovación debe ser capaz de experimentar con nuevas ideas, nuevas características, nuevas experiencias de usuario, nuevos modelos de negocio y nuevas tecnologías; y además incorporar el aprendizaje como un valor fundamental en la cultura deequipo.

  1. Diseño centrado en el cliente.

Enfocado en los resultados del negocio, donde el objetivo es garantizar que se está construyendo el producto correcto, validando continuamente la visión del producto con los usuarios.

  1. Desarrollo Agile y DevOps.

Los pilares del Modo 2 son las metodologías Agile y DevOps, que anticipan la necesidad de colaboración entre desarrollo y operaciones, y basan sus argumentos en la flexibilidad y el pragmatismo en la entrega de un producto.

  1. Aplicaciones Cloud y diseño de infraestructuras.

Las tecnologías cloud permiten flexibilidad en la forma en que las aplicaciones se crean, entregan y administran, y generalmente producen resultados comerciales más rápidamente.

Posibles inconvenientes del salto Bimodal.

Aunque tener un laboratorio de innovación en tu organización de IT siempre parece una idea genial, el enfoque Bimodal presenta varios desafíos.

Disadvantages Bimodal PLM

1. Puede generar un “muro confuso” entre los grupos de IT

Este proceso dual puede romper las comunicaciones y construir un muro entre los diferentes grupos de IT (quienes se ven obligados a competir por financiamiento, recursos y aún más importante, atención).

2. El Modo 1 puede ralentizar al Modo 2

Existe demasiada supeditación entre las soluciones enfocadas en el usuario y los sistemas tradicionales. Normalmente, los proyectos que corren bajo el modo 2 requieren igualmente del desarrollo de sistemas tradicionales. Hacer que los datos y las diversas funcionalidades estén disponibles desde las aplicaciones principales, o crear una solicitud de cambio para los datos maestros son solo dos ejemplos que ilustran la colaboración que se requiere entre el Modo 1 y el Modo 2. El Modo 1 tradicionalmente sigue un ciclo de lanzamiento rígido, cuyos cambios deben ser siempre incluidos en los planos. Por ello es importante organizarse previamente y reservar recursos en los sistemas centrales para que funcionen.

3. Incapacidad para lograr un cambio duradero.

Es fácil centrarse en el desarrollo de tecnologías innovadoras, pero no hay que olvidar que el desarrollo es sólo una parte de la ecuación. Trabajar en un proyecto de principio a fin, desarrollar e implementar procesos y capacitar a la organización es tan importante como crear una nueva herramienta brillante. Por ello, concede la importancia que merece a la gestión del cambio y asegúrate de que todos los usuarios trabajen en la misma dirección.

4. Disminución de la motivación en el equipo de Modo 1

Es bastante probable que los empleados etiqueten inevitablemente el Modo 1 como «más aburrido» y el Modo 2 como «más ameno». De hecho, es posible que algunos no quieran trabajar en el Modo 1 debido a la percepción de que ocuparse de las aplicaciones tradicionales no es tan interesante como construir otras nuevas. Debemos tener cuidado con esto, ya que pensamientos así pueden desencadenarla desmotivación de los miembros del equipo de Modo 1.

Hacia una Multi-Speed IT de principio a fin

¿Es bimodal el camino para ayudar a las empresas a deshacerse del letargo asociado a los sistemas PLM rigurosamente documentados y monolíticos? Los críticos argumentan que pasar por alto procesos y equipos ya establecidos para hacer según qué cosas, podría no ser la mejor manera de abordar la necesidad de velocidad.

Según Forrester Research, la IT bimodal puede proporcionar cierto alivio a los CIOs a corto plazo, pero no es una estrategia para alcanzar el éxito a largo plazo. En un mundo en el que estamos tratando de derribar barreras, construir un muro entre lo «innovador y rápido» y lo «heredado y lento» no es la mejor solución a largo plazo.

En este sentido, aprender de la experiencia de otros es fundamental para una transición correcta. Bill Ruh es el director general de GE Digital, ha dirigido varios proyectos en bimodal y su experiencia le ha hecho llegar a la siguiente conclusión:si una empresa quiere ser verdaderamente digital, reunir todas las capacidades digitales en un solo grupo es la única manera de lograrlo.

Otros abogan por una evolución de la IT bimodal – Multi-speed. El principio básico de Multis-peed IT es permitir que varios canales de entrega soporten las distintas velocidades y plataformas tecnológicas que requiere cada negocio.

Incluso los partidarios de este enfoque piden la coordinación entre los distintos canales de distribución. Identificar y comprender las dependencias arquitectónicas entre distintos proyectos ejecutados por distintos equipos, es esencial para asegurar que la entrega y lanzamiento de cada aplicación esté coordinada.

¿Son los Microservicios el siguiente gran paso en PLM?

PLM Microservices

Con las redes sociales y las tecnologías móviles y cloud como punto de referencia en cuestiones de velocidad, agilidad y facilidad de uso, no es de extrañar que los usuarios esperen un rendimiento y una flexibilidad similares de las plataformas PLM.

Sin embargo, si bien el argumento comercial para adoptar una tecnología más intuitiva y flexible está ampliamente respaldado, la realidad es que con el tiempo los proveedores de software se han ido alejando de este discurso. Este hecho no es otra cosa que la consecuencia derivada de los grandes cambios que las principales arquitecturas de las empresas y los modelos de negocio requieren. Y es que ya se sabe: optar por un cambio radical en plataformas bien establecidas y probadas, comenzando desde cero, es un camino arriesgado.

El riesgo es una parte ineludible de cada estrategia de negocio, y el escenario protagonizado por empleo de cloud y APIs abiertas, ha cambiado radicalmente el juego para la industria PLM. Por eso, aunque los proveedores de software tradicionales no desean que sus aplicaciones sean menos monolíticas, la tecnología y los clientes los están obligando a ello.

MICROSERVICIOS PLM: RECONFIGURAR LA ARQUITECTURA DE SISTEMAS DE LAS EMPRESAS

En los últimos años el cambio en las tecnologías de la arquitectura empresarial ha sido rápido y extenso. Por ejemplo, la gama actual de tecnologías en la nube es más potente y menos costosa que las referidas a la generación anterior. Esto permite a las empresas almacenar, analizar y utilizar datos activamente para tomar decisiones y generar nuevas oportunidades de negocio. Sin embargo, estas nuevas herramientas también son más complejas y, en muchos casos, representan un desafío para los sistemas y plataformas empresariales bien establecidas.

Los microservicios son la gran tendencia en arquitectura y desarrollo de software. Intentan resolver los problemas derivados del aumento en la velocidad y la flexibilidad, y parece que también están apareciendo en el entorno PLM: los gurús de PLM Jos Voskuil y Oleg Shilovitsky discuten en sus entradas de blog “Microservices, Apis, Platforms and PLM services” y  “Will PLM microservices eat PLM dinosaurs”, cómo los microservicios están impulsando el escenario PLM hacia arquitecturas más ágiles y flexibles.

Los microservicios representan un cambio fundamental en la forma en la que las empresas abordan la arquitectura de sistemas y el desarrollo de software. En pocas palabras, los microservicios eliminan la lógica empresarial de las aplicaciones y la sustituyen por módulos de código reutilizables que son completamente independientes de todas las demás partes de las aplicaciones.

Ahora exploremos con mayor detalle qué son los microservicios y cómo pueden afectar a los grandes proveedores de plataformas PLM.

BREVE HISTORIA DE LA ARQUITECTURA DE SISTEMAS

Orígenes de la arquitectura de sistemas de empresa: Aplicaciones monolíticas

Antes de los años 90, las arquitecturas de sistemas eran estrictamente monolíticas. Cuando hablamos de arquitecturas monolíticas, nos referimos a aquellas que consisten en una sola aplicación. Tal y como hemos revisado en «Sistemas de información en PLM«, hay tres componentes principales en las aplicaciones monolíticas: una base de datos, una aplicación del lado del servidor y una interfaz de usuario del lado del cliente. La aplicación del lado del servidor maneja las peticiones HTTP, ejecuta la lógica de negocio, recupera y actualiza los datos de la base de datos y los rellena en el navegador.

En arquitecturas monolíticas, cualquier cambio en el sistema significa que toda la aplicación debe ser chequeada desde el sistema de control de versiones.La versión debe ser actualizada y toda la aplicación implementada de nuevo.

El software en aplicaciones monolíticas no es fácil de reemplazar pieza por pieza. Los componentes de estas aplicaciones están estrechamente vinculados: si cambia algo en una parte del programa, su acción probablemente afectará a otras partes de la aplicación. Así que si no quieres «romper nada», es necesario que tus desarrolladores tengan un buen modelo mental de toda la aplicación a la hora de hacer cualquier cambio.

La mayoría de las plataformas PLM disponibles hoy en día se basan principalmente en arquitecturas monolíticas. Por lo general, apoyan a las empresas de manera propietaria, es decir, se adaptan a las necesidades de cada organización. Estos diseños hacen que sea difícil y costoso para las empresas compartir, consolidar y adaptarse a las cambiantes realidades empresariales.

Desacoplamiento de aplicaciones monolíticas con Arquitectura Orientada a Servicios (Service-Oriented Architecture - SOA)

Alrededor del año 2000, se produjo un cambio en la arquitectura de sistemas de las empresas. Esencialmente, varios pioneros llegaron a la idea de ensamblar aplicaciones utilizando un conjunto de elementos fundamentales conocidos como componentes, algunos de los cuales están disponibles “al alcance de la mano”, mientras que otros deben ser construidos desde cero.

De esta forma, fragmentaron sistemas grandes e inflexibles en un conjunto de piezas más pequeñas llamadas servicios. Estos servicios intercambiaban datos a través de la red. La comunicación entre los componentes se realizaba normalmente a través de XML.

En SOA, el servidor define a qué funcionalidad se puede acceder y cómo deben ser las peticiones y respuestas. Las interacciones son verbos-cosas que se pueden hacer con las peticiones al sistema, en lugar de estar asociadas a recursos específicos del mismo.

Principales componentes de SOA

Servicios web

Los «Servicios Web» son programas que permiten que una aplicación hable con otra a través de Internet. Ahora imagina que estás en un restaurante a punto de pedir. El camarero anota la comanda, la traslada a la cocina, y en algún momento, tú recibes tu comida. En este ejemplo, el camarero está actuando como un servicio web.

Los servicios web no están vinculados a ningún lenguaje de programación. Volviendo al ejemplo de antes, si tú solo hablas español y el personal de cocina solo habla alemán, el camarero debería ser capaz de traducir el pedido para obtengas la comida que habías pedido.

Bus de servicios empresariales (Enterprise Service Bus – EBS)

En las arquitecturas orientadas a servicios, los diferentes componentes de software se comunican entre sí mediante el envío de mensajes. Para transportar los mensajes entre componentes de software, las SOA suelen utilizar un Bus de Servicio Empresarial (Enterprice Service Bus o ESB).

El Registro SOA

El registro SOA es una biblioteca donde se almacena la información que describe lo que hace cada componente. Los desarrolladores y las aplicaciones consultan a través del registro qué servicios existen y cómo deben utilizarse.

Desafíos en la implementación

El gran desafío en las implementaciones de SOA fue que, aunque se había obtenido un mayor modularidad de software, las piezas de la aplicación seguían siendo bastante grandes. Además, al definir estrictamente cómo se podía acceder a los datos, de alguna forma se volvió a introducir la rigidez. Algunos proveedores desarrollaron formas exclusivas de llamar a los métodos a través de la red, lo que de nuevo llevó a un estrecho acoplamiento.

MICROSERVICIOS PARA ACELERAR EL CICLO DE VIDA DEL DESARROLLO DE SOFTWARE

No fue hasta el año 2010 cuando se acuñó el término «microservicios». En una arquitectura de microservicios, las aplicaciones se construyen como un conjunto de pequeños servicios, cada uno de los cuales ejecuta su propio proceso y se comunica con mecanismos ligeros, a menudo una API de recursos HTTP.

Las APIs son interfaces simples que se proporcionan a través de HTTP. Normalmente se construyen en base a interfaces REST, que hacen que los datos sean accesibles utilizando la Notación de Objetos JavaScript (JSON) y los verbos HTTP (en inglés: PUT, GET, POST y DELETE) para crear, leer, actualizar y eliminar recursos. Estos protocolos y formatos de datos son más fáciles de usar que los estándares de servicios web utilizados en los primeros SOA.

Los microservicios pueden ser vistos como una evolución de SOA. Mientras que SOA se centraba en compartir la funcionalidad de las aplicaciones, los microservicios se centran más en hacer que los propios datos estén disponibles, sin restringir su uso.

De igual forma, los microservicios son muy buenos para consumir datos de diferentes fuentes y transformarlos para otras aplicaciones.

PRINCIPIOS BÁSICOS PARA LA CONSTRUCCIÓN DE MICROSERVICIOS

1. Un microservicio, una tarea

El principio fundamental de los microservicios es que cada uno sólo debe realizar una tarea. En el siguiente ejemplo, se representa una aplicación para gestionar órdenes. Como vemos, en la arquitectura de microservicios hay un servicio dedicado para cada tarea en el proceso de gestión de pedidos.

2. Desarrollar e implementar servicios de forma independiente

Debería ser posible desarrollar y desplegar un microservicio independientemente de todas las demás partes de una aplicación. Como ya hemos visto en las arquitecturas monolíticas tradicionales, un cambio en cualquier parte de la aplicación requiere que esta se vuelva a implementar por completo. Con los microservicios, la aplicación se descompone en múltiples servicios que se pueden volver a implementar de forma independiente, lo que facilita mucho el proceso.

3. Productos, no proyectos

Tradicionalmente, el desarrollo de aplicaciones empresariales sigue siempre el modelo de proyecto: el objetivo es entregar una pieza de software en funcionamiento que luego se considera completa. Con los microservicios, la idea es que los componentes de software se conviertan en productos reutilizables de los que el equipo pueda disponer a lo largo de su ciclo de vida.

4. Métodos HTTP estándar para la comunicación de servicios

En SOA, los servicios web se comunican mediante XML. Los microservicios han adoptado métodos de comunicación modernos como HTTP, y las solicitudes y respuestas utilizan JSON para describir los datos.

BENEFICIOS DE USAR MICROSERVICIOS PLM

Escalabilidad y agilidad a través de la reutilización

En la arquitectura de microservicios, los grandes proyectos de software se dividen en módulos más pequeños e independientes. El software construido en forma de microservicios puede dividirse en múltiples servicios de componentes, de modo que cada uno de estos servicios puede ser implementado de forma independiente sin comprometer la integridad de una aplicación. Esto significa que la arquitectura de microservicios ofrece a los desarrolladores la libertad de desarrollar e implementar servicios de forma independiente.

Mejor aislamiento de errores

Las arquitecturas de microservicios mejoran el aislamiento de errores y permiten la entrega continua: si un microservicio falla, los otros seguirán funcionando. De esta forma las aplicaciones más grandes pueden no verse afectadas por el fallo de un solo servicio.

Apoyo al desarrollo de terceros

Dado que los microservicios representan una pequeña parte de la funcionalidad, es más fácil de entender, y por lo tanto subcontratar el desarrollo de aplicaciones. Otra ventaja es que el código para diferentes servicios puede ser escrito en diferentes lenguajes de programación.

Cambiar operaciones por resultados

Una consecuencia directa con la llegada de los microservicios es el cambio en la mentalidad. Las operaciones se descomponen y se definen en términos de resultados. Esto permite a las empresas visualizar el trabajo que clientes y proveedores están realizando en términos de propósito y actividad. Las organizaciones pueden identificar fácilmente qué actividades deben mantenerse internamente porque son estratégicas y proporcionan una ventaja competitiva, cuáles pueden ser subcontratadas y cuáles pueden venderse como un servicio para los clientes.

Mejor experiencia de usuario (UX) para las funcionalidades de cara al cliente

Las nuevas tecnologías web son mucho más fáciles de usar que las aplicaciones monolíticas tradicionales. La disponibilidad de datos importantes a través de los servicios nos permite el empleo de capas de presentación web modernas y la personalización de las aplicaciones de los usuarios finales.

BARRERAS A LA HORA DE PASAR A LOS MICROSERVICIOS PLUG-AND-PLAY

El desafío de la coordinación: asegúrate de que todos tus microservicios trabajen bien yen armonía

Has comenzado a encapsular tu feo código en microservicios plug-and-play. Hasta aquí todo bien, pero ¿cómo estás orquestando exactamente todos tus microservicios para asegurar el servicio integral deseado? Si los microservicios no se componen de forma clara y ordenada, la complejidad se desplaza desde el interior de un servicio a las conexiones entre ellos.

Además, es difícil determinar exactamente cuáles deben ser los límites de los servicios para asegurar que los microservicios y las aplicaciones tradicionales funcionen bien y en sintonía. Cualquier cambio en la interfaz debe ser coordinado entre los equipos, la compatibilidad debe ser comprobada cuando se hacen las actualizaciones, y las verificaciones pueden convertirse en algo bastante complejo.

Esta vez, ¿quién va a ser el poli malo que ayude a prevenir accidentes? Se necesitará una junta de gestión sólida en torno a los microservicios si no queremos acabar creando una jungla y, una vez más, limitar la flexibilidad y la agilidad.

Cuando la reutilización simplemente no funciona

El primer paso para reutilizar los microservicios es crear transparencia. ¿Cómo saben los de compras que los de fabricación ya han desarrollado un servicio de gestión de pedidos? ¿Hay alguien que organice la biblioteca de servicios y se asegure de que estos sean debidamente comprendidos y estén disponibles?

En mi experiencia, los desarrolladores suelen preferir escribir cosas nuevas que reutilizar o modificar cosas viejas. Cuesta aproximadamente tres veces más crear un servicio reutilizable que el código de un solo uso, por ello la creación de microservicios reutilizables es una inversión.

Cuando dinosaurios monolíticos y microservicios ligeros se casan

Los sistemas monolíticos tradicionales, como PLM o ERP, no son muy flexibles. Algunas de estas aplicaciones no están preparadas para los procesos de consulta y recuperación de datos más actuales, y es posible que esto acabe generando grandes problemas de rendimiento y fiabilidad. Para crear microservicios eficaces que utilicen datos de estas aplicaciones centrales, se necesita un gran nivel de experiencia. Si experimentas demasiado, puedes terminar confundiendo la gestión del tráfico, la supervisión y el rendimiento de la infraestructura central de la empresa.

¿SON LOS MICROSERVICIOS EL SIGUIENTE GRAN PASOEN PLM?

La capacidad de ofrecer aplicaciones plug-and-play se ha convertido en un importante factor de competitividad. Impulsadas por la convergencia de las redes sociales, la tecnología móvil y cloud y la creciente demanda de flexibilidad y usabilidad, las empresas deben ser ágiles, flexibles, y rápidas para satisfacer las expectativas de los clientes.

Saltar a este nuevo modelo no es sencillo. Requiere una combinación de nueva mentalidad, procesos y tecnología. Los microservicios no garantizan un viaje sin problemas, libre de preocupaciones empresariales. Pero sí representan un intento significativo de avanzar hacia una IT más flexible y moderna, que apoye la «necesidad de velocidad» en esta nueva era digital.

Todavía queda por ver si los microservicios son la nueva fórmula mágica. Algunos sugieren una arquitectura de dos velocidades: para desarrollar capacidades de cara al cliente a alta velocidad, mientras se desacoplan sistemas heredados a un ritmo más lento. Sin embargo, es cuestión de tiempo que los sistemas centrales tradicionales como el PLM comprendan los beneficios y se sumen al cambio.

Ahora mismo ya se presiona a los proveedores de PLM para que den un paso adelante y desempeñen un papel fundamental de apoyo a las empresas, para que naveguen a través de esta transición. Y es que una cosa es clara: aquellas que prevean cómo evolucionará la industria y actúen en consecuencia tendrán grandes oportunidades de prosperar.

¿Por qué las empresas que triunfan gestionan sus procesos de negocio?

PLM Business Process

Antes de responder, conviene repasar a qué nos referimos cuando hablamos de procesos. Un proceso se conforma de una serie de tareas realizadas en secuencia, con inputs claramente definidos y destinados a la entrega de outputs. Su resultado puede ser un servicio, un producto o cualquier otro objetivo de la organización.

Los procesos de negocio permiten a las empresas describir quién hace qué, y en qué orden se hace. Si somos capaces de combinar todos los procesos de negocio de la empresa en su totalidad, podemos describir cómo funciona realmente.

Pongamos un ejemplo más práctico para entender bien este concepto. Llevar a cabo un proceso de negocio es fácilmente comparable a la elaboración de una receta. Escenario típico: imagina que estás en casa a punto de prepararte la cena.Es jueves y has tenido un gran día en el trabajo, así que no sabes muy bien por qué, pero consideras que te mereces algo más que la triste y típica ensalada a la que recurres normalmente. Estás lo suficientemente motivado/a como para buscar en Google una receta especial, de modo que tras un rato buscando, decides arriesgarte con un risotto de gorgonzola.Preparas los ingredientes y comienzas a seguir los pasos minuciosamente. Sin embargo, no hay nadie allí para supervisarte ni para darte consejos, y la verdad sea dicha, tú nunca has destacado por tus buenas dotes ante los fogones. Teniendo esto en cuenta, ¿qué será lo más importante para que tu cena sea un éxito y no acabes pidiendo una pizza? Muy fácil, que la receta sea lo más específica posible. Continuemos con el momento risotto. Después de haberte preocupado de seguir la receta lo mejor posible, llega el momento de probar el arroz. Y tras él, el drama. Te acabas dando cuenta de que el punto del arroz no ha quedado como debía, y el aspecto final de tu plato no se parece ni de lejos al de la foto de la receta. Y es justo en ese momento cuando te preguntas: ¿por qué a mí? ¡Si he hecho todo tal y como se especificaba en la receta! Sin embargo, olvidas que tal vez la lista de ingredientes de la receta de Google no era lo suficientemente específica, o quizás las descripciones de cada paso eran demasiado vagas (o que directamente en un despiste te saltaste un paso importante).

 

¿Entiendes mejor ahora a qué nos referimos cuando hablamos de la importancia de combinar la totalidad de los procesos de negocio para describir cómo funciona realmente una empresa? Como con el risotto, puedes tener los mejores ingredientes, pero si te saltas un paso de la receta, estás perdido.

¿POR QUÉ UNA EMPRESA DEBERÍA TENER EN CUENTA LOS PROCESOS DE NEGOCIO?

Los procesos de negocio son un punto clave para entender de qué manera una empresa lleva a cabo su misión. Como ejemplo ilustrativo, el pago de una factura a un proveedor o la tramitación de un pedido para un cliente son ambos procesos de negocio. Las buenas empresas se caracterizan por poseer sus procesos documentados, generando outputs consistentes y de alta calidad. Igualmente, mediante la correcta documentación de los procesos las empresas pueden expandirse más rápidamente. Después de las fusiones y adquisiciones, los procesos de negocio bien documentados facilitan las integraciones y respaldan las operaciones comerciales conjuntas. Los procesos también son cruciales para la gestión eficaz del conocimiento. Se pueden usar para enseñar a los nuevos empleados a realizar las tareas requeridas y lograr los resultados deseados.

¿POR QUÉ LOS PROCESOS DE NEGOCIO SON TAN IMPORTANTES PARA EL PLM?

Los procesos de negocio permiten a las empresas desarrollar, vender, entregar y financiar sus productos de manera efectiva. La calidad de los procesos en todo el ciclo de vida del producto influye intensamente en el éxito de un producto. Las fugas de información en estos procesos pueden provocar entregas de productos más lentas y problemas de calidad.

¿DE QUÉ MANERA DEFINIMOS UN PROCESO DE NEGOCIO?

La gestión de procesos de negocio establece un enfoque global que nos ayuda a mejorar la eficiencia en una empresa. Esta gestión implica entre otras cosas: documentar los procesos existentes (mapeo de procesos), definir los procesos futuros (modelado de procesos), implementar los procesos definidos (utilización de procesos) y medir los procesos (supervisión de procesos). El mapeo, el modelado y la utilización de procesos de negocio son actividades principales en PLM. A continuación, explicaremos estas etapas mediante representaciones visuales para ilustrar de qué manera funciona cada paso. En cada uno encontraremos actividades, roles, entregas y métricas que definen con precisión las tareas que deben realizarse.

PLM business processes

1. MAPEO DE PROCESOS DE NEGOCIO.

Para crear un mapa de procesos de negocio, podemos usar un diagrama de flujo de procesos que contenga la actividad «carriles». El diagrama de flujo muestra un «carril de navegación» para cada rol e indica las actividades y eventos que ejecuta cada rol. En esta fase, el diagrama muestra la situación actual. El siguiente ejemplo representa el proceso de venta de una pequeña empresa.

PLM Business Process Mapping

2. MODELADO DE PROCESOS DE NEGOCIO.

Durante esta fase, creamos un modelo mejorado para los procesos que la empresa desea optimizar. Un modelo sirve como un marco común para el debate y la comunicación. Ayuda a las personas a comprender cómo funcionará el proceso y de dónde provienen las optimizaciones. El siguiente ejemplo representa el proceso de venta optimizado de una empresa pequeña, después de la remodelación.

PLM business process modelling

3. UTILIZACIÓN DE PROCESOS DE NEGOCIO.

Después de definir nuevos procesos, tocaría el momento de implementarlos. Para implementar estos cambios de manera productiva, se debe llevar a cabo un plan de formación y apoyo. Después de la implementación, es muy importante hacer un seguimiento del proceso y asegurarnos de recibir un buen feedback: ¿Funciona bien el nuevo proceso? ¿Necesitamos ajustarlo?

4. SUPERVISIÓN DE PROCESOS DE NEGOCIO.

Un buen proceso de negocio debe ser fácilmente medible. Para ello usamos KPI’s que supervisan la eficiencia e implementación del mismo. Un KPI es una medida, un atributo cuantificable que nos ayuda a describir el rendimiento.

En resumen, si dedicamos tiempo y esfuerzo a respaldar la supervisión de procesos, recibiremos grandes recompensas: la anticipación de problemas, el apoyo en la formación de los empleados en el nuevo y mejorado enfoque, y la certeza de que nos encontramos ante un buen negocio que cuenta con las herramientas y formas de trabajo más eficientes.

¿QUÉ DEFINE UN BUEN PROCESO DE NEGOCIO?

Es importante mantener los procesos de negocio con un alto nivel de detalle.Las empresas a veces mezclan procesos y métodos sin ser conscientes de sus diferencias. Los métodos definen cómo realizar las acciones involucradas en los pasos de proceso, por lo tanto, son más detallados y específicos. Un buen proceso de negocio debe estar bien definido, bien documentado y debe ser fácil de entender. Cualquier paso que no sea lo suficientemente claro, generará confusión y fuga de información.

Del mismo modo, los procesos deben ser medibles y manejables. En otras palabras, debemos ser capaces de monitorearlos, usando datos para saber si están funcionando correctamente, o si por el contrario están teniendo dificultades.

Los procesos de negocio constituyen los pilares de cualquier gran organización. Si una empresa quiere alcanzar la excelencia y que sus empleados trabajen de la mejor manera posible, es imprescindible definir su estrategia en un proceso de negocio.Cuando están bien gestionados, los procesos de negocio son un poderoso activo estratégico corporativo.