Skip to Content

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:
        • 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.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply