Software As Service (SaaS), Mashups… etc
Este novo(será?) modelo de negócios vem revolucionando a forma como iremos construir nossas aplicações futuras. Em vez de nos preocuparmos em (re) desenvolver nossas aplicações, iremos apenas acessar(ws,rest) API públicas(ou pagas… tsc tsc) que já implementem o serviço necessário.
Esta idéia não é necessariamente nova, pois a maior promessa do Desenvolvimento Baseado em Componentes (DBC) é justamente a mesma. A grande diferença é que no SaaS não existe deploy dos componentes(API) e os vendedores de serviço possuem um maior controle sobre seu negócio (leia-se fiscalização, pirataria ZERO!!) e liberdade de negociação com os compradores do serviço.
Mas o que seria esse maior controle? Pense que no modelo de negócios atual software é considerado como um produto fechado (Televisão, Computador, Geladeira…) , ou seja, a principal esquema de negóciação é aquele em que o usuário deseja um sistema, vai lá na prateleira (Ou na softwarehouse), compra e leva para casa para a implantação. Este modelo tradicional é conhecido como pay per copy(pague por cópia), e atualmente possui um alto grau de pirataria, pois com cada cópia do software vai um serial válido para o registro do software. E como todos nós sabemos, estes seriais podem ser compartilhados ou gerados (com os key gen’s). Observe que é a empresa de software que arca com os prejuízos da pirataria.
Neste novo modelo o software é considerado como serviço (TV a Cabo, Luz, Esgoto). Ou seja, de acordo com seu desejo (ou necessidade) você vai lá adquire o serviço(Um mashup com o Google Maps e um banco de dados geográfico da sua cidade, por exemplo) e quando não mais desejar você vai lá e cancela. Este modelo é conhecido como pay per use (pague pelo uso), a vantagem deste modelo é justamente o usuário ser responsável pela utilização do sistema principalmente sobre preço que irá pagar, além de que o vendedor do serviço sabe com certeza quem está utilizando o serviço, agora sendo capaz de bloquear os pirateiros.
Apesar de bloquear os pirateiros, este modelo não está imune a pirataria. Pois, assim como na vida real irá existir a figura do “gato” (Sim… ele mesmo, o mesmo “gato” da luz e da tv a cabo…), ou seja, a pessoa que terá acesso ao serviço utilizando a credencial de outra pessoa.
Observe que neste modelo a pessoa “lesada” é quem fica com o prejuízo da pirataria.
Sendo assim o Software as Service não vem apenas facilitar a criação rápida de aplicativos (Reuso de fato), mas também proteger as empresas produtoras de software com respeito a pirataria.
Você tem dúvidas de que o SaaS irá pegar?
- Adobe Photoshop Versão Online
- ThinkFree representa alternativa ao pacote Office
- Adobe Apollo (Plataforma da adobe em que os aplicativos web interagem com o Desktop)
Obs.: Neste post ainda ficou faltando abordar a liberdade de comercialização dos serviços no SaaS.
Por fim, vai um videozinho do youtube sobre a plataforma Apollo.
Gustavo disse,
Abril 11, 2007 às 12:47 pm
Boa!!!
Mas me diz uma coisa. Quais ambientes de execução poderiam ser usados estes serviços? Os exemplos citados são na Web, existe algum outro?
E sobre a disponibilidade dos serviços? É muito cômodo eu depender apenas de energia elétrica para iniciar meu editor de texto. Caso ele esteja sendo provido como serviço, eu não teria uma dependência de banda, hardware, etc que pudesse prejudicar o acesso?
Falow yX
yurix disse,
Abril 11, 2007 às 8:38 pm
Ambientes como a plataforma Apollo que permite uma grande interação entre a aplicação (Web) e o ambiente Desktop.
E a idéia de SaaS também se aplica a aplicações desktop através dos já conhecidos web services. Uma utilização hipotética seria uma aplicação de automação comercial verificar um web service servido pelo SERASA por exemplo. Neste caso, o SERASA poderia cobrar da empresa por invocação de método. A vantagem da empresa seria não precisar manter todo processo de consulta(Telefone) ao cadastro do SERASA.
Acredito que hoje a banda não seja um fator limitante para SaS já que temos aplicações leves e robustas (Gmail por exemplo) que não consomem tantos recursos.
Sobre o SERASA é apenas uma idéia, quem sabe eles já trabalham assim…
Anderson disse,
Outubro 5, 2007 às 12:46 pm
Gostaria de entender melhor sobre como eles vao evitar a pessoa passar a senha para outra nesse sistema, por exemplo tenho um sistema que é de consulta de carros como vou desenvolver ele via net sendo que se o kara passar a senha para outro eu vou perder cliente ao inves de ganhar?
yurix disse,
Outubro 5, 2007 às 11:03 pm
Esse problema ocorre em qualquer modelo de negociação de software (seja com o compartilhamento de serial keys ou de senhas de acesso) a diferença é que o fornecedor de software pode construir modelos do tipo pagar por instância, por usuários conectados etc., pode-se até mesmo utilizar esquemas como o banco do brasil faz para permitir acesso de um computador a sua aplicação. Outro forte motivo é a natureza da aplicaçao baseada SaaS, imagine que esse sistema seja de gerenciamento de uma concessionaria de carros, qual o motivo de você passar sua senha para outro pessoa se ela vai ter acesso a todos os dados de sua empresa? Um exemplo interessante é o caso do DabbleDB(http://dabbledb.com/help/guides/pluginapi/) que oferece um serviço de banco de dados,não faz sentido distribuir uma senha de uso do serviço se voce tem dados pessoais vitais armazenados.