Introdução ao HDMS (SAP HANA Data Management Suite)

Quando adolescente, eu me apaixonei por jogos de interpretação de papéis comumente conhecidos como RPG (no inglês Role-playing Game). Para quem nunca jogou, o jogo consiste basicamente em um grupo de pessoas que se reúne para jogar uma aventura, cada pessoa interpreta um personagem e um dos integrantes conta a história, no jargão dos jogadores “mestra” a partida; para dar sabor, os dados definem uma dimensão de imprevisibilidade à brincadeira. 

Com o passar do tempo, os jogos se tornaram menos frequentes, mas contar histórias continuou parte da minha realidade. Seja para apresentar soluções para parceiros e clientes, seja para divertir meus filhos. Em alguns casos, um pouco de ambos.

Na semana passada, enquanto eu pensava em como tornar a mensagem do SAP HANA Data Management Suite (HDMS) mais simples, passei os olhos sobre a famosa história dos três porquinhos e num click, tudo fez sentido.

Era uma vez, um mercado globalizado, cheio de desafios, oportunidades e no meio de uma grande transformação digital. Gigantes consolidados no mercado enfrentavam problemas, startups se tornavam as novas gigantes (Uber, Airbnb, Alibaba e etc.) e empresas digitais, começavam a realmente mostrar a dimensão do que poderiam fazer (como a projeção de que a Amazon terá 50% do mercado eletrônico nos Estados Unidos até o fim de 2018).

Para sobreviver nesse mercado, 3 arquitetos de solução, tomaram caminhos diferentes:

• O primeiro arquiteto era conservador
  • Ele tinha uma vida controlada
    • Ele avaliou que todo o investimento feito em Data Warehouse até hoje deveria ser preservado. O sucesso foi conseguido com anos de trabalho, criando uma visão única da verdade, uma arquitetura robusta e bem estabelecida.
    • Por anos, ele estruturou um Enterprise Data Warehouse (EDW) com ferramentas consistentes de Extraction, Transformation and Load (ETL); uma fonte única da verdade centralizada e monolítica.
    • Para garantir governança, ele conta com um centro de excelência, processos harmonizados, cada indicador relevante tem um dono, cada indicador tem documentação de cálculo e cada novo requerimento tem que ser aprovado por um conselho.
    • Os dados do ERP, CRM, Pontos de Vendas e demais dados estruturados e transacionais já fazem parte do EDW.
    • Em alguns casos, demandas especificas de real-time podiam ser endereçadas.
  • Os desafios do mercado se mostraram ferozes
    • Armazenar dados não estruturados: voz, vídeo, imagens e etc.
    • Armazenar dados de sensores
    • Armazenar dados semiestruturados
    • Usar os dados do EDW para aplicações analíticas avançadas, como por exemplo, Machine Learning, Análise Preditiva e etc.
    • Construir aplicações que usem os dados do EDW e forneçam insights em operações transacionais
    • Construir robôs que tomem decisões no mundo real a partir dos dados armazenados
  • O segundo arquiteto era um visionário
    • Ele tinha uma vida excitante
      • Animado com os novos players de mercado, participante ativo de eventos de inovação, early adopter, adepto de metodologias ágeis e advogado ferrenho de iniciar cada projeto com soluções open source e baseados em MVP (Minimum Viable Product).
      • A arquitetura baseada em Lambda era flexível e ágil para desenvolver.
      • Com a distribuição de Hadoop e Kafka, era possível fazer a ingestão de dados de sensores e integrar cenários complexos de IoT
      • Usar soluções open source para desenvolver aplicações especialistas
    • E também para ele, os desafios de mercado se mostraram ferozes
      • Para incorporar dados dos sistemas transacionais clássicos, não existem aceleradores
      • Para trazer dados estruturados não há, de forma padrão, forma de armazenar dados normatizados
      • Para harmonizar os dados mestres, ferramentas adicionais precisam ser incorporadas na arquitetura
      • Passando do momento de pilotos e MVPs, transformar a solução em produtiva tem se mostrado mais complexo do que o planejado
      • Uma vez escolhida uma plataforma ou distribuição, mudar de plataforma exige retrabalho
    • O terceiro arquiteto era pragmático. Ele sabia que deveria basear sua arquitetura futura nos desafios atuais e principais tendências:
      • Robusto – para endereçar o crescente volume de dados, estruturados e não estruturados (voz, vídeo, imagens e etc.)
      • Escalável – o futuro ainda está por vir e com ele, novos desafios e requerimentos. É fundamental que a arquitetura possa endereçar esses novos requerimentos.
      • Aberto – com o ritmo atual de inovação, novas empresas, produtos e possibilidades surgem todos os dias. É importante que a arquitetura esteja pronta para se integrar e usar essas novas possibilidades.
      • Preserva o investimento – reinventar a roda não é algo que está nos planos, além de reutilizar o que já existe é preciso buscar aceleradores para entregar mais com menos.
      • Híbrido – cloud / on premise – a realidade se impõe sobre a teoria. Pelo futuro próximo algumas soluções seguirão on premise. É importante conseguir trabalhar cloud e on premise de forma transparente.
      • Evitar ser refém de um provedor – se garantir a própria performance e evolução é difícil, imagina garantir a consistência e evolução de um provedor. Poder mover a solução para outro provedor quando for preciso é mandatório.
      • Ele decidiu compreender a visão de mercado antes de se mover:
        • Segundo a IDC, uma plataforma consistente de gestão de dados é fundamental para a transformação digital
        • O Gartner também tem materiais interessantes nesse sentido
          • Use a Data Hub Strategy to Meet Your Data and Analytics Governance and Sharing Requirements
          • Implementing the Data Hub: Architecture and Technology Choices
        • A HBR também se debruçou sobre o tema, para discutir características necessárias em uma estratégia de gestão de dados
        • Para finalizar, a SAP – que é o padrão de fato para os sistemas de back-end – também se manifestou a respeito.
      • Com base nos requisitos, estudos e opiniões de especialistas, o arquiteto desenhou sua arquitetura de referência

Essa arquitetura endereça:

• A arquitetura atende requisitos suportados por arquiteturas de mercado como Lambda ou Kappa de forma ágil e flexível
• Suportar ferramentas especialistas de parceiros como OsiSoft ou Kafka, para fazer ingestão de dados de IoT
• Usar soluções open source para desenvolver aplicações especialistas
• Todo o investimento feito em Data Warehouse até hoje será preservado. O sucesso conseguido com anos de trabalho, criando uma visão única da verdade, uma arquitetura robusta e bem estabelecida.
• Ampliar as capacidades do EDW para transformá-lo em um Logical Data Warehouse (LDW). E com o LDW, possibilitar a análise dos dados do Big Data com os contextos de negócio do EDW.
• Real-time sempre que requerido pelo caso de uso sendo endereçado

• Garantir governança e adequação às regulamentações internacionais, como por exemplo, GDPR.

CONCLUSÃO

O arquiteto de solução pragmático, que tomou o tempo para entender o mercado de forma holística e não vinculado a apenas um provedor de soluções ou mesmo à promessa de investimento zero, foi o que conseguiu entregar mais capacidades aos seus clientes internos, baseado em uma arquitetura robusta, escalável, aberta e ágil – como pode ser visto no desenho abaixo:

PS: gostaria de agradecer ao Igor Jakuboski  – Enterprise Architect na SAP – pelo desenho de arquitetura referência.