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!


ComUnidade WirelessBrasil                     BLOCO