Instituto Tecnológico y de Estudios Superiores de Monterrey
Campus Monterrey
Escuela de Ingeniería y Ciencias
Ecosistema digital para la integración de sistemas desarrollados en la empresa FRISA
Reporte presentado por Max Alejandro Santos Guerrero
sometido a la
Escuela de Ingeniería y Ciencias
como un requisito parcial para obtener el grado académico de Maestro
en
Administración de la Ingeniería
Monterrey Nuevo León, 6 de Junio de 2020
Instituto Tecnológico y de Estudios Superiores de Monterrey
Campus Monterrey
Escuela de Ingeniería y Ciencias
Los miembros del comité aquí citados certificamos que hemos leído el reporte
presentado por Max Alejandro Santos Guerrero y consideramos que es adecuado en alcance y calidad como un requisito parcial para obtener el grado de Maestro en Ingeniería en Administración de la Ingeniería,
_______________________
Dr. Juan Carlos Lavariega Tecnológico de Monterrey Escuela de Ingeniería y Ciencias Asesor principal _______________________
Dr. Rafael Salazar Chávez Miembro del comité _______________________
Ing. Rogelio Reyna Director de Planta FRISA Aerospace Testigo de la empresa
_______________________
Dr. Adán López Miranda
Director de la Maestría en Administración de la Ingeniería Escuela de Ingeniería y Ciencias
Monterrey Nuevo León, 6 de junio de 2020
Declaración de autoría
Yo, Max Alejandro Santos Guerrero, declaro que este reporte titulado,
‘Ecosistema digital para la integración de sistemas desarrollados en la empresa FRISA, y el trabajo que se presenta es de mi autoría. Adicionalmente, confirmo que:
Realice este trabajo en su totalidad durante mi candidatura al grado de maestría en esta universidad.
He dado crédito a cualquier parte de este reporte que haya sido previamente sometido para obtener un grado académico o cualquier otro tipo de titulación en esta o cualquier otra universidad.
He dado crédito a cualquier trabajo previamente publicado que se haya consultado en este reporte.
He citado el trabajo consultado de otros autores, y la fuente de donde los obtuve.
He dado crédito a todas las fuentes de ayuda utilizadas.
He dado crédito a las contribuciones de mis coautores, cuando los resultados corresponden a un trabajo colaborativo.
Este reporte es enteramente mío, con excepción de las citas indicadas.
____________Max Alejandro Santos Guerrero_______________
Nombre-Completo-Estudiante
Monterrey Nuevo León, 6 de junio de 2020
©2020 por Max Alejandro Santos Guerrero Todos los derechos reservados
Dedicatoria
Este trabajo se lo dedico principalmente a mi familia por todo el soporte, paciencia e incondicional apoyo durante todos mis estudios. También se lo dedico a mi equipo de trabajo dentro de la empresa FRISA ya que sin ellos no se habría logrado la implementación del proyecto propuesto en este trabajo.
Max Santos
Ecosistema digital para la integración de sistemas desarrollados en la empresa FRISA
por
Max Alejandro Santos Guerrero
Resumen
Muchas empresas en la actualidad enfrentan un gran desafío de transformación digital. Los miembros del equipo de tecnologías de información deben ayudar a que los nuevos modelos de negocio y modelos operativos funcionen a una escala que marque una diferencia importante en el desempeño financiero de la empresa. Para tener éxito en una transformación digital, una empresa debe desarrollar la capacidad de lograr transformaciones por áreas del negocio. Se puede desarrollar esta capacidad si se construye un ecosistema digital. Dicho ecosistema proporciona la flexibilidad para conectar rápidamente información, aplicaciones, plataformas de terceros y procesos para ejecutar negocios digitales. La tarea de construir un ecosistema digital de este tipo presenta un complejo desafío técnico y administrativo.
Formar un ecosistema digital implica varias acciones: se debe tener la
infraestructura, la arquitectura, el gobierno y otros elementos básicos para admitir la comunicación con el ecosistema digital. Las API públicas, la inteligencia
artificial (IA) y otras nuevas tecnologías permiten las conexiones y la
automatización que proporciona el ecosistema. Muchos de los sistemas que una empresa ya tiene se pueden adaptar y conectar para formar parte de un
ecosistema digital. Los ecosistemas digitales deben admitir casos de uso específicos.
En el presente documento se refiere a la realización de un ecosistema digital para los sistemas realizados dentro de la empresa FRISA, donde se implementa una arquitectura de mini servicios como un estándar de desarrollo de software de sistemas distribuidos.
Tabla de Contenido
Declaración de autoría... I Dedicatoria... II Resumen... II Lista de figuras... V Lista de tablas... V
Capítulo I - Introducción... 1
1.1 Planteamiento del problema...1
1.2 Propósito del proyecto...2
1.3 Justificación... 2
1.4 Objetivos... 3
Objetivos generales... 3
Objetivos específicos... 3
1.5 Alcances y limites... 3
Capítulo II - Marco de Referencia...4
2.1 FRISA... 4
2.2 Procesos de manufactura en FRISA...5
2.3 Sistemas CORE de FRISA...5
2.1 Procesos administrados por sistema SIF/SIM en FRISA Aerospace y Forge...6
2.4 FRISA Evolución XXI... 9
Capítulo III - Marco Teórico... 10
3.1 Plataforma Digital... 10
3.2 Componentes de una plataforma digital...11
3.3 APIs y ecosistemas digitales...12
3.4 Usos de un ecosistema digital...13
3.5 Elementos en un ecosistema digital...13
3.6 Componentes técnicos de un ecosistema digital...15
3.7 Arquitectura orientada a servicios (SOA)...16
3.7.1 Principios SOA... 17
3.8 Diseño orientado al Dominio (DDD)...17
3.8.1 Beneficios:... 18
3.8.1 Dominio... 18
3.8.2 Elementos del diseño orientado al dominio...19
3.8.3 Arquitectura en capas (Layered architecture)...21
3.9 Arquitectura de Microservicios...23
3.9.1 Granularidad de un Microservicios...23
3.9.3 Ruta de adopción a la arquitectura de microservicios...26
3.10 API Mediation Layer... 27
3.11 Seguridad en API... 29
3.11.1 Principales vulnerabilidades de seguridad...30
3.11.2 Protección distribuida de seguridad de API...31
3.12 Framework de desarrollo de software...33
3.12.1 Ventajas:... 33
Capítulo IV – Metodología de desarrollo software en FRISA...35
4.1 Definiciones... 35
4.2 Roles y Responsabilidades...36
4.3 Administración de Proyectos y Mejoras...37
4.4 Diagrama de Proceso... 37
4.5 Metodología Ágil... 37
4.6 Alta de User Stories... 39
4.7 Planeación de User Stories...40
4.8 Asignación de User Stories...40
4.9 Desarrollo de User Stories...40
4.10 Pruebas y Aprobación... 41
4.12 Cierre... 43
Capítulo IV - Desarrollo... 45
5.1 Planeación... 45
5.2 Selección de Framework de desarrollo...48
5.2.1 Lenguaje de programación...48
5.2.2 Maquetación de clases y granularidad de los microservicios...51
5.4 Elección de sistema operativo para hospedar servicios...54
5.5 Definición de servicios distribuidos, disponibilidad y escalabilidad...57
5.6 Definir API de mediación... 58
5.7 Diagrama General de Arquitectura del Ecosistema Digital...59
Capítulo 6 - Casos de uso de ecosistema digital...60
6.1 Visor De Inventarios Aerospace (VIA)...60
6.2 Plataforma digital Forja Aerospace...61
6.3 Trazabilidad de herramientas Forja Aerospace...64
Conclusiones y Recomendaciones...67
Anexos... 68
Referencias... 88
Lista de figuras.
Fig. 1 Procesos de FRISA Aerospace / Forge...5
Fig. 2 Diagrama de comunicación de Sistemas CORE de FRISA...6
Fig. 3 Diagrama conceptual de sistemas después de evolución XXI...9
Fig. 4 Plan General de Evolución XXI...10
Fig. 5 Áreas de una plataforma digital...12
Fig. 6 Elementos de un ecosistema digital...15
Fig. 7 Componentes técnicos de un ecosistema digital...16
Fig. 8 Arquitectura en capas... 22
Fig. 9 Granularidad de microservicios...25
Fig. 10 Ruta de adopción a la arquitectura de microservicios...27
Fig. 11 API de medicación... 28
Fig. 12 Principales vulnerabilidades de seguridad...30
Fig. 13 Diagrama de protección distribuida de API de mediación...32
Fig. 14 Diagrama de proceso de metodología de desarrollo de software FRISA...37
Fig. 15 Listado de User Stories... 38
Fig. 16 Kanban de User Stories... 38
Fig. 17 Datos de User Story... 40
Fig. 18 Ejemplo del correo de aprobación...42
Fig. 19 Formulario de aprobación de cierre del User Story...43
Fig. 20 Ejemplo del correo electrónico de cierre...43
Fig. 21 Plan general de implementación de ecosistema digital...46
Fig. 22 Hitos de proyecto separación de sistemas SIF Aero/Forge...48
Fig. 23 Índice TIOBE de lenguajes de programación más utilizados...49
Fig. 24 Porcentage de preguntas por mes sobre lenguajes en Stack Overflow...50
Fig. 25 Arquitectura monolítica de sistema SIF...51
Fig. 26 Maquetación de código de sistema SIF...51
Fig. 27 Arquitectura de miniservicios de FRISA...52
Fig. 28 Maquetación de código de un miniservicio de FRISA...54
Fig. 29 Herramientas esquema de servicios distribuidos...57
Fig. 30 Diagrama de ecosistema digital de FRISA...59
Fig. 31 Comunicación entre portal VIA y Ecosistema digital...60
Fig. 32 Login de portal VIA (Visor de inventarios Aerospace)...61
Fig. 33 Pantalla principal de portal VIA...61
Fig. 34 Detalle de información portal VIA...61
Fig. 35 Comunicación entre Plataforma Digital de Indicadores y Ecosistema Digital...63
Fig. 36 Pantalla principal de plataforma de Indicadores Forja...63
Fig. 37 Integración de dispositivos trazabilidad de herramientas forja...66
Fig. 38 Comunicación con ecosistema de proyecto de trazabilidad de herramientas...66
Lista de tablas Tabla 1 Definiciones de metodología de desarrollo de software en FRISA...35
Tabla 2 Roles y responsabilidades de metodología de desarrollo de software en FRISA...35
Tabla 3 Librerías de ciencias de datos de Python...50
Tabla 4 Tabla comparativa de distribuciones Linux...55
Tabla 5 Tabla comparativa de solidez de distribuciones Linux...56
Tabla 6 Tabla comparativa de precios de distribuciones Linux...56
Tabla 7 Tabla Comparativa de proveedores de API de mediación...58
Capítulo I - Introducción
1.1 Planteamiento del problema
El desarrollo de software siempre está en constante evolución, en la época actual (2019) el enfoque es modularizar. Modularizar en sí no es algo nuevo. En una época pasada, sistemas grandes (en tamaño y cantidad de funcionalidades) han sido divididos en pequeños módulos para facilitar la implementación, entendimiento y acelerar el proceso de desarrollo de nuevas funcionalidades.
Utilizar módulos está basado en la filosofía de UNIX, el cual se centra en que cada programa debería cumplir con una sola tarea (donde el cumplimiento debe ser el mejor), los programas deberían de trabajar juntos y una interface universal debe ser usada.
En una arquitectura monolítica donde al ser sistemas grandes con acoplamiento
máximo de cada uno de sus componentes, el despliegue (publicaciones o liberación de nuevas funcionalidades) tiende a ser completo. Esto conlleva que el proceso de
liberación continua sea menos eficiente ya que tiene que hacerse pruebas de todo el sistema y por lo tanto pudiera que tal proceso se rompa, por tal motivo, la liberación tiene que hacerse de manera manual. Debido al tamaño de los sistemas monolitos, el despliegue toma más tiempo. Reduciendo la flexibilidad y el costo del proceso.
Algunas organizaciones grandes y exitosas como Amazon y Google han sido defensores de crear pequeños equipos que sean dueños del cada ciclo de vida de desarrollo en sus sistemas. Recientemente hemos podido ver como Netflix ha crecido en los últimos 10 años, esto gracias a la creación de sistemas modularizados que le permiten hacerlos resistentes y fáciles de escalar.
En FRISA, los sistemas que soportan los procesos CORE del negocio se encuentran desarrollados bajo una arquitectura monolítica. Bajo esta arquitectura cada cambio o mejora que se realiza requiere que se libere todo el sistema, aunque se un cambio
menor. Además, la complejidad del sistema genera que el desarrollo de nuevas funcionalidades sea lento. Y por último un crecimiento vertical en procedimiento demanda que los equipos donde se ejecuta el sistema tengan mayor capacidad de cómputo.
1.2 Propósito del proyecto
El principal propósito del proyecto es apoyar a FRISA en su estrategia de
transformación digital mediante la implementación de un ecosistema digital que permita la integración de procesos, aplicaciones o dispositivos, así como la generación de un canal para compartir información tanto con clientes como con proveedores. Además de hacer más mantenible el proceso de desarrollo de software dentro de la empresa.
1.3 Justificación
Un ecosistema digital basado en una arquitectura modular nos permitirá tener una mejor separación de los módulos que conforman los sistemas desarrollados en casa.
Esta implementación hará que los cambios al software consuman menos tiempo en ser liberados a un ambiente productivo, permitirá que se puedan adoptar nuevas
tecnologías, podrá hacerse escalabilidad horizontal en la infraestructura que soporta los sistemas (Clúster de Servidores), el tiempo de desarrollo disminuirá debido a la
segmentación de las funcionalidades y se podrá hacer una mejor separación de la complejidad. Así como mejorar la disponibilidad de las aplicaciones. Esta nueva arquitectura será la base para utilizar infraestructura basada en la nube, en servidores propios o inclusive poder hacer una mezcla.
1.4 Objetivos
Objetivos generales
Diseñar un ecosistema digital para la empresa FRISA con una arquitectura de alta disponibilidad y escalabilidad de infraestructura horizontal, que permita la integración de plataformas internas como externas.
Objetivos específicos
Seleccionar un Framework de desarrollo.
Elegir sistema operativo para hospedar servicios (microservicios)
Definir de servicios distribuidos, disponibilidad y escalabilidad.
Establecer una API de mediación.
Generar un diagrama general de arquitectura del ecosistema digital.
Implementar sistema bajo esta nueva arquitectura.
1.5 Alcances y limites
La arquitectura deberá contemplar los procesos cubiertos por el sistema actual.
El sistema que se diseñará para esta nueva arquitectura será el MES (Manufacturing Execution System) actual, SIF 2.0
El proyecto se centrará en realizar una propuesta de arquitectura basada en mini servicios con los componentes que esta necesite para su correcto
funcionamiento.
La propuesta inicial será centrada para la planta Aerospace, sin embargo, pudiera utilizarse como base para replicarse en las demás plantas
Capítulo II - Marco de Referencia
2.1 FRISA
FRISA es una empresa líder mundial en la industria de la forja con más de 46 años en el mercado y gracias a las inversiones en tecnologías de punta que se han
implementado a través de los años, se ofrecen un amplio rango de productos derivados de aleaciones y aceros que permiten satisfacer necesidades de mercados como
Aeroespacial, Petróleo y Gas, Generación de Energía a base de hidrocarburos o vapor, Construcción y Minería, Energía Eólica y Maquinaria General. En la actualidad cuenta FRISA cuenta con 4 plantas ubicadas en Nuevo León, México.
Debido a los procesos productivos que tiene la operación en FRISA, se ha apostado desde un principio por tener un equipo de desarrollo de software en las filas de su personal. Esto ha hecho que el expertis de los sistemas desarrollados en casa sean considerados como únicos y con alto valor para la empresa por el nivel de complejidad de algunos procesos, diversidad de productos que se producen y la demanda
cambiante.
La implementación del proyecto en cuestión se ubica en la empresa FRISA, y forma parte de la transformación digital trazada en los proyectos estratégicos de FRISA Evolución XXI.
2.2 Procesos de manufactura en FRISA
Fig. 1 Procesos de FRISA Aerospace / Forge
En la Fig. 1 podemos encontrar los principales procesos de manufactura que se realizan y que componen la cadena de valor son: comercial, recepción y
almacenamiento de materia prima, ingenierías (forja, maquinados y tratamientos
térmicos), cortés, forja (Calentamiento hornos, rolado y prensado), tratamiento térmico, segmentado, maquinado, laboratorio (pruebas destructivas y no destructivas), calidad de producto y logística.
La diversidad de números de partes que se producen en la planta genera que la
producción no se considere de forma lineal por lo que el proceso de manufactura puede variar, ya que en algunos casos la deformación del producto tiene que pasar por un proceso en varias ocasiones (principalmente en forja).
2.3 Sistemas CORE de FRISA
En la actualidad existen distintos tipos de sistemas paras cubrir los diferentes procesos de negocio. Para procesos administrativos se cuentan con el sistema ERP (Enterprise Resource Planning) SAP ECC, dicho sistema esta implementado en las plantas de
FRISA Aerospace, Forge y Stee (Fig. 2). La conexión directa con equipos de
producción (Prensas, Roladoras, Tornos de Maquinado, Cortadoras, etc) es realizada por el sistema SIM (Sistema desarrollado en casa). Los procesos de producción son administrados por el sistema de manufactura (MES) SIF para las plantas de FRISA Aerospace y Forge. En la planta Steel, al ser un negoció distinto al de Aerospace y Forge cuenta con su propio sistema de manufactura llamado IMAS.
Fig. 2 Diagrama de comunicación de Sistemas CORE de FRISA
2.1 Procesos administrados por sistema SIF/SIM en FRISA Aerospace y Forge
A continuación, se enlistan los módulos cubiertos por el sistema SIF:
MES - M1 Gestión de calidad. Este módulo controla desde la certificación que se tienen que hacer a los pedidos de cliente, seguimiento de no conformidades, quejas de cliente y hallazgos en auditorías tanto internas como externas
MES - M2 Administración de las especificaciones del cliente. Concentra la información de todos requerimientos que se tienen que satisfacer para crear números de parte de cada uno de los clientes.
MES - M3 Administración de especificaciones pruebas no destructivas.
Recolecta la información de las especificaciones a nivel mundial de las pruebas no destructivas tales como ultrasonidos, líquidos penetrantes y partículas
magnéticas
MES - M4 Administración de especificaciones pruebas destructivas.
Recolecta la información de las especificaciones a nivel mundial de las pruebas no destructivas tales como tensiones, impactos, rupturas, etc.
MES - M5 Configuración del diseño de productos. Este módulo integra el conocimiento ingenieril del negocio donde se administra los pasos que debe seguir un numero de parte dentro de la planta.
MES - M6 Logística y facturación. Se utiliza para dar seguimiento de los números de parte que salen de las plantas y de realizar la facturación de los productos entregados.
MES - M7 Cotización y costeo de procesos. Es el módulo comercial que se utiliza para realizar un estimado de precios para un número de parte dado o incluso tiene su propia inteligencia para proporcionar un precio estimado dependiendo de dimensiones finales solicitadas, material y cantidad.
MES - M8 Colocación y seguimiento de pedidos de cliente. Se utiliza para hacer un pronóstico, así como es la base de entrada de pedidos que se producirá dentro de alguna de las plantas.
MES - M9 Administración de materia prima. Este módulo sirve para abastecer la demanda de materia prima solicitada por los pedidos colocados, así como dar seguimiento y administrar los inventarios.
MES - M10 Optimización de materia prima. Este módulo ayuda a encontrar el mejor uso de la materia prima que se producirá dentro de las plantas
correspondientes.
MES - M11 Administración de Herramientas. Este módulo se utiliza para conocer la demanda de herramentales que se utilizarán en los procesos de forjado (Prensados y Rolados), dar trazabilidad a cada una de ellas y administrar los inventarios.
MES - M12 Control de procesos. Cortés, Forja, Pulido, Tratamiento Térmico, Inspección, Segmentado, Maquinado, Pruebas No Destructivas, Pruebas
Destructivas y Certificación.
MES - M13 Planeación de la producción. Es el encargado de liberar la producción a la planta dependiendo de la demanda que se tenga que cubrir durante un periodo de tiempo (regularmente se realiza de manera semanal).
MES - M14 Administración de documentos. Es el repositorio central que alberga todos los documentos generados en los procesos de producción o compartidos por los clientes.
MES - M15 Gestión de la capacidad de procesos cuello de botella. Modulo que controla la utilización de los equipos críticos (Prensas, Rolas y Tornos) y es capaz de generar las fechas de entrega que la producción garantiza para un pedido realizado.
2.4 FRISA Evolución XXI
FRISA Evolución XXI en un portafolio de proyectos de transformación digital donde se contemplan como punto de partida la migración de nuestro sistema ERP SAP a la nube, el cual se encuentra dividido en 4 proyectos:
Proyecto 1: Actualización de la plataforma SAP actual (ECC) a S/4 HANA en Acería y Servicios Compartidos (Finanzas, Recursos Humanos, Contabilidad y Tesorería).
Proyecto 2: Rediseño de procesos de Aero y Forge basados en SAP S/4HANA
Proyecto 3 y 4: Implementación de SAP S/4 HANA en Aero y Forge
Proyecto 5: Adelgazamiento de sistemas SIF / SIM
Fig. 3 Diagrama conceptual de sistemas después de evolución XXI
Fig. 4 Plan General de Evolución XXI
Capítulo III - Marco Teórico
3.1 Plataforma Digital
Una plataforma digital se extiende a través de varias tecnologías, las cuales cambiaran con el tiempo, y toda organización que cuente con un departamento de tecnologías la construirá por medio de proyectos a lo largo de los años. Aun así, las diversas partes de la plataforma deben funcionar juntas lo suficientemente bien como para soportar los modelos de negocio de una empresa a medida que surgen [CITATION
GarPlataformaDigitalBill \l 2058 ]
Los pasos que contempla el plan que propone Swanton en su reporte, Getting to the Details of the Digital Platform: A Gartner Theme Insight Report, son los siguientes:
Infraestructura, operaciones y métodos - las plataformas digitales utilizan nuevas formas de infraestructura y nuevas formas de trabajo en el desarrollo de
software para que este lo más rápido y confiable en ambientes productivos.
Arquitectura: la plataforma debe incorporar principios de diseño coherentes para la flexibilidad y la interacción entre los componentes que la componen. También debe permitir escalar masivamente cada componente individualmente.
Tecnologías: las empresas digitales a menudo necesitan implementar nuevas tecnologías para automatizar la toma de decisiones y garantizar que sus servicios sean seguros.
Gobierno: la plataforma necesita un gobierno transparente y descentralizado para que los gerentes que están cerca de las operaciones cotidianas puedan tomar decisiones rápidas y mantenerse al día con los cambios en el negocio.
3.2 Componentes de una plataforma digital
Las 5 áreas que componen una plataforma digital son las siguientes:[CITATION Bil19 \l 2058 ]
Sistemas de información: compuestos con el back office y las operaciones, como ERP y sistemas centrales.
Experiencia de cliente: contiene los principales elementos orientados al cliente, como portales de clientes, comercio electronico y aplicaciones para clientes.
Datos y análisis: contiene capacidades de análisis y gestión de la información.
Los programas de gestión de datos y las aplicaciones analíticas impulsan la toma de decisiones basada en datos, y los algoritmos automatizan el
descubrimiento y la acción.
IoT: conecta los activos físicos para el monitoreo, la optimización, el control y la monetización. Las capacidades incluyen conectividad, análisis e integración a sistemas centrales y OT.
Ecosistemas: admite la creación y la conexión de ecosistemas externos, mercados y comunidades. La gestión de API, el control y la seguridad son sus elementos principales.
Fig. 5 Áreas de una plataforma digital [ CITATION Bil19 \l 2058 ]
3.3 APIs y ecosistemas digitales
Las APIs son el medio por el cual los componentes de una plataforma digital son conectados. Son utilizadas para integrar, sistemas desarrollados en diferentes tecnologías, sistemas internos de una empresa con servicios alojados en la nube o para comunicar con plataformas de clientes y proveedores.
El propósito un ecosistema digital es permitir que una empresa cree valor desde afuera hacia adentro con los ecosistemas de negocios. Dando la capacidad de hacer que activos como datos, algoritmos, transacciones y procesos comerciales estén disponibles a través de una API para ecosistemas externos. Sirven también para construir ecosistemas que una empresa puede albergar para conectar nuevos socios y desarrolladores, y buscar nuevos modelos de negocio. Y por último generar la
capacidad de conectarse a los ecosistemas de la industria, como los mercados, los centros de la cadena de suministro y las redes financieras. También requiere que las
desbloquear nuevas oportunidades de ingresos de los servicios e información existentes.[ CITATION Bil19 \l 2058 ]
En un ecosistema de aplicaciones, el creador del ecosistema alienta a los socios y desarrolladores independientes a crear aplicaciones complementarias que se integran con la aplicación a través de un conjunto de API.[ CITATION San19 \l 2058 ]
3.4 Usos de un ecosistema digital
[ CITATION LeH17 \l 2058 ]
Software de gestión de API - La gestión, la seguridad y el gobierno adecuados son fundamentales, es por eso por lo que los sistemas de gestión de API son un principal componente de los ecosistemas digitales. Algunos ejemplos de estos son Kong, apigee.
API públicas orientadas al cliente: estas API externas deben ser utilizadas por clientes u otros socios en roles orientados al cliente. Estas API no son
aplicaciones o aplicaciones, son una funcionalidad clave para ser utilizadas en aplicaciones externas, aplicaciones y sitios web.
API públicas orientadas a proveedores: similares a las API orientadas a clientes, están diseñadas para usarse fuera de la empresa, pero para
proveedores en lugar de clientes. Una vez más, estas API no son aplicaciones o aplicaciones: son una funcionalidad clave para usar en aplicaciones,
aplicaciones y sitios web externos.
Portales y aplicaciones de cliente: esta área suele ser una de las primeras actividades de divulgación de una empresa a ecosistemas externos.
Portal y aplicaciones de proveedores: esta área también es una de las primeras actividades de divulgación de una empresa a ecosistemas externos.
3.5 Elementos en un ecosistema digital
Todo ecosistema digital debe considerar los siguientes cinco elementos clave:
La plataforma: la plataforma de software que proporciona la base y los elementos centrales para las ofertas en sí.
El ecosistema del propietario: puede haber uno o varios propietarios de la plataforma en sí. Los propietarios colaboran y contratan con otras
organizaciones para proporcionar y mantener la plataforma en sí. Por ejemplo, socios que ofrecen componentes complementarios, proveedores de servicios para servicios de plataforma clave, como análisis e infraestructura, y
proveedores que proporcionan elementos de software adicionales.
El ecosistema de desarrolladores: los desarrolladores que usan la plataforma para desarrollar productos y servicios complementarios. En algunas plataformas, los desarrolladores son internos, esto brinda un mayor control sobre las ofertas, pero menos capacidad de innovación.
Las ofertas: el conjunto de productos y servicios que están disponibles utilizando la plataforma.
El ecosistema del cliente: el ecosistema de clientes que hacen uso de las ofertas para uso personal o como parte de sus propios productos y servicios. El ecosistema de clientes puede consistir en múltiples segmentos de clientes que pueden ser independientes o interactuar a través de la plataforma.
La salud del ecosistema y su éxito a lo largo del tiempo dependen de que estos cinco elementos interactúen y evolucionen. Si las ofertas tienen suficiente amplitud y riqueza, se pueden crear costos de cambio significativos, lo que incentiva aún más a los clientes a quedarse. [ CITATION Blo16 \l 2058 ]
Fig. 6 Elementos de un ecosistema digital
3.6 Componentes técnicos de un ecosistema digital
En los negocios digitales, la mayoría de las comunicaciones serán de plataforma en plataforma. Por lo tanto, la capa de integración debe conectar las aplicaciones
comerciales actuales, la plataforma digital del cliente, el IoT y las plataformas digitales de un socio. Las aplicaciones para dispositivos móviles y las interfaces basadas en la web permitirán a las personas monitorear y controlar la experiencia digital. La mayoría de estas cosas utilizarán los servicios expuestos a través de las API para comunicarse, a veces ofreciendo servicios, otras veces consumiéndolos. Las aplicaciones
comerciales modernas vienen construidas bajo una arquitectura de APIs lo que facilita la posibilidad de desarrollar una capa intermedia para compartir información basada en estas aplicaciones. Los algoritmos, los análisis y la inteligencia artificial se construirán como servicios, probablemente también utilizando servicios de socios basados en la nube. Cualquier aplicación nueva probablemente se construirá en una plataforma como servicio y será nativa de la nube.
Eventualmente, un ecosistema digital necesitará ampliarse, lo que puede requerir aplicaciones de hiperescala que involucren enfoques como la arquitectura de microservicios o mini servicios.
Algunos de los servicios comerciales digitales vinculados por la capa de integración serán activados por una interacción con el cliente a través de una aplicación o interfaz web. Muchos otros serán activados por una llamada API de un socio o un evento detectado a través de IoT.
Fig. 7 Componentes técnicos de un ecosistema digital [ CITATION Bil19 \l 2058 ]
3.7 Arquitectura orientada a servicios (SOA)
La arquitectura moderna de aplicaciones comienza con la arquitectura orientada a servicios (SOA). No hay forma de evitar un enfoque de servicios. SOA permite la agilidad. Facilita la integración. Es compatible con aplicaciones multicanal. Mejora las experiencias de los usuarios. Permite un mejor rendimiento y escalabilidad. Es el núcleo de la arquitectura nativa de la nube. Hace que las aplicaciones sean más fáciles de administrar y mantener. Es compatible con la integración de Internet de las cosas
(IoT). Es la base de un programa API. Es un requisito previo para la transformación del negocio digital.[CITATION ONe20 \l 2058 ]
3.7.1 Principios SOA
El paradigma SOA se basa en tres principios fundamentales:[CITATION ONe20 \l 2058 ]
La encapsulación aboga por encapsular la capacidad de un sistema discreto como un activo de TI autónomo (es decir, un servicio) que puede ser utilizado por cualquier aplicación que requiera la capacidad. La encapsulación reduce la redundancia y permite un acceso más fácil a las capacidades de un sistema, mejorando así la usabilidad del sistema y el valor comercial.
La separación de riesgos aboga por la separación de diferentes aspectos de un sistema de software para que cada aspecto se pueda mantener de forma
autónoma. La separación de riesgos simplifica el código de software al
encapsular y refactorizar aquellas partes del software que son relevantes para un propósito o inquietud particular, reduciendo así la redundancia y las
dependencias que existen entre inquietudes, mejorando así la capacidad de mantenimiento del sistema.
El acoplamiento flexible aboga por reducir las dependencias entre los
componentes del sistema y hacer explícitas todas las dependencias restantes. El bajo acoplamiento reduce el impacto que un cambio en un componente tiene en otros componentes, mejorando así la capacidad de mantenimiento del sistema.
3.8 Diseño orientado al Dominio (DDD)
El diseño orientado al dominio es una filosofía de diseño de software para construir sistemas complejos en los que el diseño se centra en el dominio empresarial del mundo real al que sirve el software. Se esfuerza por reducir la complejidad del sistema para garantizar que el software pueda cambiarse o ampliarse fácilmente a medida que evoluciona el dominio comercial. [ CITATION ONe20 \l 2058 ]
El diseño orientado al dominio no es una tecnología o una metodología. DDD
proporciona una estructura de prácticas y terminología para tomar decisiones de diseño que se centran y aceleran los proyectos de software que se ocupan de dominios
complicados.[ CITATION Eri04 \l 2058 ]
Los principios que el diseño orientado al dominio propone son: Colocar los modelos y reglas de negocio de la organización, en el core de la aplicación; basar nuestro dominio complejo, en un modelo de software; y utilizala para tener una mejor perspectiva a nivel de colaboración entre expertos del dominio y los desarrolladores, para concebir un software con los objetivos bien claros.
3.8.1 Beneficios
: Crea una comunicación efectiva entre expertos del dominio y expertos técnicos a través de un lenguaje común (Ubiquitous Languge).
Enfoca el desarrollo de software de un área del negocio en y lo delimita a las solo las funcionalidades o servicios que necesita (Bounded Context’s).
El software es más cercano al dominio, y por lo tanto es más cercano al cliente.
Código bien organizado, permite que el testing de las distintas partes del dominio sean de manera aisladas.
Lógica de negocio reside en un solo lugar, y dividida por contextos.
Mantenibilidad de software a largo plazo.
3.8.1 Dominio
El dominio es un lugar central donde nada externo tiene que influir, complicar o distraer la idea principal: el dominio como el corazón de nuestro software.
La capa de dominio es la responsable de representar la información del negocio, la lógica del negocio, situaciones del negocio, a pesar de las dificultades que pueden conllevar la infraestructura. Es decir, nos abstraemos de los detalles tecnológicos que pueden ser la base de datos vamos a utilizar, como vamos a persistir la información
creada por nuestros sistemas o que tecnologías de diseño de interfaces vamos a utilizar en nuestro contexto final.
El primer y principal requerimiento de un modelo de dominio es ser consistente y sin contradicciones. [ CITATION Eri04 \l 2058 ]
3.8.2 Elementos del diseño orientado al dominio
3.8.2.1 Ubiquitous Language
Un proyecto enfrenta serios problemas cuando sus idiomas se fracturan[ CITATION Eri04 \l 2058 ]. La comunicación efectiva entre los desarrolladores y los expertos del dominio es esencial para el proyecto. Un lenguaje común, que sea representado en el dominio, es muy importante, esto nos ayuda a evitar problemas futuros y diseñar un software exitoso, donde la comunicación sea la clave para su realización. Un problema en el lenguaje puede generar errores que no son necesarias, e incluso los problemas de la traducción de ida y vuelta: se traduce algo desde un idioma a otro, y luego cuando se intenta traducir en reversa, tiene otro significado.
3.8.2.2 Entidades (Entities)
Las entidades son objetos del modelo que se caracterizan por tener identidad en el sistema, los atributos que contienen no son su principal característica. Representan conceptos con una identidad que se mantienen en el tiempo, y que con frecuencia también se mantienen bajo distintas representaciones de la entidad. Deben poder ser distinguidas de otros objetos, aunque tengan los mismos atributos. Tienen que poder ser consideradas iguales a otros objetos aun cuando sus atributos difieren.[ CITATION Eri04 \l 2058 ]
3.8.2.3 Objetos de valor (Value Objects)
Al contrario que las entidades los value objects representan conceptos que no tienen identidad. Simplemente describen características. Por lo tanto, solo nos interesan sus
atributos[ CITATION Eri04 \l 2058 ]. Esto conlleva una serie de diferencias a la hora de modelar value objects respecto a las entidades. Los value objects suelen ser
modelados como inmutables y son menos complejos de diseñar, ya que podremos usarlos y descartarlos según nos interese.
3.8.2.4 Servicios (Services)
Los servicios representan operaciones, acciones o actividades que no pertenecen conceptualmente a ningún objeto de dominio concreto. Los servicios no tienen ni estado propio ni un significado más allá que la acción que los definen. Al contrario que las entidades y los value objects, los servicios son definidos en términos de lo que pueden hacer por un cliente, y por tanto tienden a ser nombrados verbos. Los verbos utilizados para nombrar a los servicios deben pertenecer al ubiquitous language, o ser introducidos en el en caso de que aún no lo sean. A la hora de implementarlos tanto sus parámetros como resultados deben ser objetos pertenecientes al dominio.
Un servicio debe de cumplir tres características principales:
La operación que lo define está relacionada con un concepto de dominio, pero no es natural modelarlo como una entidad o un value object.
Su interfaz se especifica usando otros elementos del modelo de dominio.
La operación no tiene estado, por lo que cualquier cliente podría usar cualquier instancia del servicio sin tener en cuenta las operaciones que se han realizado con anterioridad en esa instancia.
Podemos dividir los servicios en tres tipos diferentes según su relación con el núcleo del dominio.
3.8.2.5 Servicios de dominio (Domain services)
Son responsables del comportamiento más específico del dominio, es decir, realizan acciones que no dependen de la aplicación concreta que estemos desarrollando, sino que pertenecen a la parte más interna del dominio y que podrían tener sentido en otras aplicaciones pertenecientes al mismo dominio. [ CITATION Eri04 \l 2058 ]
3.8.2.6 Servicios de aplicación (Application services)
Son responsables del flujo principal de la aplicación, es decir, son los casos de uso de nuestra aplicación. Son la parte visible al exterior del dominio de nuestro sistema, por lo que son el punto de entrada-salida para interactuar con la funcionalidad interna del dominio. Su función es coordinar entidades, value objects, domain services e infrastructure services para llevar a cabo una acción. [ CITATION Eri04 \l 2058 ]
3.8.2.7 Servicios de infraestructura (Infrastructure services)
Declaran el comportamiento que no pertenece realmente al dominio de la aplicación pero que debemos ser capaces de realizar como parte de este. Por ejemplo, enviar un email de confirmación tras realizar un pago, loguear transacciones, etc.
3.8.3 Arquitectura en capas (Layered architecture)
Un sistema software está compuesto por muchas partes, de las cuales, la parte que resuelve problemas para el dominio es una porción pequeña, aunque su importancia es desproporcionada a su tamaño.
Para ser capaces de trabajar con el dominio sin perdernos en otros detalles presentes en el software necesitamos desacoplar los objetos de dominio de otras funciones del sistema. Tendremos que aislar nuestro dominio del resto del sistema para así evitar confundir conceptos pertenecientes al dominio con conceptos que solo están relacionado con la tecnología utilizada.
Podemos utilizar cualquiera de las muchas arquitecturas que existen para aislar las distintas partes del sistema, pero la opción que elijamos debería dividir nuestro sistema en al menos cuatro capas: presentación, aplicación, dominio e infraestructura.
Fig. 8 Arquitectura en capas
3.8.3.1 Presentación (Presentation)
Capa responsable de mostrar la información al usuario e interpretar los eventos de entrada del usuario. Cabe destacar que el usuario puede ser un ser humano u otro sistema que se comunica con el nuestro.
3.8.3.2 (Application)
Capa que declara las funcionalidades que el software tiene que llevar a cabo
y orquesta los objetos de dominio para resolver los distintos problemas. Esta capa no contiene reglas de negocio o conocimiento, solamente coordina y delega el trabajo a la colaboración de los objetos de dominio que se encuentran en la la siguiente capa.
3.8.3.3 Dominio (Domain)
Capa donde se encuentran los conceptos del dominio y las reglas de negocio. Es la capa más importante del sistema y es la que realmente aporta valor y resuelve los problemas para los que un determinado software es creado.
3.8.3.4 Infraestructura
Capa que provee las implementaciones que apoyan a las capas definidas anteriormente. Aquí se encapsulan la mayoría de las decisiones tecnológicas adoptadas para un sistema.
3.9 Arquitectura de Microservicios
Un microservicio es un componente de aplicación de alcance estrecho, fuertemente encapsulado, acoplado libremente, desplegable independientemente y escalable de forma independiente. La arquitectura de microservicios aplica la arquitectura orientada a servicios y los principios de diseño impulsado por dominio para entregar aplicaciones distribuidas. Los microservicios tienen tres objetivos principales: agilidad de desarrollo, flexibilidad de implementación y escalabilidad precisa.[ CITATION Tho19 \l 2058 ]
El objetivo esencial de microservicio es permitir que los equipos de desarrollo creen, prueben, empaqueten, implementen y escalen de forma independiente componentes individuales dentro de una aplicación.
3.9.1 Granularidad de un Microservicios
No todas las aplicaciones tienen requisitos de agilidad extrema, por lo que a menudo es beneficioso reducir las restricciones que una arquitectura de microservicios propone, al usar patrones y modelos más tradicionales y construir componentes más grandes. Pero a medida que disminuye la granularidad y las restricciones se relajan, los beneficios de la agilidad y la escalabilidad disminuyen, además de que los componentes comienzan a parecerse cada vez menos a los microservicios.
La granularidad también afecta los requisitos de gestión y gobernanza. Los
microservicios que mantengan una implementación al pie de la letra se reemplazarán fácilmente y, por lo tanto, son bastante desechables. A medida que los servicios aumentan su alcance, se vuelven más valiosos y menos propensos a ser vistos como desechables. Y si publica la API de un servicio para su reutilización, crea dependencias que afectan su capacidad para cambiarlo.
Gartner usa diferentes nombres para diferentes niveles de granularidad:[ CITATION Tho19 \l 2058 ]
Microservicio: para permitir la entrega continua. Un microservicio es un
se adhiere estrictamente a las restricciones de diseño de arquitectura de microservicios para admitir requisitos de extrema agilidad y escalabilidad. Es desplegable y escalable de forma independiente.
Miniservicio: para mejorar la agilidad de la aplicación y evitar algunos de los aspectos más perjudiciales de una arquitectura de microservicios. Un
miniservicio es como un microservicio, pero tiene un alcance mayor y restricciones arquitectónicas relajadas. Al igual que un microservicio, un miniservicio es un componente de aplicación físicamente encapsulado, poco acoplado, desplegable y escalable de forma independiente. A diferencia de un microservicio, un miniservicio a menudo implementa más de una función. Si gestiona el estado persistente, debe tener derechos exclusivos para actualizar el almacén de datos, aunque en algunos casos un pequeño número de
miniservicios relacionados pueden compartir un repositorio de datos.
Macroservicio: para permitir el acceso a la funcionalidad dentro de una
aplicación monolítica. Un macroservicio es lo que muchas personas llamarían un servicio SOA tradicional, o quizás una API. Encapsula lógicamente una
capacidad dentro de una aplicación monolítica y expone esa capacidad a través de una API publicada. Puede crear un servicio de macros creando una API dentro del código de la aplicación o utilizando una herramienta de integración para construir un adaptador de API.
Fig. 9 Granularidad de microservicios
3.9.2 Beneficios de Microservicios
Agilidad: microservicios facilitan una práctica de liberación continua de
aplicaciones, lo que permite a una organización implementar nuevas funciones de aplicaciones tan rápido como puedan desarrollarse.
Reducción de riesgos: debido a que las implementaciones de microservicios son pequeñas e independientes, el riesgo asociado con cada implementación se reduce.
Desarrollo distribuido: microservicios reducen las dependencias entre los componentes, lo que permite a los equipos de funciones trabajar de forma más autónoma.
Flexibilidad tecnológica: debido a que los microservicios se acoplan
libremente, los equipos de desarrollo pueden usar una variedad de tecnologías e idiomas para implementar las diferentes facetas de una aplicación.
Escalabilidad: microservicios proporcionan los medios para escalar solo las partes de una aplicación que causan contención y cuellos de botella.
Resiliencia: los patrones de diseño de microservicios, cuando se aplican correctamente, producen aplicaciones de autocuración que pueden continuar operando ante cortes parciales, y que pueden recuperarse de manera rápida y elegante.
3.9.3 Ruta de adopción a la arquitectura de microservicios
La implementación de una arquitectura de microservicio requiere habilidades
arquitectónicas avanzadas. Los pasos sugeridos por Garner para una exitosa adopción de microservicios son los siguientes:[ CITATION Tho19 \l 2058 ]
Comience con la adopción básica de SOA y encapsule la funcionalidad en sus aplicaciones monolíticas, exponiéndolas como macroservicios.
A partir de ahí, comience a refactorizar el sistema monolito y cree miniservicios que implementen la funcionalidad a nivel de dominio.
Cambie a microservicios cuando crea que está listo para comenzar a
descomponer sus bases de datos monolíticas en modelos de datos planos y listos para microservicios.
Utilice microservicios solo donde lo necesite: en aplicaciones con requisitos de extrema agilidad o escalabilidad.
No tengas miedo de mezclar paradigmas. La mayoría de las personas usan microservicios en combinación con arquitecturas monolíticas y de miniservicio.
Fig. 10 Ruta de adopción a la arquitectura de microservicios
3.10 API Mediation Layer
La capa de mediación de APIs es la solución recomendada para abordar desafíos de seguridad control de tráfico de la red interna y monitoreo de las peticiones que se realizan a cada uno de los componentes de un ecosistema. Coloca uno o más mediadores entre un consumidor de API y una implementación de servicio de API.
Estos mediadores de API protegen y controlan el acceso a las API, y mejoran y permiten la utilización de las API.
En aplicaciones modernas el uso una capa de mediación de APIs es importante para comunicarse con una red de servicios distribuidos que implementan la funcionalidad de back-end. Los servicios que corren el back-end pueden ser de diferente granularidad;
pueden ser servicios existentes o recientemente desarrollados para admitir esta
aplicación en particular; y pueden ser administrados internamente, implementados en la nube o proporcionados por un tercero.
Fig. 11 API de medicación
La capa de mediación de APIs permite garantizar que las políticas de seguridad y su cumplimiento se apliquen de forma adecuada. Mejora el rendimiento y la escalabilidad al admitir el enrutamiento y el equilibrio de carga, y por último ayuda a reducir la
inseguridad de los contratos definidos en una API. También mejora la usabilidad de las API al admitir experiencias de API personalizadas, ya que las salidas de las APIs internas pueden ser transformadas a un formato compatible. La capa de mediación permite que un servicio exponga una "API interna" que refleja directamente su modelo de dominio, y una o más "API externas" adaptadas a los requisitos específicos del cliente. Un mediador puede inyectar capacidades adicionales que pueden enriquecer la interacción. El modelo es, por definición, extensible, permitiendo cualquier tipo de capacidad inyectada.[ CITATION Tho19 \l 2058 ]
Las API se han convertido en la manera más popular de realizar la integración con aplicaciones heredadas y empaquetadas. Sin embargo, en muchos casos, una API por
sí sola no es apropiada para permitir la conectividad de todos los consumidores. Las API para aplicaciones heredadas y empaquetadas a menudo usan formatos, protocolos y métodos de autenticación / autorización definidos por ellos mismos lo que dificulta la sincronización de datos.
Una capa de mediación puede simplificar la conectividad heredada al admitir capacidades como el mapeo de credenciales, traducción de protocolos y transformación de mensajes.
Existen aspectos importantes que se deben de tomar en cuanta al utilizar una capa de mediación en la integración de sistemas heredados y empaquetados:
Si las aplicaciones no exponen ninguna API, se requerirá la habilitación del servicio básico de estas aplicaciones. Deberá construir o comprar algún tipo de adaptador para la aplicación. Una vez que el adaptador está en su lugar, un mediador de API puede abstraerlo y exponer API externas que lo hacen más fácil de consumir.
La capa de mediación podría construirse internamente o implementarse a través de una puerta de enlace API para escenarios de integración simples y mínimos.
Las aplicaciones modernas utilizan métodos de control de acceso más actuales como SAML, OAuth y OpenID Connect. Estos métodos actuales deben
correlacionarse con los mecanismos de autorización y autenticación patentados antiguos. La mediación API puede proporcionar el puente necesario.
3.11 Seguridad en API
La mayoría de los ataques a una API tienen una cosa en común: la organización atacada no tiene idea acerca de su API no segura hasta que es demasiado tarde. Por tal razón el primer paso en la seguridad de la APIs es descubrir las APIs que su organización está proporcionando o que son consumidas de un proveedor o cliente.
Las aplicaciones móviles y web son un buen lugar para comenzar, ya que a menudo las API son usadas como parte de aplicaciones web modernas o aplicaciones móviles
creadas con frameworks como Angular o React. Estas incluyen aplicaciones de una sola página (SPA) que usan API como núcleo de comunicación con el back-end. Otra fuente de API es la integración de aplicaciones. Algunas organizaciones también
pueden tener un programa API abierto que incluye un portal para desarrolladores: estas API públicas deben estar claramente protegidas. Finalmente, también considere las API de terceros que usa su organización. Si el proveedor de API sufre una violación de seguridad, esto afecta su seguridad, como consumidor de API.[ CITATION ONe19 \l 2058 ]
3.11.1 Principales vulnerabilidades de seguridad
Fig. 12 Principales vulnerabilidades de seguridad
1. Claves API sin garantía en repositorios y almacenamiento. Las claves API u otras claves, como las claves SSH o las claves privadas SSL / TLS, se pueden descubrir en el almacenamiento basado en la nube como Amazon S3 o en repositorios de código como Github, que se dejan abiertos al público en lugar de tener acceso controlado.
2. Claves API codificadas en aplicaciones. Las claves API u otras credenciales pueden estar codificadas en aplicaciones web y móviles y sujetas a ataques de descompilación, en dispositivos IoT o en aplicaciones móviles.
3. Defectos de lógica API. Las API pueden tener errores u otros defectos lógicos que pueden ser explotados.
3.11.2 Protección distribuida de seguridad de API
Las puertas de enlace API (capa de mediación) se han utilizado tradicionalmente para proteger las API. Recientemente, los proveedores de firewall de aplicaciones web han agregado cierto soporte para la protección contra amenazas API. Aun así, una
estrategia de defensa puramente basada en el perímetro "API gateway y WAF" no es adecuada para asegurar las API. Esto se debe a varios factores.
El uso generalizado de las API internas agrega el requisito de asegurar el uso interno (denominado tráfico API "este-oeste") al requisito de asegurar el uso proveniente de fuera de la organización (denominado tráfico API "norte-sur").
Dispositivos móviles que proporcionan acceso a las API a través de aplicaciones móviles, que pueden manipularse o modificarse para atacar una API.
La entrega de API en la nube, especialmente cuando las API se crean utilizando servicios como AWS Lambda y Microsoft Azure Functions, significa que la seguridad de la API también debe proteger estos servicios en la nube.
Fig. 13 Diagrama de protección distribuida de API de mediación
La puerta de enlace API externa realiza la autenticación para el tráfico "norte- sur", luego puede "inyectar" contexto de seguridad en las llamadas API
utilizando estándares como los tokens web JSON (JWT). La malla de servicio puede usar esta información de contexto contenida en los JWT, incluidos los atributos del cliente API, como su ubicación, para realizar una autorización detallada basada en la aplicación de llamada o el usuario final. Otro beneficio de esta arquitectura es que el tráfico de microservicio a microservicio ("este-oeste") no necesita pasar a través de la capa de puerta de enlace externa, y también puede usar tokens web JSON, que tienen menos sobrecarga que usar tokens de
acceso OAuth. De esta manera, las API se pueden proteger desde el borde hasta el punto final.
3.12 Framework de desarrollo de software
Un framework es una abstracción en la que cierto código común provee una
funcionalidad genérica que puede ser sobrescrita o especializada de forma selectiva por medio de código con funcionalidad específica provisto por los clientes del
framework (desarrolladores de software / programadores)[ CITATION Pre94 \l 2058 ]
El utilizar Frameworks de desarrollo es debido a la complejidad de muchas de las aplicaciones informáticas de hoy en día que han hecho prácticamente inviable el desarrollo de aplicaciones sin tener como base la reutilización de código, los cuales permiten que los desarrolladores puedan evitar partir desde cero en cada proyecto.
Según Pree, los frameworks están conformados por zonas congeladas (frozen pots) y zonas calientes (hot spots) Las partes congeladas definen la arquitectura general de un sistema de software, es decir, sus componentes básicos y las relaciones entre estos.
Esas partes permanecen inalteradas (congeladas) en cualquier instanciación del framework Las partes calientes representan los puntos en los que los programadores pueden añadir su propio código para añadir la funcionalidad especifica de su propio proyecto.[ CITATION Pre94 \l 2058 ]
3.12.1 Ventajas:
Un framework facilita el desarrollo de software permitiendo a los diseñadores y programadores dedicar su tiempo a lograr los requerimientos de software en lugar de lidiar con los detalles de bajo nivel necesarios para obtener un sistema funcional, de esta forma se puede reducir el tiempo total de desarrollo de la aplicación.
Utilizan patrones de diseño, lo cual permite que el código resultante sea limpio y extensible para futuras ampliaciones. Entre ellos destaca el Modelo Vista
Controlador que comentamos anteriormente.
Facilitan servicios genéricos necesarios en la mayoría de los proyectos. De esta forma, también se utiliza código ya testeado, evitando así en el futuro la
repetición de errores.
Favorecen la reutilización de código, simplificando el proceso de desarrollo. Ello provoca una amplia ganancia de tiempo en cuanto a la programación y el
diseño.
Aumenta la facilidad de depuración del código.
Capítulo IV – Metodología de desarrollo software en FRISA
En FRISA, el desarrollo de aplicativos de SW (o proyectos en general) sigue una metodología ágil que consiste básicamente en desarrollo incremental de servicios o características de un producto. Todos los requerimientos de mejoras o proyectos deben de ser alineados a las estrategias del negocio, motivo por el cual la revisión de estos requerimientos se realiza de forma trimestral a manera de medir el cumplimiento en este lapso de tiempo.
4.1 Definiciones
Tabla 1 Definiciones de metodología de desarrollo de software en FRISA
Concepto Descripción
Metodología Ágil Es una práctica de administración de requerimientos en la cual se realizan entregas continuas en determinados períodos de tiempo.
User Story Cualquier requisito del usuario que
implique que se tenga que hacer una o varias de las siguientes actividades:
análisis, diseño, desarrollo, pruebas y/o implementación.
Iteración Periodo de tiempo que abarca el diseño,
desarrollo, pruebas e implementación de uno o varios entregables. (Actualmente son dos semanas).
Kanban Es un sistema que se utiliza para
administrar requerimientos a través de un flujo definido. Los requerimientos se representan en forma de cartas y las columnas representan las etapas del proceso.
Áreas de Acción Áreas del negocio a las que se les da servicio.
Proyecto Es un requerimiento que se compone de
varios User Stories.
Mejora Es un requerimiento equivalente a un
4.2 Roles y Responsabilidades
Tabla 2 Roles y responsabilidades de metodología de desarrollo de software en FRISA
Rol Descripción y responsabilidades
Developer/Engineer Es la persona encargada de diseñar, desarrollar, probar e implementar los entregables.
Tiene conocimientos básicos del negocio y conocimientos altos en las tecnologías usadas para el diseño, desarrollo, pruebas e implementación de los entregables.
Operations Es la persona encargada de dar soporte y
mantener en función las aplicaciones.
También puede diseñar, desarrollar, probar e implementar entregables.
Tiene conocimientos altos del negocio y conocimientos medios en las tecnologías usadas para el diseño, desarrollo, pruebas e implementación de los entregables.
Architect Es la persona encargada de ayudar a los
roles de Developer/Engineer y Operations con la arquitectura de solución de los entregables.
Tiene conocimientos altos del negocio y conocimientos altos en las tecnologías usadas para el diseño, desarrollo, pruebas e implementación de los entregables.
Product Owner Es la persona encargada de revisar los requerimientos con los usuarios para darlos de alta en la herramienta usada para la administración de entregables.
Define los entregables que se van a hacer en cada iteración.
Se encarga de validar y aprobar los cambios de entregables dentro de las iteraciones solicitados por los usuarios.
Tiene conocimientos altos del negocio y conocimientos bajos en las tecnologías usadas para el diseño, desarrollo y pruebas de los entregables, su enfoque es más hacía el usuario final.
Team Lead Es la persona encargada de dar apoyo a los
roles de Developer/Engineer y Operations para el diseño, desarrollo, pruebas e implementación de los entregables.
Tiene conocimientos altos del negocio y conocimientos altos en las tecnologías
usadas para el diseño, desarrollo, pruebas e implementación de los entregables.
Champion Es la persona encargada de que se lleve a
cabo el User Story, se encarga de la fase de aprobación y validación.
4.3 Administración de Proyectos y Mejoras
La administración de los proyectos y mejoras se lleva a cabo por medio de una herramienta de Azure DevOps que permite planear y dar seguimiento a los requerimientos por medio de iteraciones que abarcan un período de tiempo.
4.4 Diagrama de Proceso
Fig. 14 Diagrama de proceso de metodología de desarrollo de software FRISA
4.5 Metodología Ágil
La planeación y seguimiento de los requerimientos se realiza basada en una
metodología ágil, teniendo juntas recurrentes de revisión y juntas de planeación para cada iteración.
El backlog está compuesto por un conjunto de User Stories. Los User Stories pueden componerse de tareas. Los User Stories en la herramienta pueden visualizarse en forma de listado (Fig. 15) o como vista de Kanban (Fig. 16).
Fig. 15 Listado de User Stories
Fig. 16 Kanban de User Stories
El Kanban se conforma de cartas que representan los User Stories. Las columnas representan los estatus de los User Stories.
To Do: representa el backlog de User Stories.
Developing: representan los User Stories en los que actualmente se está trabajando.
User Testing: representan los User Stories que han sido enviados al usuario para que se realicen pruebas.
Done: representan los User Stories que han sido aprobados por el usuario final y liberados en producción.
Las cartas del Kanban en color azul representan User Stories de proyectos. Las cartas en color blanco representan User Stories de mejoras en el sistema.
4.6 Alta de User Stories
Los requerimientos son solicitados por los usuarios y posteriormente se agregan en el backlog como User Story.
La información que se llena es la siguiente: (Fig. 17)
Time Estimation: tiempo estimado en horas de desarrollo, pruebas e implementación.
State: representa el estatus actual.
Assignee: representa el Developer/Engineer responsable del desarrollo, pruebas e implementación.
Champion: representa el usuario responsable de probar y aprobar el User Story.
Business Area: representa el área de acción del Champion.
Type: representa el tipo de User Story, ya sea proyecto o mejora.
Total Work: representa la suma de horas reales trabajadas en el User Story.
Fulfilled: representa si el User Story cumplió con las necesidades del usuario.
Feedback: link de la encuesta de satisfacción del usuario.
Fig. 17 Datos de User Story
4.7 Planeación de User Stories
La planeación de los User Stories para cada iteración se trata de hacer con una semana de anticipación tomando en cuenta la priorización dada por los responsables de cada área de acción. En la planeación de las iteraciones, se toma en cuenta los días inhábiles y la capacidad de desarrollo de los miembros del equipo.
4.8 Asignación de User Stories
Los requerimientos son asignados a los miembros del equipo en las juntas de planeación. Se asignan en base a la capacidad disponible de cada uno de los miembros. El Team Lead es el encargado de dar de alta los User Stories en la herramienta y asignarlos al Developer/Engineer. Cada miembro del equipo puede revisar en la herramienta que User Stories tiene asignado y la prioridad que tienen para comenzar a trabajar en ellos.
4.9 Desarrollo de User Stories
El Developer/Engineer antes de comenzar un User Story debe contactar al Team Lead o al Product Owner para entender la necesidad y el alcance del User Story.
