José Ribamar Smolka Ramos
Telecomunicações
Artigos e Mensagens
ComUnidade
WirelessBrasil
Fevereiro 2010 Índice Geral
18/02/10
• Eu detesto dizer "eu avisei..."
de J. R. Smolka <smolka@terra.com.br>
para wirelessbr <wirelessbr@yahoogrupos.com.br>, celld-group <Celld-group@yahoogrupos.com.br>
data 18 de fevereiro de 2010 01:55
assunto [wireless.br] Eu detesto dizer "eu avisei..."
Pois é. Talvez alguns se lembrem deste
artigo meu que saiu no e-Thesis (está transcrito no final desta página) em
meados de 2008 . Ou não. Não importa muito.
De qualquer forma, a disputa por mind share em torno das app stores
já é, para mim, evidência suficiente do processo de erosão de valor do modelo de
negócio clássico das operadoras de telecom, principalmente as móveis.
Leiam abaixo a transcrição de notícia do Fierce Wireless sobre os acontecimentos
no MWC em Barcelona...
[ ]'s
J. R. Smolka
--------------------------------
Is fear the driving factor behind carriers' 'open' claims?
February 17, 2010 — 5:58am ET By Sue Marek
BARCELONA, Spain--Inclement weather may have wreaked havoc on some U.S.
conference-goers' flights, but crowds of wireless executives still flocked to
the Mobile World Congress annual confab here this week. Some press conferences
on Monday felt sparsely attended, but the show floor was surprisingly crowded
and bustling.
Some events even managed to attract overflow crowds, including the Microsoft
press conference on Monday, where many reporters had to view CEO Steve Ballmer's
remarks via a simulcast in an adjoining room. And the keynote address Tuesday
evening featuring Google CEO Eric Schmidt drew a huge crowd, with attendees
lining up early and jockeying to get a seat in the overflowing auditorium.
Not surprisingly, "open" was a common theme at the show. In a keynote address
Tuesday morning, Vodafone CEO Vittorio Colao touted his company's openness to
content providers, app stores and application developers while also chastising
companies like Google and Yahoo! for what he considers their potentially
monopolistic hold on the Internet search and advertising market. And Vodafone
was not alone. Newly minted GSMA member Verizon Wireless also pushed its open
message during a press conference with Skype announcing a custom Skype Mobile
application for its smartphones.
But not everyone fell for the "open" mantra. Alcatel-Lucent CEO Ben Verwayyen
said during his keynote address that followed Colao: "Everyone claims to be
open. Fine. But who is going to stand up here and say, 'I am closed?' Fine, we
are open. But where is the business model?"
I suspect fear is behind all the claims of "openness." When I heard about the
GSMA's Wholesale Applications Community, which was admittedly thrown together at
the last minute by board members on Sunday, I wondered what was the reasoning
behind the rushed proposal. Specifics of the initiative are very vague. But the
members, which include 24 operator partners and a handful of manufacturers,
claim they will make it easier for app developers to create applications across
multiple networks.
Perhaps this rushed proposal is a reaction to worries over wireless' place in
the wider business scene. Research from Nielsen Research and commissioned by
Tellabs, which surveyed 15,000 consumers across 15 countries, found that most
consumers believe that media organizations, digital services providers and
software developers are more appropriate application providers than mobile
operators. More than 63 percent said that within the next six months they will
use mobile applications tailored to their personal preferences, location, time
of day and social setting. But the kicker is that consumers don't expect to get
these services from their carrier--they expect to get them from the likes of
Google and Facebook.
Clearly wireless operators are trying to put some order to the chaos of the
fragmented application development space. But this difficult task is not just
motivated by the need to help developers and propel the industry. I think the
main driver behind this community is the fear that if operators don't drive this
initiative, someone else will.
------------------------------
Fonte: e-Thesis
[21/07/08]
NGN, IMS e SDP. Será suficiente? - Eu detesto dizer 'eu avisei' - por
José R. Smolka
Se depender apenas do noticiário, especializado ou não, a indústria de
telecomunicações (operadoras e seus fornecedores) vai muito bem, obrigado. Sob a
batuta sábia e segura da dupla dinâmica TISPAN e 3GPP, as redes fixas e móveis
estão em processo de migração para um ambiente all-IP quadruple-play, de acordo
com o modelo NGN e IMS, e a oferta de banda larga fixa e móvel está em franco
desenvolvimento, o que permitirá que serviços, classicamente considerados fora
do escopo das redes de telefonia, tais como TV por assinatura ou broadcasting de
TV e rádio, sejm incorporados ao portfólio, e ocorra uma explosão de oferta de
novos serviços, que serão integrados à rede pelo SDP. Se tudo está tão bem,
porque eu continuo a sentir, como Shakespeare, que "existe algo de podre no
reino da Dinamarca"?
Não consigo me livrar da impressão que o timing para que tudo isto aconteça está
muito folgado. Se depender dos roadmaps de lançamento dos releases de
padronização e lançamento de produtos desenhados até aqui, uma transição
significativa das redes para este modelo operacional demorará alguma coisa entre
três a oito anos. De uma maneira geral, creio que as redes móveis migrarão mais
rapidamente, e as redes fixas seguirão em ritmo mais lento. E os planejadores
das redes conformam-se demais com isto. Tipicamente, eles esperam para ver que
features os fornecedores são capazes de entregar, para depois planejar a
montagem das redes e dos serviços sobre elas. Acho que eles deveriam adotar uma
postura mais agressiva e dizer aos seus fornecedores: Eu, operadora X, pretendo
seguir este roadmap tecnológico, distribuído no tempo e no espaço desta e
daquela maneira. Se você, fornecedor Y, pode me ajudar nisto, então bem-vindo ao
barco, senão saia da frente e dê espaço para quem possa. Até agora a única
grande operadora que eu vi fazer isto de forma consistente foi a BT, com o seu
projeto 21st Century Network (21CN), e ele levou cinco anos para preparar a rede
para as primeiras implementações, que começaram no ano passado. Creio que este
tempo que a BT levou para conseguir colocar de pé o seu projeto é uma medida
confiável dos problemas que as outras operadoras terão para transformar suas
redes atuais em NGNs, mesmo levando em conta que uma parte dos problemas
iniciais já estejam mapeados. Por isso a minha estimativa de tempo feita acima
(isto se as operadoras começarem a se mexer este ano).
O modelo de negócio de todas as operadoras de serviços de telecomunicação (com
exceção dos broadcasters de TV e rádio) é baseado em um único pilar: o controle
físico e lógico do assinante. O controle físico é típico das operadoras fixas,
porque normalmente o assinante não dispõe de meios alternativos para
conectar-se, a não ser pela rede da operadora que atende à localidade onde ele
reside ou trabalha. O controle lógico, porém, é comum às redes fixas e móveis, e
é feito obrigando que qualquer requisição de acesso a serviços feita pelo
assinante seja intermediada pela rede da operadora. E estes controles são
aceitos pelos usuários somente na medida em que eles tenham uma determinada
percepção de valor quanto aos serviços que ele consegue acessar através da rede
da operadora.
O controle físico do assinante já é uma batalha perdida, principalmente pelas
obrigações de unbundling que os órgãos de regulação do mercado estão
gradualmente impondo mundo afora. Mas também temos que considerar a progressiva
disponibilidade de redes alternativas de acesso à Internet (desde hotspots Wi-Fi
em hotéis, aeroportos e cybercafés, até redes municipais baseadas em Wi-Fi ou
WiMAX). E esta ubiqüidade de acesso à Internet é a principal ameaça à manutenção
do controle lógico do assinante.
Para entender a natureza desta ameaça precisamos compreender uma diferença
fundamental na forma de acesso a serviços nas redes de telecomunicações e na
Internet. No universo de TI, serviços são implementados por programas de
aplicação (ou seja, puro software). E todas as aplicações, sejam arquitetadas no
modelo client-server ou no modelo peer-to-peer, aderem ao end-to-end principle:
os parâmetros da sessão de uso da aplicação (serviço) - autenticação, modelo de
tarifação, grau de privacidade, tipo de encoding do conteúdo etc. - são
negociados diretamente entre os componentes client e server (ou entre os peers)
da aplicação. O papel da rede é secundário. Ela deve apenas encarregar-se de
transportar, da melhor forma possível, os pacotes de dados entre os componentes
da aplicação. Desta forma o valor percebido pelo usuário migra quase totalmente
para a aplicação, e a rede é vista como uma commodity, que agrega pouco ou
nenhum valor ao serviço.
Uma coisa é certa: as operadoras de serviços de telecomunicações não têm os
"cacoetes" necessários para tornarem-se produtoras de conteúdo. Nem podem sonhar
vencer, em velocidade e criatividade, a multidão de desenvolvedores de
aplicações que existem na praça. Elas só têm duas coisas para ressaltar como
agregadoras de valor: a capacidade de prover interoperação com os terminais
convencionais e os serviços de intermediação dos parâmetros da sessão. Como o
primeiro é transitório (porque a base de usuárrios da rede legacy tende a
diminuir com o tempo), o que resta como tentativa de barrar o processo de
comoditização da rede é investir em criar um ambiente que funcione como um "bercinho"
confortável, onde provedores de conteúdo e desenvolvedores independentes possam
"plugar" suas aplicações, desafogando-as de ter que lidar com todos os
detalhezinhos de negociação dos parâmetros da sessão, porque isto pode ser
terceirizado com a operadora (mediante algum acordo de repartição de receita,
claro). Apesar da sua arquitetura complexa, o papel do IMS na rede é somente
este: servir de front-end na autenticação dos usuários e na negociação das
características das sessões de acesso aos serviços.
Um problema com esta idéia é que, se a operadora forçar demais a mão nos acordos
de repartição de receita com os donos dos conteúdos e aplicações, ela pode
acabar empurrando estes parceiros potenciais para o outro lado da cerca.
Convenhamos que desenvolver aplicações para interoperar com redes de
telecomunicações é, pelo menos nos moldes atuais, caro e complexo. Você precisa
de hardware especializado, software caro, um bom conhecimento sobre as
interfaces disponíveis (que normalmente são documentadas de uma forma que
parecem ter sido escritas por computadores para serem lidas por máquinas de
calcular), e conhecer as "manhas" operacionais da rede. Na Internet a situação é
exatamente oposta. Qualquer um, com um PC velho, software livre, tempo
disponível, e uma conexão DSL no quartinho dos fundos ou na garagem da sua casa,
pode lançar um serviço novo na rede. Se der certo e o tráfego dos usuários
exceder a capacidade da sua infra-estrutura modesta, você pode facilmente fazer
o hosting do seu serviço em algum lugar com mais recursos, e até começar a fazer
um dinheirinho. Se der muito certo você pode ficar milionário. Seja vendendo sua
empresa start-up para algum dos pesos-pesados da Internet, como o Google, ou
fazendo um IPO. E se der errado, o que você perdeu? Tempo e talvez alguns
milhares de reais, mas, por um custo de entrada como este, dá para arriscar
alguns fracassos até emplacar um sucesso.
O segundo problema é que, mesmo que o IMS seja extremamente bom no desempenho
das suas tarefas, ele apenas media a sinalização. Ele não ajuda em nada na
criação do tal "bercinho" confortável para as third-party applications
conectarem-se à rede. Este papel, espera-se, será desempenhado pelo SDP.
Entender o SDP é mais complicado que entender o IMS. Enquanto o IMS ainda guarda
certa semelhança (mas não muita) com o conceito de "plataforma", tão querido
pelas operadoras porque, de certa forma, mantém semelhança com o tempo em que a
rede era essencialmente hardware, o SDP é uma criatura feita essencialmente de
software, e envolve determinados conceitos sobre desenvolvimento de aplicações
que até mesmo o pessoal de TI acha complicado entender.
Uma solução de SDP vai ter, necessariamente, que ser desenvolvida dentro do
conceito SOA. Um serviço SOA não tem nada a ver com o que comumente chamamos de
serviço. De certa forma, um serviço SOA é uma generalização do conceito de
objeto em OOP. Enquanto um objeto encapsula um conjunto de procedimentos, que
pode ser invocado de forma padronizada em várias aplicações diferentes, um
serviço SOA encapsula um bloco padronizado de atividades dos processos de
negócio de uma organização. Exemplo: dentro do processo de negócio "vendas" deve
haver um conjunto de atividades que pode ser agrupado sob o nome "checar
histórico de crédito do cliente". Se este bloco de atividades (não
necessariamente todas automatizadas) for descrito como um serviço SOA, então
todos os outros processos de negócio que precisem dele podem invocá-lo de forma
padronizada (business process reengineering outra vez?). A vantagem desta
abordagem é que a modelagem de processos de negócio torna-se um encadeamento
(estilo Lego) dos serviços SOA adequados, na ordem adequada.
Desta forma, desde que as third-party applications estejam desenvolvidas de
forma a interoperar com a rede através de um conjunto padronizado de APIs (como
o Parlay X, por exemplo) elas podem ser incorporadas como partes de serviços SOA
e serem facilmente "injetadas" nos processos de negócio da operadora. Esta
faceta do SDP, chamada service creation, apesar da complexidade conceitual, é a
parte fácil da coisa. Toda esta traquitana de serviços que foi descrita em
termos lógicos abstratos precisa ser comunicada para o conjunto de OSS e BSS da
operadora para que os usuários possam ter acesso concreto aos serviços. Esta é a
parte chamada service orchestration do SDP. Somente depois que estas informações
sobre que serviços existem, e como podem ser utilizados, for devidamente
repassada é que o IMS pode exercer de fato o seu papel. Alguém aí acha que a
estrutura de OSS e BSS das operadoras está preparada para isto? Nem eu. Não vai
ser apenas um conjuntinho de APIs Web Services que vai resolver esta questão.
Cada OSS e BSS terá que ser adaptado para poder interoperar com a camada de
service orchestration do SDP, inclusive o IMS, e vocês podem imaginar os efeitos
que uma modelagem e/ou implementação mal feitas nesta área podem trazer para o
negócio. Esta é a parte que eu considero realmente difícil de acontecer rápido,
porque o próprio entendimento de como fazer ainda está somente começando.
Mesmo que a operadora decida implementar este modelo apenas para novos serviços,
ela não conseguirá fugir da necessidade de integrar as aplicações de billing e
CRM no modelo SOA. Só isto já deixa muita gente de cabelo em pé, e exige um grau
de cooperação entre as áreas de engenharia e TI das operadoras que vai muito
além do usual. Na verdade, tudo isto exige que o foco das operadoras se desloque
radicalmente do hardware para o software, coisa que elas não estão habituadas a
fazer.
E as operadoras não têm saída. Ou elas encaram este processo de redefinição do
seu core business ou conformam-se a serem rebaixadas ao papel de dumb pipes, ou,
no máximo, idiot-savant pipes, para o tráfego da Internet. O tempo está
passando, e o número de usuários conectados à Internet não para de crescer. E a
Lei de Metcalfe é clara: o valor percebido de uma rede é diretamente
proporcional ao quadrado do número de nós a ela conectados. Se passar tempo
demais (mais uns cinco anos, no máximo, em minha opinião) quando as operadoras
terminarem de montar o seu "bercinho" vão descobrir que ninguém mais quer deitar
nele.
O tempo é crítico, e não existe mais folga. Ou a mudança começa a acontecer
agora ou não vai adiantar mais, e será um enorme desperdício de tempo, talento e
dinheiro. Então, para terminar, deixo vocês com uma citação (anônima) que vem
bem a propósito:
Every morning in Africa a gazelle wakes up. It knows that it must run faster
than the fastest lion, or it will be killed.
Every morning in Africa a lion wakes up. It knows that it must run faster than
the slowest gazelle, or it will starve to death.
So, when the sun goes up, it doesn't matter if you're a lion or a gazelle. You'd
better run like hell!