ABC da SOA

Como sei se devo adotar uma estratégia SOA?
Sendo uma estratégia arquitetural, SOA envolve muito mais do que o mero desenvolvimento de software. A criação de uma arquitetura baseada em um portfólio de serviços demanda que os CIOs elaborem um “case” convincente para uma arquitetura corporativa, uma metodologia de desenvolvimento centralizada e uma equipe centralizada de gerentes de projeto, arquitetos e desenvolvedores. Também requer um CEO e uma equipe executiva dispostos, que preparem o terreno para que o pessoal de TI possa mergulhar em processos core da empresa. Entender estes processos e conquistar adesão para o compartilhamento corporativo são a pedra angular de uma transformação do negócio baseada em SOA.
Governança é vital. Para que os serviços sejam reutilizados na empresa, tem de haver uma metodologia de desenvolvimento de software única e centralizada de modo que áreas diferentes não criem o mesmo serviço de maneiras diferentes ou usem conectores incompatíveis. Tem que haver um repositório centralizado para que os desenvolvedores saibam onde procurar serviços — e TI saiba por quem eles estão sendo utilizados. Os serviços têm de ser bem documentados para que os desenvolvedores saibam para que eles servem, como integra-los e as regras para usá-los. Algumas empresas, por exemplo, cobram taxas de utilização dos serviços e criam acordos de performance para garantir que os serviços funcionem bem e não sobrecarreguem a rede corporativa.
A maioria das empresas que avançou no caminho para SOA criou um grupo de arquitetura centralizado para escolher processos que serão capacitados para serviço e consultar áreas diferentes da empresa para criar os serviços específicos. O grupo centralizado também cria um mecanismo conveniente para governança. Se todas as solicitações de serviço têm de passar pelo grupo de arquitetura, as metodologias de desenvolvimento de serviço, os projetos e os acordos de performance podem ser gerenciados mais facilmente.
As empresas que tiveram mais êxito com SOA até agora são as que sempre tiverem êxito com tecnologia: grandes empresas com grandes budgets para TI cujo negócio é baseado em tecnologia (serviços de telecomunicação e financeiros). Elas também tendem a ter líderes de negócio envolvidos com a área de TI e dispostos a apoiar seus projetos. Para empresas sem estas vantagens, SOA talvez não seja tudo o que promete.
Para empresas menores, empresas que apostaram alto em pacotes de aplicativos integrados e empresas que já adotam estratégias sólidas de integração de aplicativos, SOA não tem a ver com “quando”, mas com “se”. Os CIOs têm de ser cuidadosos porque, na arquitetura orientada a serviços, os elementos “desenvolvimento de serviço” e “planejamento de arquitetura” são distintos, porém não independentes — precisam ser considerados e executados paralelamente. Serviços que são criados isoladamente, sem levar em conta as metas de arquitetura e de negócio da empresa, podem apresentar pouco potencial de reutilização (um dos benefícios mais importantes da SOA) ou fracassar por completo.

Quais as vantagens da SOA?
Antes de mais nada, os benefícios de da arquitetura orientada a serviços devem ser contextualizados. Se sua empresa não for grande ou complexa, isto é, se não tiver mais de dois sistemas primários que exijam algum nível de integração, é improvável que o modelo proporcione grandes benefícios. Em meio a todo o hype atual em torno da SOA, esquece-se facilmente que a metodologia de desenvolvimento em si não traz vantagens – é o efeito que ela tem sobre uma infra-estrutura redundante e complexa que o faz. Os arquitetos dizem que a criação de um bom aplicativo orientado a serviços envolve mais trabalho do que a tradicional integração de aplicativos. (Pesquisas mostram que SOA está sendo usada para integração tradicional de aplicativos na maioria das empresas.) Assim, o desenvolvimento da SOA gera um custo inicial extra. Para que este trabalho produza benefícios, portanto, SOA tem que eliminar trabalho em outro ponto qualquer, já que a própria metodologia não gera benefícios para o negócio. Assim, o primeiro passo é descobrir se existem aplicativos redundantes e mal integrados que poderiam ser consolidados ou eliminados como resultado da adoção. Se este for o caso, então há benefícios potenciais.
Para entender o panorama geral dos benefícios apregoados por SOA, você precisa examiná-lo em dois níveis: primeiro, as vantagens táticas do desenvolvimento orientado a serviços e, segundo, as vantagens da SOA como estratégia de arquitetura global.

Vantagens do desenvolvimento orientado a serviços:
1. Reutilização de software. Se o pacote de códigos que constitui um serviço tiver o tamanho e o escopo certos (um grande “se”, dizem os veteranos em SOA), então ele poderá ser reutilizado da próxima vez que a equipe de desenvolvimento precisar de uma função específica para um novo aplicativo que queira desenvolver. Digamos que uma empresa de telecomunicações tenha quatro divisões diferentes, cada qual com seu próprio sistema para processar pedidos. Todos estes sistemas executam determinadas funções similares, como verificações de crédito e buscas de registros de clientes. Mas, tendo em vista que cada sistema é altamente integrado, nenhuma destas funções redundantes pode ser compartilhada. O desenvolvimento orientado a serviços coleta o código necessário para criar uma versão de “verificação de crédito” que possa ser compartilhada pelos quatro sistemas. O serviço pode ser uma porção de software totalmente nova ou um aplicativo composto, consistindo de código de alguns dos sistemas ou de todos eles. De qualquer forma, o ‘composite’ é envolto por uma interface que oculta sua complexidade. Da próxima vez que os desenvolvedores quiserem criar um aplicativo que exija verificação de crédito, vão criar um link simples para o novo aplicativo. Eles não precisam se preocupar em conectar aos sistemas individuais — na realidade, nem precisam saber como o código foi incluído ou de onde ele vem. Só precisam criar uma conexão para ele.
Em uma empresa que desenvolve constantemente sistemas novos que se apóiam em funcionalidade similar — uma empresa seguradora com muitas divisões diferentes, cada uma com produtos ligeiramente diferentes, por exemplo, ou uma empresa que está sempre adquirindo outras — o tempo economizado nas tarefas de desenvolver, testar e integrar esta  mesma funcionalidade de software é uma vantagem.
Mas a reutilização não é garantida. Se desenvolvedores em outras partes da empresa não souberem que os serviços existem ou não confiarem que eles são bem construídos, ou se as metodologias de desenvolvimento variarem dentro da empresa, os serviços podem definhar e não se repetir. As empresas adeptas da reutilização desenvolveram mecanismos de governança — equipes de desenvolvimento centralizadas, metodologia única de desenvolvimento e repositórios de serviços — para aumentar suas chances de reutilização.