terça-feira, 20 de julho de 2010

Gartner cria código de conduta para contratos de manutenção

Conselho mantido pela consultoria define sete direitos dos clientes no relacionamento com os fornecedores.

Por Redação da Computerworld
19 de julho de 2010 - 14h26

Com o intuito de reduzir as preocupações dos consumidores em relação aos contratos de manutenção de hardware e software, a consultoria Gartner montou um código de conduta, voltado a estabelecer a postura adequada dos fornecedores em diversas situações.

O documento foi escrito a partir da opião de CIOs e analistas, por de situações reais vividas hoje no mercado. O objetivo, informa o Gartner, é propor mudanças na forma como a indústria de TI se posiciona.

Segundo o vice-presidente e diretor do Gartner, David Cappucio, um dos principais conflitos a serem resolvidos é o fato de que manutenção de hardware e software representa a maior forte de custos de TI, enquanto significa uma das principais fontes de receita dos fornecedores.

Nesse contexto, o papel do código de conduta é focado em fornecedores e indica como a manutenção deve ser dirigida para atingir um equilíbrio entre atender os objetivos dos clientes e não comprometer os processos de missão crítica. O documento descreve sete direitos dos usuários dos serviços, com o intuito de gerar uma relação mais equilibrada para todas as partes envolvidas:

O direito a um processo adequado de atualizações de serviços de software – Os fornecedores devem oferecer a todos os clientes um processo de atualizações e patches com frequência bem definida e prazos de duração. Além disso, precisam definir um processo para a adoção de atualizações emergenciais na descoberta de falhas operacionais ou de segurança sérias, com metodologia de notificação a todos os interessados.

As atualizações agendadas ou emergenciais devem estar alinhadas à abrangência do contrato, para que os consumidores não paguem por lançamentos desnecessários ou indesejados. Por fim, os contratos de atualizações devem atender às necessidades regionais do cliente, oferecendo níveis semelhantes de suporte, a custos semelhantes, para todas as regiões onde os negócios são realizados.

O direito a tempos de resposta e níveis de suporte de TI claramente definidos, baseados na importância da aplicação e em outros fatores de negócios – Contratos de manutenção devem estabelecer, claramente, o tempo de resposta que os fornecedores terão para determinadas aplicações e questões. O cliente, por sua vez, tem o direito de exigir uma definição a respeito do tempo máximo para a solução de problemas específicos.

Para atender esses critérios, o fornecedor deve oferecer uma variedade de níveis de manutenção, baseados em critérios corporativos específicos, incluindo quão crítica é a aplicação, a necessidade por planos de continuidade de negócios e recuperação de desastres e a necessidade de disponibilidade de suporte especializado.

O direito à previsibilidade quanto às mudanças no preço dos contratos, com planos de longo prazo para os custos – Fornecedores que oferecem diversos processos estratégicos não são facilmente “trocáveis” pela empresa tomadora de serviços. Isso engessa a capacidade do cliente de negociar preços. Para evitar uma situação complicada, o documenti recomenda que o contrato inicial detalhe todos os procedimentos de variação de preços, de forma que estes sejam amplamente reconhecidos por todos os envolvidos no contrato.

O direito de interromper ou alterar contratos de suporte para produtos que não estão em uso – As necessidades de suporte das empresas mudam, seja por redundâncias causadas por fusões e aquisições, seja por mudanças de requerimentos. Com flexibilidade no contrato de suporte, as empresas terão mais facilidade em ajustar os níveis de serviço a um ambiente empresarial, que é extremamente volátil. Os fornecedores devem permitir que os clientes encerrem determinados tipos de suporte e os custos associados, além de transferir licenças de uso de uma região para outra.

O direito à qualidade e previsibilidade dos níveis de suporte ao longo de todo o ciclo de vida do produto e do contrato – Os contratos firmados devem ser muito claros quanto ao nível de suporte prestado pelo fornecedor ao longo de todo o ciclo de vida do produto. Os clientes têm o direito de esperar total transparência com relação aos níveis do suporte e o fornecedor tem o dever de informar, proativamente, todas as mudanças que possam ocorrer no suporte.

Direito à manutenção e suporte a sistemas legados, definida claramente no contrato – Os responsáveis pelo códigom indica a dificuldade em determinar com precisão quando um produto se torna aplicativo legado e concordam que trata-se de um aspecto altamente problemático, pois nem sempre os fornecedores estão prontos ou se dispõem a oferecer apoio contínuo para esses produtos. Assim, o fornecedor deve especificar claramente por quanto tempo um cliente pode esperar o suporte a um produto depois que o ciclo de fida determinada pelo fornecedor terminar.

O direito a definições claras e futura aprovação de cada detalhe dos acordos de suporte – A falta de clareza nessas definições leva a confusão e conflitos entre clientes e fornecedores. O contrato deve especificar detalhadamente as garantias oara que o fornecedor entregue serviços apropriados, com níveis bem discutidos e sobre os quais houve acordo. Um contrato detalhado, linha por linha, permite futuras atualizações ou mudanças nos acordos de nível de serviços (SLAs) de forma justa para ambos os lados.

As 10 principais ameaças das redes sociais às empresas

Fornecedora de soluções de segurança lista os grandes riscos embutidos nos ambientes colaborativos e que devem ajudar na elaboração das políticas de acesso.

Por Network World/EUA
13 de julho de 2010 - 09h28

Os departamentos de TI têm demonstrado preocupação, já há algum tempo, em relação aos riscos que as redes sociais podem representar para as organizações. E a preocupação não é infundada, de acordo com a fornecedora de soluções de segurança de redes Palo Alto Networks.

A empresa listou as dez principais ameaças a que as empresas estão sujeitas quando seus funcionários acessam as redes sociais e como isso deve influenciar a criação das políticas de acesso.

1::Worms. Entre os vermes (worms, em inglês) de redes sociais estão o Koobface, que se tornou, de acordo com pesquisadores, “o maior botnet da web 2.0”. Apesar de uma ameaça multifacetada como o Koobface desafiar o que entendemos por “verme”, ele é projetado especificamente para se propagar pelas redes sociais (como Facebook, mySpace, Twitter, hi5, Friendster e Bebo), aliciar mais máquinas à sua botnet, e sequestrar mais contas para enviar mais spam para aliciar mais máquinas. Tudo isso para lucrar com os negócios típicos das redes botnets, como scarewares (como antivírus falso) e serviços de encontros românticos com sede na Rússia.

2::Isca para golpes de phishing. Alguém se lembra do FBAction? O e-mail que lhe pedia maliciosamente para se conectar ao Facebook, torcendo para que ninguém percebesse a URL fbaction.net no campo de endereço do navegador? Muitos usuários do Facebook tiveram suas contas invadidas e, embora tenha sido apenas “uma fração menor que um por cento”, o total de vítimas ganha corpo quando lembramos que o Facebook tem mais de 350 milhões de usuários. Pesa a favor do Facebook o fato de ter agido rápido, trabalhando para incluir o domínio numa lista negra, mas desde então surgiram muitas cópias descaradas (por exemplo, fbstarter.com). Desde então, o Facebook tem brincado de gato e rato com esses sites.

3::Trojans. As redes sociais têm-se tornado um excelente vetor para Trojans (cavalos-de-Troia). Basta se deixar seduzir por um aviso suspeito de “clique aqui” para receber:

*Zeus – um potente Trojan de roubo de dados bancários potente que, apesar de popular, ganhou vida nova nas redes sociais. Diversos roubos de grandes somas já foram atribuídos a Zeus. Um exemplo notável: o que teve como vítima a administração escolar central de Duanesburg, no Estado de Nova York (EUA), no fim de 2009.

*URL Zone – é um Trojan similar, mas bem mais esperto. Ele é capaz de comparar o saldo das contas da vítima para ajudá-lo a decidir quais roubos merecem prioridade.

4::Vazamento de informações. Compartilhar está na alma das redes sociais. Infelizmente, muitos usuários compartilham mais do que deveriam sobre empresas e entidades, com dados sobre projetos, produtos, informações financeiras, mudanças organizacionais, escândalos e outras informações importantes. Há até maridos e esposas que divulgam, na rede, como seu companheiro ou companheira tem trabalhado até tarde em projetos altamente confidenciais, acompanhado de mais detalhes sobre o tal projeto do que seria aceitável. As consequências desse tipo de indiscrição vão do embaraçoso ao jurídico.

5::Links encurtados. As pessoas usam serviços de encurtamento de URL (como bit.ly e tinyurl) para fazer caber URLs compridas em pequenos espaços. Eles também fazem um ótimo trabalho de esconder o link original; desta forma, as vítimas não serão capazes de perceber que estão clicando em um programa instalador de malware e não num vídeo da CNN. Esses links encurtados são muito fáceis de usar e estão por toda parte. Muitos dos programas para Twitter encurtam os endereços automaticamente. E as pessoas estão acostumadas a vê-los.

6::Botnets. No fim de 2009, pesquisadores de segurança descobriram que contas desprotegidas do Twitter estavam sendo utilizadas como um canal de comando e controle para algumas botnets (redes de PCs vulneráveis, comandadas remotamente). O canal padrão de comando e controle é o IRC (rede de bate-papo), mas alguns cibercriminosos decidiram explorar outras aplicações – como o compartilhamento de arquivos P2P, no caso do Storm – e agora, engenhosamente, o Twitter. O microblog tem fechado tais contas; mas, dada a facilidade de acesso das máquinas infectadas ao Twitter, a situação terá continuidade. Assim, o Twitter também se torna adepto das brigas de gato e rato...

7::Ameaças persistentes avançadas. Um dos elementos-chave das ameaças persistentes avançadas (APT, na sigla em inglês) é a obtenção de dados sigilosos de pessoas de interesse (exemplos: executivos, diretores, ricaços), para o que as redes sociais são um verdadeiro tesouro de informações. Quem usa APTs emprega as informações obtidas para seguir adiante com mais ameaças – aplicando mais “ferramentas de inteligência” (como malwares e Trojans) e, com isso, ganhando acesso a sistemas importantes. Assim, apesar de não estarem diretamente ligadas às APTs, as redes sociais são uma fonte de dados. Menos exótico, mas não menos importante para indivíduos, é o fato de que informações sobre sua vida e suas atividades servem de munição para o ataque de cibercriminosos.

8::Cross-Site Request Forgery (CSRF). Embora não sejam um tipo específico de ameaça – é mais uma técnica usada para espalhar um sofisticado verme de rede social -, os ataques CSRF exploram a “confiança” que uma aplicação de rede social tem quando funciona sob o navegador de um usuário já conectado à rede. Durante o tempo em que essa aplicação não verificar novamente a autorização que lhe foi concedida, será fácil para um ataque infiltrar-se no canal de conexão do usuário, enviando conteúdos maliciosos que, clicados por outros, fariam mais vítimas, que por sua vez ajudariam a espalhá-lo.

9::Impostura (passar por alguém que você não é). Várias contas de redes sociais, criadas por pessoas de destaque e seguidas por milhares de pessoas, têm sido invadidas (o caso mais recente é o de um punhado de políticos britânicos). Mesmo sem invadir contas, diversos impostores têm conquistado centenas e milhares de seguidores no Twitter, só para depois constranger as pessoas que fingem ser (exemplos: CNN, Jonathan Ive, Steve Wozniak, Dalai Lama), ou fazer coisas piores. O Twitter disse que a partir de agora vai bloquear esses farsantes que tentam manchar o nome de suas vítimas, mas sob sua decisão. Já ficou comprovado que a maioria dos impersonators não distribui malware, porém algumas contas já fizeram isso (como a do Guy Kawasaki).

10::Excesso de confiança. O ponto em comum entre todas essas ameaças é a tremenda confiança depositada nas aplicações sociais. Como o e-mail na época em que chegou às multidões, ou o mensageiro instantâneo quando se tornou onipresente, as pessoas confiam em links, fotos, vídeos e arquivos executáveis sempre que eles são enviados por “amigos”, pelo menos enquanto não caírem do cavalo algumas vezes. Parece que as aplicações sociais ainda não deram seu coice a um número suficiente de pessoas. A diferença em relação às redes sociais é que o propósito delas, desde o começo, é compartilhar (muita) informação, o que implicará numa curva de aprendizado mais longa para a maioria dos usuários. Isso quer dizer que as pessoas ainda terão que cair do cavalo mais algumas vezes.

quinta-feira, 1 de julho de 2010

Dez fatores essenciais ao sucesso dos projetos

Profissionais criam um guia com os principais passos para evitar problemas comuns às implementações ligadas à área de TI.

Por CIO/EUA
25 de junho de 2010 - 16h57

Qual a receita para o sucesso dos projetos? Muitos profissionais de TI concordam que o apoio dos principais gestores da companhia, uma clara definição de escopo e requerimentos, boa comunicação e os recursos adequados representam os principais ingredientes.

Esses não são os únicos fatores que influenciam as chances de sucesso de um projeto. Os executivos de TI também têm em mente que as iniciativas dependem de uma metodologia, atender às expectativas dos gestores e um grande conhecimento em gestão.

Recentemente, um grupo de 83 CIOs que participam de um grupo de discussões no LinkedIn criaram um guia com os fatores para que o projeto seja bem-sucedido.

Alguns dos fatores mencionados são óbvios, outros nem tanto. Acompanhe os principais itens discutidos:

1. Defina sucesso
Os profissionais só vão atingir o sucesso se souberem exatamente o que é esperado deles. O gerente de projetos globais da empresa Integra LIfeSciences, Steve Hawthorne, diz que é indispensável saber quais os objetivos de um projeto.

“É comum para nós, profissionais de TI, definirmos sucesso como a junção de metas, necessidade e orçamento atendidos”, diz. O executivo ainda afirma que, sim, esses são pontos importantes em um projeto. Mas vale lembrar que compreender a influência desses quesitos para a empresa é igualmente importante. Em outras palavras: saiba o quê, mas tente saber também por quê.

2. Popularidade não é tudo
Consultora de TI e líder de projetos, Bronnie Brooks, diz que, por várias vezes já teve de tomar decisões que a fizeram pouco popular entre os clientes, a gerência ou, mesmo, a equipe. Tudo isso para manter um projeto andando e atingir os resultados esperados. Em uma ocasião, por exemplo, teve de informar ao cliente que determinado recurso – esperado para o software encomendado – não poderia ser integrado ainda. O usuário teria de esperar pacientemente até o lançamento da versão seguinte.

Tomar decisões difíceis sobre onde alocar recursos no meio do andamento de projetos é, no mínimo, difícil. Gerentes de projetos também querem ser queridos, ao passo em que respondem pelo sucesso das empreitadas. Mesmo assim, não podem recuar ante a decisões críticas.

“Às vezes, a melhor decisão não é a mais popular”, diz Brooks, que emenda “mas é o que vai garantir que a projeto ande equilibrando a relação entre o esperado e o possível”.

3. Capacitar o usuário final e acompanhar o start-up
Uma questão óbvia ao sucesso do projeto é treinar os usuários para utilização das soluções. Em muitos casos, porém, a implementação de sistemas falha, não em função de entrega fora do prazo ou por estourar o orçamento, mas porque as pessoas não foram adequadamente treinadas.

“Quando a questão é aprimorar o uso do software, não existe “demais”. Certamente a maioria das soluções novas dão errado, por conta de usuários mal treinados”, afirma um gerente de TI, durante o encontro de CIOs realizado na Espanha.

4. Estabelecer atribuições e competências – de maneira clara e objetiva
Não é raro que pessoas envolvidas em um projeto, como gerentes, equipe de TI, comitês e patrocinadores não entendam exatamente quais são as atribuições individuais. Isso se dá em função da falta de esclarecimento prévio. A afirmação é do auditor de TI pertencente ao The Wood Group, Chet Ung.

Se, por exemplo, o comitê de gestão de um determinado projeto não souber qual a função dentro do projeto, jamais saberá o que é esperado dele. As pessoas têm o poder de mudar o rumo do projeto, e, nem sempre sabem disso. A conseqüência é uma contribuição deficiente, causada pela falta de informação.

“Atribuições e competências precisam ser claramente definidos e documentados. É a única maneira de evitar a confusão e de alcançar o nível de contribuição esperado de cada membro do projeto”, esclarece Ung.

5. Fluxo de trabalho transparente
“Fluxos claros de trabalho não deixam espaço para as pessoas duvidarem qual o espaço em que estão  exatamente alocadas dentro da dinâmica do processo; o que vem antes e para onde vai aquilo no que estão envolvidas no momento”, diz a presidente da empresa norte-americana ProjectExperts, Stacy Goff.

Clareza no fluxo dos processos é um componente essencial quando o objetivo é gerar economia e incrementar qualitativamente todo o projeto. “Nada se compara à segurança de saber que o trabalho está sendo feito por pessoas capacitadas, e que haverá poucas correções a serem feitas naquilo que chega na escrivaninha ou na caixa de entrada. Quando sabe-se que o próximo a receber aquilo no que estamos trabalhando é alguém dedicado e com olhos perfeccionistas, costumamos nos esmerar em nossa tarefas”, diz Goff.

6. Gerenciar alterações no escopo de projetos
É comum que usuários finais de sistemas em desenvolvimento queiram implementar mudanças e alterar algumas nuances nas soluções. Mal sabem que alterações, mesmo que pareçam mínimas, podem ocasionar em modificações brutais no esquema do projeto, influenciando tanto em custo quanto em prazo para a entrega.

Acontece que, nem sempre, o gerente de projetos consegue entender a profundidade da alteração que três botõezinhos a mais na interface do sistema ocasiona no trabalho. “Essa falta de noção é especialmente acentuada nos casos de consultorias externas”, afirma o fundador da empresa de consultoria e de gerência de projetos Spivey & Co., Chris Spivey. Na tentativa de agradar a gregos e a troianos, a gerência de projetos, muitas vezes, aceita a inlcusão dos três botões no sistema. Quando são informados pelo departamento de design técnico que essa implementação vai custar ao projeto alguns preciosos meses de trabalho extra, a casa, literalmente, cai.

É essencial dispor de um processo para gerir mudanças em projetos que estejam em andamento. Nesse gerenciamento devem ser integrados os recursos de aprovação e veto às mudanças, avaliação do prazo exigido pelas alterações e definição de custos dos incidentes. De posse de rotinas dessa natureza, um gerente de projetos pode definir a profundidade do impacto de algumas mudanças caso a caso.

Também oferece ao cliente a oportunidade de reavaliar a necessidade da implementação dos três botões na interface.

Menos surpresa, mais eficiência.

7. Gerenciamento de risco
“A gestão de riscos é, sem a menor sombra de dúvidas, parte essencial de qualquer projeto, independentemente do tamanho”, afirma Goff, da ProjectExperts. De acordo com o profissional, o gerenciamento deve estar integrado em todas as etapas, de concepção a início até o dia do lançamento.

O que torna o gerenciamento de riscos vantajoso é o fato de oferecer ao gestor do projeto uma perspectiva do que pode dar errado. Também vale para deixar a equipe de desenvolvimento, o cliente e os demais envolvidos, esclarecidos acerca dos detalhes e do ritmo a ser adotado para a execução dos trabalhos.

 8. Documentação apropriada
Sem a documentação, as equipes podem não entender de maneira adequada quais funcionalidades e requerimentos técnicos estão atrelados aos recursos planejados para a configuração da solução em desenvolvimento. A ausência da documentação detalhada também implica em um desperdicio de tempo e de recursos na tentativa de acomodar as expectativas do cliente.
É um riso enorme para a equipe, dar andamento em projetos sem embasamento documentado e as metas esclarecidas.

A habilidade de evitar confusão é, para Ung, um dos fatores que justificam a implementação de documentos referentes à execução dos projetos.

9. Controle de qualidade eficiente
Esforços para aferir a qualidade são aplicáveis nas instâncias de integração, de funcionalidade e em ensaios de stress. Não recebem a atenção devida, pelo fato da gerência de projetos não estar familiarizada com esse recurso, nem com suas diferentes vertentes. Em outros casos, à análise de qualidade é dedicado menos tempo  do que o necessário em função do ganho de tempo. A despeito do motivo, o resultado é sempre o mesmo: um software ou um hardware defeituosos – mais trabalho – menos satisfação.

“Ter um acompanhamento de qualidade eficiente é essencial”, diz Ung. “É a única maneira de garantir a entrega de uma solução de acordo com o encomendado”, afirma.

O CTO da Richard Ivey School of Business, Peter Scheyen, recomenda execução de análises de qualidade em todas etapas, e o envio de versões de teste para os clientes. “Obter deles (usuários finais) um feedback sobre o programa é algo muito precioso, é uma das maneiras mais eficientes de reduzir o eventual risco do projeto não estar saindo de acordo com o esperado na outra ponta”, finaliza o profissional da escola londrina.

10. Governança
Segundo Ung, a governança será responsável pela definição dos moldes dentro dos quais um projeto ou um programa devem ser gerenciados. “Ela também define a “linguagem” usada no desenvolvimento das soluções”, adiciona Ung. “Com uma boa governança, o trabalho flui de maneira mais harmoniosa, mais eficiente”, diz.

Ausente, a governança dá ao projeto um ar de inconsistente, pouco confiável. A equipe de desenvolvimento, por exemplo, poderá trabalhar de acordo com um molde, enquanto os analistas de negócios trabalham com outras referências, levando o projeto inteiro de encontro ao fracasso.

CEO da Red Hat: empresas não exploram potencial da tecnologia

Jim Whitehurst alerta os CIOs para as armadilhas embutidas nas promessas da computação em nuvem e questiona a postura da indústria de software proprietário.

Por Network World/EUA
29 de junho de 2010 - 14h18

As melhores experiências oferecidas pelo avanço de TI ainda são experimentadas no ambiente doméstico. Pelo menos, na visão do CEO da empresa de sistemas operacionais Linux Red Hat, Jim Whitehurst.

“Em uma conversa com um CIO, ouvi que 'o Google é o meu maior concorrente' ”, afirmou Whitehurst. Ainda de acordo com ele, esse executivo com o qual falou - e que prefere se manter anônimo - trabalha para uma empresa de logística.

Há alguns meses, o tal CIO foi abordado pelo CMO (Chief Marketing Officer) da sua companhia. Ele queria que a TI criasse um sistema para que os departamentos de marketing de vários países compartilhassem documentos e executassem tarefas de maneira colaborativa.

Depois de consultar os integrantes do departamento de TI da companhia, o CIO voltou a conversar com o executivo de marketing e lhe propôs a realização da tarefa ao custo de 14 milhões de dólares, em um prazo de nove meses.

“Do que você está falando?!” foi a resposta do CMO ao ouvir a proposta do CIO. O executivo do marketing emendou: “Eu estava ajudando minha filha no projeto de escola dela e percebi que fazia tudo usando o Google Docs; se não me engano, o custo era zero”.

O CEO da Red Hat cita essa conversa para ilustrar uma questão mais profunda: o modelo de negócios usado por empresas que adotam plataformas proprietárias está “condenado”.

Os softwares ficam cada vez mais lerdos, mesmo com o avanço na performance do hardware. O motivo disso é que fornecedores de sistemas, como a Microsoft e a Oracle, passam o tempo todo incrementando os pacotes de software com recursos que só são vantajosos para um pequeno grupo de usuários finais.

“Quantas vezes o usuário já foi obrigado a realizar a atualização do sistema, mesmo não tendo qualquer utilidade para os novos recursos implementados? E tudo isso porque, se não comprar a atualização, não pode mais contar com o suporte oferecido pela empresa”, relata Whitehurst.

Para o executivo, isso demonstra um modelo de negócios falido. "Se o produto principal de um fornecedor são os recursos para as plataformas, por que eles não vendem somente os recursos e deixam a cargo dos clientes a aquisição ou não dos complementos?”, justifica.

Nuvens particulares
Isso não quer dizer que a Red Hat não desenvolva os recursos mencionados. Durante um evento nos Estados Unidos, a empresa anunciou a disponibilidade do pacote Cloud Foundations; o nome já revela do que se trata. O produto oferece suporte à formação de nuvens particulares com base na integração de vários serviços do sistema Red Hat Linux.

A organização também aproveitou o evento para anunciar o lançamento do Enterprise Virtualization para Desktops e a versão 2.2 do software de virtualização para servidores.

Mas, de acordo com Whitehurst, a empresa não reajusta o valor do suporte para a versão Server do Red Hat Linux há oito anos. “E nós não inchamos o nosso software, só para fazer mais dinheiro com uma versão nova. Se o cliente é um consumidor, tem garantia de suporte. Ponto.”, diz.

O CEO dá a entender que poderia gerar receita maior, se espremesse os usuários. De acordo com Whitehurst, outras empresas do segmento Linux têm feito mais dinheiro com o sistema que eles. “Temos dez vezes mais sistemas instalados nos servidores que licenças compradas”, diz.

Iate e as nuvensEm um slide seguinte, Whitehurst mostrou um iate enorme, supostamente de propriedade de Larry Ellison (Oracle) e disse “Esse é o iate de um CEO de uma grande empresa de software e, uma dica, não é meu”, disse.

A arquitetura típica de TI em uma empresa costuma ser confusa, intimidadora e conduz muitos CIOs em direção à estratosfera. “A nuvem por si só”, argumenta Whitehurst, “é uma saída 'estratégica pela direita', quando muitos dos problemas internos poderiam ser resolvidos com a disponibilidade das ferramentas apropriadas”.

Os clientes querem arquitetura modular e padrões abertos que possibilitem a portabilidade dos arquivos e dos dados. Se, por um lado, a nuvem oferece essas soluções, ela também pode ser considerada a “maior armadilha de todas”, ao atrair as empresas para o ambiente e, se decidir, não permitir a migração desses serviços de volta para a terra.

A Red Hat é uma das muitas empresas atuantes no segmento de software aberto e proprietário, e afirma fornecer tecnologia com ampla escolha para o consumidor. O cliente pode decidir livremente entre as opções de recursos de hardware ou de software que julgar melhor para a empresa e para os negócios.

Whitehurst afirma que a diferença entre a Red Hat e as outras empresas é que eles trazem junto uma variedade de parcerias com outras companhias.

Apesar de estar envolvida em uma solução de virtualização própria, a Red Hat trabalha em conjunto com a Microsoft e com a VMware para garantir uma integração entre as plataformas e possibilitar que os sistemas operacionais Linux rodem eficientemente em bases ESX e Hyper-v. Nada fora do comum, se admitirmos que é comum vermos sistemas Windows rodando em cima de VMware.
Ao mesmo tempo que o CEO da Red Hat tenta, de certa forma, diminuir o impacto da nuvem, ele lança os softwares de código aberto como solução ideal para esse ambiente. Em resumo, Whitehurst disse que “o software de código fonte aberto é imprescindível para as tendências como o SaaS, a Web 2.0, para a nuvem e a computação em geral; sem a economia gerada pelo uso de software livre essas tendências jamais seriam viáveis”.