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

 El  concepto de Software Como un Servicio (Software as a Service o SaaS) es un modelo comercial que no pasará desapercibido ya que implica una nueva división del trabajo entre los que conocen el negocio y los que conocen la tecnología. Gianpaolo Carraro, del Equipo de Estrategia de Arquitectura de Microsoft Corp, viene estudiando las implicancias que esta nueva forma de distribuir software tendrá en la manera de planear arquitecturas. En base a eso nos recibió para conversar al respecto

(La versión original de esta entrevista, en idioma inglés, está disponible en http://msdn.microsoft.com/architecture/learnmore/default.aspx?pull=/library/en-us/dnbda/html/SaaSChat_MSDN.asp)

 

Gianpaolo, ante todo gracias por tomarte el tiempo para charlar con nosotros
GC: Cero drama! Un placer para mí
Te voy a pedir que te presentés, Gianpaolo. Contanos quién sos, qué hacés…
GC: Bien, mi nombre ya lo conoces. Yo manejo el grupo de arquitectura de soluciones en el Equipo de Estrategia de Arquitectura de Microsoft Corp, en Redmond. Proveemos dirección en la forma de razonar y guías alrededor de tópicos tales como “Arquitecturas Orientadas a Servicios”, “Software Factories” y “Software como un Servicio” (SaaS), por supuesto. Fred Chong en mi equipo es el arquitecto clave en las guías de arquitectura para SaaS. A lo mejor te acuerdes de él por su trabajo relacionado con Identidades en los últimos años
Grandioso. La primera pregunta que tengo es para aquellos arquitectos que todavía no se enteraron qué es SaaS. Así que… qué es “Software como un Servicio”?
GC: Simplemente pon, es “Software distribuido como un servicio que se hostea y accede vía Internet”, opuesto a lo que llamamos “on premise” donde el software es distribuido al sitio del cliente. Hay varios “sabores” de SaaS. Algunos apuntan al mercado consumidor y son la base de muchas compañías “Web 2.0” (correo electrónico, compartir fotos, etc, los Hotmail, Flickr). Otras apuntan al mercado empresarial de aplicaciones de línea de negocio (por ejemplo, salesforce.com). Yo tiendo a concentrarme más en estas últimas, más allá de que si bien tienen algunas diferencias, todos los sabores son muy similares en sus fundamentos
Es apenas un relanzamiento del modelo previo de Proveedor de Servidor de Aplicación (ASP) o los dos modelos comerciales difieren en algún modo? Me da la impresión de que nuestros lectores puedan pensar que es el mismo concepto con nombre nuevo
GC: vuestros lectores no estarían del todo equivocados. Tanto ASP como SaaS permiten a los clientes acceder al software sin tener que hostearlo ellos mismos. Aún así hay grandes diferencias: los ASPs te hosteaban la aplicación, pero normalmente tú pagabas el software a través de una licencia “regular” (tipicamente un costo alto en concepto de licencia inicial más un mantenimiento anual). Tú estabas pagando al ASP por el hosting: el hosting del software era el servicio ofrecido por el ASP y no el software en sí mismo. Además, los ASPs normalmente hosteaban una instancia del software por cliente y por eso no había beneficio por la economía de escala del multi-alquiler
Los vendedores independientes de software (independent software vendors o ISVs) que te describía antes, que ofrecen SaaS, ofrecen el software y su hosting como un solo paquete. Además, la mayoría de los ISVs de SaaS tienen arquitecturas que permiten alquilar la misma instancia de software muchas veces (multi-tenancy), por lo que pueden ofrecer su software a un costo más efectivo. Hay unos pocos “sobrevivientes” de la era ASP que se están reposicionando como hosters para SaaS; proveyendo un conjunto de servicios compartidos (mediciones, facturación, aprovisionamiento dinámico, etc) a los ISVs de SaaS de forma tal de no tener que construirlos ellos mismos
Ya te sigo. Comparado con el ASP tradicional, SaaS implica outsourcear más que la infraestructura
Entonces, imaginémonos que soy el arquitecto de software de una compañía tradicional, digamos un banco, una distribuidora, o una telco. Por qué me debería interiorizar de este modelo de distribución de software? Cómo considerás que SaaS impacta en las arquitecturas empresariales actuales para estos tipos de compañías?
GC: Hay dos tipos de “impacto”: el primero relacionado con proveer software como un servicio, el segundo relacionado con consumir software como un servicio. En lo que al consumo respecta, existen un montón de similitudes con el consumo de Servicios Web hosteados por un socio en un escenario B2B. Un aspecto típico es integrar esos servicios con los servicios locales de los sistemas “in house”. Otro cambio grande comparado con el software “on premise” son los aspectos de configuración/personalización. Con SaaS hay normalmente menos opciones de personalización y en muchos casos no existen posibilidades de agregar código propio. Con esto dije, las compañías de SaaS avanzadas ofrecen opciones de personalización a través de configuración detallada de su software a través del sitio web
Del lado del proveedor de SaaS, existen tres aspectos de arquitectura importantes que necesitan ser presentados: multi-alquiler, escalabilidad y personalización sin olvidarnos de los tradicionales (confiabilidad, rendimiento y todos los aspectos de seguridad)
Los ISVs no son los únicos preocupados en esto, aunque parezcan ser los únicos que ofrecen SaaS: existen algunas empresas, no de software, con las que hablé que quieren distribuir SaaS y ser en cierto modo casas de software. Imagínate una petrolera grande queriendo ofrecer software a sus miles de estaciones de servicio (que no es raro que no posea directamente), o una gran cadena de comidas rápidas ofreciendo cierto software promocional a sus variados canales de distribución (franquicias)
Te entendí: ofrece una oportunidad a esos canales de distribución de mejorar la eficiencia sin estar preocupandose en detalles técnicos. Bueno, ahora, dejame cambiarme de carril: imaginate que soy el arquitecto de software de un ISV o de cualquier otro tipo de casa de software. Si el modelo SaaS prevalece, qué debería considerar cuando pienso en hacer la arquitectura de aplicaciones para ofrecer como SaaS? Qué creés que voy a tener que cambiar?
GC: Para los ISVs el impacto en la arquitectura de su software puede ser absolutamente dramático. En realidad depende de cuánto se quieran beneficiar del modelo SaaS. Para explicar mejor esto, trajimos un modelo básico de madurez de SaaS descripto aquí: http://blogs.msdn.com/gianpaolo/archive/2006/03/06/544354.aspx
Déjame darte algunas claves. Tecnicamente hablando, tú puedes decidir no cambiar nada en tu arquitectura actual y ofrecer SaaS a través de algunas tecnologías de escritorio remoto (Citrix, etc); conozco un par de ISVs haciendo esto. Les permite sondear el mercado sin mucha reingeniería, aunque en seguida se golpean contra los límites de este modelo. Si un ISV realmente quiere cosechar los beneficios de SaaS desde la perspectiva de la estructura de costos existen tres áreas donde la arquitectura tiene que ser cambiada
Primero, la arquitectura tiene que permitir multi-alquiler (multi-tenancy, es decir, hostear a varios clientes en una única instancia de la aplicación, maximizando por ende el uso de recursos compartidos). La analogía viene dada por el “inquilino” de un edificio. Imagínate un edificio grande (un rascacielos) con una infraestructura común (ascensores comunes, limpieza de corredores comunes…) y apartamentos alquilados a varios inquilinos. Con este modelo tú puedes lograr mucha mayor economía de escala que vendiendole una casa a cada cliente. Esto nos lleva al segundo punto:
Personalización a través de la configuración. De vuelta con la analogía del edificio, no todos los apartamentos son iguales: un dormitorio, dos dormitorios, algunos tienen balcón, etc. Permitir personalización a cada “inquilino” es importante, pero como el software es compartido por los inquilinos, la personalización no puede ser hecha mediante código personalizado sino que necesita ser hecha mediante configuración específica de cada inquilino. Contar con un entorno rico de metadatos y de un servicio de metadatos en la arquitectura es importante
Por último, el tercer punto es la escalabilidad. Cuando vendes el software “on premise” necesitas escalarlo a la medida de la empresa a la que se lo vendes. Cuando tú hosteas el software y lo distribuyes como un servicio, necesitas escalarlo a la suma de todos los clientes que tienes. Normalmente se requieren prácticas de escalabilidad similares a las usadas por los sitios más grandes de Internet (Hotmail, Amazon, Ebay, etc)
Estos tres puntos de arquitectura (multi-tenancy, personalización y escalabilidad) son el núcleo de las guías de arquitectura que estamos creando; reconocemos que los otros aspectos mencionados antes son escenciales pero siguen siendo tratados igual que en cualquier sistema de alta disponibilidad
Definitivamente un gran desafío para estos arquitectos. Bueno, revisemos el cuadro entero: tenemos hoy en día conceptos como SOA, conectar aplicaciones aisladas, servicios de granularidad gruesa, etc. Cómo calza, desde el punto de vista de una compañía tradicional, el estilo arquitectónico orientado a servicios?
GC: Yo veo a SOA y a SaaS como estilos de arquitectura diferentes que se apoyan en un mismo conjunto de principios. En otras palabras, yo los veo como “primos”. Si tú eres un jugador de fútbol profesional, un basquetbolista o lo que sea, tú te apoyas en principios de estilo de vida saludable: comer bien, dormir al menos ocho horas, hacer ejercicio, etc. Pero a su vez tanto el futbolista como el basquetbolista se apoyan en entrenamiento específico. De la misma forma, SaaS y SOA comparten los principios de la orientación a servicios, enfrentan aspectos similares sobre identidad federada, se apoyan en tecnologías similares, etc, pero están optimizados para casos de uso levemente diferentes
La forma en que SOA está definido es normalmente alrededor de los patrones de Integración de Aplicaciones internas de la Empresa (EAI) o Negocio a Negocio (B2B). Single Sign On (SSO), Automatización de Procesos de Negocio (BPA), Agregación de Entidades, etc, son todos tópicos de arquitectura importantes para dominar SOA. Estos aspectos son también parte de la arquitectura SaaS, pero SaaS está optimizada para multi-alquiler, recursos compartidos, y aprovisionamiento automático. También otros servicios compartidos específicos tales como mediciones, facturación, etc, son frecuentemente más importantes en SaaS que en SOA, más allá de que SOA no puede pasarlos por alto
Parece como que a pesar de que ambos estilos de arquitectura enfrentan aspectos similares, lo hacen con distinta intensidad. Hace unos días le estaba contando de SaaS a un amigo (arquitecto). Estábamos charlando acerca de un proveedor concreto de SaaS que ofrece un CRM entero vía web. Mi amigo me preguntó qué pasa en el caso de que uno decida terminar el contrato con el proveedor. Me preguntó qué pasa con los datos cargados en la infraestructura del proveedor: quién posée esos datos?
Me imagino que vos seguramente no podés responder esa pregunta. Pero qué tan maduro pensás que está este modelo comercial en términos de propiedad de datos y disponibilidad a largo plazo más allá de la duración del contrato de servicio?
GC: Los datos son del que pague el mejor abogado (estoy bromeando, claro). Me parece que esto saca a la luz un punto muy importante. Sin ser abogado no puedo hablar de los términos de qué tipo de contrato hay que colocar para garantizar la propiedad de los datos, pero lo que he visto muchas veces es al proveedor de SaaS enviar archivos ZIP grandes (por ejemplo, en DVD) con los datos de manera que puedan ser guardados/backupeados en el sitio del cliente. Los datos que están hosteados fuera de las fronteras tienen también una implicancia en reportes, data warehousing, etc. Cuando están hosteados, el acceso a los datos está limitado a la API ofrecida por el ISV de SaaS, cuando los tenemos “in house” los datos pueden ser accedidos “out of band” si es necesario
En resumen, te diría que tú posées los datos incluso si están hosteados fuera de tu firewall, pero en ese caso, el hoster puede tener ciertos derechos de acceso a los mismos. Piensa en cómo los más importantes proveedores de correo electrónico usan los datos de tus correos (hosteados en su sitio) para proveerte avisos. Es un plus? Es un aspecto de privacidad? Te dejo a tí que lo juzgues
Acá en Cono Sur hay un montón de software factories sacadas de las áreas de TI originales de compañías multinacionales, como una forma de aplicar economía de escala…
GC: No tengo claro a qué llamas “software factories”. Asumo que son cierta especie de centros de excelencia que construyen software para todo el grupo
Exacto, Gianpaolo! El término “software factory” es común en América Latina y España cuando te referís a esa especie de outsourcing interno. Lo que yo conozco de esas compañías es que crean y mantienen software para sus subsidiarias en Latino América, pero todavía la infraestructura es propiedad de cada subsidiaria. Y el software es paquetizado y distribuido en la forma clásica. En la mayoría de los casos, el software tiende a ser un mismo core, un mismo núcleo, con ciertas personalizaciones locales
Me imagino que el modelo SaaS calzaría bien en estas compañías. Así que la pregunta es: Si estas software factories estuvieran interesadas en SaaS, existe algún tipo de guía que podamos distribuirles, de manera de que tengan éxito desde el princio?
GC: Esto es exactamente lo que te describía antes, cuando te contaba que algunas empresas grandes con las que hablé en Estados Unidos están apuntando a ofrecer el Software como un Servicio a sus subsidiarias, sucursales y franquicias. Como algunos de estos lugares podría no funcionar si el software distribuido como un servicio está bajo y podría resultar en grandes pérdidas (imagínate una solución de punto de ventas para un local de una distribuidora, como un servicio administrado por la cadena en su casa matriz). He estado discutiendo modelos híbridos, donde la solución puede trabajar temporalmente fuera de línea. A propósito, el modelo híbrido y el acceso fuera de línea al SaaS es otro gran tópico. Los activos que tenemos en Microsoft con Office en el front end, WinFX, el Intermediario de Servicios de SQL (SQL Service Broker) y Biztalk Server como “pegamento” con SQL al fondo, son una plataforma excelente para estos tipos de escenarios
Hasta sugiriendo la implementación, Gianpaolo! Ahora sí confirmo que sos de veras un arquitecto de soluciones!
Bueno, creo que estamos casi al final. Antes de irnos quiero preguntarte acerca de la sesión que diste en el SaaS Summit de Napa Valley el mes pasado. Sobre qué fue tu sesión?
GC: Sí, Fred y yo mantuvimos una sesión en el SaaS summit principalmente acerca de los aspectos arquitectónicos que te conté hace un rato: multi-alquiler, escalabilidad y personalización en un entorno compartido. Fue interesante ver qué tan poco conocimiento hay sobre estos aspectos, incluso para compañías que han provisto cierta suerte de distribución SaaS en sus soluciones. Con el momentum que tiene SaaS, y ojalá con cierta ayuda nuestra, esto cambiará pronto
En qué pensás que estas compañías estaban realmente preocupadas?
GC: Algunos asistentes eran amigos que venían por el lado de los negocios, así que hubo también algo de discusión acerca de monetización (“cómo hago plata con esto”). Discutimos los distintos modelos, el modelo de suscripción (pagos mensuales en oposición a la licencia a perpetuidad), así como también el modelo basado en avisos publicitarios. Otra pregunta de negocios fue el impacto en los honorarios de la fuerza de ventas. Cómo deberían estas compañías compensar a sus vendedores ahora que las ventas de billetes grandes son sustituídas por pagos mensuales más reducidos?
Del lado técnico, la principal preocupación estaba basada en la confianza: “puedo confiarle a un ISV chico que hostée mis datos, están seguros ahí, qué hacemos si el ISV desaparece (quiebra). La otra cara de la moneda también fue discutida: cómo ganar confianza como jugador chico en esta industria. El consenso general fue que el hoster podría ser una fuente ya confiable: por ejemplo, si un ISV chico va a ser hosteado por una telco grande, entonces el nivel de confianza sería mucho mayor
Excelente, Gianpaolo! Realmente te agradezco por tu tiempo y te deseo toda la suerte con tu trabajo por hacer en el espacio SaaS
GC: El placer fue mío, Diego, estuvo divertido! Si alguno de tus lectores quiere continuar la discusión, los blogs relevantes son: http://blogs.msdn.com/gianpaolo/ y http://blogs.msdn.com/fred%5Fchong/. Mi correo es gianpc@ tú conoces la compañía :-) (gianpc@microsoft.com)
About these ads
Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

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

  1. Alejandro dijo:

    Me gustó mucho tu entrevista con Gianpaolo, de una manera muy amena presenta los valores para clientes y proveedores de SaaS.
     
    Muy claros los elementos que distinguen a SaaS basado en estas tres características que menciona, Gianpaolo:
     

    Multi-tenancy
    Personalización
    Escalabilidad
     
    Un elemento que da para discutir bastante es el de la broma de poderse pagar el mejor abogado para garantizar la propiedad sobre los datos en caso de litigios. J

  2. Matias Woloski dijo:

    Diego, muy interesante la entrevista. Yo estoy haciendo mi Tesis de
    Ingenieria sobre SaaS y vengo leyendo a Gianpaolo y a Fred Chong
    hace  un tiempo. El tema es realmente muy interesante a nivel
    conceptual y a nivel tecnico, creo que WinFx nos va a permitir poder
    implementar una arquitectura SaaS con menos esfuerzo.

    Te recomiendo que te anotes en en este RSS http://feeds.feedburner.com/SaasWeek

    Nos mantenemos en contacto,
    Matias

  3. Cristofer dijo:

    muy informativo y ameno. As usual

  4. Borja dijo:

    Buena la entrevista Diego!!! como arquitecto no se… pero como periodista te ganarias el pan seguro!!!
    Comentar que para mi SaaS como concepto es nuevo, pero ya habia visto este modelo en la modalidad de proveedor y en la modalidad de consumidor de estos servicios.
    En la modalidad de proveedor en una ocasión el año pasado me estuvieron mostrando un software que una empresa de informatica perteneciente a un importante holding de empresas de la construcción en España estaba comercializando a las otras empresas del grupo. La funcionalidad de este software estaba relacionada con la gestión de proyectos de construcción y era un servicio el cual se daba tal y como lo describe Gianpaolo. Pero Ojo!! … el que sea un servicio el cual se accede via internet y que no necesite de una instalación , no significa necesariamente que no necesite una implantación. Me explico, todo depende del tipo de servicio que sea pero en este caso cambiaba bastante la forma de trabajar de la empresa y es por ello que se requeria de un trabajo previo de gestión del cambio y de adaptación del servicio a los usuarios y de los usuarios al servicio.
    En la modalidad consumidor un banco que seguro conoces bien tiene contratado sus portales de servicios para usuarios como pagos , remuneraciones , proveedores mediante este modelo, de esta manera el banco se evita los costos de desarrollar estos portales y paga por transacciones realizadas, por la otra parte el provedor del portal recupera su inversión y genera ganancia aplicando economia de escala, ya que el mismo servicio se lo ofrece a otras empresas personalizandolo para lo que cada empresa requiere a traves de cambios en la configuración.
     
    En cuanto a la polemica/ broma  de los datos de los clientes es un tema no menor ya que cada pais tiene su propia legislación acerca del tratamiento de estos, por ejemplo, creo que en Venezuela hay una restricción por la que en determinados ambitos los datos deben residir dentro del pais, lo cual podría ser una limitante para este modelo de negocio. En España hay una ley durisima (LORTAD) también por la que te enfrentas a gigantescas sanciones si la incumples.
     
    Otra de las cosas a considerar para garantizar los datos de nuestros clientes es el contar con un CPD que siga todas las normativas y un Centro de respaldo en caso de contingencia.
    Desviandonos un poco de SaaS, un caso feliz reciente de no tener los datos y las aplicaciones unicamente en nuestras oficinas fue la firma Deloitte, no se si recordarás hace poco mas de un año el incendio del edificio Windsord en Madrid, pues bien, esta firma tenía sus oficinas y alli, lo cual no evitó que pudieran seguir operando ya que transmitian periodicamente todos sus datos a los servidores de una empresa especialida en tratamiento y back up de esta información.Ver articulo
     

  5. jose dijo:

    Despues de leer la entrevista me ha quedado aun mas claro el concepto de SaaS y las diferencias existentes respecto los tradicionales ASPs.
     
    Enohrabuena por tu blog!. Te incluiré en mi blogroll.
     
    Jose Carlos del Arco.
     
    http://del.icio.us/swwsman
     

  6. Alex dijo:

    Muy buena tu entrevista pero me gustaria saber si se pudiera crear un paquete Saas para pymes en Perú y poder incluir Saas en nuestra capital tambien estoy formulando mi tesis.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s