Software as a Service

En estos días estoy trabajando sobre este tema: Software as a Service, una nueva “buzzword” que se ha estado difundiendo en el último tiempo.


Podemos ver una definición de SaaS en el glosario del Skycrapr


http://www.skyscrapr.net/archipedia/default.aspx/Archipedia/SoftwareAsAServiceGlossaryEntry.html


“The key characteristics of SaaS software, according to analyst IDC include:


1. Network-based access to, and management of, commercially available (e.g., not custom) software


2. Activities that are managed from central locations rather than at each customer’s site, enabling customers to access applications remotely via the Web


3. Application delivery that typically is closer to a one-to-many model (single instance, multi-tenant architecture) than to a one-to-one model, including architecture, pricing, partnering, and management characteristics “


Podemos consultar la Wikipedia


Software as a Service – Wikipedia, the free encyclopedia


donde encontramos:


“Software as a Service (SaaS) is a model of software delivery where the software company provides maintenance, daily technical operation, and support for the software provided to their client. SaaS is a model of software delivery rather than a market segment; software can be delivered using this method to any market segment including home consumers, small business, medium and large business.”


Traduciendo: SaaS son aplicaciones comerciales, que son accesibles por la red, y se brinda su uso a cllientes, que no necesitan instalar ese software. El proveedor de SaaS le vende o alquila su uso, preinstalado en algún servidor de la red. Pero no es sólo software “preenlatado” en la red, sino que se permite la adaptación al cliente. El término multitenant destaca que una misma aplicación puede servir a varios clientes.


Pero lo distintivo es la idea de tener la aplicación disponible por red. Eso es lo que cambia fundamentalmente con respecto al software comercial, ERP, CRM, o lo que quieran. Ejemplo emblemático de este tipo de servicio es SalesForce que brinda lo que denomina “on-demand Customer Relationship Management”. Esta empresa la descubrí en la época de la burbuja de Internet: me pareció interesante su modelo, y mucho de las cosas que he estado desarrollando desde entonces, apunta de alguna forma a reproducir ese modelo para llegar a un Enterprise Resource Planning, brindado como servicio.


Los que tienen alguna memoria, recordaran que esto es similar al concepto de ASP: Application Service Provider, como lo que encontramos en


http://www.aspstreet.com/
http://www.aspnews.com
http://en.wikipedia.org/wiki/Application_service_provider


Visiten esos sitios, y los encontrarán renovados, discutiendo a todo vapor sobre el concepto de Software as a Service.


Aquí en mi pais Argentina, encontramos a Mirol, desde hace años, propugnando por este concepto:


http://www.mirol.com/modalidad-asp.asp


“Imagínese ahorrar recursos tanto en hardware, software, así como en personal de soporte y administración…


Imagínese no tener que preocuparse de actualizaciones y nuevas versiones de software, hardware obsoleto, creación de nuevos usuarios…”


Varias empresas de tecnología informática, se han subido al tren, como IBM y Microsoft. Desde el punto de vista de esta empresa, es interesante leer algunos artículos, como


Architecture Strategies for Catching the Long Tail


un clásico de Fred Chong y Gianpaolo Carraro. Ahí plantean que, económicamente, el modelo SaaS apunta al gran volumen que se consigue a llegar a los clientes de la “larga cola”/”long tail” de:



Tambíén destacan que la repartición de costos pasa de:



a esta distribución


Pero más llama la atención, que en el gigante de Redmond, el propio Ray Ozzie, heredero de la posición de Gates, se dedique al tema, como en


http://www.internetnews.com/ent-news/article.php/3623171


Es imperdible para seguir el tema seguir los blogs de Chong y Carraro:


http://blogs.msdn.com/gianpaolo/
http://blogs.msdn.com/fred%5Fchong/


así como el blog del Gran Woloski (que ha decidido escribir su tesis sobre SaaS):


http://staff.southworks.net/blogs/matiaswoloski


El bueno de Matías escribió


SaaS: naming, paradigm shift, value
SaaS: Workflow in multitenant environment
SaaS: Realization of Metadata Services


Es interesante el artículo sobre workflow de Woloski, porque plantea temas en los que estoy pensando desde casi el siglo pasado, sobre cuáles son las partes “variables” de una aplicación. Más sobre lo que quiero hacer, más abajo.


Una entrevista al bueno de Gianpolo Carraro por Diego Dagum en


“Software as a Service”: Charla A Fondo Con Gianpaolo Carraro


Puntos de vista de Gianpaolo en:


SaaS Guidance: not only for ISVs
SaaS value proposition for the buyer
SaaS Simple Maturity Model
Multi-Tenancy, metadata driven everything and you are my #1 customer


Es una persona inteligente, lee los mismos libros que yo… :-)… lean


Blue Ocean Strategy and Architecture


Es interesante comenzar a pensar cómo debería ser una aplicación SaaS desde el punto de vista técnico. Me imagino que debería soportar múltiples empresas, permitir de alguna manera la formación de una comunidad. Esto puede ser una ventaja competitiva de un proveedor SaaS: imaginen aplicaciones que se beneficien de la sinergia de trabajar con otras empresas que usan la misma aplicación, como un sitio de compras coorporativas. Un proveedor querrá usar la aplicación que tiene mayor cantidad de empresas compradoras que la usan, si esta aplicación permite que una empresa se comunique con otras empresas usuarias.


Pero volvamos al lado técnico. Tengo en mi mente, algunas ideas. Desde hace años, trabajo en generación de código, y en la interpretación de metadata. Ya en este blog publiqué algún código para generar páginas web dinámicamente Formularios ASP.NET generados en ejecucion, en base a metadata que describa un formulario. De alguna manera, estaba pensando en una aplicación ASP (ver por ejemplo, el germen de esto en http://www.ajlopez.com/ajcontab ). desde hace algunos años. Me parece que ése es el camino a explorar, en el tema de desarrollo de aplicaciones comerciales.


Un tema a estudiar, es la organización de los datos, en semejante tipo de aplicación es el excelente artículo de Carraro, Chong y Wolter:


Multi-Tenant Data Architecture


Cómo podría construir una prueba de concepto de SaaS? Creo que puedo comenzar a escribir algunos requisitos y casos de negocio y visión, de una aplicación SaaS. Como prueba de concepto, encararía una aplicación que permite a las empresas y usuarios, definir sus propias entidades de datos (quienes conocen mi generador de código AjGenesis saben a qué apunto), y a definir, luego, de alguna forma, un flujo de trabajo con esos datos. Hasta puedo imaginar un nombre AjAga (Aj Another Generic Application … :-). Gran tema a decidir es si esto se implementa por generación de código o por interpretación de metadata en ejecución. Mi idea, es llegar a una aplicación que, según Carraro, sea


Level 1: (Configurable)


At level 1, the software can be tailored  for each tenant via configurations (no custom code), all the tenants use the same code. However at level 1, the architecture is still not multi-tenant, each customer runs its own copy (albeit the same). The separation can be either virtual (virtual machines on a same server) or physical (running on separate machines). Although much better than previous level, the architecture allows customization through configuration (code base is the same), the computing power is not shared among the instances and therefore the provider cannot achieve economy of scale, putting it at a competitive disadvantage vs. a multi-tenant solution.


 


y luego llegar a


Level 2: (Configurable, Multi tenant)


At this level. the application architecture includes the multi tenancy concepts. Akin to level 1, the UI can be customizable per tenant, so can the business rules and the data model. The customization per tenant is fully performed through configuration and is performed through a self-service tool, getting around the need of provider intervention. It is almost the SaaS “perfect case”; the only big piece missing at Level 2 is the capacity to scale out; the data partitioning is such at this level that growth can only be achieved by scaling up.


(disculpen que no traduzca) (extraído del artículo mencionado SaaS Simple Maturity Model)


He dejado algunos enlaces adicionales sobre SaaS en


http://del.icio.us/ajlopez/saas
http://www.ajlopez.net/Busqueda.php?Filtro=saas


Más delicious en


http://del.icio.us/tag/multi-tenant
http://del.icio.us/tag/saas


Nos leemos!


Angel “Java” Lopez
http://www.ajlopez.com/

This entry was posted in 2889. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>