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.
Web2.0 Folksonomy (Tagging)? WTF?
Um dos fenômenos mais interessantes da web 2.0 é a folksonomia ou tagging, que nada mais é do que associar um contexto (várias keywords) a uma informação em uma base compartilhada. Sendo assim, a grande inovação dos sistemas tagged’s é proporcionar uma busca contextual (Filtragem de Informações) mais eficaz do que os sistemas non-taggeds.
Ou melhor:
“Tagging-based systems enable users to categorize web resources by means of tags (freely chosen keywords), in order to re-inding these resources later. Tagging is implicitly also a social indexing process, since users share their tags and resources, constructing a social tag index, so-called folksonomy.”
Yusef Hassan-Montero and Víctor Herrero-Solana
Em Improving Tag-Clouds as Visual Information Retrieval Interfaces
Legal… mas o que isso tem demais? Bom, ao meu ver o interessante é que isto demonstra que estamos em um novo estágio da internet… em que nós (Eu e você inclusive!) estamos entendendo que a internet só tem significado e utilidade se as informações existentes forem encontradas de maneira simples e eficaz. Então sempre que disponibilizar um conteúdo na web… tag nele!!
Obs.: Claro que para todos os outros problemas existe o google… quem sabe o google não cria uma base de dados universal para tag’s?? Google Base???
A review sobre o paper:
- Fala sobre um novo modelo de popular nuvens de tag’s levando em consideração a interelação entre as tags.
- Relevância para meu estudo: 4
- Inovação: 8
- Relevância para mim: 10 (Gostei do assunto…)
Component Description United!!!
Como criar um padrão de fato para descrever componentes de software?? Esta é uma pergunta interessante, mas até hoje não respondida. Seria esta a pergunta de um millhão de doláres?? Em minhas lectures sobre componentes e mercados de componentes me deparei com um mais um paper (Component Market Specification Demand and
Standardized Specification of Business Components) que apresenta informações relevantes que devem ser consideradas em uma descrição de componente… apesar do dito cujo fazer o favor de apresentar/relembrar diversos conceitos, como design by contract, the importance of component markets, composition. Sua maior importância foi justamente relembrar o meu questionamento interno sobre a importância da padronização.
Muitos esforços foram guiados neste sentido nos últimos anos, basta lembrar que em diversas conferências internacionais a descrição de componentes sempre esteve presente em algum paper.
Estes estudos e as necessidades da industria culminaram na aprovação do DRAFT da OMG para a especificação RAS (Reusable Asset Specification). Eis que o problema parecia estar resolvido e que em breve teriamos uma enxurrada de players dando suporte a especificação em suas ferramentas e repositórios… mas como de praxe(Ou praga?) isto não ocorreu (OMG hahahaha).
Para não ser mentiroso, o único player que mexeu um dedo foi a IBM que implementou em 2005 um repositório simples (RAS4W) e deu um leve suporte em sua suíte de desenvolvimento (WSAD).
Mas e agora? O que vamos fazer??? Pense que se uma especificação com grandes players (IBM, Microsoft, Flashline, ComponentSource…) não virou padrão, qual seria a chance de outra especificação tomar este lugar???
Tenho a sensação que está resposta está atrelada a tão falada WEB2.0 e seus formatos de descrição.
Claro que a idéia não é provocar uma reviravolta em todos os estudos sobre descrição de componentes…. e sim tornar a descrição algo simples e fáctivel.
Como exemplo, temos o sucesso do RSS.
Mas…. o que está abordagem difere das existentes?? Vale lembrar que a criação de um mercado GLOBAL de componentes é um dos requisitos para o sucesso do DBC, e já que esperar que todos iteroperem a nível de repositório é impraticável, poderiamos ao menos sonhar que as descrições dos assets(ativos) possam ser intercambiáveis. Já imaginou realizando uma busca no google(ou froogle) através destes metadados??? E o oráculo respondendo todos nossos anseios na busca de componentes?
Para não perder o costume, aí vai o meu review…
* Review do Paper (Relevância: 8 / Inovação: 2 )
* Obs.: Um aspecto interessante do texto são as definições de termos recorrentes.
Ex.: We define a component market as an abstract place where components are exchanged and their value is determined by the bidding process between the supplier and the user of components.
Planejamento para 2007
Como sempre atrasado e sem tempo, vou tentar elaborar um planejamento (promessa??) e as atividades que estou realizando para cumprir este plano para este ano…
- Plano: Melhorar conhecimento sobre estrutura de Dados e Algoritmos
- Atividade: Cadeira do Mestrado Complexidade de Algoritmos e Estrutura de Dados
- Plano: Criar senso crítico na área de B2B e Component Business Models
- Atividade: Leitura de White Papers
- Atividade: Comprar um livro de B2B
- Atividade: Ler este livro!!!!
- Atividade: Escrever um artigo em inglês falando sobre isto
- Plano: Ficar seguro e tranquilo quanto aos conceitos e padrões j2ee
- Atividade: Estudar intensamente os padrões J2ee do Livro Core j2ee patterns
- Atividade: Ministrar o curso de Padrões da Dataprev em junho (40hrs)
- Plano: OSGI: Fundamentos e conceitos.
- Atividade: Desenvolver um exemplo de aplicação usando OSGI
- Plano: Arquitetura de Software
- Atividade: Estudar conceitos e sua funções em um processo de software
- Plano: Repositórios de Software e Web 2.0
- Atividade: Desenvolver um repositório usando apenas web 2.0
- Atividade: Elaborar uma apresentação sobre a web 2.0 e apresentar em algum congresso/seminário.
- Atividade: Atuar como consultor
- Plano: Direito
- Atividade: Estudar direito Constitucional e Administrativo, para não ser um zé mané.
Desafios no Negócio de Componentes de Software
Normalmente as pequisas sobre DBC (CBD?) focalizam em áreas técnicas, deixando de lado um importante desafio (talvez o mais importante…) que é a venda de componentes de software. Negligenciar esta área talvez tenha sido um dos grandes fatores para a lentidão no surgimento e aceitação dos mercados de componentes (ie. ComponentSource) e até hoje uma das grandes dificuldades para a migração de empresas que se baseiam em projetos para o mundo de produtos.
O artigo apresenta uma visão geral sobre o mercado de componentes, enfatizando as dificuldades (Software standardisation, lack of quality components…) e a diferença entre o modelo tradicional de desenvolvimento (Project) para o modelo adequado para componentes (Product). A maior contribuição do trabalho é um estudo empírico sobre as relações B2B entre Customers e Component Suppliers.
OBS.: Interessante a Tabela 1 que apresenta uma comparação entre Software Project Business X Software Product Business.
Visualizar White Paper (Nina Helander & Paulina Ulkuniemi)
Meu review: 7 – Interessante, mas muito confuso.
Talvez seja a dificuldade inicial de entrar em uma nova área.
