SOA sem BPMN e WebServices
Nestes 3 últimos anos vem se falando muito de SOA. Todos querem ter um projeto SOA, não tenho dúvidas que SOA virou um buzzword. Muitos vendors tentam vender SOA como uma tecnologia, mas facto não é. Ainda existe muita confusão quando se fala do assunto.
Todos querem SOA mas muito poucos sabem o que de facto SOA é e quando deve ser utilizada. Os acadêmicos já não aguentam mais trabalhos de conclusão sobre SOA. Não era de se esperar o contrário. Eu gosto de SOA e particularmente acredito ser uma boa solução em alguns cenários, porem cada vez mais SOA é banalizado e empacotado por vendedores como a ultima solução para todos os seus problema de software.
Fazem mais de 30 anos e ainda não conseguimos fazer sistemas que tenham baixo acoplamento e alta coesão. Mas cada vez mais soluções prontas são vendidas com a promessa de resolver todos os seus problemas.
O que é SOA?
SOA é um estilo de arquitetura corporativa. Quero frisar o corporativa aqui, por que se você vai desenvolver uma loja virtual ou algo para uma pequena empresa você não precisa de SOA, muito provavelmente o custo não irá ser pago pelos benefícios visto o tamanho da empresa.
SOA não é um conjunto de tecnologias!
Para fazer SOA não é necessário usar WebServices. Muito menos BPMN. Muitas pessoas acham que se usar WEBservices e/ou BPMN booom você tem um sistema SOA e tudo sera melhor. Negativo!
SOA não é para um sistema isolado!
Se você tem só um sistema e não tem prospectiva de ter outros tão cedo não há por que utilizar SOA, nesse caso você só estará dispersando recursos e adicionando risco e complexidade ao seu projeto. SOA é melhor aproveitado quando você tem dois sistemas ou mais e está em um contexto corporativo.
Começando tudo errado!
As empresas começam usando SOA de maneira errada. Por que para começar a implantação vem muitas vezes de um Diretor de TI, é verdade SOA esta na moda entre os diretores de TI. E na verdade isto deveria vir dos Arquitetos da Empresa não dos gerentes. SOA é uma solução arquitetural e tem que vir de um arquiteto.
Não é o diretor de TI que sabe se os colaboradores estão maduros o suficiente para usar SOA, novamente as pessoas se preocupam muito as coisas que não são criticas e as cosias criticas são deixadas de lado.
Primeira preocupação com SOA: Como implementar
Essa é a primeira cosia que as pessoas se perguntam e isso é errado. Na verdade primeiro devemos nos preocupar em o que é SOA e se precisamos de SOA. Muitas vezes não se precisa de SOA, mas o modismo das consultorias acaba ganhando as vezes.
Fique muito preocupado se o seu diretor de TI ou seu gerente quiser usar uma solução SOA, por que novamente se isso não veio de um arquiteto sensato, muitos problemas viram!
São princípios
SOA é sobre princípios não tecnologias. São práticas e hábitos de desenvolvimento de sistemas que se seguidos vão fazer com que seus sistemas conversem de forma mais efetiva e você reaproveite muito melhor seus componentes transformando eles em assets corporativos de verdade.
Esses princípios de certa forma se transformam em um novo paradigma. Como toda paradigma leva tempo até ser quebrado. Logo você deve se preocupar inicialmente nos princípios e depois como implementá-los.
Sim você pode usar WebServices, mas isso é um detalhes de implementação que é secundário, não é o ponto mais importante. O ponto mais importante é que você tenha consciência do que está fazendo, usar por usar é pior do que não usar em muitos casos!
A Definição de SOA
O Pessoal do Open Group vem trabalhando nisso. dito que eles estão no caminho certo. O problema é que a maioria das empresas si quer conferiu esse material.
O Nível de cada coisa
As coisas estão em níveis. SOA está em um nível de abstração muito mais alto do que WebServices, SCA, EIP e BPMN, este que por sinal é só uma notação. BPMN é só uma notação padronizada para representação de processos. Não é um componente obrigatório na sua solução SOA.
E cade os requisitos?
Não adianta de nada entender os princípios de SOA e saber como resolver tecnicamente se os requisitos não forem concebidos sobre esse paradigma. Você precisa pensar como representar os processos e como fazer o mapeamento dos processos para os casos de uso por exemplo.
O Seu analista tem que pensar SOA também! Se não é muito provável que você acabe fazendo um design muito ruim e no final acople as coisas e se isso acontecer do que adiantou toda a tranqueira de tecnologias e consultorias sobre SOA?
Precisamos de BPMN e orquestração?
Em muitos casos eu acredito que o ganho se utilizar esse tipo de solução não valha a pena. Por que você deve conhecer bem os processos de negocio, essa é uma tarefa de analise, você tem que ter bons analistas para fazer uma analise boa do processo. Depois vem o mais difícil balancear as responsabilidades dos processos com os serviços.
No final das contas tudo é sobre responsabilidades. Do que ainda ter uma notação padrão que é o caso do BPMN e ter orquestração se a complexidade está nos cenários alternativos do processos e no final das contas o processos principal muitas vezes representa só 5% da complexidade total?
Não adianta nada usar isso tudo se o acoplamento vai continuar. Você tem que ter uma equipe de design e arquitetura e analise muito bom para fazer que isso funcione de maneira efetiva.
Então não devo usar SOA?
Em muitos cenários não deve mesmo. Em outros cenários, corporativo e de mais de um sistema com equipes de boa qualificação SOA pode ser uma excelente solução corporativa mas não se esqueça de que tudo tem um custo.
Todos querem SOA mas muito poucos sabem o que de facto SOA é e quando deve ser utilizada. Os acadêmicos já não aguentam mais trabalhos de conclusão sobre SOA. Não era de se esperar o contrário. Eu gosto de SOA e particularmente acredito ser uma boa solução em alguns cenários, porem cada vez mais SOA é banalizado e empacotado por vendedores como a ultima solução para todos os seus problema de software.
Fazem mais de 30 anos e ainda não conseguimos fazer sistemas que tenham baixo acoplamento e alta coesão. Mas cada vez mais soluções prontas são vendidas com a promessa de resolver todos os seus problemas.
O que é SOA?
SOA é um estilo de arquitetura corporativa. Quero frisar o corporativa aqui, por que se você vai desenvolver uma loja virtual ou algo para uma pequena empresa você não precisa de SOA, muito provavelmente o custo não irá ser pago pelos benefícios visto o tamanho da empresa.
SOA não é um conjunto de tecnologias!
Para fazer SOA não é necessário usar WebServices. Muito menos BPMN. Muitas pessoas acham que se usar WEBservices e/ou BPMN booom você tem um sistema SOA e tudo sera melhor. Negativo!
SOA não é para um sistema isolado!
Se você tem só um sistema e não tem prospectiva de ter outros tão cedo não há por que utilizar SOA, nesse caso você só estará dispersando recursos e adicionando risco e complexidade ao seu projeto. SOA é melhor aproveitado quando você tem dois sistemas ou mais e está em um contexto corporativo.
Começando tudo errado!
As empresas começam usando SOA de maneira errada. Por que para começar a implantação vem muitas vezes de um Diretor de TI, é verdade SOA esta na moda entre os diretores de TI. E na verdade isto deveria vir dos Arquitetos da Empresa não dos gerentes. SOA é uma solução arquitetural e tem que vir de um arquiteto.
Não é o diretor de TI que sabe se os colaboradores estão maduros o suficiente para usar SOA, novamente as pessoas se preocupam muito as coisas que não são criticas e as cosias criticas são deixadas de lado.
Primeira preocupação com SOA: Como implementar
Essa é a primeira cosia que as pessoas se perguntam e isso é errado. Na verdade primeiro devemos nos preocupar em o que é SOA e se precisamos de SOA. Muitas vezes não se precisa de SOA, mas o modismo das consultorias acaba ganhando as vezes.
Fique muito preocupado se o seu diretor de TI ou seu gerente quiser usar uma solução SOA, por que novamente se isso não veio de um arquiteto sensato, muitos problemas viram!
São princípios
SOA é sobre princípios não tecnologias. São práticas e hábitos de desenvolvimento de sistemas que se seguidos vão fazer com que seus sistemas conversem de forma mais efetiva e você reaproveite muito melhor seus componentes transformando eles em assets corporativos de verdade.
Esses princípios de certa forma se transformam em um novo paradigma. Como toda paradigma leva tempo até ser quebrado. Logo você deve se preocupar inicialmente nos princípios e depois como implementá-los.
Sim você pode usar WebServices, mas isso é um detalhes de implementação que é secundário, não é o ponto mais importante. O ponto mais importante é que você tenha consciência do que está fazendo, usar por usar é pior do que não usar em muitos casos!
A Definição de SOA
O Pessoal do Open Group vem trabalhando nisso. dito que eles estão no caminho certo. O problema é que a maioria das empresas si quer conferiu esse material.
O Nível de cada coisa
As coisas estão em níveis. SOA está em um nível de abstração muito mais alto do que WebServices, SCA, EIP e BPMN, este que por sinal é só uma notação. BPMN é só uma notação padronizada para representação de processos. Não é um componente obrigatório na sua solução SOA.
E cade os requisitos?
Não adianta de nada entender os princípios de SOA e saber como resolver tecnicamente se os requisitos não forem concebidos sobre esse paradigma. Você precisa pensar como representar os processos e como fazer o mapeamento dos processos para os casos de uso por exemplo.
O Seu analista tem que pensar SOA também! Se não é muito provável que você acabe fazendo um design muito ruim e no final acople as coisas e se isso acontecer do que adiantou toda a tranqueira de tecnologias e consultorias sobre SOA?
Precisamos de BPMN e orquestração?
Em muitos casos eu acredito que o ganho se utilizar esse tipo de solução não valha a pena. Por que você deve conhecer bem os processos de negocio, essa é uma tarefa de analise, você tem que ter bons analistas para fazer uma analise boa do processo. Depois vem o mais difícil balancear as responsabilidades dos processos com os serviços.
No final das contas tudo é sobre responsabilidades. Do que ainda ter uma notação padrão que é o caso do BPMN e ter orquestração se a complexidade está nos cenários alternativos do processos e no final das contas o processos principal muitas vezes representa só 5% da complexidade total?
Não adianta nada usar isso tudo se o acoplamento vai continuar. Você tem que ter uma equipe de design e arquitetura e analise muito bom para fazer que isso funcione de maneira efetiva.
Então não devo usar SOA?
Em muitos cenários não deve mesmo. Em outros cenários, corporativo e de mais de um sistema com equipes de boa qualificação SOA pode ser uma excelente solução corporativa mas não se esqueça de que tudo tem um custo.
