Nuestro Blog

Nuestro equipo de especialistas quiso compartir algunos artículos sobre tecnologías, servicios, tendencias y novedades de nuestra industria en la era de la transformación digital.

Data Lakes en AWS

Data Lakes en AWS

Introducción

En el artículo Conceptos clave sobre Data Lakes, hablamos sobre su importancia, arquitectura y los comparamos con un Data Warehouse. En esta entrega, nos enfocaremos en su implementación usando Amazon Web Services (AWS), la plataforma cloud de Amazon. Veremos el flujo general, los distintos servicios disponibles y, por último, AWS Lake Formation, una herramienta especialmente diseñada para facilitar esta tarea.

 

Flujo general

Un Data Lake respalda las necesidades de nuestras aplicaciones y analíticas, sin que debamos preocuparnos constantemente por el aumento de recursos de almacenamiento y cómputo, a medida que la empresa crece y la cantidad de datos aumenta. Sin embargo, no existe una fórmula mágica para su creación. Generalmente, implica el uso de docenas de tecnologías, herramientas y entornos. En el siguiente diagrama, se puede observar el flujo general de datos, desde la recopilación, el almacenamiento y el procesamiento, hasta el uso de las analíticas mediante técnicas de Machine Learning y Business Intelligence.

Servicios disponibles en AWS

AWS brinda un amplio conjunto de servicios administrados que ayudan a constituir un Data Lake. Es necesaria una planificación y diseño adecuados para migrar un ecosistema de datos a la Nube, y para ello es fundamental comprender la oferta de Amazon. Aquí haremos mención de solo algunas de las herramientas más importantes en cada etapa del flujo.

 

Ingestión

El primer paso es analizar los objetivos y beneficios que se desean lograr con la implementación de un Data Lake basado en AWS. Una vez diseñado el plan, se deben migrar los datos a la Nube, teniendo en cuenta el volumen de los mismos. Es posible acelerar fácilmente esta migración con servicios como Snowball y Snowcone (dispositivos edge para almacenamiento y cómputo) o DataSync y Transfer Family, para simplificar y automatizar transferencias.

 

Canalización

En este paso, se puede operar de 2 modos: por Lotes o por Streaming.

En la Carga por Lotes, se utiliza AWS Glue para extraer información de varias fuentes, en intervalos periódicos, y moverlos al Data Lake. Normalmente implica alguna transformación mínima (ELT), como la compresión o la agregación de datos.

En el caso de trabajar con Streaming, se ingieren datos generados continuamente a partir de múltiples fuentes, como archivos de logging, telemetría, aplicaciones móviles, sensores IoT y redes sociales. Se pueden procesar durante una ventana de tiempo circular y canalizar el resultado al Data Lake.

Las Analíticas en tiempo real brindan información útil para procesos de negocio críticos que dependen del análisis de datos en streaming, como algoritmos de Machine Learning para la detección de anomalías. Amazon Kinesis Data Firehose (servicio gestionado para streaming) ayuda a realizar este proceso desde cientos de miles de orígenes en tiempo real, en lugar de cargar datos durante horas y procesarlos luego.

 

Almacenamiento y Procesamiento

En un Data Lake de AWS el servicio más importante de todos es Amazon S3, que brinda almacenamiento de alta escalabilidad, excelentes costos y niveles de seguridad, ofreciendo así una solución integral para llevar a cabo diferentes modelos de procesamiento. Puede almacenar datos ilimitados y cualquier tipo de archivo como un objeto. Permite crear tablas lógicas y jerarquías a partir de carpetas (por ejemplo, por año, mes y día), permitiendo la partición de datos en volumen. También ofrece un amplio conjunto de funciones de seguridad, como controles y políticas de acceso, cifrado en reposo, registro, monitoreo, entre otros. Una vez que los datos se cargan, pueden usarse en cualquier momento y en lugar, para afrontar cualquier necesidad. Cuenta con una amplia gama de clases de almacenamiento (Estándar, Inteligente, Acceso poco frecuente), cada una con diferentes capacidades, tiempos de recuperación, seguridad y costo.

AWS Glacier es un servicio para el archivado seguro y la gestión de copias de seguridad, a una fracción del costo de S3. Las recuperaciones de archivos pueden demorar de pocos minutos a 12 horas, dependiendo de la clase de almacenamiento seleccionada.

AWS Glue es un servicio administrado de ETL y Catálogo de Datos que ayuda a encontrar y catalogar metadatos para realizar consultas y búsquedas más rápidas. Una vez que Glue apunta a los datos almacenados en S3, los analiza mediante rastreadores automáticos y registra su esquema. El propósito de Glue es realizar transformaciones (ETL/ELT) usando Apache Spark, scripts Python y Scala. Glue no tiene servidor; por lo tanto, no hay ninguna infraestructura configurada, lo que lo hace más eficiente.

Si se requiere una indexación de los contenidos del Data Lake, puede utilizarse AWS DynamoDB (base de datos NoSQL) y AWS ElasticSearch (servidor de búsqueda de texto). Además, mediante el uso de funciones AWS Lambda, activadas directamente por S3 en respuesta a eventos como la carga de nuevos archivos, pueden dispararse procesos para mantener su Catálogo actualizado.

Analíticas para Machine Learning y Business Intelligence

Hay varias opciones para obtener información de forma masiva del Data Lake.

Una vez que los datos han sido catalogados por Glue, se pueden utilizar diferentes servicios en la capa de cliente para analíticas, visualizaciones, dashboards. etc. Por ejemplo, Amazon Athena, un servicio serverless interactivo para consultas exploratorias ad hoc utilizando SQL estándar; Amazon Redshift, un servicio Data Warehouse para consultas e informes más estructurados; Amazon EMR (Amazon Elastic MapReduce), un sistema administrado para herramientas de procesamiento Big Data como Apache Hadoop, Spark, Flink, entre otras; y Amazon SageMaker, una  plataforma de aprendizaje automático que permite a los desarrolladores crear, entrenar e implementar modelos de Machine Learning en la nube.

Con Athena y Redshift Spectrum, se puede consultar directamente el Data Lake en S3 utilizando el lenguaje SQL, a través del Catálogo de AWS Glue, que contiene metadatos (tablas lógicas, esquema, versiones, etc.). El punto más importante es que sólo se paga por las consultas ejecutadas, en función de la cantidad de datos escaneados. Por lo tanto, puede lograr significantes mejoras en el desempeño y el costo al comprimir, dividir en particiones o convertir sus datos en un formato de columna (como Apache Parquet), ya que cada una de esas operaciones reduce la cantidad de datos que Athena o Redshift Spectrum deben leer.

 

AWS Lake Formation

Construir un Data Lake es una tarea compleja, de varios pasos, entre ellos:

  • Identificar fuentes (Bases de Datos, archivos, streams, transacciones, etc.).
  • Crear los buckets necesarios en S3 para almacenar estos datos, con sus correspondientes políticas.
  • Crear los ETLs que realizarán las transformaciones necesarias y la correspondiente administración de políticas de auditoría y permisos.
  • Permitir que los servicios de Analíticas accedan a la información del Data Lake.

AWS Lake Formation es una opción atractiva que permite a usuarios (tanto principiantes como expertos) comenzar de manera inmediata con un Data Lake básico, abstrayendo los detalles técnicos complejos. Permite monitorear en tiempo real desde un único punto, sin necesidad de recorrer múltiples servicios. Un aspecto fuerte es su costo: AWS Lake Formation es gratis. Sólo se cobrará por los servicios que se invoquen a partir de él.

Permite la carga de diversas fuentes, monitorizar esos flujos, configurar particiones, activar el cifrado y gestión de claves, definir trabajos de transformación y monitorearlos, reorganizar datos en formato columnar, configurar el control de acceso, deduplicar datos redundantes, relacionar registros vinculados, obtener acceso y auditar el acceso.

 

Conclusiones

En estos 2 artículos, conocimos que es un Data Lake, qué lo hace diferente a un Data Warehouse y cómo se podría implementar en la plataforma de Amazon. Es posible reducir significativamente el CTO moviendo su ecosistema de datos a la nube. Proveedores como AWS agregan nuevos servicios continuamente, mientras mejoran los existentes, reduciendo los costos de los mismos.

Huenei puede ayudarlo a planificar y ejecutar su iniciativa de Data Lake en AWS, en el proceso de migración de sus datos a la nube y la implementación de las herramientas de Analíticas necesarias para su organización.

Conceptos clave sobre Data Lakes

Conceptos clave sobre Data Lakes

Los datos se han convertido en un elemento vital para las empresas digitales, y una ventaja competitiva clave, pero el volumen de datos que actualmente necesitan administrar las organizaciones es muy heterogéneo y su velocidad de crecimiento exponencial. Surge así la necesidad de soluciones de almacenamiento y análisis, que ofrezcan escalabilidad, rapidez y flexibilidad para poder gestionar esta masiva cantidad de datos. ¿Cómo es posible almacenarlos de manera rentable y acceder a ellos rápidamente? Un Data Lake (Lago de Datos) es una respuesta moderna a este problema.

En esta serie de artículos, veremos qué es un Data Lake, cuáles son sus beneficios y cómo podemos implementarlo utilizando Amazon Web Services (AWS).

¿Qué es un Data Lake?

Un Data Lake es un repositorio de almacenamiento centralizado, que permite guardar todo tipo de datos estructurados o no, a cualquier escala, sin procesar, hasta que se los necesite. Cuando surge una pregunta de negocio, es posible obtener la información relevante y ejecutar diferentes tipos de análisis sobre ella, a través de dashboards, visualizaciones, procesamiento de Big Data y aprendizaje automático, para guiar la toma de mejores decisiones.

Un Data Lake puede almacenar datos tal como están, sin tener que estructurarlos primero, con poco o ningún procesamiento, en sus formatos nativos, tales como JSON, XML, CSV o texto. Puede almacenar tipo de archivos: imágenes, audios, videos, weblogs, datos generados desde sensores, dispositivos IoT, redes sociales, etc. Algunos formatos de archivo son mejores que otros, como Apache Parquet que es un formato columnar comprimido que proporciona un almacenamiento muy eficiente. La compresión ahorra espacio en disco y accesos de E/S, mientras que el formato permite al motor de consultas escanear sólo las columnas relevantes, lo cual reduce el tiempo y los costos de las mismas.

El uso de un sistema de archivos distribuido (DFS), como AWS S3, permite almacenar más datos a un costo menor, brindando múltiples beneficios:

  • Replicación de datos
  • Altísima disponibilidad
  • Bajos costos, con diferentes escalas de precios y múltiples tipos de almacenamiento dependientes del tiempo de recuperación (desde acceso instantáneo a varias horas)
  • Políticas de retención, lo que permite especificar cuánto tiempo conservar los datos antes de que se eliminen automáticamente

 

datalakes

 

Data Lake versus Data Warehouse

Los Data Lakes y los Data Warehouses son dos estrategias diferentes de almacenar Big Data, en ambos casos sin atarse a una tecnología específica. La diferencia más importante entre ellos es que, en un Data Warehouse, el esquema de datos está preestablecido; se debe crear un esquema y planificar las consultas. Al alimentarse de múltiples aplicaciones transaccionales en línea, se requiere que los datos se transformen vía ETL (extraer, transformar y cargar) para que se ajusten al esquema predefinido en el almacén de datos. En cambio, un Data Lake puede albergar datos estructurados, semi-estructurados y no estructurados y no tiene un esquema predeterminado. Los datos se recogen en estado natural, necesitan poco o ningún procesamiento al guardarlos y el esquema se crea durante la lectura para responder a las necesidades de procesamiento de la organización.

El Data Lake es una solución más flexible y adaptada a usuarios con perfiles más técnicos, con necesidades de análisis avanzadas, como Científicos de Datos, porque se necesita un nivel de habilidad para poder clasificar la gran cantidad de datos sin procesar y extraer fácilmente el significado de ellos. Un almacén de datos se centra más en usuarios de Análiticas de Negocios, para respaldar las consultas comerciales de grupos internos específicos (Ventas, Marketing, etc.), al poseer los datos ya curados y provenir de los sistemas operacionales de la empresa. Por su parte, los Data Lakes suelen recibir datos tanto relacionales como no relacionales de dispositivos IoT, redes sociales, aplicaciones móviles y aplicaciones corporativas.

En lo que respecta a la calidad de los datos, en un Data Warehouse, estos están altamente curados, son confiables y se consideran la versión central de la verdad. En cambio, en un Data Lake son menos confiables porque podrían llegar de cualquier fuente en cualquier estado, curados o no.

Un Data Warehouse es una base de datos optimizada para analizar datos relacionales, provenientes de sistemas transaccionales y aplicaciones de línea de negocios. Suelen ser muy costosos para grandes volúmenes de datos, aunque ofrecen tiempos de consulta más rápidos y mayor rendimiento. Los Data Lakes, en cambio, están diseñados pensando en el bajo costo de almacenamiento.

Algunas críticas legítimas que reciben los Data Lakes son:

  • Es aún una tecnología emergente frente el modelo de madurez fuerte de un Data Warehouse, el cual posee muchos años en el mercado.
  • Un Data Lake podría convertirse en un “pantano”. Si una organización practica una deficiente gestión y gobernanza, puede perder el rastro de lo que existe en el “fondo” del lago, provocando su deterioro, volviéndolo incontrolado e inaccesible.

Debido a sus diferencias, las organizaciones pueden optar por utilizar tanto un Data Warehouse como un Data Lake en una implementación híbrida. Una posible razón sería el poder agregar nuevas fuentes o usar el Data Lake como repositorio para todo aquello que ya no se necesite en el almacén de datos principal. Con frecuencia, los Data Lakes son una adición o una evolución de la estructura de administración de datos actual de una organización en lugar de un reemplazo. Los Analistas de Datos pueden hacer uso de vistas más estructuradas de los datos para obtener sus respuestas y, a la vez, la Ciencia de Datos puede «ir al lago» y trabajar con toda la información en bruto que sea necesaria.

Arquitectura de un Data Lake

La arquitectura física de un Data Lake puede variar, ya que se trata de una estrategia aplicable por múltiples tecnologías y proveedores (Hadoop, Amazon, Microsoft Azure, Google Cloud). Sin embargo, hay 3 principios que lo distinguen de otros métodos de almacenamiento Big Data y constituyen la arquitectura básica de un Data Lake:

  • No se rechaza ningún dato. Se cargan desde varios sistemas de origen y se conservan.
  • Los datos se almacenan en un estado sin transformar o casi sin transformar, tal como se recibieron de la fuente.
  • Los datos se transforman y se ajustan al esquema durante el análisis.

Si bien la información, en gran medida, no está estructurada ni orientada a responder una pregunta específica, debe ser organizada de alguna manera, para garantizar que el Data Lake sea funcional y saludable. Algunas de estas características incluyen:

  • Etiquetas y/o metadata para la clasificación, que puede incluir tipo, contenido, escenarios de uso y grupos de posibles usuarios.
  • Una jerarquía de archivos con convenciones de nomenclatura.
  • Un Catálogo de datos indexado y con capacidad de búsqueda.

Conclusiones

Los Data Lakes son cada vez más importantes para las estrategias de datos empresariales. Responden mucho mejor a la realidad actual: volúmenes y tipos de datos mucho mayores, mayores expectativas de los usuarios y mayor variedad de analíticas, tanto de negocio como predictivas. Tanto los Data Warehouses como los Data Lakes están destinados a convivir en las empresas que deseen basar sus decisiones en datos. Ambos son complementarios, no sustitutivos, pudiendo ayudar a cualquier negocio a conocer mejor el mercado y al consumidor, e impulsar iniciativas de transformación digital.

En el próximo artículo, analizaremos cómo podemos utilizar Amazon Web Services y su infraestructura abierta, segura, escalable y rentable, para construir Data Lakes y analíticas sobre ellos.

Definición de “Hecho” en gestión de proyectos

Definición de “Hecho” en gestión de proyectos

La gestión de proyectos en el rubro tecnológico es un elemento clave para el éxito de la operación, ya que sienta las bases y estructura general del proyecto a realizar, ya que sobre esta estructura se construyen los otros elementos, como el diseño de la interfaz, la experiencia del usuario, validación de concepto, pruebas de calidad, entre otros.

Para que estos proyectos avancen, primero debemos entender la finalidad de estos, así como las necesidades actuales, futuras, explícitas e implícitas de nuestros clientes, sus usuarios finales y los respectivos grupos de interés. Posteriormente, y entendiendo el alcance de la solución, dividimos el proyecto en fases que nos permitan la realizarlo de una forma ágil y eficiente.

Es aquí donde se viene lo difícil, ya que debemos asignar de forma estratégica cada actividad a realizar, entendiendo que debemos completar una para continuar con la siguiente, sin embargo, constantemente surge la duda: ¿esta tarea/actividad está “hecha”? ¿no está relacionada con otra tarea futura que podrá afectar su estatus?

Estas y otras interrogantes son las más comunes de lo pensado, siendo el principal debate que deberían tener tanto el cliente (Product Owner) como los líderes de proyecto de parte de las compañías de desarrollo de software.

Definir el significado de “Hecho”
La Definición de “Hecho” (o como se estila decir en inglés DoD por Definition of Done) es cuando todas las condiciones, o criterios de aceptación, que un producto de software debe satisfacer son cumplidas, de manera que cumple funcionalmente con los requisitos de un usuario, cliente, equipo, o está disponible para ser utilizado por otro sistema, cumpliendo con los parámetros de calidad establecidos. Esto evita que alguna característica/funcionalidad incompleta sea puesta en productivo, generando errores y retrabajo al tener que regresar para hacer las debidas correcciones, así como disconformidad de los clientes y/o usuarios finales.

Esta definición se determina al inicio de cada proyecto, usualmente en las reuniones que sostiene el Product Owner y los líderes de desarrollo, sin embargo, suele ocurrir que a medida que avanza el proyecto, esta definición es replanteada variadas veces, de manera de que las expectativas del mismo terminan acoplándose a la práctica, así como a los distintos parámetros de calidad, proceso de trabajo, entre otros.

Teniendo claro cuándo una característica/funcionalidad esta “hecha”, entonces se puede tener una mejor idea de en qué parte del proyecto nos encontramos, permitiendo tomar decisiones más certeras y claras acerca de cuanto falta para terminarlo y cuándo deben ser incluidos los respectivos recursos en el proyecto.
Un elemento clave, que nos ayudará enormemente en esta definición consta en las llamadas User stories (historias de usuario), estas podrían definirse como el trayecto que siguen los usuarios dentro de nuestro desarrollo para realizar las tareas deseadas.

Uno de los mayores riesgos que puede ocurrir al no contar con una clara definición y entendimiento de las partes ocurre justamente al presentar todos los requerimientos completados durante el proyecto, precisamente al final de cada iteración, donde al momento hacer las debidas revisiones nos daremos cuenta de que dichos requerimientos no están del todo finalizados, generando los debates sobre el avance real.

La importancia de acordar términos
Cuando una historia de usuario o un incremento (conjunto de historias) está “Hecho”, todos en el equipo deben dar por entendido lo mismo: que esta funcionalidad/incremento ya puede salir a producción. Si bien este entendimiento es resultado de transparencia y confianza entre las partes, la parte más evidente es cuando se suele avanzar a la siguiente fase del proyecto, ejemplo: cuando el equipo Scrum finaliza un sprint.

Otro aspecto importante es definir qué tan completa debe estar una característica, funcionalidad, historia o incremento para pasar a la siguiente etapa. Si esta es de vital importancia para todo el proyecto, entonces debe ser considerado como un criterio de mínima. De lo contrario, volverán a ocurrir malentendidos de parte y parte.

Sin embargo, la Definición de “Hecho” puede evolucionar. Cuando la relación entre el Product Owner y el equipo Scrum madura y se desarrolla positivamente, puede ocurrir que la definición de “Hecho” usada previamente en los incrementos se amplíe durante las reuniones de Retrospectiva y retroalimentación, incluyendo nuevos criterios de mayor calidad, basados en parámetros más prácticos.

Relación entre “Hecho” y Criterios de Aceptación
Un elemento importante para determinar el estado de alguna característica, funcionalidad, etc. Es el llamado Criterio de Aceptación, su definición más básica es cuando esta cumple con todos los requisitos mínimos necesarias para poder ser puesta en producción, tanto a nivel técnico, como funcional, operativo, entre otros.
Los criterios de aceptación son importantes para:

  • Gestionar las expectativas, tanto para el Product Owner como para el equipo Scrum.
  • Definir el alcance y reducir la ambigüedad.
  • Establecer criterios de prueba para el control de calidad.
  • Evitar el cambio de alcance a mitad del Sprint, lo cual afecta directamente en la planificación.

Uso de la Definición de “Hecho” en las Fases de un Proyecto
Una vez entendida esta definición, así como los Criterios de Aceptación mínimo, los responsables de planificación del proyecto podrán elaborar la debida hoja/mapa de ruta del desarrollo del producto/servicio, así como la estimación global del esfuerzo a invertir con el propósito de cumplir efectivamente con las Historias de los usuarios.

A su vez, define la cantidad de trabajo a definir en cada Sprint, ya que se usará como guía para cumplir con la definición de los criterios establecidos en la reunión de planificación y en las subsecuentes reuniones de seguimiento y retrospectiva. Esto tiene como resultado una mejor evidencia en la terminación de una fase del proyecto y el inicio de la siguiente.

Impactos de la falta o mala de aplicación de la Definición de “Hecho”
Uno de los principales efectos de una incompleta o mala aplicación de la Definición de “Hecho” es la “Deuda Técnica, la cual se refiere al trabajo adicional producido por una implementación de una funcionalidad o característica que no estuvo finalizada, o que no cumplió con todos los requerimientos mínimos necesarios, como puede ser el haber realizado las debidas pruebas de calidad, o la documentación.

Como principal consecuencia encontramos que el equipo debe retrabajar en finalizar los requerimientos mínimos en las funcionales/características previamente aprobadas, lo cual genera retrasos y pérdida de recursos.

Consejos a tener en cuenta para la redacción de la Definición de “Hecho”

  • Involucrar al equipo: incluir en la etapa de planificación a la mayor cantidad de miembros responsables del equipo, de esta manera todos podrán dar su punto de vista y traer a la mesa temas que solo se podrían ver más adelante del proyecto. Mejorando la visión que se tiene del proyecto y cuándo terminaría una fase y comenzaría otra.
  • Realizar las historias de los usuarios: este valioso recurso nos permite identificar las necesidades de los usuarios desde su punto de vista. Mientas mejor definidas estén, más fácil será determinar cuándo un desarrollo está “Hecho”.
  • Cumplir con los requerimientos técnicos: es muy importante que todas las funcionalidades y requerimientos técnicos sean alcanzados, de manera de que el desarrollo tenga los parámetros de calidad aceptados, garantizando que el aplicativo tenga el desempeño esperado.
  • Cumplimiento de los requerimientos: es muy importante que todas las funcionalidades y requerimientos sean alcanzado a nivel técnico, de manera de que el desarrollo tenga los parámetros de calidad aceptados, garantizando que el aplicativo tenga el desempeño esperado.
  • Ejecutar Testing funcional y no funcional: validar la calidad y que los requerimientos técnicos estén debidamente testeados es clave. Ningún desarrollo de ningún tipo debería estar considerado “Hecho” sin haber pasado por el proceso de Testing & QA.
  • Contemplar las Épicas (Epics): donde “Hecho” a este nivel puede referirse a una prioridad estratégica de la organización, un objetivo del plan de negocio, o alguna un conjunto de requerimientos que satisfagan una necesidad del mercado.

Conclusión
El arte de gestionar un proyecto va más allá de dividirlo en fases y asignar recursos y fechas de entrega, siendo lo más importante el conocer a fondo tanto los requerimientos del cliente como contar con el dominio técnico necesario para saber asignar los recursos correctamente.

Los procesos de Huenei incluidos en su Propuesta de Servicios Ágil incluyen acordar con sus clientes la Definición de “Hecho” para sus servicios, permitiendo brindar transparencia en los resultados y confianza sobre el avance del trabajo.

Así mismo y como parte del compromiso en la aplicación de Nuestros Valores de Orientación al Cliente y Eficiencia, hacemos seguimiento y llevamos métricas de eficacia del desempeño de nuestros equipos al medir el nivel de retrabajo por deficiencias en la aplicación de la Definición de “Hecho” y sus criterios de aceptación.

En lo que respecta a la realización de tareas, la clave es que todo el equipo (tanto interno como de parte del cliente) estén en sintonía y entendimiento sobre qué se necesita para que un desarrollo, característica y funcionalidad está completamente finalizadas, permitiendo avanzar con el proyecto como para levantar la bandera para señalar que algo falta.

¿Cómo realizar un proceso de AMO?

¿Cómo realizar un proceso de AMO?

Sin importar la industria o su tamaño, los negocios que operar a nivel mundial hoy en día dependen de sistemas de aplicaciones comerciales para estimular las cadenas de producción, gestionar los mercados, conservar las conexiones con los socios y clientes e impulsar las operaciones a corto y mediano plazo.

Por tanto, son muchas las compañías que necesitan externalizar la gestión de aplicaciones, pero no tienen idea de qué tanto lo necesitan, ni qué tan pronto deberían tenerlo. Si consideras que tu compañía puede requerir este proceso y necesitas más información, en el siguiente apartado te contamos cómo determinarlo y cómo llevarlo a cabo con éxito.

Determina el alcance y necesidad de tu empresa

A menudo hallamos compañías donde su ventaja comparativa y el foco de su negocio dependen en demasía de la tecnología, pero no solo a nivel in-house para un único departamento, también en lo que respecta a procesos que apoyan a toda la empresa.
Por ello, resulta ser más eficiente e incluso rentable decantarse por el Outsource Application Management. Para determinar si esta es una de las necesidades de tu empresa, responde las siguientes preguntas básicas:

¿Tenemos identificadas cuáles actividades y procesos tecnológicos serán de gran apoyo para gestionar con más eficiencia mi negocio? ¿Tenemos dificultades para conseguir, contratar y retener profesionales expertos en tecnología? ¿Tenemos por nosotros mismos el suficiente dominio de plataformas y aplicaciones tecnológicas? ¿Podemos mantenerlas actualizadas sin problema? ¿Queremos gestionar un equipo in-house capacitado para encarar todos los retos que requiere la gestión tecnológica de la empresa?

Respondiendo estas interrogantes determinarás de forma rápida y sencilla las necesidades de tu empresa frente al AMO.

Tipos de outsorcing y sus estrategias

Subcontratación total:
En este sentido, el proveedor se hará cargo de gestionar de manera integral todas las actividades relacionadas con el soporte, el perfeccionamiento y la optimización de las aplicaciones pertenecientes a la compañía. Este tipo de subcontratación deberá proporcionar servicios tecnológicos, y a su vez, brindar ideas y recomendaciones para economizar, mejorar y evolucionar las aplicaciones, tomando en cuenta los nuevos requisitos comerciales. Además, será responsable de implementar iniciativas adecuadas de innovación digital y planes de continuidad del negocio ante eventuales situaciones inesperadas (como la pandemia del COVID-19).

Subcontratación selectiva:
Este tipo de OAM consiste en encargar al proveedor tan solo una parte muy específica de la gestión de las aplicaciones de la empresa. Su responsabilidad puede estar relacionada con la solución de problemas o actualización y mejora de los recursos, o también, pueden englobarse un grupo de objetivos tales como la supervisión, gestión, resolución de problemas y mantenimiento de aplicaciones. Este tipo de externalización está recomendada para aquellas áreas que son más complejas que las tareas individuales, pero que no interfieren en ningún proceso más completo.

Algunos consejos para conseguir el partner adecuado para tu proyecto
Para escoger el partner indicado para tu empresa, lo primero que debemos tomar en cuenta serán algunos detalles fundamentales propios de su preparación y dominio tecnológico. Por ejemplo:

  • Debe poseer el suficiente conocimiento técnico de diversas tecnologías y ser capaz de aportar soluciones factibles.
  • Debe tener experiencia en metodologías ágiles de entrega de servicios que le permita entender cuál es forma más eficiente en la que puede dividir un proyecto en varias fases.
  • El partner debe ser escalable, es decir, deberá existir la posibilidad de agregar más miembros al equipo si es necesario para cumplir con los tiempos de un proyecto.
  • La relación costo-beneficio es otro punto importante para la subcontratación. La cantidad de horas a asignar y el seniority del equipo son algunos de los elementos que se deben examinar con calma antes cerrar un contrato.
  • Considera buscar un partner que pueda alinearse en cuanto a huso horario, de esta manera la comunicación será mucho más fluida.

Una vez que hemos encontrado al profesional que se adapta a todas nuestras necesidades, es momento de crear una dinámica de trabajo favorecedora cuya organización sea clave para lograr los objetivos propuestos en el tiempo esperado. Algunas de las acciones que como empresa debes tomar en cuenta son las siguientes:

Define tus expectativas con este proceso
Es importante que el partner sepa qué se espera exactamente de su trabajo y por qué fueron seleccionados, esto ayudará a sentar las bases de una buena relación comercial, así como un mejor rendimiento del proyecto. A partir de esto se puede identificar los indicadores de medición del servicio.

Provee a tu partner todo el conocimiento necesario sobre la industria
Un checklist sobre las actividades o procesos que se requieren no es lo más indicado, es necesario que tu partner internalice las necesidades del negocio, cuáles son los clientes finales y qué necesitan, cuáles son las expectativas de la industria, entre otros. Involucra a este profesional como parte del equipo de trabajo, como un miembro más de la compañía, y es muy probable que obtengas mejores resultados. En Huenei la primera fase de ejecución del servicio AMO es la capacitación y la transferencia del conocimiento de aquellos que actualmente son los responsables de las aplicaciones.

No olvides medir y comparar
Para entender qué puedes mejorar y cómo ha estado el rendimiento en general de tu proyecto, es importante llevar las métricas correctas y actualizadas. De esta manera será posible implementar las correcciones que el área requiera en lugar de tener retrocesos o continuar con estrategias poco eficientes. En Huenei emitimos mensualmente métricas a nuestros clientes para medir la calidad del servicio (se puede incluir alguna gráfica).

Define la estrategia de tu empresa
Es sumamente importante que tu partner entienda el camino que deben recorrer, cuáles son las fases y objetivos a cumplir a corto, mediano y largo plazo sin necesidad de llegar a un punto muerto y preguntarse “¿ahora qué sigue?”. La planificación anual del servicio permite contar con una hoja de ruta para asignar los requerimientos del backlog de necesidades del negocio.

Determina fechas claras de entrega
Mantener un hoja de ruta actualizado que indique cuáles procesos o plataformas serán tercerizadas y en qué tiempo, será determinante para obtener los resultados que se esperan y sin atrasos. Esto le permite a tu partner identificar la demanda de recursos.

Nunca dejes de preguntarte “cómo podemos mejorar”
La mejora continua es sin duda la clave para un trabajo exitoso cuando de tercerización se trata. Mantén a todo el equipo motivado e informado sobre cada aspecto relevante del negocio e indaga siempre cómo pueden seguir agregando valor al trabajo que realizan.

Conclusión
Nos encontramos en un mundo cada vez más competitivo, por ello es importante que las empresas puedan implementar sistemas más eficientes para satisfacer las necesidades de sus clientes y seguir mejorando dentro de la industria.

En este sentido, dedicar tiempo y dinero a optimizar sus propios recursos y sistemas de la mano de expertos en tecnología como sucede con el outsourcing, es sin duda una de las formas más inteligentes y rentables de hacer crecer tu negocio.

¿Realizar AMO beneficia mi negocio?

¿Realizar AMO beneficia mi negocio?

La mayoría de las compañías invierten cada vez más recursos en la administración y mantenimiento de sus aplicativos, resultado de sumar cada vez más tecnologías con distintas funcionalidades, haciendo más competitivo el negocio. Debido a la ya mencionada creciente inversión de esfuerzos, son varios los líderes de IT que han recurrido a la tercerización del mantenimiento de aplicaciones.

Este tipo de estrategia cuenta con diversos beneficios tan importantes como enfocar los talentos de la empresa en áreas de mayor valor agregado, como suelen ser la innovación y optimización de procesos varios.
Además, cuando se opta por la tercerización en la administración y mantenimiento de aplicaciones se logra que las empresas puedan garantizar el rendimiento en servicios predeterminados para sus requerimientos de soporte, así como en personal destinado a invertir tiempo valioso en el traspaso de conocimientos en materia de soporte.

Gracias a la tercerización se pueden optimizar procedimientos y procesos de la compañía que intervienen directamente en la administración y mantenimiento de los sistemas de TI, al mismo tiempo que se consigue una visibilidad plena de cada servicio de asistencia y rendimiento con respecto a los SLA.

¿Qué es Applications Management Services (AMS)?
El concepto de Application Management Services o mejor conocido por sus siglas AMS se basa en externalizar los requerimientos de soporte de una aplicación, valiéndose de un proveedor externo especializado en el monitoreo, revisión y mantenimiento de cualquier aplicación. En otras palabras, AMS hace referencia a la acción de delegar ciertos procedimientos que de preferencia no deberían ser realizados un equipo de TI interno, sencillamente porque es más eficiente que los realice un agente experto.

¿Cómo saber si necesito AMS?
Para decidir si es momento de aplicar AMS en una compañía deben considerarse lo siguiente:

  • El coste del mantenimiento y monitoreo de las aplicaciones se mantiene en aumento.
  • Toda aplicación suele presentar fallos, problemas o incidencia que deben esperar hasta 24 horas o más para que se determine y se repare la falla.
  • Usualmente, el equipo de desarrollo interno no suele tener la suficiente experiencia porque la complejidad del tema requiere de un enfoque único y de investigación constante.
  • También es importante en caso de que algún miembro del equipo abandone la compañía y no deje la documentación necesaria para hacer el traspaso de información.

Tipos de AMS que puede aplicarse a una empresa:
Cuando hablamos de tercerización, las compañías pueden decantarse por al menos dos fórmulas:

  • Subcontratación completa: se espera del proveedor un servicio total por lo que este se encarga de la gestión cabal de las actividades que se relacionan con el soporte, la actualización y optimización de las aplicaciones. De esta manera, el proveedor debe proporcionar no solo servicios de tecnología, sino que también deberá ofrecer recomendaciones e ideas para optimizar y evolucionar la aplicaciones de una forma más beneficiosa de acuerdo a los nuevos requisitos comerciales. Además, debe encargarse de estructurar, facilitar y aplicar iniciativas de innovación digital pertinentes.
  • Subcontratación selectiva: En este caso, se encarga al proveedor el manejo de solo un determinado aspecto de la gestión de la aplicación que puede ser solucionar problemas o hacer más eficiente la aplicación. También puede delegarse un conjunto de aspectos específicos como supervisión, gestión del rendimiento, solución de fallas e incidentes y actualización de la aplicación.

Beneficios de implementar AMS en una empresa:

  • Soporte técnico y monitoreo permanente: el proveedor de tercerización queda a cargo de las operaciones centrales, por lo que la renuncia de un miembro del equipo, ausencia por vacaciones o reposo médico ya no serán una preocupación para la compañía, ni para el resto del equipo. Con un socio de AMS, nadie tendrá que asumir trabajo adicional y mayor estrés durante el proceso de capacitación y contratación.
  • Acceso a todas las novedades tecnológicas: delegar la revisión y mantenimiento de las aplicaciones a un proveedor especializado que dé soluciones enfocadas para AMS, es también una oportunidad para ir obteniendo toda la nueva tecnología que se va gestando en el área. La mayoría de los proveedores de servicios administrados cuentan con profesionales expertos en una gran variedad de aplicaciones.
  • Aprovechamiento de la tercerización para optimizar servicios adicionales: cuando se externaliza con un proveedor de soluciones que ofrece buenos resultados, también puede confiar otras funciones centrales de la compañía a ese mismo proveedor. Es una gran ventaja porque este proveedor tiene conocimiento sobre cómo opera su negocio por lo que puede aportar ideas o soluciones para servicios adicionales que ayuden a mejorar a la compañía en general.
  • Mayor oportunidad para que la empresa pueda crecer: Si aumenta el alcance del proyecto del cual el equipo subcontratado se está encargando o se extiende la cartera de aplicaciones, es mucho más fácil escalar e incluir más miembros que puedan estar al día con los retos de crecimiento de la empresa.
  • Se minimiza el riesgo de tiempo de inactividad: la tercerización para mantenimiento de aplicaciones garantiza la continuidad del trabajo de TI y reduce cualquier tiempo de inactividad que pueda afectar tanto a la empresa como a los clientes. Debido a que el equipo de AMS se encarga de optimizar o implementar nuevos sistemas o nuevas tecnologías, el resto del equipo de la empresa puede permanecer enfocado en el negocio principal.

Conclusión
El proveedor de AMS asume la responsabilidad de administrar una buena parte o la totalidad de las aplicaciones de su cliente, todo depende de lo que la compañía necesite. Este servicio se centra en hacer más eficiente la gestión, implementación o soluciones de los problemas que se presenten, a fin de aumentar el valor comercial de las aplicaciones.

Un equipo de AMS no solo se enfoca en aspectos de importancia como el ahorro de costos, también pueden ocuparse de los requisitos estratégicos de las empresas que los contraten. Lo mejor de este servicio es que son capaces de conocer a ciencia cierta el valor de las aplicaciones y trazar una ruta para su evolución en el futuro.

¿Qué Metodología Ágil es la mejor para mi proyecto?

¿Qué Metodología Ágil es la mejor para mi proyecto?

En los últimos años, las Metodologías Agiles han evolucionado para adaptarse a las diversas necesidades de proyectos tecnológicos, buscando siempre aumentar la productividad y efectividad en la planificación, desarrollo y ejecución de los mismos.
Existen al menos 5 metodologías que han logrado tener mayor aceptación por parte de empresas de tecnología y Desarrollo de Software, ya sea porque se ajustan a los requerimientos específicos de cada uno o porque determinadas industrias ya que encuentran más familiarizadas.
Entre las Metodologías Ágiles más conocidas podemos encontrar:

Scrum
Es uno de métodos ágiles más utilizados actualmente, conocido por su marco de trabajo basado en la iteración de los procesos, apoyándose en equipos de autogestión. Este método divide el trabajo en objetos o entregables, los cuales se estiman y se priorizan en función del esfuerzo. Es capaz de optimizar el plan de estratega y de prioridades según las necesidades de cada cliente.
Scrum promueve el orden en los pequeños equipos de autogestión e interdisciplinas, distribuyendo el tiempo de trabajo en iteraciones fijas que crean productos entregables a su objetivo final.
Pros:

  • Otorga mayor facilidad a la hora de ordenar grandes y complicados proyectos dividiéndolos en partes más pequeñas.
  • Permite mayor control y gestión sobre cómo se está llevando a cabo el proyecto.
  • Se optimiza enormemente el tiempo y utilización de los recursos.

Contras:

  • Presenta dificultad para ordenar al equipo por primera vez.
  • Si el cliente no está familiarizado con esta metodología, puede costar al principio.
  • Se necesita incluir a personal capacitado específicamente en esta metodología, como un scrum master.

 
Kanban
Ampliamente conocida por sus “tarjetas visuales”, se basa en la creación de diagramas donde se apuntan las tareas en proceso, pendientes y las completadas dentro de un equipo de trabajo. Es ideal para entender qué entregables y actividades conforman un proyecto, así como para saber qué actividades son repetitivas, por lo que formarían parte de un proceso.
Pros:

  • Mejora el trabajo en equipo gracias a su foco en la planificación de las tareas.
  • Proporciona una gran coordinación de tiempo.
  • Facilita la asignación de los recursos dependiendo de sus destrezas.

Contras:

  • Alta inversión en recursos para su implementación.
  • Se adecúa mejor a proyectos repetitivos, como mantenimiento de servidores o aplicaciones.

 
Agile Inception
A diferencia de las otras, Agile Inception se encuentra orientada a la definición o re-definición de los objetivos generales que toda empresa debería tener.
Se encuentra avalada por método de “elevator pitch”, el cual consiste en pequeñas reuniones con el equipo, los miembros o socios, en donde las intervenciones no superen los 5 minutos de duración.
Pros:

  • El método elevator pitch ayuda a ejecutar proyectos con mayor agilidad, precisión, ahorro de tiempo y practicidad.
  • Ayuda a clarificar aspectos claves del proyecto, encontrar la propuesta de valor de las tareas en cuestión y encontrar la mejor estrategia aplicada.

Contras:

  • No es posible resumir todos los puntos a tratar en reuniones breves.
  • Es posible que se generen fallas en la comunicación ya que los participantes tienen poco tiempo para exponer sus ideas.

 
LEAN
Ha sido adquirida ampliamente por empresas de desarrollo al punto de ser conocida como Lean Software Development. Esta se centra en las necesidades del cliente basándose en tres puntos clave: La importancia de lo que hacemos para el cliente, los cambios a realizar para lograrlos y las correcciones constantes.
Su objetivo es lograr la “perfección” de los procesos y tareas al eliminar todo aquello que es redundante o que no crea un verdadero valor, empoderando a los empleados y aumentando la visibilidad en ell proceso.
Pros:

  • Brinda mayor claridad en los procesos y principios del equipo, eliminando todo lo que no aporte valor al trabajo.
  • Ofrece una construcción rápida y precisa de los proyectos.
  • Fomenta el trabajo en equipo, rescatando los valores de responsabilidad y comunicación asertiva.

Contras:

  • Posee alta dependencia del equipo y de la cohesión que tengan este entre sí, la disciplina aplicada y la correcta toma de decisiones.
  • Se necesitan procesos muy aceitados para que funcione correctamente, por lo que al principio se tendría que incurrir en la prueba y error.

Los principios de LEAN se pueden establecer para diferentes tipos de proyectos, incluso combinados con otros métodos ágiles en el desarrollo de software, productos o proyectos.
 
XP or Programación Extrema
Está basada en un conjunto de buenas prácticas en el desarrollo de software en entornos muy cambiantes con requisitos específicos, así como las reglas y el orden enfocado en la retroalimentación continua del cliente y el equipo de trabajo.
Pros:

  • Ayuda a medir el alcance de un proyecto, así como los recursos a invertir.
  • Facilita el entendimiento de cómo se invierte el esfuerzo y fomenta el minimizar los errores.
  • Tiene como foco la satisfacción del cliente y la simplicidad de los procesos.

Contras:

  • Solo es indicado para proyectos de corto alcance.
  • Requiere un rígido ajuste a los principios de trabajo, ya que no es de fácil aplicación en los equipos al inicio.

 
Conclusión
Los avances tecnológicos y las exigentes dinámicas de los mercados han impulsado la creación de nuevos métodos de gestión para los procesos, así como estrategias y herramientas que optimizan el rendimiento y consiguen mejores resultados.
La satisfacción del cliente es la base principal de las Metodologías Ágiles, buscando que las empresas tengan una relación más eficiente con sus clientes actuales y potenciales. Por si fuera poco, permiten la reducción de tiempo y de costes.