Desarrollo de Aplicaciones en

Plataformas Software as
Service:¿Modelo,Plataforma o
Servicio?
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:

 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.

IDC también estima que las empresas gastarán US$14.8 billones en soluciones SaaS y
que dos de cada tres negocios considerarán comprar software con modelos de
subscripción. Estas cifras son verdaderamente importantes, ya que representan un amplio
mercado en la industria del software para los próximos años. Ejemplos de negocios que
usan este enfoque son Salesforce.com, Google Apps, Appian, OpSource, CogHead, entre
otros. Con esta tendencia, es importante también definir la forma en que este tipo de
software es desarrollado y entregado al cliente. Este artículo analizará este aspecto y sus
implicaciones en la metodología tradicional del desarrollo del software.

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.

El modelo de subscripción debe soportar diferentes tipos de cobro, como son pago por
transacción o periodo de tiempo. Los clientes de SaaS, a diferencia de los modelos ASP
(Application Service Provider), son entidades de negocio y no usuarios finales. La
plataforma SaaS provee soporte para diferentes aplicaciones, tanto las que son
entregadas para los clientes como para aplicaciones propias de los proveedores.
Comúnmente se usa el termino tenant para referirse tanto a los clientes como
proveedores que usan la plataforma para consumir o proveer las aplicaciones SaaS.

 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:

1. Multi-tenant. La arquitectura soporta múltiples clientes y proveedores.

2. Versión simple. Existe una versión de cada aplicación y es compartida para
todos los clientes.
3. Separación lógica de datos. Cada tenant tiene su propio dominio de
información, pero almacenados en una misma base de datos.
4. Contenedor de dominio. Es un punto de entrada a las aplicaciones de un
proveedor.
5. Integración de aplicaciones. Las aplicaciones SaaS deben comunicarse entre
sí, pero mantenerse independientes.
 6. 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:
 1. Accedidas por Internet.
2. Desarrolladas y desplegadas sobre una plataforma específica.
3. Soportadas por componentes compartidos de la plataforma.
4. En sentido estricto, solo deben contener lógica de negocio e interfaz de usuario.

Impacto sobre el desarrollo de software

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 anteriormente debe 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.

Implementació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.

 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.

Conclusión
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. ]