SOA para pessoas normais

Navegando pela Internet e pesquisando um pouquinho sobre SOA você encontrará coisas como “um paradigma para organização e utilização de capacidades distribuídas (...)”, “uma estratégia de TI que utiliza funções contidas em aplicações coorporativas (...)”, ou ainda “empacotando funções de negócio de aplicações novas e existentes (...)”.

Eu até que gosto de uma boa parte dessas definições, e algumas delas cumprem particularmente bem seu objetivo: definir ou explicar Service Oriented Architecture de um ponto de vista técnico. Técnico demais. Portanto, apenas para começar, que tal falarmos um pouquinho em português?

A nossa vida cotidiana apresenta uma infinidade de bons exemplos para ilustrar o tema. É possível que nunca tenha analisado por este ângulo, mas você é 100% orientado a serviços!

Por exemplo: se o motor do seu carro enguiçar, você provavelmente irá levá-lo a um mecânico para os devidos reparos; praticamente todos nós, com alguma regularidade, vamos ao cabelereiro ou ao barbeiro; e se eu quiser que este texto seja traduzido para o mandarin, certamente vou procurar um tradutor especializado.

Todos nós, mesmo sem perceber, nos utilizamos constantemente de serviços oferecidos por outras pessoas ou empresas. É simplesmente impossível para qualquer pessoa viver sem fazê-lo. Apenas para ficar nos exemplos anteriores, eu tenho algumas noções rudimentares de mecânica, mas não sei cortar cabelos nem tenho domínio do idioma chinês.

Os princípios básicos de SOA são os mesmos necessários à utilização de serviços na nossa vida cotidiana:

• Não precisamos conhecimento específico nem entender os detalhes para utilizá-los.

• Basta combinar o que deve ser feito e nossa interferência será mínima ou nenhuma

• Usamos uma composição de diversos serviços para um objetivo maior – jardineiro, carpinteiro e pedreiro, por exemplo, podem ser usados em harmonia para recriar um espaço.

• Cada um desses fornecedores presta um serviço melhor do que faríamos por conta própria.

• Vários deles podem ser encontrados consultando, por exemplo, as páginas amarelas.

Afinal de que forma isso pode me ajudar?

Chegando até aqui, você provavelmente estará se fazendo algumas perguntas: “De que forma isso pode me ajudar? Por que todos os fornecedores apresentam SOA em seus portfolios (produtos, estratégias, consultoria, serviços, etc.)? O que eu devo comprar? Por onde eu começo? Preciso mesmo começar?”.

Para começarmos a encontrar respostas para essas perguntas, vamos fazer um pequeno exercício.

Primeiro tente relacionar mentalmente o maior número de aplicações na sua organização que você conseguir, pelo menos as mais importantes para o funcionamento do negócio. Não importa se elas são desenvolvidas em casa ou adquiridas de fornecedores, se são grandes ou pequenas ou ainda qual a tecnologia utilizada.

Agora imagine quanto tempo, dinheiro e esforço foram investidos ao longo dos últimos anos com o objetivo de integrá-las, de fazer com que essas diversas aplicações conversem entre si (sistemas de produção, folha de pagamento, RH, contabilidade, logística, sistemas de segurança, etc.).

Você consegue perceber? Embora isso nem sempre seja abordado desta forma, cada aplicação tem como objetivo oferecer um ou mais serviços ao negócio, uma ou mais engrenagens do motor.

Ao olhar para nossas aplicações sob esta nova ótica, o objetivo final é conseguir tratar cada uma dessas funções de negócio como um serviço, fazendo com que eles funcionem de forma integrada para criar o grande motor.

Aplicando esse conceito ao desenvolvimento de novas aplicações, o resultado final é que elas serão, na verdade, formadas por diversos serviços menores. Assim será mais fácil compô-los de forma a criar novas ofertas para seus clientes ou reagir a fatores externos – troca de legislação, aquisição de outros softwares ou empresas, entrada em novos mercados.

Para aplicações já existentes, conseguir identificar as funções de negócio e transformar pelo menos algumas dessas funções em serviços mais independentes permitiria integrá-las mais facilmente, ou até mesmo uma substituição futura com um impacto infinitamente menor.

Boas e más notícias.

A má notícia é que, ao contrário do que vários fornecedores costumam apregoar, não é possível construir uma plataforma SOA simplesmente comprando um “Super SOA Integrator Tabajara” direto da prateleira.

Voltando ao exemplo que usamos anteriormente, você faria o conserto do motor, o corte de cabelo e a tradução de textos com a mesma pessoa? É claro que não. Uma das vantagens dessa abordagem é fazer uso dos melhores serviços disponíveis em cada especialidade.

Mas a boa notícia é que você provavelmente já faz uso de tecnologias que, de alguma forma, implementem conceitos de SOA e nem percebeu. Os fornecedores de sistemas operacionais, bancos de dados e ERPs já utilizam conceitos e infraestrutura de software com essas características há algum tempo.

É possível que você tenha pelo menos uma parte do que precisaria para começar dentro de casa mesmo. Além disso, muitos componentes podem ser encontrados nas modalidades de software livre – nesse caso o grande trabalho é separar o joio do trigo, identificar aqueles com chance de continuidade e escapar das armadilhas relacionadas à falta de mão de obra especializada.

Qual a melhor estratégia? Por onde eu começo?

Uma das máximas que eu costumo citar com alguma freqüência é que “se complicou é porque você está fazendo errado”. Repito isso há tanto tempo que, sinceramente, não sei extamente onde aprendi. Mas sempre tenho a impressão de que há uma tendência à complicação desnecessária em nossa área.

Tentando o raciocínio mais simples possível, eu diria o seguinte: não vá com tanta pressa, identifique algumas funções úteis e que não sejam grandes demais, faça um piloto, descarte qualquer opção que não traga valor imediatamente, descarte qualquer coisa que não traga visibilidade, use a experiência dos outros a seu favor.

Ir com um pouco de calma na primeira iniciativa vai ajudá-lo a aprender durante o processo. Quando aceleramos demais o passo ao caminhar pela primeira vez em algum lugar, a tendência é que não lembremos os detalhes ao longo do caminho.

Além disso, estabelecer um escopo reduzido na realização de um piloto, mas que tenha valor para o negócio, irá ajudar a assimilar a nova cultura e gerar conhecimento para ser usado nos projetos seguintes. Ao mesmo tempo permite uma entrega em curto espaço de tempo, arma valiosa provar valor e conquistar novos investimentos.

Descartar tudo que não traga valor imediatamente e também qualquer coisa que não traga qualquer visibilidade garantem que a adoção de um novo paradigma seja percebida positivamente.
 
Projetos de pouco ou nenhum retorno ou para os quais não conseguimos demonstrar valor não são argumento para conquista de investimentos simplesmente porque não merecem investimento algum.

Cuidados essenciais.

Para encerrar, lembrando que as aplicações baseadas em SOA são, na verdade, composições de diversos serviços, portanto seguem alguns cuidados e observações para quem quiser colocar a mão na massa:

• Tenha cuidado com o exagero. Não venda SOA como uma bala de prata, que seria capaz de resolver todos os problemas. Isso não é verdade.

• A disponibilidade e o nível de serviço da aplicação como um todo serão semelhantes aos de seu pior componente. Isso significa que, se você pretende atingir 99,99% de disponibilidade, isso deve ser feito para cada um dos serviços.

• E se der certo? Lembre-se de que, ao construir um serviço de sucesso, ele poderá ser utilizado por diversas aplicações, portanto deve ser escalável o suficiente para suportá-las.

• Defina bem a governança. Para serviços que atendem diversas aplicações, eventualmente pertencentes a áreas ou fornecedores diferentes, é importante entender quem tomará as decisões a respeito desse serviço – itens a serem incluídos na próxima versão, investimentos em infraestrutura, responsabilidades de suporte, divisão dos custos, etc.

• Coordenação de releases. Em uma aplicação comum, fazer liberações ou instalar novas versões em geral atinge apenas uma parcela dos usuários. Isso pode não ser verdade para serviços utilizados por diversas aplicações.

• Suporte à produção. Identificar e solucionar problemas em ambiente de produção tende a ser mais complexo, já que os diferentes serviços podem rodar utilizando tecnologias distintas e em lugares diferentes.

Fabiano Corrêa Pereira é diretor da ADP Brasil.