SOA de verdade focando no retorno

Você pode adotar SOA em sua empresa usando qualquer tecnologia. Na
teoria. Na prática, você acaba adotando as melhores e mais atuais. Estas tecnologias muitas vezes não são solução melhores porque são mais novas, mas porque têm um modelo melhor, foram concebidas
com o aprendizado dos erros de outras tecnologias anteriores.

É muito comum que, em uma adoção de SOA, algum vendor ou consultor indique
que você comece a sua adoção focando em um ESB. Por si só o ESB é uma
excelente tecnologia, porém não basta comprar um ESB, isto não vai fazer
a sua adoção de SOA estar finalizada e ter sucesso.

O que faz uma adoção de SOA ter sucesso?

O primeiro de tudo é focar no negócio. SOA possibilita uma grande
vantagem competitiva para as empresas que sabem como usar. Este saber
usar significa focar em ROI, pensar primeiro quais objetivos de
negócios devem ser atingidos.

Infelizmente a grande maioria das adoções de SOA só se baseava em compra
de software e grandes investimentos e pouco retorno para o negócio das
empresas. Para que a sua adoção de SOA dê certo você precisa muito focar
no negócio e pensar muito, mas muito mesmo, no que realmente a sua empresa
deseja atingir. Isto é bem diferente da estratégia “compre um ESB
primeiro”.

O manifesto SOA

O Manifesto SOA tem um papel importante nos dias de hoje, porque ele
representa toda esta “segunda-onda-soa”, ou seja, toda esta mudança de
pensamento, focando mais em resultados, princípios e escolhas de design
arquitetural do que em compra de software, altos investimentos e pouco ou
ZERO retorno.

Observe o quadro abaixo: no Manifesto SOA são priorizados os itens da esquerda sobre os da direita. Isso dá um noção do que é mais importante. Não significa
que você não possa fazer os itens que estão à direita, mas deve tentar evitá-los, focando nos da esquerda.

• Business value over technical strategy
• Strategic goals over project-specific benefits
• Intrinsic interoperability over custom integration
• Shared services over specific-purpose implementations
• Flexibility over optimization
• Evolutionary refinement over pursuit of initial perfectionão

O que deve ficar claro com o manifesto é que SOA não é um objetivo, mas
sim um meio para atingir algo maior. Através de SOA você pode atingir os
seus objetivos estratégicos. A história já provou que isso requer muita
reflexão, cautela e que não vai ser feito apenas com tecnologia.

Dando o segundo passo

Um vez que você tenha sentado com o pessoal de negócios da sua organização e
definido bem os objetivos de negócio, agora você pode começar a pensar
como vai fazer isso em termos de software. O manifesto ajuda, mas não
vai lhe dar todas as respostas.

Existem várias formas de fazer a sua adoção. Logo, não existe o certo, mas o que é mais apropriado, dependendo do contexto. Ok, mas você não
poderia falar um pouco mais de tecnologias? Sim. eu vou! 😀

Falando de Java, você pode usar coisas que já são consagradas como
Messageria, Arquitetura em Camadas, Separação de Conceitos muito clara,
Web Services, REST, ORM e tantas outras tecnologias.

Mas não seria interessante começar com um ESB? Isso depende muito. Se a
sua equipe já tem experiência forte com java e adoção de SOA, este é o
caminho natural. Mas se as pessoas de sua equipe não estão
familiarizadas com isso, seria bom começar com algo mais simples e focar
muito mais muito no DESGIN e na GOVERNAÇA.

Design é tudo, certamente é uma das partes mais difíceis porque você
tem que pensar em diversos pontos e diversas pequenas decisões que fazem
a diferença. O design pode e deve estar muito ligado à governança
SOA, que não deve focar apenas nos aspectos de runtime.

É muito comum ver soluções de governança por aí no mercado amarradas a um ESB, e
políticas de runtime na maioria das vezes associadas as padrões de
WebServices, mas a governança é mais, muito mais que isso.

A Governança SOA, em termos de runtime deve prover as políticas, mas
também o repositório de serviços, onde você possa consultar serviços,
versionar contratos, que ajude você a planejar a trocar e
atualização de serviços.

Então a Governaça SOA é só runtime?

Como você pode perceber no parágrafo acima, a governança foca muito em
gestão, análise de impacto e outras coisas relacionadas a serviços. Mas a
também foca antes do runtime, ou seja, em tempo de projeto ou
design.

Neste tempo que você deve pensar nas decisões mais importantes na hora
de construir a sua arquitetura e os seus serviços, isto pode ser feito
de forma incremental, de cara você não precisa de uma solução de
registry e repository, mas precisa sim definir as políticas, práticas e
escolhas de design.

Escolhas como, por exemplo, a estratégia de
versionamento de serviços, se os seus beans serão expostos diretamente ou
se você vai criar abstrações do serviços para os consumidores, como as camadas serão separadas e quais, as formas e padrões, formatos
de dados e transporte, e assim por diante.

Indo adiante…

Comece com um projeto piloto e simplifique ao máximo a sua arquitetura,
foque no design e escolha frameworks e ferramentas simples, tome muito
cuidado para não focar mais em frameworks do que propriamente nos seus
objetivos de negócio.

Soluções open source sempre são uma boa pedida, mas às vezes precisamos
colocar alguns ingredientes pagos e proprietários. Fique calmo quanto a
esse ponto, é natural que em um ambiente SOA você não tenho
homogeneidade, você vai ter diversos vendors e tecnologias.

Aprenda com os seus erros e sempre foque no retorno para o negócio,
design, governança e não deixe ter fazer as sessões de lições
aprendidas: aprendemos mais com os nossos erros do que imaginamos. À
medida que você for evoluindo nestes aspectos, você pode começar a usar
outras soluções mais complexas em termos de arquitetura.

Lembre-se de que a sua adoção SOA não vai ser feita em um ano, pode ser
que leve 5 anos ou mais, mas o que importa é o aprendizado e o retorno
para o negócio. Faça isso sem parar o mundo, porque senão você só vai
engordar a lista do Gartner de empresas que não conseguem provar o valor
de SOA para o negócio.

Abraços e até a próxima.