Fundamentos, Objetivos e Benefícios estratégicos de SOA (parte 1)
Overview
Ao decorrer de minha jornada com Arquitetura Orientada a Serviços me deparei em uma série de confusões que as pessoas tinham com SOA:
- “SOA é XML”
- “SOA são aqueles Webservices SOAP”
- “Não precisamos de SOA, hoje temos REST”
Dentre outras coisas…
O objetivo dessa postagem é desmistificar o termo, trazendo-o para um contexto mais simples de ser entendido.
Ao final de toda a série pretendo responder algumas perguntas como:
- O que é SOA?
- Para que eu preciso disso?
- Como aplicar?
- SOA é SOAP?
Antes de começar, deixe-me começar com uma analogia:
Digamos que você tenha a ideia de ter uma casa.
Em uma abordagem mais pragmática, o seu primeiro passo não deve ser iniciar a busca de onde construir a casa. Tão pouco na busca por projeto de construção junto a alguma construtora.
Pode até soar ridículo aos seus olhos a frase a seguir, mas a pergunta inicial a ser feita deveria ser: Para que projetar a casa? Comprar uma casa, alugar uma casa ou construir uma casa?
Sim, eu sei… realmente parece bem óbvio, mas aonde queremos chegar com essa analogia, e o que ela tem a ver com SOA?
Bom, tentando fazer um paralelo com o desenvolvimento de software, apesar de SOA não ser TI, quando vamos iniciar o projeto, não deveríamos nos preocupamos inicialmente em aonde vamos hospedar nossas soluções ou se devemos usar AWS ou Azure. Tão pouco nos deveríamos nos preocupar de início se iremos usar uma solução NodeJS, Java, Kotlin, mobile, Ruby, etc. O ponto inicial é: o que eu quero resolver e para que?
Ciente do problema negocial, é muito mais simples tomar uma decisão X, Y ou Z, e mais ainda, pode ser que seja o caso de não ser necessário fazer toda uma reestruturação do zero para o cliente. Voltando à nossa analogia anterior, pode ser que a melhor solução para nós mesmos não seja construir uma casa do zero, e sim alugar uma casa, mas chegaremos nesse ponto mais a frente.
Lembre-se:
SOA não é TI.
SOA não é uma metodologia.
Considerações iniciais
Sim, eu sei… sei que para você isso parece mais uma buzzword que você ouve, e que provavelmente só serve para vender software ou seja lá o que for para pessoas que acreditam no papo de vendedores Oracle, IBM, Microsoft, etc.
Vamos então tentar mudar essa primeira impressão.
SOA é o acrônimo de Service Oriented Architecture, o que responde a nossa pergunta.
Lembre-se:
SOA é uma arquitetura.
E antes de continuarmos com mais definições, vamos a um dado curioso:
SOA já teve mais de uma onda de implantação, e um outro fato curioso é que a segunda onda teve como diferencial o deixar de ser tecnológico e passar a ser estratégico.
Antes de prosseguir, não vou ficar aqui dizendo que SOA é a melhor coisa que já existiu no mundo, e tão pouco dizer que não houveram erros na forma em que a mesma foi conduzida. Também não estou te prometendo uma bala de prata capaz de resolver todos os problemas.
Um dos fatos pelos quais SOA “morreu” em sua primeira onda, foi porque muitos vendedores começaram a querer expressar SOA como algo puramente técnico, focando em ESBs (falaremos disso adiante) e em componentes de integrações.
Ei você desenvolvedor “modinha” que fala que SOA é coisa antiga e que o pessoal era muito ignorante por acreditar nesse tipo de coisas. Estamos de olho em você que diz que implementar DevOps é colocar pipeline no Jenkins na empresa.
Realmente espero que as pessoas não saturem o termo DevOps como ocorreu com SOA, mas é o que tenho visto em muitos cenários, em que a ferramenta é colocada acima da cultura. Na verdade, é até engraçado o quanto as coisas são cíclicas:
Enquanto SOA era vista por muitos como a instalação ou posse de um ESB, DevOps tem sido visto por muitos como pipelines no Jenkins. Enquanto o alinhamento do negócio com a TI era esquecido por parte das consultorias que “instalavam” SOA, propostas como disseminação de cultura e ausência de cultura da culpa tem sido negligenciadas no mundo DevOps.
De qualquer forma, isso é tema para um próximo post…
Ei você que acha que uma API REST desenvolvida com Spring Boot é um Microservice… estamos falando com você também…
Minha experiência
Para exemplificar um pouco mais, vou contar minha experiência com SOA.
Em meados de 2012 eu estava trabalhando como desenvolvedor Java Jr, e naquele momento eu havia percebido que o Java pelo Java não me traria um grande diferencial no mercado de trabalho. Existiam muitas fábricas de software em Brasília, e eu acabaria trabalhando em algo como Struts ou JSF e Hibernate.
Recebi uma proposta de um centro de pesquisas para trabalhar com SOA. Até aquele momento, nunca havia ouvido falar daquilo, mas a se basear na Orientação a Objetos e Orientação a Aspectos, eu pensava que Orientação a Serviço seria uma dependência no Maven Repository para a execução de seja lá o que for.
Troquei de emprego, e quando questionei o meu superior sobre quando eu configuraria o meu Eclipse com o plugin de SOA, ou quando eu baixaria a dependência para o meu projeto, recebi uns 3 livros de mais de 500 páginas de um autor chamado Thomas Erl.
Analisando com mais cuidado o que estava sendo explicado nos livros, pude perceber que na verdade eu estava bem longe da parte de implementação naquele momento. A ideia girava em torno de Alinhamento de Negócio e TI, porém com uma ênfase e Centralizado no Negócio (Business Centric).
Sei que posso estar um pouco atrasado, mas antes que algum vendedor te engane… Não! Se você instalar a suíte de desenvolvimento de qualquer um deles: Oracle SOA Suite, IBM Integration BUS, WSO2, Mule Soft, ainda sim pode ser que você não tenha SOA. Não existe um plugin, nem um validador se seu “código está SOA”, na verdade, pode ser que você alcance tudo isso inclusive sem figuras como barramento e mensageria, por exemplo.
Quando você começa a avaliar esse ponto com cuidado, pode perceber o porque do fracasso da primeira onda de SOA.
Não me leve a mal se você é desenvolvedor (eu também sou), mas se você está nessa jornada há um pouco mais de tempo, pode ter se deparado com o pensamento que você entende melhor o negócio do seu cliente do que ele mesmo. Você pode ter tido a prepotência, como eu já tive, que a equipe de negócio não faz nada e que se todo mundo usar o framework X, Y ou Z todos os problemas seriam resolvidos.
“Ah… mas o legado do cliente é todo em Java. Vamos começar tudo do zero com NodeJS”
“Quem é que usa MySQL hoje em dia? Vamos de NoSQL ou NewSQL. Joga tudo o que tem antes fora”
Agindo dessa forma, você só está replicando o erro que SOA teve no inicio:
“Você só vai conseguir SOA se instalar a minha suíte de desenvolvimento, não me interessa se você tem um legado em outra estrutura”
Esse é um dos motivos pelo qual a palavra SOA foi banida em algumas regiões da Europa. O significado da palavra estava saturado, e cada vendedor afirmava que só seria possível obter todos os resultados se você abrisse mão de todo o seu legado e comprasse toda uma suíte de desenvolvimento nova.
De qualquer forma, caso você seja um desenvolvedor, não ache que isso tudo é uma abordagem que excluí o desenvolvimento.
O desenvolvimento continuará sendo uma área muito importante, mas não mais que o negócio. Ainda que pensemos que num futuro próximo todas as empresas serão empresas de TI com licença para executar seus negócios em algumas áreas, é o negócio quem direciona a empresa, não os frameworks.
Considerações
Terminaremos essa primeira parte por aqui, mas já continuaremos com a segunda parte em que abordaremos os Objetivos e Benefícios Estratégicos de SOA.
Até lá
