Menú

ADOPTAR?

  • La adopción continua de contenedores para los despliegues, en particular Docker, ha tornado el análisis de seguridad de los contenedores en una técnica necesaria, y hemos movido esta técnica a “Adoptar” para reflejar este hecho. En particular, los contenedores introdujeron una nueva vía para los problemas de seguridad; es vital que se utilicen herramientas para analizar y revisar los contenedores durante el despliegue. Preferimos utilizar herramientas de análisis automático que corran como parte del pipeline de despliegue.

    Historia
  • Hoy en día, la respuesta de muchas empresas para acceder a datos para su uso analítico es construir un laberinto complejo de pipelines de datos. Estos pipelines recogen los datos de una o múltiples fuentes, los limpian, los transforman y los mueven a otra ubicación para su consumo. Este acercamiento al manejo de datos muchas veces deja a los pipelines consumidores con la difícil tarea de verificar la integridad de los datos entrantes y construir una lógica compleja para limpiar esos datos y permitir que lleguen al nivel requerido de calidad. El problema fundamental con esto es que la fuente no tiene ningún incentivo ni responsabilidad a la hora de proveer datos de calidad para sus consumidores. Por esta razón, abogamos por la integridad de los datos en su origen, lo cual quiere decir que cualquier fuente que provea datos consumibles debe describir explícitamente sus medidas para lograr la calidad y garantizar aquellas medidas. La razón principal detrás de esto es que los sistemas y equipos de origen son los más familiarizados con sus datos y los que están en mejor posición para arreglarlos en la fuente. La arquitectura Malla de datos lleva esto un paso más allá, comparando los datos consumibles a un producto, donde la calidad de estos y sus objetivos son atributos integrales de cada colección de datos compartida.

    Historia
  • Hemos visto beneficios significativos al utilizar microservicios, estos han permitido a los equipos escalar la entrega de servicios desplegados y mantenidos de manera independiente. Desafortunadamente, hemos visto a equipos creando monolitos en el front-end — una gran aplicación web y enredada sobre servicios back-end — neutralizando en gran parte los beneficios de los microservicios. Los micro frontends continúan ganando popularidad desde que se presentaron por primera vez. Hemos visto a muchos equipos adoptar de alguna manera esta arquitectura para manejar la complejidad de múltiples desarrolladoras/es y equipos contribuyendo en la misma experiencia de usuario. En junio de este año, uno de los autores de esta técnica, publicó un artículo que sirve de referencia como un introductorio a micro frontends. Este muestra cómo se puede implementar este estilo utilizando varios mecanismos de programación web así como la construcción de una aplicación React.js. Estamos seguras/os en que éste estilo crecerá en popularidad a medida que las organizaciones descompongan el desarrollo UI en varios equipos.

    Historia
  • El uso de pipelines de entrega continua para orquestar el proceso de entrega de software se ha vuelto un concepto popular. Herramientas de CI/CD pueden ser usadas para testear configuraciones de servidores (ej: Packer), aprovisionamiento de ambientes (ej: Terraform, CloudFormation) y la integración de ambientes. El uso de pipelines para infraestructura como código permite encontrar errores antes de que los cambios sean aplicados en los entornos operacionales - incluyendo entornos utilizados para desarrollo y test. También ofrecen una manera de asegurar que las herramientas de infraestructuras se están ejecutando consistentemente, utilizando agentes CI/CD en vez de workstations individuales. Nuestros equipos han tenido buenos resultados utilizando esta técnica en sus proyectos.

    Historia
  • Automatizar la estimación, seguimiento y proyección del coste de ejecución de una infraestructura en la nube es necesario para las organizaciones de hoy. Los modelos inteligentes de precios de los proveedores de la nube, combinados con la proliferación de los parámetros de precios y la naturaleza dinámica de la arquitectura de hoy pueden llevar a un costo de ejecución sorprendentemente alto. Por ejemplo, los precios de serverless basados en llamadas API, de soluciones de streaming de eventos enfocadas en el tráfico o de procesamientos de grupos de datos basados en tareas corridas, tienen una naturaleza dinámica que cambia a lo largo del tiempo a medida que la arquitectura evoluciona. Cuando nuestros equipos manejan infraestructura en la nube, implementar el coste de ejecución como función de la aptitud de arquitectura es una de sus primeras tareas. Esto quiere decir que nuestros equipos pueden observar el costo de ejecutar los servicios en comparación al valor entregado; cuando ven desviaciones respecto a lo que se espera o es aceptable, discutirán si es momento de evolucionar la arquitectura. La observación y cálculo del coste de ejecución se implementa como una función automatizada.

    Historia
  • Cuando se adopta con éxito la entrega continua (CD), los equipos se esfuerzan por hacer que sus diversos ambientes de prueba se vean lo más cercanos posible a la producción. Esto les permite evitar errores que sólo se podrían ver directamente en el ambiente de producción. Esto sigue siendo igual de válido para softwares incrustados y del Internet de las cosas (Internet of Things); si no ejecutamos las pruebas en ambientes reales, podríamos encontrar algunos errores por primera vez en producción. Las pruebas utilizando dispositivos reales ayudan a evitar este problema asegurando que se utilicen dispositivos reales en el pipeline de entrega continua.

    Historia

PROBAR?

  • La potencia y promesa de machine learning ha creado una demanda de experiencia que supera la oferta de científicos de datos especializados en este área. Como respuesta a esta brecha de habilidades, hemos visto emerger herramientas como machine learning Automatizado (AutoML) que pretenden facilitar a personas sin expertise, la automatización de inicio a fin del proceso de selección y entrenamiento de modelos. Algunos ejemplos incluyen AutoML de Google, DataRobot, y the H2O AutoML interface. Aunque hemos visto resultados promisorios para estas herramientas, recomendamos a los negocios precaución al considerarlas como la suma total de su camino en el aprendizaje de máquinas. Tal y como se advirtió en H2O website, “todavía hay una buena cantidad de conocimiento y experiencia en ciencia de datos que es requerida para producir modelos de alto rendimiento de machine learning.”. La confianza ciega en técnicas de automatización también incrementa el riesgo de introducir sesgos éticos o tomar decisiones que desfavorecen a minorías. Si bien éstas herramientas son un punto de partida para generar modelos entrenados útiles, promovemos la búsqueda de data scientists con experiencia para validar y refinar los resultados.

    Historia
  • Como el uso de contenedores, el despliegue de un gran número de servicios por parte de equipos autónomos y aumento en la velocidad de la entrega continua se han convertido en una práctica muy común en muchas organizaciones, ha surgido la necesidad de controlar la seguridad de software al momento de despliegue de forma automatizada. La certificación binaria (Binary attestation) es una técnica para el control de la seguridad al momento de despliegue; esto significa que nos permite verificar criptográficamente que una imagen binaria está autorizada para su despliegue. Usando esta técnica, un certificador, un proceso de compilación automatizado o un equipo de seguridad firma los archivos binarios autorizando que pueden ser puestos a producción siempre y cuando hayan pasado los controles de calidad y pruebas requeridas. Servicios como la autorización binaria de GCP habilitada por Grafeas y herramientas como in-toto y Docker Notary permite la creación de certificaciones y validación de firmas de imágenes antes del despliegue.

    Historia
  • Con el aumento en popularidad de las aplicaciones basadas en machine learning, y la complejidad técnica que significa construirlas, nuestros equipos dependen mucho de la entrega continua para machine learning (CD4ML) para entregar estas aplicaciones de manera segura, rápida y sustentable. CD4ML es la disciplina de traer los principios y prácticas de entrega continua a las aplicaciones de machine learning. Elimina los largos ciclos entre el entrenamiento de los modelos y su despliegue a producción. CD4ML también elimina las transferencias manuales entre distintos equipos, ingenieras/os de datos, científicas/os de datos e ingenieras/os de machine learning en el proceso de extremo a extremo de construcción y despliegue de un modelo servido por una aplicación ML. Utilizando CD4ML nuestros equipos han logrado implementar de manera exitosa el versionamiento, prueba y despliegue automatizado de todos los componentes de sus aplicaciones basadas en ML: datos, modelos y código.

    Historia
  • Uno de los principales puntos de fricción para data scientists, en su flujo de trabajo, es ubicar los datos que necesitan, darles sentido y evaluar si es confiable usarlos. Esto sigue siendo un desafío debido a la falta de metadatos sobre las fuentes de datos disponibles y la falta de funcionalidad adecuada y necesaria para buscar y localizar datos. Alentamos a los equipos que están proporcionando conjuntos de datos analíticos o construyendo plataformas de datos para que el descubrimiento de datos sea una función de primera clase en sus entornos; para proporcionar la capacidad de localizar fácilmente los datos disponibles, detectar su calidad, comprender su estructura, linaje y tener acceso a ellos. Tradicionalmente, esta función ha sido proporcionada por soluciones de catalogación de datos inflados. En los últimos años, hemos visto el crecimiento de proyectos de código abierto que están mejorando las experiencias de las/os desarrolladoras/es, tanto para proveedores de datos como para consumidores de datos, para hacer una cosa realmente bien: hacer que los datos sean reconocibles. Amundsen de Lyft, y WhereHows de LinkedIn están entre estas herramientas. Lo que nos gusta ver es un cambio en el comportamiento de los proveedores para compartir intencionalmente los metadatos que ayudan a la capacidad de descubrimiento en favor de las herramientas de descubrimiento que infieren información de metadatos parcial de silos de bases en datos de aplicaciones.

    Historia
  • Muchos equipos y organizaciones no tienen métodos formales o consistentes de hacer seguimiento a las dependencias técnicas en su software. Este problema muchas veces aparece cuando el software tiene que ser modificado y el uso de una versión obsoleta de una biblioteca, API o componente, ocasiona trabas o demoras. La función de aptitud para montículos de dependencias es una técnica que introduce una función de aptitud de arquitectura evolutiva específica para hacer seguimiento a estas dependencias a lo largo del tiempo. De manera que se da un indicio del trabajo posiblemente requerido y si un problema potencial está mejorando o empeorando.

    Historia
  • A medida que el desarrollo de aplicaciones se vuelve cada vez más dinámico y complejo, es un reto conseguir la entrega eficiente de productos accesibles y usables que tengan estilos consistentes. Design systems define una colección de patrones de diseño, librerías de componentes y buenas prácticas de diseño y desarrollo que aseguran la consistencia en el desarrollo de productos digitales. Vemos a design systems como una herramienta adicional, útil cuando trabajamos con múltiples equipos y disciplinas en el desarrollo de producto, porque permiten a los equipos enfocarse en retos más estratégicos del producto sin necesidad de reinventar la rueda cada vez que se necesita agregar un componente visual. Los tipos de componentes y herramientas que uses para crear design systems pueden variar mucho.

    Historia
  • El trabajo cotidiano de machine learning implica una serie de experimentos al seleccionar el enfoque del modelado, la topología de red, datos de entrenamiento y varias optimizaciones y ajustes al modelo. Ya que varios de estos modelos aún son difíciles de interpretar o explicar, los científicos de datos deben usar su experiencia e intuición para hipotetizar cambios y medir el impacto de los mismos en el rendimiento general del modelo. Dado que estos modelos se han vuelto cada vez más comunes en sistemas de negocio, varias herramientas de seguimiento para experimentación con machine learning han surgido para ayudar a los investigadores a llevar registro de estos experimentos y su trabajo metódicamente. Aunque no hay una ganadora, herramientas como MLflow o Weights & Biases y plataformas como Comet o Neptune han introducido rigor y reproductibilidad en todo el flujo de trabajo de machine learning. También facilitan la colaboración y ayudan a convertir la ciencia de datos de un esfuerzo solitario a un esfuerzo de equipo.

    Historia
  • Las redes neuronales profundas han sido tomadas en cuenta por su precisión en una amplia variedad de problemas. Alcanzados los suficientes datos de capacitación y la selección de una apropiada topología, estos modelos alcanzan y exceden las capacidades humanas en selectos campos de problemas. Sin embargo, resultan ser por naturaleza opacos. Aunque algunas partes de los modelos se pueden reutilizar mediante el aprendizaje por transferencia, pocas veces somos capaces de atribuir algún significado comprensible para los humanos a estos elementos. Por el contrario, un modelo explicativo es aquel que nos permite entender cómo se tomó cierta decisión. Por ejemplo, un árbol de decisión produce una cadena de inferencia que describe el proceso de clasificación. La explicabilidad se vuelve crítica en ciertas industrias reguladas o cuando nos preocupa el impacto ético de una decisión. A medida que estos modelos se adoptan más ampliamente en sistemas críticos del negocio es importante tomar en cuenta la explicabilidad como un criterio relevante al seleccionar un modelo. A pesar de su poder, las redes neuronales podrían no ser una elección acertada cuando existen estrictos requerimientos de explicabilidad.

    Historia
  • Las políticas de seguridad son reglas y procedimientos que protegen a nuestros sistemas de amenazas y alteraciones. Por ejemplo, las políticas de control de acceso definen y resguardan quiénes pueden acceder a qué tipo de servicios y de recursos y bajo qué circunstancias; o las políticas de seguridad de redes pueden limitar dinámicamente la velocidad del tráfico a un servicio en particular. El complejo panorama tecnológico de hoy exige tratar las políticas de seguridad como código: definir y mantener esas políticas bajo control de versionamiento, validarlas automáticamente, desplegarlas automáticamente y monitorear su desempeño. Herramientas tales como el Open Policy Agent o plataformas como Istio proveen mecanismos flexibles de definición y ejecución de políticas que apoyan la práctica de tratar las políticas de seguridad como código.

    Historia
  • Muchas de las soluciones técnicas que creamos hoy en día se ejecutan en entornos polycloud o nube híbrida cada vez más complejos con múltiples componentes y servicios distribuidos. En tales circunstancias, aplicamos dos principios de seguridad al inicio de la implementación: red Zero trust donde se recomienda nunca confiar en la red y siempre hacer verificaciones, y el principio del privilegio mínimo, otorgando los permisos mínimos necesarios para realizar un trabajo en particular. Los Sidecars para seguridad de endpoints son una técnica común que utilizamos para implementar estos principios y así cumplir los controles de seguridad en cada endpoint del componente. Ej: APIs de servicios, almacenes de datos, control de interfaces de Kubernetes. Hacemos esto usando un sidecar fuera de proceso: un proceso o un contenedor que se implementa y programa con cada servicio que comparte el mismo contexto de ejecución, host e identidad. Open Policy Agent y Envoy, son herramientas que implementan esta técnica. Los Sidecards para seguridad de endpoints minimizan la huella confiable en un endpoint local en lugar del perímetro de la red. Nos gusta ver que la responsabilidad de la configuración de la política de seguridad del sidecar recae en el equipo responsable del endpoint y no en un equipo centralizado separado.

    Historia
  • Zhong Tai se ha convertido en una palabra de moda en la industria de TI China por años, pero todavía tiene que popularizarse en el oeste. En su núcleo, Zhong Tai es un enfoque para entregar modelos de negocio encapsulados. Está diseñado para ayudar a una nueva generación de pequeños negocios que entregan servicios de primera clase sin los costes de infraestructura de las empresas tradicionales y habilitando a las organizaciones a proporcionar servicios innovadores a velocidades vertiginosas. La estrategia de Zhong Tai fue propuesta originalmente por Alibaba y pronto fue seguida por muchas compañías de internet Chinas, porque su modelo de negocio es nativo digital para replicar los nuevos mercados y sectores. Hoy en día, más firmas Chinas están utilizando Zhong Tai como palanca para la transformación digital.

    Historia

EVALUAR?

  • BERT (Bidirectional Encoder Representations from Transformers) es un nuevo método de representación de lenguaje pre-entrenado publicado por investigadores de Google en Octubre de 2018. BERT ha modificado significativamente el ecosistema del procesamiento del lenguaje natural (PLN) obteniendo resultados vanguardistas en una amplia gama de tareas de PLN. Basado en una arquitectura Transformer, durante el entrenamiento aprende del contexto de un token tanto por la derecha como por la izquierda. Google también ha publicado modelos pre-entrenados de propósito general para BERT que han sido entrenados en un gran corpus de texto no etiquetado, incluyendo la Wikipedia. Developers pueden usar y ajustar estos modelos pre-entrenados para los datos específicos de su tarea y conseguir grandes resultados. Hablamos acerca de transferencia de aprendizaje en PLN en nuestra edición de Abril de 2019 del Radar; BERT y sus sucesores continúan haciendo que la transferencia de aprendizaje para PLN sea un campo muy interesante, reduciendo significativamente el esfuerzo para usuarios que lidian con la clasificación de texto.

    Historia
  • Malla de datos es un paradigma de arquitectura que desbloquea datos analíticos a escala; rápidamente desbloquea accesos a un número cada vez mayor de conjuntos distribuidos de datos de dominio, para una proliferación de escenarios de consumo tales como aplicaciones de aprendizaje automático, análisis o uso intensivo de datos en toda la organización. Malla de datos aborda los modos de fallas comunes de los data lakes centralizados tradicionales o de la arquitectura de plataforma de datos, con un cambio desde el paradigma centralizado de un lake, o su predecesor, el data warehouse. Malla de datos cambia a un paradigma que traza desde una arquitectura distribuida moderna: considerando dominios como los asuntos de primera clase, aplicando platform thinking para crear una infraestructura de datos de autoservicio, tratamiento de datos como un producto, e implementando estandarización abierta para habilitar un ecosistema de productos de datos distribuidos inter-operables.

    Historia
  • Durante el año pasado, hemos visto cambios en el interés en torno al aprendizaje automático y redes neuronales profundas en particular. Hasta ahora, el desarrollo de herramientas y técnicas ha sido impulsado por la emoción de las capacidades singulares de estos modelos. Sin embargo, actualmente existe una preocupación creciente de que estos modelos pueden causar daño involuntario. Por ejemplo, un modelo puede ser entrenado para hacer decisiones de crédito rentable al excluir simplemente a solicitantes desfavorecidos. Afortunadamente, estamos viendo un interés creciente en pruebas de sesgo ético que ayudará a descubrir decisiones potencialmente dañinas. Herramientas como lime, AI Fairness 360 o What-if pueden ayudar a descubrir imprecisiones que resultan de grupos subrepresentados en datos de entrenamiento y herramientas de visualización tales como Google Facets o Facets Dive pueden ser usados para descubrir subgrupos dentro de un corpus de datos de entrenamiento. No obstante, este es un campo en desarrollo y esperamos que normas y prácticas específicas sobre pruebas de sesgo ético surjan con el tiempo.

    Historia
  • El entrenamiento de los modelos generalmente requiere recolectar los datos desde su fuente y transportarlos a una localización centralizada donde corre el algoritmo de entrenamiento.Esto se vuelve particularmente problemático cuando los datos utilizados para el entrenamiento consisten en información personal identificable. Nos incentiva el auge del aprendizaje federado como un método de entrenamiento para diversos sets de datos que permite preservar la privacidad. Las técnicas utilizadas en el aprendizaje federado permiten que los datos permanezcan en el dispositivo del usuario y bajo su control, contribuyendo igualmente con una colección de datos para el entrenamiento de modelos. Para eso, el dispositivo actualiza un modelo independientemente; luego los parámetros del modelo, en lugar de los datos, son combinados en una vista centralizada. El ancho de banda y las limitaciones computacionales del dispositivo representan retos técnicos significativos, pero nos gusta como el aprendizaje federado deja al usuario en control de su propia información personal.

    Historia
  • La tendencia que empezó como backend como servicio para aplicaciones móvil nativas hace ya varios años, ahora se está popularizando con aplicaciones web.Estamos viendo frameworks de trabajo como Gatsby.js que combinan la generación de sitios estáticos y el renderizado del lado de cliente con APIs de terceros. Referido como JAMstack (donde JAM significa JavaScript, API, y Markup), este enfoque puede proveer una valiosa experiencia de usuario en aplicaciones web que dependen mayormente de APIs y ofertas de SaaS. Ya que el HTML se renderiza o bien en el navegador o durante el tiempo de compilación, el modelo de despliegue es el mismo que usan los sitios generados de manera completamente estática, con todos sus beneficios: la superficie de ataque en el servidor es pequeña y se puede lograr gran rendimiento con bajo uso de recursos. Despliegues como estos también son ideales para una red de distribución de contenidos. De hecho, jugamos con la idea de nombrar a esta técnica aplicaciones CDN first (CDN primero).

    Historia
  • Cuando existe una clave compartida, vincular registros a partir de varios proveedores de datos resulta una tarea sencilla. Sin embargo, es posible que no siempre exista una; y aún cuando la haya, puede que no sea buena idea mostrarla por cuestiones de privacidad. La técnica de vincular registros conservando la privacidad (PPRL) con el filtro de Bloom permite el vínculo probabilístico de registros de varios proveedores de datos, sin revelar información de carácter personal. Por ejemplo, para vincular datos de dos proveedores, cada proveedor cifra estos datos personales mediante el filtro de Bloom para obtener claves vinculadas criptográficamente que luego se envían a través de un canal seguro. Tras recibir esos datos, los registros pueden vincularse calculando el índice de similitud entre conjuntos de estas claves de cada proveedor. Hemos observado que, entre otras técnicas, la de PPRL con filtros de Bloom sería escalable para conjuntos de datos de gran volumen.

    Historia
  • Los ciclos de aprendizaje semi-supervisados son una clase de flujo de trabajo de aprendizaje automático iterativo que aprovecha las relaciones que pueden encontrarse en datos no etiquetados. Estas técnicas pueden mejorar modelos al combinar grupos de datos etiquetados y no etiquetados de varias maneras. En otros casos, comparan modelos entrenados con diferentes subcolecciones de los datos. A diferencia del aprendizaje no supervisado, donde la máquina infiere clases de datos no etiquetados o de técnicas supervisadas o la colección de entrenamiento está completamente etiquetada, las técnicas semi-supervisadas sacan partido de una pequeña colección de datos etiquetados y una colección mucho más grande de datos no etiquetados.El aprendizaje semi-supervisado también está estrechamente relacionado a técnicas de aprendizaje activas donde a un humano se le dirige para que etiquete selectivamente puntos de datos ambiguous. Ya que los expertos humanos capaces de etiquetar datos de manera certera son un recurso escaso y que el etiquetar es a menudo la actividad que consume más tiempo en el flujo de trabajo del aprendizaje automático, las técnicas semi-supervisadas reducen los costes y hacen al aprendizaje automático más accesible a una nueva clase de usuarios.

    Historia

RESISTIR?

  • El antiguo término 10x engineer ha sido sometido a escrutinio estos pasados meses. Un hilo ampliamente distribuido en Twitter sugiere esencialmente que las compañías deben excusar comportamientos antisociales y dañinos para retener ingenieras/os que son percibidas/os como altamente eficientes (a nivel de output individual). Afortunadamente, muchas personas en la red social realizaron bromas sobre el concepto, pero el estereotipo del rol de “desarrollador/a rockstar” es todavía generalizado. En nuestra experiencia, grandes ingenieras/os no se guían por el output individual, sino por trabajar en equipos fantásticos. Es más eficiente construir equipos de gente con talento, tanto experiencias como backgrounds variados, que proporcionen los ingredientes precisos para el trabajo en equipo, el aprendizaje y la mejora continua. Estos equipos 10x pueden moverse más rápido, escalar rápidamente y ser mucho más resilientes, sin necesidad de justificar malos comportamientos.

    Historia
  • Cuando los equipos adoptan el concepto de micro frontends disponen de un número de patrones para integrar los micro frontends individuales en una aplicación. Como siempre, también existen anti-patrones. Uno común en este caso, es la integración de front-end a través de artefacto. Para cada micro frontend se construye un artefacto, normalmente un paquete NPM, que se sube a un repositorio. Un paso posterior, a veces en un flujo de construcción distinto, combina los paquetes individuales en un paquete final que contiene todos los micro frontends. Desde una perspectiva puramente técnica esta integración en tiempo de construcción da lugar a una aplicación funcional. Sin embargo, la integración a través de artefacto implica que, por cada cambio, el artefacto completo tiene que volverse a construir, lo que lleva tiempo y, muy probablemente, impacte negativamente en la experiencia de la persona desarrolladora. Lo que es peor, esta forma de integrar frontends también introduce dependencias directas entre los micro frontends en tiempo de construcción y, por tanto, provoca un mayor sobrecoste de coordinación.

    Historia
  • Llevamos ya un par de años construyendo arquitecturas serverless en nuestros proyectos y hemos notado que es muy fácil caer en la trampa de construir un monolito distribuido. Las arquitecturas Lambda pinball característicamente suelen perder de vista la lógica de dominio importante entre tanto enredo de Lambdas, buckets y colas, a medida que las solicitudes de estas rebotan, se incrementa entonces la complejidad de los gráficos en los servicios en la nube. Usualmente, es complicado testearlas como unidades, y las necesidades de la aplicación deben ser testeadas como un todo integrado. Un patrón que podemos utilizar para prevenir estas arquitecturas de pinball es diferenciar entre interfaces públicas y publicadas y aplicar límites de dominio con interfaces publicadas entre ellas.

    Historia
  • Hemos descubierto que cada vez más y más organizaciones tienen la necesidad de reemplazar sistemas heredados para mantenerse al día con las demandas de sus clientes (tanto internos como externos). Un antipatrón que continuamos viendo es la paridad de funcionalidades en migraciones heredadas, el deseo de retener una paridad de funcionalidad con lo antiguo. Consideramos que esto es una enorme oportunidad perdida. A menudo, los sistemas antiguos se han sobrecargado con el paso del tiempo, con muchas funcionalidades que los usuarios no utilizan (50% de acuerdo al reporte de 2014 de Standish Group) y procesos de negocio que han evolucionado con el tiempo. Reemplazar estas funcionalidades es perder el tiempo. Nuestro consejo: Convence a tus clientes a dar un paso atrás y entender lo que sus usuarios necesitan actualmente, para luego priorizar estas necesidades en base a resultados comerciales y métricas — lo que usualmente es más fácil de decir que de hacer. Esto significa que se debe conducir una investigación de usuarios y aplicar prácticas modernas de desarrollo de producto en lugar de simplemente reemplazar las existentes.

    Historia
¿No encuentras aquello que querías ver?

Cada edición del radar incluye blips que contienen la información encontrada durante los últimos seis meses. Es posible que ya hayamos incluido el tema que estás buscando en radares anteriores. Hay veces que omitimos algunos temas debido a que hay demasiado de que hablar. O también, puede faltar algo debido a que en el radar buscamos reflejar nuestra experiencia, no lo basamos en un análisis exhaustivo del mercado.

Nuevo o modificado,Ningún cambio