Monthly Archives: October 2009

A virada da Motorola(?) Qual foi o segredo?

O ano era 2008 quando Sanjay Jha, vindo de uma carreira meteórica na Qualcomm, fez a sua primeira apresentação para os funcionários da Motorola. Ele acabava de ser contratado como o novo CEO e uma das suas missões era salvar da Motorola do mesmo fim que levou a Nortel, Lucent etc.

Na sessão de perguntas, ouviu de um funcionário:

- “Por que deveríamos confiar em você?

Sua lua-de-mel na nova empresa foi curta.

(foto: Associated Press)

Um dos grandes erros da Motorola foi ter inovado com os modelos StarTac e Razr e parado por aí. Confiou nos seus produtos de sucessos. Esqueceu que toda inovação é passageira.

Os concorrentes ou escolheram o caminho de ter modelos simples, com interfaces idem, gerando um volume de vendas fenomenal, como a Nokia, ou foram altamente inovadoras, como mostrou a Apple com seu iPhone e o Google com seu sistema operacional Android com muitos serviços na “nuvem”.

Se a Motorola não tivesse um bom desempenho no natal daquele ano, tudo indicava que seria o fim da sua unidade móvel.

A estrutura explica parte dos erros

moto-estrut

Até então a Motorola, vinha utilizando a forma “clássica”, tinha estrutura verticais para sua linha de dispositivos móveis. Ou seja, havia executivos responsáveis por determinados modelos (vide figura ao lado).

O que isto gera? Simples, entre outros conflitos de interesse, cada executivo vai defender seu produto e insistir em melhorias em celulares que, por definição, terão sempre vida curta. É óbvio, ele precisa sobreviver e manter seu grupo empregado. Como admitir para o CEO e para os pares que a sua linha de produtos precisava ser extinta? Seria um atestado de incompetência!

Quando Sanjay Jha chegou na Motorola havia 22 linhas de produtos, com vários sistemas operacionais. Ele olhou e mercado e viu o líder, Nokia, estruturar seus celulares e smatrphones  em torno de um único sistema operacional – o Symbian (também utilizado pela Motorola!), a própria Apple só tem um aparelho que evolui apenas em torno de novas funcionalidades e se torna cada vez mais desejado, sem falar que ele é uma plataforma de desenvolvimento que também gera lucros para a empresa de Steve Jobs.

Já trabalhei no desenvolvimento de sistemas embarcados. Quem conhece vai entender o quanto custa ter que manter várias plataformas de sistemas operacionais: alto custo de manutenção, formação de equipes altamente especializadas (caras), os testes de liberação final (GAs) duram uma eternidade, problemas de “compatibilidade para trás” cada vez que uma versão é lançada, imensa estrutura de pós-venda etc etc.

O sinal parecia claro. Ele chamou para a mesa (um de cada vez), a Microsoft e o Google. A Microsoft avisou que um novo release do seu Windows Mobile iria atrasar bastante. Sanjay apostou todas as fichas no Google Android. Isto é o que chamamos de “foco”.

O início

Uma das primeiras ações de Sanjay Jha fez foi reunir os top executivos das 15 divisões da Motorole e pedir:

- Por favor, me digam o que vocês acham que está errado com a empresa. Quero apenas 2 slides de cada um de vocês

E Jha gosta de analisar slides. Ele faz questão de ler com detalhes os slides do apresentador, antes da reunião. Talvez fazendo o que os gestores deveriam fazer: “qual é, de fato, o verdadeiro problema aqui? Qual é a questão? Qual a causa-raiz deste problema?”. É preciso tempo, ou muita experiência, para ser chegar nas respostas à estas questões. Não se faz isto durante 50 minutos de uma apresentação.

“O problema não era a cultura de engenheiros”

Foi isto que Sanjay Jha conclui em pouco tempo. O real problema é que a Motorola não estava “conectando” seus engenheiros com o mercado, tentando conhecer o desejo real dos consumidores. Eles estavam em outra realidade.

A Motorola estava desenvolvendo telefones móveis, enquanto os consumidores queriam um pouco de tudo em seus aparelhos (vide iPhone). Falar era apenas um detalhe.

A causa-raiz, detectou Jha, era uma questão de (má) gerenciamento.

A Mudança

No 13o. dia na Motorola, Sanjay teve uma reunião com a maior operadora móvel do mundo, a Vodafone. Na mesa de discussão estavam três linhas de produtos da Motorola. O executivo da Vodafone perguntou para o CEO da fabricante de celulares:

- Caramba. Você pode escolher um destes modelos de aparelhos e me convencer por que eu deveria compra-lo?

Era outro sinal claro que alguma mudança precisava ser implementada, urgente. E ele não fez nenhum milagre, nem inventou a roda. Ele fez o que muitas empresas de tecnologia, como a Cisco, fazem:

  • Criou grupos centrais de engenheiros, marketing, gerência de produto e planejamento de estratégico de longo prazo, e fez esta turma conversarem entre si
  • E quem arbitra em  caso de divergência? Como a Cisco fez, criou um conselho, onde esta turma “lava a roupa suja” e chegam um acordo (para o bem de todos, é melhor que cheguem a um consenso, afinal qual a alternativa…?)

Resultados so far

moto-stock Bom, um das maiores operadora dos EUA, Verizon, já está comercializando o Droid Smartphone, e a gigante T-Mobile o Motorola Cliq. O vice-presidente de desenvolvimento de produtos da T-Mobile, Paul E. Cole, afirmou:

- Hoje a Motorola é um lugar completamente diferente de poucos anos atrás. Sanjay Jah tem feito um trabalho espetacular

O resultado do 3o. quarter de 2009 também foi comparativamente animador: lucro de US$ 12 M, bem diferente do prejuizo de uS$ 397 M de 1 ano atrás. O comportamento da ação está no gráfico ao lado (fonte: Nasdaq.com, fechamento do pregão de 30/out/2009). O valor da ação está no mesmo nível de Abril/2009, pré-crise financeira mundial. Ou seja, o mercado está reagindo bem em relação às mudanças.

Como nasceu o Motorola Droid e uma reunião às 18:00

Voltando a Agosto/2008, assim que Sanjay desceu da plataforma daquela sua primeira reunião com os funcionários onde foi duramente questionado, um engenheiro da empresa, Rick Osterlah, abordou o novo CEO e falou:

- Mr. Jah, já estamos trabalhando em um projeto tendo o Google Android como o novo sistema operacional

No final da mesma semana, Rick Osterlah estava no jatinho com Sanjay voando para a unidade da Motorola na Califórnia. Mr. Jah queria ver todos os detalhes pessoalmente. Poucos dias depois ele estava participando de uma reunião com todo o grupo de Rick e, não apenas pediu e revisou todos os 100 slides com antecendência, como fez perguntas detalhadas durante a apresentação e pediu que o time produzisse mais 20 slides (tive um chefe que não suporta ler nem um slide).

A apresentação foi agendada por Sanjay para iniciar às 18:00. Um “pecado mortal” para uma empresa que trabalha das 09:00 às 17:00 (já trabalhei em uma empresa similar nos EUA e a cultura é a mesma, idêntica até na jornada de trabalho).

- Reunião de 4 horas iniciando às 06:00 da noite?

“Parece mesmo que as coisas vão ser diferentes de agora em diante”, devem ter pensado os engenheiros.

ROI2: Retorno do Investimento em Inovação

Um dos critérios para definir o sucesso de uma inovação é a percepção desta inovação pelo cliente, que este mesmo cliente “compre” a nova idéia (literalmente), o que vai resultar em maior faturamento e maiores retornos.

A equação parece simples, mas não é.

mitsloanlogo A última edição da MIT Sloan Management Review traz um    artigo que discute quais inovações realmente valem o esforço?  Basta investir em pesquisa e desenvolvimento? O título do artigo é “Which Innovation Efforts Will Pay?” (edição Fall 2009).

O estudo da Booz & Co.

A matéria traz alguns números interessantes de uma pesquisa abrangente da consultoria Booz & Coo com base em pesquisa em empresas que representam 60% de todos os investimentos globais em R&D.

Algumas tem tentado “seguir a manada” e implementar uma “inovação aberta”. Muitas gastam quase todo orçamento em R&D fazendo benchmarking:  elas verificam o que os concorrentes estão fazendo de melhor (best practices) e aplicam no seu negócio. Estas abordagens, de acordo com a pesquisa, gerou produtos com pouco ou nenhum retorno.

Você pode afimar. Bem, investimento em R&D traz este risco embutido! Precisa ser sempre assim? Não!

Primeiro porque o acionista pode não concordar com você (diretor financeiro idem). “Como vou investir e você não me garante o retorno do meu investimento?“. Aqui temos vários problemas, incluindo diferenças culturais e de aceitação de risco de cada país. Não vamos entrar nesta discussão (aconselho o estudo das “Dimensões Culturais” de Hofstede para o entendimento de como funciona cada cultura).

Segundo porque podemos aprender, ler, pesquisar e analisar dados como este da Booz & Co, verificar as melhores práticas e diminuirmos o risco (que sempre vai existir a partir do momento que você levanta da cama).

A Apple e a Indústria Automobilística

É um dos exemplos mais citados em todos os estudos, este não poderia ser diferente. A Apple investe cerca de 5,9% do faturamento das vendas em R&D. A média da indústria a qual ela faz parte é de 7,6%. Gostando ou não do Steve Jobs, você tem dúvida que ele e seu time vem criando produtos inovadores?

A japonesa Toyota investe menos em R&D dos que as grandes montadoras americanas e é líder mundial, case de inovação.

ROI2: Return on Innovation Investiment

innovcurveA abordagem que os analista utilizaram para definir o ROI2 foi baseada em estudos conduzidos durante 7 anos em companhias das áreas de saúde, produtos de consumo e químicas.

ROI2 correlaciona diretamente com o crescimento orgânico das empresa e compara investimento em inovação com performance financeira da empresa.

Este é o tipo de matéria que o pessoal do financeiro iria adorar ter em mão mas, a não ser que eles sejam leitores da MIT Sloan Review, eles não devem conhecer este blog. Por enquanto fique tranquilo, ou então peça para os seus amigos do departamento de rede o bloqueio da URL do MIT para o pessoal de finanças :-)

Conclusão

Os critérios de inovação devem ser poucos e todos os esforços devem ser concentrados nestes. O crescimento orgânico deve vir acompanhado de uma correlação positiva entre investimento em inovação/R&D e performance financeira da empresa.

Simples comparação do que os seus concorrentes estão fazendo e a tentativa de fazer um benchmarking não cria inovação para sua empresa. O contexto cultural da empresa, as competências individuais, e o mapa estratégico da sua concorrente não podem ser copiados.

Category: innovation | Tags:

Arquitetura do Twitter e Google Talk: Lições Aprendidas

The only real mistake is the one from which we learn nothing

– John Powell, The Secret of Staying in Love (1990), p. 85

Se você se interessa por arquitetura de software, mais precisamente, sobre questões de escalabilidade de sistemas e soluções (software), o blog Highscalability.com é leitura obrigatória.

Algum tempo atrás eu li no blog acima um post muito interessante sobre a arquitetura de software do Twitter. O título é “Scaling Twitter: Making Twitter 10000 Percent Faster” e além da discussão de como foi a solução de arquitetura que permitiu que o Twitter ficasse 1,000% mais rápido (o post é de 27/06/2009), descreve detalhes de linguagem, tecnologias, problemas e soluções, enfim, uma aula de como funciona o “coração” de software do Twitter (lá quase tudo é open-source).

Não vou reproduzir em detalhes aqui, a leitura é interessante e valem os 10 minutos. O que me chamou a atenção na época foram as lições aprendidas em cada um dos projetos, que o autor apresenta no final do texto.

Estas informações são valiosas, priceless! Como afirmou John Powell (citado acima): “O único erro de fato é aquele do qual nada aprendemos“.

Você tem uma reunião de “lessons learned” no seu projeto? Não? Você e sua equipe estão perdendo uma excelente oportunidade de evoluir, de aprender com os erros e acertos e, principalmente, de não repetir os mesmos erros. Um conselho de amigo: invista alguns minutos com o grupo ao final de cada etapa do projeto e documente todas as abordagem que deram certos e aquelas que não devem ser repetidas (erros).

Vamos ao que interessa. Abaixo, bem resumido, reproduzo algumas “lessons learned” de dois projetos famosos: Twitter e Google Talk.

Twitter: Lições Aprendidas

  1. Compartilhe idéias com outros (comunidade). Não se esconda e tente resolver o problema sozinho. Muitas pessoas brilhantes estão dispostas ajudar (você precisa pedir)
  2. Encare seu planejamento de escalabilidade como um plano de negócio. Reuna um time de experts para ajudar você
  3. Construa o que você precisa. O Twitter investiu muito tempo tentando soluções de terceiros que pareciam funcionar, mas não eram adequadas. Quando você mesmo desenvolve pelo menos você tem o controle e pode adicionar as funcionalidades que precisar
  4. Pense em mecanismos de detecção de usuários com intenção de “derrubar” o sistema. Coloque limites de utilização de forma que nenhum deles, isoladamente, coloque seu sistema “no chão”
  5. Não utilize o banco de dados como única alternativa de armazenamento. Nem tudo necessita de um “SQL join” gigante. Cache é a palavra mágica. Pense em formas alternativas de chegar no mesmo resultado, disponibilize dados em memória. Veja detalhes de como o Twitter fez isto neste link
  6. Faça com que sua aplicação seja “modularizada” ou “particionável” desde o início. Você vai entender porque quando precisar escalar a mesma
  7. Otimize o banco de dados: indexe tudo, faça um tunnig das queries, desnormalize
  8. Teste tudo. Twitter tem agora uma suite de testes completa de forma que se ocorrer um problema de cache eles detectam o problema antes da nova versão ser liberada
  9. Muitos problemas de performance não vem da linguagem, mas de como a aplicação foi projetada
  10. Transforme o serviço do seu website em uma API aberta. Grande parte do sucesso do Twitter é graças à sua API. Isto permite que a comunidade crie inúmeros serviços e aplicativos com os quais será difícil para os concorrentes copiarem. Amazon e Google também fazem isto. Você nunca poderá fazer todo o trabalho sozinho, a criatividade do seu time tem limites.

Google Talk: Lições Aprendidas

  1. Identifique corretamente o que deve ser mensurado. No caso do Google Talk, a questão principal não é saber quantos Instant Menssages (IMs) o sistema entrega ou quantos usuário ativos o sistema suporta. Por exemplo, uma parte complicada de um IM é como exibir o status de todos os usuários conectados. A conta não é linear: UsuáriosOnLine x ListaDeAmigos x MudançaDeStatusOnline. Uma grande lista de amigos (“buddy list”) é um problema a ser endereçado, a quantidade de IMs não é o problema
  2. Simulação em “ambiente real”. Testes em ambiente controlado são bons mas não dizem muita coisa. Simule mudança de status por semanas e meses
  3. Planejamento contra problemas operacionais. O que acontece quando os servidores são reinicializados e o sistema retorna com o cache vazio?
  4. Um sistema “escalável” é um sistema distribuído. O que o Google fez foi adicionar tolerância a falhas em todo componente do sistema. Tudo pode falhar.

Larry Ellison vai pagar US$ 10 milhões de prêmio…


…se alguma organização conseguir provar que o seu banco de dados (Oracle) não roda pelo menos duas vezes mais rápido em um servidor da SUN, quando comparado à performance em um servidor da arqui-rival IBM.

Alguém se habilita? São US$ 10 milhões

ps.: vale instalar o Oracle no IBM Roadrunner?

(fonte: Associated Press)

Category: Ibm, Oracle | Tags:

Wal-Mart Telecom

wal-martcoverage_map

(fonte: Great coverage)

O mapa acima mosta a cobertura do serviço de telefonia celular Straight Talk lançado pelo Wal-Mart nos Estados Unidos. A rede de telefonia utilizada é da operadora Verizon (uma das maiores dos EUA).

Você vai no supermercado Wal-mart, ou pela Web, e contrata o serviço. Vejam os preços:

  • Por R$ 52,00 (US$ 30) você tem 1,000 minutos para fazer ligações locais ou de longa distância, 1,000 SMS e mais 30 MB para nagevar na Internet (banda larga da operadora móvel)
  • Por R$ 78,75 (US$ 45) você tem um plano sem limites: ligações locais ou longa distância, SMS, Internet…

Interessante? Lembrou da conta da sua operadora?

Agora você entende porque o governo brasileiro arrecada R$ 15,5 bilhões/ano do serviço de telefonia móvel e as operadoras tem lucro operacional menor que 10% deste total (R$ 1,4 bilhão)? É disparada, a maior carga tributária do mundo.

Por que este blog discute este assunto? Simples, parte deste valor que vai para o governo poderia ser revertida para o barateamento das tarifas e para a geração de novos produtos e serviços como este que uma rede de supermercado americano acabou de lançar. E o que sobra para investimento em inovação? Em tecnologia para permitir tarifas menores, melhor atendimento e produtos de telefonia inovadores como as do exemplo acima?

Qual a lógica de desenvolver um negócio em que o Lucro Operacional gerado é 1/10 do Imposto que o governo leva? Qual o incentivo para o empreendedor? Como formentar a  concorrência em um mercado que se consolida cada vez mais? Quem sai ganhando quando tivermos apenas 3 ou 4 operadoras de telefonia móvel? Nós consumidores? Responda você mesmo…

Não existe nada de errado no lucro e na existência das grande corporações. A questão é que o governo deveria criar condições para o surgimento de novas empresas, aumentando a concorrência e beneficiando uma parcela bem maior da população.

Finlândia torna banda larga em direito do cidadão

Guardando todas as diferenças, não custa ver outro exemplo que vem da Finlândia. Este país será o primeiro no mundo a transformar o acesso a banda larga um direito do cidadão, garantido por lei.

  • Em Julho de 2010,  todos os 5,3 milhões de habitantes terão direito a acesso em velocidade de pelo menos 1 Mbps
  • A meta será o primeiro passo para disponibilizar acesso de 100 Mbps para toda população até 2015

Já sabemos que existe um estudo na Casa Civil sobre um plano para universalizar o acesso a banda larga. A intenção é excelente mas, adivinhem onde a discusão está emperrada? O ministro das Telecomunicações (Hélio Costa) defende os investimentos do setor privado; o secretário de TI do ministério de Planejamento (Rogério Santanna) afirma que o governo pode implementar por conta própria. Certo…

Category: telecom | Tags:

SOA e BPM devem ser iniciativas separadas?

soabpm

Existe existia uma idéia pré-concebida na minha mente que SOA BPM devem ser iniciativas “casadas”, parte de um processo único. O resultado pode ser catastrófico. Algumas razões:

  • SOA é estilo de arquitetura que utiliza fortemente o conceito de serviços para a construção de aplicações compostas
  • BPM é sobre análise de processos de negócios e otimização
  • A turma de Business Process Management (BPM) encontra na arquitetura orientada a serviços (SOA) a abordagem ideal para colocar em prática os processos de negócio que irão permear por toda a organização
  • Quando se fala de Business Process a tecnologia é o menor dos problemas. Política, resistência de alguns departamentos, problemas inevitáveis de comunicação, falta de direcionamento estratégico, áreas ou empresas dispersas geograficamente… …estes são os desafios da implantação de BPM

A utilização de uma arquitetura orientada a serviço pode ser parte de um esforço, de uma estratégia de BPM, porém ter as duas iniciativas de forma concorrente é um forte indício de que você esteja utilizando a abordagem “Big Bang” (que deve ser evitada).

SOA e BPM tem objetivos diferentes e métricas diferentes. Como afirmou J P Morgenthal em seu blog, “The Tech Evangelist“:

…SOA and BPM each have their own metrics of success and their ownbarriers to success. Combining them into one, well, the words “boilingthe ocean” comes to mind

Afinal, qual o papel do Analista de Negócio?

Ele precisa entender de arquitetura orientada a serviço? Não! Seu foco deve ser localizar e extrair dos stakeholders as informações necessária para capturar o “as is” (hoje) e ajudar a definir o “to be” (amanhã). Acredite, é a parte mais difícil.

Para ganhar agilidade no processo e evitar entrevistas desnecessárias com os clientes (internos ou externos), um(a) arquiteto(a) SOA deve acompanhar o(a) analista de negócio.

Se você quiser saber quais as oito competências que todo  Analista de Negócios deve ter, eu aconselho a leitura deste artigo: “Eight Competencies a Business Analyst Needs to Know“.

Bottom-up, Top-down, “Goal-oriented”?

Geralmente (isto não é regra) as equipes com foco na arquitetura SOA utilizam a abordagem “bottom-up“, em que os arquitetos especificam Serviços com base em “capacidades” (capabilities) que já existem. O risco desta abordagem é resultar em implementação de Serviços que não correspondem com os requisitos do processo. É o problema da “visão de poço” ou “visão de profundidade” em que coloca-se muito foco na tecnologia e, por vezes, esquecemos o objetivo maior, que faz parte de um processo de negócio.

Do outro lado, analistas de negócio (BPM), que geralmente utilizam excessivamente abordagens “top-down” irão tentar otimizar processos sem levar em conta o detalhamento que permitirá a implementação de um Serviço.

Qual a solução? A que eu recomendo é a utilização de iterações em que visita-se do topo (“top“) até a base (“bottom“), ou seja, verifica-se o processo “to be” mapeado pela equipe de BPM e a definição do(s) Serviço(s) projetado(s) pela equipe de arquitetos SOA.

Avançando nesta discussão o ideal seria ter definidos objetivos (“Goals“) factíveis e de curta duração, com grande visibilidade, e adotar esta ação conjunta “bottom-up”+”top-down” com um Goal de negócio como meta. A isto eu defino como “Goal-oriented“.

Abraços,

Davi

(atualizado às 08:10 PM para atualização do tópico “Bottom-up, Top-down, “Goal-oriented”?)

Category: bpm, SOA | Tags:

SOA precisa ser cara?

opensourcesoa(fonte: Mike Davis, IT Toolbox)

Não ! Primeiramente é importante lembrar que não existe uma solução única, seja ela open-source ou não, que seja o “best of breed“, ou seja, felizmente sua empresa não precisa ficar “refém” de nenhum fornecedor.

Como já afirmei acima, mesmo as soluções open-source não são a solução para toda e qualquer iniciativa em direção a arquitetura orientada a serviços (SOA). Não existe a “bala de prata” e nem um fornecedor único que tenha a solução para todos os seus problemas, com um preço que você pode pagar.

A questão que apresento aqui é que existem alternativas que podem devem ser avaliadas.

O que eu sempre falava nos seminários sobre SOA é que a utilização de produtos open-source tem algumas vantagens. Algumas delas são:

  • Validação da arquitetura proposta: uma espécie de prova de conceito da macro-arquitetura proposta
  • Custo: solução de baixo custo antes de realizar grandes investimentos em soluções proprietárias
  • “Hands-on”: em geral é preciso “colocar a massa” para instalar os softwares… …não espere “Next->Next->Finish“… Isto permite que sua equipe conheça como as soluções funcionam de verdade

Algumas soluções opensource disponíveis

A lista a seguir apresenta algumas soluções open-source para auxilia-lo a adotar uma estratégia SOA:

Cases de Sucesso

logo-nespresso

Fornecedor de vendor machines de cafés, a empresa utilizou o Mule ESB para integrar sua central de voz (Nortel), seu ERP, seu sistema de controle de estoque etc. Case detalhado aqui

lazokytoyota2 Lakozy é uma subsidiária da Toyota na Índia, o case é da implantação de um workflow opensource para agilizar os processos internos – sem mais a utilização de formulários em papel – e algumas funcionalidades interessantes como integração com serviços de short message (SMS)

inep Órgão do Ministério da Educação do Brasil. O case detalhado aqui comenta a utilizacão de alguns produtos da JBoss/Red Hat: JBoss Enterprise Application Platform, JBoss Enterprise Portal Platform, JBoss Operations Network (JON) e JBoss Seam Framework

Como estes existem centenas de cases de sucesso.

Conclusão

A mensagem mais importante é que SOA é uma mudança de “estilo de vida”, de pensar em soluções como aplicações compostas, em serviços, padrões abertos, objetivos de negócio, com ganhos de longo prazo (que são os mais sustentáveis). Não ter orçamento para iniciar SOA é uma daquelas desculpas que damos quando queremos perder peso e não temos como pagar uma academia. Para a maioria de nós, se faz necessário pagar uma academia para perder peso ou basta mudar o estilo de vida? Responda você mesmo…

Implementar esta abordagem de arquitetura passa por :

  • Mudanças culturais: como gestor, arquiteto esta é uma tarefa sua; você precisa estudar, conhecer, evangelizar
  • Planejamento inicial: é necessario tempo para a construção da arquitetura de alto nível, da “big picture”. Porém é este “blueprint” que irá guiar todas as modificações propostas. Se necessário peça ajuda de terceiros mas, não esqueça de colocar a visão da sua empresa. Isto ninguém pode fazer, apenas você
  • “Quick Wins”:  para os mais crédulos, resultados práticos. A utilização da abordagem SOA+Metodologia Ágil pode ajudá-lo a conseguir resultados rápidos (viva o SCRUM!)
  • Prova de Conceito da sua Arquitetura: é neste ponto que soluções open source vão ajudar você; o investimento inicial é baixo, os ganhos de conhecimento para a sua equipe  ”não tem preço”… …o restante o Mastercard corporativo compra :-)
  • Padrões abertos:  lembre-se que sua solução open source pode ser substituída por middlewares proprietários – seja por questões de performance, missão crítica, volume a ser processado etc – utilizando padrões abertos de integração, Web Services, REST, sua migração para soluções fechadas será suave
  • Pensar Grande, começar pequeno: construa a “big picture”, inicie com resultados de curto prazo, faça uma análise de “Visibilidade da Solução X Tempo de Desenvolvimento”, divida em quatro quadrantes e escolha aqueles projetos com maior Visibilidade/Retorno e com menor tempo de desenvolvimento

Não deixe de aproveitar o feriado! Abraços,

Davi

Mapa de Aquisições do Google

O site MeetTheBoss preparou um infográfico com todas as aquisições do Google desde a sua fundação. O mapa detalhado (que você pode ver ao clicar na imagem diretamente no post original) informa, além dos nomes de todas as empresas, o ano da aquisição e o valor investido pelo gigante de buscas.

mapadeaquisicoesgoogle

(fonte: MeetTheBoss.com)

O texto original ainda apresenta um breve histórico do Google, desde a sua fundação (1996). Vamos ao resumo do resumo:

  • Projeto inicial: pesquisa do, na época, estudande de PhD da universidade de Stanford, Larry Page
  • Nome original do projeto: ‘BackRub‘ (ainda bem que mudaram…)
  • Próximo passo: Larry Page convidou seu amigo Sergey Brin, também aluno de PhD de Stanford, e ambos desenvolveram o algoritmo PageRank, inovador no conceito de atribuir peso à “popularidade” de uma página ou site a partir da quantidade de referências à esta
  • O domínio Google.com foi registrado em 15 de Setembro de 1997
  • O início da empresa foi em 4 Setembro de 1998
  • Primeiro investidor foi Andy Bechtolsheim, co-fundador da Sun Microsystems, que investiu meros US$ 100,000
  • A venda de anúncios iniciou em 2000 (Google AdWords)
  • Page e Brin estão atualmente entre as 6 pessoas mais ricas dos EUA

Abaixo o primeiro servidor do Google:

Category: google | Tags:

Cloud da Amazon: US$ 220 milhões/ano

amzec2.png

Este valor é uma estimativa de quanto o serviço de Cloud Computing da Amazon.com feita por Randy Bias em seu blog Cloud Scaling.

A Amazon é uma empresa que fatura algo em torno de US$ 19.2 bilhões/ano, ou seja, o seu serviço de cloud (EC2, Amazon’s Elastic Compute Cloud) representa 1% do faturamento mas, convenhamos, não é nada desprezível correto?

Qual o tamanho da “nuvem” da Amazon?

Bias cita alguns números sobre a infraestrutura da EC2 da Amazon. Vejamos (atenção são valores e capacidades estimadas, a Amazon, por razões óbvias, não divulga o tamanho da sua infraestrutura):

    1. 40.000 servidores
    2. são dual-core server de 2U com 8 cores, montados em rack. O autor do post acha que são modelos S2108 da fabricante SGi. Cada rack com 16 servidores
    3. Custo estimado de cada servidor: US$ 2 a 2,5 mil
    4. Capacidade de utilização: planejada inicialmente para um máximo de 75%
    5. Discos: tudo indica que são 8 discos SATA de 500 GB por máquina
    6. Cerca de 20% desta capacidade é reservada para as próprias operações da loja Amazon.com
    7. Provavelmente este parque de servidores está distribuído em 6 data centers, com 6,700 servidores/site

Tipos de Servidores e % de Cada Configuração

Continuando sua estimativa, Bias acha que as 5 configurações de servidores virtuais tem o seguinte percentual de utilização:

    1. 21% m1.small: small Instance (Default) 1.7 GB of memory, 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit), 160 GB of instance storage, 32-bit platform
    2. 35% m1.large: large Instance 7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of instance storage, 64-bit platform
    3. 20% m1.xlarge: extra Large Instance 15 GB of memory, 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each), 1690 GB of instance storage, 64-bit platform
    4. 13% c1.medium: high-CPU Medium Instance 1.7 GB of memory, 5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each), 350 GB of instance storage, 32-bit platform
    5. 11% c1.xlarge: high-CPU Extra Large Instance 7 GB of memory, 20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each), 1690 GB of instance storage, 64-bit platform

Receita da “nuvem”: por hora, mês e ano

Com base nestas estimativas e no preço do serviço, o autor chega à seguinte conclusão em relação ao faturamento:

Resumo das instâncias da EC2:

m1.small 34,675
m1.large 28,896
m1.xlarge 8,256
c1.medium 5,366
c1.xlarge 2,270

Faturamento de cada instância:

Hora : US$ 25,264
Mês  : US$ 18,190,195
Ano  : US$ 218,282,342

Nada mau para uma empresa .com que começou vendendo livros!

Category: Cloud Computing, statistics, vendors | Tags:

IBM iNotes: concorrente corporativo para o GMail?

inotesxgmail.png

A IBM anuncia o lançamento do LotusLive iNotes, um Web-based e-mail para o mercado corporativo. Tudo indica que este produto é resultado da aquisição da Outblaze, uma empresa de Hong Kong.

A “big blue” aposta que ainda existe demando no mercado por um serviço mais “estável” e que as empresas estão dispostas a pagar por isto. As últimas instabilidades de alguns serviços do Google é uma das armas da IBM contra o o principal concorrente do seu novo e-mail. O Google alega que seu seu Google Apps (nome da sua suite) alega que tem mais de 15 milhões de usuários no mundo.

Preço

A diferença por usuário/ano é considerável. Ponto para o iNotes. A questão que o produto da IBM se restringe ao e-mail, contatos e calendário, enquanto que o Google tem uma série de outros aplicativos.

  • IBM LotusLive iNotes: US$ 36/funcionário/ano
  • Google GMail: US$ 50/funcionário/ano

Tamanho do Inbox

Ponto a favor do Google. Ele oferece um inbox com 25 Gb enquanto que o iNotes apenas 1 Gb. Convenhamos, 1 Gb é muito pouco (se quiser mais espaço você precisará pagar mais).

Estabilidade

É bem verdade que ocorreram alguns imprevistos com os serviços do Google, mas eu desconheço serviço 100% livre de falhas. O preço para ter “zero” de “downtime” certamente não seria este que a IBM cobra. Textos de lançamento de produto e artigos de revista não garantem estabilidade dos serviços. Precisaríamos ter acesso ao SLA do iNotes para verificar qual o “uptime” garantido. Se alguem encontrar este SLA me avise.

De qualquer forma, a concorrência é sempre benéfica. Bom final de semana!

Category: Ibm, vendors