Arquitetura de Integração

Algumas boas práticas sobre APIs

~ Marco Mendes ~ 1 comentário

Existe ainda alguma confusão sobre APIs. Muitos gestores acreditam que uma API é um algum termo nerd discutido nos porões do desenvolvimento de software. E muitos desenvolvedores acreditam que uma API é apenas um conjunto de funções expostas a partir da sua IDE para habilitar a integração da sua aplicação com algum front-end.

Outros gestores e desenvolvedores mais atentos já observaram que APIS são ferramentas que podem aumentar suas receitas e reduzir o TCO de seus códigos legados. Um exemplo muito bacana no contexto brasileiro é como market places tem aumento o faturamento de grandes redes varejistas. E já existem também congressos temáticos no Brasil para discutir as possibilidades de negócio como por exemlo o API Experience.

APIs, definitivamente, vieram para ficar. APIs podem potencializar aplicações legadas, abrir novos canais de parcerias de negócio e até mesmo criar novos produtos para as suas áreas de negócio.  E isso é muito bom para que TIs possam prover mais alinhamento e valor de negócio.

Mas como podemos nos locomover no mundo das APIs? Como iniciar e gerar valor com elas?

Se você perguntar para algum fornecedor de ferramenta que precisa alimentar seus filhos a resposta vai ser – Compre a minha ferramenta mágica de API Management. “Ela irá centralizar, segurar, governar e resolver todos os problemas de API da sua organização.” Infelizmente, isso não é verdade e nos leva à primeira diretriz

1. Não compre uma ferramenta de API Management (até que você tenha estabelecido uma cultura mínima de APIs na sua empresa)

Tenho observados casos de fracasso de empresas que tem adotado ferramentas de APIs sem estabelecer API Teams e formar desenvolvedores que entendam minimamente do protocolo HTTP e do estilo REST.

2. Comece pelos fundamentos básicos e apenas depois avance para as tecnologias

Você é o desenvolvedor ultra mega blaster especialista em ASP.NET Web API e SpringBoot, certo?  Mas você ainda acredita que o POST é para incluir um recurso, PUT é para alterar um recurso. E você também nao sabe o significado da palavra idempotência e o seu efeito prático. E você ainda acredita que REST implica em HTTP. Se sim, pare por um momento e fundamente seus conhecimentos.

Conheço muitos “especialistas” em APIs que nunca leram a RFC do protocolo HTTP – https://tools.ietf.org/html/rfc2616 ou as seções centrais do trabalho de origem de Roy Fiedling sobre REST. É como você conhecer um padre que nunca leu uma bíblia ou um cirurgião que nunca leu um livro de anatomia. Os resultados podem ser muito ruins.

Conhecer os fundamentos do protocolo HTTP, REST e princípios arquiteturais para produzir aplicações escaláveis é vital para usar bem os ótimos produtos de API de mercado.

3. Trate APIs como produtos de negócio

No mais recente relatório da APIgee (State of API Report 2017), empresa especialista em APIs comprada pelo Google, foi observado que as empresas mais bem sucedidas no uso de APIs tem tratado APIs como produtos de negócio.

Tratar APIs como produtos aproxima a TI das áreas de negócio, cria valor e potencializa a criação de novos negócios com empresas parceiras.

4. Use tecnologias simples

Não complique o uso de APIs com tecnologias pesadas. Devemos aprender algo com o fracasso dos ESBs e servidores de orquestração BPMS/SOA na primeira década do século XXI.

Fuja dos protocolos  SOAP e WS-*, exceto se você precisa interoperar com governo. E mesmo assim, crie fachadas REST sobre HTTP para não expor complexidades para os seus clientes.

Use produtos leves e de fácil aprendizado, como o ASP.NET Web API, Spring Boot ou Node.JS. Realiza provas de conceitos e crie experimentos. Estabeleça aprendizados e compartilhe experiências na sua empresa.

4.  Crie APIs Robustas

APIs não devem expor funções de negócio (e não tabelas de banco de dados). Muitos times tem criado APIs que operam como CRUDs das tabelas de seus banco de dados. E esta anti-prática já foi documentada aqui como algo ruim pela ThoughtWorks (Anemic REST). Se você encontrar uma API anêmica na sua máquina, copie a mesma para o diretório /dev/null.

APIs devem ter automação de testes. Em 2017, isso nem deveria ser mais lembrado. Ainda assim, é assombroso que existam desenvolvedores por aí que ainda não acreditam em testes de unidade. Mas é assombroso que também existam políticos corruptos no Brasil!

Mas de volta aos testes de unidade, ferramentas como o Swagger, PostMan ou frameworks XUnit são aliados poderosos neste sentido e podem ajudar a manter as suas APIs integras.

APIs devem ter documentação, preferencialmente em um formato navegável e que permita o consumo da API em modelo self-service pelos desenvolvedores de clientes das APIs. Novamente ferramentas bacanas existem aqui com o Swagger, Apiary ou o Slate API Docs Generator.

APIs devem ser baseadas pelo menos no nível 2 de Maturidade RESTful de Richardson

Mas quem é Richardson? E o que ele tem a ver com o meu trabalho?
Leia aqui porque isso é importante para você.

APIs devem ser consistentes entre desenvolvedores e times. Crie com o seu time um padrão apropriado para criar APIs.

Você pode usar algumas boas práticas de mercado e adaptá-las para a sua realidade. Por exemplo, recomendo estes pontos de partida para você o seu time:

5. Governe as suas APIs (Sim! Agora você pode adotar uma ferramenta de API Management)

Você já um API Team, já sabe usar o protocolo HTTP e já começou a estabelecer uma cultura de APIs. Muito bom! Agora você pode baixar uma ferramenta aberta ou comprar uma ferramenta de API Management.

Opções não faltam para você e recomendo o excelente relatório do Forrester de integração híbrida. Use-o como ponta de partida para você selecionar os seus candidatos, fazer provas de conceitos e dar o próximo passo em termos de maturidade na sua organização.

Bons estudos e boas APIs!

API Nerd do Dia – https://developer.marvel.com
(Para aprender como fazer uma boa API com os seus quadrinhos e filmes preferidos).

 

O radar técnico da ThoughtWorks, em português

~ Marco Mendes ~ 1 comentário

A ThoughtWorks possui uma excelente publicação técnica, com tendências tecnológicas em técnicas, linguagens, plataformas e ferramentas de desenvolvimento de software. Originalmente publicado em inglês, esteve inacessível àqueles não versados na língua do Tio Sam. Felizmente, eles lançaram o novo Radar Técnico também em português.

Neste radar, de Janeiro de 2014, os temas centrais por eles pontuados são:

Alerta e recuperação antecipados em produção – Estamos observando uma infinidade de novas ferramentas e técnicas para capturar logs, monitorar, armazenar e consultar dados operacionais. Quando combinadas com uma rápida recuperação oferecida pela virtualização e automação de infraestrutura, as empresas podem reduzir a quantidade de testes necessários antes da implantação, talvez até mesmo executando os testes no próprio ambiente de produção.

Privacidade versus Big Data – Ao mesmo tempo em que estamos animados com as novas perspectivas de negócio possibilitadas pela coleta exaustiva de dados, também estamos preocupados com o fato de muitas empresas armazenarem grande quantidade de dados pessoais desnecessariamente. Defendemos que as empresas adotem uma atitude de “datensparsamkeit” e armazenem apenas o mínimo de informações pessoais necessárias sobre seus clientes.

O rolo compressor do JavaScript continua – O ecossistema em torno do JavaScript continua evoluindo como uma importante plataforma de aplicação. Muitas ferramentas interessantes têm surgido para testes, gerenciamento de dependências e construção de aplicações JavaScript, tanto do lado servidor, como do cliente.

A fusão do mundo físico e digital – dispositivos de baixo custo, plataformas de hardware aberto e novos protocolos de comunicação estão levando a experiência de usar um computador para mais perto do mundo ao nosso redor, longe das telas. Um grande exemplo é a proliferação de dispositivos vestíveis para rastrear dados biométricos e o suporte de hardware em outros dispositivos móveis, como telefones e tablets, para interagir com os mesmos.

Embora muitas das tecnologias do radar ainda sejam muito exóticas para a maior parte do público de TI do Brasil, é notável a tendência de crescimento do JavaScript, que também tenho observado em relatório do Gartner e até da nossa base pessoal de projetos e da observação de clientes. É o JavaScript, criado na quinta divisão do futebol inglês e que caminha a passos largos para a Champions League da tecnologia.

Para os curiosos, o relatório pode ser baixado neste sítio.
Boa leitura nerd, agora em português!

Como organizar uma prova de conceito arquitetural

~ Marco Mendes ~ 2 Comentários

O termo prova de conceito (POC) em arquiteturas de software e dados tem se tornado muito popular. Provas de conceito são instrumentos de mitigação de riscos técnicos, criação de arquiteturas executáveis e podem servir a vários propósitos gerenciais em um projeto. Apresentamos abaixo um modelo mental para guiar arquitetos na escolha e organização de uma prova de conceito. O nosso modelo é baseado em seis questões de análise

1. Que requisitos e cenários são candidatos a uma prova de conceito?

Observe a figura abaixo, que mostra os tipos de requisitos típicos de um sistema. Como exemplo, se considerarmos um site de comércio eletrônico veremos que os cenários de negócio ligados à venda de produtos e que fazem comunicações com sistemas de processamento de pagamento diversos são críticos para o negócio e ao mesmo tempo desafiantes tecnicamente em termos do tempo de reposta, disponibilidade, escalabilidade e vazão.

Tipos de Requisitos em projetos de software.
Tipos de Requisitos em projetos de software.

Os requisitos do quadrante 1 são aqueles que devem ser investigados pelo arquiteto e que normalmente derivam provas de conceito.

2. Quantas provas de conceito devo ter?

O número de provas de conceito é proporcional ao grau de risco de um projeto e portanto não é um número pré-determinado. Como regra geral, o número de provas de conceito deve tornar o risco técnico do projeto baixo e administrável ao longo do seu ciclo de vida.

3. O que uma prova de conceito irá explorar?

Provas de conceito normalmente exploram dois aspectos (estruturas ou comportamentos).

Provas de conceito que exploram estruturas normalmente são usadas para compararmos ou selecionarmos tecnologias, determinar viabilidade tecnológica de uma pilha tecnológica ou mesmo a descoberta de uma melhor prática técnica (ex. JEE ECB ou ASP.NET MVC). Provas de conceito que exploram comportamentos normalmente querem explorar algum caso de uso, história do usuário ou cenário de negócio potencialmente complexo em um sistema.

4. O que uma prova de conceito irá produzir?

A figura abaixo fornece tipos comuns de provas de conceito, que podem ir desde uma leitura de um artigo, passando por uma simulação simples de uma solução e até mesmo um protótipo evolutivo. Como regra geral, quanto maior o risco, mais densa tende a ser uma prova de conceito.

Tipos de provas de conceito

O conjunto dos produtos resultantes das provas de conceito de um produto é chamdo de arquitetura executável, composta por modelos, artigos, rascunhos, códigos descartávels ou mesmo códigos evolutivos.

5. Quando devo fazer as provas de conceito?

Use a regra do terço. No primeiro 1/3 de um projeto você deve ter todas as provas de conceito de um projeto finalizadas de forma a acomodar riscos e determinar a arquitetura executável do seu sistema.

6. Como encaixar as provas de conceito no processo de software da minha empresa?

  • Se você usa métodos ágeis, mescle provas de conceito ao longo dos primeiros sprints de um projeto. Se possível, crie o conceito do Sprint 0 dedicada apenas ao tema prova de conceito.
  • Se você usa o processo unificado (IBM RUP, Enterprise Unified Process, Open-UP, Essential UP ou similar), a fase de elaboração foi criada para lidar com provas de conceito.

Extraordinary claims require extraordinary evidence – Carl Sagan

A evolução do BPM, o iBPM

~ Marco Mendes ~ Deixe um comentário

A Target é uma gigante americana que trabalha no mercado varejista e que desenvolveu nos últimos anos um sofisticado sistema de análise preditiva que lhe permite avaliar, com boa precisão, as preferências de compra de cada consumidor individualmente. Este modelo é resumido no esquema abaixo.

Este modelo demonstra o conceito de Intelligent Business Operations e mostra como empresas podem obter vantagem competitiva com o uso de tecnologia da informação.
Modelo de análise preditiva de compras da Target, para permitir o envio de propagandas mais assertivas e melhorar a probabilidade de compras de novos produtos e portanto aumento do seu faturamento financeiro.

Baseado neste modelo, esta empresa conseguiu até mesmo detectar grávidas no segundo trimestre da gravidez, o que lhe promoveu vantagem competitiva e fidelização das novas mamães e papais. Para referência, antes da Target as empresas somente conseguiam detectar automaticamente as novas mães no terceiro trimestre da gravidez. Este caso foi até citado na revista Veja na edição que fala sobre BigData e representa o que Gartner Group chama de IBO (Intelligent Business Operations). O IBO é o processo de melhoria das operações de uma empresa, que se tornam mais inteligentes e responsivas através da integração de BPM, análise preditiva, tecnologias sociais e móveis. As organizações que já entenderam o potencial do IBO estão avançando e ocupando espaços de outras organizações mais lentas e reativas.

Para que uma empresa implemente um IBO, ela precisa possui uma plataforma de automação de TI apropriada. Esta plataforma é o iBPM, ou o intelligent Business Process Management.

Um BPM tradicional, mesmo que muito robusto, pode ser visto como a coleção das seguintes peças:

  • Modelador de processos, com suporte a linguagem como BPMN.
  • Simulador de processos, para análise futura de melhorias de processo.
  • Orquestrador de processos, que é um ambiente de execução que permite que um processo BPM seja executado e enlace serviços de TI.
  • IDE para modelagem e orquestração de processos, que é o ambiente de desenvolvimento do analista de BPM
  • Monitor de processos (BAM), que avalia em tempo real as métricas e indicadores de um processo de negócio.
  • Repositório de processos, que permite manter as versões de processo e governar os ativos de processos de uma organização.

Um iBPM vai muito além. Ele inclui também:

  • Suporte à mídia social para incorporar fontes de dados  externas e perspectivas externas (como especialistas e as vozes dos clientes) e dados de contexto em todo o ciclo de vida de um processo. A mídia social pode melhorar e fornecer mais informações sobre o contexto situacional. A mídia social também apoiará técnicas analíticas adicionais, tais como análise de rede social para apoiar as decisões de um processo. Em termos práticos, um processo de promoções de vendas pode olhar os feedbacks sobre um produto no Twitter e Facebook e tomar decisões baseados nestas questões.
  • Suporte de dispositivo móvel para dar aos contribuintes individuais e supervisores acesso 24/7  para manter a capacidade de respostas em qualquer momento .
  • capacidades analíticas ativas em áreas como monitoramento de atividades de negócios (BAM) e tecnologias CEP (Processamento de eventos complexos) para fornecer análises melhores e mais amplas.
  • painéis de negócios mais elaborados para fornecer melhor visibilidade em tempo real sobre o desempenho do processo.
  • Um conjunto crescente de ferramentas de gestão de decisões, incluindo
    suporte poderoso para a gestão de regras de negócio (BRM e BRMS), tecnologias de otimização e simulação, bem como motores de otimização baseados em restrições que utilizam técnicas matemáticas avançadas para pesar
    trade-offs e gerar a decisão mais eficaz disponível.
  • O acesso a fontes de informação não-estruturados e externas, incluindo vídeo, áudio e streams sociais
  • Integração com ferramentas analíticas on-demand.

Para se implementar um iBPM, é necessário uma boa arquitetura de integração, a escolha e seleção de um bom fornecedor de iBPM e a presença de bons arquitetos para habilitar com sabedoria esta nova e complexa plataforma.

PegaSystems, Appian e IBM largaram na frente e ofertam as soluções mais robustas de iBPM, segundo o quadrante mágico do Gartner Group (Ver quadro abaixo). Mas muitas outras empresas também ofertam soluções interessantes e já habilitam a sua empresa para avançar no caminho das operações inteligentes de negócio.

O quadrante mostra os principais fornecedores da segunda geração de ferramentas BPM do século XXI
O quadrante mostra os principais fornecedores da segunda geração de ferramentas BPM do século XXI, o iBPM.

Texto originalmente postado em: http://www.betapyx.com/blog/2014/01/08/a-evolucao-do-bpm-o-ibpm/.

O padrão VETRO e a integração de sistemas

~ Marco Mendes ~ Deixe um comentário

Integrar aplicações em diferentes tecnologias, plataformas ou sistemas operacionais pode ser um formidável desafio a desenvolvedores e arquitetos. Observo nas empresas códigos muito desorganizados e muita confusão quando o assunto é integrar aplicações. Compilo neste post um pequeno padrão arquitetural para ajudar a resolver problemas de integração.

Conheça o padrão VETRO

Vamos aprender a usar este padrão em um exemplo fictício onde precisamos buscar os dados de um determinado cidadão do sistema da receita federal e gravar estes dados em um banco de dados local em formato SQL.

1. VALIDAR. 

O primeiro passo recomendado de toda integracão é realizar a validação dos dados recebidos. A validação pode verificar se o objeto de dados (um esquema XML ou texto JSON) está bem formado.

Como os dados são gerados por aplicações externas, é sempre boa prática “desconfiar” dos dados que estão sendo recebidos, pois eles podem ter sido modificados na estrutura de negócio ou no formato técnico sem aviso prévio.

No exemplo dado, poderíamos checar se a mensagem XML com os dados de um cidadão estão em conformidade com o esquema XSD esperado.

2. ENRIQUECER

O termo enriquecer tem por objetivo adicionar dados adicionais ao pacote de dados recebido. Muitas vezes isso é necessário para que o pacote de dados esteja compatível com o formato esperado pelo destinatário.

No exemplo dado, poderíamos enriquecer a mensagem XML com os dados do cidadão com a informação do login do usuário que esteja usando a aplicação. Estamos considerando que esta informação nova poderia ser usada para auditoria

3. TRANSFORMAR

O próximo passo é realizar a transformação dos dados (seja no formato dos dados ou protocolo técnico). No nosso caso, queremos extrair da estrutura XSD e colocar em um formato universal da plataforma que estamos usando.

Por exemplo, se estivéssemos escrevendo estes códigos em Java ou C#, poderíamos criar um objeto POJO ou POCO com os dados do cidadão enriquecidos com o login do usuário.

4. ROTEAR

Agora estamos próximo do fim e neste passo estamos fazendo o roteamento da informação para o seu destino. No nosso caso, iremos abrir a conexão (IP e porto) com o banco de dados onde iremos salvar o nosso POJO ou POCO com os dados do cidadão.

Em cenários mais elaborados, o roteamento pode envolver rotas complexas.

5. OPERAR

Finalmente, iremos gravar os dados no banco de dados. O passo operar implica em entregar a informação para o destinatário final e terminar a rotina de integração.

O padrão VETRO pode ser implementado através do padrão de desenho cadeia de responsabilidades em Java ou C# e curiosamente forma a base de vários produtos de ESB do mercado. Em projetos SOA, chamamos estas lógicas de serviços de mediação, que também possuem a mesma estrutura básica.

Independente da tecnologia ou plataforma, entretanto, organizar um código desta forma nos fornece limpeza semântica e boa organização em lógicas de integração.

Boas integrações!

Pensamento do dia:
“Manifest plainness,
Embrace simplicity,
Reduce selfishness,
Have few desires.”,
Lao-tzu