Gestión de requerimientos no funcionales en SOA: Más allá de los servicios

Transcripción

1 Gestión de requerimientos no funcionales en SOA: Más allá de los servicios Jorge Humberto Arias B. Oracle Consulting LAD Bogotá-Colombia 1

2 Experiencia es lo que tú consigues, cuando no consigues lo que quieres Randy Pausch, 2008 CMU (En su best seller The last lecture ) Visión es el arte de ver las cosas invisibles. Jonathan Swift ( ) 2

3 Agenda 1. Motivación 2. Contexto RNF 3. Gestión de RNF dentro de SOA 4. Conclusiones

4 Motivación: Análisis de arquitectura dirigido por el negocio 1) Problema de negocio 2) Identificación del modelo Operacional 3) Identificación del QUE vía EA (Enterprise Architecture) 4) Definición del COMO vía SA (Solución Architecture) 5) Definición de la arquitectura técnica de implementación

5 Motivación: Análisis de arquitectura dirigido por el negocio 1) Problema de negocio Empresa Línea de negocio Proyecto 2) Identificación del modelo Operacional 3) Identificación del QUE vía EA (Enterprise Architecture) Diversificación Replicación Coordinación Unificación Análisis dimensional del problema ( architectural view) Elaboración del AS-IS Definición del TO-BE Identificación de brechas Elaboración del roadmap priorizado 4) Definición del COMO vía SA (Solución Architecture) Identificación del estilo de arquitectura Definición de arquitectura lógica Definición de la arquitectura física

6 Motivación: Arquitectura de solución Estilo de arquitectura (Pipes, Multi-ier, Messages, servicios) Arquitectura Lógica Arquitectura técnica

7 Motivación: Evolución de estilos de arquitectura Modelo host 1980 Terminal Host - Lógica Presentación - Lógica funcional - Datos

8 Motivación: Evolución de estilos de arquitectura Modelo Cliente/Servidor dos niveles Cliente - Lógica Presentación - Lógica funcional Servidor -Datos 1980 Terminal Modelo host Host - Lógica Presentación - Lógica funcional - Datos

9 Motivación: Evolución de estilos de arquitectura Modelo Cliente/Servidor dos niveles Cliente - Lógica Presentación - Lógica funcional Servidor -Datos 1980 Terminal Modelo host Host - Lógica Presentación - Lógica funcional - Datos Modelo Cliente/Servidor modificado Cliente - Lógica Presentación Servidor - Lógica funcional -Datos 1998

10 Motivación: Evolución de estilos de arquitectura Modelo Cliente/Servidor dos niveles Cliente - Lógica Presentación - Lógica funcional Servidor -Datos 1980 Terminal Modelo host Host - Lógica Presentación - Lógica funcional - Datos Modelo Cliente/Servidor modificado Cliente - Lógica Presentación Servidor - Lógica funcional -Datos 1998 Terminal (Browser) WebServer AppServer Multicapas Lógica Presentación Lógica Negocio (componentes) Datos DBServer

11 Motivación: Evolución de estilos de arquitectura (Dónde estamos y qué hemos aprendido? (1) Qué hemos aprendido después de 35 años de evolución?

12 Motivación: Evolución de estilos de arquitectura (Dónde estamos y qué hemos aprendido? (2) Las aplicaciones deben estructurarse alrededor de capas Por qué? La reglas del negocio no deben estar muy separadas de los datos o visceversa Qué perdemos y ganamos con esta decisión? La emulaciones de terminal eran, son y serán bonitas Está de acuerdo? Y recuerde Kiss It Simple and Stupid Cuantas veces cometemos los mismos errores por ser demasiado técnicos?

13 Cliente Motivación: Evolución de estilos de arquitectura () Modelo Cliente/Servidor dos niveles - Lógica Presentación - Lógica funcional Servidor -Datos Canales (Web2.0) Portal BPM Dashboard ESB Modelo SOA/BPM Pesentación Negocio Datos Modelo Cliente/Servidor modificado Cliente - Lógica Presentación Servidor - Lógica funcional -Datos 1998 Terminal (Browser) WebServer AppServer Multicapas Lógica Presentación Lógica Negocio (componentes) Datos DBServer

14 Motivación: Los proyectos de TI son cada vez más complejos Las arquitecturas han tenido que venir evolucionando como forma de respuesta a las necesidades, cada vez más exigentes y diversas, del negocio. Los estilos de arquitectura no son una moda, son una clara forma de resolver y responder a la complejidad (Legacy, Client-Server, Multi-capas, Servicios, etc.) Cada estilo de arquitectura trae consigo ventajas y desventajas. Es por esto que es el contexto del problema de negocio quien indica/define el estilo de arquitectura correcto. El impacto de nuestras decisiones cada día es mayor en el negocio. Los problemas son más de negocio que de tecnología

15 Motivación: El todo es más que las suma de sus partes Aplicación de magnitud empresarial = Procesos y Requerimientos funcionales + Estilo de arquitectura correcto + Gestión de requerimientos no funcionales basado en el estilo de arquitectura + Experiencia: Patrones y buenas prácticas ARQUITECTURA XXIX Salón de Informática - Agosto'

16 Motivación: En resumen Las apuestas de negocio cada día son más agresivas. El mundo cada día está más globalizado; por esta razón debemos potenciarnos con un modelo tecnológico lo suficientemente veloz y lo suficientemente flexible que permite enfrentar dicha agresividad. SOA inspirada en una visión EA es quizás una de las respuestas más claras para estructurar este modelo tecnológico Todos estas fuerzas externas (Business Driver y RNF) deben ser gestionadas y consideradas dentro de la especificación de la arquitectura orientada a servicios. 16

17 Agenda 1. Motivación 2. Contexto RNF 3. Gestión de RNF dentro de SOA 4. Conclusiones

18 Contexto: Arquitectura & Fuerzas Externas Contexto Relaciones Proceso de negocio Funcionalidad Servicio Componente Objeto Elemento estructural Elemento estructural Motivadores de negocio Relaciones Condiciones de mercado Requerimientos no funcionales Elemento estructural Relaciones Interfaces Integraciones Mecanismos de comunicación Fuerzas Externas que gobiernan y dirigen la estructura y relaciones 18

19 Contexto: Motivadores de negocio (Business Drivers) Toda organización, empresa o entidad de gobierno está sujeto a fuerzas externas que definen la forma en que deben ser entregados, soportados y operados los servicios y productos que mercadea. El impacto de estas fuerzas externas (Tendencias del entorno) sobre la organización reciben el nombre de motivadores de negocio Dependiendo de la vertical de la industria u organización existen diferentes motivadores de negocio: Reduce time to market (Flexibilidad, BPM, BRE, SOA) Orientación al cliente y servicios más que a productos ( CRM, Configurador de servicios, modelos de fidelización) Orientación a procesos de negocio medibles Modelo de combos y servicios de valor agregado( 3 en 1) Vistas 360 del cliente (cross-selling, up-selling) Autoservicio Multicanalidad Regulaciones de gobierno 19

20 Seguridad Contexto: Multi-canalidad de servicios & Procesos CANALES Portal Agencias IVR Intranet ATM PROCESOS SERVICIOS Gestion Tarjetas Digitalización documentos Actualización/ Información de Clientes Catalogo de productos Simuladores Motor de riesgos (scoring) Gestion Producto Gestion cuenta de ahorros Vista 360 Clientes Liquidadores EIS Cuentas de ahorros Tarjetas Credito Scoring Credito ERP CRM Banca Seguros Banca Corporativ a Moneda internacio nal Credito Vehiculos DHW Autorizador INFRAESTRUCTURA iseries ERP CRM J2EE APPSERVER IIS +.NET Requerimientos no funcionales de infraestructura

21 Contexto: Integración horizontal ( Cadenas de valor Inter-organización) Dell: Order 2 Cash Business Process Cliente Pago Factura Cuenta Orden Dell China Logistics DHL Citibank Customer Care Inc Capturar Orden Aprovisionar Orden Entregar Orden Facturar & Recolectar Pago Evaluar Prestación. servicio 21 Necesitamos estructurar dialectos de negocio Basado en modelos canómicos que den flexibilidad

22 Bienvenido al Siglo XXI, esto no es un sueño, no es más que una consecuencia de Globalización 3.0 (Léase The world is flat ) 22

23 Contexto: Qué cosas Influencia la arquitectura? Arquitectura de Solución del sistema empleando el estilo SOA Es influenciado Restringe a Business Driver - Multicanalidad - Reduce Time 2 Market - Orientacion a Clientes - Orientacion a Procesos - Cadenas de valor Horizontales - Regulaciones de gobierno Calidades sistémicas Funcionalidad Desempeño Disponibilidad Interoperatibilidad Extensibilidad etc. 23

24 Contexto: Calidades Sistémicas (1) Funcionalidad Funcionalidad es la principal calidad del sistema, pero no la única y exclusiva. Categorías Observables en tiempo de ejecución ( run-time behavior ) Desempeño, Seguridad, disponibilidad, usabilidad, funcionalidad. No observables en tiempo de ejecución ( build-time behavior ) Portabilidad, mantenibilidad, reusabilidad, integridad, capacidades y facilidades de pruebas 24

25 Contexto: Calidades Sistémicas de la arquitectura (2) Las calidades son atributos de: Sistema & Arquitectura ( Observables y no observables) Negocio ( costos, time-to-market, uso y reutilizacion de sistemas legados. Trade-offs Por lo general las calidades nunca se podrán aplicar en sentido puro. (Ver Ejemplo) 25

26 El desempeño definido en términos de tiempos de acceso y tiempos de respuesta a las plataformas tecnológicas que soportan la operación del negocio de una organización NO es considerada una fuerza motivadora para adoptar una visión SOA/BPM. BPM/SOA es impulsado por principios de Flexibilidad de negocio, estandarización, portabilidad y reusabilidad. Estos principios por lo general van en contravía del desempeño. 26

27 Contexto: Calidades Sistémicas de la arquitectura (3) - Resumen Usabilidad Accesibilidad Facilidad Operabilidad Confiabilidad Tolerancia a fallos Robustez Seguridad Desempeño Latencia Throughtput Eficiencia Escalabilidad Soporte Mantenibilidad Maniobrabilidad Extensibilidad Portabilidad Interoperabilidad 27 Facilidad de Pruebas

28 Contexto: Arquitectura Conceptual multicapas Mapping- RNF (Partimos de la base) CANALES Portal Agencias IVR Intranet ATM PROCESOS SERVICIOS Gestion Tarjetas Digitalización documentos Actualización/ Información de Clientes Catalogo de productos Simuladores Motor de riesgos (scoring) Gestion Producto Gestion cuenta de ahorros Vista 360 Clientes Liquidadores EIS Cuentas de ahorros Tarjetas Credito Scoring Credito ERP CRM Banca Seguros Banca Corporativ a Moneda internacio nal Credito Vehiculos DHW Autorizador INFRAESTRUCTURA iseries ERP CRM J2EE APPSERVER IIS +.NET Requerimientos no funcionales de infraestructura

29 Contexto: Arquitectura Conceptual multicapas Mapping- RNF ( Modelo tradicional) Z o n a P r o v e e d o r e s Zona de Canales Zona SOA Zona Monitoreo Zona Datos S e r v i c i o Portal Legacy system BI IVR CRM OLAP Agencias Internet Modelo N-Tier Tradicional ERP OLTP 29 ATM? Quien maneja la traducción de formatos y asegura la entrega de mensajes? AppServer Legados

30 Contexto: Arquitectura Conceptual multicapas Mapping- RNF (Uso de servicios) Zona Proveedores Zona de Canales Zona SOA Zona Monitoreo Zona Datos Servicio Portal? No se puede delegar al consumidor la composición (Manejo Transaccional?) Servicios Negocio Legacy system BI IVR Agencias? Servicios Datos CRM OLAP Internet Servicios infraestructura ERP OLTP ATM Servicios Presentación AppServer Legados 30

31 Contexto: Arquitectura Conceptual multicapas Mapping- RNF (Uso de procesos) Zona Proveedores Zona de Canales Zona SOA Zona Monitoreo Zona Datos Servicio Portal Servicios Negocio Legacy system BI IVR Procesos S2S Servicios Datos CRM OLAP Agencias Internet Procesos H2S Servicios infraestructura ERP OLTP ATM Procesos S2S Servicios Presentación AppServer? Legados Cómo va el negocio? 31

32 Contexto: Arquitectura Conceptual multicapas Mapping- RNF (Uso de métricas y monitoreo ) Z o n a P r o v e e d o r e s Zona de Canales Zona SOA Zona Monitoreo Zona Datos S e r v i c i o Portal Servicios Negocio Legacy system BI IVR Procesos S2S Servicios Datos CRM OLAP Agencias Procesos H2S Internet Servicios infraestructura ERP OLTP ATM Procesos S2S Servicios Presentación AppServer OK Warning Error Legados Dashboard 32

33 Contexto: En resumen Todo estilo de arquitectura es influenciado por motivadores de negocio y calidades sistémicas. La adopción del estilo de arquitectura SOA es motivado por principios de flexibilidad, reusabilidad, interoperabilidad, mantenibilidad y no por principios de desempeño (Tiempo real) SOA no es una moda es una respuesta a las necesidades del negocio alrededor de los modelos tradicionales de tecnología. Estructure y planee una solución bajo el enfoque arquitectónico que propone SOA empleando un blue-print de trabajo que le permita visualizar la big-picture de la solución. 33

34 Agenda 1. Motivación 2. Contexto RNF 3. Gestión de RNF dentro de SOA 4. Conclusiones

35 Gestión de requerimientos - Multicanalidad Servicios Adaptador Tranformación Procesos Servicios Tranformación Portal GenerarPedido Portal GenerarPedido Legacy system BI IVR GenerarPedido IVR CRM OK Warning Error OLAP Agencias Dashboard GenerarPedido Agencias Procesos S2S ERP OLTP Internet ATM Procesos H2S AppServer Legados 35 Dialecto Canal Dialecto Canónico Dialecto Proveedor

36 Gestión de requerimientos Multicanalidad via objetos canónicos Modelo de objetos genéricos (Canónicos) Empleado Cuenta Factura Canal (Siebel) Balance Tarjeta Crédito Problemas de gobernabilidad: Quien mantiene esto? Empleado Cuenta Factura Proveedor iseries Balance Tarjeta Crédito Empleado Cuenta Factura Canal (IVR) Balance Tarjeta Crédito ENTIDADES CANONICAS Empleado Balance Cuenta Tarjeta Factura Crédito FIX HR-XML IFX Dialectos de industria 36

37 Gestión de requerimientos Flexibilidad (Localización de reglas de negocio) Portal Servicios Adaptador ProcesarPedido Portal Procesos Reglas de control de flujo Servicios Crear Cliente CRM Reglas de negocio OLTP IVR Agencias ProcesarPedido IVR Procesar Pedido Venta Aplicar Cargo Facturador Prepago OLAP La correcta ubicación garantiza flexibilidad y promueve reusabilidad ProcesarPedido Agencias Internet ATM Reglas de enrutamiento Actualizar Inventario Inventario Físico Inventario Lógico 37 Dialecto Canal Dialecto Canónico Dialecto Proveedor

38 Gestión de requerimientos Manejo transaccional (1) Servicios Adaptador Procesos Servicios TX OLTP Portal ProcesarPedido Portal TX Crear Cliente IVR Agencias Internet ProcesarPedido IVR ProcesarPedido Agencias Procesar Pedido Venta TX X TX Aplicar Cargo TX Aplicar Debito Aplicar Crédito Facturador Prepago OLAP ATM Actualizar Inventario Inventario Físico Inventario Lógico 38 Dialecto Canal Dialecto Canónico Dialecto Proveedor

39 Gestión de requerimientos Manejo transaccional (2) Alrededor de las transacciones debe asegurarse el ACID (Atomocity, Consistency, Isolation and Durability) Dentro de una arquitectura SOA puede llegarse a requerir control transaccional alrededor de: Proveedor de servicio Servicio Proceso de negocio Existen diferentes enfoques y mecanismos para garantizar el ACID 2PC (Two Phased Commit) (Proveedor del servicio) Compensación (Proceso & Servicio) 39 Cuando dos o más funcionalidades residentes en el mismo sistema son llamadas bajo el mismo contexto transaccional debe implementarse un servicio de mayor nivel de granularidad al interior de la plataforma proveedora que coordine la transacción.

40 Gestión de requerimientos Manejo transaccional (3) Servicios Adaptador Procesos Servicios 2PC OLTP Portal IVR Agencias ProcesarPedido Portal ProcesarPedido IVR ProcesarPedido Agencias Procesar Pedido Venta S -1 Crear Cliente S -1 Aplicar Cargo S -1 2PC Aplicar Debito Aplicar Crédito Facturador Prepago OLAP Internet ATM Actualizar Inventario S -1 S -1 S -1 Inventario Físico Inventario Lógico 40 Dialecto Canal Dialecto Canónico Dialecto Proveedor

41 Gestión de requerimientos Manejo de Excepciones (1) Servicios Adaptador Procesos Servicios Portal Crear Cliente X OLTP IVR Agencias ProcesarPedido IVR Procesar Pedido Venta M L M Repetir G L CRM OLAP Internet ATM Proceso de gestión de errores Excepciones: Genera (G) Captura (C) Maneja (L) 41 Dialecto Canal Dialecto Canónico Dialecto Proveedor

42 Gestión de requerimientos Manejo de Excepciones (2) La captura, propagación y gestión de excepciones es fundamental para garantizar una solución confiable, robusta y consistente. Como parte de la gestión de una excepción en un ambiente de servicios se puede considerar: Repetir la solicitud: Si obedece a un problema de infraestructura Determinar time-out entre repeticiones (t) Numero de repeticiones (m) Programar a una capa de nivel de superior si se alcanza t m veces. Propagar a la capa de nivel superior si obedece a un problema de negocio o data entry 42 Sí el problema es de negocio, se propaga y el receptor es un proceso de negocio, este último debe proceder a capturar el error y a gestionar el mismo delegando el manejo de la excepcion a un proceso de gestión de errores.

43 Gestión de requerimientos Generación de Tableros de Control (1) Dashboard Servicio Facade Eventos de negocio Repositorio de eventos 43

44 Gestión de requerimientos Generación de Tableros de Control (2) Eventos Alertas de negocio Métricas de negocio Tablero de control (Dashboard) Numero de créditos de consumo otorgados en la ciudad de Bogotá en la última semana? Dimensión: Geografía Bogotá Fact: Créditos Otorgados Dimensión: Tiempo Último año 44 Dimensión: Tipo Crédito Consumo Modelo Estrella

45 Gestión de requerimientos Generación de Tableros de Control (3) Z o n a P r o v e e d o r e s Zona de Canales Zona SOA Zona Monitoreo Zona Datos S e r v i c i o Portal Servicios Negocio Legacy system BI IVR Procesos S2S Servicios Datos CRM OLAP Agencias Procesos H2S Internet Servicios infraestructura ERP OLTP ATM Procesos S2S Servicios Presentación AppServer OK Warning Error Legados Dashboard 45

46 Gestión de requerimientos Gestión de Seguridad (1) Qué no le pase a usted! Tomado de Internet : Pictures.com Derechos reservados

47 Gestión de requerimientos Gestión de Seguridad (2) Dónde estamos parados? Qué Requerimientos debemos Soportar? Infraestructura SOA 47

48 Gestión de requerimientos Gestión de Seguridad (3) Privacidad Privacidad: Encripción WS-Security (Encripción a nivel de mensaje) Menos intrusivo para consumidores externos Trama plana HTTPS (Encripción a nivel de Transporte) Requiere más infraestructura 48 WS-Security (Encripción a nivel de mensaje)

49 Gestión de requerimientos Gestión de Seguridad (4) Ejemplo: Privacidad a Nivel de mensaje <?xml version='1.0'?> <PaymentInfo xmlns=' <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number> </Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo> <?xml version='1.0'?> <PaymentInfo xmlns=' <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number> <EncryptedData xmlns=' Type=' <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo>

50 Gestión de requerimientos Gestión de Seguridad (5) Integridad de mensajes Integridad& No-repudio: Firmas Digitales WS-Security (Firmas a nivel de mensaje) Trama plana HTTPS (Encripción a nivel de Transporte) 50 WS-Security (Firmas a nivel de mensaje)

51 Proxy de Seguridad Gestión de requerimientos Gestión de Seguridad (6) Autenticación (Quíen) & Autorización (Qué) Servicios Adaptador Procesos Servicios Portal Consultar Saldo Consultar Saldo OLTP IVR ProcesarPedido IVR Procesar Pedido Venta Crear Cliente CRM Agencias Entry Point OLAP Internet ATM HTTPS Directorio de servicios Repositorio de políticas WS-Security Autenticación & Autorización 51 Dialecto Canal Dialecto Canónico Dialecto Proveedor

52 Proxy de Seguridad Gestión de requerimientos Gestión de Seguridad (7) Autenticación (Quíen) & Autorización (Qué) Proxy Seguridad Servicios Adaptador Procesos Servicios Portal IVR Consultar Saldo Portal Procesar Pedido Venta Consultar Saldo Crear Cliente CRM OLTP Directorio de servicios Agencias Repositorio de políticas Oracle WSM IBM DataPower OLAP Internet ATM HTTPS WS-Security 52 Dialecto Canal Dialecto Canónico Dialecto Proveedor

53 Gestión de requerimientos: En resumen La gestión de Motivadores de negocio y requerimientos no funcionales al interior de la arquitectura determinan la forma y la robustez de la misma, y la capacidad de ésta de responder a las necesidades reales del negocio. Al momento de considerar o plantear estrategias y mecanismos que permitan gestionar calidades sistémicas (MN& RNF) se debe partir de la premisa Tratar de ser no intrusivo La agregación de capas a la arquitectura potencia la flexibilidad, mantenibilidad y reusabilidad pero impacta el desempeño final; por esta razón debe hacer un trade-off entre lo que se gana vs. lo que compromete. 53 No todo debe ser resuelto a nivel de implementación en el primer proyecto. Sin embargo, es importante que en todo momento se considere las diferentes dimensiones de análisis de RNF y Motivadores de negocio (Esto le permitirá tener visión, es decir, ver lo invisible)

54 Agenda 1. Motivación 2. Contexto RNF 3. Gestión de RNF dentro de SOA 4. Conclusiones

55 Conclusiones El negocio es un objetivo en movimiento que sólo puede ser soportado sobre un modelo tecnológico altamente flexible y alineado a la estrategia de negocio más que a las prácticas y estándares de moda con los cuales nos inundan cada nuevo día. SOA no es una moda, es un estilo de arquitectura que re-surge de las cenizas de los 70 s como un medio y herramienta válida para responder a los cada día más agresivos requerimientos de negocio. 55

56 Trade-off: Características de una buena solución de diseño (1) Bajo Acoplamiento Desempeño / Eficiencia Alta Cohesión

57 Trade-off: Características de una buena solución de diseño (2) Bajo Acoplamiento Producto de un buen diseño Desempeño / Eficiencia Alta Cohesión

58 Trade-off: Características de una buena solución de diseño (3) Bajo Acoplamiento Producto de un buen diseño Desempeño / Eficiencia Alta Cohesión

59 Trade-off: Características de una buena solución de diseño (4) Cliente Web Aplicación X (No-arquitectura) RDBMS

60 Trade-off: Características de una buena solución de diseño (5) Cliente Web Tiempo Respuesta 6.5 segs 1.5 segs Aplicación X (No-arquitectura) RDBMS 5.0 segs

61 Trade-off: Características de una buena solución de diseño (6) Aplicación X (No-arquitectura) Cliente Web Tiempo 1.5 segs RDBMS Respuesta 6.5 segs Alto acomplamiento, baja cohesión 5.0 segs

62 Trade-off: Características de una buena solución de diseño (7) Presentación Negocio Cliente Web RDBMS

63 Trade-off: Características de una buena solución de diseño (8) Aplicación X Presentación Negocio Cliente Web RDBMS Bajo Acomplamiento Alta cohesión

64 Trade-off: Características de una buena solución de diseño (9) 1.5 segs Aplicación X 1.0 segs 1.0 segs Presentación Negocio 1.5 segs Cliente Web Tiempo Respuesta 7.2 segs 0.7 segs 1.5 segs RDBMS

65 Trade-off: Características de una buena solución de diseño (10) 1.5 segs Aplicación X 1.0 segs 1.0 segs Presentación Negocio 1.5 segs Cliente Web Tiempo Respuesta 7.2 segs 0.7 segs 1.5 segs Qué paso? Dónde está el problema? Qué le decimos al gerente? RDBMS

66 Trade-off: Características de una buena solución de diseño (11) Gané (+) Robustez Escalabilidad Mantenibilidad Perdí (-) Desempeño Tiempo de respuesta. Retornar