Published 15 years ago
(updated 12 years ago)
Recientemente me encontraba impartiendo una clase de Arquitecturas de Software. En un experimento rápido pregunté si alguien conocía el término Software-as-a-Service (SaaS). La respuesta fue una rotunda negativa de todos. Luego pregunté si alguien había usado alguna vez Google Docs y la gran mayoría respondió afirmativamente. Les comuniqué mi conclusión: aunque no conocían el término, ya habían usado SaaS.
Ahora bien, antes de definir ciertos conceptos en cuanto a este tema,creo que es importante mencionar algunas tendencias de negocioen este mercado; Gartner predice que:
Conceptos SaaS
Para comenzar, podemos decir que SaaS no es una tecnología ni una metodología. Tampoco es un modelo de negocio específico. SaaS es un enfoque que consiste en varios componentes:
Figura 1. Arquitectura SaaS
La figura 1 muestra la arquitectura de alto nivel de una plataforma SaaS. En el nivel más alto se encuentran las aplicaciones proporcionadas por los proveedores. La plataforma expone componentes de
soporte para estas aplicaciones. Otros servicios son de meta-datos y administración de tenants. Infraestructura de software y hardware también es proporcionada por la plataforma. Sobre esta arquitectura, las aplicaciones SaaS son desarrolladas, desplegadas y entregadas a un número considerable de clientes.
Actualmente los proveedores de SaaS no han establecido las mejores prácticas para desarrollar este tipo de aplicaciones ni tampoco estándares en la industria. Las metodologías tradicionales son suficientes
para desarrollar modelos SaaS muy simples, pero cuando se trata de especializar y escalar hacia un negocio más avanzado, aún se carece de técnicas bien establecidas. Por el lado de ingeniería de
software, las aplicaciones SaaS presentan diferencias en cuanto a su ingeniería de requerimientos con las aplicaciones empaquetadas (por ejemplo, desde la perspectiva del cliente, la instalación y mantenimiento
son diferentes). Pioneros del modelo SaaS argumentan que se requiere un enfoque alterado de ingeniería de software para este tipo de aplicaciones.
Una pregunta importante es cómo el enfoque SaaS afecta a los proveedores de software y su incentivo a invertir en el desarrollo de productos. Transformar un producto empaquetado a un modelo SaaS no es una simple cuestión de reescribir código. Estas compañías necesitan examinar sus modelos de ingeniería y mercadeo para adaptarse a este nuevo enfoque de negocio y de desarrollo.
Figura 2. Ciclo de vida en aplicaciones SaaS
La figura anterior describe que las actividades son diferentes a un producto tradicional. Una de las causas principales de estas diferencias, es que las aplicaciones SaaS están acopladas a una plataforma y en
cada etapa esta plataforma juega un rol importante en el ciclo de vida SaaS. La siguiente tabla analiza el impacto en cada etapa del desarrollo cuando el software es entregado como producto y como servicio.
Desarrollo de aplicaciones SaaS
El impacto en el proceso de desarrollo de software presentado anteriormentedebe ser tomado en cuenta cuando una aplicación es desarrollada como servicio. Las metodologías tradicionales son ahora analizadas y redefinidas para cumplir los nuevos requerimientos impuestos por este nuevo enfoque. Podemos redefinir las actividades de cada etapa en esta propuesta:
El desarrollo de aplicaciones sobre plataformas SaaS requiere de consideraciones
en los diferentes escenarios del ciclo de vida del software.
Requerimientos
En el enfoque tradicional, los requerimientos consisten en definir una serie de funciones que satisfagan las necesidades de un cliente. En el caso de las aplicaciones SaaS, los desarrollos son meramente basados en un modelo de negocio. Eso es, una aplicación SaaS debe cumplir con los requerimientos de un mercado meta. Debido a que las aplicaciones serán consumidas por un gran número de subscriptores (empresas clientes) y cada uno puede tener potencialmente un número grande de usuarios, entonces más requerimientos no funcionales son introducidos al proceso, como por ejemplo: soporte para alta concurrencia, almacenamiento escalable, virtualización/ clustering entre otros. Las actividades propuestas son:
Análisis
La etapa de análisis debe ser realizada también desde la perspectiva de negocio. Esto es debido a que cada aplicación tratará de satisfacer las necesidades de un amplio número de clientes. La definición de los procesos de negocio que soportará cada aplicación es un paso importante en este tipo de aplicaciones, ya que debe permitir la personalización y definición de procesos similares para cada cliente.
Diseño
La fase de diseño consiste en desarrollar documentación que soporte la etapa de construcción.
Además de las tareas comunes involucradas en la implementación, dentro del desarrollo SaaS es necesario considerar a la plataforma que soporta las aplicaciones.
Pruebas
La principal diferencia entre las metodologías tradicionales y la propuesta para SaaS radica en que las pruebas de integración necesitan validar la integración correcta entre las aplicaciones y la plataforma.
Otra diferencia importante es en cuanto a las pruebas de rendimiento y métricas de uso.
Nuevas plataformas conocidas como Software-as-a-Service (SaaS) serán un importante canal de distribución para el software empresarial en un futuro cercano. El proceso de desarrollo sobre estas plataformas debe considerar diversos factores que no presentan los métodos actuales de desarrollo de software. Las diferencias entre desarrollar software como servicio o como producto empaquetado son evidentes y estas diferencias cambian la manera en que las aplicaciones SaaS son desarrolladas. Dadas estas diferencias, este trabajo analiza las consideraciones necesarias para cada etapa de desarrollo en este nuevo tipo de aplicaciones y también presenta una guía para desarrollar aplicaciones en ambientes de negocio Software-as-a-Service.
Referencias
[ Turner, M.; Budgen, D.; Brereton, P. “Turning software into aservice”. Computer. Volume 36, Issue 10, Octubre 2003. ]
[ Predicts 2007: Software as a Service Provides a Viable DeliveryModel. Gartner Inc. 2006. ]
[ Wolde, Erin Ten. Research Analyst, IDC. Agosto 2007. ]
[ Natis, Yefim V. Introducing SaaS-Enabled Application Platforms: Features, Roles and Futures. Gartner Inc. 2007. ]
[ Choudhary, V. “Software as a Service: Implications for Investment in Software Development”. Annual Hawaii International Conference on System Sciences, 2007. ]
[ Olsen, E.R. “Transitioning to Software as a Service: Realigning Software Engineering Practices with the New Business Model”. Service Operations and Logistics, and Informatics, 2006. ]
[ Carraro, Gianpaolo; Chong, Fred y Page, Eugenio Pace. “Efficient Software Delivery Through Service-Delivery Platforms”. The Architecture Journal. Microsoft MSDN Architecture Center ]
[ Chou, Timothy. The End of Software. Sams Publishing, 2005. ]
Ahora bien, antes de definir ciertos conceptos en cuanto a este tema,creo que es importante mencionar algunas tendencias de negocioen este mercado; Gartner predice que:
- Para el 2010, 20% de las compañías de comercio electrónico usarán el modelo SaaS y 15% de las grandes compañías reemplazaránsus soluciones de ERP con soluciones basadas en SaaS.
- Para el 2011, 25% de los nuevos negocios de software usarán el modelo SaaS.
- Para el 2012, las suites de BPM (Business Process Management) serán embebidas en soluciones SaaS y más del 66% de los ISVs (Independent Software Vendors) ofrecerán sus servicios como SaaS.
Conceptos SaaS
Para comenzar, podemos decir que SaaS no es una tecnología ni una metodología. Tampoco es un modelo de negocio específico. SaaS es un enfoque que consiste en varios componentes:
- Un modelo de negocio basado en subscripción.
- Una plataforma SaaS que permite desarrollar y desplegar aplicaciones sobre demanda.
- Proveedores que desarrollan y/o comercializan esas aplicaciones.
- Un modelo de entrega a través de Internet hacia múltiples clientes.
- Plataforma SaaS. Una plataforma debe proveer infraestructura (tanto de hardware como de software) que soporte el desarrollo y entrega de aplicaciones sobre Internet como servicios. Arquitecturas comunes tienen los siguientes atributos de diseño:
- Multi-tenant. La arquitectura soporta múltiples clientes y proveedores.
- Versión simple. Existe una versión de cada aplicación y es compartida para todos los clientes.
- Separación lógica de datos. Cada tenant tiene su propio dominio de información, pero almacenados en una misma base de datos.
- Contenedor de dominio. Es un punto de entrada a las aplicaciones de un proveedor.
- Integración de aplicaciones. Las aplicaciones SaaS deben comunicarse entre sí, pero mantenerse independientes.
- Componentes de soporte. La plataforma proporciona componentes compartidos para las aplicaciones: seguridad y autenticación, manejo de cuentas de usuario, logging, control de uso y métricas, soporte para diferentes modelos de subscripción, entre otros componentes importantes.
Figura 1. Arquitectura SaaS
La figura 1 muestra la arquitectura de alto nivel de una plataforma SaaS. En el nivel más alto se encuentran las aplicaciones proporcionadas por los proveedores. La plataforma expone componentes de
soporte para estas aplicaciones. Otros servicios son de meta-datos y administración de tenants. Infraestructura de software y hardware también es proporcionada por la plataforma. Sobre esta arquitectura, las aplicaciones SaaS son desarrolladas, desplegadas y entregadas a un número considerable de clientes.
- Aplicación SaaS. Básicamente, una aplicación es una serie de módulos y funciones que puede ser desplegada bajo demanda dentro de una plataforma. Una aplicación SaaS es desarrollada acorde a la plataforma que la soporta. Las características de estas aplicaciones pueden definirse como sigue:
Impacto sobre el desarrollo de software
- Accedidas por Internet.
- Desarrolladas y desplegadas sobre una plataforma específica.
- Soportadas por componentes compartidos de la plataforma.
- En sentido estricto, solo deben contener lógica de negocio e interfaz de usuario.
Actualmente los proveedores de SaaS no han establecido las mejores prácticas para desarrollar este tipo de aplicaciones ni tampoco estándares en la industria. Las metodologías tradicionales son suficientes
para desarrollar modelos SaaS muy simples, pero cuando se trata de especializar y escalar hacia un negocio más avanzado, aún se carece de técnicas bien establecidas. Por el lado de ingeniería de
software, las aplicaciones SaaS presentan diferencias en cuanto a su ingeniería de requerimientos con las aplicaciones empaquetadas (por ejemplo, desde la perspectiva del cliente, la instalación y mantenimiento
son diferentes). Pioneros del modelo SaaS argumentan que se requiere un enfoque alterado de ingeniería de software para este tipo de aplicaciones.
Una pregunta importante es cómo el enfoque SaaS afecta a los proveedores de software y su incentivo a invertir en el desarrollo de productos. Transformar un producto empaquetado a un modelo SaaS no es una simple cuestión de reescribir código. Estas compañías necesitan examinar sus modelos de ingeniería y mercadeo para adaptarse a este nuevo enfoque de negocio y de desarrollo.
Figura 2. Ciclo de vida en aplicaciones SaaS
cada etapa esta plataforma juega un rol importante en el ciclo de vida SaaS. La siguiente tabla analiza el impacto en cada etapa del desarrollo cuando el software es entregado como producto y como servicio.
Desarrollo de aplicaciones SaaS
El impacto en el proceso de desarrollo de software presentado anteriormentedebe ser tomado en cuenta cuando una aplicación es desarrollada como servicio. Las metodologías tradicionales son ahora analizadas y redefinidas para cumplir los nuevos requerimientos impuestos por este nuevo enfoque. Podemos redefinir las actividades de cada etapa en esta propuesta:
Figura 3. Redefinición de las actividades en el ciclo de vida SaaS.
El desarrollo de aplicaciones sobre plataformas SaaS requiere de consideraciones
en los diferentes escenarios del ciclo de vida del software.
Requerimientos
En el enfoque tradicional, los requerimientos consisten en definir una serie de funciones que satisfagan las necesidades de un cliente. En el caso de las aplicaciones SaaS, los desarrollos son meramente basados en un modelo de negocio. Eso es, una aplicación SaaS debe cumplir con los requerimientos de un mercado meta. Debido a que las aplicaciones serán consumidas por un gran número de subscriptores (empresas clientes) y cada uno puede tener potencialmente un número grande de usuarios, entonces más requerimientos no funcionales son introducidos al proceso, como por ejemplo: soporte para alta concurrencia, almacenamiento escalable, virtualización/ clustering entre otros. Las actividades propuestas son:
- Definición de un plan de requerimientos de negocio. Deben ser identificadas las características del plan de negocio (del proveedor) para ser transformadas a requerimientos funcionales.
- Análisis del mercado meta. Catalogar y puntualizar las necesidades principales del mercado meta. Se deben evaluar las necesidades del mercado y definir características de alto valor para los clientes potenciales. En esta actividad se van identificando los requerimientos no-funcionales que se mencionaron anteriormente.
- Definición de las funcionalidades. Puntualizar las características principales como funciones de cada aplicación que será entregada como servicio. Estas funcionalidades deben ser completamente alineadas al mercado y no a los requerimientos de un solo proveedor.
Análisis
La etapa de análisis debe ser realizada también desde la perspectiva de negocio. Esto es debido a que cada aplicación tratará de satisfacer las necesidades de un amplio número de clientes. La definición de los procesos de negocio que soportará cada aplicación es un paso importante en este tipo de aplicaciones, ya que debe permitir la personalización y definición de procesos similares para cada cliente.
- Análisis de procesos de negocio. En esta actividad se deben analizar los procesos de negocio que serán automatizados con la aplicación. Por ejemplo, si se desarrolla un CRM, se deben analizar los procesos de venta y su integración con otros procesos como cadenas de suministro, por ejemplo. Cada proceso con sus actividades, roles y reglas de ejecución debiera ser documentado.
- Desarrollar casos de uso. Tarea formal en metodologías existentes, que debiera hacerse para documentar y modelar las funcionalidades de la aplicación. Artefactos tradicionales son casos de uso descriptivos y sus diagramas.
Diseño
La fase de diseño consiste en desarrollar documentación que soporte la etapa de construcción.
- Investigación de tecnologías. Es importante en esta etapa hacer investigación sobre las tecnologías que soporten las necesidades identificadas. Un artefacto entregable puede ser un documento de investigación acerca de plataformas SaaS, proveedores existentes, frameworks, componentes Web 2.0, etc.
- Evaluación de tecnologías. Es importante definir cuál es la plataforma y las tecnologías que serán usadas en el proceso de desarrollo. Las pruebas de concepto en esta etapa son necesarias, para realmente determinar si la plataforma y tecnologías cumplen con los requerimientos tanto de negocio como técnicos.
- Arquitectura de servicios. En este caso, las decisiones arquitecturales están basadas en las premisas SaaS y la plataforma que las soporta. Debido a que las plataformas SaaS están diseñadas para ofrecer una infraestructura de servicios, los componentes de la aplicación deberían ser diseñadas bajo este enfoque.
- Ingeniería de procesos de negocio. Incluso cuando la aplicación debe proveer una definición predeterminada del proceso de negocio que ejecutará, su valor incrementa cuando es posible redefinir cada proceso de acuerdo al cliente.
- Documentación tradicional. Esta actividad involucra diversas tareas comunes como diagramas UML. Se trata de la documentación formal de la aplicación y depende de las especificaciones de la misma.
- Diseñar casos de prueba. Esta tarea resulta obviamente importante para cualquier desarrollo serio. Se deben incluir mecanismos de pruebas unitarias, de integración, de rendimiento, etc.
- Prototipos. Los recursos y la agilidad de generar y desplegar aplicaciones en plataformas SaaS puede ser explotado a través de la construcción de prototipos.
Además de las tareas comunes involucradas en la implementación, dentro del desarrollo SaaS es necesario considerar a la plataforma que soporta las aplicaciones.
- Desarrollo de servicios de negocio. Se trata de codificar las interfaces principales de la aplicación, así como sus implementaciones.
- Integración con los servicios de la plataforma. Desarrollar el código para consumir los servicios que la aplicación necesita para operar. Estos servicios consumidos pueden ser de seguridad, logging, métricas, etc.
- Desarrollar la lógica de negocio. Implementación de las reglas de negocio para los módulos de la aplicación.
- Desarrollar el front-end. Diseño y desarrollo de interfaces de usuario.
- Desarrollo de integración. Si es necesario, desarrollar código para integrarse con otros sistemas.
- Implementación de tecnología. Asegurarse que toda la implementación trabaja correctamente. Esta actividad cubre revisión de código, mejores prácticas, revisión de complejidad ciclomática, pruebas funcionales, entre otros.
Pruebas
La principal diferencia entre las metodologías tradicionales y la propuesta para SaaS radica en que las pruebas de integración necesitan validar la integración correcta entre las aplicaciones y la plataforma.
Otra diferencia importante es en cuanto a las pruebas de rendimiento y métricas de uso.
- Pruebas unitarias. Estas pruebas son desarrolladas y ejecutadas por cada desarrollador.
- Pruebas de integración. Pruebas importantes en cuanto a la integración con la plataforma, con otros módulos de la aplicación y con otras aplicaciones.
- Pruebas de rendimiento. Cada aplicación tiene sus propios requerimientos de rendimiento, en este caso, las aplicaciones SaaS tienen una fuerte dependencia en el número de usuarios y sus especificaciones.
- Pruebas de medición de tenants. La aplicación no debiera implementar código para logging o medición de uso. Estos componentes son responsabilidad de la plataforma misma. El objetivo de estas pruebas es asegurar que el uso y debug de cada aplicación es correctamente registrado y para cada tenant (cliente y/o proveedor).
- Aprobación Técnica. Consiste en correr todas las pruebas sistemáticamente y asegurarse que la aplicación es correctamente desplegada a producción. En el caso de actualizaciones y bugfixes, la plataforma debe proporcionar mecanismos de rollback cuando existan fallas y se pueda regresar a versiones anteriores.
Nuevas plataformas conocidas como Software-as-a-Service (SaaS) serán un importante canal de distribución para el software empresarial en un futuro cercano. El proceso de desarrollo sobre estas plataformas debe considerar diversos factores que no presentan los métodos actuales de desarrollo de software. Las diferencias entre desarrollar software como servicio o como producto empaquetado son evidentes y estas diferencias cambian la manera en que las aplicaciones SaaS son desarrolladas. Dadas estas diferencias, este trabajo analiza las consideraciones necesarias para cada etapa de desarrollo en este nuevo tipo de aplicaciones y también presenta una guía para desarrollar aplicaciones en ambientes de negocio Software-as-a-Service.
Referencias
[ Turner, M.; Budgen, D.; Brereton, P. “Turning software into aservice”. Computer. Volume 36, Issue 10, Octubre 2003. ]
[ Predicts 2007: Software as a Service Provides a Viable DeliveryModel. Gartner Inc. 2006. ]
[ Wolde, Erin Ten. Research Analyst, IDC. Agosto 2007. ]
[ Natis, Yefim V. Introducing SaaS-Enabled Application Platforms: Features, Roles and Futures. Gartner Inc. 2007. ]
[ Choudhary, V. “Software as a Service: Implications for Investment in Software Development”. Annual Hawaii International Conference on System Sciences, 2007. ]
[ Olsen, E.R. “Transitioning to Software as a Service: Realigning Software Engineering Practices with the New Business Model”. Service Operations and Logistics, and Informatics, 2006. ]
[ Carraro, Gianpaolo; Chong, Fred y Page, Eugenio Pace. “Efficient Software Delivery Through Service-Delivery Platforms”. The Architecture Journal. Microsoft MSDN Architecture Center ]
[ Chou, Timothy. The End of Software. Sams Publishing, 2005. ]
- Log in to post comments