por Sean Gordon, Robert Grigg, Michael Horne e Simon Thurman

Resumo

Essa discussão analisa as semelhanças e diferenças entre BI (Inteligência de Negócio) e SO (Orientação a Serviços), dois paradigmas arquiteturais que se desenvolveram de forma independente. Defi nimos aqui uma estrutura arquitetural que promove os pontos fortes de BI e SO, ao mesmo tempo em que defi nimos princípios orientadores para garantir que as doutrinas fundamentais de cada uma das arquiteturas integrantes não estejam comprometidas.

O substantivo sinergia significa a ação combinada de entidades ou condições discretas, uma vez que o efeito total é maior do que a soma dos seus efeitos individuais. A SoBI (Inteligência de Negócio e Orientação a Serviços) constitui a sinergia dos paradigmas de BI e SO e descreve os padrões e a arquitetura para realizar essa sinergia, fornecendo uma estrutura de implementação recomendada pelas melhores práticas; a capacidade de se integrar ao nível arquitetural mais apropriado; a modelagem de dados de um projeto de BI dentro da estratégia de SO de deixar os sistemas de fontes implantados; e uma implementação comum para as transformações de dados e a lógica de dados: de dados para dados, de dados para serviços, de serviços para dados e de serviço para serviço.

A BI e a SO constituem paradigmas amplos. Vamos começar defi nindo BI. O data warehousing é uma disciplina ampla que permite a coleta, a consolidação e o armazenamento de dados para suportar a BI. Os componentes de um data warehouse bem-sucedido podem ser resumidos como coleta, limpeza e consolidação de dados ETL (Extract Transform and Load), e armazenamento de dados. A BI é a entrega das informações para suportar as necessidades de tomada de decisão da empresa. Pode ser descrita como o processo de aprimorar os dados na forma de informações e depois na forma de conhecimento. Cada sistema de BI tem uma meta específi ca, que se origina das exigências do negócio.

Figura 1 - Visões da BI e da SO

Figura 2 - Visões da BI e da SO

Figura 3 - Visões da BI e da SO

Para facilitar a leitura, o armazenamento de dados e a inteligência de negócio serão consolidados na sigla BI ao longo dessa discussão. A SO é um meio de construir aplicativos distribuídos; no seu nível mais abstrato, a SO enxerga tudo como prestador de serviços: dos aplicativos para as empresas, passando pelos dispositivos. Os prestadores de serviços expõem os recursos por meio das interfaces. Essas interfaces defi nem o contrato entre o chamador do serviço e o serviço em si. O consumidor de um serviço não se importa em saber como o serviço é implementado, apenas o que ele faz e como invocá-lo.

Os próprios serviços são os alicerces dos aplicativos orientados a serviço. Os serviços encapsulam os aspectos fundamentais da orientação ao serviço, ou seja, a separação entre a interface e a implementação.

A SO é essencial para garantir a agilidade de negócio e a fl exibilidade de TI prometidas pelos serviços da Web. Esses benefícios são entregues não apenas ao se visualizar a arquitetura de serviços da perspectiva tecnológica ou ao se adotar protocolos de serviços da Web, mas também ao se exigir a criação de um ambiente orientado ao serviço que se baseia em princípios específicos importantes.

A BI existe há anos; suas práticas são bem-estabelecidas, e as pessoas sentem-se confortáveis com os conceitos envolvidos no fornecimento de uma solução de BI. Para muitos, a BI é simplesmente a apresentação de informações de uma maneira oportuna por uma interface sofi sticada de cliente. Para aqueles envolvidos no fornecimento de soluções de BI, esse aspecto da solução geral de BI é a ponta do iceberg. Abaixo do nível da água, há um enorme exercício no aprimoramento da qualidade dos dados e a integração dos dados entre aplicativos e sistemas corporativos distintos, e a consolidação desses dados em um armazém de dados. A integração dos dados tem predominantemente o maior custo em um projeto de BI.

Convergência EAI e ETL

Até recentemente, a SO teve pouco ou nenhum papel para desenvolver no mundo da BI, principalmente porque a abordagem da SO na integração dos dados parecia cansativa e excessivamente complexa para uma comunidade acostumada a movimentar dados de qualquer volume conectando-se diretamente ao sistema de fontes no nível do banco de dados. Na BI, a integração dos dados é realizada por meio do processo ETL, que é a pedra angular de qualquer solução de BI, e as soluções de BI tendem a buscar a maneira mais direta e efi ciente de realizá-la.

A EAI (Integração de Aplicativos Empresariais), como a BI, está presente há muitos anos. É um problema comum encontrado numa empresa em que os sistemas foram implementados ou desenvolvidos de uma maneira orgânica. A própria EAI pode ser defi nida como o compartilhamento do processo e dos dados entre aplicativos dentro da empresa. Especifi camente, quando usamos o termo EAI, estamos nos referindo à integração dos sistemas dentro da empresa – por exemplo, integração de aplicativos, dados e processos.

A integração de aplicativo a aplicativo se refere à troca de dados e serviços entre aplicativos dentro da empresa. De forma especial, essa forma de integração ocorre com freqüência entre aplicativos que se encontram em plataformas tecnológicas diferentes, com base em arquiteturas diferentes. Em geral, a EAI é difícil e como de costume exige a conectividade entre plataformas tecnológicas heterogêneas; envolve regras e processos comerciais complexos, além de processos comerciais de longo prazo nos quais as unidades lógicas de trabalho podem se estender por dias ou semanas à medida que se movimentam por processos diferentes dentro da organização; e em geral é orientada pela necessidade de ampliar/aprimorar um negócio ou processo automatizado existente ou introduz um processo de negócio automatizado inteiramente novo.

As soluções para os problemas de EAI podem envolver a resolução do problema de integração dos aplicativos em uma série de níveis arquiteturais diferentes, como o de dados, aplicativos, processo e assim por diante. Dessa maneira, tanto a ETL quanto a SO podem fazer parte de uma solução EAI. De muitas maneiras, a SO se desenvolveu a partir da necessidade de encontrar soluções comuns, abertas e interoperáveis para o problema da EAI.

A ETL tradicional é um processo orientado por lotes que se concentra na integração dos dados durante o tempo de inatividade do negócio. No mercado conectado de hoje, a empresa não tem um tempo tranqüilo para que esse processo ocorra. O conjunto de dados corporativos tem o potencial de aumentar signifi cativamente à medida que iniciativas como a seqüência de cliques, o comércio eletrônico e a RFID são cada vez mais utilizados, e a ETL deve ser fl exível o sufi ciente para emergir de suas raízes orientadas a lotes e fornecer dados em uma base orientada a eventos.

Em uma solução SO, esses eventos são prontamente roteados, consumidos e integrados como parte de uma arquitetura orientada a eventos. A BI se desenvolveu da incapacidade dos sistemas operacionais de lidar com efi ciência com as capacidades analíticas (agregação, tendência, exceção, etc.), daí que sistemas distintos de TI foram desenvolvidos para atender a essa necessidade. Essa divisão artifi cial não é mais aceitável; as empresas de hoje estão buscando cada vez mais utilizar as capacidades analíticas para orientar suas decisões operacionais – por exemplo, na descoberta de um cartão de crédito suspeito fraudado no checkout, com base nos dados históricos extraídos em padrões fraudulentos.

Figura 4 - SO como fonte de dados para a BI

Figura 5 - BI consumindo os eventos de SO

As organizações também estão cada vez mais ansiosas para desbloquear esses dados e disponibilizá-los mais amplamente a outras partes da organização, para um público maior de usuários e ferramentas. Tradicionalmente, o acesso às informações da BI sempre exigiu acesso a um conjunto específi co de ferramentas de manipulação de dados. No atual ambiente de SO, a meta deve ser abrir esses dados organizacionais para um público mais amplo e permitir que o valor dos dados seja percebido de forma mais abrangente.

Uma variedade mais ampla

À medida que aumentam a variedade e o número de fontes de dados considerados dentro do escopo da BI, aumenta também a complexidade em potencial da solução ETL exigida. Por exemplo, os serviços da Web, o RSS e os dados não estruturados e semi-estruturados são fontes de dados que agora se enquadram sob o guarda-chuva da integração de dados, mas não estão tradicionalmente associados a ETL. Com a adoção disseminada dos princípios orientados ao serviço e as tecnologias associadas de ativação, o acesso a uma maior variedade de sistemas torna-se possível, desbloqueando uma variedade muito mais ampla de dados comerciais.

As organizações continuam a escrutinar a economia da integração de dados em cada projeto, afetando os produtos que selecionam, e isso está gerando uma mudança no cenário da integração de dados e uma mudança relacionada na funcionalidade fornecida por software de ETL ou EAI. Os fornecedores precisam aumentar a fl exibilidade e a funcionalidade oferecidas por suas plataformas em resposta a esses novos desafi os. O resultado líquido para o cliente é um conjunto de ferramentas com uma gama cada vez mais integrada de funcionalidades.

Os usuários familiarizados com o conjunto de produtos da Microsoft não podem ter deixado de perceber esse padrão. O BizTalk foi desenvolvido no espaço da EAI e da fi losofi a B2B (Business-to-business), mas pode ser aplicado em alguns cenários de ETL. Os DTSs (Serviços de Transformação de Dados), a ferramenta ETL da Microsoft que faz parte da plataforma SQL Server 2000, foram desenvolvidos a partir de um cenário de ETL. Não é nenhuma coincidência o fato de que a versão SQL Server 2005 desse projeto tenha sido rearquitetada para suportar uma variedade mais ampla de cenários de integração, tendo sido rebatizada de Integration Services para enfatizar isso.

Embora as SOAs e as arquiteturas de BI tenham evoluído separadamente e incluído tecnologias e disciplinas específi cas aos seus próprios objetivos arquiteturais, muitas das tecnologias que elas utilizam se sobrepõem. Também há um claro mapeamento entre os conceitos utilizados, e cada um deles consegue ver o outro em seus próprios termos. Chamamos isso de “visões do outro lado”, e a visão geral pode ser vista na Figura 1.

Vamos discutir cada cenário em mais detalhes.Da perspectiva da BI, é possível enxergar um aplicativo de SO como uma coleção de fontes de dados e de eventos. Há dois modos principais nos quais um serviço pode funcionar como fonte de dados em um contexto de BI: serviço como o provedor dos dados mediante solicitação e serviço como editor de eventos que são de interesse (consulte a Figura 2). Em ambos os cenários, os tamanhos da mensagem são pequenos. A solução para a transferência e a transformação dos dados em larga escala ainda será por meio das técnicas normais de importação do armazém de dados, tais como a ETL.

Essas mensagens fi sicamente grandes não são o domínio normal da SO. Do ponto de vista da SO, a BI pode ser vista como uma coleção de serviços. Da perspectiva da SO, uma fonte de dados pode ser prontamente exibida como serviço com a inserção de uma camada simples de fachada que recebe a solicitação de serviço do barramento de serviço e chama a solicitação apropriada. A “fachada” então transforma os resultados da solicitação (se necessário) no esquema de dados e retorna os resultados ao chamador (consulte a Figura 3).

A arquitetura SoBI disponibiliza os dados de BI no armazém de dados como serviço para outros aplicativos dentro da arquitetura. Essa disponibilidade fornece aos aplicativos uma forma tranqüila de acessar os dados consolidados para suportar as exigências da BI. Dessa forma, a arquitetura de BI torna-se um componente integrado da arquitetura de aplicativos da SO. Observe que haverá ocasiões em que o tipo de dados que é necessário do sistema é puramente de natureza da inteligência de negócio , tais como a exportação de dados de larga escala. Nesses cenários, a abordagem da interface do serviço não será adequada.

Figura 6 - Tamanho da mensagem versus volume da mensagem

SO (Orientação ao Serviço)	BI (Inteligência Comercial)
Mais bem adequada à integração de aplicativo para aplicativo e bem ajustada aos eventos de baixo volume e baixa freqüência	Mais bem adequada à integração de dados para dados e capaz de lidar com grandes volumes de dados
Fornece uma plataforma operacional, define com fi rmeza os formatos e as estruturas de dados e encapsula e abstrai a funcionalidade	Fornece um modelo combinado dos dados empresariais e fornece as bases para as decisões comerciais, além da capacidade de fazer qualquer pergunta sobre os dados
Suporta a reutilização dos componentes empresariais e permite a mudança ágil nos processos comerciais	Ferramentas e mecanismos bons para transformar os dados

Provisão de dados orientada ao serviço

Da perspectiva da inteligência comercial, um serviço pode ser prontamente exibido como fonte de dados com a inclusão de uma camada simples de fachada que fornece um mapeamento entre a interface de BI e a interface exposta pelo serviço. A “fachada” então transforma os resultados da chamada do esquema de dados usado no barramento de serviço no formato de dados esperado pela plataforma de BI , devolvendo os resultados ao chamador (consulte a Figura 4).

Alguns serviços expõem as informações por meio de eventos que são publicados quando ocorre uma mudança interessante no serviço. Outros serviços e aplicativos na organização podem se inscrever nos eventos publicados pelos serviços. Integrar serviços de publicação de eventos em uma plataforma de BI é algo que se consegue com utilização de um agente que coteja os eventos inscritos e os transfere periodicamente em grandes quantidades para a plataforma de BI (consulte a Figura 5).

Um dos desafi os no desenvolvimento da SoBI era encontrar uma abordagem que promovesse os principais pontos fortes de cada arquitetura e identifi casse a área em que a integração causava mais desafi os. Vamos dar uma olhada em alguns dos principais desafi os inerentes à implementação da BI seguindo os princípios da SO. Esses desafi os geralmente surgem devido às exigências específi cas das quais cada arquitetura precisava dar conta no seu desenvolvimento.

A Figura 6 mostra as diferenças na granularidade dos dados que separa as abordagens da BI e da SO. Em pontos extremos, temos mensagens ou eventos de pequeno porte, que estão naturalmente no espaço de evento da SO. Essas mensagens de pequeno porte não são consumidas de forma imediata ou efi ciente em uma arquitetura de BI sem a utilização de agentes de eventos para cotejar esses eventos e importá-los para o armazém de dados em uma base regular. Os dados de grande porte, ou seja, a importação em massa ou o movimento de grandes quantidades de dados, são manuseados com mais efi ciência por meio das técnicas de armazém de dados, como a ETL. Os serviços em um sistema de SO que expõem grandes quantidades de dados são inefi cientes de usar e raramente implementados. No meio do caminho, temos os serviços típicos de médio porte, defi nidos para consumir dados sufi cientes para atender a uma exigência em particular. Esse meio do caminho é a chave para o valor agregado da SoBI.

Os aplicativos orientados ao serviços apresentam um vínculo fraco entre seus serviços integrantes. Esse vínculo fraco é um dos princípios fundamentais da SO e suporta o desenvolvimento de aplicativos ágeis/ fl exíveis que podem se adaptar à mudança comercial. Consulte a Tabela 1 para ver os benefícios específi cos da SO e da BI.

As soluções de BI estão fi rmemente vinculadas às fontes de dados que alimentam o armazém de dados e aos aplicativos que o utilizam.

A BI evoluiu de um ambiente centrado em lotes no qual a ETL é usada como meio para consumir e consolidar diretamente grandes quantidades de dados do sistema de fonte, seguindo um cronograma conhecido de preenchimento do armazém de dados.

Figura 7 - A estrutura SoBI

A SO exige que a interface da mensagem e os formatos das mensagens de entrada e da resposta eventual estejam fi rmemente defi nidos. Com efeito, ao se expor os serviços que descrevem as capacidades comerciais, as questões que podem ser feitas em um aplicativo de SO são conhecidas de antemão. No entanto, também há um aspecto desconhecido que se relaciona à exposição dos serviços que são agregados ou orquestrados por outro aplicativo. A BI está preocupada com a capacidade de permitir que os aplicativos façam qualquer pergunta ao armazém de dados dentro dos limites do modelo de armazém de dados. A pergunta, ou o tamanho, o conteúdo e o formato do resultado não são conhecidos até que a questão seja feita.

A SoBI vence

Uma abordagem SO é mais adequada para a exposição dos serviços que encapsulam as capacidades ou serviços comerciais que publicam eventos de interesse para outros sistemas. A BI fornece um ambiente fechado para satisfazer as exigências de informações da empresa. A BI permite que o consumidor dos dados os visualize de muitas e diferentes maneiras potencialmente novas. Essa fl exibilidade fornece a capacidade de identifi car tendências e relações que podem ser negligenciadas.

Anteriormente apresentamos os principais pontos fortes de cada um dos paradigmas, e eles podem ser vistos como questões fundamentais caso sejam vistos puramente da posição do outro paradigma. Agora vamos revisitar esses desafi os e ver quais benefícios a SoBI pode trazer. A funcionalidade da ETL na superfície do warehouse para a SoBI permite que eventos comerciais interessantes, apreendidos durante o processo de ETL, sejam publicados como eventos. Vamos considerar alguns exemplos.

Integridade referencial. A SoBI pode fornecer agregações da posição “agora”. Por exemplo, os dados que não se encontram no sistema de origem podem ser adicionados no armazém de dados como espaço reservado, a fi m de manter a integridade dos dados no banco. Esse espaço reservado pode ocorrer quando sistemas distintos de fontes fornecem dados em momentos diferentes (por exemplo, valores transacionais fornecidas antes que as informações associadas de referência sejam recebidas). Esses dados serão armazenados como dados reservados privados dentro do serviço da BI. É possível enviar uma notifi cação para o sistema de fonte para garantir que não tenha ocorrido um erro, e quando os dados de referência tornam-se disponíveis o armazém de dados estará novamente em sintonia com o sistema de registro.

Serviço de validação única. A funcionalidade necessária para a validação durante o estágio da ETL pode ser exposta por meio da estrutura SoBI para utilização em outras partes da empresa. Atualizações no momento certo. A principal vantagem aqui para a BI é que a adoção da ETL da perspectiva da SO pode permitir inserções reais em tempo sufi ciente no armazém de dados e, portanto, o armazenamento de dados potencialmente em tempo real. Além disso, o melhor suporte aos eventos e à integração orientada a eventos pode fornecer à BI um mecanismo muito melhor para invocar a ETL do que os métodos tradicionais, como o cronograma agendado ou a análise persistente de um diretório conhecido por um arquivo indicador.

Esquema comum de negócio. Dentro de qualquer organização, pode haver múltiplos sistemas que mantêm as informações sobre as mesmas entidades e que guardam essas informações em diferentes formatos. Há sinergias claras entre esses cenários:

• Desenvolver o modelo lógico de dados para o armazém de dados é essencial para qualquer iniciativa de BI. O modelo de dados constitui o produto fi nal dos esforços para consolidar os dados dos sistemas de fontes distintos. A estrutura do modelo de dados orienta o exercício de transformação que ocorre como parte do preenchimento do armazém de dados e, conseqüentemente, permite que o armazém de dados forneça a versão única da verdade para as informações de gerenciamento.

• Para qualquer serviço de agregação de entidade dentro de um projeto de SO, é importante conseguir consenso sobre os signifi cados comuns para as entidades nas quais os serviços vão operar. Esse consentimento é referido como consolidação do esquema, sendo o processo de criar esquemas de dados principais que contêm um superconjunto das informações para descrever as entidades no sistema com detalhes sufi cientes para que serviços diferentes possam localizar os dados de que necessitam.

Outro serviço de entidade que entra em sintonia com essa abordagem é a capacidade de expor os dados de referência. De acordo com Easwaran G. Nadhan, diretor-geral do EDS, “fi ca claro com as experiências em um número (relativamente pequeno) de organizações que passaram a adotar as SOAs agressivamente que coordenar os dados de referência é o primeiro passo necessário para se conseguir a orientação de serviço” (consulte Recursos).

Uma verdade

Uma versão da verdade. Dando uma olhada na funcionalidade oferecida por duas arquiteturas holisticamente, a SoBI nos fornece a oportunidade de consolidar os dados operacionais e de BI sem a necessidade de transferir fi sicamente todos os dados operacionais para a plataforma de BI, que é uma abordagem comum para fornecer a “versão única da verdade” em um projeto de BI. Adotando a escolha arquitetural mais apropriada, os dados operacionais podem ser deixados no lugar, mas ainda estar disponíveis para a estrutura da SoBI como serviço, caso surja a necessidade de acessá-los ou consultá-los.

Por exemplo, em um ambiente de TI interessado na análise de incidentes de segurança ou de saúde, a SoBI permitiria que os detalhes factuais de cada incidente fossem transferidos para o armazém de dados – ou seja, o fato de que um acidente aconteceu, onde aconteceu e a classifi cação desse incidente –, o que permitiria que toda a análise e a agregação apropriadas fossem realizadas como esperado pela plataforma de BI.

A vantagem da SoBI é que ela fornece um meio de ainda acessar os detalhes transacionais no sistema de registro (por exemplo, o texto em formato livre que acompanha o incidente, que descreve em detalhes as circunstâncias em volta do acontecimento). Esse acesso é geralmente conhecido como “detalhamento” na BI, e para realizá-lo todos os dados relevantes à exigência são tradicionalmente transferidos para o armazém de dados.

Na verdade, talvez não se permita (por razões de proteção de dados) ou não se prefi ra (aumenta o fardo da ETL e as exigências de armazenamento do armazém de dados para mantê-los, os quais, por defi nição, são operacionais por natureza) fazer isso, tendo o potencial de acrescentar pressão extra à plataforma de BI ao se tornar a verdadeira fonte para todos os dados de incidente, muito embora nunca esteja atualizada.

Serviços comerciais. A combinação da habilidade do BI trabalhar com tempo real sufi ciente e da capacidade de deixar os dados operacionais no lugar nos dá a oportunidade de desenvolver um serviço valioso em torno da estrutura SoBI que não seria possível caso estivéssemos trabalhando em apenas uma das arquiteturas integrantes. Pense em um sistema de detecção de fraude no varejo. Na BI, temos as ferramentas para desenvolver um mecanismo analítico capaz de buscar padrões em quantidades potencialmente enormes de dados transacionais, resultando em uma lista de cartões de créditos suspeitos.

A adoção de princípios de SO nos permite oferecer um serviço que fornece os detalhes de cartões de créditos em utilização no nosso armazenamento à medida que são descartados. A arquitetura de SoBI permite que esse serviço seja consumido pelo componente de BI da plataforma e o analise em relação à lista conhecida de cartões suspeitos, e portanto responda imediatamente caso seja detectada uma transação potencialmente suspeita.

Uma nova geração de serviços comerciais

Agregação de dados transacionais e históricos como serviço. Dado um serviço exposto por meio da estrutura de SoBI que agora pode agregar com perfeição os dados transacionais atuais e os dados históricos do armazém, é possível fornecer suporte a uma nova geração de serviços comerciais. Um exemplo seria mudar lentamente as dimensões, que é onde um valor como o nome do cliente muda com o tempo. Obviamente, essas informações estão disponíveis no armazém de dados, por isso, se houver a exigência de expor um serviço de entidade que dá uma visão única do cliente, pode-se conseguir isso com mais precisão e facilidade.

Trazer os padrões de abstração de interface para a BI. A capacidade de usar o padrão de abstração de interface na funcionalidade da BI torna a funcionalidade e os dados mais acessíveis aos aplicativos de linha de negócios, permitindo-se a exposição de regras comerciais complexas geralmente escondidas na camada da ETL.

Figura 8 - Dimensionamento e fl exibilidade ideais

Limpeza e consolidação. Os dados serão alterados por motivos de consistência e integridade. Quando essa mudança envolve uma operação de mapeamento, este será disponibilizado para a arquitetura como serviço. Quando essa mudança envolve a correção dos dados, os detalhes dessa correção serão repassados ao sistema de registro por meio de uma solicitação de mudança ao serviço de posse, ou seja, o processo de ETL não pode alterar os dados uma vez que não é o proprietário. Por sua vez, esse processo obviamente promove o aperfeiçoamento da qualidade dos dados.

Obter uma visão consistente e de múltiplos sistemas do produto. Durante o estágio de ETL, os dados do mesmo produto (ou entidade) podem exigir transformação, para que possam ser armazenados de uma forma consistente. Com o serviço ativando o acesso aos dados, a organização pode expor uma única visão comum de um produto.

Mapeamentos disponíveis como serviços. Como se observou anteriormente, o mapeamento é uma exigência fundamental no estágio de ETL. A estrutura SoBI permite que a funcionalidade do mapeamento seja exposta como serviço para outros usos dentro da organização. Esses usos incluem cenários de referências empresariais e de EAI. Essa disponibilidade desse serviço também pode ser usada para promover transformações otimizadas.

Cálculo. O armazém de dados geralmente é usado para armazenar valores pré-calculados e suportar as exigências da inteligência comercial. Por exemplo, os dados de vendas e de previsões podem ser mantidos em sistemas físicos diferentes. A consolidação dos dados desses sistemas no armazém de dados nos permite calcular e armazenar os índices reais e os da previsão, permitindo análises e relatórios de alto desempenho. A lógica de negócio usada para defi nir esses cálculos geralmente interessa a outras partes da empresa, por isso o cálculo que fornece respaldo a essa invenção dos dados no armazém será disponibilizado para a arquitetura SoBI como serviço.

Fornecer uma estratégia para a integração. Acredita-se que um dos resultados da estrutura SoBI é a capacidade, no nível arquitetural, de fornecer uma estrutura para os futuros cenários de integração. Conformidade/auditoria. A aplicação da estrutura SoBI exige a adesão a um processo formal de governança. Entre os exemplos estão a identifi cação do sistema de registro ou do proprietário dos dados operacionais, e a defi nição das mensagens que descrevem as exigências funcionais e dos dados. Dado que apenas o proprietário dos dados pode fazer uma mudança neles, outros sistemas simplesmente fazem uma solicitação de mudança, e a auditoria pode ser executada num ponto único.

Agregação. Para suportar tempos rápidos de resposta, os dados no armazém são geralmente pré-agregados. Por exemplo, o armazém de dados pode conter dados relacionados às vendas em um nível individual de transação, mas a maioria dos relatórios da administração pode exigir que os totais sejam apresentados mensalmente. Nesse caso, é mais econômico listar as (potencialmente milhares de) transações individuais em um nível mais apropriado para as pesquisas conhecidas e armazenar os resultados em um conjunto, evitando a necessidade de se fazer pesquisas conhecidas para realizar a ação de agregação no momento da pesquisa. Quando essas agregações forem criadas, elas serão disponibilizadas para a arquitetura como um serviço.

Qualidade dos dados da empresa

A maioria das organizações sofre com o problema da compatibilidade entre seus sistemas de TI. Esse problema é ainda mais visível quando ocorrem fusões. Não existe razão pela qual os sistemas de empresas completamente diferentes sejam consistentes ou alinhados, ou satisfaçam um projeto unifi cado. Uma iniciativa de BI precisa resolver os problemas de sistemas diferentes, dos silos de dados e da incompatibilidade dos dados por meio de iniciativas de qualidade nos dados. Caso os usuários da empresa não confi em nas informações que lhe são apresentadas, eles não usarão o sistema.

Figura 9 - Ordenando eventos para a integração

Figura 10 - Atualizando as fontes de dados não empresariais

Melhorar a qualidade dos dados não é simplesmente um processo de resolver problemas com elementos individuais de dados; trata-se de projetar um processo de negócio que melhore o gerenciamento e a qualidade dos dados como recurso empresarial. Em um aplicativo de SO, os dados fornecidos por um serviço são controlados por meio de encapsulamento por ele realizado, sendo publicados apenas em um formato específi co que corresponda ao esquema de dados defi nido pelo serviço.

Consegue-se o acesso aos dados por meio das mensagens que o serviço publica. O serviço é responsável apenas pela manutenção da integridade dos dados, uma vez que constitui o único mecanismo que manipula diretamente os dados. O esquema que defi ne as entidades nas mensagens de serviço e a defi nição das próprias mensagens melhoram muito o aspecto da qualidade dos dados de qualquer solução, devido à capacidade de testar automaticamente as mensagens para ver se há conformidade com o esquema ou o contrato de mensagens suportados por um serviço.

Vamos dar uma olhada no exemplo de estrutura SoBI. É importante que a estrutura SoBI defi na e diferencie claramente os diferentes tipos de dados e os proprietários associados desses dados, o que garante a integridade pois os dados podem ser reparados em apenas um lugar. Também permite que os dados sejam dispostos de acordo com o uso apropriado. A Figura 7 mostra a arquitetura de dados de alto nível para a estrutura SoBI. O objetivo dessa arquitetura é destacar como tipos diferentes de dados serão tratados na solução.

Figura 11 - Visualizações das informações

Como você pode ver, os sistemas de registro são integrados no armazém de dados por meio de métodos ETL tradicionais, com a exceção de que os serviços de transformação normalmente contidos no processo ETL são exibidos para reutilização por parte dos serviços tradicionais. Essa reutilização permite que as informações sejam integradas no armazém de dados e expostas por meio de fachadas de serviços em um esquema comum à medida que os serviços de transformação são compartilhados por ambos os mecanismos.

Também se reconhece que nem todas as informações no armazém de dados podem ser expostas por meio da interface de serviço e que ainda pode haver uma pequena população de usuários na organização que vão precisar de acesso direto ao armazém de dados para realizar uma análise complexa e ad hoc. Vamos dar uma olhada em mais detalhes nos fatores que infl uenciam a implementação bem-sucedida da estrutura SoBI. Num alto nível, a orientação arquitetural para a aplicação das peças integrantes da SoBI pode ser resumida como mostrado na Tabela 2. Entre os fatores de sucesso para o projeto SoBI estão:

• Governança. É pouco provável que um projeto SoBI seja bemsucedido sem um processo associado de gerenciamento de mudança organizacional no lugar para lhe fornecer respaldo.

• Dados empresariais e estratégia de SOA. A SoBI baseia-se na existência de um plano estratégico para os aplicativos de SO na organização e no reconhecimento da importância do sistema de armazenamento dos dados de registro em armazenamentos ou aplicativos de nível empresarial. Por exemplo, a organização não armazena as principais informações comerciais nas planilhas.

• Relatórios operacionais versus administrativos. Deve-se fazer uma clara delineação entre os tipos operacionais e administrativos de relatórios que serão necessários na estrutura SoBI. A SoBI BI será a versão única da verdade para os relatórios administrativos. Terá o alcance sufi ciente para atender às exigências específi cas da empresa em termos de inteligência comercial. O armazém de dados de suporte conterá apenas os dados necessários para suportar essas exigências.

• Propriedade dos dados. Embora o armazém de dados contenha os dados coletados de múltiplas fontes e sistemas de dados, de uma perspectiva orientada ao serviço, o armazém de dados não deve ser considerado a versão principal ou o armazenamento-padrão de todas as exigências de dados. O proprietário desses dados permanece sendo o sistema de registro.

Fatores de sucesso

Vamos dar uma olhada nesses fatores de sucesso em mais detalhes. A governança é um fator de sucesso fundamental no desenvolvimento de uma solução orientada ao serviço bem-sucedida. É importante que uma organização possa controlar e anunciar os serviços, os formatos de mensagens e as estruturas que são suportados para impedir uma proliferação não controlada dos serviços, das mensagens e das defi nições de entidades no ambiente. Isso está intimamente ligado às atividades de definição de esquema e exige um gerenciamento ativo por parte de um corpo de governança para garantir que o sistema adere aos princípios orientados ao serviço.

A chave é encontrar um equilíbrio no nível da governança e ter controle sufi ciente para fornecer uma estrutura para o desenvolvimento e a implantação bem-sucedidos dos serviços, mas não ao ponto de debilitar a capacidade do sistema de responder, de forma ágil, às necessidades da empresa.

Em qualquer projeto de BI, a falta de clareza na função do armazém de dados e no escopo dos dados neles contidos pode levar a problemas. Em um exercício de projeto duradouro, se o escopo do armazém de dados não for gerenciado, o exercício de projeto cresce à medida que são descobertas fontes de dados em potencial, e os dados nessas fontes precisam ser consolidados no modelo de armazém de dados.

O modelo de armazém de dados precisa ser projetado para garantir a capacidade de expansão, a fi m de garantir que os dados de ativos diferentes podem ser adicionados à medida que se possa fazer um caso de negócio para os dados. Não é algo prático partir do princípio de que os dados de todos os aplicativos no cenário organizacional possam ser incluídos no projeto do primeiro modelo de dados. É mais provável que uma abordagem incremental do projeto e do desenvolvimento do armazém seja mais bem-sucedida.

Para a estratégia dos dados e da SOA empresarial, a aplicação bem-sucedida da SoBI baseia-se na existência de um plano estratégico organizacional para os aplicativos de SO e para o sistema dos dados de registro a serem mantidos nos armazenamentos ou nos aplicativos empresariais. Quando os sistemas e os dados não conseguem suportar a integração direta na SOA proposta pela estrutura SoBI, parte-se do pressuposto de que o plano eventual da empresa é migrar esses sistemas e fontes de dados para uma plataforma que suportaria esse nível de integração. Entre os exemplos dos tipos de sistemas mencionados nessa pressuposição estão os sistemas que são mais carregados e não podem lidar com o fardo extra de expor os serviços e sistemas que não suportam pesquisas online e se baseiam em exportações periódicas em lotes.

Algumas das informações essenciais ao negócio são mantidas em armazenamentos ou aplicativos que não são apropriados aos dados do valor desse negócio – por exemplo, as planilhas do Microsoft Excel que guardam versões principais dos dados tornando a planilha o sistema de registro. Deve haver uma direção estratégica que leve ao ponto no qual os dados são mantidos em um armazenamento ou aplicativo que tenham força em toda a empresa, e para os documentos se tornarem visualizações desses dados, e não as fontes principais. O objetivo é transformar os documentos enquanto sistemas de registro em documentos enquanto visualizações dos dados mantidos nos sistemas de registro.

Manter a integridade

Deve-se fazer uma clara delineação entre os tipos operacionais e administrativos de relatórios que serão necessários na estrutura SoBI. A visão tradicional do armazém de dados como fonte única de todas as necessidades de informações corporativas não se mantém na estrutura SoBI. O objetivo da estrutura SoBI é apoiar o que há de mais importante na BI como “a versão única da verdade”, mas também manter a integridade dos sistemas de registro como proprietários dos dados corporativos.

É provável que um relatório operacional atenda a um destes critérios: exigir acesso ao vivo aos dados; ser necessário para o gerenciamento operacional da empresa (por exemplo, as informações numa transação individual); não precisar de dados históricos para comparações; e não precisar de dados resumidos (dados agregados, exceto para o total básico). Em geral, defi ne-se um relatório administrativo como algo que:

• Exige um acesso não imediato aos dados, mas na hora certa, e em geral exige que os dados resumidos sejam apresentados em um cronograma histórico predeterminado (por exemplo, comparações métricas mês a mês por ativo)

• Apresenta ao usuário a capacidade de explorar os dados apresentados de acordo com a sua vontade, para pesquisar rapidamente os problemas em potencial de desempenho (por exemplo, aumentar o detalhamento dos dados). O relatório pode destacar as áreas de falha com base na formatação condicional.

• É defi nido apenas para avisar o usuário quando ocorrer um problema (relatório de exceção).

• Auxilia na previsão do desempenho comercial.

• Ajuda nas metas subjacentes da pessoa e da empresa (por exemplo, a efi ciência de produção, a sobrevenda e a maximização do lucro do produto).

Embora o armazém de dados contenha os dados coletados de múltiplas fontes e sistemas de dados, de uma perspectiva orientada ao serviço, o armazém de dados não deve ser considerado a versão principal. O proprietário desses dados permanece sendo o sistema de registro.

A SO discrimina claramente entre dois tipos diferentes de dados, a saber, os dados que são mantidos no serviço e os dados que o serviço expõe aos aplicativos ou a outros serviços. Os dados internos são aqueles que o serviço utiliza para realizar as operações que ele fornece. Essas informações são inteiramente privadas ao serviço, nunca sendo expostas diretamente. Os dados externos são aqueles publicados pelo serviço e usados para trocar informações e solicitações com os clientes do serviço. Esses dados são defi nidos explicitamente em termos de um esquema organizacional.

O aplicativo que é proprietário dos dados (também conhecido como sistema de registro) é responsável, no fi m, por manter seus próprios dados; portanto, para permitir que outros aplicativos solicitem mudanças nos dados, o aplicativo proprietário precisa expor a funcionalidade de atualização de solicitação por meio de sua interface de serviço. (Consulte Recursos para obter mais informações sobre esses dois tipos de dados.)

Ao trabalhar com a integração de dados, a SoBI será fl exível o suficiente para trabalhar com esses cenários de integração principais.

• Volumes de dados, que são transações exclusivas ad hoc ou cargas de dados em massa de grande volume.

• Integração com aplicativos empacotados e esquemas de bancos de dados “proprietários” de terceiros.

• Consolidação do banco de dados.

• Integração de fontes de dados relacionais, não relacionais, estruturadas e semi-estruturadas e de sistemas legados.

• Suporte a serviços da Web e integração com middleware de troca de mensagens.

Ao trabalhar com a BI, a SoBI visará a satisfazer várias exigências. As empresas precisam coletar e agregar informações de fontes diferentes dentro da organização e conseguir compartilhar essas informações de uma maneira aberta, com um estado diverso de aplicativos em partes diferentes da organização, sem primeiro conhecer em detalhes como as informações serão utilizadas. As empresas também precisam isolar os usuários do formato e da estrutura subjacentes dos dados, em vez de se focar no signifi cado dos dados de negócio dentro da organização. Os consumidores das informações estão preocupados principalmente com a semântica dos dados, e não com a sintaxe deles. Partes diferentes da empresa precisam conseguir compartilhar uma linguagem comum quando descrevem a si próprias, e as empresas precisam publicar os dados de forma mais ampla dentro da organização, diferenciando a publicação dos dados e os dados para análise.

A publicação de informações definidas, tais como KPIs, ou métricas por meio de mecanismos abertos como os serviços da Web, permite que essas informações sejam consumidas facilmente na organização, sem o recurso dos aplicativos especializados. A publicação de dados para análise ainda será uma parte principal dos serviços prestados pelo armazém de dados, mas isso tende a se focar em um público mais limitado na organização, com o acesso aos aplicativos especializados necessários para a análise dos dados. Uma das metas da SoBI é permitir a ampla divulgação das informações a um público mais amplo de usuários, aplicativos e outros serviços na organização.

Padrões de integração da SoBI

Outro objetivo da estrutura SoBI é ter uma abordagem pragmática do trabalho com sistemas que não podem ser integrados diretamente na arquitetura – por exemplo, os que não podem suportar carga extra ou aqueles que não são dimensionáveis o sufi ciente para suportar a integração direta.

Tendo isso em mente, a estrutura defi ne um conjunto de cenários (ou padrões) que descrevem categorias de sistemas de fonte típicos que os autores encontraram, junto com um esboço recomendado para integrar cada categoria do sistema. Prevê-se que essa coleção de padrões de integração evoluirá e se desenvolverá à medida que sistemas mais diversos são integrados em uma solução SoBI. Esses padrões ajudam a resolver uma das principais prioridades orientadas a serviço, qual seja, a capacidade de conseguir suportar a substituição de aplicativos com impacto mínimo na empresa. A estrutura SoBI descreve como esses sistemas podem ser abstraídos de uma forma que garanta que haja uma interrupção mínima quando os sistemas são fi nalmente substituídos.

Figura 12 - Abordagem não adequada à interface do serviço

Figura 13 - Substituição da implementação de BI

Até agora conseguimos estruturar a SoBI em termos de um cenário mundial ideal no qual os vários sistemas de registro podem participar da arquitetura SoBI de uma maneira orientada ao serviço. Em um ambiente de projeto real, é provável que haja uma série de restrições que infl uenciam a nossa capacidade de implementar a SoBI pura. Identifi camos várias categorias de restrições, que serão discutidas brevemente, e como exemplos em cada caso identifi camos um padrão, que, ao ser utilizado em conjunto com o princípio da SoBI na SOA empresarial e na estratégia de dados, garante que a implementação pragmática da SoBI permanece dentro dos princípios orientadores da estrutura SoBI.

SoBI pura

Uma situação ideal é aquela em que o aplicativo é dimensionável e fl exível o sufi ciente para suportar a exposição dos serviços e eventos ao barramento de serviço, ou diretamente ou por meio de uma fi na fachada de serviço (consulte a Figura 8). Essa categoria de aplicativo também é capaz de suportar a exportação dos dados para o armazém de dados, conforme necessário.

Uma das restrições no tipo do sistema de fonte é o processamento transacional/em tempo real. Alguns aplicativos conterão as informações que são interessantes da perspectiva da análise e de uma perspectiva em tempo real. Tais aplicativos podem ser habilitados para o serviço criando-se uma fachada de serviço que expõe os serviços do aplicativo à organização, e que dispara eventos quando são realizadas mudanças ou atualizações “interessantes”. Nesse cenário, os aplicativos que estão interessados nos eventos desse aplicativo podem se subscrever para os eventos publicados. Os assinantes incluirão um agente do armazém de dados que ordena os eventos para a integração com o armazém de dados (consulte a Figura 9).

Os sistemas não estruturados e semi-estruturados são outra restrição. Em qualquer ambiente complexo, provavelmente haverá uma série de fontes de dados que contêm informações que devem ser consumidas pela solução, mas que são mantidas em formatos semiestruturados ou não estruturados, tais como sistemas de gerenciamento de planilhas e documentos. Com esses tipos de sistemas, é importante estruturar as informações antes da integração no armazém de dados, e será possível fazer isso em uma de várias formas. Uma delas é aplicar a estrutura ao armazenamento de dados. Por exemplo, a provisão de modelos estruturados e controlados por mudanças para as planilhas e documentos, de tal forma que as informações possam ser extraídas com precisão e confi abilidade do documento, envolverá a mudança do processo comercial. Outra forma é impor a estrutura na leitura dos dados realizada no armazenamento, que é algo inerentemente difícil na medida em que se baseia em pressuposições sobre a semântica da estrutura existente da fonte de dados e na confi ança de que isso nunca muda. Se essa pressuposição se mantiver, é possível realizar uma extração pragmática.

Estamos partindo do pressuposto de que as fontes de dados não empresariais serão por fi m atualizadas para suportar mais diretamente os serviços que elas fornecem (consulte a Figura 10). É importante mudar os documentos das fontes de informações para visualizações das informações (consulte a Figura 11).

Agora vamos dar uma olhada nas restrições de limitação do sistema de fontes. Para os sistemas muito carregados, haverá ocasiões em que há fontes de dados ou sistemas que contêm dados que não podem ser interrogados em tempo real devido a restrições tecnológicas ou operacionais. Considere estes exemplos: um sistema muito utilizado talvez não consiga suportar o acréscimo de uma interface de serviço que processa um novo grupo de pesquisas em uma base freqüente; uma fonte de informações que não suporta o acesso simultâneo, como os dados mantidos em uma planilha; e o acesso ad hoc ou em tempo real aos dados em um sistema de produção é considerado um risco para a execução diária efi caz do sistema essencial à empresa.

Nesses cenários, a solução tática é fazer cache dos dados em um sistema que pode então fornecer uma interface defi nida e publicada para os dados ou serviços. Esse cache permite que os aplicativos e serviços tenham acesso às informações mais atualizadas possíveis por meio de um serviço exposto. Essa abordagem fornece uma maneira de dimensionar uma fonte de dados ou aplicativo para atender às exigências do negócio de uma forma que garante um claro desligamento dos dados ou do aplicativo e do serviço prestado. Esse desligamento é importante para o desenvolvimento futuro, quando o aplicativo ou os dados podem ser transferidos para uma solução mais dimensionável e prestar o serviço diretamente, ou quando o aplicativo pode ser aprimorado para suportar o serviço diretamente.

Uma advertência que se pode fazer aqui é que haverá ocasiões em que o tipo de dado que é necessário pelo sistema é puramente de natureza da inteligência comercial, tais como a exportação de dados de larga escala. Nesses cenários, a abordagem da interface de serviço não será adequada (consulte a Figura 12).

Estamos partindo do pressuposto de que os sistemas muito carregados serão por fi m atualizados para suportar mais diretamente os serviços que eles fornecem.

Baixa expectativa de vida

Um dos princípios da SoBI é que a organização deve colocar em vigor um plano estratégico para os aplicativos orientados ao serviço e para o sistema de dados de registro a ser mantido nos armazenamentos ou aplicativos da empresa. Esse plano signifi cará inevitavelmente a substituição de alguns sistemas de registro no atual cenário, e em alguns casos é bem provável que sejam substituídos após a implementação do projeto de BI. Portanto, é fundamental que seja defi nida uma abordagem que possa suportar esses sistemas nos anos fi nais de suas vidas e facilitar o processo de substituição quando o próximo sistema ganhar vida (consulte a Figura 13). Essa abordagem vai precisar produzir uma arquitetura que garanta o equilíbrio entre uma transição fácil para a nova fonte de dados e o compromisso de empenhar a equipe do projeto em um grande esforço de desenvolvimento que no fi nal será jogado fora.

Sobre os autores

Sean Gordon é arquiteto de estratégia de sistemas empresariais e de prática de consultoria em arquitetura da Microsoft e trabalha no escritório da empresa na Escócia.

Robert Grigg é consultor administrativo e arquiteto empresarial em Conchango, no Reino Unido.

Michael Horne é consultor administrativo e arquiteto de inteligência de negócio em Conchango, Reino Unido.

Simon Thurman é arquiteto no grupo de desenvolvimento da Microsoft Developer Network, Reino Unido.