RESOLVENDO PROBLEMAS DE CUSTOMIZAÇÃO EM SOFTWARES COMO SERVIÇO (SaaS)

Transcrição

1 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

2 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

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

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

5 Í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) Figura 2. Categorias de modelo de isolamento em nível de Base de Dados. Fonte: (CHONG, CARRARO, & WOLTER, Multi-Tenant Data Architecture, 2006) Figura 3. Isolamento com bases de dados separadas. Fonte: (CHONG, CARRARO, & WOLTER, Multi-Tenant Data Architecture, 2006) Figura 4. Isolamento com schemas separados. Fonte: (CHONG, CARRARO, & WOLTER, Multi-Tenant Data Architecture, 2006) Figura 5. Dados coexistentes na mesma base e no mesmo schema. Fonte: (CHONG, CARRARO, & WOLTER, Multi-Tenant Data Architecture, 2006) Figura 6. Ilustração de gráfico da Long Tail. Fonte: Wikipédia Figura 7. Gráfico da Long Tail mapeando os públicos alcançáveis. (CHONG & CARRARO, Architecture Strategies for Catching the Long Tail, 2006) 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) Figura 9. Customização do modelo de dados por tabela extensível. Fonte: (CHONG & CARRARO, Architecture Strategies for Catching the Long Tail, 2006) Figura 10. Gráfico de resposta Você já ouviu falar em software como serviço (SaaS) ou computação em nuvem? 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)? 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? 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

6 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

7 Lista de Siglas ASP COTS CRM EAV ERP HTTP HTTPS PC RH SaaS SPED TI Application Service Provider Commercial off the Shelf Software Customer Relationship Management Entity Attribute Value Enterprise Resource Planning Hypertext Transfer Protocol Hypertext Transfer Protocol Secure Personal Computer Recursos Humanos Software as a Service Sistema Público de Escrituração Digital Tecnologia de Informação

8 Sumário 1. Introdução Considerações Gerais Caracterização do Tema Identificação do Problema Justificativa e Contribuição do Estudo Objetivos e Delimitação do Trabalho Hipóteses Metodologia Base Tecnológica do SaaS Definições do conceito SaaS Acesso via Navegador Multi Tenancy Isolamento de dados Multi Tenant Excelência Aspectos Mercadológicos Long Tail Mercado inviável para SaaS Customizações Cenário atual Customização do modelo de dados Campos customizados Customização de procedimentos Considerações gerais Análise das pesquisas de formulário Conclusão... 36

9 9. Referências Bibliográficas Apêndices Apêndice A Texto que conceitua SaaS Anexos Anexo A Relatório de respostas da pesquisa de formulário... 46

10 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: 9

11 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. 10

12 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. 11

13 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 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 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; 12

14 Apontar boas técnicas de oferecer customizações, de forma adequada, às aplicações SaaS 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. 13

15 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 14

16 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. 15

17 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 Services 1 ). 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. 16

18 é 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 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 17

19 através de certificados digitais (PMSP, 2011), do modo como faz os aplicativos que compõem o SPED 2, em várias prefeituras e secretarias da fazenda estatuais. É fortemente característico das aplicações SaaS uma arquitetura multi tenancy 3, 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) 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. 18

20 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 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). 19

21 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. 20

22 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 21

23 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. 22

24 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 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 . Isso requer uma arquitetura que otimize o compartilhamento de recursos entre os usuários, mas imprescindivelmente capaz de diferenciar os dados de cada um. 23

25 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. 24

26 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 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 bestsellers. 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. 25

27 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) 26

28 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.) 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). 27

29 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. 28

30 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á- 29

31 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 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. 30

32 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 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); 31

33 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 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 32

34 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 33

35 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 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). 34

36 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: ou ainda, 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. 35

37 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-premise 4, 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. 36

38 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á 37

39 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 38

40 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. 39

41 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: 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: 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: 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: bi 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: 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: CARVALHO SOUSA, F. R. (Maio de 2010). Acesso em 16 de Setembro de 2011, disponível em Universidade Federal do Ceará: CERVO, A., & BERVIAN, P. (1978). Metodologia Científica. Mcgraw-hill. 40

42 CHENG, H. K., & KOEHLER, G. J. (2003). Optimal pricing policies of webenabled application services. Decision Support Systems, pp 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: / 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: 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: COMPUTERWORLD/EUA. (04 de Janeiro de 2011). Demanda por soluções de BI no modelo SaaS aumentará em 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: 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: 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), nd International Conference on, pp

43 GARTNER, INC. (2011). IT Glossary - SaaS. Acesso em 13 de 08 de 2011, disponível em Gartner: 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, WISM International Conference on, pp MA, D., & SEIDMANN, A. (2008). The Pricing Strategy Analysis for the Software-as-a-Service Business Model. Springer-Verlag Berlin Heidelberg, pp 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: 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: 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: 42

44 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: 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: 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 Acesso em 23 de Setembro de 2010, disponível em ComputerWorld: 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: SPOSITO, R. (14 de Julho de 2008). Como usar bem o SaaS? Acesso em 16 de Setembro de 2011, disponível em Info CORPORATE: TAURION, C. (01 de 12 de 2010). Entendendo o modelo Multi-tenancy. Acesso em 16 de 07 de 2011, disponível em imasters: 43

45 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: 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: 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: 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: 44

46 10. Apêndices 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. 45

47 11. Anexos 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% 46

48 "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 % Não, de modo nenhum. 8 8% 47

49 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% % % % % 9 6 6% 10 - Com certeza 19 19% 48