Qué es ESG ESG es una sigla que reúne acciones, prácticas y frentes de trabajo relacionados con la temática Medio Ambiente, Social y Gobernanza. Esta tríada constituye un conjunto de prácticas y principios corporativos que ya son ineludibles como motor de inversiones, reputación y participación en mentes y corazones. Ya se ha demostrado la correlación positiva entre el desempeño ESG (cuando se ejecuta de manera estratégica, holística y genuina) y un resultado superior tanto en términos financieros como reputacionales. Estos artículos de Harvard Business Review y el Centro para Negocios Sostenibles de la Universidad de Nueva York explican esta correlación en detalle. Y este vídeo de la consultora KPMG explica de forma más sucinta qué es ESG. Cualquiera que quiera hacer un curso rápido para profundizar un poco más, le recomiendo este de la consultora y socio de Softplan, Deep ESG. El año pasado Softplan empezó a profundizar en este tema. Mapear la relevancia de los impactos de la empresa en sus clientes (el grupo de interés más importante de la empresa junto con los empleados) es una de las múltiples iniciativas de un programa ESG. En una empresa como Softplan, donde nos consideramos "expertos en traducir conocimiento y tecnología en soluciones que simplifican e impactan diariamente la vida de miles de personas en Brasil y el mundo", impregnar este conocimiento en el área de desarrollo (aquí considerando producto, diseño, ingeniería de software y arquitectura) puede ser quizás la estrategia más eficaz para hacer valer esta afirmación. Recientemente completamos este trabajo de mapeo de soluciones que atienden a clientes del Sector Público, siguiendo este estándar muy estricto de Global Reporting Initiative. Impactos, hechos y cómo se combinan ESG y Tech Hablando de Seguridad de la Información, nuestro "maestro Jedi" Alexandre Golin enumeró, en 2009, los 4 principios de los Tribunales SAJ de la época: Integridad, Autenticidad, No repudio y No retroactividad (I Me atrevería a decir que tiene un quinto principio oculto que es el de la inviolabilidad). Desde entonces, se han mejorado muchos conceptos, prácticas y requisitos, incluso aquí en Softplan. Actualmente, estamos muy orgullosos de decir que estos cuatro (o cinco) principios guían todas las soluciones de la empresa. Pues bien, la Seguridad de la Información, combinada con la Privacidad de los Datos, fue considerada un impacto relevante por los clientes de todas las soluciones para el sector público. ¿Tiene dudas sobre la actualización de un determinado componente de la aplicación? ¿Existen muchos cursos gratuitos de Devops y no sabes cuál tomar? Las cuestiones relacionadas con la seguridad de la información y la privacidad de los datos siempre serán un refugio seguro. No nos olvidemos de la 'E' de Medio Ambiente, que también tiene que ver con Producto, Diseño, Desarrollo y Arquitectura. La reducción de las emisiones de carbono es un impacto relevante en prácticamente todas las soluciones. Algo que une a todas las soluciones de Softplan es la digitalización de procesos y la reducción del uso de papel. Por ejemplo, el lema de 1Doc es "¿Hagámoslo despegar?". El balance de las emisiones de CO₂ por la sustitución del papel, además de todo lo que no se emite por el papel no producido, transportado, almacenado y desechado, por los procesos digitales y sus emisiones derivadas del consumo energético de los centros de datos e infraestructuras suele ser positivo en más del 75%. Pero ¿y si les dijera que en 2022, los 92 tribunales de Brasil imprimieron más de 500 millones de hojas de papel? Estos datos provienen del conjunto de los Tribunales, que no necesariamente son del ámbito judicial. Es una maldita lástima, ¿verdad? Pero ¿por qué siguen imprimiendo tanto papel si más del 90% de su colección es digital? ¿Es sólo porque es más cómodo? Probablemente no. Nuestros diseñadores han invertido mucho en aportar mayor ergonomía y comodidad a nuestras pantallas, para minimizar la necesidad de imprimir. Este tema ofrece una hoja de ruta gigante de epopeyas, historias y descubrimientos. Y las métricas de resultados están aquí, frente a nosotros. Cada vez más organismos públicos cuentan con programas de logística sostenible donde se mide el consumo de papel. Y para aquellos a quienes les gusta la economía del comportamiento, aquí hay un consejo para insertar ese inteligente empujón al pie de cada página: "No imprimir este artículo evitó la deforestación de N árboles". Aún dentro de la 'E', Devops/DBAs que gestionan datos en la nube, ¿sabías que las consolas de AWS permiten la adopción de criterios de sostenibilidad? Puede seleccionar regiones más eficientes (máquinas nuevas y de mayor rendimiento, fuente de energía renovable), implementar “un diseño que garantice una alta utilización y maximice la eficiencia energética del hardware subyacente” y utilizar servicios administrados. Para quienes no lo saben, es un mundo nuevo y, en la mayoría de los casos, la sostenibilidad generará ahorros financieros y eficiencia operativa. Las operaciones de Softplan en el sector público permiten que nuestras soluciones tengan un impacto directo en millones de personas. ¡En 2022, los portales de acceso externo de nuestras soluciones tuvieron un volumen promedio de 4,3 mil millones de consultas y 3,2 millones de nuevos procesos/demandas por mes! Garantizar una entrega de calidad a los clientes significa mayor prosperidad, eficiencia y bienestar para la sociedad, que ahora tiene acceso a servicios públicos más eficientes y de mejor calidad. ¿Pero como asi? Pensemos en un Tribunal de Justicia: ¿Cómo medimos la eficiencia (ups, otro Impacto, y este quizás el más importante, dentro de la 'S' de Social) de un Tribunal? Sabemos cuáles son los resultados esperados de una Corte eficiente. Y también sabemos cómo nuestra solución contribuye directa e indirectamente a estos resultados. Este conocimiento, difundido dentro de los equipos (para reiterar, nuestro modelo operativo requiere conocimiento y propiedad en todos los niveles funcionales de las áreas finales), proporciona una referencia, tanto para los clientes como para nosotros, de qué priorizar, cuál es el ritmo de entregas y cómo. Midamos si las entregas están dando los resultados esperados. ¿Y qué importancia tiene para un Tribunal de Justicia? Debe proporcionar un canal para que los usuarios externos consulten y presenten demandas. Mejorar y ampliar el acceso de la sociedad a los organismos públicos también es un impacto mapeado. Este canal necesita tener amplio acceso (múltiples servicios) y ser ágil (performativo y con alta disponibilidad). ¿Te diste cuenta de que estas características, que tienen métricas muy objetivas, ya ofrecen los impulsores necesarios para el aseo personal? En términos de eficiencia, mapeamos un máximo de 4 indicadores por solución. Fue difícil (para nosotros y para los clientes), pero centrarnos en los más importantes nos ayuda a pensar en el panorama general. En el caso de Tribunales, uno de los indicadores mide las variaciones de stock de un año a otro, otro indicador mide la duración de los procesos, otro la capacidad de satisfacer la demanda (que es dinámica y depende de los insumos) y otro, la Meta 2 del CNJ, determina que los casos más antiguos deben ser juzgados primero. He aquí una fantástica guía para animar a equipos y clientes a diseñar e implementar soluciones que: reduzcan el stock de casos, priorizando los más antiguos, dentro de duraciones de proceso sostenibles y siempre vinculadas al benchmarking de Tribunales del mismo tamaño. Para los PM y PO que aman las matrices de priorización, aquí hay un plato completo para calificar historias y tareas. ¡Esta huella funciona para todas nuestras soluciones! Pensemos en Sider, que digitaliza innumerables servicios dentro de las estructuras de los departamentos de infraestructura y de caminos y autopistas. Aquí también tenemos el impacto del acceso de ciudadanos y empresas a estos servicios. Los portales de acceso actúan como mostradores de atención virtuales. ¿Y cómo se mide el nivel de este servicio? En primer lugar, el servicio tiene que ser disponible y amplio, hay que poder hacer de todo allí: consultar, abrir demandas, solicitar y acceder a información y documentos y pagar cosas. Luego, se puede evaluar el tiempo de servicio de los servicios principales. ¡El motor del desarrollo está aquí! Necesitamos ampliar el acceso y reducir el tiempo de servicio tanto como sea posible. Para ello, también tenemos que ser conscientes del marco regulatorio de los organismos. Cumplir con este marco también es un impacto relevante señalado por los clientes. Hay que reducir tiempos, respetando los trámites legales, trámites y plazos. Como Softplan tiene capilaridad y experiencia a nivel nacional, aquí podemos actuar como una red, como un centro, absorbiendo, alimentando, retroalimentando, transfiriendo y compartiendo conocimientos y buenas prácticas entre organismos de todo el país. Estoy bastante seguro de que alguien simplemente correlacionó esto con la transformación digital. Bueno, promover la transformación digital se consideró un impacto relevante en todas nuestras soluciones que atienden al sector público. Aquí ampliamos el alcance de ESG a los equipos de residentes, soporte, comunicación y relaciones. ¿Se da cuenta de cómo ESG y usted (compañero Dev, DBA, PM, PO, UXer, etc.) tienen mucho que ver entre sí? No es sencillo, pero tampoco es nada del otro mundo. En resumen: necesitamos definir los impactos y sus indicadores y métricas de una manera metodológicamente rigurosa, involucrando a los clientes y a los expertos internos (y externos) de una manera genuina. Recopilar y poner a disposición datos y evidencia en forma de indicadores. Utilice datos como insumo, considerando el contexto y las especificidades. No subestimes el entorno externo, ya que es complejo y dinámico. Impregnar conocimiento en el equipo. Fomentar el debate y el análisis crítico. Concéntrese siempre en el panorama general. ¿Cuáles son los principales impactos e indicadores que mueven la aguja? Concéntrate en ellos como prioridad. Garantizar que, con el tiempo, los impactos relevantes sigan siendo relevantes y los indicadores apropiados sigan siendo apropiados.  

Un temor para todo equipo es elegir una herramienta que rápidamente quedará obsoleta. Si ha estado desarrollando aplicaciones durante algunos años, probablemente ya haya experimentado esto. Por tanto, elegir buenas herramientas es una tarea que implica responsabilidad, ya que puede guiar el proyecto (y la empresa) hacia el éxito o hacia un mar de problemas y gastos. En este artículo, comprenderemos los usos y beneficios del marco Angular. Elegir un marco front-end no es diferente y también implica investigación y estudios. Elegir una “pila”, como la llamamos en este mundo, es trivial tanto para el presente como para el futuro. Sin embargo, en medio de esta elección surgirán algunas preguntas: ¿Encontraremos profesionales calificados para abordar este marco? ¿Podremos mantener un ritmo de actualizaciones? ¿Existe un plan bien definido sobre la dirección que tomará el marco? ¿Existe una comunidad (aquí también nos referimos a las grandes empresas que la apoyan) comprometida? Todas estas preguntas deben responderse antes de iniciar cualquier proyecto, ya que descuidar una pantalla puede generar escenarios devastadores para el producto y, en consecuencia, para la empresa y sus ganancias. Motivaciones para utilizar un marco Quizás la respuesta más directa es que a veces es bueno no seguir reinventando la rueda. Problemas rutinarios como manejar rutas para una aplicación web, o incluso controlar dependencias, generar paquetes optimizados para su publicación en producción, todas estas tareas ya tienen buenas soluciones desarrolladas y, por lo tanto, elegir un framework que te brinde este conjunto de herramientas es perfecto para ganar productividad, solidez en el desarrollo de una aplicación y además mantenerla siempre actualizada siguiendo las mejores prácticas. Además de las motivaciones directas, también puedo mencionar: La facilidad para encontrar herramientas que se integren con el framework La búsqueda de software de calidad, integrado con pruebas y otras herramientas que maduren el proceso de desarrollo Muchas situaciones y problemas ya han sido resueltos ( porque hay mucha gente trabajando con la tecnología) Motivaciones para usar el framework Angular: Construido usando Typecript, uno de los lenguajes más populares en este momento MVC Arquitectura Control e Inyección de Dependencia Modularización (con opción de carga diferida) Buenas bibliotecas para integración Comunidad grande y comprometida 1835 contribuyentes en el repositorio oficial Apoyado y mantenido oficialmente por el equipo de Google La solidez de Angular Actualmente, podemos afirmar claramente que el marco es estable y recibe actualizaciones frecuentes debido a su naturaleza de código abierto. Esto se debe a que lo mantiene el equipo de Google, que siempre busca dejar lo más claro posible la hoja de ruta de lo que está por venir, lo cual es muy bueno. Además, la comunidad Angular es muy activa y comprometida. Es difícil tener un problema que aún no se haya resuelto. Una de las preocupaciones de todo desarrollador es la de realizar cambios drásticos en una herramienta. Cualquiera que haya vivido el cambio de V1 a V2 de Angular sabe este dolor, el cambio fue prácticamente total. Sin embargo, el marco se basó correctamente en Typecript, lo que aportó robustez y otra razón para su adopción: con Typecript, tenemos posibilidades que Javascript por sí solo no puede resolver: escritura fuerte, integración con el IDE, facilitar la vida a los desarrolladores, reconocimiento de errores en el desarrollo. tiempo y mucho más. Actualmente, el framework se encuentra en la versión 17 y ha ido ganando cada vez más madurez y solidez, con el aumento de características innovadoras como el recientemente lanzado aplazar. Actualización fácil El marco proporciona una guía para cada actualización a través del sitio web https://update.angular.io, este recurso ayuda mucho a guiar la actualización de su proyecto. CLI completo Angular es un marco. Por lo tanto, al instalar tu paquete tendremos la CLI lista para lanzar nuevos proyectos, generar componentes, ejecutar pruebas, generar el paquete final y mantener actualizaciones para tu aplicación: Para crear tu primer proyecto, simplemente abre tu terminal y ejecuta el siguiente comando : Diseños de interfaz sólidos Si necesita un diseño para su aplicación que proporcione componentes listos para usar, como alertas, ventanas modales, avisos de snackbar, tablas, tarjetas, una de las posibilidades más populares es elegir Angular Material, un buen punto a Seguir su software es porque Google lo mantiene, por lo que cada vez que el marco avanza en versión, Material generalmente sigue esta actualización. Además de Material, existen otras opciones en la comunidad, como PrimeNG, que trae un conjunto de componentes muy interesante (y grande). Soporte de biblioteca Nx Angular tiene soporte completo para el proyecto Nx, lo que hace posible escalar su proyecto de una manera muy consistente, garantizando principalmente el almacenamiento en caché y posibilidades avanzadas para que pueda mantener y escalar su aplicación local o en su entorno de CI. A continuación se muestran algunos ejemplos específicos de cómo se puede utilizar Nx para mejorar un proyecto de Angular: Puede crear una biblioteca de Angular que se puede reutilizar en varios proyectos. Puede crear un monorepo que contenga todos sus proyectos de Angular, lo que facilita la colaboración entre equipos. Puede automatizar tareas de desarrollo comunes, como ejecutar pruebas e implementar sus proyectos. Pruebas (unitarias y E2E) Además de Karma y Protactor que nacieron con el marco, ahora puedes usar proyectos populares como Jest, Vitest y Cypress. Estado con Redux Una de las bibliotecas más utilizadas por la comunidad es NgRx Store, que proporciona gestión de estado reactiva para aplicaciones Angular inspiradas en Redux. GDE brasileños En Brasil actualmente contamos con dos GDE Angular, lo cual es importante para nuestro país y también para generar contenido Angular en portugués, trayendo noticias e insights siempre actualizados a nuestra comunidad directamente desde el equipo de Google. Loiane Gronner William Grasel Alvaro Camillo Neto Grandes empresas que utilizan y apoyan Quizás la más notoria sea Google, el mantenedor oficial del marco. La empresa tiene varios productos creados con Angular y en los últimos años ha apoyado aún más el desarrollo y la evolución de la herramienta. Un punto importante a la hora de elegir un framework es saber que grandes empresas lo están utilizando, porque nos da una señal de que esa herramienta tendrá soporte para actualizaciones y evolución ya que a nadie le gusta estar reescribiendo productos desde cero, aquí mencionaré algunas empresas globales. que lo utilizan Angular en sus productos, sitios web, servicios web: Google Firebase Microsoft Mercedes Benz Santander Dell Siemens Epic Blizzard's En el panorama nacional también tenemos ejemplos de grandes empresas que utilizan el framework con éxito, podemos mencionar algunos: Unimed Cacau Show Americanas Checklist Fácil Picpay ¿Quieres saber más? ¿Interesado en comenzar con Angular?  

¿Qué es un Modelo Arquitectónico y por qué es importante? Básicamente, un modelo arquitectónico es la estructura abstracta en la que se implementará su aplicación. "La arquitectura de software de un programa o sistema informático es la estructura o estructuras del sistema que abarca los componentes del software, las propiedades visibles externamente de esos componentes y las relaciones entre ellos". (Bass, Clements y Kasman, Arquitectura de software en la práctica) Para definir el modelo que mejor se adapta a tu proyecto, necesitamos conocer bien las estrategias de la empresa a corto, medio y largo plazo, los requisitos no funcionales y arquitectónicos del software, así como la curva de crecimiento de usuarios en el tiempo y el volumen de solicitudes. . Además de los puntos mencionados a lo largo de este artículo, todavía hay otros a tener en cuenta a la hora de decidir qué modelo arquitectónico aplicar. Como ejemplo, podemos enumerar: Preocupaciones de seguridad; Almacenamiento de datos; Lockins; Volumen total de usuarios; Volumen de usuarios simultáneos; TPS (transacciones por segundo); Plan de disponibilidad/SLA; Requerimientos legales; Disponibilidad en uno o más tipos de plataformas; Integraciones. El estudio de la arquitectura, los RA (requisitos arquitectónicos), los VA (variables arquitectónicas), los RF (requisitos funcionales), los RNF (requisitos no funcionales) y los criterios que definen cada uno de estos elementos influyen directamente en la elección del modelo correcto. La elección del modelo arquitectónico puede afectar todo el ciclo de vida de la aplicación. Por tanto, este es un tema que debemos tratar con mucha atención. El uso de MVP (especialmente aquellos que no entran en producción) puede ayudar mucho en esta tarea. Dan una oportunidad única de equivocarse, ajustar, volver a equivocarse, probar conceptos, ajustar y equivocarse tantas veces como sea necesario para que al final el software tenga la arquitectura en la versión más correcta, trayendo así las verdaderas ganancias de este. elección. Cómo se dividen los modelos arquitectónicos Es ideal dejar claro que como muchas definiciones en el mundo del software, qué son los modelos arquitectónicos y qué son pueden variar. Por eso, en este artículo intenté dividirlos en cuatro grandes grupos: monolíticos, semimonolíticos (o monolitos modulares), monolitos distribuidos (o microlitos) y microcomponentizados. Monolítico Modelo en el que todos los componentes forman una única aplicación o ejecutable integrados en un único código fuente. En este caso, todo se desarrolla, implementa y escala como una sola unidad. Figura 1 – Ejemplo de un modelo monolítico. Ventajas Simplicidad: a medida que la aplicación se trata como una unidad única y cohesiva, se vuelve más simple ya que todas las partes están contenidas en un único código fuente. Mayor adherencia a los Patrones de Diseño: teniendo en cuenta que contamos con un único código fuente, otro factor que lo facilita es que los propios patrones de diseño (Design Patterns, 01/2000) fueron escritos en tiempos de dominio monolítico, haciendo que la aplicación de incluso más adherente. Mayor rendimiento: debido a la baja latencia en la comunicación, los monolitos suelen tener un buen rendimiento, incluso utilizando tecnologías más obsoletas. Menor consumo de recursos: la baja complejidad, la simplicidad y la menor sobrecarga de comunicación entre capas favorecen un menor consumo de recursos. Solución de problemas más sencilla: la creación de entornos de desarrollo y depuración se facilita en los monolitos, ya que los componentes comparten los mismos procesos en ellos. Otro factor que podemos tener en cuenta es que los monolitos tienen menos puntos de fallo externos, simplificando la búsqueda de errores. Contras Tamaño de equipo limitado: las fallas relacionadas con la integración continua y los conflictos de fusión ocurren con mayor frecuencia en monolitos, lo que crea dificultades en el trabajo paralelo para equipos grandes. Escalabilidad: la escalabilidad puede estar limitada en ciertos aspectos. Incluso con facilidad en la escalabilidad vertical, la escalabilidad horizontal a menudo puede convertirse en un problema que podría afectar el crecimiento de la aplicación. Disponibilidad de ventanas: normalmente, para un monolito se intercambian ejecutables, lo que requiere una ventana de disponibilidad sin que los usuarios accedan a la aplicación, lo que no ocurre con otros modelos arquitectónicos que pueden utilizar otras técnicas de despliegue como Blue-Green o incluso trabajar con imágenes. o vainas. Única tecnología: la baja diversidad tecnológica muchas veces puede convertirse en un impedimento para el crecimiento de la aplicación al atender solo un tipo de sistema operativo, por ejemplo, o no atender plenamente las nuevas funcionalidades solicitadas por los clientes al no contar con actualizaciones que tengan capacidad para resolver complejos. problemas. Mayor gasto en compilación y ejecución: los monolitos grandes generalmente tardan mucho en compilarse y ejecutarse localmente, generando un mayor compromiso en el tiempo de desarrollo. Cuándo usar Baja escalabilidad y disponibilidad: si la aplicación tiene una escala limitada donde, por ejemplo, el número de usuarios es bajo o no es obligatoria una alta disponibilidad, el modelo monolítico es una buena solución. Aplicaciones de escritorio: el modelo monolítico es muy recomendable para aplicaciones de escritorio. Equipos de baja antigüedad: los modelos monolíticos, por su simplicidad y ubicación de componentes, permiten que los equipos de baja antigüedad trabajen con un mejor rendimiento. Recursos limitados: para una infraestructura limitada y con recursos escasos. Semimonolítico (o monolito modular) Modelo en el que las aplicaciones están compuestas por partes de estructuras monolíticas. En este caso, la combinación intenta equilibrar la simplicidad del modelo monolítico y la flexibilidad del microcomponentizado. Actualmente, este modelo arquitectónico suele confundirse con los microservicios. Figura 2 – Ejemplo de un modelo semimonolítico. Ventajas Aporta los beneficios de los modelos monolíticos y microcomponentizados: con esto, es posible mantener piezas como estructuras monolíticas y microcomponentizar solo los componentes que tienen una necesidad real. Diversidad tecnológica: posibilidad de utilizar diferentes enfoques tecnológicos. Infraestructura diversificada: este modelo se puede desarrollar para utilizar infraestructura tanto On Premise como Cloud, favoreciendo la migración entre ambas. Soporta equipos más grandes: la segmentación de componentes permite que varios equipos trabajen en paralelo, cada uno dentro de su propio ámbito. Especialidades Técnicas: debido a la segmentación se aprovechan mejor las hard skills del equipo como frontend, UX, backend, QA, arquitectos, etc. Contras Estandarización: debido a la gran cantidad de componentes que pueden aparecer en un modelo semimonolítico, la estandarización (o la falta de ella) puede convertirse en un problema importante. Complejidad: la complejidad inherente a este tipo de modelos también tiende a aumentar con nuevas funcionalidades. Por lo tanto, nuevas características como mensajería, almacenamiento en caché, integraciones, control de transacciones, pruebas, entre otras, pueden agregar aún más complejidad al modelo. Presupuesto: en modelos que soportan el uso de diferentes tecnologías con equipos grandes se necesitan profesionales más especializados y con mayor nivel de veteranía, lo que muchas veces se traduce en un mayor gasto en gastos de personal. Resolución de problemas complejos: la complejidad del modelo y la diversidad de tecnologías hacen que la resolución de problemas de la aplicación sea cada vez más difícil. Esto se debe a la gran cantidad de puntos de falla (incluidos los externos a la aplicación) que llegan a existir y la comunicación entre ellos. Cuándo usar Aceptado en Varios Escenarios: es un modelo flexible que puede afrontar varios escenarios, pero no siempre de la mejor manera. Poca Definición: en proyectos que tienen incertidumbres o incluso que no tienen la definición completa de sus requerimientos, este modelo es el más adecuado. En equipos medianos y grandes: como hemos comentado, la división de componentes en varios grupos facilita el trabajo paralelo en equipos medianos y grandes. Normalmente, los grupos tienen sus propios repositorios de código, lo que hace que el trabajo paralelo sea más ágil. Diverse Seniority: este modelo se beneficia de equipos con este formato, ya que el software semimonolítico presenta desafíos variados, tanto en la capa frontend como backend y en temas de infraestructura (IaC – Infrastructure as a Code). Infraestructura: para una infraestructura híbrida o basada en la Nube, este modelo es más aplicable. Es un modelo que permite, por ejemplo, la adopción gradual entre On-Premise y Cloud, facilitando la adaptación y minimizando los impactos operativos. Monolito distribuido Este modelado es un modelado "moderno" que también ha sido implementado y confundido con el modelo de microcomponentes/microservicios. "No deberías comenzar un nuevo proyecto con microservicios, incluso si estás seguro de que tu aplicación será lo suficientemente grande como para que valga la pena". (Fowler, Martín. 2015) En resumen, en este modelo arquitectónico el software se construye sobre la base del modelo monolítico, pero se implementa según el modelo microcomponenteizado. Actualmente muchos lo consideran un antipatrón. Figura 3 – Ejemplo de modelo de monolito distribuido. No valdría la pena enumerar las características pro (no sé si las hay), pero sí vale la pena mencionar las que van en contra: este modelo arquitectónico reúne los puntos negativos de los otros dos estilos con los que se combina. confundido. En él, los servicios están altamente acoplados y además tienen varios tipos de complejidad, tales como: operacional, testabilidad, despliegue, comunicación e infraestructura. El alto acoplamiento, especialmente entre servicios backend, trae serias dificultades de implementación, sin mencionar el aumento significativo de los puntos de falla en el software. Microcomponenteizado Modelo de software en el que todos los componentes están segmentados en partes pequeñas y completamente desacopladas. Dentro de los microcomponentes podemos mencionar: Microfronteras Microbases de datos Microvirtualizaciones Microservicios Microlotes mejores amigas API Figura 4 – Ejemplo de un modelo microcomponenteizado. "Un microservicio es un componente de aplicación orientado a servicios que tiene un alcance estricto, está fuertemente encapsulado, está débilmente acoplado, se puede implementar y escalar de forma independiente" (Gartner, s.f.). Las opiniones convergen para decir que cada microservicio que funcionó fue primero un monolito que se volvió demasiado grande para ser mantenido y llegó a un punto común de tener que ser separado. Ventajas Escalabilidad: la escalabilidad en este modelo se vuelve bastante flexible. Dependiendo de la necesidad, los componentes se escalan de forma específica. Desarrollo ágil: los equipos pueden trabajar de forma independiente en cada componente, lo que facilita la implementación continua y acelera el ciclo de desarrollo. Resiliencia: si un componente falla, no necesariamente afecta a toda la aplicación. Esto mejora la resiliencia general del sistema. Es importante tener en cuenta que existen enfoques de punto único de falla para evitar este tipo de problema. Tecnología diversificada: cada componente puede desarrollarse utilizando diferentes tecnologías, permitiendo elegir la mejor herramienta para cada tarea específica. Además, también favorece las habilidades existentes de cada equipo. Facilidad de Mantenimiento: los cambios en un componente no afectan automáticamente a otros, facilitando el mantenimiento y la actualización continua. Desacoplamiento: los componentes son independientes entre sí, lo que significa que los cambios en un servicio no afectan automáticamente a otros, facilitando el mantenimiento. Contras Costo: alto costo de todos los componentes de este modelo (entrada, salida, solicitudes, almacenamiento, herramientas, seguridad, disponibilidad, entre otros). Tamaño: el software microcomponente tiende a ser más grande en esencia. No sólo el tamaño de la aplicación, sino todo el ecosistema que la impregna desde el compromiso con el entorno de producción. Complejidad Operacional: hay un aumento exponencial de la complejidad en este modelo. Diseñar buenos componentes arquitectónicos para que se gestione esta complejidad es de gran importancia. Es importante elegir y gestionar bien las herramientas de registro, APM y Monitoreo Continuo, por ejemplo. Administrar muchos microservicios puede resultar complejo. Se requiere un esfuerzo adicional para monitorear, organizar y mantener los servicios en funcionamiento. Latencia: la comunicación entre microservicios puede volverse compleja, especialmente en sistemas distribuidos, lo que requiere estrategias adecuadas de comunicación y gestión de API. Gastos generales de la red: el tráfico de red entre microservicios puede aumentar, especialmente en comparación con las arquitecturas monolíticas, lo que puede afectar el rendimiento. Coherencia entre transacciones: garantizar la coherencia en las operaciones que involucran múltiples microservicios puede ser un desafío, especialmente cuando se trata de transacciones distribuidas. Capacidad de prueba: probar las interacciones entre microservicios puede ser más complejo que probar una aplicación monolítica, lo que requiere estrategias de prueba eficientes. Infraestructura: es posible que deba invertir en una infraestructura sólida para respaldar la ejecución de múltiples microservicios, incluidas herramientas de orquestación de contenedores y sistemas de monitoreo. Dispersión Técnica: en este punto podemos decir que hay una acción de la Ley de Conway “Inversa”, ya que los equipos, así como las tecnologías y herramientas, tienden a seguir la dispersión y la segregación. En equipos, cada persona toma conciencia de una pequeña parte de un todo mayor. De esta forma, para tecnologías y herramientas, cada desarrollador utiliza el framework o herramientas que más le convienen. Diseño basado en dominios: para aumentar las posibilidades de éxito de este modelo, los equipos deben tener conocimientos de DDD. Cuándo usar Volumetría: la arquitectura de microservicios/microcomponentes ha demostrado ser efectiva en sistemas de alto volumen, es decir, aquellos que necesitan lidiar con grandes cantidades de transacciones, datos y usuarios. Disponibilidad: una de las principales razones para adoptar este tipo de arquitectura es la disponibilidad. Cuando está bien construido, el software que adopta la microcomponentización no tiende a fallar en su totalidad cuando las partes pequeñas presentan problemas. Por lo tanto, otros componentes continúan funcionando mientras el componente problemático se recupera. Escalabilidad: si diferentes partes de su aplicación tienen diferentes requisitos de escalabilidad, los microservicios pueden resultar útiles. Puede escalar solo aquellos servicios que necesitan la mayor cantidad de recursos, en lugar de escalar toda la aplicación. Tamaño del equipo: Los equipos pequeños pueden ser un problema. Configuraciones, textos estándar, entornos, pruebas, integraciones, procesos de entrada y salida. Resiliencia > Rendimiento": en casos de incertidumbre, por ejemplo, el volumen de solicitudes y hasta dónde puede llegar, como grandes e-commerces en periodos de alto acceso (Black Friday) donde es necesario que el software sea más resiliente y desempeñarse mejor en la mediana. Lista de verificación comparativa Figura 5 – Lista de verificación Comparación entre modelos. Conclusión En resumen, la elección del modelo arquitectónico es crucial para el éxito del proyecto, requiriendo un análisis cuidadoso de las necesidades y objetivos. Cada modelo arquitectónico tiene sus ventajas y desventajas y debemos guiar la decisión alineándola con los requerimientos específicos del proyecto. Al considerar las estrategias, los requisitos y los estudios arquitectónicos de la empresa, es posible tomar una decisión que tendrá un impacto positivo en el ciclo de vida de la aplicación. El trabajo (y apoyo) del equipo de arquitectura es sumamente importante. También es de gran importancia que la gerencia y áreas afines apoyen brindando tiempo para recolectar toda esta gama de información. ¿Aún tienes dudas? Al principio, comience con el semimonolito/monolito modular. Asimismo, preste mucha atención al modelado de bases de datos. Referencias Garner. (Dakota del Norte.). Microservicio. Obtenido de https://www.gartner.com/en/information-technology/glossary/microservice Gamma, E., Helm, R., Johnson, R. y Vlissides, J. (1994). Patrones de diseño: elementos de software reutilizable orientado a objetos. Addison-Wesley. Bass, L., Clements, P., Kazman, R. (2013). Arquitectura de software en la práctica (3ª ed.). Addison-Wesley. Arquitectura de Microservicios (12/2023). Obtenido de https://microservices.io/ Fowler, S. J. (2017). Microservicios listos para producción. Novatec. Formación ArchExpert. (Dakota del Norte.). Contenido premium. Obtenido de https://one.archoffice.tech/ Monolito Primero (06/2015). Obtenido de https://martinfowler.com/bliki/MonolithFirst.html Microservicios. Consultado el 01/2024.

En este artículo hablaré sobre GraphQL centrándonos en las aplicaciones dotNet. Aquí, mostraré cómo los problemas inherentes de REST motivaron la creación de GraphQL. A continuación, presentaré los conceptos básicos de la especificación de este lenguaje. Luego presentaré la biblioteca Hot Chocolate, que es una de las muchas bibliotecas que implementan la especificación GraphQL. Finalmente, mostraré un pequeño ejemplo del uso de esta biblioteca en una aplicación dotNet. REST Antes de hablar de GraphQL es necesario hablar de REST. El término fue acuñado por Roy Thomas Fielding (2000) en su tesis doctoral. En este trabajo, Fielding presenta REST como un patrón arquitectónico para aplicaciones web definido por cinco restricciones: Cliente-servidor: Esta restricción define que la interfaz de usuario debe estar separada de los componentes del sistema que procesan y almacenan datos. Sin estado: esta restricción dice que el cliente no necesita estar al tanto del estado del servidor, ni el servidor necesita estar al tanto del estado del cliente. Caché: esta restricción indica que, cuando sea posible, la aplicación del servidor debe indicar a la aplicación cliente que los datos se pueden almacenar en el caché. Sistema en capas: esta restricción indica que la aplicación debe construirse apilando capas que se agreguen funcionalidad entre sí. Interfaz uniforme: Esta restricción indica que los recursos de la aplicación deben estar disponibles de manera uniforme, de modo que, al aprender a acceder a un recurso, automáticamente se sepa cómo acceder a los demás. Según el trabajo de Fielding, esta es una de las características centrales que distinguen a REST de otros patrones arquitectónicos. Sin embargo, el propio autor afirma que esto degrada la eficiencia de la aplicación, ya que los recursos no están disponibles de una manera que satisfaga las necesidades específicas de una aplicación determinada. Cómo se ve REST en la práctica En la Figura 1 puede ver parte de la API OneDrive de Microsoft. En esta imagen se puede ver la uniformidad en el acceso a los recursos. Esto se nota cuando notamos que, para obtener datos, simplemente se envía una solicitud GET a un punto final que comienza con el término unidad y va seguido del nombre del recurso y su ID. La misma lógica se aplica a la creación de recursos (POST), modificación de recursos (PUT) y eliminación de ellos (DELETE). Accediendo a la documentación de Google Drive, podemos ver el retorno típico de una API REST. La documentación antes mencionada muestra el gran volumen de datos que puede traer una sola solicitud REST. A pesar de ser grande, es posible que una aplicación cliente aún necesite realizar solicitudes adicionales para obtener más datos sobre el propietario de un archivo, por ejemplo. Considerando las restricciones determinadas por Fielding y los ejemplos mostrados, es fácil ver dos problemas inherentes a REST. El primero de ellos es el tráfico de datos que el consumidor no necesita y el segundo es la posible necesidad de realizar varias solicitudes para obtener los datos necesarios para crear una página web. Figura 1 - Acceda al artículo completo aquí. Comprender GraphQL GraphQL surgió en 2012 en Facebook como una solución a los problemas encontrados en el estándar REST. En 2015, el lenguaje pasó a ser de código abierto y en 2018 se creó la Fundación GraphQL, que se encargó de especificar la tecnología. Es importante resaltar que GraphQL no es una biblioteca ni una herramienta. Al igual que SQL, GraphQL es un lenguaje para buscar y manipular datos. Mientras usamos SQL en la base de datos, GraphQL se usa en las API. La Tabla 1 muestra una expresión SQL para recuperar un número de pedido y un nombre de cliente de una base de datos. De manera similar, la Tabla 2 muestra una expresión GraphQL para obtener los mismos datos de una API que admite GraphQL. En los ejemplos, podemos ver dos ventajas principales de GraphQL sobre REST. El primero está presente en el hecho de que GraphQL permite al consumidor buscar únicamente los datos que necesita para crear su página web. El segundo está presente en que el consumidor podría buscar los datos del pedido y del cliente en una sola llamada. Tabla 1: Ejemplo de selección en una base de datos relacional. Tabla 2: Ejemplo de una expresión GraphQL. Considero interesante mencionar dos características más de una API GraphQL. El primero de ellos es la existencia de un único punto final. A diferencia de REST, donde se crea un punto final para cada recurso, en una API GraphQL todas las consultas y mutaciones se envían al mismo punto final. El segundo es el hecho de que una API GraphQL solo admite el verbo POST. Esta es otra diferencia más en relación con un REST, donde se deben usar diferentes verbos HTTP dependiendo de la intención de la solicitud. Por lo tanto, mientras en una API REST debemos usar los verbos GET, POST, PUT y DELETE, en una API GraphSQL usaremos el verbo POST para obtener, crear, cambiar y eliminar datos. Lenguaje de definición de esquemas Hablemos ahora un poco sobre SDL (lenguaje de definición de esquemas). Cuando se utiliza una base de datos relacional, primero es necesario definir el esquema de la base de datos, es decir, es necesario definir las tablas, columnas y relaciones. Algo similar ocurre con GraphQL, es decir, la API necesita definir un esquema para que los consumidores puedan buscar los datos. Para crear este esquema, se utiliza SDL. El sitio web oficial de GraphQL tiene una sección dedicada a SDL. En esa sección puede encontrar una descripción completa del lenguaje para crear esquemas GraphQL. En este texto, presentaré la sintaxis básica para crear un esquema GraphQL. En la Figura 2 puede ver parte de un esquema GraphQL creado con Apollo. Podemos ver que el esquema comienza con la definición de dos tipos fundamentales: Consulta y Mutación. En el primer tipo definimos todas las consultas que tendrá nuestra API. En nuestro ejemplo, los consumidores podrán buscar clientes, productos y pedidos. El tipo de mutación define qué operaciones de manipulación de datos estarán disponibles para el consumidor. En el ejemplo presentado, el consumidor podrá crear, cambiar y eliminar clientes y productos. Sin embargo, cuando se trata de pedidos, puede crear, agregar un artículo, cancelar y cerrar el pedido. Además de los tipos Consulta y Mutación, puede ver la presencia de los tipos Cliente y Producto. En ambos, hay propiedades ID, String y Float. Estos tres tipos, junto con los tipos Int y Boolean, se denominan tipos escalares. El esquema también muestra la definición de una enumeración denominada OrderStatus. La Figura 3 muestra la definición de tipos de entrada que se utilizan para proporcionar datos de entrada para consultas y mutaciones. Creo que es importante señalar que la forma de crear el esquema varía según la biblioteca que elijas. Cuando se utiliza la biblioteca Apollo para javascript, la definición del esquema se puede realizar a través de una cadena pasada como parámetro a la función gql o mediante la creación de un archivo (generalmente llamado esquema.graphql). Sin embargo, cuando se utilizan bibliotecas como Hot Chocolate para dotNet, la definición del esquema se realiza mediante la creación de clases y la configuración de servicios en la aplicación. Por tanto, la forma en que se crea un esquema GraphQL puede variar mucho según el lenguaje y la biblioteca elegidos. Figura 2. Figura 3. Elementos básicos del lenguaje GraphQL Como se mencionó anteriormente, GraphQL es un lenguaje y por lo tanto tiene una sintaxis. Puede encontrar la guía completa con la sintaxis del idioma en el sitio web oficial de GraphQL. Sin embargo, en este artículo describiré sus elementos básicos.   La búsqueda de datos se realiza mediante consultas, las cuales deben comenzar con la palabra clave consulta seguida del nombre de la consulta. Si tiene parámetros debes abrir paréntesis y, dentro de ellos, debes colocar el nombre de cada parámetro seguido de su valor. Se deben utilizar dos puntos (:) para separar el nombre del parámetro de su valor. Una vez finalizada la lista de parámetros, se deben cerrar los paréntesis. Luego, debes abrir llaves ({) y colocar dentro de ellas el nombre de los campos que deseas. Con la lista de campos finalizada, debes cerrar la llave (}). La Tabla 3 muestra un ejemplo simple de una consulta. Tabla 3: Ejemplo de consulta. Hay escenarios en los que los parámetros de consulta pueden ser complejos. Cuando un parámetro es complejo, es decir, es un objeto con uno o más campos, se deben abrir llaves inmediatamente después de los dos puntos. Dentro de las claves se debe colocar el valor de cada campo del objeto y su respectivo valor, ambos deben estar separados por dos puntos (ver tabla 4). También hay escenarios en los que los campos de consulta pueden ser complejos. En estos casos, debe abrir llaves justo después del nombre del campo. Dentro de las claves, debes colocar los nombres del campo objeto (ver tabla 5). Tabla 4: Ejemplo de consulta. Tabla 5: Ejemplo de consulta. Las reglas descritas hasta ahora también se aplican a las mutaciones. Sin embargo, estos deben iniciarse con la palabra clave mutación en lugar de consulta. Es interesante observar que existen otros elementos en la sintaxis de GraphQL, pero los elementos descritos hasta ahora son suficientes para ejecutar la mayoría de consultas y mutaciones. Al ser un lenguaje, GraphQL debe ser implementado mediante alguna aplicación o biblioteca. Para que nuestra API admita consultas y mutaciones, generalmente necesitamos una biblioteca. Por supuesto, podríamos implementar la especificación del lenguaje por nuestra cuenta, pero eso sería muy improductivo. La sección “Código” del sitio web GraphQL.org muestra una lista de bibliotecas que implementan GraphQL para los más variados lenguajes. Para el mundo dotNet, por ejemplo, existen las bibliotecas “GraphQL para .NET”, “Hot Chocolate” y otras. Cuando se habla de implementaciones GraphQL, es necesario hablar del concepto de “resolvedores”. Un solucionador es una función activada por la biblioteca que implementa GraphQL. Esta función es responsable de recuperar de manera efectiva los datos solicitados por la consulta. Lo mismo ocurre con las mutaciones, es decir, cuando la biblioteca recibe una solicitud para ejecutar una mutación, la biblioteca identifica el solucionador que ejecutará los cambios en la base de datos (insertar, actualizar y eliminar). Nótese, entonces, que en la mayoría de bibliotecas las búsquedas y cambios de datos se realizan mediante su propio código. Se puede ver, entonces, que las bibliotecas que implementan GraphQL son responsables de interpretar la consulta/mutación enviada por el llamante y descubrir la función adecuada para resolver la consulta/mutación solicitada. Para ver un ejemplo de una API sencilla que utiliza Hot Chocolate, visita mi GitHub. En definitiva, GraphQL es un lenguaje creado por Facebook con el objetivo de superar los problemas inherentes a REST. El lenguaje proporciona una sintaxis simple para obtener datos de una API y cambiar datos de ella. Se implementa mediante una amplia variedad de bibliotecas para los idiomas más diversos, lo que permite al desarrollador crear una API GraphQL utilizando su idioma favorito. Referencias "GraphQL". Wikipedia, 9 de junio de 2022, en.wikipedia.org/wiki/GraphQL. Consultado el 6 de noviembre. 2023. La Fundación GraphQL. "GraphQL: un lenguaje de consulta para API". Graphql.org, 2012, graphql.org/. Thomas Fielding, Roy. "Disertación de campo: CAPÍTULO 5: Transferencia de estado representacional (REST)". Ics.uci.edu, 2000, ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm. Consultado el 6 de noviembre.  

¿Qué son los sistemas de diseño multimarca? Los sistemas de diseño multimarca son sistemas con atributos que los hacen flexibles para su uso en diferentes contextos, patrones visuales y diseño de interfaz. Están desarrollados para casos en los que una única biblioteca pretende servir productos de diferentes marcas. Generalmente, este tipo de sistema de diseño también es independiente de marcos, plataformas o tecnologías; se les llama sistemas de diseño independientes de la tecnología. Actualmente, el sistema de diseño agnóstico más popular es Lightning, desarrollado por Salesforce, también creador del concepto. Beneficios Además de ser una única fuente de información, el sistema de diseño multimarca comparte el costo de operación, lo que hace que el trabajo sea verdaderamente colaborativo entre equipos. Según los diseñadores del grupo Volkswagen, la implementación de GroupUI trajo los siguientes resultados: Mayor agilidad, eficiencia y reducción de costos son algunos de los beneficios de los sistemas de diseño multimarca. Escalabilidad Desarrollados a partir del concepto de tokens de diseño, permiten replicar una misma biblioteca en diferentes productos, independientemente del framework en el que se desarrollen. Al mismo tiempo, permiten que cada uno de estos productos utilice sus propios estándares visuales. Otro punto muy relevante es compartir características como buenas prácticas, capacidad de respuesta, accesibilidad, rendimiento, UX y ergonomía. Uso en diferentes tecnologías Actualmente es común encontrar en sistemas de diseño, incluso aquellos que atienden a una sola marca, diferentes bibliotecas para productos web, iOS y Android. Esto se debe a la existencia de diferentes especificaciones para los navegadores de escritorio y móviles, así como entre dispositivos con sistemas operativos nativos, como Apple y Google. Trabajando independientemente de estas tecnologías, es posible crear instancias del mismo sistema de diseño en diferentes componentes de la biblioteca para cumplir con estas particularidades. Ganancia en eficiencia Según datos difundidos por los líderes de UX y sistemas de diseño del Grupo Volkswagen, a través de la presentación Multibrand Design System dentro del grupo Volkswagen y sus marcas, se produce un gran aumento en la agilidad, productividad y eficiencia al trabajar con el multimarca. concepto . Eficiencia operativa con el uso de sistemas de diseño multimarca. (Fuente: YouTube) Comparando el esfuerzo requerido entre un producto sin sistema de diseño, pasando por uno que tiene su sistema de diseño y llegando a uno que adopta la metodología multimarca, es posible notar una reducción incremental y considerable en la UI. esfuerzos (diseño de interfaz) y desarrollo. Esta implementación permite una forma de trabajar más orientada a la experiencia y el descubrimiento del usuario, al liberar recursos para estas actividades, que hasta entonces se consumían en el diseño e implementación de interfaces. Estandarización Un sistema de diseño detallado y bien especificado se convierte en una única fuente de verdad. Cuando se comparte dentro de la organización, además de facilitar mucho el trabajo de los equipos, permite una estandarización consistente, evitando la necesidad de las mismas discusiones, descubrimientos y definiciones, que quedan listas para ser reutilizadas como resultado del desarrollo constante de un diseño. sistema. Fácil personalización Según los expertos, la principal característica de un sistema de diseño multimarca es la flexibilidad. En este contexto, personalizar significa permitir que cada producto aplique sus decisiones de diseño visual. Para que esto sea posible, se crean bibliotecas de diseño de tokens. Se pueden duplicar y personalizar fácilmente, generando patrones visuales distintos para cada marca y producto. Los tokens de diseño pueden interpretarse como variables que llevan atributos de estilo, como un color de marca, que, aplicado como token, permite, al cambiar el valor que lleva la variable, reflejar el cambio en todos los lugares donde se muestra el color en el interfaz. En el ejemplo anterior, tenemos especificaciones de color de marca para tres sistemas de diseño diferentes y en la columna de la izquierda tenemos el token, que seguirá siendo el mismo en todos los productos. El valor que lleva la variable es diferente en cada caso. Estas definiciones se aplican a cualquier otro atributo visual, como tipografía, espaciado, bordes, sombreado e incluso animaciones. Estructura de los sistemas de diseño multimarca Según Brad Frost, uno de los consultores de sistemas de diseño más influyentes en la actualidad y autor del libro Atomic Design, se recomienda que los sistemas de diseño multimarca tengan tres capas: Estructura de tres niveles de un sistema de diseño . (Fuente: Brad Frost) Agnóstico tecnológico (1ª capa) El nivel agnóstico de un sistema de diseño es la base de los demás, por lo tanto, solo incluye códigos de script html, css y java, con el objetivo de renderizar componentes en el navegador. Esta capa es sumamente importante a largo plazo, ya que permite la reutilización futura de un sistema de diseño. Por ejemplo, en el escenario actual, se puede decir que el lenguaje más popular es React. Sin embargo, esto no siempre fue así y no se sabe qué tecnología será la próxima en destacar. Por este motivo, es importante contar con una capa base, que pueda aplicarse a nuevas tecnologías, sin tener que empezar un nuevo sistema de diseño desde cero. En esta primera capa, los diseñadores y desarrolladores construyen los componentes del sistema de diseño en un entorno de taller, documentados en una herramienta como Figma y Zeroheight. El resultado de este trabajo son componentes renderizados en el navegador, considerando que el framework adoptado hoy puede no ser el mismo que se adopte en el futuro. Tech-specific (2da capa) El nivel de tecnología específica es donde ya existe una dependencia de alguna tecnología y/o plataforma y, además, existe la oportunidad de generar una capa de sistema de diseño para todos los productos que utilizan la misma tecnología. Un buen ejemplo de este tipo de sistema de diseño es Bayon DS, que sirve a los productos SAJ. También es posible utilizarlo para desarrollar cualquier otro producto que utilice tecnología React. Producto específico (tercera capa) La tercera capa es donde todo se vuelve muy específico y todo el esfuerzo se hace para un determinado producto. En este nivel, se puede crear documentación relacionada con estándares únicos que solo se aplican a ese contexto particular. Siguiendo el concepto de Atomic Design, esta capa crea componentes con mayor complejidad y menor flexibilidad, como páginas y plantillas, para generar patrones de productos. En la tercera capa, las aplicaciones individuales consumen la versión específica de la tecnología seleccionada, a través de administradores de paquetes como npm y Yarn. Cómo estamos poniendo en práctica estos nuevos conceptos Hace unos meses, tras el anuncio de la iniciativa Inner Source, comenzamos a estudiar una manera de transformar Bayon, para que pudiera "recibir" este nuevo concepto. Personalmente, comencé una investigación en profundidad sobre los temas tratados en este artículo. Además, mis jefes me dieron la oportunidad de participar en un bootcamp avanzado sobre sistemas de diseño, lo que me aportó mucho aprendizaje. Paralelamente a la investigación, reunimos a algunos profesionales con conocimiento de Bayon, representados por colegas de los equipos de arquitectura y diseño de producto de las verticales JUS, para discutir las posibilidades de acción para convertir nuestro sistema de diseño a los estándares más recientes. Juntos, diagnosticamos la forma más correcta de crear y aplicar una biblioteca de tokens de diseño, lo que nos permitió eliminar nuestro marco actual, Material UI, para que, en su lugar, esté la implementación del nuevo sistema de diseño agnóstico de Softplan. Componentes web y Stencil A través de reuniones recurrentes con representantes de empresas del Grupo Softplan, se discute la posibilidad de desarrollar una biblioteca de componentes web. En él, cada atributo visual o decisión de diseño se aplica a través de tokens de diseño, permitiendo una personalización completa que garantiza que cada componente presentará las características visuales del producto correspondiente. Los componentes web son un conjunto de API que permiten la creación de etiquetas HTML personalizadas, reutilizables y encapsuladas para su uso en páginas y aplicaciones web.

La seguridad de la información se refiere al conjunto de prácticas, medidas y procedimientos adoptados para proteger la información y los datos sensibles de una organización o individuo contra amenazas, acceso no autorizado, pérdida, robo, daño o cambios no deseados. El objetivo es garantizar la confidencialidad, integridad y disponibilidad de los datos, así como preservar su autenticidad y evitar que caigan en manos equivocadas. La seguridad de la información es esencial en un mundo altamente conectado que depende de sistemas informáticos, redes y tecnologías digitales. Cubre varias áreas, incluyendo: Confidencialidad: Garantizar que la información sólo sea accesible a personas autorizadas evitando el acceso no autorizado mediante autenticación, cifrado y control de acceso. Integridad: Garantizar que los datos sean exactos, completos y no sufran cambios no autorizados durante su almacenamiento, transmisión o procesamiento. Disponibilidad: Asegurarse de que la información esté disponible y accesible cuando sea necesaria, evitando interrupciones causadas por fallas, ataques o desastres. Autenticidad: Garantizar que la información se atribuye correctamente a sus autores y que el origen de los datos es verificable. No repudio: Asegurar que el autor de una acción no pueda negar la autoría o la realización de una transacción. Gestión de riesgos: Identificar, analizar y mitigar amenazas y vulnerabilidades para proteger la información de posibles incidentes de seguridad. Impactos de la falta de seguridad de la información La falta de seguridad de la información puede provocar una serie de impactos negativos importantes para los individuos, las organizaciones e incluso la sociedad en su conjunto. Algunos de los principales impactos incluyen: Robo de datos: los piratas informáticos y los ciberdelincuentes pueden ingresar a sistemas desprotegidos y robar información confidencial como datos personales, números de tarjetas de crédito, información bancaria y otros datos confidenciales. Este tipo de robo puede provocar fraude financiero, robo de identidad y extorsión. Fuga de información: Fuga de información confidencial, como secretos comerciales, propiedad intelectual o información gubernamental confidencial. Como resultado, estas filtraciones pueden dañar la competitividad de las empresas, la seguridad nacional y la privacidad de las personas. Daño a la reputación: Cuando una organización sufre una brecha de seguridad, su reputación puede verse seriamente comprometida. La percepción pública de una falta de atención a los datos de los clientes puede afectar negativamente la confianza de los clientes y socios comerciales. Interrupción del negocio: los ciberataques, como el ransomware o la denegación de servicio (DDoS), pueden dejar los sistemas inoperables e interrumpir las operaciones comerciales. Esta interrupción puede causar pérdida de productividad, daños financieros y frustración del cliente. Pérdida financiera: como el costo de reparar sistemas comprometidos, pagar rescates por ransomware o enfrentar litigios relacionados con violaciones de datos. Infracciones regulatorias y legales: en muchos países, existen leyes y regulaciones que requieren una protección adecuada de los datos y la información confidencial de los clientes. La falta de seguridad puede dar lugar a violaciones de estas leyes, lo que puede dar lugar a multas, sanciones y acciones legales. Espionaje y ciberguerra: Facilitar el ciberespionaje e incluso los ciberataques a gran escala entre países, socavando la seguridad nacional y la estabilidad geopolítica. Daño a la confianza digital: socavar la confianza general en las tecnologías digitales, lo que puede ralentizar la adopción de nuevas tecnologías y dañar la economía digital. Medidas de seguridad Para mitigar dichos impactos, es esencial que las personas y las organizaciones inviertan en medidas de seguridad de la información, como cifrado, autenticación sólida, capacitación en concientización sobre seguridad, actualizaciones periódicas de software y auditorías de seguridad. Además, es esencial que los gobiernos y los sectores industriales trabajen juntos para desarrollar políticas y estándares de ciberseguridad más sólidos. Algunos elementos comunes para garantizar la seguridad de la información incluyen firewalls, sistemas de prevención y detección de intrusiones (IDS/IPS), antivirus, cifrado, copias de seguridad periódicas, políticas de contraseñas seguras, capacitación en concientización sobre seguridad y monitoreo de actividades sospechosas. Es deber de cada uno de nosotros velar por la seguridad de la información, reconociendo la importancia de una postura vigilante en nuestro actuar diario. La responsabilidad no recae sólo en los expertos en tecnología o en departamentos concretos, sino en cada individuo. Por tanto, desconfiar, verificar y validar la información recibida es una práctica fundamental para no caer en trampas de la ingeniería social. Después de todo, esta forma de ciberataque puede originarse en fuentes inesperadas y aparentemente confiables. Sólo asumiendo el papel de nuestro propio aliado en la seguridad digital podremos construir una base sólida para proteger nuestra privacidad, datos personales e información sensible. Reforzando nuestra conciencia y adoptando medidas preventivas, podemos contribuir significativamente a un entorno en línea más seguro y confiable para todos. Es importante prestar atención a herramientas de inteligencia artificial como Chat GPT o Google Bard. Nunca utilices una dirección de correo electrónico corporativa para acceder a estas herramientas, ya que puede suponer un riesgo importante para la seguridad de la información sensible de la empresa para la que trabajas. Cuando utilice estas plataformas, opte siempre por utilizar un correo electrónico personal.