SOA de verdade focando no retorno
Você pode adotar SOA em sua empresa usando qualquer técnologia na teoria. Na prática você acaba adotando as melhores e mais atuais técnologias. Estas tecnologias muitas vezes não são solução melhores por que são mais novas, mais por que tem um modelo melhor, foram concebidas com o aprendizado dos erros de outras técnologias 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 execelente técnologia 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 negocio, SOA possibilita uma grande vantagem competitiva para as empresas que sabem como usar. Este saber usar significar focar em ROI, pensar primeiro em que objetivos de negocios devem ser atingidos.
Infelismente a grande maioria das adoções de SOA só se baseava em compra de software e grandes investimentos e pouco retorno para o negocio das empresas. Para que a sua adoção de SOA de certo você precisa muito focar no negocio e pensar muito mais muito no que realmente a sua empresa deseja atingiar. Isto é bem diferente da estratégia compre um ESB primeiro.
O Manifesto SOA
O Manifesto SOA tem um papel importante nos dias de hoje, por que ele representa toda esta *segunda-onda-soa*, ou seja, toda esta mudança de pensamento, focando mais em resultados e principios, escolhas de design arquitetural do que compra de software, altos investimentos e pouco ou ZERO retorno.
São priorizados os itens da esquerda sobre os itens da direita no manifesto SOA, isto dá um noção do que é maios importante. não significa que você não possa fazer os itens da direita, mas deve tentar evitar eles focando nos da esquerda, então vamos ao manifesto.
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 mais 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 vair ser feito apénas com ténologia.
Dando o Segundo passo
Um vez que você sentou com o pessoal de negocios da sua organização e definiu bem os objetivos de negocio, 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, existe o que é mais apropriado dependendo do contexto. Ok, mas você não poderia falar um pouco mais de ténologias? Sim eu vou! :D
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 ténologias.
Mas não seria interessante começar com um ESB? Isso depende muito. Se a sua equipe já tem experiencia forte com java e adoção de SOA, este é o caminho natural. Mas se as pessoas de sua equipe não estão fanilharizadas 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 dificies por que você tem que pensar em diversos pontos e diversas pequenas decisões que fazem a diverença. O Design pode e deve estar muito ligado com a governança SOA que não deve focar apénas nos aspectos de runtime.
É muito comun ver soluções de governça ai no mercado amarradas a um ESB e politicas 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 politicas mas também o repositorio de serviços, aonde você possa consultar serviços, versionar contratos de serviços, 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 paragrafo a cima a a governça foca muito em gestão, analise de impacto e outras coisas relacionadas a serviços. Mas a governç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 politicas, práticas e escolhas de design.
Escolhas como por exemplo, qual vai ser a sua estratégia de versionamento de serviços, você vai expor diretamente os seus beans ou vai criar abstrações do serviços para os consumidores, você vai separar como as camadas, quais camdas, quais seram 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 negocios.
Soluções open source sempre são uma boa pedida, mas as vezes precisamos colcoar alguns ingredimentes pagos e proprietários, fique calmo quanto a esse ponto, é natual que em um abimente SOA você não tenho homogenidade, você vai ter diversos vendors e técnologias.
Aprenda com os seus erros e sempre foque no retorno para o negocio, design, governança e não deixe ter fazer as sessões de lições aprendidas, nos aprendemos mais com os nossos erros do que imaginamos. A medida que você for evoluindo nestes apectos você pode começar a usar outras soluções mais complexas em termos de arquitetura.
Lembrese de que a sua adoção SOA não vai ser feita em um ano, pode ser que leve 5 ou mais anos, mas o que importa é o aprendizado e retorno para o negocio. Faça isso sem parar o mundo, por que senão você só vai engorar a lista do Gartner de empresas que não conseguer provar o valor de SOA para o negocio.
Abraços e até a próxima.
É 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 execelente técnologia 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 negocio, SOA possibilita uma grande vantagem competitiva para as empresas que sabem como usar. Este saber usar significar focar em ROI, pensar primeiro em que objetivos de negocios devem ser atingidos.
Infelismente a grande maioria das adoções de SOA só se baseava em compra de software e grandes investimentos e pouco retorno para o negocio das empresas. Para que a sua adoção de SOA de certo você precisa muito focar no negocio e pensar muito mais muito no que realmente a sua empresa deseja atingiar. Isto é bem diferente da estratégia compre um ESB primeiro.
O Manifesto SOA
O Manifesto SOA tem um papel importante nos dias de hoje, por que ele representa toda esta *segunda-onda-soa*, ou seja, toda esta mudança de pensamento, focando mais em resultados e principios, escolhas de design arquitetural do que compra de software, altos investimentos e pouco ou ZERO retorno.
São priorizados os itens da esquerda sobre os itens da direita no manifesto SOA, isto dá um noção do que é maios importante. não significa que você não possa fazer os itens da direita, mas deve tentar evitar eles focando nos da esquerda, então vamos ao manifesto.
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 mais 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 vair ser feito apénas com ténologia.
Dando o Segundo passo
Um vez que você sentou com o pessoal de negocios da sua organização e definiu bem os objetivos de negocio, 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, existe o que é mais apropriado dependendo do contexto. Ok, mas você não poderia falar um pouco mais de ténologias? Sim eu vou! :D
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 ténologias.
Mas não seria interessante começar com um ESB? Isso depende muito. Se a sua equipe já tem experiencia forte com java e adoção de SOA, este é o caminho natural. Mas se as pessoas de sua equipe não estão fanilharizadas 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 dificies por que você tem que pensar em diversos pontos e diversas pequenas decisões que fazem a diverença. O Design pode e deve estar muito ligado com a governança SOA que não deve focar apénas nos aspectos de runtime.
É muito comun ver soluções de governça ai no mercado amarradas a um ESB e politicas 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 politicas mas também o repositorio de serviços, aonde você possa consultar serviços, versionar contratos de serviços, 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 paragrafo a cima a a governça foca muito em gestão, analise de impacto e outras coisas relacionadas a serviços. Mas a governç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 politicas, práticas e escolhas de design.
Escolhas como por exemplo, qual vai ser a sua estratégia de versionamento de serviços, você vai expor diretamente os seus beans ou vai criar abstrações do serviços para os consumidores, você vai separar como as camadas, quais camdas, quais seram 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 negocios.
Soluções open source sempre são uma boa pedida, mas as vezes precisamos colcoar alguns ingredimentes pagos e proprietários, fique calmo quanto a esse ponto, é natual que em um abimente SOA você não tenho homogenidade, você vai ter diversos vendors e técnologias.
Aprenda com os seus erros e sempre foque no retorno para o negocio, design, governança e não deixe ter fazer as sessões de lições aprendidas, nos aprendemos mais com os nossos erros do que imaginamos. A medida que você for evoluindo nestes apectos você pode começar a usar outras soluções mais complexas em termos de arquitetura.
Lembrese de que a sua adoção SOA não vai ser feita em um ano, pode ser que leve 5 ou mais anos, mas o que importa é o aprendizado e retorno para o negocio. Faça isso sem parar o mundo, por que senão você só vai engorar a lista do Gartner de empresas que não conseguer provar o valor de SOA para o negocio.
Abraços e até a próxima.
