Dashboards e a performance ideal

Read this post in English HERE

Hoje um colega de projeto me fez uma pergunta que

gostaria de compartilhar com os amigos leitores do blog:

Como avaliar se o tempo de resposta de um dashboard é aceitável?

Uma das entregas do projeto, um dashboard com indicadores de custos de produção para uma empresa de mineração, demorava mais de um minuto na sua primeira execução.

A resposta às vezes me parece tão simples quanto óbvia: quando você acessa um portal de notícias, em quanto tempo espera ter todas as informações na tela? Mesmo que o portal seja o mais completo disponível, com todas as notícias do momento, se a cada vez que você acessar a informação precisar aguardar mais de um minuto para ter a notícia, provavelmente vai procurar outro portal.

É claro que esta analogia não abrange todos os aspectos de um cenário com um dashboard corporativo, porque podem estar envolvidos assuntos como infraestrutura, relevância da informação na companhia, volumetria, viabilidade de se ter acesso por outro canal e assim por diante. Isso todos nós, técnicos, sabemos e muito bem. Mas nem sempre o usuário, aquele executivo que passa por umas 5 reuniões no mesmo dia e geralmente consegue parar por 15 minutos pra dar atenção à tecnologia, sabe ou concorda com isso. Já presenciei algumas discussões (leia-se “brigas”) entre sponsors e gerentes de projeto sobre este assunto, cada um com a sua razão. O lado técnico mostra que aquela informação anteriormente tomava 2 dias de esforço de uma equipe pra ser obtida e o sponsor argumenta que durante a pré-venda, com apenas um click, a informação era apresentada instantaneamente.

Na minha humilde opinião, um minuto pra se obter uma informação pode ser excelente, mas desde que seja em um relatório, que pode ser executado em background enquanto o usuário executa suas outras tarefas. Neste caso, é comum encontrarmos relatórios não de um minuto, mas de até mesmo horas de execução.

Mas quando falamos em dashboards, seja ele acessado por um PC ou via mobile, geralmente o usuário aguarda a resposta a cada click, e um minuto parado, apresentando a informação em uma reunião ou somente buscando respostas de negócio, muitas vezes é o argumento necessário para se inutilizar aquele dashboard que nos tomou dias de desenvolvimento.

Existem técnicas para se melhorar a performance de um dashboard; agendar uma execução prévia dos dados costuma ser uma delas, embora muitas vezes isso limite o escopo da informação disponibilizada. Desenvolver uma estrutura de dados específica para cada dashboard durante a fase de ETL também é uma opção bastante escolhida, embora muitas vezes inviabilizada por questões como custo e governança. A aplicação de tecnologia in-memory é geralmente a melhor das opções, quando realmente é uma opção.

Em resumo, se percebemos que a informação solicitada para um dashboard não vai atender os requisitos mínimos de navegabilidade para este tipo de front-end, o ideal é sugerirmos ao cliente um relatório ou outra solução de front-end. Definitivamente, um dashboard completo, na minha opinião, não é um dashboard cheio de informações e gráficos incríveis, mas um dashboard que dê a resposta para o usuário antes que ele comece a pensar em outro tipo de pergunta, como por exemplo, será que eu não encontro essa informação em outro lugar?

Sobre o exemplo citado acima, já que não estava prevista ainda para esta fase do projeto a utilização da tecnologia in-memory, precisamos buscar outras soluções. Com uma série de otimizações de queries e melhor sincronização nas execuções das mesmas, aplicações de novas lógicas e ajustes pontuais na navegação, conseguimos reduzir o tempo de execução do dashboard para cerca de 12 segundos na primeira execução e de 4 segundos, em média, para resposta a cada click durante a navegação. O tempo foi considerado justo tanto pelo lado técnico como pelo lado funcional, em vista da qualidade da informação apresentada, mas é possível que para alguns amigos leitores do blog, este ainda não seja um tempo de resposta ideal. Considero aceitável, embora acredite que este ainda seja o limite a ser sugerido em casos mais extremos quando se desenvolve um dashboard sem a utilização da tecnologia in-memory.

Um abraço,

-----------

Igor Alexandre Jakuboski é profissional de Business Intelligence há mais de 7 anos, tendo já atuado em dois dos principais fornecedores de soluções de BI do mercado e liderado projetos no Brasil e no exterior. Atualmente atua como Principal Solution Architect na SAP. Perfil no LinkedIn: br.linkedin.com/pub/igor-jakuboski/41/28b/88a

Dashboards and the ideal performance

Para ler este post em português clique AQUI

Today a project colleague asked me something that I'd like to share with our friends readers of this blog:

How to evaluate if a dashboard response time is acceptable?

One of the project deliverable, a dashboard with production costs indicators for a mining company, was taking more than a minute in its first execution.

The answer sometimes seems so simple as obvious: when you access a news portal, how soon you expect to see all information on the screen? Even if the portal is the most complete one available with all news of that moment, if every time you access the information you have to wait more than a minute to see the news, you   will probably look for another portal.

It is clear that this analogy does not cover all aspects of a scenario with an enterprise dashboard because it may involve issues such as infrastructure, relevance of information on the company, volumetry, feasibility of having access by another channel and so on. That, all of us technicians, know and know very well. But not always the user, that executive which goes through 5 meetings in the same day and usually can stop only for 15 minutes to pay attention to technology, knows or agrees with this. I've seen some discussions (read "fights") between sponsors and project managers on this subject, each with its reason. The technical side shows that the information previously took two days of a team effort to be obtained and the sponsor argues that during the pre-sale, with just one click, the information was presented instantly.

In my humble opinion, a minute to get some information may be excellent, but provided it is in a report that can run in the background while the user performs its other tasks. In this case, it is common to find reports of not only a minute but hours of execution.

But when we talk about dashboards, whether accessed from a PC or via mobile, the user usually waits for the response to each click, and a minute stopped displaying the information in a meeting or just seeking business answers is often the argument necessary to disable that dashboard that took us one day to develop.

There are techniques to improve the performance of a dashboard; schedule a previous execution of the data is usually one of them, although it often limits the scope of the information provided. Develop a specific data structure for each dashboard during the ETL phase is also a common chosen option, though often frustrated by issues such as cost and governance. The application of in-memory technology is usually the best option, when it is really an option.

In summary, if we realize that the requested information to a dashboard will not meet the minimum requirements of navigability for this kind of front-end, ideally we suggest the customer a report or another front-end solution. Definitely a complete dashboard, in my opinion, is not a dashboard full of information and amazing graphics, but a dashboard that gives the answer to the user before he starts thinking about another kind of question, for example, wouldn't I find this information anywhere else?

About the example mentioned above, since it was not yet planned for this phase of the project the use of in-memory technology, we must seek other solutions. With a series of queries optimizations and better synchronization of them, we were able to reduce the dashboard execution time to around 12 seconds in his first execution and of four seconds, in average, for the response to each click during navigation. The time was considered fair by both technical and functional side, given the quality of the information provided, but it is possible that for some friends readers of the blog this still is not an optimal response time. I consider acceptable, although I believe that this is still the limit to be suggested in the most extreme cases when developing a dashboard without the use of in-memory technology.

Regards,
--------------
Igor Alexandre Jakuboski is a professional of Business Intelligence for over 7 years, having already worked on two of the leading providers of BI solutions in the market and led projects in Brazil and abroad. He currently works as Principal Solution Architect at SAP. LinkedIn profile: 

br.linkedin.com/pub/igor-jakuboski/41/28b/88a

BI in memory sem servidor?

Não, a SAP não anunciou que o HANA vai rodar em iPads sem servidor, não foi isso! A SAP Brasil anunciou uma parceria com a Ativas para que o appliance do SAP HANA rode no DataCenter da Ativas. A notícia saiu no TI INSIDE e você pode ler na íntegra aqui.

Os céticos pensarão: e daí? Acho que a grande novidade neste caso não é exatamente tecnológica, é cultural. Eu sou de uma época em que:

• os profissionais de TI das empresas se orgulhavam de possuir verdadeiras raridades no CPD - Centro de Processamento de Dados (antigo nome do Data Center)
• os administradores dos sistemas operacionais administravam TUDO: cada file system, cada backup, cada TUDO;
• os administradores de banco de dados eram os DONOS de todos os dados dentro do banco. Ninguém criava um índice que fosse sem o "amém" do DBA.

E o que o PRESENTE (não o futuro) nos reserva? O SAP HANA é um appliance, ou seja, uma caixa preta. Você "pluga" ela no seu ambiente, configura quais modelos devem ser considerados e a "caixa" decide COMO armazenar, como otimizar etc. Resultado: a administração não é mais responsabilidade do adminitrador, o DBA não existe como entendiamos há 15 anos e agora a última barreira caiu: a caixa preta talvez seja azul e você nunca vai saber.

Bem-vindo a esse "Brave New World".

Grande abraço,

Novos tempos: novos problemas e novas soluções

Se você não for um extraterrestre, já ouviu falar nas transformações sociais e nos negócios trazidos pela WEB 2.0, as mídias sociais (twitter, facebook, orkut, myspace etc.) e a computação em nuvem. Se você trabalha com BI, adicione a esse caldeirão o processamento In-Memory e você tem buss words para usar nas próximas reuniões até o fim do semestre.

A pergunta que é pouco respondida até agora é: como todas essas ferramentas podem nos ajudar no nosso dia-a-dia de BI? Bom, vamos por partes:

Sobre In-Memory, você pode encontrar mais informações aqui no BRIntelligence mesmo, no artigo: In memory, em memória e o futuro do Business Intelligence - BI e tambén no artigo falando sobre HANA A nova solução para seus problemas: HANA (?);

Sobre as demais mídias: twitter, facebook, orkut, myspace, youtube etc. ainda não falamos. Sinceramente eu não tenho muitas respostas e não vi nenhum caso onde essas mídias estejam sendo usadas integradas às soluções de BI cooporativas. Mas eu tenho uma idéia, um sonho talvez de como uma ferramenta como o Twitter pode ser um divisor de águas também no mundo de BI. Como?

Durante anos, áreas comerciais e de marketing vêm se perguntando como medir o impacto de uma campanha de marketing em termos númericos mas não financeiros. Perguntas como: as pessoas gostaram da campanha? A campanha atingiu o público alvo? quantas pessoas foram atingidas pela campanha?

Enquanto essas campanhas não paravam de sair, especialistas de diversas áreas uniram esforços para responder essas perguntas com pesquisas, amostragens, extrapolações estatísticas etc. HOJE a realidade pode ser diferente. As campanhas de marketing podem ser medidas em termos númericos baseados em comentários em mídias sociais que podem ser interpretadas por tecnologias como o Many Eyes da IBM (http://www-958.ibm.com/software/data/cognos/manyeyes/) e então segmentadas em: categoria de usuários, menções favoráveis, menções contrárias, sugestões etc.

Pela primeira vez na história, temos a chance de medir o impacto externo de ações inciadas dentro das empresas. Não, isso não é simples e nem fácil por diversos motivos:

1. a tecnologia ainda não ajuda, são necessárias várias ferramentas e interfaces para se atingir esse resultado
2. as informações em si não são padronizadas e nem estruturadas
3. o acesso a essas informações não está padronizado ou estruturado

Mesmo quando essas primeiras barreiras forem vencidas, ainda assim precisaremos de mão-de-obra qualificada e capaz de lidar com essa nova realidade e organizações dispostas a começar a trilhar esse caminho.

Não estou dizendo que será fácil ou para amanhã. Mas na minha opinião, certamente será para a próxima semana.

Grande abraço,

A nova solução para seus problemas: HANA (?)

Se você é profissional SAP e não vive em um aquário, você muito provavelmente escutou falar de HANA. HANA significa: High Performance Analytical Appliance (em tradução livre: uma aplicação analítica de alta performance). Mais informações oficiais podem ser encontradas no site oficial, aqui.

O primeiro anúncio sobre HANA foi feito no SAPPHIRE 2010 (chegamos até a mencionar isso no artigo: In memory, em memória e o futuro do Business Intelligence - BI). E o anúncio foi feito pelo alto escalão da SAP, vale a pena dar uma olhada nos vídeos abaixo:

Vishal falando sobre o assunto

Hasso falando sobre o assunto:

A SAP fez até um vídeo muito bacana usado no último SAPFORUM tentando explicar as capacidades do SAP HANA 1.0:

Mas de fato, o que é HANA? Em resumo, SAP HANA é o primeiro produto que utiliza uma série de técnicas e inovações tecnológicas para suportar a tomada de decisões em tempo real. Entre os pontos que valem a pena destacar:

• In-Memory - não é exclusividade da SAP, essa tendência veio pra ficar. Com o barateamento da memória ficou evidente que em um futuro próximo, disco rígido será peça de museu. Isso pode ser visto em outros lugares. Laptops estão usando cada vez mais discos SSD (solid state disk), os iPhones também não usam mais memória e vários provedores de BI também estão adotando esse modelo (para citar um, QlikView por exemplo).
• Armazenamento colunar - lembra que você aprendeu que cada registro é uma linha no banco de dados? No caso do HANA isso não é verdade. Cada registro é uma coluna. Por que? Grosso modo, quando um comando SQL de sumarização é executado no banco de dados, mesmo querendo o total de uma coluna, o banco tem que ler todas as linhas. Com o armazenamento colunar, é preciso ler apenas 1 linha. A linha que contêm toda a informação que deve ser sumarizada. Eu vou escrever outro artigo sobre armazenamento colunar no futuro e posto o link aqui.
• Real Real-time - consulta em tempo real de verdade. Quem conhece as práticas de mercado de DW e BI sabe que, em geral, as informações são transferidas para o DW em processos de carga. Essas cargas podem ser diárias, semanais ou mesmo mensais dependendo da necessidade de negócio. A promessa da SAP é utilizar uma tecnologia adquirida com a aquisição da SYBASE para que todo registro feito no sistema transacional esteja disponibilizado milisegundos depois no HANA.

Mas na minha opinião, o lançamento do produto HANA em si não é a melhor notícia. A melhor notícia é a existência e aplicação PRÁTICA dessas inovações tecnológicas que fazem parte do HANA. A menssagem da SAP é clara, este é apenas o primeiro produto. Tanto é que o HANA 1.5 já está no forno. Eu acho que além de uma campanha de marketing bem feita, o discurso de que uma nova geração de softwares (equivalente a criação do famoso R/3) pode estar prestes a nascer. Vamos ver o que o futuro nos reserva.

Para aqueles que como eu querem escutar um cliente antes de tomar uma decisão, eu encontrei um case da Hilti que vale a pena ser visto (em inglês):

Se você quer uma segunda opinião, isso é o que o Dilbert tem a dizer sobre possibilidades "real-time":

Grande abraço,

In Memory Technology... onde usar?

Algum tempo atrás eu postei um texto sobre In Memory Processing (processamento em memória) que foi bem popular aqui no Blog. Você pode ler o artigo na integra aqui.

Hoje recebi um email com um texto muito bancana sobre utilizações diretas e indiretas dessa tecnologia. Vale a penas ler.

Grande abraço,

In memory, em memória e o futuro do Business Intelligence - BI

In memory ou processamento em memória parece ser a bola da vez. A gigante alemã SAP usou boa parte de suas palestras no SAPPHIRE 2010 discutindo o assunto e todos os outros grandes players do mercado investem no assunto.

No Brasil, o assunto também é discutido e, mais importante, já é realidade: de acordo com a Computer World de julho, a Coca-Cola do Brasil já está usando in memory na sua área financeira. Você pode ver a reportagem completa aqui.

Mas de fato, o que é in memory? Eu vi uma definição muito boa de Ingo Brenckmann no último SAPPHIRE, que pode ser vista aqui. Claro que tem um pouco de propaganda, mas os conceitos estão, em sua maior parte, presentes.

Em poucas palavras: processamento em memória é um conjunto de técnicas, tecnologias e ferramentas que permitem o armazenamento de um grande volume de dados em memória, tornando possível a análise desses dados em tempo real, acompanhando o raciocínio humano, sem ruptura no processo de análise.

Apesar de querer me ater aos benefícios criados para o usuário final e as potencialidades de utilização, não posso deixar de ressaltar os principais impulsionadores dessa tendência:

• a evolução do poder computacional;
• o barateamento dos custos de aquisição de memória;
• a necessidade constante de respostas imediatas para problemas imediatos;
• a crescente complexidade dos cenários analisados, que fazem da análise de cenários e simulações uma ferramenta básica.

Agora que sabemos o que é e o que levou ao processamento em memória, fica a pergunta mais importante: o que podemos fazer com isso?

Na verdade a potencialidade completa ainda não foi explorada, mas existem alguns exemplos que já são realidade em muitas ferramentas de mercado:

• Análise de crédito: imagine que um cliente entra em contato por telefone solicitando a aprovação de um crédito adicional de 10% para compra de mercadoria. Utilizando processamento em memória, o atendente poderia obter informações sobre histórico de pagamento, probabilidade de inadimplência baseada em características do cliente, impacto no orçamento mensal e anual da empresa no caso de se conceder ou não o crédito, além dos impactos no objetivo pessoal e departamental em dois cenários: o cliente ser um bom pagador ou não. O mais impressionante: a resposta é imediata e baseada nas informações do último segundo de transações no ERP, o cliente recebe ou não a liberação do crédito na mesma hora.
• Simulação de cenários de planejamento: com a escassez de recursos que toma conta de várias empresas e departamentos, é muito comum receber solicitações do tipo: por favor, reduza sua previsão de gastos para o próximo ano em 10%. O fato é que mais e mais as empresas amarram seus planejamentos com eventos: sejam eles projetos, eventos de marketing, campanhas etc. Nessa nova realidade, reduzir 10% no orçamento geralmente não é um exercício simples. Com o processamento em memória seria possível criar diversos cenários "on the flight" sem o envolvimento direto de TI levando-se em consideração: cancelar o evento A ou B e seus respectivos impactos, não apenas no novo objetivo orçamentário, mas também na lucratividade da empresa e em todos os demais componentes (gastos, despesas operacionais, vendas, crescimento orgânico etc). E com isso, fornecer informações em tempo real, para defender um BOM orçamento ou ajustá-lo de forma a adequar o planejamento a realidade.

Grande abraço,