Processo de Definição de Serviços

JBOWS ("Just a Bunch of Web Services" ou em uma tradução livre: "Só um monte de Web Services"). Foi assim que o analista Joe McKendrick chamou pela primeira vez em 20/9/05 no famoso "post" do Werservices.Org, projetos SOA conduzidos sem qualquer formalismo, gerenciamento, testes específicos e tipicamente orientados a tecnologia. JBOWS Architecture. E não Service-Oriented Architecture... Vale a pena a leitura do artigo.

Uma das conclusões diretas, então, é a necessidade de um processo formal para desenvolvimento de serviços cobrindo desde análise de requerimentos de negócio, modelagem e desenho de serviços e o próprio desenvolvimento e entrega dos mesmos.

Um exemplo de processo de desenvolvimento de serviços está abaixo:

O SDP ("Service Definition Process") possui três "inputs":

• "Blueprints", padrões de especificações, "frameworks", etc já existentes na empresa que eventualmente serão adaptados pelo Serviço em definição;
• Requerimentos de negócio para o Serviço
• Requerimentos técnicos e situação atual do legado

A análise de "gap" é feita pelo SDP. Como "output" temos:

• SLAs ("Service Level Agreements") e OLAs ("Operational Level Agreements") para o Serviço
• Custos da implementação do Serviço envolvendo por exemplo, atualização do legado, software e/ou hardware adicionais, novos desenvolvimentos, etc
• Documentos de Arquitetura: especificações técnicas para a construção e entrega do Serviço

Mais uma vez este é somente um exemplo para condução do Processo de Definição de Serviços em um nível baixo de detalhe. Há diversos outros disponíveis e que podem ser tomados como base para um processo específico à empresa. O "site" SOA Methodology de Thomas Erl descreve processos sólidos e detalhados para Análise e Desenho de Serviços. O "site" baseia-se principalmente em dois de seus livros: Service-Oriented Architecture - Concepts, Technology, and Design (mais precisamente seus capítulos 10 a 16) e SOA - Principles of Service Design.

Ambos os livros descrevem duas aproximações para especificação e entrega de serviços: "Bottom-Up" e "Top-Down". O "Principles of Service Design" possui uma ilustração confrontando os seus pontos positivos e negativos.

Em "SOA - Concepts, Techonology, and Design" há o detalhamento das estratégias. Diria que a estratégia "Top-Down" (pág. 363) é "purista": a partir do recolhimento dos requerimentos de negócio, percorre o processo de identificação e especificação de serviços, com análise de "gap" do legado, impacto nos serviços existentes e finalmente a sua implementação.

Já a estratégia "Bottom-Up" (pág. 366) não seria, na verdade, uma estratégia real para atingir SOA. Se por um lado, lança mão de tecnologias como Web Services para encapsular funcionalidades de legado e assim maximizar o seu uso, por outro, é um convite à JBOWS Architecture.

Erl propõe ainda e estratégia "Agile" (pág. 370), ou "meet-in-the-middle", com a combinação de ambas as anteriores.

Riscos potenciais:

• "Top-Down":
• Precisa de patrocínio corporativo.
• Pode resultar somente em papel.
• Pouca visibilidade tecnológica pode incorrer em análises não completas de custos
• "Bottom-Up":
• Projeto SOA transformando-se em Projeto de Integração ou SOI
• Resolução de problemas tecnológicos somente, sem aderência às demandas de negócio
• JBOWS

Por fim, é importante notar que, independentemente da estratégia adotada, um dos pólos do processo é a Governança SOA, tema complexo que fica para outro "post".