Depois de anos e muito dinheiro investido em tecnologia para registrar e armazenar dados de praticamente todas as transações e da vasta gama de objetos instrumentados, os clientes querem obter mais vantagem de todas essas informações. As empresas querem informações mais oportunas e úteis, especialmente se elas puderem afetar de forma direta e positiva o crescimento e a rentabilidade.
A análise dos dados abrange diversos domínios de problemas, incluindo vendas no varejo, fraude, aquisição e retenção do consumidor/cliente, segurança e serviços financeiros. Portanto, envolve muitas tecnologias. Os principais padrões e tecnologias usados para dar suporte à criação de soluções para os diversos domínios de problemas são fornecidos juntamente com o valor que fornecem.
Durante anos, a indústria de TI gastou uma quantidade incalculável de tempo e dinheiro criando sistemas para registrar dados e transações. Além disso, o número de dispositivos que produzem dados que são coletados está crescendo exponencialmente. E mais, vastos sistemas de armazenamento de dados estão disponíveis para armazenar esses dados, e redes rápidas existem para transmiti-los entre os datacenters e as máquinas que os processam. As empresas querem tirar proveito do investimento nos dados disponíveis para obter insights oportunos e úteis, gerando crescimento e rentabilidade.
O que é analítica de negócios?
A analítica de negócios é uma tecnologia que oferece insights imediatos e acionáveis sobre como uma empresa está se saindo. Ela permite detectar e analisar tendências, padrões e anomalias, permitindo fazer planejamento e orçamentos e prever recursos. O objetivo é tomar decisões mais inteligentes, que levem a resultados melhores e mais rentáveis. A oportunidade de criar valor de negócio por meio de dados é reforçada pelo grande volume de dados disponíveis. O desafio é produzir saída de analítica que crie este valor com custo reduzido. A analítica de negócios refere-se à análise e organização dos dados e à entrega de informações de negócios significativas de forma oportuna e conveniente. Por exemplo, alertas em tempo real ou painéis executivos são formas de apresentação que mostram medições de alto nível do desempenho corporativo. Ao fornecer informações on-line, e não em relatórios estáticos, as ferramentas de analítica de negócios permitem conhecer fatos de negócios relevantes mais cedo, permitindo-lhe fazer uma análise detalhada para examinar os detalhes, clicando em um gráfico para ver os números por trás dele.
A analítica de negócios não é um único produto ou tecnologia, mas um domínio de tecnologia que exige muitos produtos para interoperar. Um sistema de analítica analisa dados provavelmente armazenados em bancos de dados diferentes e armazéns em vários formatos de dados. Além disso, o sistema talvez também incorpore alimentações de dados em tempo real para análise em conjunto de dados históricos. Enquanto os dados são analisados, as regras podem ser aplicadas, os modelos preditivos ou de otimização incorporados, e as diferentes formas de saída produzidas dependendo do cenário ou do problema a ser resolvido.
Considere uma loja de varejo que tenta reter clientes existentes. O histórico de compras de produtos do cliente pode ser armazenado em um banco de dados enquanto o histórico de transações dele fica em outro. A loja de varejo pode coletar os tipos de produtos comprados, o valor que determinado cliente gastou com esses produtos em diferentes épocas do ano, a forma como as ofertas de compra influenciam as decisões de compra, e assim por diante. A loja de varejo também tem dados em tempo real que não são armazenados nos bancos de dados supracitados, como o que está entrando e saindo de suas prateleiras no momento, com base em dados reais de vendas. Usando todos esses dados, um modelo de predição pode ser construído para determinar, com um nível de confiança, qual a probabilidade de determinado cliente comprar produtos recebidos ou já existente na loja. Com base nesses vários fatores, esse modelo pode ser combinado a regras de negócios, dados demográficos do cliente e padrões e escolhas de compras de histórico para tomar decisões inteligentes. Por exemplo, uma loja pode planejar uma ação em tempo real por meio de uma oferta especial no ponto de venda, ou pode determinar qual o melhor momento para oferecer e anunciar incentivos e vendas e a quem direcioná-los. A analítica pode fornecer insights interessantes e úteis sobre os clientes, permitindo compreender as tendências e o comportamento dos clientes e se certificar de que os clientes saibam de ofertas específicas e direcionadas.
Os cenários são compostos de vários bancos de dados com informações históricas e alimentações de dados em tempo real, modelos de previsão ou otimização, regras de negócios e um painel de interface com o usuário. Todos trabalham em conjunto entre si, mas não são concebidos ou desenvolvidos para necessariamente resolver o problema específico. Os padrões tratam melhor dessas interações complexas entre os diversos produtos e sistemas devido à comunicação estreita que é necessária. Os padrões proporcionam benefícios ao cliente à medida que eles ficam sabendo que seus dados, regras, modelos de previsão, e assim por diante são armazenados em um formato ou são acessíveis de forma aberta e não controlada por um único fornecedor. Os padrões permitem liberdade de ação que os clientes desejam para não ficarem presos a um conjunto de ferramentas específico, formato de dados ou protocolo. Além disso, os padrões permitem que sistemas distintos trabalhem juntos sem que sejam construídas tendo o outro em mente.
O foco da analítica de negócios é o desenvolvimento de novos insights e a compreensão de um negócio com base em métodos estatísticos e de análise aplicados a esses dados, resultando em decisões melhores e mais bem informadas. O software de analítica de negócios pode fornecer esse e outros tipos de insights para esses e outros tipos de problemas, analisando enormes quantidades de dados em um curto período.
A análise dos dados não é nenhuma novidade. No entanto, alguns dos desafios atuais encontrados nela incluem:
- A grande quantidade de dados que deve ou pode ser processada para produzir resultados precisos e acionáveis
- A velocidade em que é preciso analisar os dados para produzir resultados
- O tipo de dados analisados— estruturados versus não estruturados
Quantidade de dados
Os sistemas analíticos atuais devem ser capazes de lidar com volumes de dados em escala de Internet . Os dados on-line crescem rapidamente, e termos como terabytes, petabytes e exabytes são comumente usados. (Consulte a Tabela 1.)
Tabela 1. Definições e estimativas de volumes de dados
| Definições | Estimativas |
|---|---|
| Gigabyte: 1024 megabytes | 4.7 gigabytes: um único DVD |
| Terabyte: 1024 gigabytes | 1 Terabyte: mais ou menos dois anos de MP3s sem parar. (Supondo um megabyte por minute de música) 10 terabytes: a coleção impressa da Biblioteca do Congresso americano |
| Petabyte: 1024 terabytes | 1 petabyte: a quantidade de dados armazenados em uma pilha de CDs com cerca de 3 km de altura, ou 13 anos de vídeo em HD-TV 20 petabytes: a capacidade de armazenamento de todas as unidades de disco rígido criadas em 1995 |
| Exabyte: 1024 petabytes | 1 exabyte: um bilhão de gigabytes 5 exabytes: todas as palavras já faladas pela humanidade |
Em 2002, havia cerca de cinco exabytes de dados on-line. Em 2009, esse total aumentou para 281 exabytes, uma taxa de crescimento de 56 vezes em sete anos. De acordo com a Forrester Research Inc., a quantidade total de dados armazenados pelas empresas dobra a cada três anos.
Escala de Internet refere-se à era de tamanhos de dados em terabytes e petabytes e à capacidade de ser escalável para satisfazer as exigências de processamento a fim de lidar com essa quantidade de dados em tempo hábil. A quantidade de dados a serem processados inclui dados armazenados, bem como dados de fluxo em tempo real. Hoje, praticamente tudo é gravado de forma eletrônica: vigilância em vídeo e áudio, transações bancárias, transações de compra, tráfego de e-mails, tráfego de mensagens instantâneas, pesquisas na Internet, imagens e registros médicos, e muito mais.
Por exemplo, considere o cenário simples de dirigir do trabalho para casa e parar para comprar gasolina. Ao deixar seu local de trabalho e caminhar até o carro, você provavelmente será gravado em câmeras de vigilância por vídeo. Enquanto dirige, seu celular talvez esteja enviando informações de localização por GPS que são gravadas. Chega então uma mensagem de texto no caminho para casa. O horário e o conteúdo dessa mensagem são armazenados pela sua operadora. Você espera para responder até parar no posto de gasolina, onde outro conjunto de câmeras de vigilância em vídeo registra a atividade. Depois, sua transação de compra de gasolina é registrada, juntamente com seu cartão de fidelidade passado na bomba. O posto de gasolina está em uma área de alta criminalidade que a cidade monitora com tecnologia, como a ShotSpotter (consulte Recursos para obter um link). O ShotSpotter utiliza microfones posicionados em vários locais para gravar e ouvir tiros. Se for ouvido um tiro, as autoridades são notificadas imediatamente e a vigilância por vídeo é direcionada para a área. Portanto, enquanto você está no posto de gasolina, o áudio é analisado e registrado.
Uma parte considerável do aumento de dados armazenados pode e será atribuído aos registros médicos eletrônicos (EMRs). Os EMRs e os avanços nos exames médicos por imagem, juntamente com o tempo que precisam ser armazenados (sete anos de acordo com a lei federal dos EUA), continuarão a contribuir para o crescimento maciço nos dados armazenados. Esses dados armazenados criam volumes de dados em uma escala antes impensável. Além disso, alimentações de vídeo e áudio são extremamente caras de armazenar devido ao grande volume desse tipo de dados coletados, juntamente com suas características ruins de compactação. Esse grande volume torna importante a análise em tempo real desse tipo de dados, o que permite uma forma seletiva de armazenar apenas as partes pertinentes.
São gravados dados em todos os lugares, a partir de praticamente tudo que se move, e de muitas coisas que não se movem também. Além de uma transação normalmente gravada, muitos objetos inócuos, como estacionamentos, prédios e esquinas, são instrumentados e gravam grandes volumes de dados 24 horas por dia.
Com a quantidade de dados armazenados crescendo constante e exponencialmente, cresce também a quantidade de dados que um sistema de analítica de negócios deve processar para produzir resultados relevantes. Pense no Twitter, que processa sete terabytes de dados todos os dias, enquanto o Facebook processa 10 terabytes por dia. O Colisor de Hádrons do CERN gera 40 terabytes por segundo. Sem sistemas analíticos que escalem esses volumes, os dados coletados perdem o valor.
Para colocar esse volume em perspectiva, a Yahoo! relatou que usa o Hadoop para classificar um petabyte de dados em cerca de 16 horas (consulte os Recursos para aprender mais sobre essas referências). Essa classificação exigiu cerca de 3.800 nós com dois processadores quad-core de 2.5 Ghz por nó. Se todos os outros fatores fossem iguais, a classificação de um exabyte no mesmo cluster levaria cerca de 1.000 vezes mais, ou quase dois anos.
Sistemas de analítica de negócios também processam dados de fluxo em tempo real que ainda não foram armazenados. A velocidade com que as grandes quantidades de dados e os dados em tempo real são processados é fundamental para produzir insights importantes em tempo hábil. Em alguns casos de uso de analítica de negócios, o insight ou a resposta corretos, mas fornecidos posteriormente e de forma não oportuna, podem ser considerados a resposta errada. O sistema de analítica de negócios deve ser capaz de lidar com grandes volumes de dados, processá-los de forma eficiente e chegar ao resultado em uma janela de tempo relevante para o usuário. Por exemplo, um sistema de reconhecimento facial que trabalhe a partir de uma transmissão de vídeo em tempo real possui valor muito maior se indicar em um minuto, em vez de um dia após o fato ocorrido, que um suspeito procurado está em um local específico.
Dados estruturados versus não estruturados
A maioria dos dados produzidos hoje é não estruturada. Não estruturado significa que não há nenhum significado latente associado aos dados, de forma que um programa de computador possa entender o que eles representam. Dados estruturados são aqueles que têm significado semântico anexados, tornando mais fácil serem compreendidos. Por exemplo, a seguinte mensagem de texto ou e-mail contém dados não estruturados:
Hi Joe, call me...my numbers are home – 919-555-1212, office – 919-555-1213, cell – 919-555-1213. |
Ao ler essa mensagem, um ser humano sabe o significado latente e o dos dados. Ele pode dizer quais são os números de telefone residencial, comercial e do celular. Para representar os mesmos dados em HTML, eles deverão ser estruturados por meio do seu layout e de como o HTML é organizado em forma aninhada. Os dados, no entanto, não estão estruturados para um sistema analítico, porque não há sentido associado a eles. HTML, e-mails, mensagens de texto, blogs, vídeo e áudio, todos representam informações não estruturadas. Se a informação relevante de número de telefone for colocada em HTML, o resultado talvez seja este:
<h1>List of Numbers</h1> <b>HNumber: 919-555-1212</b> <b>ONumber: 919-555-1213</b> <b>CNumber: 919-555-1214</b> |
O HTML parece estruturado como descrito aqui, mas não é o tipo de estrutura que aplica significado latente aos dados. Esses dados ainda não estão estruturados no que se refere a um sistema de processamento analítico. Além disso, se foi usado XML sem um esquema, também estaria não estruturado da mesma forma que o HTML:
<List of Numbers> <HNumber>919-555-1212</HNumber> <ONumber>919-555-1213</ONumber> <CNumber>919-555-1214</CNumber> </List of Numbers> |
XML costuma ser chamada de semiestruturada. Há estrutura nos relacionamentos dos dados, mas os dados não são estruturados no que diz respeito ao seu significado. Com um esquema, agora é possível dizer que a XML acima é estruturada porque há uma maneira de anexar significado aos dados. Com um esquema, sabe-se que os elementos HNumber, ONumber e CNumber representam diferentes números de telefone: Residencial, Comercial e Celular, respectivamente. Os bancos de dados também contêm dados estruturados. Dados armazenados em linhas e colunas com um esquema permitem que o significado dos dados seja entendido por um programa de computador.
Parte do valor de diferentes produtos de analítica é sua capacidade de processar grandes quantidades de dados não estruturados para descobrir o significado latente. Considere o exemplo de mensagem de texto, HTML e XML sem o esquema acima. Um programa de computador pode descobrir que provavelmente esses são números de telefone porque correspondem a um padrão de três dígitos seguidos de um separador [na forma de um hífen (-), ponto (.) ou espaço ( )], seguidos por mais três dígitos, um separador e depois quatro dígitos. É possível ser feito mais de processamento para inferir que os três números são da Carolina do Norte, devido ao código de área 919. É possível imaginar um algoritmo similar para um número internacional, com código de país.
Dados estruturados são mais simples de processar porque há mais informações disponíveis com antecedência para o programa determinar o significado dos dados. Essa abordagem é mais eficiente do que gastar ciclos de computação para deduzir isso. Grande parte do crescimento de dados na era atual, porém, acontece com dados não estruturados, tornando vital que os sistemas sejam capazes de processá-los de forma eficiente e de determinar corretamente o significado contido dentro neles. Por exemplo, e-mails e mensagens de texto, bem como fluxos de áudio e vídeo, são algumas das maiores categorias de dados não estruturados hoje. Esse tipo de dado não estruturado continua a crescer ininterruptamente, tornando seu processamento eficiente crítico para o sucesso contínuo dos sistemas de processamento analítico de negócios.
Embora a quantidade, velocidade e tipo de dados sejam desafios enfrentados pelos sistemas de analítica de negócios, estão sendo feitos grandes avanços na resolução dessas questões. O processamento de grandes conjuntos de dados, que costumava levar semanas, agora leva minutos. Alimentações em tempo real podem ser processadas de forma eficiente enquanto os dados ainda estão em movimento, em execução em clusters de escalada com recurso de failover, e todos realizados em máquinas commodity. Esse tipo de processamento permite a criação de aplicativos impensáveis poucos anos atrás. Para que essa área da computação tenha benefício máximo, os padrões de software desempenham um papel importante.
Analítica de previsão é onde o software utiliza várias origens de dados históricos para fazer previsões sobre eventos ou comportamentos futuros. As previsões são fornecidas com um nível de confiança respectivo.
Analítica de dados em movimento
Trata-se da análise de dados antes de eles pararem em uma unidade de disco rígido ou outra mídia de armazenamento. Devido à grande quantidade de dados coletados hoje, muitas vezes não é viável armazenar os dados antes de analisá-los. Além disso, mesmo se houver espaço para armazenar os dados primeiro, é necessário tempo adicional para armazenar e depois analisar. Esse intervalo de tempo não é aceitável em alguns casos de uso.
Devido à grande quantidade de dados armazenados, é necessária tecnologia para examiná-los, entendê-los e tirar conclusões a partir deles. Muitos dados são armazenados em locais de relação ou OLAP. Mas, hoje, cada vez mais dados são armazenados de forma não estruturada. Com o crescimento explosivo de dados não estruturados, é necessária tecnologia para fornecer analítica sobre origens de dados relacionais, não relacionais, estruturados e não estruturados.
São usadas regras para definir ou restringir algum aspecto do negócio a fim de tomar decisões mais inteligentes. As regras são armazenadas fora da lógica do aplicativo, tornando mais fácil que uma pessoa de negócios adicione ou modifique regras sem colocar o sistema off-line.
Os relatórios assumem a forma de painéis de interface com o usuário com vários graus de complexidade.
Esta seção descreve alguns dos principais padrões e sua relevância e valor para apoiar a análise de dados.
UIMA (Unstructured Information Management Architecture) é um padrão OASIS no qual a IBM preside o comitê técnico (consulte Recursos). UIMA é uma estrutura para processar informações não estruturadas, descobrir o significado latente, relacionamentos e fatos relevantes contidos nesses dados, e representar os resultados de forma aberta e padronizada. Por exemplo, é possível usar a UIMA para ingerir texto simples e determinar a pessoas, lugares, organizações e relacionamentos, como "é amigo de" ou "é casado com", contidos nos dados. Esses resultados são representados em uma estrutura de dados definida pelo padrão UIMA.
UIMA define quatro termos para ajudar na compreensão do seu papel e propósito:
- Artefato— Um conteúdo não estruturado
- Análise— Designa semântica a um artefato
- Analítica— Software que executa a análise
- Metadados de artefato— O resultado da análise de um artefato por uma analítica
Analise uma grande coleção de pesquisas em restaurantes fast-food, o que equivale a uma grande quantidade de textos não estruturados. Essas informações são analisadas para localizar as razões de queixas mais comuns, identificar os nomes e localizações de lojas com mais queixas e, para cada tipo de queixa, ver quais restaurantes geraram a maior parte das queixas. É possível usar a UIMA para recolher esse tipo de informação a fim de visualizar tendências e o tipo de queixas. Também é possível ver quais tipos de queixas tornam-se mais raros e quais aumentam.
Consultando a Figura 1, os dados de pesquisa brutos representam o artefato (1), visto que se trata de conteúdo não estruturado. A análise designa significado aos artefatos (2). Por exemplo, os restaurantes 15 e 38 têm a maior parte das queixas sobre sobremesas, enquanto o 27 reduziu suas queixas pela metade desde o último levantamento. A analítica é , em geral, o software proprietário que executa essa análise e produz os metadados do artefato(3). Os metadados de artefato são contidos em uma estrutura de dados conhecida como CAS (Common Analysis Structure).
Figura 1. Visualização de alto nível da UIMA
Um dos objetivos da UIMA é apoiar a interoperabilidade da analítica. A CAS permite compartilhar esses resultados entre analíticas. Essa abordagem beneficia os clientes, permitindo-lhes compartilhar as representações de dados e interfaces entre várias ferramentas e produtos que suportam UIMA. De acordo com o exemplo na Figura 1, uma analítica pode interoperar com uma ferramenta que realize a análise de artefatos se ambas suportarem UIMA. Essa capacidade permite que várias ferramentas interajam e que os clientes escolham fornecedores diferentes para a análise de seus dados não estruturados.
A UIMA suporta uma representação de dados comum de artefatos e metadados de artefato de forma independente da representação original do artefato. Ele também permite o intercâmbio independente de plataforma de artefatos e metadados de artefatos, permitindo descobrir, reutilizar e compor uma analítica desenvolvida de forma independente. Além disso, a UIMA fornece interoperabilidade de analítica desenvolvida de forma independente. A UIMA é a tecnologia de ponta nessa área e é apoiada por implementações de software livre Apache. A especificação 1.0 foi concluída em março de 2009, sem que haja trabalho adicional planejado. (Para obter um link para a especificação UIMA, consulte Recursos.)
PMML (Predictive Model Markup Language) é uma linguagem de marcação baseada em XML desenvolvida pelo Data Mining Group (DMG), do qual a IBM é contribuinte. (Consulte Recursos.) PMML representa um modelo de previsão criado depois de analisar dados históricos de vários insights.
Por exemplo, suponha que uma empresa de telecomunicações queira analisar dados históricos para prever, com algum nível de certeza, se os clientes vão descontinuar seu serviço de telefone fixo em favor de serviço de celular. O algoritmo (1 na Figura 2) analisa os dados históricos e produz parâmetros para uma equação entre vários campos de entrada (idade, salário, estado civil, proprietário ou locatário de imóvel, nível educacional, e assim por diante) que prediz melhor se é provável que o cliente abandone o serviço. O algoritmo produz um modelo PMML (2) que é a entrada de um processo de classificação (3). O processo de classificação gera uma previsão (4) sobre a probabilidade de determinado cliente abandonar o serviço, juntamente com um indicador da confiança dessa previsão. Maior confiança na previsão de que um cliente será perdido pode ditar uma resposta mais agressiva.
Figura 2. Visualização de alto nível de PMML
PMML é um padrão de intercâmbio de modelo para compartilhar modelos entre fornecedores. PMML fornece aos aplicativos modelos independentes de fornecedor com o objetivo de que questões de propriedade e incompatibilidades não sejam mais uma barreira para o intercâmbio de modelos entre aplicativos. Isso é benéfico, pois permite que os usuários desenvolvam modelos dentro do aplicativo de um fornecedor e usem o aplicativo de outro fornecedor para visualizar, analisar, avaliar e utilizar os modelos. Visto que PMML é um padrão baseado em XML, a especificação vem na forma de um esquema XML.
A adoção de PMML no segmento de mercado é forte, como indica esta lista de empresas que o adotaram. (Para obter o link para a página da Web, consulte Recursos.)
- Augustus / Open Data Group
- KNIME
- MicroStrategy
- Pervasive DataRush
- Rapid-i
- R/Rattle
- Salford Systems
- SAS
- TIBCO
- Weka
- Zementis
RIF (Rule Interchange Format) é um padrão W3C no qual a IBM é copresidente. RIF representa, em XML, a forma executável de uma regra de negócios. As regras de negócios podem ser usadas em sistemas de analítica de negócios de várias maneiras. As regras são usadas para determinar ações específicas que o sistema toma com base em várias condições e entradas. Por exemplo, uma empresa de empréstimos hipotecários teria regras para determinar se uma pessoa se qualifica para um empréstimo. Fatores como renda, endividamento e pontuação de crédito desempenhariam um papel. As regras podem possuir a seguinte forma: se o mutuário tem renda acima de X, dívida inferior a Y e uma pontuação de crédito acima de Z, ele se qualifica para um determinado montante de empréstimo. Diferentes fornecedores têm sua própria maneira de escrever regras, mas o RIF permite um formato comum e interoperável para seu formato executável.
O RIF foi projetado principalmente para o intercâmbio de regras entre os mecanismos de regra. O RIF agrega valor, pois fornece interoperabilidade entre sistemas de execução de regra, evitando bloqueio por fornecedores de regras. Essa interoperabilidade permite que os usuários empreguem várias ferramentas para criar suas regras de negócio, mas interoperem com vários sistemas de execução de regras que suportam RIF.
O RIF tornou-se a recomendação do W3C em junho de 2010. Portanto, a adoção no segmento de mercado tem aumentado, como indica esta lista de referência de implementações de RIF. (Para obter o link para a página da Web, consulte Recursos.)
- SILK
- OntoBroker
- fuxi
- Eye
- VampirePrime
- RIFle
- Oracle (OBR)
- STI Innsbruck (IRIS)
- riftr
- WebSphere ILOG JRULES
- TIBCO
- FICO
- Drools
Essas implementações possuem padrão RIF, desenvolvido nestas circunstâncias. Várias dessas empresas talvez implementem o padrão completo, embora não se possa afirmar isso com certeza.
XBRL (eXtensible Business Reporting Language) é um padrão da XBRL International baseado em XML usado em relatórios financeiros. A XBRL é relevante porque está ligada e/ou é adotada por diversos governos e países como formato padrão para o fornecimento de relatórios financeiros. Com a sua crescente utilização, a análise de documentos XBRL e os dados que contêm tornam-se relevante.
Tradicionalmente, os relatórios são produzidos em HTML ou PDF. Esses formatos, embora fáceis de ler por um ser humano, não são estruturados. XBRL é estruturado, pois é fornecido em XML com um esquema bem conhecido, mas não é muito legível para os seres humanos. Portanto, é possível inferir o significado a partir dos dados, tornando o documento estruturado e mais útil por um programa de computador.
Recentemente, a SEC começou a exigir que 500 das maiores empresas públicas comecem a arquivar suas demonstrações financeiras utilizando XBRL. Esse requisito vai se expandir gradualmente para incluir pequenas empresas públicas no futuro. As empresas com capitalização de mercado acima de cinco bilhões de dólares começaram a arquivar em XBRL em 2009, mas, este ano, elas devem apresentar as demonstrações financeiras com marcações de notas de rodapé mais detalhadas. Aquelas com capitalização de mercado acima de 700 milhões de dólares devem fazer sua apresentação inicial em XBRL sem marcações detalhadas das notas de rodapé. Todas as empresas coreanas de capital aberto já tiveram, desde outubro de 2007, que arquivar eletronicamente seus relatórios periódicos e outros relatórios financeiros no formato XBRL. Os arquivamentos em XBRL necessários estão sendo usados no Japão pela Bolsa de Valores de Tóquio (TSE), que responde por 90% de todas as transações feitas nas bolsas de valores japonesas. Desde 2008, a TSE exige que todas as entidades cotadas arquivem suas informações financeiras na TSE em formato XBRL.
O XBRL tem sido adotado e imposto em várias das mais maduras economias do mundo. A Tabela 2 identifica diversos países onde XBRL já foi adotado.
Tabela 2. Adoção de XBRL
| País | Organização | Aplicativo/programa |
| Holanda | Autoridade Fiscal Holandesa | Declaração de imposto de pessoa jurídica |
| Austrália | Australian Prudential Review Authority (APRA) | Arquivamentos prudenciais |
| Jamaica | Bank of Jamaica | Arquivamentos registrados de empresas financeiras |
| Estados Unidos | Federal Financial Institutions Examination Council (FFIEC) | Modernização de relatório de resgate |
| Estados Unidos | Comissão de Valores Mobiliários | Programa de arquivamento voluntário em XBRL |
| Bélgica | Banco Nacional da Bélgica | Arquivamentos de contas anuais de empresas belgas |
| Japão | Banco do Japão | Arquivamentos de empresas de serviços financeiros |
| Espanha | Banco da Espanha | Arquivamentos COREP |
| Canadá | Ontario Securities Commission (OSC) | Programa de arquivamento voluntário |
| Japão | Bolsa de Valores de Tóquio (TSE) | Arquivamentos de relatórios financeiros de registrador da TSE |
OWL (Web Ontology Language) é uma linguagem de alto nível para representar ontologias de informações ou modelos. Por exemplo, Joe é um ser humano, é casado com Jane e é do sexo masculino. Sam é um ser humano, é casado com Sue, é do sexo masculino e é marido. Portanto, é possível deduzir que Joe é marido. Essas interações estão sendo exploradas porque o esquema XML muitas vezes tem semântica ruim e exige mais interações humanas para deduzir fatos semelhantes. Com OWL, é possível deduzir mais facilmente o conhecimento de forma programática, tornando a OWL útil para troca de modelos e uso em sistemas baseados em regras.
A seguir, é descrito um cenário de varejo que usa os vários padrões citados anteriormente.
A Figura 3 mostra os componentes de alto nível desse cenário. O componente consiste em:
- Bancos de dados que contêm dados históricos (dados em repouso)
- Alimentações de dados em tempo real (dados em movimento)
- Mecanismos que executam a analítica nesses dados
- Analítica de previsão
- Regras de negócios
- Interfaces com o usuário usando painéis para exibir os resultados ou alertas, permitindo interações com o usuário
Figura 3. Componentes do cenário
A Figura 4 mostra os pontos de integração principais, atuais e futuros, entre os diferentes componentes (na Figura 3) onde os vários padrões discutidos anteriormente interagem e fornecem benefícios de interoperabilidade. Os dados históricos usam uma variedade de padrões, como XML, CSV, XLS, PDF, DITA e XBRL. Os mecanismos analíticos frequentemente usam UIMA. A analítica de previsão e as regras de negócios normalmente usam os padrões PMML e RIF, respectivamente.
Figura 4. Pontos de integração principais
As várias figuras que seguem percorrem o cenário e explicam o valor que os padrões agregam. Os padrões têm um papel importante, especialmente ao implementar esse tipo de solução em um ambiente existente e heterogêneo de cliente. Este cenário representa uma solução para uma grande loja de varejo que está tentando usar dados históricos e em tempo real para aumentar as vendas, manter os clientes existentes e atrair novos.
A Figura 5 mostra os dados históricos da cadeia de varejo, em diferentes bases de dados e armazenados em vários formatos de dados. Este cenário inclui dados, como dados de transações de clientes, preferências, histórico de compras, informações demográficas, dados de pesquisa de opinião, anotações e gravações de central de atendimento sobre o cliente, e assim por diante. Além disso, é fornecida uma alimentação de dados em tempo real. Essa alimentação pode incluir dados, como transações minuto a minuto por loja ou região, dados de transações ao vivo por cliente ou grupo de clientes, alimentações ao vivo de central de atendimento para clientes, alimentações de vigilância por vídeos, produtos a caminho de diversos locais de armazenamento, e assim por diante.
Figura 5. Dados históricos e em tempo real
Cada figura sucessiva usa sombreamento para indicar a porção nova da imagem que foi adicionada. A Figura 6 mostra o Hadoop usado para análise de dados históricos a fim de fornecer analítica em dados estruturados e não estruturados. Por exemplo, a análise desses dados históricos pode revelar informações sobre padrões de compra para clientes específicos, preferências de compra, atitudes em relação a lojas concorrentes, e muito mais. Observe a introdução do padrão UIMA para compartilhar a saída analítica com outros sistemas e permitir a interoperabilidade.
Figura 6. Análise de dados históricos
A Figura 7 mostra a introdução de um mecanismo de análise em tempo real. Esses mecanismos podem ingerir e processar dados em movimento em tempo real, estruturados ou não. Além disso, é possível alimentar resultados da análise histórica no mecanismo em tempo real para ajudar a descobrir insights adicionais. Por exemplo, considere uma análise histórica que mostra que as vendas de determinado produto são melhores durante os fins de semana, mas baixas em outros dias. Além disso, a análise em tempo real mostra que o produto específico está baixo no estoque e que o fim de semana está se aproximando. É possível enviar um alerta sobre essa situação, na esperança de corrigi-la.
A Figura 7 mostra também uma conexão bidirecional entre o mecanismo de análise em tempo real e os dados históricos no banco de dados. O mecanismo pode usar dados históricos para correlacionar com os dados em tempo real, além de poder armazenar os dados periodicamente. Por exemplo, vamos supor que os dados em tempo real continham alimentações de áudio vindas de centrais de atendimento ao cliente. Não é necessário armazenar cada minuto de cada chamada, e sim chamadas aleatórias para análise de qualidade mais tarde. As chamadas em que o sistema detecta um cliente irritado podem ser gravadas para revisão e análise posteriores.
Figura 7. Análise de dados em tempo real
A Figura 8 mostra a analítica de previsão como parte do cenário. (Veja uma versão maior da Figura 8.) É possível usar ferramentas de modelagem para criar um modelo de previsão em PMML. Esse modelo PMML pode ser armazenado no banco de dados e entendido por meio de um mecanismo de análise em tempo real. Por exemplo, é possível usar o modelo de predição PMML nesse caso para determinar a probabilidade de que determinado conjunto de fatos dos dados em tempo real e históricos leve um cliente a abandonar sua fidelidade e comprar de um concorrente. À medida que o mecanismo de análise em tempo real processa os dados, ele pode usar esse modelo para classificar os fatos que descobre. Esta classificação permite que o mecanismo obtenha insights adicionais sobre os dados que está processando.
Figura 8. Analítica de previsão
A Figura 9 mostra que é possível injetar novos modelos PMML no mecanismo de análise em tempo real. (Veja uma versão maior da Figura 9.) Essa injeção é um conceito eficiente, já que é possível criar e implementar novos modelos enquanto o sistema está em execução com base nos dados que estão sendo coletados no momento.
Figura 9. Injeção de modelo PMML em tempo real
A Figura 10 representa a introdução de regras de negócios nesse cenário. (Veja uma versão maior da Figura 10.) À medida que o mecanismo de análise em tempo real processa os dados recebidos e de histórico procurando tendências de vendas, ele pode chamar as regras criadas com um sistema de gestão de regras de negócios para tomar decisões inteligentes adicionais. Por exemplo, uma regra pode dizer: "Se o cliente A, B ou C (parte dos seus clientes Ouro) não teve uma transação de compra nos últimos N dias, e se seus dados de pesquisa indicam que ele pode passar para um concorrente, ofereça-lhe um desconto específico."
A Figura 10 também mostra o padrão RIF. O RIF também é usado para representar a forma executável de uma regra. Essa forma permite que os sistemas de regra de fornecedor compartilhem regras de modo que os clientes não fiquem presos a um fornecedor de regra específico.
Como no caso da injeção em tempo real de novos modelos PMML de predição representada na Figura 9, a Figura 10 mostra como injetar novas regras também em tempo real.
Figura 10. Implementação de regras de negócios
A Figura 11 mostra como são utilizados painéis e recursos de visualização. (Veja uma versão maior da Figura 11.) É possível criar esses recursos combinando as informações em tempo real que estão sendo processadas com os dados históricos armazenados em bancos de dados tradicionais ou OLAP, resultando em alerta em tempo real ou em painel informativo.
Figura 11. Painéis e visualização
Com a explosão de dados coletados e disponíveis, juntamente com a expectativa de ganhar insights novos e adicionais a partir desses dados, existe a pressão para manusear, processar com eficiência e entender dados em volumes antes inimagináveis. Para alcançar esses objetivos são necessários múltiplos sistemas e tecnologias, de legado e novos, trabalhando em conjunto. Essa integração entre as tecnologias exige padrões que permitam a interoperabilidade necessária para integrar os dados, produtos e tecnologias para alcançar de forma eficiente os objetivos almejados pelas empresas e consumidores.
Aprender
- ShotSpotter: Acesse o Web site do ShotSpotter.
- PMML Powered: Acesse a lista de empresas que adotaram PMML, cortesia do Data Mining Group.
- Hadoop Sorts a Petabyte in 16.25 Hours and a Terabyte in 62 Seconds Leia mais sobre o resultado e as regras para as referências de classificação.
- Implementations - RIF: Veja um resumo dos relatórios de implementação recebidos pelo W3C.
- OASIS Unstructured Information Management Architecture (UIMA) TC: Leia mais sobre a padronização de busca semântica e analítica de conteúdo no projeto e especificação em UIMA, em OASIS
- Apache UIMA: Aprenda sobre o projeto Apache UIMA por meio de sua documentação e código de origem.
- PMML 4.0 - General Structure of a PMML Document: Explore como usar XML para representar modelos de mineração no projeto e especificação de PMML, no The Data Mining Group.
- RIF: Analise o projeto e especificação de RIF no W3C.
- XBRL: Acesse o projeto e especificação de XBRL na XBRL International para aprender mais sobre essa linguagem para comunicação eletrônica de dados comerciais e financeiros.
- Projeto Apache Hadoop: Aprenda sobre a estrutura Hadoop que permite o processamento distribuído de grandes conjuntos de dados entre clusters
- OWL Web Ontology Language Overview: Leia mais sobre a Web Ontology Language no W3C.
- Iniciante em XML? Obtenha os recursos que precisa para aprender XML.
- Área de XML do developerWorks: Encontre os recursos necessários para melhorar suas qualificações na esfera de XML. Consulte a seção Biblioteca técnica de XML para ter acesso a uma grande variedade de artigos técnicos e dicas, tutoriais, padrões e IBM Redbooks
- Certificação XML da IBM: Descubra como se tornar um Desenvolvedor Certificado pela IBM em XML e tecnologias relacionadas.
- Eventos técnicos e webcasts do developerWorks: Mantenha-se atualizado em relação à tecnologia nessas sessões.
- DeveloperWorks no Twitter: Inscreva-se hoje para seguir os tweets do developerWorks.
- Podcasts do developerWorks: Ouça entrevistas e discussões interessantes para desenvolvedores de software.
- Demos on demand no developerWorks: Acompanhe demos que abrangem desde a instalação de produto e configuração para iniciantes até funcionalidade avançada para desenvolvedores experientes.
Obter produtos e tecnologias
- Versões de avaliação de produto IBM: Faça o download ou explore as versões de teste on-line no IBM SOA Sandbox e entre em contato com as ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli®e WebSphere®.
Discutir
- Fóruns de discussão da zona de XML: Participe de qualquer uma das várias discussões relacionadas a XML.
- O comunidade do developerWorks: Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.

Peter Haggar é Senior Technical Staff Member da IBM no Research Triangle Park, na Carolina do Norte. Mais recentemente, ele trabalhou em analítica de negócios, padrões de softwares emergentes, XML, XML binário e serviços da Web. Agora, ele trabalha em tecnologia emergente de Internet focada em Watson e DeepQA. Ele trabalha para a IBM há mais de 20 anos. Entre em contato com Peter pelo e-mail haggar@us.ibm.com.