Atualizando mercado de WCM

Em maio, comentei sobre a Fusões de gigantes também no mercado de ECM, quando ocorreu a compra da Vignette pela Open Text. Aproveitei para fazer um panorama atual sobre o mercado de Gestão de Conteúdo Corporativo (ECM).

Em 5 de agosto último saiu o Quadrante Mágico para Web Content Management (WCM) do Garner, para o mercado de gestão de conteúdo web (um segmento específico do ECM), de autoria dos analistas Mick MacComascaigh, Toby Bell e Mark R. Gilbert, Gartner.

[photopress:ecm_gartner_quarante_wcm_2009.png,full,centered]

Fonte: Gartner, agosto 2009, reproduzido por Oracle (Industry Analyst Reports sobre Oracle ECM/WCM).

A Oracle se posiciona este ano como líder, emparelhada com Autonomy, Open Text e SDL.

Irina Guseva comentou a análise em Parsing Gartner’s 2009 Magic Quadrant for Web Content Management em artigo para CMS Wire, 2009-08-10.

E ainda neste mês de setembro deve sair o novo relatório anual do Gartner com o Quadrante Mágico para ECM 2009. Vamos aguardar que alguma das principais empresas fornecedoras divulgue a análise para o público.

Segurança das aplicações web

[Atualizado em 2011-08-21, com referências do OWASP.]

Depois do incidente de segurança envolvendo o portal da operadora Vivo que abordei ontem, um artigo de hoje da IT Web tem tudo a ver: 5 lições de segurança, por Greg Shipley, Tyler Allison e Tom Wabiszczewicz, da empresa Neohapsis especializada em GRC (GRC em inglês), para InformationWeek EUA, 10/09/2009.

No artigo, os especialistas quebram o silêncio típico do mundo corporativo sobre segurança e trazem uma síntese de sua experiência em observação direta das brechas de segurança do mundo real onde realizaram investigações forenses, para ajudar as empresas a entender como essas brechas acontecem e o que se pode fazer sobre elas.

Eles ressaltam: “Após centenas de casos, podemos afirmar, sem sombra de dúvidas, que os ataques estão mais sofisticados do que nunca. Com agilidade, eles exploram controles de segurança falhos e práticas operacionais negligentes e, munidos com ferramentas comuns para gerenciamento de rede, adaptam malwares. Táticas e tecnologias de segurança da informação também progrediram, mas não no mesmo ritmo.”

O mais admirável é que os recursos para mitigar as brechas de segurança são métodos razoáveis e bem conhecidos. O que é preciso é um esforço para que esses métodos sejam implementados e continuamente praticados de forma mais ampla e efetiva pelas corporações.

Problema – vulnerabilidades e ameaças nas aplicações

O Website de uma empresa geralmente serve como porta de entrada para os ataques. Aplicativos web são a porta preferida dos invasores.

Isso porque equipes de TI em geral investem apenas em segurança do perímetro e do tráfego da rede, incluindo proteções clássicas como firewall, antivírus, antispam, IDS/IPS, SSH, HTTPS e VPN. E mesmo nestes casos, não fazem um monitoramento proativo e contínuo, nem tem um plano de resposta a incidentes consistente e efetivo. Por outro lado, mantém sistemas desatualizados e ignoram aplicativos falhos que podem, facilmente, ser explorados.

Códigos de software com pouca ou nenhuma preocupação com segurança desde sua concepção — o que passa inclusive pela escolha de tecnologias que já englobem conceitos e mecanismos nativos de segurança, robustez e proteção — escancaram brechas de segurança por todos os pontos das aplicações.

Nas aplicações corporativas internas, as maiores preocupações costumam ser com vazamento de informações e com uso e permissões indevidos — até mesmo maliciosos, no caso de colaboradores insatisfeitos ou despreparados, negligentes, imprudentes.

Mas quando as aplicações são externas, especialmente em portais, sítios e serviços web abertos à Internet, o universo de ameaças subitamente se expande para o mundo todo, para qualquer pessoa no planeta com acesso internet, algum tempo disponível e intenções que podem ir da curiosidade inconsequente ao crime.

Aplicações sem segurança tipicamente expõem vulnerabilidades amplamente conhecidas — do conhecimento de qualquer hacker de plantão — e graves como:

  • Autenticação vulnerável, com usuários e senhas fracas, pouco ou nenhum controle a tentativas de acesso “força bruta” etc.
  • Baixa granularidade de permissões, de forma que um vez acessado com usuário legítimo muitas vezes se permite acessar alguns serviços ou situações que não seriam efetivamente necessárias ou mesmo devidos àquele usuário.
  • Ausência de validação, consistência e crítica de dados no lado servidor, quando um usuário está com JavaScript desativado ou defeituoso no lado cliente.
  • Ausência de validação de condições limite nos tipos, formatos, valores e tamanhos recebidos em dados ou parâmetros fornecidos pelo usuário, permitindo ataques como Estouro de buffer e de pilha, Corrupção de memória, Negação de serviço (DoS).
  • Ausência ou insuficiência de tratamento robusto, inteligente e proativo de exceções na aplicação. Muitas vezes a maior parte das inúmeras situações de erro ou exceção possíveis são esquecidas, descartadas ou subestimadas pelos programadores.
  • Ausência de mecanismos de rastreabilidade e auditoria, como gravação de registros de log/históricos de acessos e ações do usuário e do próprio sistema.
  • Mecanismos de proteção (integridade e privacidade) de dados com criptografia ausentes, simplórios/precários, ou mal implementados.
  • Não evitar Injeção de código, Injeção de SQL, Injeção de HTML e Cross site scripting (XSS) nas entradas de dados e parâmetros fornecidos pelo cliente/usuário.
  • Utilizar ou permitir a Inclusão de arquivos locais (ou remotos).

A lista de possibilidades comuns poderia se estender. Mas por aí já se percebe que boa parte das aplicações na web são “queijos suíços” em potencial, em se tratando de abundância de furos de segurança.

Solução – informação e ferramentas desde o início

Ao abordarem que se deve levar segurança de TI a sério, os peritos apontam o caminho: “A melhor defesa de uma empresa é a integração da segurança no ciclo de vida de desenvolvimento de aplicativos. A criação de códigos com poucas falhas de segurança oferece um retorno maior do que se tentar reparar aplicativos em uso.”

A organização internacional Web Application Security Consortium (WASC) reúne um grupo de especialistas e praticantes de segurança e representantes de comunidades de código aberto, voltada para intercâmbio de idéias e organização e promoção de melhores práticas, em segurança de aplicação na World Wide Web. WASC consistentemente lança informação técnica, artigos, guidelines de segurança e outras documentações úteis sobre segurança de aplicações web.

Entre o material da WASC, destaco uma compilação com descrição de mais de 50 ameaças e vulnerabilidades em aplicações web, o Glossário de Segurança Web e o padrão de referência para avaliação de vulnerabilidades de aplicações web, Web Application Security Scanner Evaluation Criteria (WASSEC). O material é aberto, público e gratuito (em inglês).

Outra entidade dedicada a promover a melhoria da segurança em aplicações de software é a comunidade internacional Open Web Application Security Project (OWASP). Todas as ferramentas, documentação, fóruns e capítulos criados e mantidos pelo OWASP são livres, abertos e isentos.

Entre os projetos e material de referência mantidos pelo OWASP, destacam-se: Enterprise Security API (ESAPI), Development Guide, Ruby on Rails Security Guide, Secure Coding Practices – Quick Reference Guide, Application Security Verification Standard (ASVS), Code Review Guide, Testing Guide, OWASP Top Ten, AppSec FAQ Project, How To’s and Cheat Sheets, Software Assurance Maturity Model (SAMM), Comprehensive, Lightweight Application Security Process (CLASP).

Para a varredura e análise de vulnerabilidades em aplicações existem ferramentas para auxiliar e prover alguma automação e agilidade nos trabalhos. Há desde softwares livres como o Wapiti – Web application vulnerability scanner / security auditor e o OWASP Zed Attack Proxy, até produtos comerciais como IBM Rational AppScan e HP WebInspect / Application Security (veja também Web Application Scanners Comparison).

Também o padrão internacional ISO/IEC 15408: Information technology — Security techniques — Evaluation criteria for IT security é um conjunto de normas disponíveis gratuitamente.

O padrão ISO 15408 é baseado no Common Criteria for Information Technology Security Evaluation / Critérios Comuns para Avaliação de Segurança de Tecnologia da Informação (abreviado como Common Criteria ou CC). Este, por sua vez, é originado dos padrões para critérios de avaliação de segurança do Departamento de Defesa dos Estados Unidos (TSEC), Canadá (CTCSEC) e Europa (ITSEC, França, Alemanha, Países Baixos e Reino Unido).

CC é um framework padronizado de critérios para especificação, implementação e avaliação de requisitos e propriedades de segurança em sistemas de informação e produtos de TI. O rigor da avaliação é medido em sete níveis, Evaluation Assurance Level, EAL1 a EAL7. Cada EAL consiste em um pacote ou conjunto de requisitos de segurança, denominados Security Assurance Requirements (SARs).

Até eu dou modestas contribuições de informação sobre boas práticas que podem garantir um código de aplicação mais segura, nos artigos: Eficiência e segurança com SQL parametrizado e Senhas armazenadas com segurança.

Não faltam informação e recursos livremente disponíveis, em abundância e muitas delas de alta qualidade e fácil utilização, para que as empresas e instituições comecem a praticar e adotar a construção de aplicações seguras.

Essa preocupação é especialmente crítica na web, que cada vez mais se apresenta como um veículo de serviços e aplicações em larga escala e abrangência.

Empresas do meu Brasil (e do mundo!), cuidem seriamente da segurança de suas aplicações e serviços, especialmente na internet!

Para saber mais:

  • Referências sobre Segurança Digital e Privacidade, incluindo Informação sobre segurança, Entidades e centros, Criptografia, Infraestrutura de chaves públicas (ICP), Malware, Segurança de e-mail, Firewall, Prevenção e detecção de intrusos, Padrões, Protocolos e aplicações, Privacidade, Bibliografia e outros tópicos relacionados.

Software Patterns e Frameworks

O mundo do software vem ficando cada vez mais amplo, abrangente e complexo. Se você olhar o universo abrangido por tecnologias como Java, verá que é difícil “enxergar até o fim de seu horizonte”.

Com isso, a curva de aprendizagem de tecnologias para desenvolvimento de software cresce muito. Em contrapartida vão surgindo iniciativas de melhores práticas e modelos prontos para simplificar situações comuns.

Duas forças nesse sentido da simplificação ou organização de situações comuns em software são os Patterns e os Frameworks.

Software Patterns são padrões conceituais que documentam a caracterização e a solução para problemas comuns (genéricos) de construção de software. Visam definir um idioma comum para estas situações (em vez de descrever a situação/problema/solução, você cita o nome dado a ela) e evitar que se “reinvente a roda”.

Existem patterns voltados para modelagem/desenho — design patterns, arquitetura de software — architectural patterns, integração — integration patterns. Embora não sejam específicos do paradigma orientado a objetos, os design patterns surgiram na área de software contemporâneos a esse paradigma e por isso muitas vezes são definidos usando conceitos de OO e mais facilmente aplicáveis em linguagens com suporte a OO.

Frameworks são arcabouços de construção de software. Ainda não encontrei grandes definições para frameworks, mas eu entendo framework como um modelo de trabalho predefinido para implementação de determinado aspecto de software. Um framework costuma englobar bibliotecas, componentes, APIs, estruturas, mecanismos e uma proposição (ou às vezes imposição) de forma de trabalho.

Enquanto patterns são modelos conceituais, frameworks são soluções práticas e específicas para determinada situação e tecnologia/linguagem. Freqüentemente um framework se baseia ou implementa um ou mais patterns aplicáveis àquela situação. Frameworks visam facilitar e acelerar o desenvolvimento de software.

[Texto originalmente postado na lista de discussão MGJUG-users, em 26/jul/2008.]

Livros sobre software patterns:

Para saber mais:

Whitepaper GlassFish em português

A Sun está distribuindo um whitepaper sobre seu produto baseado no GlassFish, servidor código-aberto de aplicações Java EE: o Portfolio Sun GlassFish.

Baixe o PDF: Construa uma Plataforma Web Aberta de Alto Desempenho para sua Empresa com o Portfolio Sun GlassFish™
Documentação da Sun Microsystems, Fevereiro de 2009
(original em inglês)

A única solução de software livre (código aberto) que tem se mantido, em 2006 e 2008, no quadrante líder do relatório do Gartner Quadrante Mágico para Servidores de Aplicação Corporativos é o Red Hat JBoss. A solução da Sun tem se mantido um pouco atrás, no quadrante dos visionários, mas bem próximo de se juntar aos líderes.

O software livre Apache Geronimo está situado em uma posição mais atrás, ainda no quadrante dos players de nicho, embolado com vários outros fornecedores rumando o início do quadrante líder.

O relatório do Gartner terá atualização no terceiro trimestre de 2009. Então, brevemente veremos como estará o posicionamento atual desses servidores, provavelmente já contemplando a fusão dos líderes BEA e Oracle.

Veja a seguir transcrição do resumo e do índice do artigo da Sun.

Resumo

Sun GlassFish whitepaper - capa As atuais empresas de TI líderes de mercado devem construir mais com menos — mas o mercado oferece ferramentas excessivamente caras, muito difíceis de adquirir/usar/manter ou de que ofereçam suporte aos padrões da concorrência. O portfolio Sun GlassFish™ é uma plataforma de aplicativo Web aberta completa que proporciona às empresas as inovações provenientes das principais comunidades de código-fonte aberto, empacotado em uma solução que oferece preços flexíveis baseados em inscrições e suporte empresarial. Proporciona às empresas de todos os portes a extraordinária escalabilidade e segurança necessárias para os aplicativos de missão crítica.

Índice

  1. Resumo executivo
  2. Desafios do mundo atual
    • Inovações da comunidade vs. soluções patenteadas
  3. A solução da Sun
  4. 10 razões principais para usar o portfolio Sun GlassFish
  5. Perspectivas do setor
    • Portfolio Sun GlassFish no governo
    • Portfolio Sun GlassFish nas telecomunicações
    • Portfolio Sun GlassFish na saúde
  6. Conclusão
    • Saiba mais

Sun GlassFish whitepapers e webcasts em inglês:

Fusões de gigantes também no mercado de ECM

Não é só no mercado de infra e middleware que os líderes estão uns comprando os outros. No segmento de Gerenciamento de Conteúdo Corporativo (Enterprise Content Management – ECM), a canadense Open Text acaba de comprar a Vignette. Ambas empresas estão entre as principais no mercado de ECM, sendo que a Open Text é considerada por institutos de pesquisa uma das cinco líderes do setor, ao lado de EMC, IBM, Oracle e Microsoft.

Dentre as líderes, a Open Text é a única empresa exclusivamente focada em ECM; as outras atuam em diversos segmentos. Já a Vignette é especializada em conteúdo e mídia digital para web e Internet, ou seja, o segmento de ECM específico de Gerenciamento de Conteúdo Web (Web Content Management – WCM) e Sistemas de Gerenciamento de Conteúdo (Content Management Systems – CMS).

Open Text compra Vignette por US$ 310 milhões, por IT Web, 2009-05-08.

Press release por Open Text (Waterloo, Ontario, Canadá) e Vignette (Austin, Texas, EUA): Open Text to Acquire Vignette (idem na Vignette), 2009-05-06.

Veja a evolução do Quadrante Mágico do Gartner, do Forrester Wave e do Datamonitor Decision Matrix para o mercado de ECM nos últimos anos:

[photopress:Gartner_Quadrante_ECM_2008.png,full,centered]

Fonte: Gartner, Quadrante Mágico para Enterprise Content Management, 2008; 2008-09-23; por Karen M. Shegda, Toby Bell, Kenneth Chin, Mark R. Gilbert, Mick MacComascaigh; reproduzido por Microsoft; também por EMC, por Oracle e por Day Software.

[photopress:Gartner_Quadrante_ECM_2007.png,full,centered]

Fonte: Gartner, Quadrante Mágico para Enterprise Content Management, 2007 [PDF]; 2007-09-21; por Karen M. Shegda, Toby Bell, Kenneth Chin, Mark R. Gilbert; reproduzido por IBM.

[photopress:Forrester_Wave_Q4_2007.png,full,centered]

Fonte: Forrester, The Forrester Wave™: Enterprise Content Management Suites, Q4 2007 [PDF]; 2007-11-09; por Kyle McNabb, para Information & Knowledge Management Professionals; reproduzido por Oracle.

[photopress:datamonitor_matrix_ecm_2006.png,full,centered]

Fonte: Datamonitor, Decision Matrix: Selecting an Enterprise Content Management Vendor (Competitor Focus) [PDF]; dezembro 2006; reproduzido por EMC Corporation em ECM Connection.

[photopress:gartner_quarante_ecm_2006.png,full,centered]

Fonte: Gartner, Magic Quadrant for Enterprise Content Management, 2006; 2006-10-11; por Karen M. Shegda, Kenneth Chin, Mark R. Gilbert, Debra Logan, Toby Bell, Lou Latham.

Empresas e produtos considerados líderes:

Desafiantes:

  • Autonomy Interwoven (aquisição em janeiro 2009) – também focada em ambiente web/internet, assim como a Vignette.
  • Hyland Software – OnBase – solução de GEC/ECM muito amigável.
  • Xerox – DocuShare.
  • Alfresco – Alfresco Enterprise – software de código aberto criado por dissidentes da Documentum.

CMS Watch – Mapa de Fornecedores ECM, em estilo “mapa de metrô”:

CMS Watch - ECM Subway Vendor Map

Para saber mais:

Disseminando Engenharia de Software

A DevMedia, grupo de comunicação que publica no Brasil as revistas Java Magazine, SQL Magazine, Web Mobile, Clube Delphi e .net Magazine, lançou recentemente a Engenharia de Software Magazine, disponibilizada mensalmente, exclusivamente em meio digital para download (edição 1 gratuita).

É uma iniciativa pioneira para promover e disseminar a engenharia e a arquitetura de software, áreas que nos últimos anos tem se expandido em abrangência, complexidade e importância no projeto e desenvolvimento de sistemas. A revista abre espaço para boa informação em melhores práticas, metodologias, tecnologias, ferramentas, mercado e casos de sucesso.

Na área acadêmica, a Sociedade Brasileira de Computação (SBC) organiza anualmente, há mais de duas décadas, o Simpósio Brasileiro de Engenharia de Software (SBES). A 23ª edição do SBES ocorrerá de 5 a 9 de outubro em 2009 na UFC, em Fortaleza, Ceará, realizado junto com o Simpósio de Banco de Dados (SBBD).

Já com enfoque mais prático e no mesmo espírito da revista ES Magazine, a DevMedia organiza agora outro evento, a Engenharia de Software Conference, que será realizada nos dias 22 e 23 de maio deste ano em São Paulo, SP,

Com caráter inovador e independente, a Engenharia de Software Conference não tem patrocínio de nenhuma empresa fabricante de software, para garantir imparcialidade. Serão 40 horas de conteúdo, distribuídas em 30 palestras. A conferência é voltada para profissionais atuando no campo de engenharia de software. É uma oportunidade excelente de capacitação, divulgação e networking.

O evento da DevMedia conta com a presença de palestrantes renomados, como a keynote Ana Regina Rocha, uma das idealizadoras do Modelo Mps.Br (Melhoria de Processos do Software Brasileiro), implementadora e avaliadora SOFTEX e membro do grupo de pesquisa em Engenharia de Software da Universidade Federal do Rio de Janeiro.

Veja a seguir a divulgação do Engenharia de Software Conference.

Raras são as oportunidades de ter acesso a informações que realmente podem transformar sua carreira. Essa é uma delas.
Dias 22 e 23 de maio, a DevMedia promove em São Paulo o evento
Engenharia de Software Conference.

Serão 30 palestras que vão desde o projeto até o último teste de um software, passando pelos modernos conceitos de gerenciamento.

Com palestrantes renomados e temas pertinentes o evento promete excelentes oportunidades de aprendizado e networking.

Reserve sua agenda. Inscrições Limitadas


DevMedia

Checklist: Diagnóstico de indisponibilidade no ambiente de serviços web

Em mais de 16 anos trabalhando com o ambiente de aplicações e conteúdo web, boa parte deles atuando ou cooperando na administração, já vivenciei muitos problemas.

Em geral, nada é mais atordoante do que o surgimento (súbito ou intenso) de algum evento ou reclamação de indisponibilidade ou erro em um ou mais serviços ou recursos. Em um ambiente complexo como este, interpretar os sintomas, rastrear até a origem, identificar a(s) causa raiz do problema e obter uma solução é missão ampla e complexa.

Some-se o fato de, cada vez mais, o ambiente web estar sendo cenário de sistemas e serviços de missão crítica e operação ininterrupta 24×7. Ou seja, é uma estressante corrida contra o tempo.

Por isso, elaborei aqui um checklist procurando listar todos os elementos envolvidos neste complexo ecossistema, para orientar e facilitar o diagnóstico de indisponibilidades no ambiente de serviços web.

  1. Problemas e sintomas
    1. O quê: Caracterização dos problemas: quais serviços, em que situação
    2. Quando: Data ou período de início de problemas observados ou reportados
    3. Como: Cada problema identificado pode ser reproduzido sistematicamente, ocorreu uma única vez, ou é intermitente?
  2. Usuário
    1. Indisponibilidade ou problemas de configuração no acesso do usuário
    2. Desktop usuário infectado por malware
    3. Desktop usuário com problemas no navegador, no sistema operacional, instalação ou configuração de software
    4. Desktop usuário com gargalos ou problemas de processamento e desempenho de hardware (CPU, memória RAM, GPU, disco/armazenamento, rede), ou de configuração de driver, software ou sistema operacional
    5. Desktop usuário com falhas ou defeitos de hardware
    6. Robôs de busca e varredura com atividade excessiva
    7. Invasores, ataques e usos indevidos ou mal-intencionados
  3. Aplicação
    1. Defeitos (bugs, inadequações ou ineficiência) no código da aplicação, inclusive SQL (consultas, stored procedures) submetido ao banco de dados
    2. Serviços ou aplicações web implantados ou atualizados no período
    3. Configurações e testes realizados em produção ou desenvolvimento
    4. Mudanças no contexto/cenário operacional
  4. Infraestrutura de Software
    1. Gargalos de configuração ou picos de ocupação (slots, threads, ouvintes)
      1. Proxy ou web cache
      2. Servidor web
      3. Servidor de aplicação (Java EE, .NET, PHP etc.), CMS/ECM, SOA, ESB, BPM e outros servidores de middleware
      4. Servidor de banco de dados
      5. Outros serviços, recursos e mecanismos envolvidos (autenticação, transação, armazenamento etc.)
    2. Incompatibilidade e falhas – atualizações e patches no período
      1. Serviços proxy, web, aplicação, banco de dados, outros
      2. Sistema operacional
      3. Java VM, ferramentas, componentes e bibliotecas
  5. Infraestrutura de Hardware e Rede
    1. Hardware dos servidores – Gargalos ou falhas
      1. Uptime – tempo “no ar” desde o último desligamento
      2. E/S (I/O): discos, partições e storage em geral
      3. CPU: carga, multitarefa, deadlocks, temperatura
      4. Memória e cache
    2. Equipamentos e configurações de rede e conectividade
      1. Gargalos e falhas de hardware nos equipamentos de rede e conectividade
      2. Falhas (mau contato, encaixe, desgaste, ruptura etc.), interferência ou insuficiência em cabeamento, conectores e sinal sem-fio
      3. Ativação e configuração de interfaces, rotas e domínios de rede
      4. Mudanças e atualizações de configuração de switches, roteadores, hubs etc.
      5. Mudanças e atualizações de firewall, IDS e outros appliances de rede, conectividade e segurança
    3. Transmissão de dados e telecomunicações
      1. Falhas ou indisponibilidade nos canais (links) de comunicação de dados
      2. Gargalos no tráfego, volume ou QoS de dados
    4. Gerenciamento de energia e ambiente
      1. Falhas ou instabilidade no fornecimento ou rede de energia
      2. Falhas em no-breaks, estabilizadores ou geradores
      3. Falhas ou insuficiência na refrigeração
      4. Falhas ou incidentes na estrutura física do ambiente
      5. Invasores, ataques e ação ou mal-intencionada na segurança física do ambiente
  6. Provedores de serviços e recursos
    1. Mudanças ou alterações diversas ocorridas em provedores externos

Os itens de diagnóstico aqui listados são, em geral, apenas os elementos a serem verificados, sem entrar em detalhe de como fazer o diagnóstico, pois isso pode variar muito de um ambiente para outro.

Entre os recursos de diagnóstico, destaco dois, presentes na maioria dos sistemas ou componentes de tecnologia:

  • Arquivos de log/registro/histórico de mensagens/avisos/alertas/erros
  • Console, ambiente ou ferramenta de administração, monitoramento e controle

Como a lista é grande, priorize a análise e o diagnóstico dos elementos para os quais haja indício provável — em especial, evento, registro ou alta probabilidade de incidente, falha, ou alteração recente –, deixando os menos suspeitos para o final. Como costumo dizer: “Não procure chifre em cabeça de cavalo.”

Referências relacionadas:

IDG Computerworld sobre BI e BA

O portal Computerworld da IDG Brasil está com um hotsilte Company Zone patrocinado pelo IDC – Conheça as vantagens do Business Intelligence.

O “IDC Special Study – A Inteligência dos Negócios como Diferencial Competitivo” provê informações sobre o mercado de Business Intelligence e Business Analytics, em uma série de matérias:

O conceito de Inteligência de Negócios em TI, tradicionalmente conhecido como BI (Business Intelligence – Inteligência de negócios) evoluiu para o conceito de BA (Business Analytics – Análise de negócios). Pesquisas realizadas pela IDC mostram que, para atender às transformações do negócio, o Mercado de Business Intelligence tem evoluído em ciclos:

  • 1975 a 1990: basicamente produção de relatórios em mainframes;
  • 1990 a 2005: interfaces amigáveis e arquiteturas cliente-servidor (reporting, DW, data mining, ETL, OLAP, dashboards, scorecards);
  • o último, iniciado em 2005 com previsão de término em 2020, traz consigo o conceito de Inteligência de Negócios, aplicado a soluções mais completas, evoluindo para o que o mercado chama de BA (Business Analytics).

[photopress:Evolucao_Mercado_BI.gif,full,centered]

Fonte: Qual o panorama atual do mercado de BI e BA, Computerworld, IDG Brasil, baseado em análise do IDC, 2008.

A inteligência analítica de negócios (BA) possibilita o acesso, a transformação, a armazenagem, a análise, a modelagem, a entrega e o rastreamento da informação com o objetivo principal de capacitar a tomada de decisão estratégica. Divide-se, basicamente, em duas categorias: Performance management – PM (ferramentas e aplicações) e Data Warehouse – DW (plataformas); engloba, além das tradicionais ferramentas de BI e plataformas de armazenagem DW, aplicações analíticas de CRM, BPM, SCM e OPP. Os benefícios obtidos pelas instituições devem influir diretamente na melhoria de processos de negócio, na forma de mais velocidade, assertividade, relevância, consistência, controle e visão.

A IDC mapeou as ações que devem ocorrer em ordem cronologia para a obtenção de sucesso em um processo de avaliação, aquisição e implantação de um projeto de Inteligência de Negócios:

  1. Gestores devem identificar e mapear as necessidades e processos organizacionais, com foco na importância estratégica de cada um destes.
  2. TI deve identificar e selecionar os possíveis parceiros estratégicos, observando capacidade tecnológica, competência técnica e de negócios, aderência ao perfil da organização, relação custo benefício, atuação do fornecedor, incluindo tamanho (receita anual) e seus atuais clientes e casos de sucesso, e a diversidade quanto a extensão e abrangência do portfólio de produtos oferecidos.
  3. Criar um comitê de competência, composto por dois grupos-chave de pessoas: o grupo de conhecimento técnico e o grupo de conhecimento de negócio; este comitê será responsável por definir as funcionalidades do projeto de Inteligência de Negócios a ser implementado pela organização.
  4. Planejar e negociar contratos, definindo claramente escopo, prazo, custo, condições de exceção, matriz de responsabilidades, níveis de serviço (SLA), indicadores, métricas — atentar-se para as métricas de negócio, e não apenas as técnicas — bônus e penalidades.
  5. Gerenciar, executar e controlar o projeto, com acompanhamento contínuo do projeto para assegurar que aquilo contratado está sendo cumprido e está satisfatório, bem como identificar possíveis necessidades de mudanças, oferecendo ao comitê embasamento para as tomadas de decisão.

Segundo a IDC, os maiores erros na adoção destas soluções, que podem levá-la ao insucesso ou à insatisfação, são normalmente:

  • Uma adoção liderada apenas pela área de tecnologia, sem o apoio da alta gerência e sem o devido envolvimento das outras áreas internas de interesse.
  • Falta de conhecimento sobre os impactos que podem ser gerados pela nova solução, nos negócios da organização. Por exemplo, considerar disponibilidade de 99,5% como um indicador, sem prévia análise.
  • O quanto custaria para a empresa a indisponibilidade de 0.05%? Esta sim deveria ser a questão a ser respondida.

Os aspectos técnicos são sim importantes, mas os de negócio também o são. Uma boa solução deve começar sempre com o entendimento real do processo de tomada de decisão, que ocorre ao longo de cada processo de negócio. É preciso entender e documentar as decisões tomadas, bem como o impacto que causaram no desempenho. Responder a perguntas pode auxiliar nesse entendimento:

  • Como tomamos as decisões hoje?
  • Estas decisões são tomadas de forma coerente?
  • Quem são os melhores tomadores de decisão?
  • As decisões consideram indicadores reais de negócio?
  • Estamos utilizando as melhores práticas na tomada de decisão?

Para aumentar as chances de sucesso de um projeto de BI/BA, a IDC sugere, inclusive, que um centro de competência seja considerado, a fim de assegurar:

  • Apoio e aprovação da alta gerência.
  • Equipe composta por especialistas na tecnologia de BA e por especialistas no negócio da organização que tenham poder de decisão.
  • Foco na integração contínua, na qualidade e nos esforços magistrais para a gerência de informações.
  • Única fonte de conhecimento corporativa para o processo de tomada de decisão.
  • Políticas e procedimentos de governança estabelecidos.
  • Indicadores de medida de performance definidos de acordo com as necessidades de negócio da organização.
  • Redução do risco de fracasso.

Desde 2006, o mercado de fornecedores de solução para BI e BA tem evoluído e se movimentado bastante em consolidação e convergência, como constatava o artigo “Quatro tendências em BI que você deve conhecer” publicado pelo portal CIO em janeiro desse ano.

Dos grandes fornecedores, SAS Institute é o único “pure player” focado totalmente nesse mercado, o que contribuiu para ser um fornecedor de destaque por suas inovações. Outros grandes players têm aumentado seu foco de atuação em BI e BA com aquisições, como Oracle (adquiriu Hyperion em mar/2007), IBM (adquiriu Cognos) e SAP (adquiriu Business Objects em out/2007). Além dos fornecedores já citados, Microstrategy e Microsoft também aparecem entre os líderes. Para mais informações, veja o artigo “Líderes em BI 2008” neste blog.

O Whitepaper Fatores críticos para o sucesso do BI oferecido pela Microstrategy, disponível para download gratuito (PDF) no portal da IDG Computerworld Brasil, traz também um diagrama muito interessante apresentando uma arquitetura de referência para o que o artigo chama de Pervasive BI:

[photopress:Arquitetura_Ref_BI_Pervasive.png,full,centered]


Uma pena que não esteja mais disponível para download no portal da Computerworld Brasil o Executive Briefing “A Importância da Business Intelligence”, com uma coletânea de seis matérias em que os editores da revista apresentam visões e análises do mercado de BI.

O primeiro artigo destaca a previsão do Gartner que até 2012, BI fará parte de 85% das aplicações corporativas, envolvendo desde aumento de identificação de oportunidades táticas até uso em transformações de processo de negócio.

Para um panorama do presente, o quarto artigo traz a informação que, de acordo com a pesquisa “B2B Marketing Report” conduzida pela Epsilon Interactive junto a 175 profissionais de marketing dos Estados Unidos, BI já é essencial para 98% dos executivos de marketing.

O segundo artigo traz pesquisa da Forrester Research, encabeçada pelo analista Boris Evelson, apontando 10 dicas para uma estratégia de BI bem sucedida:

  1. Escolha um responsável do Nível-C (que não seja o CIO nem CTO). A implementação de BI não deve, em absoluto, ser responsabilidade da TI; deve estar patrocinada por um executivo de primeiro escalão da linha de frente.
  2. Crie definições comuns. Métricas e indicadores devem ser única e claramente definidos.
  3. Tenha acesso à atual situação. Tanto a área de TI como de negócio devem estar envolvidas na análise detalhado do ponto em que está a inteligência de negócio na instituição, incluindo processos, fluxos e estrutura organizacional.
  4. Crie um plano para armazenamento de dados.
  5. Entenda o que os usuários precisam.
  6. Decida entre comprar ou construir o modelo de análise de dados.
  7. Considere todos os componentes de BI.
  8. Escolha um sistema integrador.
  9. Pense em “acionável” e em “pequenos passos”. Escolha a dedo um usuário especialista, um analista de negócio e um desenvolvedor e crie primeiro uma prova de conceito.
  10. Escolha algo simples para começar, mas com compenentes de alto valor para produzir resultados. O projeto deve começar pequeno, escolhendo-se de 10 a 20 indicadores de desempenho e criando padrões e governanças com base neles.

O quinto artigo do Executive Briefing da Computerworld faz um alerta essencial: BI exige profissional com experiência de negócios. O perfil necessário ao profissional encarregado das iniciativas de Business Intelligence (BI) demanda conhecimentos técnicos na mesma medida que capacidades de negócios. Eles precisam, antes de mais nada, entender os tipos de decisão que a instituição precisa tomar, as perguntas que deverão ser feitas no processo de decisão e os tipos de dados que vão responder a estas questões. Os profissionais de BI também devem ter talentos sociais, em especial habilidades de comunicação mais apuradas.

Cloud computing – não confundir com grid computing

Cloud computing, ou computação em nuvem (computação nas nuvens, para os mais românticos) é o termo que vem sendo adotado para o seguinte conceito e tendência: uso de recursos computacionais e serviços baseados na Internet (chamada “a Nuvem”, “the Cloud”). Segundo Reuven Cohen, a explicação mais simples para cloud computing pode ser descrita como ‘software centrado na Internet’.

Isso engloba o uso maciço de software como serviço (software as a service – SaaS) através da Internet — o exemplo típico são as aplicações de escritório do Google Docs disponíveis e utilizadas através da Internet, utilizando-se um simples navegador/browser Internet no computador do usuário. Também inclui a tendência de desenvolvimento de aplicações que incorporam serviços e funcionalidades disponibilizadas através da Internet, chegando até o desenvolvimento de software e serviços usando uma plataforma computacional disponibilizada pela Internet, como mostra o artigo A short introduction to cloud platforms — An Enterprise-oriented view [pdf] de David Chappel, agosto 2008.

Atualmente, empresas como Google e IBM encabeçam a promoção e a pesquisa do uso de cloud computing, muitas vezes alardeado como o futuro da informática, como mostra a reportagem Google prepara, hoje, o futuro da informática [vídeo] da Rede Globo, apresentada no Jornal da Globo de 6 de maio de 2008.

Embora profetizado como grande tendência futura para os próximos anos, cloud computing enfrenta também o ceticismo e a crítica, como por exemplo se vê no ensaio do cronista de tecnologia americano John C. Dovorak (reprodução comentada por Antonio Passos), em sua coluna publicada na revista INFO Exame de junho de 2008. Já para o especialista visionário Nicolas Carr, autor do best-seller Does IT Matter (2004) e do livro recente “A grande virada: reconectando o mundo, de Edison a Google” (do inglês The Big Switch: the World from Edison to Google), cloud computing é uma forte previsão, mas a adoção nas grandes empresas não vai acontecer do dia para noite, ainda levará de uns cinco a dez anos para as grandes corporações migrarem em peso sua TI para cloud.

Cloud computing não deve ser confundido porém com grid computing, ou computação em grade/grelha. Este último consiste no modelo computacional do uso de um conjunto ou agrupamento de computadores em rede (mas com baixo acoplamento) para computação distribuída de aplicações e serviços, se comportando como uma espécie de super computador virtual, permitindo a realização de tarefas em larga escala.

A utilização de plataformas cloud computing — ou seja, a formação de um grid de computadores disponibilizados através da Internet — é uma forma possível de implementação de grid computing. O caso mais comum atual de grid computing, porém, ainda é a agregação de um conjunto de servidores dentro do ambiente de datacenter de uma corporação, aproveitando o investimento em servidores de pequeno e médio porte para produzir o processamento e a disponibilização de serviços de grande porte.

A definição de Dennis Byron, analista da Research 2.0, apresentada no blog Carreira e Certificações em TI no artigo Computação em nuvem: Microsoft, Google e tempestade à vista, apresenta uma relação objetiva entre os dois conceitos:

O cloud é, basicamente, uma combinação de grid computing, que tratava basicamente de potência de processamento bruta, e software como serviço. Na realidade, cloud é virtualização de rede.

Para saber mais sobre cloud computing:

Para saber mais sobre grid computing:

Para saber mais sobre computação distribuída:

Tiers and Layers – Camadas Físicas e Lógicas

[Atualizado em 31 de outubro de 2008.]

No contexto de arquitetura de software, ambos os termos técnicos Tier e Layer em inglês podem ser traduzidos para português como Camada, em geral relativo a sistemas multi-camadas. Mas cuidado para não haver equívoco ou ambiguidade, pois os dois termos não são meros sinônimos, têm significados distintos.

  • Layer se refere a Camada Lógica de organização dos componentes do sistema ou aplicação.
  • Tier se refere a Camada Física ou Estrutural dos componentes com foco na infraestrutura (hardware, sistema operacional e serviços/servidores) e suas responsabilidades no sistema.

Segundo Peter Eeles, no artigo Layering Strategies, o termo layer (camada) se refere à aplicação do padrão arquitetural genericamente conhecido como Layers Pattern, que estrutura em camadas um sistema que requer decomposição, por algum motivo. Por exemplo, um sistema:

  • que é muito complexo para ser compreendido em seu todo de uma só vez;
  • que é difícil de ser mantido;
  • que é construído por equipes distintas, possivelmente com habilidades e conhecimentos diferentes;
  • cuja maioria dos elementos reusáveis são difíceis de se identificar.

Eis as principais camadas lógicas (layers), segundo Martin Fowler in: Patterns of Enterprise Application Architecture (Addison-Wesley, 2003, ISBN-13 978-032112742-6, 560 p.), Capítulo 1 – Layering, The Three Principal Layers:

Camada Lógica Responsabilidades
Apresentação Interação com usuário (exibição de informações, validação de entrada), provisionamento de serviços.
Domínio / Negócio Lógica específica particular ao sistema ou aplicação.
Acesso a Dados Comunicação com bancos de dados, EIS, sistemas de mensagens, monitores de transação.

Uma boa prática que se prega no projeto da arquitetura de software é que cada camada lógica só deve interagir com a(s) camada(s) imediatamente adjacente(s), visando a maior separação de atribuições (coesão) e o baixo acoplamento.

As camadas físicas (tiers) caracterizam a infraestrutura sobre a qual o sistema ou aplicação executa. As camadas físicas podem variar de acordo com a plataforma e o ambiente tecnológicos específicos que se utiliza. Um modelo canônico de camadas físicas em ambiente web pode ser resumido como a seguir.

Camada Física Caracterização
Cliente Navegador (browser) web, páginas DHTML (HTML, JavaScript, CSS, DOM), componentes/plug-ins adicionais RIA (Flash, Applet Java, JavaFX, ActiveX, XUL etc.), outros objetos MIME (dados, documentos e arquivos em outros formatos).
Rede e Serviço Web Servidor web, protocolo HTTP sobre TCP/IP, processamento de requisição-resposta do cliente web, encaminhamento e integração com servidor de aplicações.
Serviços de Componentes e Aplicação Servidores de aplicação (plataformas mais comuns: Java EE e Microsoft .NET), servidor de objetos distribuídos (EJB, COM+, CORBA etc.).
Serviços de Dados e Integração Servidores de bancos de dados (SGBD), sistemas de mensageria, mecanismos de integração/interação com outros sistemas (EIS).

 

Tipicamente, as camadas lógicas são mapeadas em uma ou mais fatias da camada física da arquitetura. Para exemplificar um mapeamento típico de camadas lógicas em camadas físicas no ambiente web, a apresentação em geral abrange o cliente web, o servidor web e os mecanismos MVC do servidor de aplicação; o domínio ou negócio se concentra no servidor de aplicação; e o acesso a dados se concentra nos servidores de bancos de dados e outros eventuais componentes na camada física de dados e integração.

Contudo, para Eeles, o termo layer é um conceito geral de divisão de um sistema em camadas, que pode ter diversas estratégias de organização e aplicação. Este autor define tier como um caso específico de layer associado a estratégia particular de responsibility-based layering (camadas baseadas em responsabilidades).

Eeles ainda adverte para o fato que mesmo tiers não implicam a efetiva organização ou distribuição física. Um sistema 3-tier pode estar fisicamente em um único hardware, ou ter suas camadas distribuídas entre dois ou mais computadores (grid, cluster, farm etc.).

Para saber mais:

Layers Pattern: