saas: análise de impacto na transformação da investigação ... · saas: análise de impacto na...
Post on 12-Dec-2018
220 Views
Preview:
TRANSCRIPT
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
Vitor Pedro Figueiredo de Pinho
Relatório de Dissertação na Sage Portugal S.A.
Orientador na FEUP: Professor Doutor António Lucas Soares
Orientador na Sage Portugal: Dr. Jorge Santos Carneiro
Faculdade de Engenharia da Universidade do Porto
2009-07-20
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
ii
Para a Paula e para a Sofia
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
iii
Resumo
As actuais transformações do mercado no domínio do Software de Gestão Empresarial têm
permitido colocar em evidência a crescente tendência para a adopção do modelo SaaS -
Software as a Service.
Perante este cenário, os produtores de software tradicional têm vindo a ser interpelados a
adaptarem-se construtivamente aos desafios que esta realidade implica num quadro
diversificado de segmentos de mercado, bem como em áreas específicas de negócio.
Deste modo, a mudança de paradigma do fornecimento de produtos para serviços implica um
complexo processo de ajustamento e adaptação organizacional, com impactos em toda a
organização e, muito particularmente, nas equipas de Investigação e Desenvolvimento.
O trabalho realizado identifica os principais factores de impacto para a equipa de
desenvolvimento da Sage Portugal, detalhando o contexto onde estão inseridos e a sua relação
com a restante organização.
Complementarmente, identificam-se os principais desafios emergentes neste âmbito e
procede-se à elaboração de um quadro de medidas com potencialidade para aumentar a
capacidade de resposta organizacional face às necessidades de adaptação e de ajustamento
decorrentes do confronto com a mudança de paradigma em análise.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
iv
SaaS: Impact analysis on transformation of product research and development for
services
Abstract
The current market changes in the Business Management Software field have highlighted the
growing trend towards the adoption of the SaaS (Software as a Service) model.
Given this scenario, the producers of traditional software are pushed to adapt constructively to
the challenges that this fact implies in a variety of market segments, as well as in specific
areas of business.
Thus, the paradigm shift from the supply of products to the supply of services involves a
complex process of organizational adjustment, with impacts across the organization,
particularly in the R&D teams.
The work identifies the main impact factors on the development team of Sage Portugal,
detailing where they fit the context and their relationship with the rest of the organization.
In addition, it identifies the main challenges in this field and proceeds to the establishment of
a set of measures with potential to increase the organizational capacity to respond to the needs
of adaptation and adjustment arising from the confrontation with the change of paradigm
under analysis.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
v
Agradecimentos
Em primeiro lugar gostava de agradecer à minha família por me ter proporcionado todas as
condições para realização do trabalho.
Queria agradecer aos orientadores da dissertação, ao Professor Doutor António Lucas Soares
pela ajuda na concretização dos assuntos a abordar e por todo o apoio prestado na organização
das ideias. Ao Dr. Jorge Santos Carneiro, pelos ensinamentos ao longo da minha vida
profissional, que muito contribuíram para este trabalho.
Quero ainda agradecer aos meus amigos Sérgio Fabela e Jorge Morais pela disponibilidade e
pelo contributo na revisão do texto final.
Agradeço também à Dr.ª Maria Antónia Costa por todo o incentivo que me deu para a
realização do Mestrado em Engenharia de Serviços e Gestão.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
vi
Índice de Conteúdos
1 Introdução ........................................................................................................................................... 1
1.1 Introdução ao Software as a Service ................................................................................................... 1
1.2 Enquadramento, motivação e objectivos ............................................................................................. 2
1.3 Abordagens e metodologias ................................................................................................................. 4
1.4 Estrutura da dissertação ...................................................................................................................... 5
2 Estado da Arte ..................................................................................................................................... 7
2.1 O mercado de Software as a Service ................................................................................................. 10
2.2 As núvens (Clouds) ou Plataformas de Serviços ............................................................................... 10
3 Impacto do Software as a Service no modelo de negócio ................................................................ 12
3.1 Importância da garantia de níveis de serviço (SLAs) ......................................................................... 12
3.2 Responsabilidade sobre a informação dos clientes ........................................................................... 13
3.3 Aspectos legais a considerar ............................................................................................................. 16
3.4 Modelo de Licenciamento e Preços ................................................................................................... 17
3.5 Impacto na relação com o canal de revenda...................................................................................... 18
3.6 Impacto nas Operações ..................................................................................................................... 22
3.7 Novos desafios para o Marketing ....................................................................................................... 23
4 Impacto do modelo SaaS na Engenharia de Software ..................................................................... 25
4.1 Aspectos gerais a ter em conta na construção de uma aplicação SaaS ............................................ 25
4.2 Tecnologias emergentes para o desenvolvimento SaaS ................................................................... 26
4.3 Engenharia de software baseado em serviços ................................................................................... 28
4.4 Processo de desenvolvimento ........................................................................................................... 29
4.5 Arquitectura de bases de dados Multi-Tenant .................................................................................... 34
4.6 Interface com o utilizador em aplicações SaaS .................................................................................. 36
5 Quadro de medidas ........................................................................................................................... 39
5.1 Enquadramento geral e motivação para o investimento .................................................................... 39
5.2 Preparação interna ............................................................................................................................. 40
5.3 Impacto financeiro provocado pelo novo modelo de remuneração .................................................... 40
5.4 Barreiras culturais .............................................................................................................................. 41
5.5 Remuneração dos Parceiros e da Equipa de vendas ........................................................................ 41
5.6 Plano de Risco ................................................................................................................................... 41
5.7 Preparação dos serviços de suporte .................................................................................................. 42
5.8 Preparação da equipa de R&D .......................................................................................................... 43
6 Conclusões e perspectivas de trabalho futuro .................................................................................. 45
Referências e Bibliografia ...................................................................................................................... 48
Anexo A : Legislação portuguesa a respeito da protecção de dados pessoais e preservação
de documentos fiscais ....................................................................................................................... 50
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
vii
Índice de Figuras
Figura 1- Serviços e Produtos de Software ............................................................................... 9
Figura 2 – Processo de desenvolvimento de software como produto....................................... 30
Figura 3 - Arquitectura do sistema de base de dados .............................................................. 34
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
viii
Lista de abreviaturas e acrónimos
SaaS: “Software as a Service” Modelo de fornecimento de software onde a aplicação é
alojada e disponibilizada aos clientes como um serviço através da Internet.
R&D: “Research and Development” Departamento de Investigação e Desenvolvimento de
produtos e serviços.
E-marketplace: “acrónimo da sigla inglesa Electronic marketplace”, é um espaço virtual
onde se faz comércio electrónico no sentido mais lato
Web Service: É uma solução utilizada na integração de sistemas e na comunicação entre
aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir
com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam
compatíveis.
VAR: É uma empresa que adiciona funcionalidades a produtos existentes e vende e vende o
produto ao cliente final como um produto integrado, ou solução “chave na mão”.
SOA: Service-oriented architecture: É um tipo de arquitectura de software cujo princípio
fundamental preconiza que as funcionalidades implementadas pelas aplicações devem ser
disponibilizadas na forma de serviços.
Browser: Programa de computador que habilita os seus utilizadores a interagir com
documentos na Internet, também conhecidos como páginas HTML, que estão hospedadas
num servidor Web.
Major Releases: Versões principais de um dado produto de software.
Cash Flow: É um termo referente ao montante monetário recebido e pago pela empresa num
determinado período de tempo pré definido. É utilizado para avaliação do estado de um
negócio ou projecto específico.
Software On-Premises: Software executado localmente, vendido no modelo tradicional de
compra de licenças.
Software Off-Premises: Software executado remotamente, normalmente alugado como um
serviço; sinónimo de Software as a Service (SaaS)
CAGR (Compound Annual Growth Rate): Termo de investimento que representa a taxa de
crescimento anual durante um período pré-definido.
SLA: Acordo preparado e traduzido para um documento de contrato assinado entre o cliente e
o fornecedor de um serviço que estabelece as condições e obrigações entre as partes.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
1
1 Introdução
1.1 Introdução ao Software as a Service
O Software as a Service (SaaS), não pode ser perspectivado enquanto conceito totalmente
novo, atendendo a que no passado existiram várias abordagens onde a ideologia subjacente
era muito semelhante ao que hoje chamamos SaaS. Apesar de existirem múltiplas definições
para o SaaS na literatura, este conceito pode ser caracterizado pela existência de software,
passível de ser fornecido directamente através de uma infra-estrutura de servidores remotos e
disponibilizado aos seus clientes, normalmente via browser através da Internet. [1]
O modelo “puro" SaaS, baseia-se em aplicações Multi-tenant, ou seja, em aplicações cuja
arquitectura permite a execução de uma única instância da aplicação, que serve vários
clientes, neste caso inquilinos do sistema. Estas aplicações são desenhadas de forma nativa
para a Web, utilizando tecnologias semelhantes às usadas no desenvolvimento de web sites
tradicionais, com as normais preocupações de desenvolvimento em ambientes de fraca
conectividade.
Existem ainda algumas derivantes do modelo, como por exemplo o conceito S+S da
Microsoft™, onde permanece o software instalado na máquina do cliente, e a informação é
sincronizada entre o cliente e os serviços alojados remotamente. Alguns produtores,
atendendo à necessidade de criarem interfaces específicos com os clientes, optam por
disponibilizar o software fora do browser, apesar de manterem na sua essência os
fundamentos do SaaS.
O SaaS è encarado como uma mudança disruptiva em relação ao modelo tradicional de
fornecimento de software. O modelo negócio das empresas que fornecem software tradicional
tem vindo ao longo do tempo a sofrer várias mutações. Hoje em dia, a grande maioria dos
produtores, apresenta ao mercado serviços de manutenção, que para além de garantirem
formação e assistência técnica, possibilitam o acesso a todas as novas revisões do produto
durante o período de vigência do contrato. Apresentam também uma oferta complementar de
serviços que extravasa o âmbito do produto e abrange várias áreas colaterais, como IT,
marketing, gestão, contabilidade, áreas de especialização vertical entre outros. Esta mutação é
provocada por um lado pela necessidade de abrir novos mercados, mas essencialmente pela
importância de criar mecanismos de facturação recorrente com vista a uma maior
previsibilidade do negócio e aumento de Cash Flows.
Neste contexto, os produtos passam a ser mais uma linha no orçamento anual, e não a única
fonte de receita a sustentar todo o negócio. A forma dos produtores de software tradicional
motivarem os clientes a manter activos os seus contratos de serviço, passa obviamente pela
qualidade e relevância dos serviços prestados, mas também pelas melhorias incrementais
introduzidas nos produtos ao longo do tempo e o impacto positivo que possam trazer para o
negócio dos clientes. Como consequência, assistimos a uma tendência clara para o aumento
da frequência de entrega de novas funcionalidades ao mercado. Se no passado era normal um
produtor ter um ciclo bianual ou anual de lançamento de Major Releases, hoje em dia, apesar
de por motivos de marketing ser mantido o lançamento de uma versão de maior destaque com
periodicidade alargada, é normal o lançamento trimestral, ou mesmo mensal de novas
funcionalidades nos produtos.
O aumento da frequência de lançamento de novas versões, provoca necessariamente um
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
2
impacto negativo nos parceiros de negócio, nos responsáveis de IT e muitas vezes nos
próprios clientes. O SaaS, pela sua essência resolve este problema e liberta todo o trabalho de
distribuição e instalação dos produtos localmente nos clientes. As melhorias são introduzidas
de uma forma constante, numa lógica chamada de “eternos Beta”, ou software continuamente
em desenvolvimento, sem nunca chegar realmente a uma versão terminada para entrar em
produção.
O modelo SaaS, encoraja as empresas à sua utilização por vários factores:
Os custos de IT são manifestamente inferiores
Sendo um aluguer, o software não constitui um activo fixo para a empresa
O serviço pode ser adequado constantemente às necessidades do cliente, com modelos
de licenciamento mais versáteis,
Existe uma relação directa com o produtor e qualquer problema pode ser resolvido
sem partilha de responsabilidades
A utilização è ubíqua, ou seja, produto pode ser acedido a partir de qualquer ponto
com acesso internet
1.2 Enquadramento, motivação e objectivos
O estudo proposto tem como objectivo identificar e explorar os factores de impacto
organizacional, provocados pela mudança do modelo tradicional de produção e
comercialização de software, para um modelo de fornecimento de software como serviço
(SaaS - Software as a Service) através da Internet. O trabalho foi desenvolvido no contexto da
empresa Sage Portugal S.A..
Sobre a Sage Portugal
A Sage Portugal S.A. integra o Grupo Sage, líder mundial no desenvolvimento de software de
gestão e serviços para pequenas e médias empresas (PME). A Sage Portugal dispõe de uma
ampla oferta de produtos e serviços desenvolvidos para o mercado nacional e de acordo com a
dimensão das empresas, tem uma capacidade acrescida para responder, de forma adequada, às
necessidades dos seus clientes. A Sage Portugal, possui actualmente uma equipa de 150
colaboradores, mais de 80 mil utilizadores e uma rede de mil parceiros, apresenta uma gama
variada de produtos desenhados para suprir todas as necessidades de gestão das PME
portuguesas.
Aliado ao forte crescimento orgânico dos últimos anos, a Sage Portugal tem crescido também
por via das aquisições, das quais se destacam a Infologia, a SP, a Gestexper, a Adonix, o
Orçam, solução para o mercado da Construção Civil e Obras Públicas, a Escripóvoa, com
soluções para o mercado do Retalho e mais recentemente a XRT, com soluções de gestão de
tesouraria. 1
1 Mais detalhes em www.sage.pt
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
3
Sobre o Grupo Sage
O Grupo Sage é, há mais de duas décadas, o parceiro de software de gestão preferido pelas
pequenas e médias empresas em todo o mundo. A liderança mundial do Grupo SAGE,
presente na Europa, América do Norte, África e Ásia, deve-se à elevada capacidade de
resposta com que satisfaz as necessidades, cada vez mais amplas e diversificadas, das várias
áreas de negócio que abrange com as soluções globais e integradas de software de gestão.2
Actualmente, com a função de Direcção do Departamento de Investigação e Desenvolvimento
da Sage Portugal S.A., tem como responsabilidade a identificação de tendências tecnológicas
no mercado e a preparação interna da empresa para os novos desafios no desenvolvimento de
software.
O reconhecimento da tendência de adopção do modelo SaaS em alguns segmentos de
mercado, com especial destaque para o mercado de entrada e em áreas verticais relevantes, foi
um dos principais factores de influência no interesse pela Engenharia de Serviços e Gestão.
O desenho e fornecimento de serviços, embora partilhe o mesmo tronco comum e tenha
preocupações semelhantes ao desenvolvimento de produtos, deve ser encarado com todas as
suas diferenças sem menosprezar os aspectos fundamentais intrínsecos à sua essência.
A construção de um serviço, deve ter preocupações de desenho tendo em conta aspectos
como:
Pontos de espera
Pontos de falha
Gestão de expectativas dos clientes
Planos de recuperação em caso de falha
Evidência física no teatro de operações
Entre outros …
Depois da entrada em produção, a monitorização constante dos indicadores de eficiência de
serviço, a melhoria contínua baseada na relação com os clientes, a interacção permanente do
prestador com o consumidor são factores determinantes do sucesso e radicalmente diferentes
dos esperados, apenas pela adequação e bom funcionamento de um produto.
Antes do percurso académico do MESG, imaginava que estas diferenças existissem,
conseguia identificar alguns aspectos do conhecimento comum, mas não detinha os
fundamentos devidamente sistematizados nem as ferramentas adequadas para o desenho
profissional de um serviço.
Actualmente, os produtos desenvolvidos no Departamento de R&D da Sage Portugal estão
instalados em cerca de 80.000 empresas em Portugal. Por mais pequena que seja a adopção a
2 Mais detalhes em www.sage.com
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
4
um software desenvolvido em modelo SaaS, servirá necessariamente como solução de gestão
para centenas de empresas. Este tipo de clientes confiará totalmente os seus dados e
dependerá da eficiência do serviço para o bom funcionamento de processos críticos de
negócio.
Esta mudança de paradigma, tem necessariamente que ser encarada de uma forma
profissional, tendo em conta todos os aspectos que possam afectar directa ou indirectamente a
Sage Portugal, os seus clientes e parceiros.
Objectivos específicos
Para analisar o impacto na transformação investigação e desenvolvimento de produto para
serviços, o trabalho será dividido em dois eixos de análise principais, com objectivo de
conseguir uma maior abrangência sistémica e consequentemente maior amplitude relacional:
1) Análise do impacto no modelo de negócio, explorando as várias vertentes da
organização e a sua relação com a área de I&D
2) Análise de impacto na área de I&D, em particular nos aspectos relacionados com a
Engenharia de Software
Por fim, apresentará uma proposta de medidas para fazer face aos desafios decorrentes desta
forte tendência de mercado, na eventualidade da empresa decidir pelo investimento no
modelo.
1.3 Abordagens e metodologias
O impacto na transformação do modelo para um produtor de software tradicional é sentido
nas mais variadas áreas da empresa:
a) Na produção através de um paradigma totalmente diferente para o processo de
desenvolvimento de produtos, testes e entrada em produção de novas versões; novos
requisitos não funcionais relacionados com a tecnologia; novos desafios na
escalabilidade e segurança das soluções entre outros.
b) No marketing através da escolha de requisitos baseada na análise da utilização real das
aplicações; a gestão de expectativas e da relação directa com o cliente através da Web;
c) Na área Comercial com um conjunto de regras diferentes para o canal de revenda e
preços de serviço baseados na utilização;
d) Na área financeira onde será por um lado mais simples o controlo de cobranças, mas
onde existe um aumento da complexidade nas variáveis de facturação.
Para os clientes, esta mudança de paradigma obriga a repensar prioridades estratégicas e
definir novas formas de organização empresarial. A importância dada à gestão interna de
sistemas é reduzida, mas por outro lado tem que existir uma preocupação acrescida na
garantia de um sistema de comunicação fiável e resistente a falhas e de acordos de nível de
fornecimento de serviço que comprometam os fornecedores com a disponibilidade da solução.
Uma falha de conectividade ou a indisponibilidade do sistema do fornecedor podem significar
uma paragem imediata de operações.
Todos estes factores requerem uma profunda reflexão, baseada em informação devidamente
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
5
sistematizada para apoio na tomada das melhores decisões estratégicas de médio e longo
prazo.
Um produtor de software como a Sage Portugal, com um modelo de negócio muito baseado
em serviços que gravitam sobre uma base de produtos comercializada actualmente pelo
processo normal de distribuição de software, poderá desenvolver uma das seguintes
abordagens:
1) Ignorar o modelo SaaS e continuar a distribuir software da forma tradicional,
incorporando no entanto alguns serviços que ajudam a fidelizar clientes com contrato;
2) Transitar do modelo tradicional para o modelo 100% SaaS, e reestruturar toda a
actividade para o fornecimento de software apenas através da Internet;
3) Optar por um modelo misto, onde oferece as duas soluções aos clientes (utilização
local ou remota), ou então aplicar o modelo SaaS apenas numa área de negócio;
Sem dúvida que a opção três será a que acarreta menor risco, pelo menos a curto prazo, mas
será também a que traz maiores custos para a empresa, com a manutenção em paralelo do
desenvolvimento de dois tipos de soluções.
Atendendo a que esta área de investigação apresenta lacunas significativas ao nível do seu
desenvolvimento em Portugal, o desenho da investigação é estruturado como um estudo
sociológico convencional.
O trabalho mobiliza o estudo de casos que reflectem experiência em organizações e conjuga
essa informação com a revisão da literatura científica sobre este novo paradigma. O resultado
final permite colocar em evidência os principais problemas ao nível da Investigação e
Desenvolvimento e sugere um plano de acções de forma a minimizar os aspectos negativos do
confronto com esta nova realidade.
1.4 Estrutura da dissertação
No Capítulo de Introdução, apresenta-se um sumário sobre o conceito de Software as a
Service e a sua comparação com o modelo de distribuição tradicional de software.
Complementarmente procede-se à explicação dos objectivos do trabalho a motivação e o
contexto onde foi desenvolvido.
O Capítulo 2, estado da arte, descreve em detalhe a componente teórica que suporta a
investigação. É realçado particularmente o tema SaaS – Software as a Service, em primeiro
lugar a perspectiva histórica com uma abordagem conceptual sobre os fundamentos do
modelo. Seguidamente são apresentados diferentes estudos que sustentam a tendência de
mercado para adopção do SaaS e procede-se à identificação dos segmentos com maior
influência. Complementarmente é explorado o conceito de plataforma de serviços (Clouds)
com os aspectos mais relevantes sobre este tipo de infra-estruturas e quais os principais
operadores neste novo mercado em ascensão.
O Capítulo 3 aborda o impacto do Software as a Service no modelo de negócio, salientando
aspectos como a nova forma de licenciamento dos produtos em aluguer e respectivo impacto
financeiro, a relação com o canal de revenda e outros parceiros de negócio, as vantagens e a
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
6
responsabilidade acrescida decorrente da proximidade entre o produtor e os sues clientes. Na
perspectiva do cliente, é dado um especial destaque à confiança de toda a sua informação e
aspectos legais relacionados, a total dependência do fornecedor da solução e as principais
mudanças sentidas na organização.
O Capítulo 4 explora os principais aspectos sobre o impacto da mudança para o modelo SaaS
no processo de desenvolvimento de produtos. Os factores de impacto são analisados sobre
várias perspectivas: o processo de desenvolvimento; a infra-estrutura, ou plataforma
tecnológica, tendo em conta as suas responsabilidades, características e ferramentas; os
requisitos não funcionais exigidos neste tipo de aplicações; a preparação e organização da
equipa de desenvolvimento e por fim os aspectos relacionados com a integração de soluções e
os novos desafios colocados à Investigação e Desenvolvimento.
A estratégia de fornecimento de aplicações através do modelo SaaS não pode ser encarada
pela organização numa perspectiva meramente técnica. O modelo obriga necessariamente
uma reorganização de toda a empresa para a venda de serviços. Esta mudança, pela sua
abrangência terá que ser encarada desde a direcção de topo e posteriormente disseminada por
todas as áreas operacionais, mesmo que se trate de uma adopção parcial por parte de uma
dada unidade de negócio.
Tendo em conta os aspectos de negócio e os aspectos técnicos abordados nos Capítulos 3 e 4,
o Capítulo 5 apresenta uma proposta de plano de acção, focalizando-se nas áreas mais
afectadas em cada departamento e sugerindo um quadro de medidas com vista à preparação
organizacional para adopção do modelo SaaS.
O Capítulo 6, Conclusões e perspectivas de trabalhos futuros, resume as ideias principais
exploradas ao longo do trabalho, com especial destaque para a sistematização dos objectivos
específicos propostos. Por fim apresenta um resumo com a visão pessoal sobre as principais
vantagens e desvantagens sobre investimento no modelo de negócio SaaS para o Software de
Gestão para Pequenas e Médias Empresas.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
7
2 Estado da Arte
A disponibilização de software como um serviço em modelo de aluguer, foi sendo
classificada ao longo dos tempos através de diversas designações de mercado – Application
Service Provider (ASP), Internet Business Service (IBS), Application Infrastructure Providers
(AIPs), Solution Service Provider (SSP), Business Service Provider (BSP), mas nunca com a
abrangência e importância dada actualmente ao termo SaaS [2].
A SIIA (Software & Information Industry Association), ao identificar uma tendência na
adopção de várias formas de aluguer de aplicações e representando tanto os produtores de
software tradicional “On-Premises” (software executado localmente), como os produtores
emergentes no modelo de aluguer, desenvolveu o Strategic Backgrounder [2], numa tentativa
de analisar o estado do mercado e antecipar o impacto do modelo SaaS para os membros da
associação. Esta preparação dos ISVs segundo o autor, poderia passar por construir novas
versões de produtos preparadas para o aluguer, ou formar parcerias no sentido de criar uma
oferta SaaS para os clientes.
Apesar do conceito SaaS ter circulado antes de 2001, o documento Strategic Backgrounder da
SIIA, esteve na génese da sua expansão e divulgação, que foi inicialmente difundido na sua
forma tradicional com a primeira e última letra em maiúsculas em Fevereiro de 2001. [3]
O conceito foi incorporado na indústria de software e representa hoje uma importante
tendência de mercado que deve ser acompanhada pelos principais produtores, consumidores,
analistas e investigadores. O SaaS representa uma mudança fundamental no mercado de
software, tratando-se ao mesmo tempo de uma alteração profunda em relação ao modelo
tradicional On Premises [4].
O termo até então mais utilizado para definir o modelo de aluguer de software era designado
por ASP (Application Service Provider), caracterizado pelo IDC que se referia a empresas
com um conjunto bem definido de características:
Application centric: o negócio principal é o fornecimento de um serviço de acesso e a
gestão de aplicações;
Uma empresa ASP vende o acesso às aplicações, sem que o cliente tenha necessidade
de comprar uma licença de utilização perpétua;
Gestão centralizada: a gestão das aplicações é feita a partir de um único local e não
em casa de cada cliente
Serviço um para muitos, ou seja existe um único serviço é desenhado para vários
clientes
Podem existir vários fornecedores intervenientes, mas o ASP tem a responsabilidade
da qualidade do serviço contratualizado pelo cliente
Actualmente, por não existir uma definição clara do modelo, várias empresas se intitularam de
ASP, mesmo não cumprindo os requisitos definidos no conceito do IDC e foi criada uma
enorme confusão no mercado [2]. Aliado à fraca maturidade tecnológica e ás excessivas
expectativas criadas nos clientes sobre o modelo de aluguer, esta confusão foi certamente um
dos factores que mais influenciou a descredibilização do termo ASP.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
8
Quais os factores diferenciadores e as características do modelo SaaS?
Existem diferenças consideráveis do conceito SaaS relativamente ao ASP ou a qualquer um
dos outros anteriormente referidos. A principal diferença reside na arquitectura da solução.
Enquanto que num modelo típico ASP, o cliente compra uma aplicação e instala essa
aplicação num servidor alugado de uma forma isolada, o chamado (Sigle-Tenant model), uma
aplicação SaaS:
utiliza um modelo (Multi-Tenant), ou seja, a mesma infra-estrutura de hardware e
software é partilhada por um conjunto de utilizadores, mas existe uma única instância
da aplicação para todos os utilizadores (os inquilinos) do sistema [2].
aplicam o conceito e-commerce em alternativa ao modelo Outsourcing defendido pelo
ASP;
enfatiza a capacidade e a necessidade de aplicação massiva de personalizações;
é um modelo de negócio coerente no que diz respeito à apropriação e criação de valor,
enquanto que o ASP é mais uma terminologia tecnológica. [5]
Apesar dos avanços nas tecnologias, linguagens de programação e ambientes de
desenvolvimento, o paradigma utilizado para a construção e manutenção de software pouco
alterou desde os anos 60. A internet alargou a abrangência da visão conceptual sobre o que
entendemos como software. As práticas aplicadas ao desenvolvimento de Web Sites não são
muito diferentes das aplicadas na construção de software [6]. As melhores práticas de
desenvolvimento de software colocam o foco na satisfação das reais necessidades do cliente.
O papel do software focaliza-se na disponibilização de um serviço. Mudando o foco para a
descrição e entrega desse serviço em vez de fornecer software, podemos libertar-nos dos
constrangimentos impostos pelos modelos “tradicionais” de desenvolvimento de aplicações e
configurar o pensamento para os cenários e experiências de utilização mais adequados[6]
Criação de valor para os clientes
Do ponto de vista da criação de valor para o cliente, são possíveis de identificar três tipos de
categorias de soluções:
projectos de software, total ou parcialmente personalizados para os requisitos do
cliente;
produtos de software, sem nenhum tipo de personalização e orientados para o mercado
de massas;
serviços de software, com um certo grau de personalização e muito pensados para os
requisitos dos clientes.
Como podemos ver na figura 1, existe uma tendência de fusão entre o conceito de produto de
software e serviço de software. A tendência actual na indústria de produtos de software é,
como o autor refere a “servicization” das soluções de software, ou Software as a Service. [7]
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
9
Os riscos e os benefícios do modelo SaaS para o fornecedor
Lassila et al [5] refere como muito importante a capacidade de estabelecer parcerias para o
sucesso no modelo SaaS. As competências necessárias para o fornecimento de uma solução
SaaS, dado o tipo de tecnologias e as diferenças para o modelo tradicional são difíceis de
adquirir, mesmo para os maiores produtores.
O autor apresenta ainda uma matriz adaptada sobre os maiores riscos benefícios do modelo
SaaS na perspectiva do produtor da solução.
Benefícios para o fornecedor SaaS Riscos para o fornecedor SaaS
1) O modelo SaaS permite economias de
escala, tanto na produção como na
distribuição (Oferta um para muitos)
1) A gestão da rede de fornecedores que
permite a integração do negócio de produtos
e serviços é complexa
2) No modelo SaaS os Cash Flows são
mais previsíveis do que na venda de
software tradicional (receitas
recorrentes)
2) A mudança para o modelo SaaS
inicialmente provoca uma redução de
rentabilidade, porque as receitas entram
diferidas por períodos mensais ou trimestrais
3) O modelo SaaS expande o potencial
de base instalada
3) É expectável a ocorrência de problemas de
performance e escalabilidade, dependendo da
solução técnica utilizada
4) O ciclo de vendas dos serviços SaaS é
mais curto do que o do software
tradicional
4) Risco de investimento inicial na infra-
estrutura para arranque do negócio SaaS e
custo de aquisição de software de terceiras
partes
5) O SaaS diminui os custos de gestão e
manutenção de versões
5) A personalização de soluções SaaS
geralmente tem maiores custos
6) Com uma integração bem sucedida de
produtos e serviços numa oferta SaaS,
o fornecedor cria barreiras à entrada
para novos concorrentes
6) É necessário um compromisso para maior
frequência de distribuição de versões
Figura 1- Serviços e Produtos de Software
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
10
2.1 O mercado de Software as a Service
O mercado de Software as a Service está a desenvolver-se para uma vasta gama de aplicações
como: e-mail; Recursos Humanos; CRM (Customer Relationship Management); BI (Business
Inteligence) entre outras. [8]
De acordo com o Gartner [8], o mercado estará em rápido crescimento nos próximos anos,
pelo que o autor explicita que as tendências para o SaaS são:
Em 2009, 100% das principais empresas de consultoria estarão a desenvolver
estratégias SaaS;
Em 2010, 20% das empresas que desenvolvem soluções de e-commerce estarão a
utilizar um modelo de entrega SaaS;
Em 2010, 15% das empresas de grande dimensão estarão a ponderar projectos para
substituição dos ERPs para soluções baseadas em SaaS;
Em 2010, 85% dos fornecedores SaaS estarão a disponibilizar níveis de serviço com
um uptime mínimo de 99.5% nos contratos standard assim como SLAs (Service level
agrements) de performance;
Em 2011, 25% dos negócios novos de software serão SaaS;
Em 2012, a oferta de BPMSs (Business Process Management Systems) estará
embebida em 40% das ofertas SaaS;
Em 2012, mais de 66% dos ISVs (Independent Software Vendors) estarão a oferecer
parte dos serviços em SaaS.
Os números referidos pelo Gartner não serão certamente extrapoláveis para o mercado
Português, mas manifestam uma tendência sobre o amento de relevância deste modelo de
distribuição de software.
Um estudo recente do Gartner, [9] Market Trends: Software as a Service, Worldwide, 2008-
2013 indica que a adopção ao Software as a Service continua a crescer e a evoluir no mercado
de software empresarial. As razões citadas para esta evolução incluem o constrangimento
orçamental na actual conjuntura de crise económica e o aumento de popularidade das
plataformas de serviços ou Cloud Computing.
O relatório destaca principalmente:
As soluções de escritório e desenvolvimento de conteúdos que continuam com um
crescimento rápido, embora a partir de uma base de pequena dimensão.
Os mercados de conteúdos, comunicação e colaboração continuam a demonstrar a
mais alargada disparidade de geração de lucros em SaaS
A adopção do SaaS no mercado dos ERPs e SCM varia consoante a complexidade dos
processos.
O Mercado de CRM exibe uma adopção mais generalizada, entre 9% e mais de 33%
do total de receitas em software, dependendo da secção de CRM. Globalmente, 18%
das receitas no mercado CRM foram conseguidas no modelo SaaS em 2008.
2.2 As núvens (Clouds) ou Plataformas de Serviços
O termo Cloud Computing refere-se tanto ás aplicações distribuídas enquanto serviços através
da Internet, como ao Hardware e ao Software de sistema existente nos datacenters para servir
de suporte ao fornecimento desses serviços. Aos serviços, foi atribuida a designação SaaS,
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
11
enquanto que ao Hardware e Software de sistema foram chamadas Clouds ou Núvens. [10]
“De um ponto de vista mais formal, uma Cloud pode ser definida como: um tipo de sistema
paralelo e distribuído que consiste num conjunto de computadores virtualizados e
interligados que é gerido dinamicamente e apresentado como um ou mais recursos baseados
em contratos de serviço negociados entre o fornecedor do serviço e os seus
consumidores.”[11]
Quando as Clouds disponibilizadas ao público em geral são denominadas Public Clouds e se
derem suporte a aplicações SaaS vendidas no modelo de pagamento segundo utilização, como
por exemplo os serviços de comunicação ou a factura da água, o conjunto é chamado Utility
Computing. As Clouds de utilização privada para os serviços de uma determinada empresa
são denominadas de Private Clouds. O Cloud Computing é o somatório do modelo SaaS com
Utility Computing, mas não inclui as Private Clouds. [10]
Qualquer fornecedor de Software as a Service, terá necessariamente o desafio de ponderar
qual a melhor tecnologia e plataforma (ou Cloud) para desenvolver o seu negócio. Por outro
lado os maiores fornecedores de tecnologia para o desenvolvimento de aplicações estão a
posicionar-se também como fornecedores de plataformas, alargando assim a “pilha
tecnológica” e criando uma maior dependência por parte dos produtores de soluções.
Assistimos também à rendibilização das infra-estruturas existentes, como o caso da Amazon,
que capitaliza o investimento feito na sua própria plataforma, alugando a capacidade de
processamento da sua Private Cloud.
O mercado das Clouds encontra-se actualmente em franca ascensão e conta como principais
protagonistas: A Microsoft e a plataforma Azure [12], a Google com o Google AppEngine, a
Amazon com o seus AWS (Amazon Web Services), onde se destaca o recente conceito EC2
(Elastic Compute Cloud) e a SalesForce.com que disponibiliza a plataforma Force.com para
desenvolvimento de aplicações de negócio na sua tecnologia proprietária.
É possível criar uma analogia entre estas Clouds e as linguagens de desenvolvimento. Existem
plataformas mais comparáveis à linguagem “C”, com as vantagens de maior controlo de baixo
nível, mas com a desvantagem da complexidade como o caso do EC2, e por outro lado as
plataformas de domínio aplicacional como a AppEngine e a Force.com, mais comparáveis a
linguagens de alto nível como o Ruby on Rails. [10]
O modelo de negócio das Clouds baseia-se normalmente em formas de pagamento por
utilização, onde é pré-definida uma capacidade máxima e depois é calculada a cada momento
a capacidade dos recursos realmente utilizada. Existem inúmeras vantagens para os pequenos
produtores, que através deste modelo não têm custos de entrada e podem ver as suas
aplicações a concorrer rapidamente com os gigantes da indústria em termos de performance e
escalabilidade. Esta realidade nunca seria possível com o investimento em datacenters e infra-
estruturas de hardware proprietário.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
12
3 Impacto do Software as a Service no modelo de negócio
A mudança de paradigma no fornecimento de software como serviço traz necessariamente
implicações que extravasam o âmbito técnico associado ao desenvolvimento e entrega do
produto. Esta mudança deve ser encarada como um novo modelo de negócio, totalmente
disruptivo, introduzindo perturbações no mercado em relação ao modelo on-premises.
No passado recente, vivemos mudanças importantes como por exemplo: a transformação dos
sistemas operativos baseados em instruções de linha de comando como o DOS e o UNIX para
ambientes gráficos como Windows, X-Windows ou MAC OS; a passagem de processamento
concorrente de instruções aos sistemas distribuídos; a evolução das redes locais até à
capacidade actual da internet e mais recentemente o Grid Computing e a virtualização que
permitiram a criação das Clouds que suportam as infra-estruturas de Software as a Service.
Todos os momentos de grande mudança são propícios ao aparecimento de empresas
incumbentes que aproveitam as tecnologias para se diferenciarem e criarem oportunidades nos
mercados maduros como o caso do software de gestão empresarial.
O modelo SaaS irá certamente permitir novas oportunidades de negócio, principalmente
porque os custos de entrada são totalmente diluídos pelas Clouds com os modelos de
pagamento por utilização (Pay-per-use) onde não existe qualquer custo inicial e a capacidade
de computação é escalonável consoante a necessidade de resposta.
Qualquer produtor com uma base instalada de elevada dimensão não poderá ignorar esta
realidade e terá que preparar convenientemente o seu posicionamento neste novo mercado.
Esta preparação, passa necessariamente pela adaptação da sua oferta e consequente
reestruturação de todas as áreas de suporte.
3.1 Importância da garantia de níveis de serviço (SLAs)
O modelo SaaS pressupõe a existência de um elevado nível de confiança nos serviços
prestados pelo fornecedor da solução. Embora alguns fornecedores defendam cenários onde a
informação é sincronizada e exista tanto localmente como na Cloud, a dependência será
sempre elevada e qualquer falha de operatividade poderá colocar em causa a realização de
transacções ou processos críticos para os clientes.
O fornecedor SaaS poderá não ter controlo sobre a infra-estrutura, estando ele próprio sujeito
à qualidade de serviço de terceiros através de uma lógica de subcontratação. Neste cenário é
muito importante que seja o fornecedor da solução SaaS o único ponto de contacto com o
cliente, quando a responsabilidade é repartida é também normalmente complicado gerir a
fronteira, acabando mais tarde ou mais cedo por transparecer para o cliente qualquer tipo de
ineficiência.
A indústria de software não tem historicamente grande experiência na negociação de SLAs,
dada a essência do fornecimento do software como um produto. Um ponto crítico nos SLAs é
a existência de penalizações por falhas de qualidade no serviço contratado. Estas penalizações
normalmente incorrem na atribuição de descontos ou créditos de outra natureza que afectam
dinamicamente a rentabilidade do negócio, constituindo um risco e ao mesmo tempo um
importante desafio de qualidade para o fornecedor.
Os SLAs são geralmente formados através da adopção de um padrão acordo
a partir do fornecedor ou por negociação entre as partes. Com a crescente adopção de SaaS,
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
13
estes métodos são rígidos, ou de lenta e onerosa implementação. [13] No artigo “SLA
Negotiation System Design Based on Business Rules”, os autores propõe uma abordagem
inovadora através de um mecanismo de negociação electrónica entre as partes. Este
mecanismo permitiria flexibilizar o acordo e ao mesmo tempo monitorizar automaticamente a
qualidade de serviço contratada.
Tan et al propõe [14] um modelo que tenta transformar a subjectividade das diferentes partes
intervenientes e construir um modelo inter-subjectivo com base na redefinição e
consensualização de critérios de serviço.
A investigação nesta matéria, directamente relacionada com a avaliação e definição de
critérios justos e modelos de contratação por níveis de serviço, tem evoluído
significativamente e proporcionalmente à necessidade e importância motivada pelo SaaS. Não
obstante da relevância dos modelos matemáticos e da investigação teórica, existirá sempre
uma “margem cinzenta”, onde a subjectividade predomina. Como em qualquer outro tipo de
oferta: o marketing colateral, a importância da marca e credibilidade do fornecedor, o factor
humano da relação e da gestão de expectativas serão sempre variáveis a ter em conta no
sucesso do fornecimento do software como um serviço.
Do ponto de vista operacional, para a eventualidade de uma falha crítica, será necessário ter
em conta questões como:
Existe monitorização que permita reportar uma mudança no estado do serviço,
propagando em toda a cadeia de fornecimento?
É utilizado redireccionamento para notificar os subscritores através de uma página de
estado quando o sistema não está disponível, indicando a razão de não disponibilidade.
Existe algum sistema de informação para os utilizadores que estão no momento a
utilizar o serviço?
A execução do controlo de estado e a monitorização é efectuada numa plataforma
totalmente independente da que suporta o SaaS?
O fornecimento do estado do serviço está disponível na interacção pessoa-máquina e
máquina-máquina?
Existe algum mecanismo de notificação dos subscritores quando o sistema está
novamente operacional?
3.2 Responsabilidade sobre a informação dos clientes
A responsabilidade do alojamento da informação aliado à disponibilidade e qualidade do
serviço, representam os principais factores críticos de sucesso para o modelo SaaS.
Os sistemas alojados em Clouds estão sujeitos aos mais variados tipos de ataques e
vulnerabilidades. Enquanto um software vendido como produto está protegido dentro da
Firewall da empresa e acede esporadicamente a informação da rede pública, o mesmo
software disponibilizado como um serviço funciona exposto na rede e a sua segurança é
normalmente confiada aos gestores das infra-estruturas.
A FCCN (Fundação para a Computação Cientifica Nacional) publicou em 2007 um artigo
através do CERT (Computer Emergency Response Team) com o título “Cuidados com
alojamento de conteúdos em terceiras entidades” alertando para um conjunto de problemas de
segurança neste tipo de sistemas. [15] O texto agrupa os tipos de serviço em duas categorias:
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
14
partilha de conteúdos e produção de conteúdos.
Os serviços de partilha de conteúdos online permitem estabelecer comunidades de utilizadores
com interesses semelhantes, onde existe partilha de informação, muitas vezes pessoal entre os
vários utilizadores.
Neste tipo de serviços, colocam-se problemas de segurança como:
Falsa sensação de intimidade – Os utilizadores agem como se estivessem a partilhar
informação num ambiente restrito, mas muitas vezes estão a expor os seus conteúdos
em locais públicos;
Agregação de dossiês digitais – Recolha de informação pública sobre uma dada
entidade ou individuo em vários locais, constituindo assim um dossier detalhado com
informação relevante;
Agregação de dados secundários – Correlação do dossier digital com entidades
relacionadas;
Reconhecimento de faces – As imagens pessoais podem ser analisadas através de
software específico e utilizadas para identificação do utilizador;
CBIR (Content-based Image Retrieval) – Tecnologia que permite encontrar imagens
numa base de dados com uma determinada característica. Poderá ser utilizada para
reconhecimento da localização física de um dado utilizador;
Meta-dados em imagens – Associação de informação a uma dada imagem, que poderá
ser utilizada para associação de utilizadores a imagens;
Dificuldade na eliminação de contas – Em alguns serviços é impossível a eliminação
total do perfil e suas referências, como por exemplo comentários de outros utilizadores
associados a mensagens.
SPAM – A divulgação de perfis nas redes colaborativas facilitam a utilização de
informação para envio em massa de mensagens electrónicas não solicitadas.
Cross-site scripting (XSS), vírus e worms – Aproveitamento de falhas em
determinadas tecnologias de desenvolvimento para infiltração de vírus e vermes
(programas auto-propagáveis com efeitos nocivos);
Agregação de redes sociais – Programas que agregam várias redes sociais, mas que
normalmente disponibilizam fracos níveis de segurança;
Phishing – Forma de fraude electrónica onde alguém se faz passar por outra pessoa ou
entidade com o objectivo de obter senhas ou outro tipo de informação;
Infiltração em redes sociais – Neste tipo de fraude, alguém entra na rede social
fazendo-se passar por amigo para ter acesso à informação partilhada;
Calúnias por roubo de identidade - Criação de perfis falsos, em nome de
personalidades públicas, pessoas conhecidas numa determinada rede ou grupo para
denegrir a sua identidade;
Assédio – Nas redes sociais abertas é muito fácil para um perseguidor contactar as
suas vítimas.
Bullying – Semelhante ao assédio, mas com o objectivo de humilhar ou magoar
publicamente.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
15
Espionagem Industrial – Através da informação não controlada publicada nestas redes
é possível aceder facilmente a informação privilegiada sobre empresas concorrentes.
Os serviços de produção de conteúdos online permitem a criação e optar pela partilha da
respectiva informação. Estes serviços têm um comportamento semelhante às aplicações que
estão instaladas localmente no computador, com a importante diferença de estarem
disponíveis em qualquer local através da Internet. Esta classificação está mais próxima do
conceito de Software as a Service, embora de uma forma geral podemos dizer que o SaaS
abrange ambas as realidades.
Para este tipo de serviços, o autor identifica como principais problemas de segurança:
Invasão de privacidade – Roubo de informações pessoais e confidenciais
Roubo de identidade – Envio ou publicação de algo em nome de um dado utilizador
Existem ainda outras vulnerabilidades mais técnicas inerentes a este tipo de sistema que
podem permitir a exposição de dados críticos do utilizador, roubo do controlo da sessão,
execução de código malicioso ou abrir portas para outros ataques.
A informação pessoal é replicada por vários locais, utilizada e armazenada sem a existência
de qualquer controlo ou garantia. A probabilidade de ocorrência dos tipos de ataques e
vulnerabilidades anteriormente descritos aumenta consoante a nossa informação é
disseminada pela rede. Mesmo no mundo físico, com a quantidade de dispositivos que
utilizamos e com a proliferação de sistemas CRM que a todo o momento recolhem
informação sobre o nosso comportamento, vemos os nossos dados dispersos e vulneráveis a
qualquer tipo de ataque.
No artigo “Privacy in the clouds”[16] o autor defende a centralização dos dados de
identificação pessoal. Neste modelo os dados pessoais estão descritos apenas num local e o
próprio utilizador autoriza posteriormente o acesso à sua informação, evitando assim
múltiplos códigos e senhas de acesso. Como um bom exemplo para ilustrar este modelo,
vemos a iniciativa de uma comunidade de desenvolvimento de software livre que desenvolveu
o OpenID (http://openid.net/)
A evidência da possibilidade de todo este tipo de ataques sobre o SaaS enfatiza a necessidade
de um controlo apertado sujeito a constante monitorização sobre a plataforma. A área de
segurança de Tecnologias de Informação, só por si constitui uma especialização da
Engenharia de Software e actualmente assume um papel preponderante no mundo das Clouds.
A ocorrência de uma infiltração no sistema, para além da gravidade de exposição da
informação dos utilizadores pode ter um efeito “bola de neve” com o “passa palavra” nas
comunidades virtuais, onde a replicação da mensagem entre utilizadores acontece a uma
velocidade elevada. Este aspecto deve ser encarado como um assunto da maior importância
pelo efeito que pode causar na credibilidade da marca e do serviço sendo que, nos casos de
maior gravidade pode, inclusivamente, colocar em causa a viabilidade do modelo de negócio.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
16
Como referido no início do capítulo, aliado à importância de proteger a informação dos
clientes é critico assegurar elevados níveis de disponibilidade. Quando o software está
instalado localmente e a base de dados existe dentro de uma qualquer rede local, existe uma
sensação de segurança aparente e de disponibilidade constante. Na realidade os sistemas nas
pequenas e médias empresas são muitas vezes negligenciados, pelo que os servidores são
mantidos em modelos “No news, good news”, apenas sujeitos a intervenção perante falhas
críticas e gerando, em alguns casos, perdas irreparáveis de informação. As condições
desejáveis envolvem um conjunto de meios para manter o hardware em salas estanques,
duplamente alimentadas, com baterias de suporte e meios evoluídos contra incêndios e outro
tipo de catástrofes.
Por outro lado, os custos de pessoal especializado na manutenção de segurança e
monitorização constante do estado da infra-estrutura só são justificáveis com economias de
escala como vemos nos fornecedores de plataformas de alojamento e mais recentemente nas
Clouds.
3.3 Aspectos legais a considerar
A partir do momento em que o produtor de software se responsabiliza pelo arquivo e
manutenção dos dados dos seus clientes, torna-se fundamental o conhecimento de todos os
aspectos legais sobre essa mesma matéria. De notar também que muitas vezes o alojamento da
informação é feito fora do espaço comunitário, o que levanta problemas acrescidos para a
garantia da legalidade sobre o arquivo de informação.
A entidade responsável em Portugal pela protecção de dados é a Comissão Nacional de
Protecção de Dados, uma entidade administrativa independente, com poderes de autoridade,
que funciona junto da Assembleia da República.
Tem como atribuição genérica controlar e fiscalizar o processamento de dados pessoais, em
rigoroso respeito pelos direitos do homem e pelas liberdades e garantias consagradas na
Constituição e na lei. A Comissão é a Autoridade Nacional de Controlo de Dados Pessoais.
A CNPD coopera com as autoridades de controlo de protecção de dados de outros Estados,
nomeadamente na defesa e no exercício dos direitos de pessoas residentes no estrangeiro.
Segundo a legislação actualmente em vigor em Portugal, embora esteja previsto o
arquivamento, processamento e emissão de documentos fiscalmente relevantes por terceiras
partes, é imprescindível ter em conta os requisitos mencionados no Anexo A.
Tanto no caso dos dados pessoais, como na informação de carácter fiscal, a responsabilidade
no modelo SaaS sobre a manutenção da informação terá que ser acautelada para além do
âmbito do serviço prestado. Por exemplo, ao disponibilizar um serviço de facturação
electrónica, na eventualidade de rescisão de contrato, o fornecedor terá obrigatoriamente que
disponibilizar os documentos originais assinados digitalmente ao cliente. O término do
contrato não iliba a responsabilidade sobre o tratamento da informação confiada pelos
clientes.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
17
3.4 Modelo de Licenciamento e Preços
Assiste-se, actualmente, a uma enorme mudança no comportamento da indústria de software
empresarial no que concerne à alteração do modelo de negócio para serviços. Em
simultaneidade com estas mudanças, as empresas deparam-se com o declínio das receitas com
produtos [17].
As vendas tradicionais dos upgrades de versão deram lugar a contratos de manutenção anuais
que permitem acesso a correcções, pequenas melhorias e alterações legais no software.
O desenvolvimento de novos paradigmas como o SaaS e o conceito de “Falso gratuito”, onde
o utilizador acaba por pagar indirectamente o produto - por exemplo recebendo
constantemente mensagens publicitárias - introduz novos desafios à indústria neste sector e
obriga a exercícios de inovação para o desenvolvimento das tabelas de preços da nova
geração.
Com a banalização dos modelos Pay-per-use, utilizados por todos os fornecedores de clouds,
onde não existe nenhum comprometimento inicial e o serviço pode ser experienciado sem
qualquer custo de configuração no arranque, será de esperar o aparecimento deste tipo de
modelos na oferta de Software as a Service.
Os tipos de serviços oferecidos por um produtor de software no modelo tradicional baseiam-
se fundamentalmente no apoio telefónico, formação no software e áreas de conhecimento
relacionadas e, em alguns mercados, disponibilizam adicionalmente serviços de
desenvolvimento à medida. A maioria deste tipo de serviços é prestada sem grandes custos
marginais e com margens brutas acima dos 90%. Os custos são reduzidos a pouco mais do
que o custo de pessoal e marketing. Em contraste, as margens brutas de empresas com um
forte desenvolvimento de IT situam-se nos 30% ou ainda menos [17].
Este factor deve ser considerado seriamente na aposta na decisão sobre a mudança e na
definição de preços e formas de licenciamento. A externalisação do alojamento e de toda a
gestão da infra-estrutura terá com certeza um custo mais reduzido e previsível. No entanto
terão que ser ponderados vários factores, entre os quais: a dependência do fornecedor; o risco
de confiar a informação dos clientes; a disponibilidade e segurança do sistema.
Um grande desafio para a gestão
Um dos maiores desafios de gestão na mudança para o modelo SaaS, será encontrar um ponto
de equilíbrio que permita manter as receitas conseguidas com os contratos de manutenção de
produto e transferir progressivamente essas receitas para o modelo onde só existem serviços.
Numa primeira análise, poder-se-á pensar que, pelo facto de se tratar de um aluguer e de se
aumentar a dependência por parte do cliente, será sempre mais simples manter um contrato.
Na prática a realidade poderá ser mais complexa. A utilização de serviços está muitas vezes
conotada com preços baixos ou até gratuitidade. Normalmente estes serviços são financiados
de forma indirecta, ao contrário do que acontece com a compra de um produto onde o valor
percebido e a “vantagem psicológica” é maior, mesmo que na prática seja uma falsa
vantagem.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
18
Existem vários modelos de preço, mas de alguma forma podem ser enquadrados em três
grandes grupos:
Subscrição: No modelo de subscrição existe um contrato por um período de tempo que
concede ao utilizador o direito de usufruir do produto e de um conjunto de serviços
associados;
Baseado em transacções: Utilização, normalmente pré-paga, de um dado produto
limitada a um conjunto de transacções. Este modelo é semelhante ao utilizado nos
cartões pré-pagos dos telemóveis com um determinado número de minutos disponíveis
para utilização;
Baseado em publicidade: Neste modelo, a utilização do produto é financiada pelas
entidades que publicitam a sua oferta. O utilizador normalmente não tem que pagar
nada pelo usufruir das características base do produto.
Existem várias combinações e derivações destes três modelos, como por exemplo: oferta do
produto base financiado com publicidade e possibilidade de subscrição de novas
funcionalidades ou outros tipos de serviço.
Nos mercados onde o produtor opera numa relação directa com o cliente, sem a figura do
revendedor, será sempre mais simples configurar um modelo de preço mais flexível. Será
sempre desejável discriminar os preços, procurando um modelo económico que abranja o
maior número de segmentos de utilizadores tentando obter o máximo lucro de quem mais
valoriza a utilização do produto ou serviço. Veja-se como exemplo a Xerox com a sua política
de aluguer de máquinas fotocopiadoras. Em vez de estabelecer um preço de aluguer apenas
pelo período em que a máquina estava alocada nas instalações cliente, baseava também o
aluguer no número de fotocópias que o cliente fazia. Presumivelmente o número de
fotocópias é um indicador de utilidade que a fotocopiadora tem para cada cliente. Este tipo de
discriminação permite maximizar o preço consoante o valor percebido pelo produto ou
serviço.
Em síntese, a definição de um novo modelo de preços para a venda no modelo SaaS deve ter
em conta este novo mercado e a oferta existente para o mesmo tipo de produtos. Como em
qualquer outro negócio é fundamental procurar factores de diferenciação que evitem a
concorrência directa apenas baseada na comparação de preço/características. A versatilidade
permitida pela utilização alugada e o consequente controlo sobre o número de transacções e
tempo de utilização do produto, gera novas variáveis facilitadoras de inovação na formatação
da oferta, que devem ser convenientemente aproveitadas. O aumento do custo marginal não
pode ser negligenciado, sob a pena da destruição do valor percebido no produto e acabando
por destruir mercado e diminuir drasticamente a margem bruta conseguida com a venda de
produtos.
3.5 Impacto na relação com o canal de revenda
A maioria dos grandes produtores de software comercializa os produtos nos segmentos
principais de mercado através de um canal de revenda. Este canal é constituído por empresas
do sector, os chamados VARs (Value-Added Resellers3), que estudam as necessidades dos
clientes, adicionam funcionalidades, desenvolvem integrações, formam os utilizadores e
3 Um VAR é uma empresa que adiciona funcionalidades a produtos existentes e vende e vende o produto ao
cliente final como um produto integrado, ou solução “chave na mão”.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
19
colocam o produto no cliente como uma “solução chave na mão”, pronta a ser utilizada. Os
parceiros actuam como aceleradores do negócio e conseguem replicar a mensagem do
produtor de uma forma exponencial dificilmente conseguida através de marketing directo.
No modelo SaaS estas empresas, numa abordagem simplista, são transformadas em meros
promotores de soluções e o seu valor acrescentado para o cliente pode tornar-se
negligenciável perante um cliente menos atento. Na prática, esta mudança na forma de
distribuição dos produtos não resolve todos os problemas do cliente, ao ponto de não ser
necessária a presença de um apoio local na implementação da solução. Para a grande maioria
das empresas não existe uma única solução que responda às suas necessidades. Mesmo
utilizando apenas um produto, existem desafios de integração de hardware local como por
exemplo a recolha de informação de produção, a recolha e disponibilização de informação
para gestão de armazéns, o sistemas de auto-venda, entre outros.
Novas oportunidades para os parceiros com o modelo SaaS
Com um número estimado de 10 milhões de empresas a utilizarem SaaS nos próximos 5-10
anos, a indústria SaaS irá proporcionar oportunidades de negócio para mais de 200.000
parceiros.
O valor acrescentado a criar pelos parceiros no mundo SaaS difere do software tradicional. Os
parceiros devem focalizar-se no alinhamento de processos de negócio, optimização da
utilização da informação, entrega da solução, suporte funcional e integração entre sistemas.
Devido à diferença estrutural e de serviços no modelo SaaS, a SIIA propõe uma nova
denominação aos parceiros ou VARs, como CATALISTS, ou catalisadores de negócio. [18]
Os Catalisadores são empresas ou indivíduos que compreendem as várias necessidades do
negócio, tais como a melhoria de processos em áreas de Vendas, Marketing, Operações,
Recursos Humanos, Logística, entre outras e, ao mesmo tempo, as aplicações SaaS de forma a
propor a melhor solução ao cliente.
Principais diferenças para os Parceiros ou Catalisadores SaaS
Ao longo do trabalho, e em particular no capítulo da introdução no qual se procedeu à
descrição do modelo SaaS, tem vindo a ser explicitado as várias características
diferenciadoras entre o SaaS e um produto de software para além da forma como a solução é
entregue ao cliente. Algumas destas diferenças têm impacto directo no negócio do parceiro. A
tabela seguinte resume os aspectos de maior relevância para os Parceiros.
Aspectos de maior relevância Observações
Arquitectura da solução Como a aplicação reside nos servidores do
produtor, não existe necessidade de instalar
nada na casa do cliente. Esta alteração
implica necessariamente um impacto
negativo no valor percebido dos serviços
prestados pelo parceiro.
Melhoria constante No software tradicional os parceiros têm
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
20
contacto com as novas funcionalidades e
correcções disponibilizadas pelo produtor.
No modelo SaaS as aplicações estão em
constante melhoria (eternas versões Beta). Os
parceiros podem participar em programas de
testes, mas encontra-se em igualdade de
circunstâncias com os outros clientes.
Adaptação da solução ao cliente Enquanto que no software tradicional as
parametrizações podem ser protegidas pelos
parceiros e replicadas fisicamente nos
sistemas de vários clientes, no modelo SaaS
as parametrizações das soluções residem no
espaço de alojamento do produtor. O
produtor tem acesso a todo o trabalho
efectuado pelos seus parceiros e poderá
incorporar conhecimento sobre uma dada
área vertical de negócio.
Licenciamento O licenciamento da solução é feito entre o
produtor e o cliente final. O parceiro não tem
intervenção directa na instalação da licença.
Integração de diferentes soluções A integração com uma solução SaaS requer
conhecimento sobre os protocolos de
comunicação e mecanismos de segurança. As
tradicionais APIs de acesso local são agora
substituídas por acções baseadas em
comunicações com URLs, ou WebServices.
Os parceiros têm obrigatoriamente que se
adaptar a uma nova realidade.
Disponibilização de novas versões A disponibilização de novas versões é
efectuada directamente nos servidores e
comunicada para toda a rede de clientes. Os
parceiros não têm nenhum trabalho de
instalação no cliente. Este factor, embora
providencie por um lado vantagens para o
parceiro, pode retirar-lhe de alguma forma
poder negocial junto do cliente.
Contratação de serviços A contratação de serviços é feita
directamente com o produtor. O produtor
assume toda a responsabilidade sobre os
níveis de serviço contratados e o parceiro não
pode influenciar em nada esta relação.
Venda a novos clientes Como foi referido no capítulo anterior,
existem vários modelos de preços para o
SaaS. Dependendo do modelo criado pelo
produtor, o parceiro poderá ficar numa
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
21
situação de fraca previsibilidade sobre as
receitas que irá conseguir.
Marketing Os produtores de soluções SaaS muitas vezes
direccionam o marketing para os utilizadores
das aplicações em alternativa à comunicação
de vantagens para a empresa no global. Os
utilizadores agem como promotores das
soluções que mais facilitam os seus
processos de trabalho.
Esta alteração implica necessariamente um
alinhamento por parte dos parceiros que vão
replicar a mensagem e vender o serviço.
Serviços técnicos Os utilizadores de uma solução SaaS têm
necessidade dos parceiros para tirar o maior
partido possível da solução e ajustar os
processos de negócio. Os serviços técnicos
prestados pelo parceiro deixam de existir.
Remuneração do canal Com a imprevisibilidade na venda da solução
inicial, quando existe um custo variável
baseado na frequência de utilização ou
qualquer outra variável dinâmica, os
produtores têm que encontrar modelos justos
de remuneração do canal. A facturação do
parceiro sobre a utilização do serviço passa a
depender totalmente dos indicadores
fornecidos pelo produtor.
Término do contrato Com a venda de um produto, mesmo que o
cliente não pretenda evoluir a versão o
parceiro pode continuar a prestar serviços.
Com o aluguer da aplicação SaaS, se o
cliente não renovar a subscrição, deixa de
usar a solução e o parceiro pára
automaticamente de facturar.
Especialização e impacto nos Recursos
Humanos
A mudança de necessidades por parte dos
clientes obriga necessariamente à aquisição
de diferentes competências por parte dos
parceiros. Para o levantamento dos aspectos
fundamentais do negócio e proposta de
melhoria de processos, os recursos técnicos
com conhecimento de tecnologias de
informação têm necessariamente de ser
convertidos em quadros polivalentes com
maior conhecimento de gestão.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
22
O risco da imprevisibilidade do negócio para o parceiro
A comercialização de aplicações tendo como base um aluguer, com um custo variável
dependente da frequência ou do tipo de utilizações, tem um impacto directo na forma de
remuneração do canal de distribuição. Enquanto que ao vender um produto existe uma
margem previamente definida para o VAR, no modelo SaaS, o parceiro tem apenas uma
estimativa do tipo e da frequência de utilização da solução. A relação do cliente torna-se
muito mais próxima do produtor da solução, e só este consegue informação real sobre o tipo
de utilização, a frequência e os aspectos mais valorizados no dia-a-dia de utilização do
produto. Não será fácil para o parceiro promover a utilização do produto de forma a
incrementar o seu rendimento em cada um dos clientes.
O desafio mais importante para o Parceiro Catalisador será transformar a sua actividade,
aprofundando o conhecimento nos aspectos funcionais de cada negócio de forma a exercer
uma actividade verdadeiramente criadora de valor para o cliente, em alternativa aos aspectos
mais técnicos da manutenção local do software e da gestão da infra-estrutura local de
hardware.
Cabe ao produtor de software encontrar modelos de remuneração do canal de parceiros
ajustados a esta nova realidade, sem penalizar e desprezar a importância destas empresas na
sua actividade.
Síntese
Numa primeira abordagem existem vários aspectos negativos para o parceiro quando o
produtor adopta o modelo SaaS. Na realidade, o produtor só conseguirá adquirir o
conhecimento e a especialização necessária para o desenvolvimento de um serviço que
abranja várias áreas de negócio com o apoio do canal de parceiros. Sem parceiros de negócio
será muito difícil catapultar a actividade e gerar um efeito de promoção massiva de qualquer
tipo de serviço.
Os parceiros que se especializam em determinados sectores de actividade adquirem um
conjunto de conhecimentos e competências que os diferenciam, gerando um enorme valor
acrescentado para o cliente. O produtor, para aproveitar estas competências, terá que
desenvolver modelos de remuneração que tornem possível e rentável a actividade do parceiro,
apesar da transformação do tipo de serviços prestados.
Os parceiros, por sua vez, terão que investir nesta transformação e adaptar a organização
através da especialização num conjunto de áreas de negócio, criando um real valor
acrescentado na melhoria de processos dos clientes.
3.6 Impacto nas Operações
Para as empresas cotadas em bolsa, o modelo SaaS apresenta todas as variáveis necessárias
para o sucesso do negócio. A previsibilidade e a recorrência da subscrição de serviços, aliada
à facilidade de controlo de recebimentos contribuem fortemente para um bom Cash Flow 4 e
para a facilidade de previsão e planeamento do negócio.
4 Cash Flow é um conceito que diz respeito ao montante monetário recebido e pago pela empresa num
determinado período de tempo pré definido. É utilizado para avaliação do estado de um negócio ou projecto
específico.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
23
Enquanto após a venda de um produto, o fornecedor fica muitas vezes sem contacto como
cliente durante um largo período de tempo, no modelo SaaS, para além da facturação
recorrente, existe uma ligação contínua ao cliente, com constante interacção e troca de
experiências.
Este modelo, no entanto cria novos desafios na forma de facturar. As variáveis normais de
uma licença de software tradicional reduzem-se a um conjunto limitado, como por exemplo:
identificação do cliente, número de postos de trabalho, versão da aplicação, módulos
disponíveis no produto. No caso da venda de software como um serviço baseado na
utilização, podemos identificar factores como: tempo de utilização por cada operador, número
de transacções, níveis funcionais ou até tipo de utilização do produto. Desta forma, trata-se de
uma nova realidade, com um modelo totalmente livre, que exige um esforço de adaptação das
equipas e dos sistemas internos para recolha e processamento de toda esta informação.
Os sistemas SaaS são vendidos muitas vezes no modelo “Pay-per-use”, onde tal como a
factura da energia, ou telecomunicações não existe um custo pré-definido e o utilizador está
sujeito a um valor variável consoante o tempo de utilização das características do serviço pré-
estabelecidas no inicio do contrato.
Os contratos estabelecem garantias de níveis de serviço para o cliente e consequentes
penalizações. No modelo SaaS é necessário desenvolver um plano de risco muito mais
rigoroso. Uma falha técnica pode ter implicações financeiras graves e afectar directamente o
negócio.
3.7 Novos desafios para o Marketing
Sendo o maior desafio do Marketing a adaptação do produto às necessidades dos utilizadores,
nada como ter uma aplicação a ser utilizada dentro da própria casa do fornecedor. Desta
forma é possível uma monitorização total e em tempo real de todas as actividades de cada
cliente. As equipas de Marketing podem assim entender tendências e necessidades que
contribuem para uma melhor adequação do produto a cada cliente. Os quatro Ps do Marketing
de produto são agora alargados para sete com os elementos fundamentais do Marketing de
Serviços (Product, Price, Place, Promotion, Participants, Physical Evidence, Process of
delivery), obrigando a uma profunda reflexão sobre esta nova realidade.
O produto é colocado em evidência como um canal privilegiado de comunicação com o
cliente, podendo em alguns casos servir para a distribuição publicitária, veja-se por exemplo a
utilização de publicidade no Microsoft Windows Live Messenger com os seus banners, ou no
Google e-mail com mensagens publicitárias no contexto do conteúdo de cada mensagem.
Estas formas de comunicação ajudam muitas vezes a financiar a utilização do software e a
tornar a sua utilização economicamente mais acessível para o cliente final.
A correcta gestão de expectativas dos clientes e o desenvolvimento de planos de Service
Recovery em caso de indisponibilidade tornam-se, deste modo, factores críticos sendo na
maioria dos casos mais valorizados pelos clientes do que a qualidade funcional dos próprios
produtos.
A aquisição de um produto de software é, muitas vezes, motivada pelas informações que
circulam nas redes de relações informais ou pelo conhecimento de um caso de estudo bem
sucedido em determinada empresa. Enquanto o software na sua forma tradicional apresenta
um comportamento coerente em todas as iterações de utilização, o mesmo produto vendido
numa lógica SaaS, tal como qualquer serviço, pode provocar diferentes experiências para o
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
24
cliente em momentos distintos da sua utilização. Esta avaliação com base na experiência de
serviço, principalmente em casos menos bem sucedidos, cria um grande desafio de
comunicação para a transmissão da qualidade real do produto e do serviço.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
25
4 Impacto do modelo SaaS na Engenharia de Software
Com o modelo SaaS são levantados novos desafios para o produtor de Software. Enquanto
que uma aplicação tradicional funciona numa rede local, sem grandes exigências ao nível da
segurança e da escalabilidade, uma aplicação SaaS funciona remotamente e está disponível
para um grande conjunto de empresas ou indivíduos.
Este modelo cria desafios muito importantes para as equipas de produção de software. No
modelo tradicional existe um passo de distribuição e instalação que minimiza o impacto da
propagação de erros. A disponibilização de uma versão de produção passa agora a ter
consequências imediatas na experiência dos utilizadores e qualquer falha é propagada no
mesmo instante. Na perspectiva inversa, a correcção de um qualquer erro ou a introdução de
uma nova funcionalidade pode ser também disseminada de imediato, sem a entropia e o atraso
normalmente causado pelo processo de distribuição.
As empresas tradicionais de desenvolvimento para pequenas empresas têm novos desafios,
muito próximos em alguns casos da realidade vivida no chamado “Mid Market”, ou mercado
das médias e grandes empresas. A integração de soluções torna-se mais complexa afigurando-
se crítico o fornecimento de interfaces como WebServices5 para tornar possível o diálogo
entre as diferentes soluções.
A criação de uma experiência de interacção ao nível de uma aplicação desktop é um desafio
muito importante para a difusão deste tipo de soluções. A garantia de uma boa usabilidade e
da produtividade de trabalho para os utilizadores finais irá certamente representar um factor
decisivo na mudança do modelo tradicional para o modelo SaaS.
Os clientes passam a entregar totalmente a informação crítica do negócio e a depender da
plataforma do fornecedor de software. Este factor incrementa exponencialmente a
responsabilidade do produtor, que extravasa neste sentido a garantia do bom funcionamento
do produto. Uma empresa produtora de software tem neste modelo de fornecimento a
responsabilidade de gerir, ou subcontratar, a gestão de uma infra-estrutura segura e escalável
que garanta a performance e total disponibilidade.
4.1 Aspectos gerais a ter em conta na construção de uma aplicação SaaS
Antes de planear o desenvolvimento importa conhecer quais os elementos chave que devemos
ter em conta para o desenho de uma aplicação baseada na Web vendida como um serviço.
M.T. Hooglviet desenvolveu uma investigação sobre o tema “SaaS Interface Design:
Designing Web-based software for business purposes” [19] onde refere que as linhas de
orientação sobre a construção de aplicações Web são também aplicadas ao SaaS, no entanto
uma aplicação SaaS deve ser enriquecida em vários aspectos que diferem do paradigma
tradicional do desenvolvimento Web.
5 Web service é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes.
Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que
sistemas desenvolvidos em plataformas diferentes sejam compatíveis.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
26
Como linhas de orientação para a construção de uma aplicação SaaS são referidos os
seguintes eixos de acção:
Expandir as preocupações de desenho a todos os serviços e não apenas ao núcleo
da aplicação:
o Uma aplicação SaaS é composta por vários serviços: registo, subscrição,
facturação entre outros complementares ao serviço nuclear. Esta
“constelação de serviços” obriga a uma preocupação com o conjunto, para
que seja possível criar uma coerência que proporcione uma boa experiência
na utilização do conjunto.
Permitir a evangelização por parte dos utilizadores
o As aplicações SaaS, como referido anteriormente são normalmente
subscritas num modelo de pagamento por utilização. Neste modelo é muito
importante o “passa palavra” gerado na comunidade de utilizadores. É
recomendável difundir publicidade sobre o serviço em blogs e outras
comunidades Web. É também recomendável a disponibilização de
mecanismos de envio directo de informação aos amigos.
Estabelecer uma forte chamada para a acção
o Os utilizadores devem ser convencidos a conhecer os aspectos mais fortes
da aplicação através de um teste experiencial. Como a aplicação está
disponível na internet e não requer instalação no cliente, será mais simples
proporcionar este tipo de experiência.
Disponibilizar sessões de testes sem qualquer custo
o Proporcionar aos utilizadores a possibilidade de utilizar a aplicação durante
um período de tempo sem qualquer custo. Estas sessões devem ao mesmo
tempo ser acompanhadas por uma equipa de apoio ao cliente que garanta o
acompanhamento contínuo.
Integrar ajuda e suporte na própria aplicação
o Quando o utilizador tem uma dificuldade na aplicação deve poder através
de uma ligação directa aceder ao tutorial da função em causa.
Adicionalmente será interessante a possibilidade de entrar directamente em
contacto com o operador de suporte, passando o contexto da situação em
causa para o operador de suporte.
Pedir continuamente feedback aos utilizadores
o A aplicação deve pedir periodicamente feedback aos utilizadores sobre a
experiência de utilização. Desta forma será possível incorporar melhorias
contínuas no serviço e estabelecer um circuito de comunicação que
aumenta a lealdade e satisfação dos clientes.
4.2 Tecnologias emergentes para o desenvolvimento SaaS
Apesar dos produtores não terem dúvidas sobre as vantagens do modelo de distribuição de
software como serviço, o mesmo não se pode dizer em relação ás tecnologias e infra-
estruturas sob as quais vão desenvolver os seus serviços.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
27
Turner (2003) [20] explicita no seu artigo “Turning software into a Service” diversas falhas
em aspectos tecnológicos que afectam negativamente o desenvolvimento de aplicações como
serviços. Só cerca de três anos mais tarde, em 2005-2006 com a maior difusão da Internet de
banda larga e o aumento de fiabilidade da rede pudemos assistir a um aumento considerável
da adesão ao SaaS. Um dos factores que contribuiu positivamente foi o aumento de confiança
dos utilizadores sobre o alojamento de informação externamente. As empresas começam
agora a ponderar verdadeiramente os custos de manter uma infra-estrutura interna de
Tecnologias de Informação, versus subcontratar serviços. A tendência de aceitação do modelo
SaaS é visível para os mais variados tipos de aplicações: processamento de texto, folhas de
cálculo, servidores de e-mail, ferramentas CRM, serviços externos de cópias de segurança,
segurança da rede, entre outras [9].
Paralelamente à mudança de mentalidade, outro factor fundamental consiste na qualidade da
experiência de utilização alcançada actualmente com a utilização de uma aplicação alojada
remotamente. Esta experiência de utilização só é possível com a evolução das tecnologias que
alavancam o desenvolvimento deste tipo de aplicações [21]:
Web 2.0 A Web 2.0 está relacionada com novas oportunidades
de negócio, redes sociais e evoluções tecnológicas.
A Internet é vista como uma plataforma de
comunicações e o browser tornou-se um interface
universal para todos os utilizadores.
Do ponto de vista tecnológico surgiram várias novas
possibilidades que facilitam o aparecimento de
aplicações SaaS com interfaces quase comparáveis
aos conseguidos localmente.
RIAs (Rich Internet applications) As RIA são aplicações Web com características e
funcionalidade semelhante às aplicações tradicionais
executadas localmente. Estas aplicações funcionam
dentro de um browser, mas são distribuídas
tipicamente através de plataformas complementares
proprietárias, como por exemplo: Microsoft
Silverlight, Adobe Flex/Air, JavaFX entre outras e
executadas dentro de um ambiente reservado
chamado (Sandbox).
As RIAs estão directamente relacionadas com o
sucesso do SaaS. A facilidade de criar experiências
interactivas com este tipo de tecnologias vem
impulsionar fortemente a utilização do browser como
contentor de aplicações. A tecnologia vectorial
utilizada pelos fornecedores das referidos frameworks
RIA permite desenhar interfaces rápidos e com muito
dinamismo, processados localmente, sem recorrer ao
servidor. No servidor o estado da sessão é mantido,
assegurando assim a interacção cliente-servidor de
forma quase não percepcionada pelo utilizador.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
28
SOA (Service-oriented arquitecture) As arquitecturas orientadas a serviços são utilizadas à
muito tempo nos sistemas empresariais de maior
dimensão. Estas arquitecturas surgiram como
facilitadoras de integração e orquestração de vários
processos.
Muitas aplicações expõem os seus principais serviços
na Web, ou por outro lado consomem serviços
subcontratados a entidades terceiras. À medida que
aparecem mais serviços disponíveis na Web, as
aplicações tendem a utilizar muitos destes serviços
em alternativa ao desenvolvimento e integração local.
Veja-se a título de exemplo, a possibilidade de
utilização do serviço Google Maps para cálculo de
rotas de entrega de mercadorias.
Cloud Computing O modelo SaaS dificilmente seria economicamente
viável para a grande maioria das empresas se não
existissem os fornecedores de Clouds
Virtualização A virtualização é a tecnologia que veio permitir o
desenvolvimento das Clouds. Através da
virtualização é possível criar uma abstracção
completa dos recursos físicos de hardware. Com este
tipo de software é possível simular um recurso que
não está fisicamente presente, pelo menos nessa
configuração.
4.3 Engenharia de software baseado em serviços
O desenvolvimento de software foi ao longo do tempo uma tarefa realizada pelo fornecedor,
onde os especialistas de domínio são os fornecedores de requisitos e não necessariamente
quem produz. Recentemente este paradigma tem vindo a ser transformado e surge o conceito
de SBSE (Services Based Software Engineering) para dar resposta ao desenvolvimento de
Software como um serviço e não como produto [22].
O conceito surgiu com um artigo de Saeed e Jaffar-ur-Rehman onde referem que o Software
as a Service tem requisitos de engenharia muito diferentes do desenvolvimento como produto.
Consequentemente argumentaram a necessidade de uma abordagem alternativa para a
engenharia de software e propuseram uma separação do modelo SBSE [23]. A título de
exemplo, e numa perspectiva de utilizador final, o modelo SaaS não requer a instalação local
nem actualização de novas versões funcionais ou correcção de anomalias.
O autor refere ainda que existe uma cultura na forma como a engenharia é praticada numa
dada organização e que esta cultura pode afectar o próprio modelo de negócio.
O aspecto cultural é controverso, mas é um facto que a arquitectura e a tecnologia utilizada
para o desenvolvimento de uma dada aplicação condicionam fortemente o seu sucesso ao
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
29
longo do tempo e têm necessárias implicações no modelo de negócio.
No estado actual de fraca maturidade tecnológica para o desenvolvimento SaaS é fundamental
desenhar uma boa arquitectura que mantenha independência sobre as plataformas defendidas
pelos fabricantes. Este será um dos aspectos que requer maior investimento do ponto de vista
técnico na mudança para o novo modelo SaaS.
O artigo “Transitioning do Software as a Service” [23] examina em detalhe os aspectos
relacionados com as práticas de engenharia de software respeitantes ao planeamento, gestão
de versões e manutenção no contexto de uma pequena empresa de software que mudou para o
modelo SaaS. Foram observados aspectos importantes na vivência desta experiência de
transição, alguns dos quais merecem especial destaque:
1) Planeamento: Os ciclos de desenvolvimento com planeamento rígido a longo prazo
não funcionam no modelo SaaS. Esta prática terá que ser revista e transformada em
modelos mais ágeis de desenvolvimento incremental, com planeamentos mais curtos
que respondam às necessidades imediatas de parceiros e clientes.
2) Gestão de versões: As práticas de desenvolvimento de software tradicional
habituaram-nos ao desenvolvimento por versões. O incremento de versões para além
do controlo interno dentro do produto, permitia ao Marketing convencer os clientes
sobre a venda de novas características e de alguma forma “cortar” com a continuidade,
realçando que só a última versão é a melhor. No SaaS, será sempre preferível não
alarmar os clientes com melhorias disruptivas. As melhorias e correcções de
anomalias devem ser introduzidas no sistema da forma mais pacífica possível, sem que
o cliente se aperceba que existe uma nova versão. O fornecedor deve focalizar-se em
providenciar um serviço sólido e fiável.
3) Manutenção: No modelo SaaS a manutenção do sistema torna-se uma das actividades
mais importantes da engenharia de software. A introdução de novas funcionalidades e
a correcção de anomalias devem ser transparentes para o utilizador. Enquanto que para
a instalação de uma versão correctiva no cliente era aceitável uma paragem da
actividade, no SaaS estas melhorias têm que ser introduzidas no sistema de forma
invisível para os utilizadores.
4.4 Processo de desenvolvimento
A construção de software sobre uma plataforma de serviços ou Cloud, altera
consideravelmente o processo de desenvolvimento, ou seja a forma como se processa o
desenho, o desenvolvimento e a entrega do serviço [24].
Os métodos tradicionais de desenvolvimento de software devem ser revistos de forma a
cumprir os novos requisitos do desenvolvimento de serviços.
Para que seja possível o desenvolvimento sobre plataformas de serviços, as aplicações têm
que cumprir três requisitos principais [25]:
1) Devem ser independentes do sistema operativo e do hardware onde são executadas;
2) A informação deve ser independente da aplicação que a manipula;
3) Os componentes da aplicação devem suportar comportamentos dinâmicos e
independentes para que seja possível reagrupar a execução.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
30
Para explicar as principais diferenças no processo de desenvolvimento foi aqui assumido um
modelo reduzido com as principais fases que estão presentes em qualquer tipo de
metodologia:
No desenvolvimento de software como serviço, podemos observar as mesmas fases do
processo. As diferenças encontram-se no tipo de actividades e preocupações encaradas em
cada uma das fases.
No artigo “Efficient Software Delivery Through Service-Delivery Platforms” [26] são
referidas as fases da vida de uma aplicação vendida como um serviço e as suas actividades.
A tabela seguinte sumariza as principais etapas do desenvolvimento de uma aplicação com
serviço sobre uma plataforma.
Construção Análise de requisitos
Desenvolvimento da solução e integração com a plataforma de
serviços (Cloud)
Entrega Configuração da plataforma
Verificação de compatibilidade
Instalação da aplicação na plataforma
Verificação dos níveis de serviço acordados
Comercialização Os clientes descobrem a aplicação
Os clientes aprendem a trabalhar com a aplicação
Os clientes experimentam a aplicação
Os catalisadores integram a aplicação com outras soluções
Utilização O cliente utiliza a aplicação
O cliente ou o catalisador personalizam a aplicação
Figura 2 – Processo de desenvolvimento de software como produto
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
31
A plataforma monitoriza a execução e gere a aplicação
A plataforma reporta e escala os incidentes para o produtor
Manutenção O produtor instala novas versões funcionais da aplicação
O produtor instala correcções de erros
O fornecedor da plataforma instala novas funcionalidades e
correcções de erros no software da plataforma
Ao comparar os dois processos de desenvolvimento verificamos que existem diferenças
consideráveis. Mesmo nas actividades com designação semelhante, as preocupações são
significativamente distintas. Verifica-se também que a plataforma que serve de base para o
desenvolvimento da aplicação está intrinsecamente relacionada com todas as fases da
construção da solução [24].
De seguida, tendo como base o processo tradicional de desenvolvimento de software, são
apresentadas as principais considerações a ter em conta em cada uma das etapas para o
desenvolvimento de uma aplicação como um Serviço:
Levantamento de
Requisitos
- Os requisitos não funcionais assumem um papel de maior
importância. Será necessário garantir todos os requisitos
necessários para o funcionamento sob a plataforma escolhida, ao
mesmo tempo que é necessário assegurar a satisfação das
necessidades do mercado;
- As aplicações devem ser desenhadas para servir múltiplos
inquilinos. Torna-se fundamental ter em conta aspectos não
funcionais como: escalabilidade, performance, resistência a picos
de utilização, segurança, entre outros;
- Para o correcto cumprimento dos níveis de serviço garantidos aos
clientes será necessário estudar a melhor solução em parceria com
o fornecedor da plataforma;
- A escolha da infra-estrutura e da tecnologia mais adequada são
factores críticos de sucesso;
- Dada a imaturidade tecnológica actual do mercado, é
fundamental encontrar uma arquitectura que garanta a maior
independência possível para que se mantenha válida e garanta o
retorno de investimento.
Análise - A análise deve ser conduzida sob a perspectiva do negócio. O
modelo SaaS trata cada indivíduo dentro do sistema como um
actor independente. Esta interacção directa, permite desenhar o
serviço mais adequado dependendo do papel que cada utilizador
desempenha na organização;
- A personalização è muito importante neste tipo de sistemas onde
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
32
a mesma aplicação irá servir um número muito grande de clientes
com requisitos muito particulares em cada um dos processos;
- É recomendado o uso de casos de utilização para descrever cada
um dos processos. Esta abordagem formal elimina subjectividade e
focaliza a análise no detalhe de cada actividade.
Desenho Na fase de desenho é produzida toda a documentação de suporte ao
desenvolvimento do serviço.
- Investigação sobre a melhor tecnologia a utilizar: Depois de
analisar os requisitos da plataforma e as necessidades dos clientes
estão reunidas todas as condições para o estudo das linguagens e
frameworks para o desenvolvimento na Web 2.0.
- Validação da tecnologia e plataforma escolhidas: Dada a
imaturidade de algumas tecnologias e plataformas, apesar de
aparentemente poderem parecer as soluções mais adequadas è
recomendável o desenvolvimento de protótipos ou provas de
conceito. Estas provas de conceito podem ser logo nesta fase
submetidas a testes de carga e usabilidade com cenários que
permitam antecipar eventuais problemas futuros. Estes testes
devem incluir a utilização das APIs disponibilizadas pelos
fornecedores, só assim é possível um conhecimento adequado do
funcionamento da infra-estrutura.
- Na fase de desenho um dos mais importantes artefactos a entregar
è a especificação da arquitectura. Neste caso as decisões sobre a
arquitectura devem ter em conta por um lado a plataforma, por
outro as melhores práticas inerentes ao desenvolvimento de uma
aplicação SaaS.
A arquitectura de uma solução SaaS, no que diz respeito à
integração entre sistemas, deve ter em conta 3 aspectos em
particular:
1) A integração com a cloud, que requer necessariamente
consumir um conjunto de WebServices disponibilizados
pelo fabricante;
2) A possibilidade de expor e consumir WebServices dentro
da própria plataforma para integração com outras
aplicações no mesmo “domínio”;
3) A possibilidade de integração com outras aplicações fora
da plataforma, sejam elas SaaS, ou aplicações tradicionais
executadas no cliente.
Todas estas interacções devem ser loosely-coupled
(completamente separadas, ou seja um sistema não assume nada a
respeito do comportamento do parceiro, permitindo um maior
isolamento). Tipicamente são utilizadas arquitecturas orientadas ao
desenvolvimento de serviços (SOA).
-Na fase de desenho é igualmente importante a opção pela
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
33
arquitectura de dados. Basicamente existem 3 soluções possíveis:
1) Uma base de dados independente por cada inquilino do sistema;
2) A mesma base de dados com esquemas diferentes;
3) A mesma base de dados e o mesmo esquema.
Cada solução apresenta vantagens e desvantagens. No subcapítulo
seguinte são explicadas em detalhe as várias opções.
Implementação - A codificação da aplicação deve ter em conta o ambiente da
plataforma onde será executada a aplicação. É muito importante
que o ambiente de depuração, durante a fase de desenvolvimento,
seja próximo do ambiente de produção para evitar imprevistos em
fases mais avançadas do processo;
- O desenvolvimento deve iniciar-se pelos processos core. Desta
forma será mais simples garantir que todos os processos podem ser
invocados como WebServices e ao mesmo tempo podem desde
logo ser aplicados testes unitários para garantir o bom
funcionamento dos processos;
- Será importante pensar logo à partida na implementação da
camada de baixo nível que interage com os serviços
disponibilizados pela plataforma como por exemplo: serviço de
autenticação, serviço de facturação, monitorização, entre outros.
Como estes serviços dependem mais de terceiros, será importante
antecipar problemas de comunicação nas fases preliminares do
projecto;
- Desenvolvimento do interface: Embora não seja o núcleo da
aplicação, o interface desempenha um papel fulcral na experiência
do cliente com a aplicação.
Um interface com o utilizador bem conseguido deve ser intuitivo,
coerente, eficiente, apelativo e simples de utilizar.
Validação - A fase de validação de uma aplicação SaaS, para além de todos
os aspectos inerentes aos testes de uma aplicação tradicional deve
verificar: a interacção entre a aplicação e a plataforma; a
performance e monitorização do comportamento de cada inquilino
quando o sistema è submetido a testes de stress.
Devem ser utilizados:
- Testes unitários: executados por cada programador em peças dos
sistema cujo âmbito è inteiramente da sua responsabilidade;
- Testes de integração: devem ser previstos os cenários de
integração anteriormente descritos. Devem ser contemplados de
forma especial os testes de performance através de vários
processos escritos por diferentes programadores;
- Teste de performance: Estes testes devem ter critérios iniciais de
satisfação bem definidos para que sejam cumpridas as expectativas
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
34
de utilização requeridas pelo mercado;
- Testes de medição ou monitorização: Em principio a plataforma
deve dispor de mecanismos de monitorização da actividade de
cada inquilino do sistema. De qualquer das formas, é
recomendável não entregar este tipo de monitorização aos
fornecedores da plataforma. A aplicação deve dispor de um registo
de actividade de cada inquilino para que possa ser confrontado
com os indicadores obtidos a partir do fornecedor da Cloud.
- Antes da entrada em produção, devem ser contemplados testes de
instalação e desinstalação de novas versões, garantindo que o
processo pode ser efectuado de forma transparente para o
utilizador.
4.5 Arquitectura de bases de dados Multi-Tenant
O desenho de um serviço responsável por armazenar de forma segura, fiável e de rápido
acesso toda a informação dos vários inquilinos, requer necessariamente um estudo
aprofundado sobre a arquitectura do sistema de base de dados.
A dimensão de uma base de dados de um sistema SaaS depende directamente do número de
inquilinos suportados pelo sistema e ao mesmo do volume de informação gerado por cada
inquilino. Memo para os sistemas mais simples, as bases de dados podem facilmente atingir
dimensões na ordem dos vários terabytes de informação.
Existem várias soluções próximas de dois eixos de decisão: isolamento da base de dados de
cada inquilino; partilha da mesma base de dados por todos os inquilinos.
Ambos os sistemas apresentam vantagens e desvantagens. Se optarmos pelo isolamento em
bases de dados independentes, é mais simples garantir o nível de serviço por cada inquilino e
existe uma total separação da informação, por outro lado qualquer alteração de estrutura terá
que ser replicada pelos vários esquemas de dados.
A partilha de uma mesma base de dados por todos os inquilinos apresenta claras vantagens ao
nível da simplicidade de manutenção e ao mesmo tempo facilita a criação de economias de
Figura 3 - Arquitectura do sistema de base de dados
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
35
escala. Com esta solução será, no entanto, mais complicado garantir os níveis de serviço
assegurados a cada inquilino.
Paralelamente à melhor opção técnica, devem ser ao mesmo tempo contemplados os aspectos
de legislação que possam obrigar ao isolamento de determinados tipos de informação
sensível.
Do ponto de vista técnico existem à partida três abordagens possíveis para arquitectar o
repositório de informação [27]:
1) Separar em bases de dados diferentes a informação de cada inquilino
2) Utilizar a mesma base de dados, separando o esquema de dados de cada inquilino
3) Utilizar a mesma base de dados e partilhar o esquema de dados
A tabela seguinte resume as principais dimensões de análise sobre cada uma das abordagens:
Separar em base de
dados diferentes
Utilizar a mesma base
de dados com
esquemas diferentes
Utilizar a mesma base
de dados e o mesmo
esquema
Abordagem -Identificação em
metadados da
instância da base de
dados associada a
cada inquilino
-Cada inquilino tem um
conjunto diferente de
tabelas dentro da
mesma base de dados
-Todos os inquilinos
utilizam o memo
conjunto de tabelas na
mesma base de dados
Vantagens -Fácil de restaurar
uma cópia de
segurança de um dado
inquilino
-Maior nível de
segurança porque os
repositórios são
independentes entre
cada inquilino
- Fácil implementação
- Segurança moderada
-Melhor escalonamento
de inquilinos dentro de
cada servidor
-Melhor escalonamento
de inquilinos dentro do
mesmo servidor
Aspectos a ter
em conta
-Não é possível um
grande número de
inquilinos dentro do
mesmo servidor
-Maior custo de
gestão e cópias de
segurança
-Maior custo da infra-
estrutura de suporte às
BDs
-Mais difícil de
restaurar a informação
de um dado inquilino
-Mais difícil de
restaurar a informação
de um dado inquilino
-Mais difícil de
implementar extensões
ao modelo de dados
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
36
Recomendação
de utilização
-Quando o inquilino
tem requisitos
especiais ao nível do
isolamento de dados
-A aplicação tem um
número reduzido de
tabelas (perto cem
tabelas)
-É importante o
escalonamento
-É possível utilizar
várias especificações de
linguagem na mesma
base de dados
-É importante o
escalonamento
-Quando existe
necessidade de “fundir”
informação de vários
inquilinos
Um cliente típico de uma dada aplicação empresarial vendida como um produto, nunca
chegará a atingir volumes de dados que justifiquem este tipo de preocupações de
escalonamento.
O objectivo deste subcapítulo é sumarizar os principais pontos que podem causar impacto
para o produtor que nunca teve nas suas preocupações a gestão de bases de dados com este
nível de dimensão e onde a robustez, segurança e disponibilidade são factores críticos de
sucesso. O tema em causa, deve ser objecto de investigação aprofundada tendo em conta o
tipo de aplicação SaaS a desenvolver.
Adicionalmente ao referido, existem aspectos muito relevantes a respeito da personalização
da informação para cada inquilino e ao modelo de segurança mais adequado que devem ser
aprofundados e ponderados complementarmente na decisão sobre a arquitectura de dados.
No artigo “Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques”
[28] é referido em detalhe uma metodologia de mapeamento do esquema da base de dados
chamada “Chunk Folding”, onde as tabelas lógicas são particionadas verticalmente em blocos
agrupados em pastas e posteriormente armazenados em tabelas físicas multi-inquilino. Estas
tabelas em fase de consulta são agrupadas para responder aos vários tipos de interrogações.
Segundo os autores, esta metodologia permite grande escalabilidade e ao mesmo tempo
tempos de resposta muito eficientes, mesmo em repositórios com grande volume de
informação.
4.6 Interface com o utilizador em aplicações SaaS
Existem diferenças significativas no desenho do interface com o utilizador para uma solução
SaaS comparado com uma aplicação tradicional.
As características intrínsecas ao modelo SaaS (ver capítulo Estado da Arte: Quais os factores
diferenciadores e as características do modelo SaaS) tornam o desafio de construir um
interface eficiente e que proporcione uma experiencia de serviço agradável uma tarefa de
engenharia complexa que requer a utilização das ferramentas adequadas para que seja
conseguida uma dinâmica semelhante ao software tradicional. [29]
Os utilizadores de aplicações tradicionais estão habituados a interfaces ricos com grande
interactividade e respostas rápidas ás acções dos utilizadores, que garantem uma boa
produtividade de trabalho.
Numa aplicação tradicional, o programador pode controlar com exactidão a forma como o
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
37
interface é apresentado ao cliente. O desenho da aplicação é optimizado para um dado sistema
operativo e as características físicas da máquina, sendo possível controlar a dimensão do ecrã
e a forma como são representados os objectos.
A forma tradicional de apresentação de uma aplicação baseada em HTML não tem condições
para garantir uma boa experiência de usabilidade aos utilizadores de aplicações de negócio
tradicionais. O modelo de interface Web foi desenhado tendo em conta outro tipo de
requisitos. Ao basear-se no conceito de pedido/resposta para comunicação com o servidor,
onde as respostas são apresentadas em novas páginas de informação, cria barreiras
intransponíveis no dinamismo e na interactividade requerida.
Ao navegarmos na internet através de um browser temos uma noção de liberdade e podemos
“saltar” de aplicação para aplicação sem uma preocupação de contexto. Numa aplicação SaaS,
apesar de ser um tipo de aplicação Web, será conveniente manter o utilizador concentrado no
contexto da própria aplicação. A aplicação deve conseguir que o utilizador se abstraia do
paradigma de utilização da web e apesar de interagir através do browser sinta que tem a
aplicação no seu domínio local. Um bom exemplo é a experiência conseguida com o
Microsoft Outlook Web Access®
, onde é mantido todo o aspecto e comportamento principais
da aplicação local.
Existem vários frameworks que facilitam o desenvolvimento de aplicações SaaS, mantendo o
paradigma de uma aplicação executada localmente. As aplicações construídas com este tipo
de tecnologia são chamadas RIA (Rich Internet Applications).
Tecnologias para desenvolvimento RIA:
AJAX (Asynchronous Javascript and XML)
o O AJAX é uma combinação de várias tecnologias já banalizadas na
internet: Javascript; XML (eXtensible Markup Language); XSLT
(Extensible Stylesheet Language Transformations). Com a conjugação
destas tecnologias é possível obter informação do servidor assincronamente
sem interferir com o comportamento e o aspecto da página que está a ser
representada. Esta funcionalidade, atendendo a que evita a necessidade de
representação do resultado numa nova página, veio permitir um aumento
considerável de dinamismo e interactividade na Web.
Java FX
o JavaFX é uma plataforma de software multimédia, desenvolvida pela Sun
Microsystems baseada em Java para a criação e disponibilização de RIAs.
A grande vantagem do JavaFX é que pode ser executado em vários
dispositivos diferentes, como por exemplo: telemóveis, PDAs e consolas
de jogos.
Microsoft Silverlight
o O Silverlight é um acessório para o browser que permite a execução de
animações e aplicações dinâmicas e, tal como o Flex, pode tirar partido de
tecnologia vectorial. A grande vantagem é a possibilidade de integrar áudio
e vídeo no browser dentro da própria aplicação. O Silverlight utiliza
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
38
XAML (Extensible Application Markup Language), uma linguagem
declarativa proposta pela Microsoft. Esta linguagem é utilizada na
aplicação cliente para carregar conteúdos dinâmicos a partir do servidor.
Adobe FLEX
o O FLEX é um Framework OpenSource que permite o desenvolvimento de
aplicações dinâmicas na Web, baseadas na plataforma do Macromedia
Flash.
Adobe AIR (Adobe Integrated Runtime)
o O Adobe AIR permite o desenvolvimento de aplicações multi-plataforma
tirando partido de um conjunto de tecnologias: Flash; Flex e Html. Esta
tecnologia apresenta o grande problema de necessitar de uma instalação
local de um ficheiro assinado digitalmente. Com este requisito local, não é
realmente um facilitador para o desenvolvimento SaaS. De qualquer das
formas, poderá ser contornado o problema com a descarga no momento da
execução, simulando assim um ambiente 100% na internet.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
39
5 Quadro de medidas
Neste capítulo é apresentado um quadro de medidas que tem em vista a capacitação
organizacional para responder aos desafios decorrentes da adopção do modelo SaaS,
anteriormente analisados nos capítulos 3 e 4. Estas medidas pretendem apoiar a empresa na
ponderação sobre o investimento no modelo SaaS e qual o melhor momento para reagir.
O resumo é baseado no estudo desenvolvido sobre o tema e no conhecimento existente sobre
a organização.
Os objectivos específicos a atingir enquadram-se nos seguintes pontos:
1. Alertar para os aspectos menos óbvios na adopção do modelo SaaS
2. Ajudar na tomada de decisão sobre o investimento neste novo paradigma
3. Minimizar o impacto na mudança, no caso da Sage Portugal optar por investir
5.1 Enquadramento geral e motivação para o investimento
Os produtos standard cada vez mais respondem, de forma ajustada, aos requisitos essenciais
dos clientes, sendo percepcionados como commodities e dificilmente evidenciam
características que justifiquem uma grande diferenciação de preços. Por outro lado, os clientes
querem tirar partido de todas as funcionalidades dos produtos, pelo que os serviços de apoio
ao cliente e de formação associada ganham uma importância acrescida no negócio das
empresas de software.
As empresas têm necessidade de criar mecanismos de recorrência na renovação destes
contratos de serviço pelo que aumentam a frequência de lançamento de funcionalidades,
tornando a utilização do produto quase num modelo de aluguer. Um cliente que não tenha um
contrato de serviço ficará rapidamente com a aplicação obsoleta ou terá custos elevados para
actualização.
Este funcionamento torna-se muito próximo do modelo de negócio SaaS. A grande diferença
consiste no aspecto técnico de entrega da aplicação como produto e não como Serviço.
Desde que sejam quebradas as barreiras iniciais de confiança e que a tecnologia permita uma
experiência de utilização comparável será inevitável, pelo menos em alguns segmentos,
fornecer soluções como serviço.
Como referido nos capítulos anteriores, esta mudança não pode ser encarada superficialmente
e terá que ser devidamente ponderada nas várias vertentes da organização.
O novo modelo trará um conjunto de riscos associados que devem ser devidamente
acautelados embora, por outro lado, facilitará vários aspectos na perspectiva do produtor.
De seguida é apresentada uma síntese dos principais eixos a considerar sendo que, para cada
tema, será referida uma medida de minimização do impacto.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
40
5.2 Preparação interna
O modelo SaaS só será bem sucedido se existir de facto uma mudança de atitude nas várias
vertentes da empresa. Tal como no teatro, deverá existir uma grande preparação nos
bastidores para que tudo corra sem surpresas no palco. Esta atitude deverá ser assumida por
todos os intervenientes com uma focalização na experiência proporcionada em cada iteração
do cliente.
O novo modelo organizacional terá que ser difundido a partir da gestão de topo
através das várias direcções. A mudança não pode ser encarada como um aspecto
meramente técnico, nem poderá ser vista como uma oferta complementar de mais um
produto ou de uma área de negócio isolada.
Dada a importância do tema, é sugerida a constituição de uma equipa transversal aos
vários departamentos que possa tratar da elaboração prévia de um plano estratégico,
e de um plano de acções.
Os planos devem ser posteriormente difundidos por toda a organização, com o devido
patrocínio da administração, de forma a conseguir uma visão comum sobre a
importância e a forma de abordar o tema SaaS.
5.3 Impacto financeiro provocado pelo novo modelo de remuneração
Com a venda de software como produto, são conseguidas receitas no início do negócio
decorrentes da venda de licenças e serviços de implementação.
No modelo SaaS estas receitas são diluídas no contrato de serviço, pelo que existirá uma
recorrência constante, mas em contrapartida uma menor geração de cash-flows.
O sucesso de uma empresa ou unidade de negócio SaaS não pode ser visto pelo crescimento
das receitas, pelo menos no momento de transição de paradigma. As métricas sobre
angariação de novos clientes, tempo de retenção de clientes, previsibilidade e visibilidade de
cash flows e ainda o diferimento das receitas no balanço são os indicadores mais fiáveis para
avaliação do estado do negócio.
Na venda de um produto o custo marginal é quase desprezível enquanto que na venda de um
serviço existirá um custo significativo associado ao alojamento da aplicação, informação e
consequente utilização de largura de banda. Este factor implica necessariamente uma
diminuição significativa da margem bruta.
Será importante ter este aspecto em conta para que seja devidamente salvaguardado o
impacto inicial sobre os indicadores financeiros no momento da mudança de
paradigma. O preço do serviço terá que incluir de alguma forma o custo da plataforma.
Eventualmente poderá ser conseguido recorrendo a financiamento indirecto através de
ferramentas de marketing, para que o cliente não fique prejudicado no custo final.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
41
5.4 Barreiras culturais
Para ter sucesso na implementação do modelo SaaS a empresa terá que ultrapassar várias
barreiras psicológicas provocadas pela redefinição da relação com os parceiros e cliente,
diferente proposta de valor e posicionamento como uma empresa de Serviços.
Nesta fase, os valores da empresa Integridade e Confiança assumem um papel
fundamental. Só com uma relação transparente e baseada nestas premissas será
possível estabelecer uma dinâmica de mudança com vantagens para ambas as partes.
A relação com o parceiros deverá ser totalmente transparente e devem ficar à partida
claramente definidas as fronteiras sobre os serviços a prestar ao cliente.
Para os clientes, todas as condições de utilização devem ficar claras, evitando assim a
geração de falsas expectativas em relação ao serviço fornecido.
5.5 Remuneração dos Parceiros e da Equipa de vendas
O SaaS é geralmente vendido num modelo de pagamento por utilização, onde, tal como a
factura da água ou electricidade, o valor a pagar é variável consoante o tempo de utilização do
recurso. Com a venda de um produto, o parceiro e o comercial sabem à partida qual a
percentagem de remuneração no momento do negócio. No modelo SaaS perante uma venda,
para além do valor recebido ser menor no momento inicial do negócio, existirá uma
imprevisibilidade quanto à frequência de utilização do recurso. A vantagem principal deste
modelo é a dependência do serviço ou seja o cliente não poderá continuar a utilizar a
aplicação sem manter o contrato activo. Desde que as expectativas do cliente sejam garantidas
será um modelo de continuidade que garante também previsibilidade na equipa de vendas.
A empresa terá que encontrar mecanismos que minimizem o impacto negativo em
novas subscrições do serviço. O adiantamento de um valor estimado através de uma
perspectiva de utilização que venha a ser ajustado ao longo do tempo pode constituir
uma das medidas a implementar para fazer face ao impacto em análise.
5.6 Plano de Risco
Existem novos factores de risco inerentes ao negócio SaaS.
Os principais riscos do modelo SaaS:
1) Dependência do fornecedor da plataforma de IT e consequentes possibilidades de
falha ao nível de segurança, disponibilidade, entre outras;
2) Os picos de utilização do serviço podem gerar problemas de escalabilidade e
disponibilidade;
3) A mudança de paradigma poderá causar insatisfação na experiência de utilização da
aplicação por parte dos clientes, mesmo tendo o cuidado de manter todas as
características funcionais;
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
42
4) A dificuldade de integração de soluções por parte dos parceiros de negócio poderá ser
de alguma forma inibidora para a geração de novas subscrições;
5) A responsabilidade sobre os dados dos clientes está sujeita a várias falhas de perda ou
violação de informação;
6) Ao disponibilizar a aplicação através da Web ficará automaticamente sujeita aos mais
variados tipos de ataques;
7) A fraca maturidade tecnológica implica necessariamente o risco de apostar numa
linguagem ou framework de desenvolvimento que poderá não ter a evolução desejada;
8) A impossibilidade de adaptar as aplicações actuais para a venda como serviço sem a
reescrita para uma nova arquitectura. Qualquer projecto desta dimensão acarreta
grandes riscos.
Constitui uma medida crítica preparar um plano de monitorização que garanta
previsibilidade e ao mesmo tempo rapidez de resposta perante uma catástrofe
imprevista.
Complementarmente, deverá existir um alinhamento de todos os departamentos de
forma a maximizar a agilidade de resposta e manter a satisfação do cliente.
5.7 Preparação dos serviços de suporte
O suporte a clientes deverá estar preparado para os novos desafios criados pela utilização de
aplicações alojadas. No modelo tradicional um dos grandes problemas dos serviços de suporte
está na imprevisibilidade e desconhecimento do ambiente onde a aplicação está a ser
executada. Actualmente, qualquer produtor de software utiliza um conjunto variado de
componentes de terceiras partes. A coexistência no mesmo ambiente de aplicações de vários
fornecedores, aliada à gestão de versões dos componentes de terceiros, cria desafios
importantes às equipas de desenvolvimento e suporte. Neste contexto complexo, a maioria das
situações só pode ser resolvida mediante um acesso de telemanutenção.
A utilização de uma aplicação alojada num ambiente controlado pelo produtor vem resolver
todos estes problemas e liberta a equipa de serviços para outro tipo de preocupações.
Mediante a exposição de uma qualquer incidência será necessário, por vezes, simular o
ambiente de execução na mesma sessão de trabalho do cliente.
Os sistemas devem estar preparados para passar a execução de uma dada sessão para
o contexto dos serviços, que assumirá o comando da aplicação como se tratasse de uma
telemanutenção no cliente.
A experiência de utilização de uma aplicação alojada pode ser afectada por
congestionamentos de tráfego ou até indisponibilidade em picos de utilização. Estas situações
geram naturalmente contactos com os serviços e requerem um plano adequado de resposta
para uma correcta gestão de expectativas.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
43
Assume-se como medida fundamental dar a conhecer os indicadores de performance a
todos os intervenientes na relação com o cliente.
Adicionalmente, devem existir ferramentas automáticas de alerta para garantir que
todos os clientes são previamente avisados sobre falhas ou momentos de maior tráfego
que possam ser antecipados.
A relação directa com todos os clientes, sem o filtro criado pelo canal de revenda, aumenta
drasticamente o número de contactos com os serviços técnicos.
Para garantia de uma boa experiência, as equipas devem ser devidamente
dimensionadas para a nova realidade SaaS.
5.8 Preparação da equipa de R&D
Como referido no Capítulo 4, existem vários factores críticos a considerar na equipa de
Investigação e Desenvolvimento. As mudanças não se circunscrevem apenas aos aspectos
tecnológicos, atendendo a que existem significativas alterações processuais e novas
exigências e requisitos na construção de serviços aplicacionais.
Os maiores impactos para a equipa de R&D concentram-se nas seguintes áreas:
1) Garantia de segurança e escalabilidade do serviço
2) Novos desafios de integração de soluções
3) Novos desafios na personalização do serviço para cada cliente
4) Gestão ou subcontratação da infra-estrutura de suporte ao serviço (ou Cloud)
5) Novas tecnologias inerentes ao desenvolvimento SaaS (Web 2.0, RIAs, SOA,
Cloud computing)
6) Desenho da arquitectura de dados Multi-Tenant
7) Alteração de processos de Engenharia de Software (Services Based Software
Engineering) respeitantes ao planeamento, gestão de versões e manutenção de
produtos.
A conjugação destes factores, provoca uma necessidade de reconfiguração da estrutura e
dinâmicas da equipa, definição de novos processos e preparação dos recursos para este novo
desafio.
Sugere-se a constituição de uma equipa específica para desenvolvimento SaaS que
para além de se preparar para o novo paradigma tenha a responsabilidade de
disseminar conhecimento nas restantes áreas do departamento.
Será muito importante reservar o devido tempo para investigação sobre a melhor
arquitectura, tecnologia a utilizar e infra-estrutura. Dada a imaturidade da
tecnologia é indispensável o desenvolvimento de uma prova de conceito com a
integração das várias componentes. Neste aspecto será relevante a recolha de
conhecimento e experiência internacional dentro do Grupo e, ao mesmo tempo, de
outras instituições locais com valor reconhecido em Engenharia de Software.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
44
As mudanças provocadas no processo de desenvolvimento implicam
necessariamente a apropriação e desenvolvimento de uma nova forma de
trabalhar, muito diferente da utilizada para a construção de produtos. É
fundamental a redefinição de processos de planeamento, lançamento de
actualizações, monitorização e manutenção do funcionamento do serviço. Deve ao
mesmo tempo ser simulada a actualização de novas funcionalidades e correcção
de anomalias, avaliando o impacto no serviço e garantindo que o processo pode
ser desencadeado sem qualquer paragem por parte dos clientes.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
45
6 Conclusões e perspectivas de trabalho futuro
Como se pode ver na análise do Estado da Arte existem diversas evidências que sustentam a
tendência de evolução do modelo SaaS no mercado de Software de Gestão empresarial
[9][8][30].
Perante este facto, torna-se fundamental a definição de uma estratégia de abordagem que
contemple os vários factores de impacto na adopção do SaaS. A análise de impacto tratada
neste estudo foi desenvolvida tendo em conta dois eixos principais de investigação:
1) O impacto no modelo de negócio, analisando as várias vertentes da empresa e a
sua relação com a área de I&D
2) O impacto na área de I&D, em particular nos aspectos relacionados com a
Engenharia de Software
Estes dois eixos foram escolhidos pela grande diferença do contexto, mas também por não ser
possível dissociar a relação entre as duas perspectivas. Por um lado, na área técnica existe
uma preocupação sobre o desafio tecnológico e sobre o novo paradigma de computação
distribuída. Por outro lado, afigura-se um elemento nuclear para qualquer decisor explorar os
novos desafios e antecipar o efeito da mudança no contexto global da organização.
Aspectos gerais, para uma prévia contextualização
O SaaS é um modelo totalmente disruptivo e, para ter sucesso, depende do envolvimento da
administração de uma prévia preparação transversal em toda a organização.
Em algumas empresas de software assistimos a uma tendência de conversão do modelo de
negócio para serviços, apesar de continuarem a fornecer as aplicações como produtos. Nestes
casos, a mudança para o SaaS acarreta menores necessidades de transformação e
reestruturação, atendendo a que apesar de existirem diferenças significativas, principalmente
nas áreas de I&D e Serviços, os impactos nos restantes departamentos poderão ser
minimizados. Nestas empresas o SaaS aparece como uma evolução do negócio e vem
colmatar algumas dificuldades sentidas na distribuição do software como produto.
Tal como acontece na grande maioria das indústrias, o desenvolvimento de software
tradicional implica incorporar vários componentes no produto desenvolvidos por um leque
alargado de fornecedores. Embora exista uma elevada dependência, estes componentes após
incorporação têm um comportamento previsível no contexto do produto desenvolvido. O
modelo SaaS só se tornará viável para a maioria dos fornecedores através da subcontratação
de um fornecedor de infra-estrutura ou Cloud. Neste caso, existirá uma relação de
dependência, onde não é fornecido um componente como produto, mas sim sob a forma de
serviço, onde o comportamento poderá variar consoante a iteração.
O modelo SaaS apesar de trazer várias vantagens para o produtor apresenta um custo marginal
mais elevado do que a venda de um produto. Este custo está relacionado com a manutenção
ou subcontratação da infra-estrutura e terá que ser de alguma forma acautelado para que se
negócio garanta a mesma margem bruta.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
46
Modelo de negócio SaaS
Quanto ao modelo de negócio, o SaaS obriga a reequacionar toda a organização. Uma
mudança deste tipo favorece em primeiro lugar a emergência de empresas incumbentes, que
têm a grande vantagem de não se preocuparem com a gestão da base instalada de clientes nem
com a necessidade de transformar o canal de revenda. Os fornecedores tradicionais podem,
por um lado, actuar como barreiras à entrada, através da relação privilegiada que têm com os
seus clientes e, por outro lado, podem desenvolver uma análise contínua do mercado para
identificar potenciais aquisições ou novas áreas de negócio.
Os serviços disponibilizados na internet estão de alguma forma conotados com baixo custo,
em particular no momento da subscrição inicial. Os utilizadores, por omissão pensam que este
tipo de serviços é oferecido ou pelo menos será de fácil acesso. Os produtores SaaS terão
necessariamente que encontrar definições de preços baseados na utilização que proporcionem
mecanismos de discriminação, maximizando assim o valor conseguido nos clientes, com
maior valor percebido sobre serviço prestado.
Com a elevada dependência que o cliente passa a ter do seu fornecedor, as garantias de nível
de serviço dadas sobre a disponibilidade e segurança assumem um papel diferenciador no
mercado e podem justificar assim o aumento de preços e a qualidade percebida.
O SaaS acarreta uma enorme responsabilidade sobre a manutenção da informação alojada
respeitante ao negócio dos clientes. A sensibilidade desta informação e os aspectos legais
inerentes à sua preservação obriga a um investimento, que subestimado poderá ter
consequências graves para toda a organização.
A relação com o canal de revenda terá necessariamente que ser repensada neste novo modelo.
Para um cliente com menor nível de informação e conhecimento, o valor acrescentado pelo
VAR restringe-se à manutenção de equipamentos, instalação do produto e formação sobre as
novas características. Com a utilização de um serviço alojado no produtor, o parceiro perde
poder negocial junto do cliente e terá dificuldade em justificar o seu valor acrescentado.
Na realidade, mesmo no modelo SaaS o VAR é um actor fundamental na cadeia de valor. O
domínio prático dos detalhes processuais nas mais diversas áreas de negócio e o factor de
proximidade junto do cliente são muito difíceis de atingir pelo produtor. A integração de
soluções torna-se agora um desafio mais complexo pela real distribuição das aplicações onde
as tradicionais APIs deram lugar a WebServices.
Se o parceiro se especializar neste domínio poderá posicionar-se num patamar mais elevado,
libertando-se dos pormenores técnicos e criando um real valor acrescentado para o cliente
através da melhoria dos processos de negócio.
O Marketing tem um desafio importante na divulgação das soluções SaaS. Enquanto que um
produto é fisicamente reconhecível e as suas características são automaticamente percebidas,
um serviço só poderá ser valorizado mediante uma experiência de utilização. O Marketing
SaaS tem à sua disposição um conjunto de variáveis dificilmente obtidas com a venda de um
produto. Como a aplicação é utilizada na casa do fornecedor, torna-se possível, em tempo
real, perceber quais as características mais valorizadas do produto e quais as funções com
maior frequência de utilização. A análise destas variáveis constitui um activo da maior
importância para a melhoria contínua da adaptação do serviço às reais necessidades dos
clientes.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
47
Impacto na Engenharia de Software
A construção de uma aplicação no modelo SaaS acarreta diversos aspectos com diferenças
significativas em relação ao desenvolvimento de um produto.
As diferenças podem ser enquadradas na seguinte categorização:
1) Orientações gerais a ter em conta no desenho de aplicações SaaS
2) Aspectos relacionados com a Engenharia de Software e processo de desenvolvimento
3) Tecnologias utilizadas
4) Arquitectura de dados
5) Aspectos de usabilidade e requisitos de interface com o utilizador
6) Utilização de infra-estruturas remotas de alojamento (Clouds)
Como referido na abordagem sobre o Modelo de Negócio, a preparação das pessoas e a
aculturação com esta nova realidade será eventualmente um dos maiores desafios na
mudança. Na investigação e desenvolvimento será relevada adicionalmente a necessidade de
capacitação técnica dos recursos para enfrentar a diversidade de aspectos técnicos associados
a esta nova forma de desenvolvimento.
A investigação e desenvolvimento de produto, poderia passar a ser equacionada como um
fornecedor interno, que teria que responder aos requisitos colocados pelo Marketing e pelas
várias unidades de negócio. No modelo SaaS é imprescindível uma relação de contínua
colaboração entre as várias vertentes da organização e a I&D não se podendo implementar o
cenário em análise de forma fragmentada e atomista.
Atendendo à mudança de paradigma equacionada ao longo do estudo, a análise dos impactos
decorrentes da adopção do modelo SaaS, enquanto janela de oportunidade no contexto
empresarial, afigura-se de vital importância para a sustentabilidade, viabilidade e
competitividade das organizações empresariais.
Nesta perspectiva, o estudo desenvolvido pretendeu constituir-se como um contributo para
estimular os processos de generatividade, adaptabilidade e inovação organizacional no
contexto de transição entre paradigmas, sistematizando a constelação de medidas de
capacitação organizacional.
Perspectivas de trabalho futuro
O trabalho desenvolvido, abordou vários aspectos relevantes da transformação da
investigação e desenvolvimento do produto para serviço. Não seria possível transmitir a ideia
global sobre o impacto no R&D e no Modelo de Negócio em geral sem esta abordagem
sistémica. Esta abrangência de temas, implicou uma de alguma forma menor detalhe em
algumas áreas. Particularmente os aspectos técnicos relativos à arquitectura, tecnologia e
infra-estrutura a utilizar requerem um trabalho mais profundo de análise e reflexão e
desenvolvimento de provas de conceito. Só desta forma será possível avaliar de uma forma
mais concreta todos os aspectos de usabilidade e experiência de utilização.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
48
Referências e Bibliografia
[1] TripleTree e SIIA, “SOFTWARE AS A SERVICE:
CHANGING THE PARADIGM IN THE SOFTWARE INDUSTRY,” Jul. 2004.
[2] SIIA, “Software as a Service: Strategic Backgrounder,” Fabruary. 2001.
[3] “SaaS - Wikipedia,” Mai. 2009.
[4] A. Wohl, Succeeding AT SaaS: Computing in the Cloud, 2008.
[5] A. Lassila, “TAKING A SERVICE-ORIENTED PERSPECTIVE ON SOFTWARE
BUSINESS: HOW TO MOVE FROM PRODUCT BUSINESS TO ONLINE SERVICE
BUSINESS,” IADIS International Journal, vol. 4, 2006, pp. 70-82.
[6] M. Turner, D. Budgen, e P. Brereton, “Turning Software into a Service,” IEEE Computer
Society, vol. 36, Out. 2003, pp. 33-44.
[7] M. Aramand, “Software products and services are high tech? New product development
strategy for software products and services,” Technovation, vol. 28, 2008, pp. 154-160.
[8] G. , “Market Trends: Software as a Service in the Enterprise Application Software
Markets, Worldwide, 2007,” 2007.
[9] S. Mertz, C. Eschinger, T. Eid, H. Huang, C. Pang, e B. Pring, “Market Trends: Software
as a Service, Worldwide, 2008-2013,” Mai. 2009.
[10] M. Armbrust,, A. Fox, R. Griffith, A. D.Joseph, R. Katz, A. Konwinski, G. Lee, D.
Patterson, A. Rabkin, I. Stoica, e M. Zaharia, “Above the Clouds: A Berkeley View of
Cloud Computing,” Fev. 2009.
[11] R. Buyya, C.S. Yeo, e S. Venugopal, “Market-Oriented Cloud Computing:
Vision, Hype, and Reality for Delivering IT Services as Computing Utilities,”
Proceedings of the 10th IEEE International Conference on High Performance
Computing and Communications, Set. 2008, pp. 5-13.
[12] D. Chappell, “INTRODUCING THE AZURE SERVICES PLATFORM AN EARLY
LOOK AT WINDOWS AZURE, .NET SERVICES, SQL SERVICES, AND LIVE
SERVICES,” Out. 2008.
[13] H. Kaminski e M. Perry, “SLA Negotiation System Design Based on Business Rules,”
IEEE, 2008, pp. 609 - 612.
[14] L. Tan, C. Chi, e J. Deng, “Quantifying Trust Based on Service Level Agreement for
Software as a Service,” 2008 32nd Annual IEEE International Computer Software and
Applications Conference, Turku, Finland: 2008, pp. 116-119.
[15] L. Morais, “Cuidados com alojamento de conteúdos em entidades terceiras,” 2007.
[16] A. Cavoukian, “Privacy in the clouds,” Identity in the Information Society, 2008.
[17] M.A. Cusumano, “The Changing Software Business: Moving from Products to
Services,” Computer, vol. 41, 2008, pp. 20-27.
[18] SIIA, “CHANNELS FOR THE NEW SAAS INDUSTRY,” 2007.
[19] M. Hoogvliet, “SaaS Interface Design: Designing web-based software for business
purposes,” 2008.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
49
[20] M. Turner, D. Budgen, e P. Brereton, “Turning Software Into a Service,” IEEE
Computer Society, vol. 36, Out. 2003, pp. 38-44.
[21] Nitu, “Configurability in SaaS (software as a service) applications,” ISEC '09:
Proceeding of the 2nd annual conference on India software engineering conference, pp.
19--26.
[22] M. SAEED e M. JAFFAR-UR-REHMAN, “Enhancement of Software Engineering by
Shifting From Software Product to Software Service,” IEEE Computer Society,
Muhammad Ali Jinnah University, Islamabad, Pakistan: IEEE, 2005, pp. 302 - 308.
[23] E.R. Olsen, “Transitioning to Software as a Service: Realigning Software Engineering
Practices with the New Business Model,” 2006 IEEE International Conference on
Service Operations and Logistics, and Informatics, Shanghai, China: 2006, pp. 266-271.
[24] J. Espadas, “Application Development over Software-as-a-Service platforms,” The Third
International Conference on Software Engineering Advances, Out. 2008, pp. 97-104.
[25] E. Castro-Leon e J. He, “Virtual Service Grids: Integrating IT with Business Processes,”
IT Professional, vol. 11, 2009, pp. 7-11.
[26] C. Gianpaolo, F. Chong, e E. Pace, “Efficient Software Delivery Through Service-
Delivery Platforms,” The Architecture Journal - MSDN, vol. 12, Jul. 2007.
[27] F. Chong, G. Carraro, e R. Wolter, “Building Distributed Applications: Multi-Tenant
Data Architecture,” MSDN, Jun. 2006.
[28] S. Aulbach, T. Grust, D. Jacobs, A. Kemper, e J. Rittinger, “Multi-Tenant Databases for
Software as a Service: Schema-Mapping Techniques,” Vancouver, Canada: 2008, pp.
1195-1206.
[29] K. Lindholm, “The User Experience of Software-as-a-Service Applications,”
Information & Service Design Symposium, 2007.
[30] B. Desai, V. Weerakkody, e W. Currie, “Market Entry Strategies of Application Service
Providers: Identifying Strategic Differentiation,” Proceedings of the 36th Hawaii
International Conference on System Sciences (HICSS’03).
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
50
Anexo A : Legislação portuguesa a respeito da protecção de dados pessoais e
preservação de documentos fiscais
Os aspectos mais relevantes na legislação Portuguesa a respeito ao tratamento de dados
informáticos com influência directa no modelo SaaS e no software de gestão em particular,
têm em conta fundamentalmente o tratamento e preservação de dados pessoais e o tratamento
de dados fiscais, nomeadamente no que diz respeito ao arquivo e transmissão de facturas ou
documentos equivalentes.
Tratamento de dados pessoais segundo Artigo 35º da Constituição da República Portuguesa:
1) Todos os cidadãos têm o direito de acesso aos dados informatizados que lhes digam
respeito, podendo exigir a sua rectificação e actualização, e o direito de conhecer a
finalidade a que se destinam, nos termos previstos na lei.
2) A lei define o conceito de dados pessoais, bem como as condições aplicáveis ao seu
tratamento automatizado, conexão, transmissão e utilização, e garante a sua protecção,
designadamente através de entidade administrativa independente.
3) A informática não pode ser utilizada para tratamento de dados referentes a convicções
filosóficas ou políticas, filiação partidária ou sindical, fé religiosa, vida privada e
origem étnica, salvo mediante consentimento expresso do titular, autorização prevista
por lei com garantias de não discriminação ou para processamento de dados
estatísticos não individualmente identificáveis.
4) É proibido o acesso a dados pessoais de terceiros, salvo nos casos excepcionais
previstos na lei.
5) É proibida a atribuição de um número nacional único aos cidadãos.
6) A todos é garantido livre acesso às redes informáticas de uso público, definindo a lei o
regime aplicável aos fluxos de dados transfronteiras e as formas adequadas de
protecção de dados pessoais e de outros cuja salvaguarda se justifique por razões de
interesse nacional.
7) Os dados pessoais constantes de ficheiros manuais gozam de protecção idêntica à
prevista nos números anteriores, nos termos da lei.
Responsabilidades e obrigações sobre os ficheiros com dados pessoais, definida na Lei da
protecção de dados pessoais (Lei nº 67/98):
Notificar a CNPD dos tratamentos de dados pessoais que pretenda efectuar, antes do
seu início, isto é, antes de começar a recolher os dados pessoais.
Notificar a CNPD de quaisquer alterações posteriores que venham a ocorrer.
Proceder ao tratamento de dados de forma lícita e com respeito pelo princípio da boa
fé.
Recolher os dados para finalidades explícitas e legítimas.
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
51
Recolher apenas os dados adequados, pertinentes e não excessivos em relação à
finalidade para que são recolhidos e tratados.
Prestar ao titular dos dados todas as informações exigidas por lei (artigo 10º), sem
descuidar a informação específica para a recolha de dados em redes abertas.
Manter os dados exactos e actualizados, assegurando que são apagados ou rectificados
os dados inexactos ou incompletos.
Não utilizar os dados para uma finalidade diferente daquela que motivou a recolha.
Caso pretenda uma outra utilização, deverá solicitar a autorização prévia da CNPD e o
consentimento dos titulares dos dados.
Assegurar o exercício do direito de acesso, sem restrições e sem demoras, aos titulares
dos dados. As informações registadas sobre o titular devem ser-lhe transmitidas em
linguagem clara e rigorosamente correspondente ao conteúdo do registo.
Garantir o exercício do direito de rectificação dos titulares dos dados.
Garantir gratuitamente o direito de oposição ou de eliminação dos dados utilizados
para marketing directo, quando requerido pelo titular.
Assegurar o consentimento prévio dos titulares dos dados ao envio de comunicações
electrónicas não solicitadas, quando não se trate de clientes. Caso o titular seja cliente,
deverá ser dada a possibilidade de o titular se opor ao tratamento dos seus dados para
efeitos de marketing em todas as comunicações electrónicas efectuadas.
Recolher e manter as declarações de consentimento expresso do titular para o
tratamento de dados pessoais, quando tal for exigido.
Implementar as medidas de segurança necessárias para protecção da informação,
evitando a consulta, modificação ou destruição dos dados por pessoa não autorizada, e
que permitam detectar eventuais desvios de dados.
Respeitar o sigilo profissional relativamente aos dados pessoais tratados.
Não realizar interconexão de dados pessoais, salvo disposição legal ou autorização da
CNPD.
Não comunicar dados a terceiras entidades que não tenham os seus tratamentos
notificados à CNPD.
Destruir os dados pessoais logo que findo o período de conservação autorizado.
Interromper imediatamente o tratamento de dados pessoais, quando ocorra
desconformidade com a lei e tenham recebido da entidade competente directriz nesse
sentido.
Regras de arquivo e transmissão de documentos de facturação electrónica
Uma factura é um documento comercial cuja emissão é, em regra, obrigatória para todos os
transmissores de bens ou prestadores de serviços, sendo um elemento essencial para o
Imposto sobre o Valor Acrescentado (IVA), na medida em que confere aos adquirentes dos
bens ou aos destinatários dos serviços um direito de crédito perante o Estado, que se
consubstancia no exercício do direito à dedução do imposto nela incorporado.
A factura electrónica é o mesmo documento comercial, mas reduzido a um formato
electrónico, isto é, "desmaterializado". A factura electrónica tem o mesmo valor que a factura
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
52
em papel, desde que contenha as menções obrigatórias para qualquer factura, e satisfaça as
condições exigidas na lei para garantir a autenticidade da sua origem e a integridade do seu
conteúdo.
O Artigo 52º do CIVA refere:
1 - Os sujeitos passivos são obrigados a arquivar e conservar em boa ordem durante os 10
anos civis subsequentes todos os livros, registos e respectivos documentos de suporte,
incluindo, quando a contabilidade é estabelecida por meios informáticos, os relativos à
análise, programação e execução dos tratamentos.
5 - Os sujeitos passivos com sede, estabelecimento estável ou domicílio em território nacional
que pretendam proceder ao arquivamento em suporte electrónico dos documentos referidos no
número anterior fora do território da Comunidade devem solicitar autorização prévia à
Direcção-Geral dos Impostos, a qual pode fixar condições específicas para a sua efectivação.
6 - Os sujeitos passivos que não disponham de sede, estabelecimento estável ou domicílio em
território nacional que pretendam manter o arquivo dos livros, registos e demais documentos,
incluindo os referidos no n.º 4, fora do território da Comunidade, devem solicitar autorização
prévia à Direcção-Geral dos Impostos, a qual pode fixar condições específicas para a sua
efectivação.
7 - É ainda permitido o arquivamento em suporte electrónico das facturas ou documentos
equivalentes, dos talões de venda ou de quaisquer outros documentos com relevância fiscal
desde que processados por computador, nos termos definidos por portaria do Ministro das
Finanças
A possibilidade da emissão e conservação de facturas e documentos equivalentes por via
electrónica é regulada pelo Decreto-Lei 196/2007 de 15 de Maio que refere em particular:
Artigo 2º – Sistemas informáticos de facturação por via electrónica
1) Os sistemas informáticos de emissão, de recepção e de arquivamento de facturas ou
documentos equivalentes em formato electrónico devem garantir as seguintes
funcionalidades:
a) A autenticidade da origem de cada factura electrónica ou documento equivalente;
b) A integridade do conteúdo da factura electrónica ou documento equivalente;
c) A integridade da sequência das facturas electrónicas ou documentos equivalentes;
d) A validação cronológica das mensagens emitidas como facturas electrónicas ou
documentos equivalentes;
e) O arquivamento, em suporte informático, das facturas ou documentos equivalentes
emitidos e recebidos por via electrónica;
f) A manutenção, durante o período previsto no artigo 52º do Código do IVA, da
autenticidade, integridade e disponibilidade do conteúdo original das facturas e
documentos equivalentes emitidos e recebidos por via electrónica;
g) O não repúdio da origem e recepção das mensagens;
SaaS: Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço
53
h) A não duplicação das facturas ou documentos equivalentes emitidos e recebidos
por via electrónica;
i) Mecanismos que permitam verificar que o certificado utilizado pelo emissor da
factura electrónica ou documento equivalente não se encontra revogado, caduco ou
suspenso na respectiva data de emissão.
2) As funcionalidades dos sistemas informáticos de emissão, de recepção e de
arquivamento de facturas ou documentos equivalentes em formato electrónico podem
ser asseguradas, no todo ou em parte por terceiros em nome e por conta do sujeito
passivo.
Artigo 4º – Conservação
1) As facturas e documentos equivalentes emitidos e recebidos por via electrónica devem
ser conservados, sem alterações, por ordem cronológica de emissão e recepção.
2) O processamento automático efectuado pelos sistemas informáticos de facturação por
via electrónica deve incluir o registo dos dados relativos aos documentos mencionados
no número anterior de forma a garantir uma transferência exacta e completa dos dados
para os suportes de arquivamento.
top related