LuisCarrasco 1/22

Michael Heiss http://www.flickr.com/people/michaelheiss/

Puntos clave en la seleccin de aplicaciones de
negocio en modelo SaaS / en la nube

Presentacin descargable en: http://www.nodotic.com/?p=1033

LuisCarrasco 2/22



Contenidos:













New York rises de Eugene de Salignacs
Introduccin
Puntos clave
Multi-tenancy
Tecnologa
Inicio del Servicio
Evolucin del Servicio
Fin del Servicio
Integracin
Privacidad
Gobierno del Servicio
Gestin de Costes
Conclusin
Referencias
Sobre el autor

LuisCarrasco 3/22

INTRODUCCIN
Mover las aplicaciones de negocio (ERP, CRM, etc.) a la nube (en modo SaaS) es una
tendencia en ascenso entre los responsables de las tecnologas de la informacin en las
empresas a tenor de los mltiples informes y encuestas de los analistas del sector de las TIC
[1], [2], [3].
No tengo cifras locales concretas, slo mi experiencia directa hablando con colegas, clientes y
proveedores, pero esta tendencia parece ms tmida en nuestro entorno que en otros y es que
por alguna razn aqu siempre somos ms precavidos en lo de introducir cambios, por decirlo
amablemente, o quiz no haya an una oferta suficiente [13].
Ciertamente es comprensible que los responsables de llevar a cabo e impulsar este tipo de
innovaciones en las empresas tengan muchas y serias dudas, dado el riesgo (no
necesariamente mayor que continuar igual, todo sea dicho) que puede suponer un cambio
estratgico de ese calibre en la gestin de la informacin de sus empresas, pero como estoy
plenamente convencido de que es cuestin de poco tiempo que el modelo dominante de tener
tu ERP, CRM etc. in house se quede obsoleto (*) y con el nimo de contribuir, en la medida de
mis modestas posibilidades, a romper, mediante informacin, transparencia y debate, esos
miedos y dudas, me he decidido a escribir este artculo sobre qu es lo que hay que saber
antes de decidir mover las aplicaciones de negocio a un modelo SaaS.
El artculo lo he estructurado alrededor de los siguientes puntos clave:
o Multi-tenancy. Como condicin necesaria para que el modelo sea sostenible.
o Tecnologa. Consideraciones respecto de la arquitectura tecnolgica de la
aplicacin SaaS.
o Inicio del Servicio. Qu hemos de tener en cuenta en relacin a como se pone en
marcha el servicio.
o Evolucin del Servicio. Qu debemos gestionar para asegurar la adaptacin de
la aplicacin SaaS a los requerimientos cambiantes de nuestra organizacin.
o Fin del servicio. Elementos importantes en el momento de finalizar la relacin con
el proveedor de la aplicacin SaaS
o Integracin. Consideraciones a la relacin de la aplicacin SaaS con otras
aplicaciones
o Privacidad. Cmo cumplir la legislacin vigente y proteger nuestros datos
sensibles.
o Gobierno del servicio. Gobierno de la relacin con el proveedor y gestin de la
calidad del servicio.
o Gestin de costes. Indexacin de los costes al uso de la aplicacin.

LuisCarrasco 4/22
Cada uno de estos puntos se desarrollarn desde el punto de vista de una empresa que est
considerando una estrategia SaaS para sus aplicaciones de negocio y que quiere validar las
capacidades de potenciales proveedores. No obstante, me gustara que este artculo fuera til,
no slo para aquellos responsables de sistemas de informacin de esa hipottica empresa sino
tambin tambin para que proveedores de aplicaciones y servicios comprueben que su oferta
es competitiva y se ajusta a un modelo SaaS de verdad o True SaaS.
[*] Sobre modelos obsoletos siempre me gusta citar a Nicholas Carr, uno de los primeros
visionarios de lo que ahora se ha venido a llamar Cloud Computing,que explica en varios de
sus libros y artculos como principios del siglo XX las empresas industriales tenan sus propios
generadores elctricos y pozos de agua in house y que al extenderse las redes de distribucin
de electricidad y agua se cambiaron a la Energa y Agua as a Service. Modelo que ahora, salvo
contadsimas excepciones, vemos como el nico racional y sostenible.

LuisCarrasco 5/22

MULTI-TENANCY

Empiezo con el punto que considero crucial a la
hora de decantarnos por un determinado
proveedor de aplicaciones de negocio SaaS ya
que de alguna manera abarca, o es consecuencia,
del resto de puntos clave que se comentan en el
resto del artculo: el multi-tenancy.
En una primera aproximacin se podra definir que
una aplicacin de gestin SaaS es Multi-tenancy
si:
Puede ser compartida por diferentes clientes.
Es capaz de adaptarse y evolucionar con los
diferentes requerimientos de cada cliente.
Y al mismo tiempo ser viable, tcnica y
econmicamente, para el proveedor.
Estos requisitos veremos ms adelante que
condicionan fuertemente la arquitectura
tecnolgica de una aplicacin SaaS y el modelo
de negocio del proveedor
Para entender este concepto fundamental es
necesario conocer los antecedentes a los actuales
modelos SaaS, los ASP o Application Service
Providers que en los 90 llegaron a tener cierta
notoriedad o Hype como se dice ahora.
La visin de negocio de los ASP era la misma que
pueden tener los actuales modelos SaaS pero el
estado de la tecnologa y madurez de las
empresas que se podran haber beneficiado no lo
era. Por ejemplo, uno trivial, la velocidad y
disponibilidad de las lneas de comunicaciones, o
la disposicin de las empresas a sacar sus centros
de datos fuera de sus paredes (algo a lo que ahora
estn ms predispuestas en general).
En muchos casos, el concepto ASP acababa en
que una aplicacin cliente-servidor, diseada y
construida para ser desplegada dentro de una red
local corporativa, se habilitaba para que su parte
servidor pudiera ser accesible desde fuera de la
red local a travs de Internet, y el paquete se
venda en forma de acceso por usuario.
Entre las razones tcnicas por lo que este modelo
fracas, operativa y econmicamente, se pueden
contar:
Velocidad y disponibilidad de Internet
en esa poca.
La arquitectura fsica con la que se
haban diseado esas aplicaciones no
escalaba ni soportaba bien compartir
infraestructuras fsicas en el lado servidor.
Era ineficiente en el aprovechamiento de
recursos hardware y software (la
virtualizacin de servidores era una
tecnologa incipiente, de laboratorio
prcticamente) y el hardware era caro en
esos aos.
La arquitectura del software no estaba
pensada para ser compartida por
compaas diferentes. Los datos y tablas
quiz s (o ni eso) pero una configuracin
del software para necesidades especficas
de una compaa no se poda hacer
estanca al resto, por lo que se podan
producir colisiones o incompatibilidades
entre ellas. Las modificaciones que sobre
una arquitectura ya desarrollada tenan
que hacerse, complicaban ms an el
entorno y lo podan hacer ingestionable
tcnicamente por el proveedor.
La evolucin del software poda ser en la
prctica inviable. O todos los clientes se
coordinaban para cambiar de versin a la
vez o no se poda, lo que deriv en que el
software se quedase atascado en una
versin o en que se tuviesen que separar
instalaciones por versin algo
antieconmico y a medio plazo
insostenible.
Al haber mucha lgica, incluso datos, en la
parte cliente, el despliegue y
mantenimiento homogneo de cualquier

LuisCarrasco 6/22
implantacin compartida era una tarea
muy costosa porque haba que actualizar
software en cada estacin de trabajo
En conclusin, para que una aplicacin de
gestin sea viable en modo SaaS, debe ser
capaz de poder conseguir economas de escala
al compatibilizar el que los clientes puedan
compartir los costes fijos (infraestructuras,
implantacin, soporte, mantenimiento, des-
implantacin, etc.), cubrir las necesidades
comunes y especficas de esos clientes y al
mismo tiempo poder evolucionar para
acomodarse a los cambios en esas
necesidades de cada uno. Es decir que sea
Multi-tenancy.
Afortunadamente esta posibilidad lleg de la mano
de avances tecnolgicos como la virtualizacin,
seguridad, velocidad y ubicuidad de lneas,
navegadores rpidos y capaces de incorporar
lgica de forma estndar -no propietaria- en local,
entornos y metodologas de desarrollo ms
avanzados, etc. que permitieron desarrollar
productos con arquitecturas tecnolgicas que
posibilitaban el Multi-tenancy y desplegar modelos
True SaaS.
Y como podemos verificar con nuestro proveedor
que su aplicacin de gestin es Multi-tenancy y
evitar as que en realidad acabemos contratando
una aplicacin tradicional en hosting, o lo que es lo
mismo que seamos un Single-tenancy ms en sus
infraestructuras?
Pues deberemos hacerle preguntas como:
Todos los clientes estn en la misma versin
del software? Todos los clientes deberan correr
la misma versin del cdigo, sin customizaciones
de cdigo. De esta forma cualquier configuracin
propia del cliente no acabar afectando al resto de
clientes ni, a su vez, se ver afectada por
personalizaciones de cdigo del resto de clientes -
Cunto se tarda en hacer un cambio de versin?
Qu tiene que hacer el cliente si se actualiza
la versin del software? Los clientes no se
deberan preocupar de tener que actualizar el
software, para ellos debera ser transparente, en
un extremo ni enterarse. As la actualizacin es
para todos los clientes a la vez y cualquier
configuracin especfica del cliente no debera
condicionar el poder actualizar el software al resto
Podras hacer maana mismo un cambio de
versin sin avisar a tus clientes?
Con qu periodicidad se actualiza el
software? No debera haber versiones en el
sentido tradicional sino frecuentes mejoras
incrementales (un ejemplo seran las aplicaciones
de Google) Cuntos cambios de
versin/upgrades/mejoras has hecho en el ltimo
ao?
Cmo va a cubrir la aplicacin mis
requerimientos funcionales clave [eljanse
varios cuidadosamente] y que son especficos
de mi compaa/negocio/sector? Si el proveedor
contesta que debe adaptar/cambiar el software es
probable que ste ya no sea una opcin adecuada
(al menos en modo SaaS) para el cliente. De
alguna forma la arquitectura de la aplicacin debe
estar construida de forma que se puedan
diferenciar las diferentes compaas cliente en el
momento de ejecucin de la aplicacin. En los
modelos ASP esto se consegua con el cdigo de
compaa/unidad organizativa, pero un
modeloTrue SaaS debe ir ms all, con
codificaciones que permitan que en modo de
ejecucin la aplicacin pueda distinguir entre
compaas clientes, hacer uso de clusters o
agrupaciones de unidades organizativas por
compaa cliente o por criterios de localizacin
geogrfica para temas de normativas locales por
ejemplo.
Con estos requisitos, en mi modesta opinin, veo
muy difcil, por no decir imposible, que una
aplicacin que no ha sido tcnicamente
diseada y concebida desde cero con un
enfoque de ser Multi-Tenancy, pueda serlo, ya

LuisCarrasco 7/22
que las modificaciones a posteriori que una
aplicacin tradicional requiera para ser Multi-
tenancy acabarn hacindola compleja y costosa
de gestionar y mantener, es decir inviable
econmicamente.
En conclusin, hay que prestar atencin a los
provedores con productos tradicionales
reetiquetados como SaaS que realmente no son
Multi-tenancy.

TECNOLOGA

Como ya se ha comentado anteriormente, la
tecnologa ha desempeado un importante papel
en el desarrollo viable de los modelos SaaS por lo
que, para asegurarnos que nuestro proveedor
SaaS tiene un modelo de negocio sostenible, es
importante poder contrastar con l cosas como:
Acceso con Browser as a Platform. El acceso a
la aplicacin debera poder hacerse sin necesidad
de instalaciones de software especfico en local o
al menos que el proceso de instalacin y
actualizacin se automatice de forma que sea
transparente para el usuario (aunque entonces
habr que gestionar los permisos en las
estaciones de trabajo, algo que en determinadas
organizaciones puede ser un impedimento
importante)
Lo habitual, y en mi opinin mejor opcin, es que
sea a travs de un navegador estndar (mejor
que no se dependa de uno en concreto) con AJAX,
HTML5 y como mximo algn plug-in tipo ActiveX,
Applet. Tambin es de esperar que avances
recientes en protocolos a nivel de aplicacin como
SPDY y Web Sockets de HTML5 mejoren
latencias y rendimiento de los actuales protocolos
HTTP pero esto ahora est saliendo
tmidamente de los laboratorios.
De esta forma se consigue:
Conectividad. Ser ms fcil acceder a la
aplicacin desde cualquier ubicacin con
acceso a Internet.
Facilidad de despliegue. En la
implantacin no se debera tener que invertir
en hardware de terminal de usuario ni
tiempo de instalacin.
Facilidad de evolucin. La aplicacin podr
evolucionar desde el lado de servidor sin
tener que actualizar nada en los clientes
facilitando as al proveedor el mantener una
versin nica de su aplicacin para todos
sus clientes
Un tema colateral importante aqu es la
conectividad de dispositivos locales como
impresoras, PLCs, sensores industriales, etc. pero
lo trataremos en el punto de integracin.
Escalabilidad de la plataforma tecnolgica
Hemos de partir de la premisa de que la
plataforma tecnolgica en la que estar alojada la
aplicacin SaaS ser compartida y deber poder
crecer de forma ms o menos lineal segn el uso
que le de la propia empresa y las empresas
vecinas. Parece pues muy razonable interesarnos
por las herramientas y tecnologas que el
proveedor va a utilizar para asegurarnos esa
escalabilidad. Concretamente habra que
preguntarle por temas como:
Qu productos/tecnologas va a utilizar
para gestionar su plataforma Cloud:
virtualizacin, despliegues de aplicaciones
(nuevos clientes y/o versiones/parches),
creacin de nuevos entornos/instancias,
gestin de los cambios de versin de
productos base (sistema operativo, bases de
datos, ), sincronizacin entre entornos de
desarrollo, test y produccin, compaginar
instalaciones compartidas con dedicadas,
etc.
Si la plataforma fsica es propia o de un
tercero proveedor de PaaS (Force.com,
Google App por ejemplo) o IaaS (Amazon
AWS, Microsoft Azure, IBM, etc.). Este punto,

LuisCarrasco 8/22
adems tiene relevancia a efectos legales,
como veremos ms adelante.
Si dispone de herramientas o tecnologas
especficas para la gestin de grandes
volmenes de datos o cmo va a asegurar
la escalabilidad de un entorno de datos que
al ser compartido va crecer ms y de forma
menos previsible de lo que lo hace en un
escenario no compartido. Sin llegar a los
extremos de tener que disponer de
tecnologas de Big Data pero creo que no
vale el enfoque por el que se optara en una
instalacin monocliente (el Multy-tenancy
aparece otra vez) al ser potencialmente un
entorno menos predecible y planificable.
Disponibilidad y seguridad fsica de la
plataforma tecnolgica
Teniendo en cuenta que al ser una aplicacin de
negocio vamos a utilizar la plataforma tecnolgica
del proveedor para gestionar nuestras operaciones
es obvio que tenemos que asegurarnos de que
esta plataforma va a estar disponible cuando la
necesitamos. Es por eso que nos deber interesar
conocer:
Contingencia. Qu pasa si hay una
incidencia que hace que las instalaciones (o
parte de ellas) donde residen las
infraestructuras dejan de estar operativas o
incluso son destruidas?, Cmo lo ha
previsto el proveedor y cmo se integra en
nuestra estrategia de recuperacin del
negocio en caso de desastre (tiene un
Disaster Business Recovery Plan)?, Hay
redundancia de equipamientos como lneas
de comunicaciones, alimentacin
elctrica, generador/grupo electrgeno,
etc.?, Dispone el proveedor, o nosotros, de
una instalacin de respaldo alternativa
para el caso de un desastre total, y en ese
caso cmo se efectuara la transicin?, y la
sincronizacin de datos entre
instalaciones principal-respaldo?
Rendimiento ante picos de actividad,
algunos predecibles y otros no,
inestabilidad del entorno por el cambio
continuo, Qu tecnologas va a utilizar el
proveedor para garantizar el rendimiento de
la plataforma, velocidad de las lneas, uso
de recursos de CPU, ? De la misma forma
que con la escalabilidad de datos, las
estrategias y arquitecturas tecnolgicas que
se han venido utilizando en instalaciones
single-tenancy es probable que no sean las
ms adecuadas.
Seguridad fsica. Cmo se controla el
acceso fsico a las instalaciones?, Quin
tendr acceso?, Sistemas de
vigilancia/registro/grabacin?,
Monitorizacin. Cmo va a controlar el
proveedor el rendimiento y disponibilidad de
la plataforma? Lo mejor es que el proveedor
pueda ensearos su centro de control y que
os explique qu herramientas de control y
gestin de alarmas utiliza y cmo os vais a
enterar si hay una incidencia. Volveremos
sobre esto en el punto de gestin del
servicio.
Seguridad de Datos
Los datos de clientes, sus pedidos, la informacin
de tu inventario, la facturacin toda esta
informacin no se puede perder; en general, no la
puede ver cualquiera y en algn caso la empresa
est obligada a protegerla. Se ha de tener claro al
menos:
Cmo se gestionan las copias de
seguridad: Periodicidad (diaria, cierre de
periodo/ejercicio, ), quin lo hace, dnde
se gestionan/almacenan las copias, control
de acceso,?
Cmo es la sincronizacin con posibles
centros de respaldo?
Se cifra la informacin sensible (ms sobre
esto en el punto sobre privacidad)?
Cmo se controla el acceso a la aplicacin,
a la base de datos, etc. tanto accediendo
desde dentro como desde fuera del
firewall/permetro de seguridad?

LuisCarrasco 9/22
Se registra/audita la actividad de acceso a
datos? Qu, quin y cundo se
modifican/leen/borran los datos
Cmo se asegura que otros clientes no ven
mis datos?
etc. no me extiendo ms en este punto
porque entiendo que hay disponible
abundante documentacin al respecto.
Green/Eficiencia Energtica
Y para empresas con sensibilidad y
responsabilidad social, por qu no preguntar por
las polticas de eficiencia energtica y prcticas de
proteccin del medio ambiente, etc.? Aunque sea
slo sea por el inters propio en que el proveedor
reduzca sus gastos operativos para dar un servicio
competitivo y sostenible hay informes [4] que
indican que entre un tercio y la mitad de los costes
operativos de un centro de proceso de datos
corresponden a la factura de energa.

INICIO DEL SERVICIO

Uno de los atractivos de utilizar un modelo SaaS
pasa por la premisa de que en general todo tiene
que ser ms rpido y sencillo. Es una hiptesis
de partida porque de no ser as el modelo no es
sostenible ni viable y debemos, por tanto, prestar
atencin a todos los elementos que nuestro
proveedor pueda aportar en este sentido.
Rapidez y sencillez en que:
No sea necesario realizar instalaciones de
infraestructura hardware y software en las
instalaciones de la empresa, lo que ya de
entrada debera acortar el tiempo de puesta
en marcha y eliminar las necesidades
adicionales (espacio, seguridad,
climatizacin, por ejemplo) para acomodar
nuevas infraestructuras o instalaciones
locales de software en los equipos de
usuario.
Haya disponibilidad de herramientas de
carga, depuracin, comparacin, etc. de
datos orientadas a acelerar la migracin y
conversin de informacin y la gestin de
paralelos.
Se utilicen Metodologas de puesta en
marcha giles [5], colaborativas, iterativas,
etc con entornos preconfigurados para la
captura rpida e incremental de requisitos,
aprender pronto para ajustar tambin pronto,
disponer de funcionalidades que estn
operativas de forma rpida y poder ir
afinndolas en ciclos cortos tambin.
La Configuracin (set up de entorno,
seguridad, alta de usuarios, etc.) sea rpida,
con asistentes (tipo siguiente-siguiente) y
aceleradores tales como un catlogo de
plantillas de procesos sectoriales y
horizontales ya preconfigurados, opciones
de activacin/desactivacin de
funcionalidades pre-existentes a demanda,
etc.
La puesta en marcha la puedan liderar
usuarios no tcnicos (a.k.a. de negocio) no
necesariamente expertos de producto.
Se podr objetar y con razn, que excepto el
primero, los anteriores puntos no tienen por qu
ser exclusivos de un modelo SaaS. Cierto pero,
no es verdad que suenan a ciencia ficcin en el
caso de los productos tradicionales? por qu
debera ser diferente en el caso de un modelo
SaaS? Pues se me ocurren al menos dos razones:
Ya lo he comentado al principio, si no es as
el modelo SaaS no se aguanta, por lo que
si un proveedor no nos est ofreciendo este
tipo de facilidades hay que verificar muy bien
el coste-beneficio que esperamos obtener.
Estos elementos deberan ser ms
fcilmente exigibles a una aplicacin SaaS
verdadera que a una tradicional ya que,
como ya se coment anteriormente en el
punto de Multi-tenancy, su arquitectura ya

LuisCarrasco 10/22
debera haberse diseado incluyendo
estas premisas y requerimientos.

EVOLUCIN DEL SERVICIO

Dentro de los puntos clave no poda faltar el
relativo a asegurar la evolucin adecuada del
servicio que esperamos recibir una vez puesto en
marcha dicho servicio, o dicho de otra forma, de la
elasticidad de la aplicacin para adaptarse a
las necesidades cambiantes que seguro va a
tener nuestra empresa.
Por eso deberemos pedirle al proveedor de la
aplicacin informacin sobre:
Evolucin de funcionalidades:
Cmo nos va a asegurar el proveedor que su
aplicacin evoluciona tecnolgica y funcionalmente
con el mercado/sector y con nuestras necesidades
especficas. Concretamente:
Qu plan de producto, road map, tiene
establecido: mdulos, funcionalidades
nuevas, etc. Atencin a la frecuencia de
actualizacin que, como ya se mencion en
la entrada de esta serie correspondiente a
Multi-tenancy, debera ser mayor que la de
una aplicacin tradicional.
Qu garantas nos da de adaptacin a
cambios a la legislacin vigente, algo
especialmente importante en aplicaciones
financieras y de RRHH.
Respecto a la evolucin de las
funcionalidades especficas de nuestra
empresa (ya sea mantenimiento evolutivo o
despliegue de nuevos mdulos y/o
funcionalidades) hay que pedir que, como se
coment en la entrada correspondiente al
inicio del servicio, pueda ser liderado por la
propia empresa, preferentemente por
usuarios del negocio -sin dependencias de
personal del rea de IT, por ejemplo
mediante la disponibilidad de un catlogo de
plantillas de procesos sectoriales y
horizontales que puedan ser desplegadas
por usuarios no tcnicos, activacin y
desactivacin de funcionalidades pre-
existentes a demanda y con un Sandbox
para pruebas para as no afectar al sistema
en produccin.
Todos estos puntos no son exclusivos de una
aplicacin SaaS evidentemente pero es de esperar
que sean ms asequibles que en las aplicaciones
tradicionales por lo ya mencionado anteriormente
de que la arquitectura de la aplicacin SaaS ya
debera haber sido diseada con estas
consideraciones.
Escalabilidad/rendimiento de infraestructuras:
Hay que considerar que al ser un modelo SaaS
vamos a tener que compartir las infraestructuras
con otras empresas. Debemos por tanto
asegurarnos de conocer qu medios, tecnologas,
metodologas, etc. tiene el proveedor para
acomodar picos en el nmero de transacciones en
el sistema, ya sean las previsibles (por ejemplo
cierres de mes, facturaciones masivas mensuales,
etc.) como las no previstas (un nuevo cliente por
ejemplo).
Otra vez hay que recordar que tenemos que estar
seguros que el modelo tecnolgico del
proveedor es sostenible y viable, no slo desde
el punto de vista tecnolgico sino tambin desde
el punto de vista econmico.
A nadie le va a gustar que se caiga el sistema, o
vaya lento, porque la empresa de al lado ha
lanzado su proceso de facturacin mensual o el
proveedor entre en riesgo de quiebra por las
inversiones que tiene que realizar para
acomodarse al volumen de transacciones que trae
un nuevo cliente. Por eso modelos de
infraestructura elsticos basados en IaaS de
terceros sern recomendables en principio ya que
permitirn esa escalabilidad de forma lineal
(aunque no olvidemos los temas legales, como se

LuisCarrasco 11/22
comentar posteriormente en el punto
correspondiente a privacidad)
Escalabilidad de usuarios:
Otro elemento a atar en corto es cmo se gestiona
el crecimiento y decrecimiento de usuarios de la
aplicacin para acomodarse a la dinmica de la
empresa. Un ejemplo extremo sera el de una
empresa sujeta a una alta temporalidad, donde en
la temporada alta sube el nmero de usuarios.
Debemos por tanto tener controlados aspectos
como:
Como varan los costes segn el n de
usuarios (me extender ms sobre esto en
el punto correspondiente a costes)
Facilidad de replicar/desactivar usuarios,
roles, etc. No tendra mucho sentido en un
entorno dinmico y gil, como el que se
supone que es un entorno SaaS, que poner
en marcha un nuevo usuario sea costoso.
Y es que nunca hemos de perder de vista que si
estamos barajando una aplicacin SaaS es porque
nos preocupa, entre otras cosas, la elasticidad de
la solucin, tanto para crecer como para
decrecer.

FIN DEL SERVICIO

En la Salida o Finalizacin del Servicio es
fundamental que nos aseguremos de la facilidad y
rapidez de salida en el caso en que haya
problemas, y as no quedarte atrapado por tu
proveedor [6]. Este punto est bastante estudiado
(vendor lock-in le llaman en la literatura
especializada) y es una de los puntos que ms se
citan como impedimentos y reticencias a los
modelos SaaS
A mi parecer, se ha de tener en cuenta:
Control y portabilidad de los datos:
Aunque la empresa cliente tendr acceso
restringido a las infraestructuras y depende en
ltima instancia del proveedor para que le
entregue sus propios datos, no se debera aceptar
ninguna restriccin por parte del proveedor a
acceder a tus datos en cualquier momento.
Por supuesto que debe haber reglas (seguridad de
acceso, formatos, tiempos de preaviso, etc.) pero
es un derecho inalienable del cliente el poder
extraer su informacin cuando la necesite y las
facilidades que ste tenga van a ser un
indicador inestimable de la bondad del
proveedor y de su aplicacin.
El tema se puede complicar si adems hay una
externalizacin de procesos (BPO) donde los
procesos son efectuados directamente por el
propio proveedor ya que entonces ser ms difcil
para el cliente conocer la estructura en detalle de
los datos que se quiere llevar.
Concretamente, habr que averiguar del
proveedor qu plan de salida ofrece en caso de
cese del servicio, con especial atencin a:
Formato de los datos para su portabilidad.
Archivos planos, Exports de tablas de las
bases de datos, un tema bastante
tecnolgico que deber conocerse bien para
identificar las posibles limitaciones que
pudiera haber.
Punto de corte: es decir en qu momento
se hace la foto de los datos para su
portabilidad. Una posibilidad, para estar
seguros de que el conjunto de datos es
coherente, es pedir una copia de seguridad
portable en cada cierre de periodo. En
teora, al menos a nivel de datos, sers libre
de irte al final de cada periodo con un
conjunto coherente de datos.

LuisCarrasco 12/22
Control y portabilidad de la aplicacin:
Si el proveedor quiebra o desaparece, o
simplemente decido irme, podr llevarme la
aplicacin y los datos a otro sitio? Lo puedo fijar
por contrato? Estas preguntas son de difcil
respuesta en segn que casos, sobre todo si el
software es propietario (o la tecnologa en la que
fue desarrollado) y desde luego no es algo
habitualmente previsto en los contratos que se ven
por ah (no me lo imagino con gigantes como
Salesforce.com o NetSuite por ejemplo). A este
respecto pues y en principio, ser interesante
poder optar por aplicaciones Open Source o
propietarias con derecho a descarga y
modificacin de los fuentes para uso exclusivo de
la empresa cliente.
Conocimiento
Adicionalmente tendremos que considerar no slo
la disponibilidad/portabilidad de la aplicacin.
Tener la aplicacin no basta, hay que tener los
recursos y el conocimiento (nosotros o terceros)
para que funcione.
Es por esto que aunque deleguemos totalmente la
gestin de aplicacin en el proveedor SaaS,
mantengamos personas dentro de nuestra
organizacin con el conocimiento necesario para
gestinar, aunque sea temporalmente y bajo
mnimos, la aplicacin hasta que finalice la
transicin a otro proveedor/aplicacin.
Condiciones y operativa de salida
Es decir fechas de preaviso, posibles
penalizaciones y calendarios mnimos (que habr
que acabar de negociar durante la negociacin del
contrato), coste de servicios adicionales en caso
de ser necesarios, etc. No me extender sobre
algo que est bastante explicado [6]
Y para rizar el rizo, Por qu no intentar la
Portabilidad de Procesos?
En la prctica consiste en poder llevarte contigo la
definicin de los procesos de negocio soportados
por la aplicacin, que slo ser posible si sta, de
alguna manera, est basada o respaldada por
algn tipo de herramienta BPM, que implemente
definiciones de los procesos en formatos
estandarizados tipo BPEL, BPMN, XPDL, etc.
De esta manera, al menos en teora, se podran
importar la definicin de los procesos a otras
aplicaciones de la misma manera que se
importarn los datos. Soy consciente de que esta
posibilidad es, a da de hoy, remota por el estado
de madurez de las herramientas BPM [13] pero no
la descartara a medio plazo.

INTEGRACIN

Es muy probable que la aplicacin SaaS que
queramos poner en marcha no sea la nica de las
aplicaciones de la empresa y que necesitemos
interconectarlas e integrarlas entre ellas.
La dificultad adicional que tenemos que
gestionar es que la aplicacin SaaS va a estar
en un entorno que no est siendo gestionado
por nosotros, por lo que se aaden
complejidades de ndole tcnica y operativa
que no se pueden desdear: necesidad de
traspasar un firewall que se supone muy exigente
de un tercero, no control de las ventanas
temporales y mecanismos de integracin si sta es
asncrona o batch, restricciones de seguridad y
tcnicas a la hora de hacer una integracin en
tiempo real, rigideces en formatos de
archivos/mensajes de integracin,etc.
Concretando, deberemos tener en cuenta
elementos como:
Integracin con aplicaciones externas
Tales como una Web de ventas, aplicacin de
nmina, herramientas de BI y/o reporting, EDI,
para las que como ya se ha mencionado antes hay
restricciones operativas y tcnicas que dificultan la
integracin. Hay que enterarse muy bien de las
vas estndar como APIs, Web Services,
herramientas, metodologas, etc. que el proveedor

LuisCarrasco 13/22
va a poner a nuestra disposicin para facilitarnos
esta integracin desde y hacia fuera de su firewall.
Con ofimtica
Hay que rendirse a la evidencia de que los
usuarios trabajan con archivos de ofimtica de
forma intensiva y que cada vez ms a las
aplicaciones de negocio se les requiere trabajar
con informacin no estructurada, como los
documentos ofimticos, integrada con la
transaccional propia de la aplicacin. Y hemos de
tener en cuenta que los documentos normalmente
estn/salen de la red local, del equipo de usuario o
de un gestor documental, y que muchas veces
esos documentos son pesados, lo que va a
suponer un reto para el ancho de banda disponible
y el rendimiento en general de la aplicacin. Otra
opcin, que me parece muy interesante, es la de
usar ofimtica en la nube. En ese sentido apunta
la decisin de SAP de integrar SAP Business
ByDesign con las aplicaciones de negocio de
Google [7]
Dispositivos locales:
Como impresoras, PLCs/Sensores en entornos
industriales, controles de presencia, etc.
Tendremos que verificar cuidadosamente los
requerimientos tcnicos de estos equipos para
estar integrados con la aplicacin SaaS en
cuestin. Si por esta razn se han de cambiar
equipos, el Business Case de la operacin se
puede resentir.
Hemos de ser consciente pues que una bscula
que vuelca datos al ERP, una impresora de cdigo
de barras o trmica, un PLC controlado desde el
ERP, etc. pueden ser dispositivos ms
complicados de integrar en un entorno Cloud.





PRIVACIDAD

Llegamos al tema, nada trivial por los aspectos
legales y de procedimiento que hay detrs, de la
seguridad y privacidad. Vaya por delante que
trasciende el propsito de este artculo hacer una
descripcin exhaustiva de la legislacin que debe
aplicarse, y como no tengo la formacin ni la
experiencia en temas legales requerida para ello,
me limitar a los aspectos tcnicos y operativos y
a proporcionar una lista de elementos a contrastar
con el proveedor, que he podido recopilar.
Dicho de forma muy sintetizada: hay que
asegurarse de que nuestros datos sensibles
(entendiendo como sensibles, datos de tipo
personal o los propios secretos de la empresa)
van a ser almacenados y tratados de una forma
que se cumpla la legislacin vigente en materia
de privacidad y seguridad, lo que acabar
afectando a cualquier elemento del servicio
relacionado con:
Ubicacin de los datos
Seguridad de acceso y almacenamiento
Tratamiento automatizado
Concretamente, tendremos que comprobar (y que
se refleje de alguna manera en el contrato con el
proveedor) al menos lo siguiente:
Realmente nuestro proveedor SaaS va tener
que almacenar/tratar datos sensibles?
Datos personales, segn se definan en la
legislacin vigente, que nos comprometen como
empresa y para los que hay diversos niveles de
sensibilidad- No es lo mismo una nmina que una
factura, y ya no digamos datos mdicos de un
empleado.
Datos propios de la empresa secretos: propiedad
intelectual, i+d, frmulas, listas de inversores,
Ser una tarea clave la identificacin de estos
datos y los controles que deberemos acordar con

LuisCarrasco 14/22
el proveedor para garantizar el cumplimiento, tanto
de nuestros requisitos de seguridad como el de los
legales.
Cul es la ubicacin de los servidores?
En la legislacin espaola sobre datos de caracter
personal, si los servidores van a estar fuera de las
fronteras espaolas aplica el concepto de
transferencia internacional de los datos, lo que
obliga a comprobar que el pas destino est
homologado por las autoridades espaolas como
ubicacin aceptable. Actualmente es aceptado
cualquier pas del Espacio Econmico Europeo o
de aquellos que la Agencia de Proteccin de Datos
tiene en su lista de Pases con un nivel adecuado
de proteccin. Atencin tambin a los
proveedores de nuestro proveedor.
Qu tipo de seguridad, fsica, respaldo,
procedimientos, acceso a servidores, etc. tiene
activada el proveedor?
Sin nimo de extenderme en este tema, el
proveedor debera poder mostrar qu medidas de
seguridad tiene implementadas. Lo ms fcil es
que pueda acreditar tales medidas mediante
certificaciones del tipo ISO27001, SAS 70 type II o
equivalente y que pase las auditoras especficas
pertinentes que marcan esas certificaciones.
Cmo se accede y viajan los datos?
El acceso, presumiblemente va Web, es
seguro,va https/SSL o VPN, o equivalente? Se
cifran los datos sensibles, que lo requieran, al
viajar y ser almacenados?
Quin puede acceder y tratar los datos
sensibles?
Aparte del proveedor principal, hay
subcontratados o terceros que pueden acceder y/o
tratar nuestros datos?
Debe tenerse en cuenta que es posible que
nuestro proveedor SaaS est utilizando recursos e
infraestructuras de terceros, por ejemplo una
aplicacin que corra en los servidores de Amazon.
Obviamente tendremos que conocer hasta el final
la cadena de proveedores y tenerlo en cuenta en
el contrato (por ejemplo que sea necesaria la
autorizacin previa para cualquier subcontratacin
o cesin del servicio a un tercero por parte de
nuestro proveedor SaaS )
Como nos afecta la legislacin especfica, por
ejemplo la LOPD en el caso de Espaa?
Es fundamental conocer de acuerdo a la
legislacin, el responsable ltimo es siempre la
empresa, por lo que se deber acotar muy bien en
el contrato, aparte de todo lo mencionado
anteriormente, los lmites y salvaguardas en el
tratamiento de los datos: fines de ese tratamiento,
como se devolvern y destruirn, etc.
y si, los seguramente super-exigentes,
abogados del BBVA no ven ningn problema en
que informacin tan sensible como la que manejan
los empleados del banco est en la nube[8] qu
podemos decir aqu.
Para acabar este apartado, recomiendo la lectura
de las referencias [9] respecto a privacidad que se
relacionan en la seccin de referencias.

GOBIERNO DEL SERVICIO

Si vamos a utilizar una aplicacin en modo SaaS
Software as a Service - tendremos que gestionar
ese as a Service y la manera habitual de gestionar
cualquier servicio externalizado es mediante
acuerdos sobre la calidad del servicio que
espera recibir el cliente del proveedor o, en la
jerga del sector, SLAs [10] (Service Level
Agreement) ligados a la QoS (Quality of Service).
Esta entrada no pretende cubrir en detalle qu es
un SLA ni como se negocia/acuerda, hay mucha
literatura, y buena, disponible, sino en los puntos
particulares que pueda tener la gestin y medicin
del servicio en el caso de aplicaciones SaaS de
gestin.

LuisCarrasco 15/22
Dicho esto, cuando estemos negociando con
nuestro proveedor de aplicaciones SaaS de
gestin cmo se va a gestionar,medir y gobernar
el servicio que nos quiere vender, tendremos que
atender, al menos, a los siguientes puntos:
Niveles de servicio por capas.
Teniendo en cuenta la arquitectura tpica de este
tipo de aplicaciones es conveniente conocer los
niveles de servicio para las distintas capas
tecnolgicas que la conforman:
Aplicacin
Integracin/Middleware
Infraestructuras
En principio los niveles de servicio que ms hemos
de controlar directamente son los de Aplicacin.
El resto pueden ser relevantes si hay terceros
proveedores, por ejemplo en la capa de
infraestructuras. Y si ese es el caso leer bien los
SLAs ofrecidos por ese tercero no vaya a ser que
no ests cubierto adecuadamente [11]
Niveles de servicio por tipo
Los niveles de servicio se pueden definir de varios
tipos. En este contexto no debera faltar:
Rendimiento de la aplicacin. Estos
niveles de servicio no es aconsejable que
sean genricos y se han de intentar definir
para las transacciones que consideremos
ms importantes por ejemplo tiempo que
se tarda en finalizar la entrada de un pedido
de cliente. Es recomendable que cada
empresa revise su caso particular y no
acepte por defecto las estndares (si las
hubiere, que es poco probable). Otro tema
es como se mide.
Tiempos/calidad de respuesta al soporte.
Tiempos relacionados con consultas,
incidencias, etc. de los usuarios finales o de
los tcnicos. Aparte de estos tiempos hay
que definir tipos de incidencia/consulta,
prioridades, etc.
Disponibilidad de la aplicacin.
Normalmente se expresa en porcentajes de
tiempo y excluye los tiempos dedicados a
mantenimiento de la plataforma. No olvidar
especificar el periodo de medicin de esa
disponibilidad (no es lo mismo el 99,9% de
disponibilidad mensual que anual).
No disponibilidad del servicio por
mantenimiento. Ya s que se ha dicho
antes que en una aplicacin true SaaS el
cliente ni se tiene que enterar de un cambio
de versin pero entiendo que la plataforma
requerir paradas por mantenimiento. Hay
que prestar atencin a tiempos de preaviso y
horarios (no es lo mismo no tener disponible
la plataforma el da que lanzas la facturacin
mensual que no tenerla un domingo)
Tiempos de puesta en marcha de nuevas
funcionalidades. Si la aplicacin, como
debera una True SaaS, permite
activar/desactivar funcionalidades, ser
conveniente especificar el tiempo de
activacin/desactivacin operativa.
Ligados a los procesos de negocio
Ya se ha apuntado antes pero lo recalco. Estamos
en un contexto de aplicaciones de gestin
empresarial. Cualquier parmetro de gestin del
servicio/sistema ha de tener como referente los
procesos de negocio cuando se traten temas
de disponibilidad, horarios, rendimientos,
velocidad, tiempos de ejecucin, aunque
hemos de ser conscientes del reto que puede
suponer para el proveedor trabajar en ese modo.
Hay ms elementos a tener en cuenta a la hora de
negociar los SLAs pero no veo que tengan
particularidades relevantes con respecto a un
SaaS de aplicaciones de gestin. No obstante no
nos olvidemos de temas como:

LuisCarrasco 16/22
Ajuste/renegociacin de SLA. Hay que
prever la posibilidad de ajustar
peridicamente los parmetros que miden la
calidad del servicio
Monitorizacin. Cmo va el cliente a ver
en tiempo real los parmetros de medicin
de la calidad del servicio y problemas que
puedan haber?
Reporting. Forma, periodicidad, formato de
la informacin, etc. que el proveedor va a
poner a disposicin del cliente para el
seguimiento de la calidad del servicio.
Penalizaciones/incentivos si las
expectativas no se cumplen o se cumplen
mejor de lo previsto
Mecanismos para la mejora continua.
Cmo incorporar las lecciones aprendidas y
el conocimiento adquirido de errores en
mejorar la gestin y el servicio
No se me escapa que este punto ha quedado
bastante genrico pero es que es un tema muy
extenso. He intentado al menos citar los puntos
ms importantes.

GESTIN DE COSTES

No puede faltar en este repaso de los puntos clave
a considerar al seleccionar una aplicacin de
negocio SaaS, el de los costes. Y es que uno de
los atractivos que posiblemente busquemos al
optar por un modelo SaaS es el de variabilizar los
costes totales de propiedad de la aplicacin de
gestin.
Esta variabilizacin se conseguir al utilizarse un
modelo de suscripcin/pago de una cuota
peridica relacionada con el uso que se hace
del sistema y que incluye todo (licencias,
infraestructuras, help-desk, nuevas versiones, etc.).
Y ese relacionada con el uso que hace del
sistema es clave en toda la gestin de costes:
Cmo nos va a medir el uso del sistema
nuestro proveedor?
Pues mejor temprano que tarde tendremos que
conocer bien su modelo de indexacin del
servicio, que habitualmente viene dado por uno o
una combinacin de los siguientes elementos:
N de Usuarios de la aplicacin, ya sean
concurrentes (slo cuentan los que estn
conectados en un momento dado) o
nominales (cuentan se conecten o no
pero cuidado con el shelfware! [12]). En el
caso de concurrentes tendramos modelos
dinmicos donde se pueden conectar todos
los que quieren y luego te facturan o con un
tope, donde si ste es n, el usuario n+1
que se quiera conectar no puede.
Tipos de usuario: No todos los usuarios
son iguales. Por ejemplo los hay que utilizan
todas las funciones, intensiva o
espordicamente, otros que utilizan una
funcionalidad determinada de forma
intensiva, los que se conectan slo para
consultar, lo habitual es que se
establezcan diferencias a nivel de
tarificacin entre estos diferentes tipos de
usuario.
Por mdulos / funcionalidad activada /
desactivada. Es decir por el tipo de uso que
se hace de la aplicacin. A considerar en
este caso, la facilidad que deberemos
requerir de nuestro proveedor para tener
una gestin gil de este uso tal como se ha
mencionado en el apartado sobre evolucin.
Transacciones por periodo. Este modelo
puede ser muy ventajoso si se liga a
transacciones que suponen ingresos ya que
el coste del servicio se liga al ingreso. Por
ejemplo por nmero de pedidos de clientes
entrados, facturas emitidas, clientes a los
que se le factura en el mes, o incluso un
porcentaje de la facturacin.
Consumo de recursos de computacin.
Esto, que se lleg a hacer en los albores de

LuisCarrasco 17/22
la informtica cuando gigantes como IBM te
alquilaban ciclos de CPU, no es un modelo
que para aplicaciones de gestin tenga
mucho sentido ya que es muy poco
predecible. No lo veo en un entorno de
aplicaciones de gestin pero si alguien tiene
una mejor opinin que comente.
Adicionalmente tendremos que tener en cuenta
que puede haber lmites inferiores (mnimos de
uso) y superiores, normalmente asociados a
limitaciones por consumo de recursos como ancho
de banda, ocupacin disco, consumo de CPU, etc.
Concluyendo, est claro que, independientemente
del modelo que ofrezca el proveedor, habr que
hacer un estudio minucioso de cmo se va a usar
la aplicacin y prever que tengamos la
capacidad de ir ajustando dinmica y
elsticamente nuestras necesidades.

LuisCarrasco 18/22
CONCLUSIN:
En este artculo he intentado hacer una cobertura a alto nivel de todos los puntos que
considero claves en la seleccin de una aplicacin de gestin en la nube o SaaS y que puedan
ser de ayuda tanto a la empresa que se est planteando comprar como a la que vende, o
quiere vender, este tipo de aplicaciones. Espero haber cubierto este objetivo dentro de mis
modestas posibilidades y si te ha gustado el artculo te agradecera su difusin entre tus
contactos profesionales, en redes sociales y colegas de trabajo que creas que les pueda
interesar - sobre todo si son CEOs, CIOs, CFOs, CxOs en general
Los puntos cubiertos en el artculo deben considerarse como una gua de partida, una especie
de check-list y nunca deberan ser sin ms el nico elemento para tomar una decisin. Si crees
que necesitas una ayuda ms adecuada a tus necesidades especficas no dudes en
contactarme.

LuisCarrasco 19/22

REFERENCIAS:
[1] How Cloud Computing And ERP Mobility Are Reordering Gartners Hype Cycle for ERP
http://softwarestrategiesblog.com/2012/01/02/how-cloud-computing-and-erp-mobility-are-
reordering-gartners-hype-cycle-for-erp/

[2] Roundup of Cloud Computing Forecasts and Market Estimates, 2012.
http://softwarestrategiesblog.com/2012/01/17/roundup-of-cloud-computing-forecasts-and-
market-estimates-2012/

[3] Gartner Executive Programs' Worldwide Survey of More Than 2,300 CIOs Shows Flat IT
Budgets in 2012, but IT Organizations Must Deliver on Multiple Priorities.
http://www.gartner.com/it/page.jsp?id=1897514

[4] Building data startups: Fast, big, and focused. Low costs and cloud tools are empowering
new data startups.
http://radar.oreilly.com/2011/08/building-data-startups.html

[5] Webinar en el Project Management Institute sobre la utilizacin de mtodos giles en la
implantacin de ERPs
http://www.nodotic.com/?p=539

[6] Atrapado por tu proveedor. Post en nodoTIC.com sobre los elementos a gestionar para
evitar quedar bloqueado por tu proveedor de servicios
http://www.nodotic.com/?p=679

[7] SAP Integration with Google Apps. SAP and Google recently announced plans to integrate
SAP Business ByDesign and Google Apps for Business.
http://en.sap.info/apps-google-bydesign/64640

[8] One of the most influential banks in the world adopts Googles technology as a part of its
innovation strategy. BBVA banks on the Google cloud
http://press.bbva.com/latest-contents/press-releases/spain/bbva-banks-on-the-google-
cloud(9882-22-101-c-92220).html

[9] Varias referencias en relacin a legislacin sobre privacidad de datos
Reforma/actualizacin que propone la Comisin Europea sobre el marco de 1995
http://ec.europa.eu/justice/newsroom/data-protection/news/120125_en.htm
LOPD y Cloud Computing:
http://www.gpn6.com/2011/11/lopd-y-cloud-computing/
Consulta pblica de la Agencia Espaola de Proteccin de Datos sobre Cloud Computing (es posible que este
enlace caduque, si es as buscar en la misma Web
http://www.servicios.agpd.es/AGPD/inicio_encuesta.seam?cid=960
Gua Cloud del Instituto Nacional de Tecnologas de la comunicacin INTECO
http://www.inteco.es/Seguridad/Observatorio/guias/Guia_Cloud
Aspectos contractuales y marco regulador del cloud computing
http://www.gesdatos.com/el-rincon-del-dato/aspectos-legales-en-cloud-computing.html

LuisCarrasco 20/22
Un ejemplo de condiciones de privacidad de un proveedor (SalesForce)
http://www.salesforce.com/company/privacy/
Un ejemplo de condiciones de disponibilidad (Netsuite)
http://www.netsuite.com/portal/infrastructure/availability.shtml
Lista de pases considerados Seguros
https://www.agpd.es/portalwebAGPD/canalresponsable/transferencias_internacionales/index-ides-idphp.php

[10] Posts en nodoTIC.com sobre el concepto de SLA
http://www.nodotic.com/index.php?s=sla

[11] Amazon SLAs Didn't Cover Major Outage. Customers affected by the recent EC2 outage
were compensated by Amazon, but not because the terms of the SLA required it.
http://www.informationweek.com/news/cloud-computing/software/229403086

[12] Shelfware. Software purchased but not used.
http://en.wiktionary.org/wiki/shelfware

[13] Presentacin en el Internet Global Congress de Barcelona de 2006 sobre herramientas BPM.
http://www.slideshare.net/luiscu/13-1-carrasco-delphin-phaq-presentation

[13] Encuesta en nodoTIC sobre ERP SaaS disponible en Espaa
http://www.nodotic.com/?p=701

LuisCarrasco 21/22

SOBRE EL AUTOR:

Luis Carrasco es Ingeniero de Telecomunicacin por la
Universidad Politcnica de Catalua, y Executive MBA por
EAE Barcelona.

Actualmente es gerente en Delphin Project Hunting, donde,
como consultor y project manager, lidera iniciativas para
sus clientes de mejoras organizativas, de procesos y
sistemas de informacin para la gestin empresarial.

Luis es editor de www.nodoTIC.com, blog sobre sobre tendencias en sistemas
de informacin de gestin empresarial.

Tambin podis encontrarle en diversas redes sociales:


http://www.linkedin.com/in/luiscu

@nodotic

https://plus.google.com/u/0/111838161734108867236/about

LuisCarrasco 22/22

DISCLAIMER:

Este artculo se ha publicado bajo licencia Creative Commons sa-by, lo que
bsicamente significa que puedes utilizarlo como quieras siempre que
menciones a su autor y que compartas de la misma forma cualquier obra
derivada en la que lo hayas utilizado. Para los detalles puedes visitar la Web de
creative commons: http://creativecommons.org/licenses/by-sa/3.0/deed.es

En la redaccin de este artculo me he inspirado en mltiples lecturas y he
utilizado recursos grficos que he intentado referenciar y atribuir a sus autores.
Si crees que hay algo en el artculo que debera ser cambiado, aadido o
modificado hzmelo saber.