Embed Size (px)
Citation preview
RESOLVENDO PROBLEMAS DE CUSTOMIZAÇÃO EM
SOFTWARES COMO SERVIÇO (SaaS)
ANDRÉ LUIZ ARANHA DOS SANTOS
LUKAS SOARES CAVALCANTE
UNIVERSIDADE PRESBITERIANA MACKENZIE
São Paulo
2011
ANDRÉ LUIZ ARANHA DOS SANTOS
LUKAS SOARES CAVALCANTE
RESOLVENDO PROBLEMAS DE CUSTOMIZAÇÃO EM
SOFTWARES COMO SERVIÇO (SaaS)
Trabalho de conclusão de curso apresentado à
Faculdade de Computação e Informática da
Universidade Presbiteriana Mackenzie, como
requisito parcial para a obtenção do título de
Bacharel em Sistemas de Informação.
Orientador: Prof. Ms. Cláudio Rogério Washizo Caruso
São Paulo
2011
Resumo
SaaS (Software as a Service) é um novo modelo de fornecimento de software,
onde a aplicação fica hospedada na infra estrutura do fornecedor, e é paga por
anuidade, ou mesmo por uso efetivo. Visando o levantamento de práticas e
métodos para a customização desse tipo de aplicação, esta pesquisa chega a
contemplar as bases tecnológicas e embasamento técnico do modelo (origens,
disponibilização pela internet, mecanismos “multi arrendamento” e questões de
isolamento de dados), além de expor técnicas pesquisadas de customização,
seja em nível de base de dados, campos e procedimentos da aplicação. São
tratados ainda os aspectos mercadológicos do modelo SaaS,
indissociavelmente do conceito de Long Tail, que nos leva a ter em vista que
essas aplicações são voltadas a um rol por demais abrangente de usuários,
que por sua vez, conduz à conclusão de que as possibilidades de
parametrização, e também as atualizações de sistema, precisam ser
ponderadas da forma devidamente rigorosa. Desde o início, ficou sujeita à
validação a hipótese de publicar customizações de pequeno impacto como
atualização, para todos os clientes, e customizações mais profundas serem
disponibilizadas em ambientes separados e dedicados. Em suma, a hipótese
acaba sendo validada, mas com as recomendações e considerações expostas,
inclusive a de trabalhar essa funcionalidade desde a fase de projeto. De
quebra, foi feita uma pesquisa via formulário on-line, de onde tiramos dados
estatísticos para comparar com as afirmações teóricas das fontes pesquisadas.
Ficou claro que as possibilidades de customização acabam satisfazendo as
necessidades e esperanças dos usuários, dados os levantamentos técnicos e
as estatísticas das respostas à pesquisa realizada, principalmente no tocante
ao conhecimento que os usuários afirmam ter da tecnologia, suas intenções e
pensamentos, coisas que fizeram parte do formulário.
Palavras chave: SaaS, software como serviço, customização, parametrização,
multi arrendamento.
Abstract
SaaS (Software as a Service) is a new model of software delivering, which the
application be hosted no the vendor’s infrastructure, and it is paid on an annual
or monthly basis, or even on an effective use rate. In order to verify practices
and methods for customizing on this type of application, this research work
comes to contemplate the technological bases of SaaS (origin, delivery via
internet, multitenant engine, and data isolation issues), besides exposing the
surveyed customizing techniques, on database, fields and application
procedure levels. It is also covered aspects of SaaS marketing, indissolubly
from the “Long Tail” concept, which lead us to aim these applications are
addressed to a group highly great of users. These all drive to concluding that
the parameterization possibilities and system updates must be deliberated
under the properly right method. Since the work beginning, a hypothesis was
subjected to validation. It was: publishing small changes for all clients, as being
general updates; and high customizations on dedicated instances, just for use
of the claimant. In summary, this hypothesis was validated by the research, but
with the exposed recommendations and considerations, including work on the
customization functionality since the project phase. Also was published an
online form to collected responses from the general public about SaaS, for
comparing statistical data with the theoretical statements, of the sources read. It
became clear that customization possibilities satisfies the user’s needs and
hopes, saw the technical information and survey response’s statistics,
especially referring to the knowledge the users say have of SaaS, their
intentions and thinking, that was included in the form.
Keywords: SaaS, software as a service, customizing, parameterizing,
multitenant.
Índice de Ilustrações
Figura 1. Extremos quanto ao modelo de isolamento em nível de Base de
Dados. Fonte: (CHONG, CARRARO, & WOLTER, Multi-Tenant Data
Architecture, 2006) ........................................................................................... 19
Figura 2. Categorias de modelo de isolamento em nível de Base de Dados.
Fonte: (CHONG, CARRARO, & WOLTER, Multi-Tenant Data Architecture,
2006) ................................................................................................................ 20
Figura 3. Isolamento com bases de dados separadas. Fonte: (CHONG,
CARRARO, & WOLTER, Multi-Tenant Data Architecture, 2006) ..................... 20
Figura 4. Isolamento com schemas separados. Fonte: (CHONG, CARRARO, &
WOLTER, Multi-Tenant Data Architecture, 2006) ............................................ 21
Figura 5. Dados coexistentes na mesma base e no mesmo schema. Fonte:
(CHONG, CARRARO, & WOLTER, Multi-Tenant Data Architecture, 2006) ..... 22
Figura 6. Ilustração de gráfico da Long Tail. Fonte: Wikipédia. ........................ 26
Figura 7. Gráfico da Long Tail mapeando os públicos alcançáveis. (CHONG &
CARRARO, Architecture Strategies for Catching the Long Tail, 2006) ............ 26
Figura 8. Gráfico da Long Tail mapeando o novo mercado que passa a ser
alcançável para o SaaS. (CHONG & CARRARO, Architecture Strategies for
Catching the Long Tail, 2006) .......................................................................... 27
Figura 9. Customização do modelo de dados por tabela extensível. Fonte:
(CHONG & CARRARO, Architecture Strategies for Catching the Long Tail,
2006) ................................................................................................................ 31
Figura 10. Gráfico de resposta – Você já ouviu falar em software como serviço
(SaaS) ou computação em nuvem? ................................................................. 46
Figura 11. Gráfico de resposta – Você utilizaria um software que fica
hospedado, juntamente com seus dados, na infra estrutura do fornecedor, a
troco de não precisar se preocupar mais com TI (software e hardware)? ........ 46
Figura 12. Gráfico de resposta – “Assinaria” um software assim mesmo que seu
fornecedor NÃO prestasse nenhum tipo de customização, exceto as opções
oferecidas pela própria aplicação? ................................................................... 47
Figura 13. Gráfico de resposta – A possibilidade de precisar de customizações,
em um software não customizável, causaria algum tipo de receio em você na
hora de "assinar", mesmo que ele te atenda perfeitamente no momento? ...... 47
Figura 14. Gráfico de resposta – Se você adquirisse um software, de qualquer
natureza, para a empresa onde trabalha, qual você crê ser a probabilidade de
necessitar customizações dentro de seis meses? ........................................... 48
Lista de Siglas
ASP Application Service Provider
COTS Commercial off the Shelf Software
CRM Customer Relationship Management
EAV Entity Attribute Value
ERP Enterprise Resource Planning
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
PC Personal Computer
RH Recursos Humanos
SaaS Software as a Service
SPED Sistema Público de Escrituração Digital
TI Tecnologia de Informação
Sumário
1. Introdução .................................................................................................. 9
2. Considerações Gerais ............................................................................. 11
2.1. Caracterização do Tema ..................................................................... 11
2.2. Identificação do Problema ................................................................... 12
2.3. Justificativa e Contribuição do Estudo................................................. 12
2.4. Objetivos e Delimitação do Trabalho................................................... 12
2.5. Hipóteses ............................................................................................ 13
3. Metodologia .............................................................................................. 14
4. Base Tecnológica do SaaS ..................................................................... 16
4.1. Definições do conceito SaaS .............................................................. 16
4.2. Acesso via Navegador ........................................................................ 17
4.3. Multi Tenancy ...................................................................................... 18
4.4. Isolamento de dados Multi Tenant ...................................................... 19
4.5. Excelência ........................................................................................... 23
5. Aspectos Mercadológicos ...................................................................... 25
5.1. Long Tail ............................................................................................. 25
5.2. Mercado inviável para SaaS ............................................................... 27
6. Customizações ........................................................................................ 29
6.1. Cenário atual ....................................................................................... 29
6.2. Customização do modelo de dados .................................................... 30
6.3. Campos customizados ........................................................................ 31
6.4. Customização de procedimentos ........................................................ 32
6.5. Considerações gerais .......................................................................... 34
7. Análise das pesquisas de formulário ..................................................... 35
8. Conclusão ................................................................................................ 36
9. Referências Bibliográficas ...................................................................... 40
10. Apêndices ................................................................................................. 45
10.1. Apêndice A – Texto que conceitua SaaS ......................................... 45
11. Anexos ...................................................................................................... 46
11.1. Anexo A – Relatório de respostas da pesquisa de formulário .......... 46
9
1. Introdução
O SaaS (Software as a Service, ou Software como Serviço) é um novo modelo
de fornecimento de programas de computador, em plataforma web, onde o
cliente o “assina” e paga tarifas enquanto utiliza o software, podendo
simplesmente cancelar o serviço quando não mais deseja-lo.
Ao contrário do modelo COTS, ou on the shelf, ou ainda on-premise, que
consiste no “mercado de prateleira” de software, onde o cliente adquire (uma
única vez) a licença e o mesmo torna-se um ativo da empresa, que possui toda
a infraestrutura necessária para operá-lo.
Do ponto de vista técnico, existe uma única aplicação, rodando num servidor
mantido pelo fornecedor do software, a qual todos os clientes acessam,
comportando-se de igual modo para todos. Nesse detalhe, nasce o problema
da customização de aplicações fornecidas como serviço, pois o programa de
computador é um só atendendo a todos os usuários.
A pesquisa concentrará esforços no sentido de encontrar alternativas viáveis
para a solução do problema da customização. Não objetivando o enfoque
técnico, estaremos propensos a analisar a viabilidade das opções de natureza
técnica a serem encontradas.
Por falta de padrão nas literaturas estudadas, estabelecemos nossa própria
terminologia para designar determinadas ações:
Customização – consiste em qualquer atividade de alteração de uma
aplicação SaaS, para sua melhor adequação ao uso. O termo é
qualificado tanto para modificações feitas pelo fabricante, ao alterar
códigos fonte, quanto pelo usuário, mediante recursos disponíveis no
aplicativo. Ainda, poderemos utilizar “customização” para referir-nos às
alterações de softwares não vendidos como serviço. Uma customização,
então, pode ser feita por:
10
o Intervenção técnica – alteração de códigos fontes, normalmente
praticado pelo fabricante ou fornecedor. Afeta todos os usuários
da instância alterada;
o Parametrização – alteração do comportamento e/ou estrutura da
aplicação mediante configurações oferecidas por ela para tal.
Sempre feito pelo usuário final, e válido somente sobre o seu
escopo da aplicação, sem afetar os outros usuários.
Um termo que é muito confundido com o SaaS é o ASP (Application Service
Provider, ou Provedor de Serviços de Aplicação). ASP trata de aplicações que
não foram originalmente desenhadas para operar na internet, mas foram
modificadas, para que seus usuários pudessem usufruir de recursos on-line
com elas, ou mesmo para que pudessem ser vendidas pelo site do fabricante.
O conceito de SaaS nasceu devido às limitações dos ASP, que lidavam com
softwares legados. Assim como SaaS, ASPs podem ser pagos enquanto há
utilização, e podem ter ativação instantânea (BLOKDIJK, 2008). Ainda, a
possibilidade de haver licença perpétua o software fica descaracterizado como
SaaS (GARTNER, INC., 2011). Em nossa pesquisa, trabalhamos com o
conceito de SaaS, por não considerar a existência de tecnologias legadas e
aplicações já desenvolvidas para ambientes off line ou mono usuário.
11
2. Considerações Gerais
2.1. Caracterização do Tema
O SaaS (Software as a Service) é um modelo de fornecimento de software que
vem crescendo a partir dos anos 2000, que consiste em fornecer ao cliente, via
internet, um software de plataforma web que fica hospedado no servidor do
fornecedor.
Em vez do usuário ou empresa adquirir uma licença permanente de um
programa de computador, desembolsando uma única vez o valor do produto,
ele faz uma assinatura de um serviço que, sendo pago mensalmente, ou
conforme o uso, confere-lhe o direito de uso da aplicação, podendo ter limites
de utilização, conforme o pacote contratado.
Assim, as empresas usuárias já não precisam possuir infraestrutura pré-
definida, adquirir componentes de hardware, tampouco arcar com tarefas de
manutenção, integridade, disponibilidade, e outros encargos do gerenciamento
de TI, o que gera economias em atividades e até contratação de profissionais
(MA & SEIDMANN, 2008).
BLOKDIJK (2008) divide o fornecimento SaaS em dois principais tipos, que
diferem-se pelo público alvo da aplicação:
Aplicações de negócios (line-of-business), tais como CRMs, ERPs e
outras aplicações para empresas;
Orientadas ao cliente, geralmente fornecidas gratuitamente, como web
mails.
A pesquisa estará focada nas aplicações empresariais, onde há margem para
as questões a serem estudadas.
12
2.2. Identificação do Problema
Apesar do crescimento promissor do SaaS, o mesmo possui questões não
solucionadas, no tocante a preços de licenciamento e custos secundários de
gerenciamento, segundo COUTO (2010). Entre os fornecedores que estão
aderindo a esse novo paradigma, observa-se ainda vários modelos de
negócios um tanto experimentais, contudo, não se sabe qual irá prevalecer.
Também existe a questão da customização: uma vez que o software oferecido
é disponibilizado em instância única (uma só aplicação rodando no servidor,
conceito de multi tenancy, explicado mais adiante) a todos os usuários,
quaisquer alterações nos códigos fontes lhes serão replicadas, anulando a
possibilidade de exclusividade entre os clientes.
2.3. Justificativa e Contribuição do Estudo
Levando em conta a impraticabilidade de se manter várias instâncias de uma
mesma aplicação, ou o abandono da customização para clientes específicos,
bem como os interesses em larga escala evidenciados, é necessário chegar a
um método prático de se aplicar e manter as customizações, do ponto de vista
técnico.
No mundo mercadológico do SaaS, passa a ser alcançável um enorme
mercado, antes alienados aos fornecedores de softwares tradicionais (veja o
capítulo Aspectos Mercadológicos). Pela oportunidade de negócio que ele
constitui, e pela maior quantidade de usuários, fazem-se necessários métodos
de customização práticos para o pessoal de TI do fornecedor, e que supram a
maioria das necessidades em potencial de todos os usuários clientes.
2.4. Objetivos e Delimitação do Trabalho
O objetivo geral da pesquisa consiste na solução de problemas com
customizações de aplicações SaaS, fazendo dos objetivos específicos o
seguinte:
Validar uma hipótese concebida para o tratamento de customizações em
SaaS;
13
Apontar boas técnicas de oferecer customizações, de forma adequada,
às aplicações SaaS.
2.5. Hipóteses
Ao pesquisar em livros e publicações especializadas, somadas à experiência
na área, pode-se levantar algumas hipóteses. Dentre elas apresentamos uma
aparentemente aceitável, que será validada no decorrer da pesquisa.
No caso das customizações, pode-se dividi-las em duas categorias:
Micro alterações – são aquelas que consistem desde a eliminação de
falhas, otimização e melhoramento de funções e interfaces, até o
acréscimo de novos recursos que não influenciem nos fluxos principais
do sistema;
Macro alterações – são aquelas que acarretam o tratamento de um
maior número de dados, informações, afetando e alterando os outros
fluxos do sistema e, portanto, a operação do usuário.
A alternativa proposta como hipótese para estudo é o seguinte método para
publicação de customizações: a disponibilização de micro alterações seria
diretamente na instância principal do aplicativo, ficando à disposição de todos
os usuários (ou assinantes) do software, uma vez que sua operação não será
afetada; criar novas instâncias da aplicação e da base de dados para os
usuários que desejarem customizações que envolvam macro alterações (neste
caso haveria o problema de duplicidade, e o fornecedor também atuará como
uma fábrica de software).
Esse método se aplica às customizações solicitadas pelo cliente no aplicativo,
não às opções de parametrização disponibilizadas pela aplicação ao usuário,
consistindo assim intervenções técnicas no sistema.
14
3. Metodologia
Além de pesquisas bibliográficas e em meios de comunicação específicos,
elaborou-se questionário on-line para que seja medida a aceitação de
profissionais e empresários, tanto de TI quanto de outras áreas, de forma
generalizada, quanto às imposições dadas pelas soluções SaaS, no tocante a
customizações, escopo, desempenho da ferramenta e modelo do fornecimento.
Ainda, serão buscadas informações junto a fornecedores de SaaS, para
levantamento dos pontos técnicos a serem observados no momento de
customizar um software como serviço, bem como os recursos que eles
mesmos disponibilizam.
No decorrer do trabalho, foram realizadas as seguintes atividades:
Revisão e pesquisa bibliográfica, em meios acadêmicos e empresariais,
acerca de soluções SaaS;
Aplicação e análise de resultados de pesquisa com questionários;
Confronto dos resultados das pesquisas de questionário com as
informações obtidas das fontes bibliográficas, de forma a levantar
evidências e conclusões;
Busca de notícias e matérias nos meios de comunicação (sites, jornais,
revistas, meios especializados em TI e em negócios, e afins).
A pesquisa foi concebida com base na metodologia científica apresentada
pelas autoras EVA LAKATOS e MARINA MARCONI. O método indutivo foi
adotado por ser um processo mental, onde a partir de dados particulares e
suficientemente constatados, influenciam a verdade geral e universal. Pode-se
dizer que os argumentos indutivos levam a conclusões onde o conteúdo é
muito mais abrangente do que as premissas em que se baseiam (MARCONI &
LAKATOS, 2003).
O método indutivo irá contribuir com a validação de uma hipótese de melhor
prática de customização, fundamentando-se no cruzamento da análise das
15
vantagens e desvantagens de cada método com o levantamento das opiniões e
pensamentos dos usuários.
A característica marcante do método indutivo é que os argumentos levam
apenas a conclusões prováveis ou pode-se afirmar que as premissas de um
argumento indutivo correto sustentam ou atribuem certa verossimilhança à sua
conclusão. Assim, quando as premissas são verdadeiras, o melhor que se
pode dizer é que a sua conclusão é, provavelmente, verdadeira (CERVO &
BERVIAN, 1978).
Pelo fato do tema SaaS ser novidade no mercado e com poucos opúsculos
publicados, onde a maior parte das informações encontradas a seu respeito
estão em artigos, sites especializados em tecnologia, notas de fornecedores
em seus sites, pesquisas de especialistas e em alguns livros, cujo o acervo é
muito limitado, não é possível obter uma conclusão absolutamente verdadeira,
pois cada autor apresenta pontos de vista diferentes e chegam a conclusões
diversas. Com isso o mais coerente é adotar o método indutivo, onde
chegamos a uma conclusão provavelmente verdadeira ao findar da pesquisa.
16
4. Base Tecnológica do SaaS
4.1. Definições do conceito SaaS
Software as a Service (SaaS) também recebe nomes como aplicação
hospedada, fornecedor de aplicações, soluções hospedada, entre outros. Isso
significa que o software está hospedado remotamente em servidores e
infraestrutura mantidos pelo fornecedor. O armazenamento, suporte técnico e
manutenção necessários também são dados pelo fornecedor (BLOKDIJK,
2008).
Para MELO, ARCOVERDE, MORAES, PIMENTEL, & FREITAS (2007), o SaaS
assemelha-se ao modelo original do mainframe, onde o controle era
centralizado, e a privacidade e flexibilidade do usuário individual eram
limitadas. Retratam ainda que há quem possa dizer que SaaS tem uma falta de
controle e privacidade inaceitável.
No site institucional da empresa Digital Intelligence, SaaS é o modelo onde as
empresas deixam de comprar licenças e passam a ser “assinantes” dos
softwares (DIGITAL INTELLIGENCE, 2011), que são acessados pela internet.
Os benefícios oferecidos são redução de custo, agilidade, acessibilidade,
flexibilidade, continuidade e integração (que parte da pró-atividade da
fabricante em questão, a Digital Intelligence, no tocante à integração com
sistemas comuns no mercado, outros produtos da empresa, e interfaces via
Web Services1).
Já a Gartner define SaaS como um software de propriedade total do
fornecedor, que é fornecido e administrado remotamente pelo mesmo. Se há
necessidades do cliente instalar algo em sua infraestrutura, o produto não
constitui SaaS (GARTNER, INC., 2011). Ainda na mesma definição, deve haver
a figura do fornecedor, que também possui (ou terceiriza) a infraestrutura
necessária, as operações de suporte, de manutenção e atualização. O software
1 Solução na comunicação de aplicações diferentes, com componentes que trocam dados fazendo do
XML uma linguagem universal.
17
é um conjunto único de códigos e modelos de dados, que é consumido de
forma um-para-muitos por vários clientes ao mesmo tempo. Os clientes só
podem realizar suas customizações através de mecanismos oferecidos pela
aplicação, sem mudanças no código fonte ou modelo de dados, em contraste
com a hospedagem de aplicações tradicional, que mantinha diferentes bases
de dados e versões para cada cliente que requeria modificações.
4.2. Acesso via Navegador
SaaS é um modo de fornecer um programa de computador via internet aos
usuários, de modo que o mesmo fique hospedado em servidores da infra
estrutura do fornecedor, que também proporciona recursos como
armazenamento, processamento, suporte e manutenção, conforme necessário,
bem como atualizações e correções (BLOKDIJK, 2008).
Com o enraizamento da internet – em banda larga – no cotidiano das pessoas
e empresas, a utilização de aplicações rotineiras que dependem de
conectividade tornou-se viável. Assim, os programas SaaS, que basicamente
dependem de um navegador de internet, ganharam o que lhes faltava para
serem aceitos em grande escala.
A utilização via internet traz consigo duas vantagens:
o acesso aos dados mesmo de fora do escritório, e de regiões distantes,
durante viagens;
por meio de celulares e dispositivos móveis, de micro computadores de
qualquer tipo de hardware ou sistema operacional.
Portanto, além de romper qualquer barreira geográfica, resolve o problema de
interoperabilidade entre plataformas, uma vez que pode ser acessado por
qualquer dispositivo capaz de acessar páginas de internet.
O problema de segurança no tocante à comunicação pode ser resolvido com o
uso do protocolo HTTPS (HTTP com SSL), que além fornecer um duto de
comunicação seguro na internet, permite a identificação do servidor e cliente
18
através de certificados digitais (PMSP, 2011), do modo como faz os aplicativos
que compõem o SPED2, em várias prefeituras e secretarias da fazenda
estatuais.
É fortemente característico das aplicações SaaS uma arquitetura multi
tenancy3, onde a mesma instância da aplicação interage, processa requisições
e armazena dados de todos os usuários no mesmo banco de dados e nos
mesmos recursos de armazenamento físico, porém não compartilhando as
informações entre eles (BLOKDIJK, 2008), a menos que esteja previsto nas
regras de negócio. Obviamente as máquinas que hospedam a aplicação devem
ter capacidade computacional de atender todas essas demandas, de todos os
usuários, oferecendo escalabilidade para o software (BLOKDIJK, 2008).
4.3. Multi Tenancy
Multi Tenancy é uma arquitetura na qual uma única instância de uma aplicação
é utilizada por vários clientes, onde cada cliente é denominado tenant.
Inclusive, tenants podem estar habilitados a customizar detalhes do software,
como as cores da interface gráfica e regras de negócio, tudo via
parametrização, mas nunca tocando nos códigos fonte. Tende a ser mais
econômico, pois os custos de desenvolvimento e manutenção são
compartilhados (WHAT IS, 2011).
Na definição de Taurion (2010), Multi Tenancy, ou multi inquilino, ou ainda multi
arrendatário, é uma arquitetura que permite que vários clientes / empresas
compartilhem os mesmos recursos físicos ao usar um aplicativo ERP, por
exemplo, mas mantendo seus dados logicamente isolados.
As aplicações SaaS em web têm em comum o atender a vários clientes sem
que um tenha conhecimento da existências dos outros (SILVEIRA, 2010).
Pelo que temos observado quanto ao uso do termo, “Tenancy” significa
“arrendamento” em inglês, e é muito usado nas literaturas de língua inglesa
(multi tenancy, tenant) para referir-se à arquitetura onde há o consumo, por
2 SPED – Sistema Público de Escrituração Digital.
3 Multi sessão. Uma única instância de aplicativo que roda no servidor e atende diversos clientes.
19
parte de usuários, às aplicações SaaS, que costumam ficar hospedadas nos
servidores dos fornecedores.
Multi tenancy significa a capacidade de uma mesma aplicação poder atender
múltiplos clientes ao mesmo tempo; cada tenant individual é um cliente da
aplicação.
Quando for dito “usuário”, “cliente” ou afins, estaremos em correspondência
com o termo tenant, das referências de língua inglesa, não devendo o leitor
desprezar o contexto e sentido da sentença.
4.4. Isolamento de dados Multi Tenant
Os possíveis modelos de isolamento dos dados dos clientes (tenants) em nível
de base de dados são uma árvore resultante da combinação de um conjunto de
fatores. A escolha adequada para esses detalhes depende da aplicação e da
consideração de fatores técnicos, comerciais, estratégicos e externos CHONG,
CARRARO, & WOLTER (2006).
Figura 1. Extremos quanto ao modelo de isolamento em nível de Base de Dados. Fonte: (CHONG, CARRARO, & WOLTER, Multi-Tenant Data Architecture, 2006)
Contudo, pode-se enxergar três categorias principais de isolamento, a saber,
bases separadas, schemas separados e schemas compartilhados. As três
abordagens referem-se apenas à alocação dos dados (bases de dados) de
cada usuário da aplicação, ficando os recursos computacionais, códigos fonte e
compilados totalmente compartilhados entre os usuários, descritos a seguir por
CHONG, CARRARO, & WOLTER (2006).
20
Figura 2. Categorias de modelo de isolamento em nível de Base de Dados. Fonte: (CHONG, CARRARO, & WOLTER, Multi-Tenant Data Architecture, 2006)
Bases separadas
Cada usuário da aplicação dispõe de uma base de dados exclusiva para os
registros que lhe pertencem, em isolamento lógico aos dados dos demais
usuários. Fica por conta da aplicação a identificação e o acesso à base de
dados correta, conforme o usuário requisitante.
Figura 3. Isolamento com bases de dados separadas. Fonte: (CHONG, CARRARO, & WOLTER, Multi-Tenant Data Architecture, 2006)
Esse modo facilita a extensão do modelo de dados, atendendo individualmente
às necessidades dos usuários; a recuperação isolada de dados de clientes
específicos em caso de desastres, mas os custos de manutenção e backup
tendem a ser altos. É um método adequado para organizações que
necessitem, e paguem, por um maior grau de isolamento e flexibilidade.
Base compartilhada com schemas separados
Usa apenas uma base de dados, porém cada usuário possui seus registros
num conjunto de tabelas agrupadas em um schema de seu uso exclusivo e
criado para si.
21
Figura 4. Isolamento com schemas separados. Fonte: (CHONG, CARRARO, & WOLTER, Multi-Tenant Data Architecture, 2006)
As características desse modo são:
A implementação, gerenciamento e customização dos dados e modelo
de dados são tão fáceis quanto no modo isolado;
Oferece um grau intermediário de isolamento lógico de dados, mas não
igual à arquitetura de bases separadas;
Pode suportar um número maior de clientes;
Os processos de backup e restauração tornam-se mais complexos, pois
tratando-se de uma mesma base, esses procedimentos afetam todos os
esquemas;
Recomendado para aplicações com até cem tabelas por usuário.
Base compartilhada e schemas compartilhados
É o agrupamento de todos os dados, de todos os usuários, num único schema.
Há uma tabela de usuários, e a identificação dos registros nas outras tabelas
dá-se com o uso de chaves estrangeiras. A aplicação, portanto, não precisa
fazer câmbios de configuração em suas conexões ao banco de dados, mas em
contrapartida, requer um maior esforço no desenvolvimento da parte de
22
segurança, para garantir que os dados não serão acessados por outros
usuários, acidental ou maliciosamente.
Figura 5. Dados coexistentes na mesma base e no mesmo schema. Fonte: (CHONG, CARRARO, & WOLTER, Multi-Tenant Data Architecture, 2006)
As características mais relevantes são:
Possui o menor custo de hardware e backup;
Permite atender o maior número de usuários no mesmo servidor;
Os métodos de restauração são semelhantes ao modo de schemas
isolados, porém com complicações adicionais, pelo compartilhamento
das tabelas;
Recomendado a aplicações que precisam atender um grande número de
clientes, e compatíveis com o grau de isolamento de dados oferecido.
Já segundo as definições de TAURION (2010), os modelos de isolamento de
dados multi-tenant ou multi inquilino são outros: Inquilino Isolado, multi
inquilino via hardware compartilhado (virtualização), multi inquilino via
container e multi inquilino via todo o stack de software compartilhado.
Inquilino isolado
Cada um tem seus próprios recursos tecnológicos alocados, sem o menor
compartilhamento. Apesar de o usuário ter uma experiência multi tenant, pelo
fato de todos os clientes terem suas aplicações hospedadas no mesmo data
center, o modelo não o é. Para uma oferta de SaaS, esse modelo carece de
agilidade e de elasticidade, já que a adição de um novo cliente requer a
alocação de novos recursos e instalação de uma nova instância.
23
Hardware compartilhado (virtualização)
Cada cliente tem o seu stack de tecnologia, mas o hardware é alocado via
mecanismos de virtualização. É o modelo anterior acrescido de elasticidade de
hardware.
Container
As requisições de vários clientes são executadas na mesma instância de um
container de aplicação (um servidor), mas cada um tem sua própria instância
no software de banco de dados. Ou seja, o ambiente de execução é
compartilhado, mas a base de dados não.
Stack de software compartilhado
A evolução do modelo anterior, onde há compartilhamento de todos os
recursos tecnológicos, inclusive da instância do software e do banco de dados.
4.5. Excelência
Como afirmam CHONG e CARRARO (2006), do ponto de vista de arquitetos
de aplicação, há três características fundamentais que uma aplicação SaaS
bem desenhada deve conter:
Escalabilidade (scalable)
Trata da maximização da concorrência e uso mais eficiente dos recursos
computacionais.
Atendimento eficiente a vários usuários (multi-tenant-efficient)
É uma das mais significantes mudanças de paradigma que uma
arquitetura centralizada poderia sofrer. O servidor que hospeda o
software, o qual determinado cliente (tenant) acessa, também o
disponibiliza para centenas de outros clientes, sem o menor
conhecimento uns dos outros, semelhantemente a um provedor de
hospedagem de sites ou contas de email. Isso requer uma arquitetura
que otimize o compartilhamento de recursos entre os usuários, mas
imprescindivelmente capaz de diferenciar os dados de cada um.
24
Possibilidades de configuração (configurable)
Uma mesma instância de software atende a muitos usuários de
diferentes empresas, o que impede os desenvolvedores de
simplesmente escrever códigos para customizar a experiência de um
usuário, pois isso seria refletido a todos os clientes. Uma alternativa
seria permitir configurações, através de parametrização, com meta
dados para os clientes definirem como querem que a aplicação se
apresente e comporte. O desafio atual para a arquitetura SaaS é
assegurar a possibilidade de configuração simples e fácil para os
usuários, sem insistir em demandas extras de desenvolvimento. Essa é
a questão da nossa pesquisa, e será devidamente tratada nos capítulos
seguintes.
25
5. Aspectos Mercadológicos
Neste ponto, faz-se necessário abordar questões mercadológicas do SaaS,
que, apesar de não relacionadas ao foco da pesquisa, podem nos ajudar a
chegar a conclusões, por influenciarem na viabilidade em certos pontos
técnicos, além de constituir o nosso argumento de justificativa da pesquisa.
5.1. Long Tail
A demanda de artigos como CDs, livros, DVDs tendem a seguir a Lei da
Distribuição de Pareto (power law distribution). Assim, milhares de títulos são
publicados todos os anos, mas apenas alguns chegam ao patamar de best-
sellers. O restante jaz no que se chama de “long-tail”: uma infinidade de títulos
não populares, sem perspectiva de vendas significativas (CHONG &
CARRARO, 2006).
Ainda segundo a explanação de CHONG & CARRARO, as lojas físicas
tradicionais concentram-se na venda dos produtos mais populares, pois têm
suas limitações de estoque e prateleira, e usam seu espaço da forma mais
lucrativa possível. Já as lojas virtuais, por sua vez, não precisam se preocupar
com espaço, pois podem enviar os produtos aos clientes diretamente de seus
espaçosos centros de distribuição e armazenamento. Assim, é possível
anunciar e vender desde o milionésimo item da escala de popularidade até o
lançamento mais vendido do momento. O acesso a essa long tail gera um
enorme aumento de receitas.
Uma grande loja física pode comportar até 130 mil títulos diferentes em suas
prateleiras e estoques. Mas a maioria das vendas do e-commerce Amazon.com
são de títulos que não se enquadram entre os 130 mil mais populares (CHONG
& CARRARO 2006 apud ANDERSON 2004). Ou seja, a maior parte das
vendas da Amazon.com seria inviável caso fosse uma loja física.
26
Figura 6. Ilustração de gráfico da Long Tail. Fonte: Wikipédia.
A parte verde do gráfico representa os produtos mais populares e procurados,
e suas vendas. A amarela, que se assemelha a uma cauda, é a projeção dos
menos procurados, os quais juntos, produzem um somatório de receitas maior
que o proveniente dos mais demandados.
Um conceito parecido se aplica ao mundo do SaaS. Fornecedores de soluções
de software complexas, para grandes empresas, tem uma limitação de público
alvo, devido à condição financeira e porte dos clientes. Não são todas as
empresas que podem arcar com servidores dedicados, softwares adicionais,
funcionários de TI para manter tudo isso, pagar equipes de desenvolvimento
para customizar o produto, etc. Certas soluções só podem ser compradas por
grandes corporações, apesar de serem benéficas para pequenas e médias
empresas.
Figura 7. Gráfico da Long Tail mapeando os públicos alcançáveis. (CHONG & CARRARO, Architecture Strategies for Catching the Long Tail, 2006)
27
O SaaS tem uma plataforma ideal para promover a Long Tail como modelo de
negócio ( MY SAAS BLOG, 2007). Com os detalhes já citados do SaaS,
incluindo entre outras coisas o compartilhamento do hardware, que é mantido
pelo fornecedor, é possível vender a mesma solução a um preço muito menor,
além de eliminar os custos de manutenção para o cliente. Com isso, uma
massa demasiadamente grande de clientes (a Long Tail) entra no mercado
potencial para o fornecedor de software.
Figura 8. Gráfico da Long Tail mapeando o novo mercado que passa a ser alcançável para o SaaS. (CHONG & CARRARO, Architecture Strategies for Catching the Long Tail,
2006)
Sendo assim, fazem-se convenientes métodos que permitam a “assinatura” do
software de forma rápida e fácil, tanto para a empresa quanto para o cliente,
para que se possa realizar um número escalável de vendas. A possibilidade de
assinatura instantânea pelo site do produto, via formulário, é ótima, pois
dispensaria muitos recursos e desgastes (tempo, pessoal, telefone, etc.).
5.2. Mercado inviável para SaaS
Apesar do SaaS ter como característica a tomada de uma demanda reprimida
pelos fornecedores tradicionais, vale lembrar que ele também possui um
mercado aparentemente inalcançável, como os softwares críticos, estratégicos,
de inteligência de negócio e que, enfim, tenha um alto volume de
particularidades, como colocou UNICOMM (2010), sendo que esse mesmo
fator foi denominado uma imaturidade momentânea por SPOSITO (2008).
28
Trata-se de que, quanto mais peculiaridades, maior será a dificuldade, e
maiores serão as perdas de aderência, ao adaptar um software genérico a uma
empresa. Por isso, aplicações que tocam o âmago de uma empresa, como
ERPs e inteligência de negócios, nem sempre se prestam ao modelo SaaS
(UNICOMM, 2010). Esse tipo de software, nas empresas, geralmente
permanece em constante evolução, seja para melhorar suas funções atuais ou
agregar-se com novas; ou seja, sofrendo mudanças constantes no código
fonte. Não seria de se estranhar que um produto SaaS dessa modalidade
tenha, ao longo do tempo, instancias exclusivas para a maioria dos seus
clientes. Daí a grande inviabilidade para o modelo como serviço.
29
6. Customizações
6.1. Cenário atual
Normalmente as aplicações SaaS fornecem alguma flexibilidade para os
usuários, mas o modelo possui suas limitações. Se uma aplicação exige, para
implantação em determinada empresa, uma customização que o fornecedor
não pode dar, seu uso fica inviabilizado (CARRARO & CHONG, 2006).
Dependendo da abordagem de compartilhamento utilizada (vide
“Compartilhamento de dados em multi tenant”), essa questão se agrava,
tornando necessário outra instância da mesma aplicação, descaracterizando o
modelo de fornecimento no tocante à centralização.
As principais necessidades de customização vêm, entre outros, dos seguintes
fatores (PROGRESS SOFTWARE CORPORATION, 2008):
a) Acessibilidade – principalmente para pessoas míopes ou daltônicas.
Inclusive, o governo dos Estados Unidos possui regulamentações de
acessibilidade para sistemas;
b) Padrões Corporativos – Há empresas que fazem questão de manter sua
marca e identidade visual nas estações de trabalho, e não aceitar a
marca de diferentes fornecedores de SaaS. A possibilidade de
customização das cores e logotipos pode facilitar a aceitação desses
clientes.
Para WARFIELD (2007), os fornecedores de SaaS precisam saber reconhecer
se o domínio de suas aplicações realmente tem uma tendência a necessitar de
customização ou não. Se sim, eles precisam encontrar um jeito de fornecer a
customização e a devida implementação a preço e tempo competitivo em
relação ao resto do mercado.
Segundo SOUSA (2010) as duas principais técnicas utilizadas para resolver
mudanças de requisitos, em qualquer software, são:
Configuração – o usuário conta com artifícios e parâmetros já
contemplados na aplicação para alterar suas funcionalidades e adequá-
30
la às suas necessidades (a própria “parametrização” da nossa
terminologia, como explanado na Introdução);
Personalização – Envolve alterações no código fonte para implementar
tais modificações (exatamente o que denominamos “intervenção
técnica”, na Introdução).
Como a intervenção técnica requer novos esforços de desenvolvimento, dá
margem a novas fases de análise, implementação, testes, homologação e
aceitação, ou seja, a um novo projeto, aumentando o custo e o tempo de
desenvolvimento e implantação do software. O autor salienta que o
desenvolvimento de SaaS deve evitar ao máximo a customização, usando
ampla parametrização para atender às exigências do mercado.
6.2. Customização do modelo de dados
Para customizações do modelo de dados, há três opções, segundo CHONG &
CARRARO (2006), a saber: base de dados dedicada, base compartilhada
com extensão fixa, base compartilhada com extensão customizável.
Base de dados dedicada
Possui exatamente a mesma estrutura do modelo de compartilhamento de
dados com mesmo nome, descrito anteriormente. Cada cliente tem sua base
de dados e as customizações são nela feitas, sem interferência nos demais
usuários.
Base compartilhada com extensão fixa
A base de dados é compartilhada para todos os clientes (tenants). Em cada
tabela há um conjunto estático de campos genéricos, que podem ser usados
com a finalidade desejada por cada cliente.
31
Figura 9. Customização do modelo de dados por tabela extensível. Fonte: (CHONG & CARRARO, Architecture Strategies for Catching the Long Tail, 2006)
Base compartilhada com tabela extensível
Cada dado que fuja ao padrão do sistema é armazenado em uma tabela
separada, que se relaciona ao registro principal. Essa tabela, além da chave
estrangeira, possui um par de campos nome / valor. Opcionalmente pode ser
agregado outro campo para armazenar o tipo do dado, para que a aplicação
saiba como trata-lo adequadamente. A grande desvantagem dessa técnica é a
complexidade contraída pelas funções do banco de dados, como busca,
indexação, consulta, etc.
6.3. Campos customizados
Inevitavelmente, os usuários costumam apresentar novas necessidades, que
estendem as aplicações. Sendo que existe um mesmo modelo de dados e
código de programa, os fornecedores necessitam uma maneira de entregar
essa customização sem mudar o banco de dados nem os códigos do sistema.
Duas formas tornaram-se popular (BHATIA, 2010):
Entity Attribute Value (EAV) – Usa pares de nome e valor, e inúmeras
tabelas com meta dados (YCMI). Apesar de se adaptar rapidamente a
qualquer mudança, é muito diferente do modelo relacional, dificultando
sobremaneira a escrita de consultas e inviabilizando indexações
(AGUIAR, 2008);
32
Custom Joined Table – Adiciona uma tabela extra no banco, para cada
cliente.
BHATIA (2010) afirma haver um método melhor do que esses, o qual descreve
em sua obra. Não serão descritos detalhes técnicos, apenas a arquitetura.
O schema conta com uma tabela extra com campos de vários tipos (as
quantidades e tipos limitarão a customização), para armazenamento dos dados
dos campos customizados, e que se relaciona com a tabela de clientes
(tenants); ainda, uma segunda tabela com o mapeamento dos campos
customizados, também se relacionando com a tabela de tenants, apenas para
armazenamento de informações como o nome, tipo, descrição tamanho (...)
dos campos (metadados). A grande vantagem, segundo o autor, é manter os
benefícios do modelo relacional.
6.4. Customização de procedimentos
Foram estudados alguns métodos para customizações mais profundas em
softwares SaaS e multi tenant. Serão expostos seu embasamento e
consequências, sem abordagem dos detalhes técnicos.
Uma das propostas para customizações de SaaS que envolvam além de
campos de tabelas, chegando ao nível de procedimentos, é o chamado modelo
de customização por multi granularidade. No momento, os estudos ainda não
estavam em um patamar adequado para aplicação à realidade de forma pratica
e objetiva (LI, SHI, & LI, 2009).
Os autores expõem os desafios da customização em aplicações multi tenant, e
propõem um modelo de customização que interpreta os relacionamentos entre
os elementos do sistema que, por sua vez, são categorizados em: dados,
serviço, processo e interface. Os objetos de cada tipo, que devem ser
customizados, são identificados separadamente, bem como os seus
relacionamentos, para análise.
As possibilidades de método de customização podem enquadrar-se em quatro
níveis, os níveis de granularidade. Esses níveis oferecem características
33
distintas no tocante à flexibilidade, facilidade para o usuário, facilidade para o
desenvolvimento, entre outros.
Acerca da customização por granularidade, o que obtemos, por enquanto, é um
modelo para se analisar os elementos do sistema e seus relacionamentos, bem
como do impacto da implantação dos recursos de customização. Por ainda não
possuir a devida maturidade, não é possível analisar vantagens e
desvantagens.
Também existe a customização baseada em topologia de dependências.
DONG, ZHANG, SHI, XU, & GUO (2010) propõem que os tenants terão à
disposição possibilidades de intervenção para configurar parametrizações nas
seguintes camadas:
Dados – Usada para a configuração de colunas em tabelas. A aplicação
pode contar com colunas vazias, ou genéricas, para o usuário decidir
como usar. Existem técnicas para a prática dessa customização;
Função – O usuário pode selecionar diferentes módulos de funções.
Podem ser funções inteiras ou algumas partes;
Processo – Trata do work flow da aplicação. O tenant pode customizar
(ou parametrizar) a aplicação tanto montando um novo processo através
de funções já existentes, quanto alterando a ordem em que funções são
executadas;
Interface – Parametrização da interface do usuário em geral,
abrangendo cores, títulos, nomes, logotipos, etc.
Haveria telas de configuração, para o usuário especificar suas preferências
acerca dos itens do sistema, divididos nas categorias acima. É utilizada, ainda,
a “topologia de dependências”, que documenta as dependências de um
elemento para com outro, para análise, e servindo também para auxiliar e
validar as configurações feitas por usuários finais. Nesse modelo, as
intervenções podem ser dividas em adição, modificação e retirada de funções.
De qualquer modo, vemos que a customização de processos, mais ainda do
que de campos, torna complexo o desenvolvimento da aplicação, mais ainda
34
quando essas customizações devem ser possíveis via parametrização, quando
inclui também a necessidade de validação do que o usuário está fazendo.
6.5. Considerações gerais
Ao levantar dados sobre o assunto, pode-se notar claramente que
customização dos aplicativos é algo que não se adequa ao SaaS. Ainda afirma
que esse tipo de artifício é bom para atividades que estão sendo automatizadas
pela primeira vez, pois não há processos legados para substituir, ou que não
estejam ligadas ao núcleo ou à inteligência do negócio (UNICOMM, 2010).
A aplicação ideal para SaaS é aquela básica, padronizada e que possa ser
compartilhada entre várias empresas, a exemplo de CRM, RH, contabilidade,
colaboração e controle de despesas. Para aplicações críticas ou que agregam
diferenciais ao negócio, o modelo ainda não é maduro, devido à necessidade
de customizações. Customizar significa mexer no código fonte, e isso desvirtua
o conceito. Esse tipo de artifício terá de ser sacrificado, para manter o baixo
custo e facilidade de implantação. Consultorias apontam essa questão como
uma das desvantagens do SaaS (SPOSITO, 2008).
35
7. Análise das pesquisas de formulário
Foi realizada uma pesquisa via formulário dirigida tanto a profissionais de
tecnologia da informação quanto de outras áreas, sem distinção, bem como a
gestores e empresários, objetivando justamente a averiguação da aceitação
dos paradigmas do SaaS pelo público generalizado, em especial a questão das
imposições de customização.
Fazem-se necessárias pesquisas mais aprofundadas e segmentadas para a
constatação do que realmente o mercado espera no momento. Porém, como
as deliberações de uma só classe em determinado instante podem não refletir
as tendências factuais, ponderamos válido fazer a pesquisa de forma
generalizada.
A repetição da mesma pesquisa, depois de um período razoável para as
evoluções da área de TI, como três a cinco anos, também é válida para medir a
evolução do público e confirmar tendências.
Na seção Conclusão serão expostas as informações levantadas pela pesquisa
de campo, em confronto com o restante do trabalho. Os gráficos de
consolidação das respostas constam no endereço:
http://tiamk.net/RespostaPesqSaaS.pdf, ou ainda,
http://www.arank.com.br/Files/RespostaPesqSaaS.pdf.
Na contabilização final da pesquisa, havia 102 respostas registradas. Como o
formulário é aberto a público, e foi amplamente divulgado, talvez haja mais
registros posteriores.
36
8. Conclusão
Apesar de se parecer com o mainframe na questão da centralização da
inteligência, e de o sucesso do PC ter vindo da individualização dos usuários,
como concluem alguns pesquisadores, é evidente que o SaaS proporciona
muito mais do que aquele paradigma. Juntamente com o software é oferecida
uma terceirização (outsourcing) de serviços profissionais, de infraestrutura e de
manutenção, de forma implícita, bem como uma disponibilidade global e multi
plataforma da aplicação. Essa terceirização representa própria e
intencionalmente “a falta de controle e privacidade”, também citada por
acadêmicos, sendo seus encargos transferidos para o fornecedor.
Por ser um produto voltado à long tail, ou seja, uma infinidade de
consumidores, oriunda das bases da pirâmide econômica das pessoas
jurídicas, com diferentes necessidades e particularidades, o SaaS acaba
forçado à customização por parametrização, tornando-a não tão dispensável
quanto no modelo de negócio on-premise4, uma vez que neste, cada cliente
normalmente tinha sua própria instância, e instalada no seu próprio parque,
dando então margem a qualquer tipo de mudança peculiar; e naquele as
atualizações no código fonte influenciam todos os clientes da fornecedor de
SaaS, em suas minuciosidades. Consequentemente as customizações no caso
do Software como Serviço devem ser ponderadas mui rigorosamente.
Em contra partida, a própria customização vai à contramão do SaaS, segundo
duas fontes a que tivemos acesso. Isso faz sentido, pois faz parte do SaaS
como modelo de negócio o alcance da long tail, que exige rapidez e facilidade,
de aquisição e implantação, não compatibilizando-se com métodos
desgastantes e demorados, ou com a realização de projetos de implantação.
Ainda que não apresente inconvenientes para empresas já habituadas a operar
como as tradicionais fábricas de software, a prestação de serviços de
customização inviabiliza o alcance do mercado da long tail, em custo e tempo
competitivo.
4 Modelo de venda e licenciamento tradicional de software.
37
Faz muito sentido dirigir um produto com baixa disposição à customização
apenas a aplicações padronizadas e não críticas. Independente de
conseguirmos enxergar ou não o que seria a maturidade necessária para a
adequação do SaaS aos sistemas que envolvem peculiaridades, é um erro
subestimar a capacidade de evolução da tecnologia, em termos de técnicas e
inovações, sobretudo na informática. Contudo, também concluímos que novos
aplicativos como serviço, pelo menos no corrente momento, só são válidos
para as aplicações com baixa tendência à mudança.
O problema de customização de campos e no modelo de dados está
praticamente resolvido, com as técnicas citadas. No caso da customização de
procedimentos, foram estudadas duas técnicas muito semelhantes, apesar de
uma delas ter sido apresentada como ainda não suficientemente madura para
a prática. De qualquer modo, é razoável que se ofereça mais customizações
apenas nos recursos (campos e processos) mais passíveis de mudança, tendo
em vista que esse tipo de incremento torna complexo o desenvolvimento do
sistema, sobretudo no tocante à customização processos, ou implementação
da parametrização de processos.
Quanto à hipótese proposta, concluímos que sua viabilidade depende do
modelo de negócio adotado pelas companhias, se de apenas um fornecedor de
SaaS, ou se também de uma fábrica de software. Para nós, é adequado sim
adotar esse modelo no seguinte modo:
Publicar na instância geral todas as customizações que não implicarem
mudanças de rotinas por parte do cliente, a exemplo de, tipicamente,
novos campos que sejam opcionais; ou ainda leves incrementos em
processos, desde que só sejam ativados por opção (e por padrão
desativada);
Caso o fornecedor de SaaS também ofereça projetos de customização
no software, cabe criar uma nova instância para tudo aquilo que alterar
fluxos e saídas, com dificuldade de coexistência com o primeiro modelo,
ou que necessitar de câmbios no modo como o cliente opera do sistema,
requerendo-lhe novas instruções. Pois instabilidades nos softwares são
capazes de prejudicar a imagem desse modelo. Nesse caso, há
38
possibilidades de negócios baseados no fornecimento dessas
instâncias, que envolvem servidores dedicados e staff, de forma a
oferecer a solução já pronta a um preço definido;
Ao criar um SaaS para fornecer, fazê-lo desde as fases de projeto e
concepção empregando técnicas que permitam ao banco de dados e à
aplicação o suporte a novos campos de definição exclusiva do usuário,
como o EAV ou Custom Joined Table, ou preferencialmente, a técnica
proposta por Bhatia (vide seção 7.3. Campos customizados), ainda que
limite a quantidade de campos customizados, pois ela mantém os
benefícios do modelo relacional e não exige intervenções técnicas para
cada novo cliente.
A questão da customização requer muito cuidado por parte da comunidade de
fabricantes. Já foi postado que, caso distribuições do Linux pudessem adotar
padrões diferentes de manipulação de arquivos (entre outras coisas), somado
ao fato de o código ser aberto, seria gerada uma série de incompatibilidades
entre computadores diferentes, ao trocar arquivos, podendo levar o sistema
operacional à sua autodestruição. A solução para isso foi padronizar,
convencionalmente, as funções do kernel que podiam sujeitar o sistema a
incompatibilidades. A fim de evitar o mesmo risco para o SaaS, seria bem vinda
uma convenção que tratasse de que tipos de recursos precisam oferecer
customização (cadastro de funcionários, processos de faturamento, etc.), e que
categoria de aplicações, em minucias, são adequadas ao SaaS.
Quanto à pesquisa de opinião feita com formulário on-line, foi possível
identificar, principalmente, as seguintes informações:
a) 67% das respostas registradas alegam conhecer SaaS e saber do que
se trata.
b) A possibilidade de cortes de custos e despreocupação com a TI interna
leva 86% dos pesquisados a declarar sua aceitação ou a possibilidade
de cogitar o uso de uma solução SaaS;
c) A maioria das respostas (64%) realmente afirmou ter um receio de não
poder customizar um software adquirido, contra 36% que dizem não
39
temer, seja por confiar na capacidade dos fornecedores de suprir novas
necessidades ou por outros motivos. Por outro lado, esse receio não
parece impedir mais da metade dos entrevistados (53%) de assinar um
software na hipótese de não poder customiza-lo, a não ser pelos
recursos que a aplicação oferece;
d) Em uma questão que pedia, em uma escala de 0 a 10, a probabilidade
de fazer-se necessária depois de seis meses, uma customização em um
software adquirido, a média de respostas com as notas de 0 a 4 foi de
2,8%, e total de 14%; já a média e total de respostas para as notas de 5
a 10 foram, respectivamente, 14,3% e 86%. Ou seja, constata-se que na
maioria dos casos, se faz realmente necessária a opção de
customização.
Os itens (c) e (d) demonstram certo nível de consciência dos respondentes
acerca dos “inconvenientes” do SaaS, principalmente diante do item (a), que se
refere ao conhecimento por parte deles. Mesmo assim, é notado pelo item (b)
uma maioria disposta à ideia desse modelo de fornecimento. Diante disso,
podemos passar a encarar a tendência à estaticidade como algo menos nocivo
para o marketing dessas soluções. Para evitar inviabilizações no modelo, ainda
que pouco impactantes (e também para acompanhar a provável concorrência),
faz-se mais válidas ainda as medidas apontadas acerca da hipótese, citadas há
pouco nessa seção: publicar micro customizações na instância compartilhada,
para atender expectativas de suprimento de novas necessidades; e
disponibilizar parametrização de campos de tabela e alguns procedimentos,
para minimizar fatores de inviabilização.
Sugerimos novas pesquisas com foco na aceitação de micro e pequenos
empresários (long tail) ao modelo, experimentos com técnicas para amadurecer
o SaaS a aplicações críticas e em modelos práticos de customização de
procedimentos.
40
9. Referências Bibliográficas
MY SAAS BLOG. (30 de Janeiro de 2007). SaaS and The Long Tail. Acesso
em 02 de Setembro de 2011, disponível em My SaaS Blog:
http://www.mysaasblog.com/longtail.htm
AGUIAR, G. M. (27 de Fevereiro de 2008). Modelo (EAV) - Entity-Attribute-
Value. Acesso em 10 de Setembro de 2011, disponível em MSDN Fóruns:
http://social.msdn.microsoft.com/Forums/pt/520/thread/c48bdf54-3a36-4159-
8c89-a7aa0d46a096
ANDERSON, C. (Outubro de 2004). Wired 12.10: The Long Tail. Acesso em 27
de Agosto de 2011, disponível em Wired.com:
http://www.wired.com/wired/archive/12.10/tail.html
ARIMA, K. (23 de Julho de 2010). Venda de SaaS corporativo será de US$ 8,5
bi. Acesso em 24 de Novembro de 2010, disponível em Info Exame:
http://info.abril.com.br/noticias/corporate/venda-de-saas-corporativo-sera-de-us-
8-5-bi-23072010-39.shl
BHATIA, S. (09 de Outubro de 2010). High Performance Custom Fields for
Multi-Tenant SaaS Architectures. Acesso em 28 de Julho de 2011, disponível
em Beyond Relational:
http://beyondrelational.com/blogs/sanjay/archive/2011/01/20/high-performance-
custom-fields-for-multi-tenant-saas-architectures.aspx
BLOKDIJK, G. (2008). SaaS 100 Success Secrets. Lightning Source.
CARRARO, G., & CHONG, F. (Outubro de 2006). Software as a Service
(SaaS): An Enterprise Perspective. Acesso em 21 de Maio de 2011, disponível
em MSDN Library: http://msdn.microsoft.com/en-us/library/aa905332.aspx
CARVALHO SOUSA, F. R. (Maio de 2010). Acesso em 16 de Setembro de
2011, disponível em Universidade Federal do Ceará:
http://www.es.ufc.br/~flavio/files/saas.pdf
CERVO, A., & BERVIAN, P. (1978). Metodologia Científica. Mcgraw-hill.
41
CHENG, H. K., & KOEHLER, G. J. (2003). Optimal pricing policies of web-
enabled application services. Decision Support Systems, pp. 259-272.
CHEROBINO, V. (16 de Outubro de 2007). SaaS: Quatro letras para conquistar
as pequenas empresas. Acesso em 15 de Setembro de 2010, disponível em
ComputerWorld:
http://computerworld.uol.com.br/gestao/2007/10/16/idgnoticia.2007-10-
15.3940692242/
CHONG, F., & CARRARO, G. (Abril de 2006). Architecture Strategies for
Catching the Long Tail. Acesso em 21 de Maio de 2011, disponível em MSDN
Library: http://msdn.microsoft.com/en-us/library/aa479069.aspx
CHONG, F., CARRARO, G., & WOLTER, R. (Junho de 2006). Multi-Tenant
Data Architecture. Acesso em 21 de Maio de 2011, disponível em MSDN
Library: http://msdn.microsoft.com/en-us/library/aa479086.aspx
COMPUTERWORLD/EUA. (04 de Janeiro de 2011). Demanda por soluções de
BI no modelo SaaS aumentará em 2011. Computer World.
COUTO, V. (21 de Setembro de 2010). Software como serviço: modelo ganha
fôlego no País. Acesso em 23 de Setembro de 2010, disponível em
ComputerWorld:
http://computerworld.uol.com.br/tecnologia/2010/09/21/software-como-servico-
modelo-ganha-folego-no-pais/
Diário do Comércio. (28 de Setembro de 2010). Web Paper. Diário do
Comércio, p. 6.
DIGITAL INTELLIGENCE. (2011). O que é SaaS - Software as a Service?
Acesso em 13 de 08 de 2011, disponível em DigitalIntelligence:
http://www.digital-it.com.br/o_que_e_saas_software_as_a_service.html
DONG, J., ZHANG, S., SHI, Y., XU, X., & GUO, W. (09 de Agosto de 2010).
Process Customization Based on Dependent Topology in Software as a Service
Model. Software Engineering and Data Mining (SEDM), 2010 2nd International
Conference on, pp. 295-298.
42
GARTNER, INC. (2011). IT Glossary - SaaS. Acesso em 13 de 08 de 2011,
disponível em Gartner: http://www.gartner.com/technology/it-glossary/saas.jsp
IMHOFF, C. (Abril de 2010). Business Intelligence as a Service: Key Evaluation
Criteria for ISVs to Consider.
JUTRAS, C. (2009). A Fresh Lock at SAP's Software as a Service (SaaS)
Solution.
LI, H., SHI, Y., & LI, Q. (31 de Dezembro de 2009). A Multi-granularity
Customization Relationship Model for SaaS. Web Information Systems and
Mining, 2009. WISM 2009. International Conference on, pp. 611-615.
MA, D., & SEIDMANN, A. (2008). The Pricing Strategy Analysis for the
“Software-as-a-Service” Business Model. Springer-Verlag Berlin Heidelberg, pp.
103-112.
MARCONI, M., & LAKATOS, E. M. (2003). Fundamentos de Metodologia
Científica. São Paulo: Editora Atlas.
MELO, C. A., ARCOVERDE, D. F., MORAES, É. R., PIMENTEL, J. H., &
FREITAS, R. Q. (Março de 2007). Software como Serviço: Um Modelo de
Negócio Emergente. São Paulo, Pernambuco, Brasil: Centro de Informática -
Universidade Federal de Pernambuco.
MICROSOFT CORPORATION. (n.d.). Microsoft Software as a Service.
Retrieved 04 20, 2011, from Microsoft Software as a Service:
http://www.microsoft.com/serviceproviders/saas/default.mspx
PMSP. (2011). Nota Fiscal Eletrônica de Serviços - Manual de Utilização do
Web Service. Acesso em 18 de Maio de 2011, disponível em Prefeitura da
Cidade de São Paulo: http://ww2.prefeitura.sp.gov.br/nfe/files/NFe-Web-
Service-v2-2.pdf
PROGRESS SOFTWARE CORPORATION. (2008). SaaS Customization and
Personalization. Acesso em 19 de 07 de 2011, disponível em Progress
Software Corporation:
43
http://web.progress.com/docs/whitepapers/public/SaaS/SaaS-Usability--
Personalization.pdf
REDAÇÃO COMPUTERWORLD. (26 de Julho de 2010). SaaS crescerá 5
vezes mais rápido que venda de licenças. Acesso em 23 de Setembro de 2010,
disponível em ComputerWorld:
http://computerworld.uol.com.br/negocios/2010/07/23/saas-crescera-5-vezes-
mais-rapido-que-venda-de-licencas/
REDAÇÃO DA COMPUTERWORLD. (08 de Fevereiro de 2011). Disoft cria
unidade de ERP. Computer World.
SILVEIRA, G. (23 de Agosto de 2010). Um produto para muitos clientes:
implementando multitenancy. Acesso em 02 de Setembro de 2011, disponível
em blog.caelum.com.br: http://blog.caelum.com.br/um-produto-para-muitos-
clientes-implementando-multitenancy/
SOARES, E. (23 de Dezembro de 2010). Associações comerciais vão oferecer
solução de NFe por SaaS. Computer World.
SOARES, E. (18 de Maio de 2010). SaaS: SAP inicia testes de novo ERP no
Brasil ainda em 2010. Acesso em 23 de Setembro de 2010, disponível em
ComputerWorld: http://computerworld.uol.com.br/negocios/2010/05/18/saas-
sap-inicia-testes-de-novo-erp-no-brasil-ainda-em-2010/
SOUZA FILHO, F. (21 de Abril de 2009). Uma solução econômica que vem das
nuvens. Acesso em 23 de Setembro de 2010, disponível em Jornal Diário do
Comércio: http://www.dcomercio.com.br/materia.aspx?id=15517&canal=53
SPOSITO, R. (14 de Julho de 2008). Como usar bem o SaaS? Acesso em 16
de Setembro de 2011, disponível em Info CORPORATE:
http://info.abril.com.br/corporate/infraestrutura/como-usar-bem-o-saas.shtml
TAURION, C. (01 de 12 de 2010). Entendendo o modelo Multi-tenancy. Acesso
em 16 de 07 de 2011, disponível em iMasters:
http://imasters.com.br/artigo/19067/cloud/entendendo_o_modelo_multi-tenancy/
44
THIERAUF, R. J. (2001). Effective business intelligence systems. Quorum
Books.
UNICOMM. (30 de Outubro de 2010). SaaS é adequado para a minha
empresa? Acesso em 10 de Setembro de 2011, disponível em Unipress:
http://uni.com.br/knowledge_base/?p=694
VINÍCIUS, S. (23 de Novembro de 2010). De pacotes de escritório a HDs
virtuais, conheça os principais softwares grátis que dispensam instalação.
Diário do Comércio, p. 18.
WARFIELD, B. (23 de Outubro de 2007). Does SaaS Limit Over-
Customization? Acesso em 26 de Julho de 2011, disponível em SmoothSpan:
http://smoothspan.wordpress.com/2007/10/23/does-saas-limit-over-
customization/
WHAT IS. (05 de Abril de 2011). What is multi tenancy? Definition of
WhatIs.com. Acesso em 20 de Agosto de 2011, disponível em WhatIs - The
Tech Dictionary and IT Encyclopedia:
http://whatis.techtarget.com/definition/multi-tenancy.html
YCMI. (s.d.). The EAV/CR Model of Data Representation. Acesso em 10 de
Setembro de 2011, disponível em Yale Center for Medical Informatics:
http://ycmi.med.yale.edu/nadkarni/eav_cr_frame.htm
45
10. Apêndices
10.1. Apêndice A – Texto que conceitua SaaS
A seguir, um trecho que conceitua SaaS, extraído do livro SaaS 100 Success
Secrets, de Gerard Blokdijk (2008, p. 105) traduzido:
Você ainda lembra dos dias em que estava em frente a centenas de
CDs de novos softwares recém licenciados e dispositivos de
hardware, pensando em qual deles iria entrar orçamento, e se os
requisitos mínimos iriam compatibilizar com o seu computador? Você
ainda adere à ideia de ter que chamar os seus funcionários para
garantir que há backups todos os arquivos, para prevenir-se contra
perdas de dados por queda de energia?
Que tal ir à mais próxima loja de informática e comprar os mais
recentes patches e upgrades para manter os padrões de operações
de negócios? Graças aos céus você já pode deixar tudo isso para
trás. Se você está abrindo um negócio, ou já possui um, você vai
querer considerar a implantação de Softwares como Serviço (SaaS)
para facilitar todas as suas preocupações em um instante.
Sim, isso é verdade. Tudo o que você precisa ter é um computador
com internet e está tudo pronto. Não há necessidade de adquirir mais
hardwares ou softwares. Tudo está bem na sua frente, graças ao seu
confiável navegador.
O conceito é simples e você se preocupa apenas com seu negócio e
o fornecedor de SaaS cuidará do fluxo crítico de informações do seu
sistema. O legal dessa solução é que seus dados de importância
podem ser acessados a qualquer hora. Além disso, todos os
registros e informações são mantidos num servidor de alta
segurança, portanto pode ficar tranquilo que eles estão seguros. Por
último, assinar uma solução SaaS é muito acessível. Então pense
nisso. Assine agora e deixe o resto com o fornecedor.
46
11. Anexos
11.1. Anexo A – Relatório de respostas da pesquisa de formulário
Você já ouviu falar em software como serviço (SaaS) ou computação em
nuvem?
Figura 10. Gráfico de resposta – Você já ouviu falar em software como serviço (SaaS) ou
computação em nuvem?
Opção Respostas Porcentagem
Não
24 24%
Sim, mas não sei o que significa
10 10%
Sim, e sei do que se trata
68 67%
Você utilizaria um software que fica hospedado, juntamente com seus
dados, na infra estrutura do fornecedor, a troco de não precisar se
preocupar mais com TI (software e hardware)?
Figura 11. Gráfico de resposta – Você utilizaria um software que fica hospedado,
juntamente com seus dados, na infra estrutura do fornecedor, a troco de não precisar se preocupar mais com TI (software e hardware)?
Opção Respostas Porcentagem
Sim
50 49%
Posso cogitar
38 37%
Não
14 14%
47
"Assinaria" um software assim mesmo que seu fornecedor NÃO
prestasse nenhum tipo de customização, exceto as opções oferecidas
pela própria aplicação?
Figura 12. Gráfico de resposta – “Assinaria” um software assim mesmo que seu
fornecedor NÃO prestasse nenhum tipo de customização, exceto as opções oferecidas pela própria aplicação?
Opção Respostas Porcentagem
Sim
54 53%
Não
48 47%
A possibilidade de precisar de customizações, em um software não
customizável, causaria algum tipo de receio em você na hora de
"assinar", mesmo que ele te atenda perfeitamente no momento?
Figura 13. Gráfico de resposta – A possibilidade de precisar de customizações, em um
software não customizável, causaria algum tipo de receio em você na hora de "assinar", mesmo que ele te atenda perfeitamente no momento?
Opção Respostas Porcentagem
Sim
65 64%
Não, pois sei que novas necessidades
serão supridas.
29 28%
Não, de modo nenhum.
8 8%
48
Se você adquirisse um software, de qualquer natureza, para a empresa
onde trabalha, qual você crê ser a probabilidade de necessitar
customizações dentro de seis meses?
Figura 14. Gráfico de resposta – Se você adquirisse um software, de qualquer natureza, para a empresa onde trabalha, qual você crê ser a probabilidade de necessitar customizações dentro
de seis meses?
Opção Respostas Porcentagem
0 - Nula 3 3%
1
3 3%
2
4 4%
3
2 2%
4
2 2%
5
18 18%
6
12 12%
7
13 13%
8
20 20%
9
6 6%
10 - Com certeza 19 19%
![[E-book] - Gestão Avançada para SaaS](https://img.document.onl/doc/110x75/5872b2cd1a28ab523c8b5e47/e-book-gestao-avancada-para-saas.jpg)
