Requisitos em SOA

Neste artigo veremos os principais aspectos dos requisitos de negócio de projetos SOA, como definir estes requisitos e as formas mais práticas de identificar serviços e requisitos para uma gestão orientada a serviços.

Auxiliar na condução da coleta de requisitos de Projetos SOA e tornar claros os benefícios de se ter uma estratégia para identificação de serviços e um inventário de serviços que reflita os processos de negócio da empresa.

Orienta a criação de um processo de elicitação, documentação e modelagem de requisitos de negócio voltado a projetos que abordem a estratégia SOA. Auxilia no esclarecimento de algumas abordagens de identificação de serviços e formação de processos de negócio.

Os projetos Service-Oriented Architecture (SOA) quando comparados a projetos de desenvolvimento tradicionais na área de TI, estão expostos aos mesmos (ou até maiores) desafios no que implica a elicitação e a modelagem de requisitos. Para projetos ditos “tradicionais” existe uma quantidade significativa de pesquisas e estudos que identificam que a definição inadequada de requisitos é a principal responsável por grande parte dos erros detectados ao longo do processo de desenvolvimento de sistemas [4].

As atividades de elicitação e modelagem de requisitos necessitam de um conjunto de habilidades únicas, pois estas atividades são mais que técnicas, envolvendo muitas vezes exercícios de sensibilidade. Por exemplo, não se pode evitar o fator humano – as pessoas mudam de opinião sobre o que querem. É irreal pensar que seja possível capturar 100% das necessidades ou exigências, já que na maioria das vezes elas mudarão. Um bom analista de requisitos deve envolver os stakeholders no processo e criar um ambiente onde fique claro o valor dos requisitos e a importância da sua precisão. O analista deve ainda demonstrar a extrema importância da participação dos stakeholders no processo de documentação dos requisitos e torná-los responsáveis pelas alterações ou omissões na documentação gerada.

Outros estudos mostram que a não eliminação de erros durante a especificação torna mais difícil e dispendioso o desenvolvimento de uma aplicação, à medida que o ciclo de vida avança para etapas posteriores [2], no entanto fica a questão: esses estudos podem servir de base para projetos SOA?

Em meio a uma estratégia SOA algumas empresas investem muito em tecnologia, porém este está longe de ser o maior problema neste tipo de projeto. Na verdade, um projeto SOA corre o sério risco de se tornar um desperdício de tempo e dinheiro, mesmo contando com uma arquitetura eficiente e tirando proveito das mais recentes tecnologias de mercado.

Na prática, nota-se que o verdadeiro diferencial entre sucesso e fracasso em uma abordagem orientada a serviços está em dar atenção especial aos requisitos das pessoas envolvidas nessa abordagem. Os requisitos de um projeto SOA podem ser divididos em dois grupos: requisitos de negócios e requisitos técnicos, e ambos devem ter uma atenção diferenciada desde o início do projeto.

Neste contexto, este artigo concentra-se nos aspectos dos requisitos de negócio dos projetos SOA, em como definir estes requisitos e as formas mais práticas de identificar serviços e capturar requisitos para uma gestão orientada a serviços. Em um próximo artigo pretende-se demonstrar como definir os requisitos técnicos, que são outra parte essencial de uma Arquitetura Orientada a Serviços.

Por onde começar?

Uma boa implementação SOA pode trazer um excelente resultado para uma organização. Um projeto implementado de uma forma eficiente pode obter um alto nível de reuso em futuros projetos, podendo chegar até a 80% [5], sendo esta uma taxa surpreendente se comparada com uma arquitetura tradicional. No entanto, a implantação de um cenário SOA em uma organização não é uma tarefa fácil, além do comprometimento dos funcionários da organização para que o projeto possa ser executado com sucesso, é extremante importante a divisão do projeto por etapas.

Uma abordagem SOA traz consigo uma grande quantidade de riscos, pois nem tudo é só agilidade. Quando se fala em SOA pensa-se em uma modelo projetado para suportar mudanças, flexível, rápido (time to market) e de baixo custo de implementação (considerando apenas seu reuso). Por outro lado tem-se os riscos devido a complexidade: duplicidade de código, falta de visibilidade dos serviços, dificuldade no reuso, instabilidade, identificação dos serviços e isso é só o começo. Para tornar todos estes riscos gerenciáveis é preciso mitigá-los.

Um erro inicial, muito comum nas organizações, é tentar alterar todo o cenário de desenvolvimento de software de uma só vez. Essa é uma estratégia que traz sérios problemas relacionados à cultura da organização. Outro fator importante é que normalmente quando se tenta fazer uma mudança muito brusca em grande escala, as chances de se conseguir uma migração tranquila são mínimas, pois passam a existir muitos sistemas para se trabalhar ao mesmo tempo e dessa forma não é possível concentrar os esforços em cada detalhe necessário.

Uma solução que é bem aceita pela a maioria dos profissionais (e autores da área, por mais incrível que pareça) é a concepção dos projetos em fases: primeiro se escolhe alguns sistemas menos críticos como prova de conceito (POC), realiza-se a migração e observa-se o funcionamento para só depois repetir o mesmo processo para outros sistemas mais complexos.

Definido o projeto, o primeiro passo a ser dado é a identificação dos serviços. Para isso, é fundamental definir qual estratégia será utilizada para essa identificação e quais os requisitos de negócio mais importantes para cada serviço identificado.

Identificação dos serviços

Inicialmente os serviços precisam ser isolados de acordo com seu impacto para o negócio, isto é, os serviços devem ser significativos o suficiente para demonstrar valor e benefícios gerados a partir de um roteiro SOA de longo prazo. Existem duas principais estratégias que podem ser usadas para o processo de identificação [1]:

• Top-down: A estratégia “Top-Down” é mais intuitiva, pois é realizada diretamente a partir dos requisitos de negócio. O processo de identificação e especificação de serviços se baseia na análise dos sistemas legados e em possíveis serviços já existentes para elaborar uma solução;
• Bottom-up: a estratégia “Bottom-Up” 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 reuso, por outro, é um convite ao que o autor Joe McKendrick [3] chamou de JBOWS, (“Just a Bunch of Web Services” ou simplificando “Só um monte de Web Services”) que caracteriza projetos SOA conduzidos sem qualquer formalismo, gerenciamento, testes específicos e tipicamente orientados apenas a tecnologia. Na Tabela 1 são apresentados os principais riscos na utilização das duas estratégias.

Em uma solução intermediária e bem mais realista, Thomas Erl propõe uma abordagem “meet-in-the-middle”, com a combinação de ambas as estratégias anteriores. Esta abordagem sugere uma análise de prioridades durante o processo de identificação dos serviços e a definição de um modelo de inventário de serviços. A recomendação é que os serviços de alta prioridade sejam entregues com antecedência e em paralelo exista um monitoramento do ambiente de utilização dos serviços, pois as informações coletadas por essa monitoria servem de base para criação de novos serviços ou manutenção dos existentes.

Requisitos para um serviço

Esta seção descreve as categorias de requisitos de negócio e o processo que se pode seguir para reunir estes requisitos para um serviço em um projeto SOA. Em um sentido amplo, as categorias mais importantes para elicitar requisitos para serviços são listadas abaixo (lembre-se, este artigo enfoca apenas os requisitos de negócio, os requisitos técnicos para um serviço serão discutidos em um próximo artigo):

• Visibilidade: Esta é uma das categorias que é compartilhada tanto por requisitos técnicos como por requisitos de negócio, e responde a seguinte pergunta: “Como um consumidor de um serviço consegue encontrá-lo e adquire conhecimento de como usá-lo?”. Em termos de negócio é importantíssimo que o consumidor de um serviço tenha facilidade em descobrir um serviço existente em um inventário de serviços;
• Capacidades: Esta categoria deve esclarecer a granularidade usada na identificação das capacidades disponíveis em um serviço (fazendo uma analogia com a Orientação a Objetos, uma capacidade para um serviço é como um método para uma classe). Um serviço pode oferecer várias capacidades, serviços mais granulares possuem capacidades mais especificas, enquanto que os menos granulares possuem capacidades mais genéricas. A descrição das capacidades de um serviço deve ser clara e precisa, já que um consumidor de um serviço não deve ter dúvidas sobre qual função irá fornecer o serviço requerido, e qual problema do negócio ele pretende resolver;
• Interação: Esta categoria define requisitos sobre como será a interação de um serviço com o aplicativo que trocará informações com esse serviço. Uma premissa básica é que um serviço deve ser fácil de usar. Ao projetar um serviço, os desenvolvedores devem facilitar para consumidores o seu uso. O consumidor, após identificar um serviço em um inventário, buscará uma forma de utilização prática deste serviço em sua aplicação. Quanto mais fácil e rápida for a transição entre identificar e obter os benefícios de um serviço, melhor e mais vezes o serviço tende a ser utilizado;

• Informação: Esta categoria deve conter requisitos que definam quais os parâmetros de entrada e saída para um serviço e o tratamento de exceções. A interface de um serviço deve ser projetada como um contrato, um acordo entre consumidor e fornecedor de forma que, se o consumidor cumprir sua parte (pré-condições), o serviço garante o resultado especificado (pós-condições) com algumas exceções também especificadas:

  • Pré-condições: são os parâmetros de entrada e os estados do sistema que devem ser validados antes da “execução” do serviço;
  • Pós-condições: especificação do estado do sistema (por exemplo, elementos criados ou destruídos, atributos e relacionamentos alterados) ou os parâmetros de saídas garantidos/válidos após a “execução” do serviço. Em outras palavras, o resultado esperado da “execução” do serviço;
  • Exceções: todas as situações em que a “pós-condição” não pode ser garantida, mesmo com a “pré-condição” atendida.
• Composição: Esta categoria deve conter requisitos que definam relações entre os serviços a serem construídos e suas capacidades. Uma das principais características de um serviço, que deve ser perseguida desde o momento da especificação, é a sua capacidade de se compor com outros serviços. A atomicidade e/ou granularidade de um serviço pode depender de sua estratégia de descobrimento. Uma abordagem “top-down“ identificará os processos de negócios, sendo que cada atividade pode ser desmembrada em subprocessos. Por outro lado, em uma abordagem “bottom-up“, os serviços vão sendo expostos por meio das funcionalidades dos sistemas legados existentes, onde a granularidade e a atomicidade destes serviços vão sendo refinadas até que os mesmos possam ser compostos em processos de negócios.

Agora que já se sabe o tipo de informação necessária para capturar, é importante falar sobre o processo. Em um mundo SOA é importante identificar os provedores de serviços ou aplicativos, para se descrever em termos comerciais, qual a utilidade real de cada serviço. Infelizmente, nem sempre se conhece todos os provedores de um serviço. Neste caso, é preciso localizar os consumidores de serviços (partes interessadas do negócio para quem está sendo criado esse serviço) e pedir que eles descrevam o que querem que o serviço realize. Apesar dessa descrição ser imprescindível, não se pode tentar chegar a todos os consumidores em potencial, isso não é viável.

Do ponto de vista do processo, os consumidores de serviços devem ser capazes de descrever o serviço a partir de requisitos funcionais e não funcionais. O primeiro passo é capturar requisitos a partir das categorias descritas anteriormente, utilizando qualquer metodologia ou ferramenta de requisitos, no entanto, a opção por usar casos de uso é altamente recomendável.

Em um projeto SOA, é preciso envolver de forma ativa todos os stakeholders envolvidos nos serviços a serem disponibilizados, pois este é um dos fatores de grande risco para o projeto. Ao tentar vender o conceito de SOA, não se deve procurar apenas o pessoal técnico, procurar os executivos corporativos dos setores de vendas e marketing, por exemplo, torna muito mais fácil a construção de aplicações corporativas para o setor de tecnologia. Todas as informações que forem coletadas devem ser documentadas de alguma forma. Uma dica inicial é adotar um formato padrão para descrever os casos de uso e um pequeno manual de “boa escrita”, pois são soluções que funcionam e dão menos dor de cabeça.

Os gerentes precisam entender o conceito fundamental de serviços, como pensar seus negócios e processos de negócio em termos de serviços, bem como identificar quais serviços podem ser reutilizados através de funções de negócios. Em um cenário ideal, nesse ponto existiria a conjunção entre os projetos SOA da empresa e os projetos BPM (Business Process Management), então o detalhamento dos casos de uso poderia ser completado por meio de Diagramas de Atividades ou BPDs (Business Process Diagram), como sugere a Figura 1.

Vale dizer que BPM é um conceito que tem sua origem em uma necessidade gerencial, o qual pode ser suportado por ferramentas de TI com o intuito de tornar mais ágil a gestão dos processos. O público-alvo de BPM inclui desde pessoas ligadas à gestão de negócios até profissionais de TI envolvidos na implantação de ferramentas de apoio. Um projeto SOA pode se beneficiar desses conceitos para atender de forma muito mais direta as necessidades do negócio.

Portanto, é evidente que uma empresa conhecedora de seus processos – e que preferencialmente já tenha uma iniciativa de BPM – estará bem melhor preparada para fazer uma definição mais sólida do seu inventário de serviços. No caso dela não possuir esse mapeamento, será necessário fazer a definição dos serviços recuperando a documentação de sistemas ou, nos casos mais extremos, analisando-se o próprio código-fonte dos sistemas. Tratando-se, sem dúvida, de opções bastante indesejáveis.

Outro benefício que uma iniciativa BPM traz para um projeto SOA é a possibilidade de tornar mais tangíveis os objetivos do projeto. Em algumas empresas, as áreas de negócio tratam os benéficos de SOA como indiretos, e impõe restrições no momento de aprovar investimentos nesta área. De fato, segundo o Gartner Group, o principal motivo de insucesso das iniciativas de SOA é a dificuldade em justificar o investimento para as áreas de negócio.

Apesar de SOA e BPM, quando combinados, serem uma opção muito interessante e claramente vantajosa em termos de negócio, cada uma tem sua própria complexidade e são soluções diferentes para problemas diferentes.

Quais os requisitos de uma estratégia SOA?

Deve-se, de antemão, estar ciente que SOA envolve muito mais do que o mero desenvolvimento de software. A criação de uma arquitetura baseada em um inventário de serviços demanda uma metodologia de desenvolvimento centralizada e uma equipe organizada de gerentes de projeto, arquitetos e desenvolvedores. Também requer uma equipe executiva solícita, que prepare o ambiente para que o pessoal de TI possa esmiuçar os detalhes dos processos da empresa. A compreensão destes processos é o núcleo de uma transformação do negócio baseada em SOA.

Para aumentar a possibilidade de reutilização dos serviços, é ideal que exista uma metodologia de desenvolvimento de software única, centralizada e aplicada na prática, de modo que áreas diferentes não criem o mesmo serviço (e o que é ainda pior) de maneiras diferentes. Como já foi dito, é imprescindível a existência de um inventário centralizado para que os desenvolvedores saibam onde procurar serviços e a área de TI saiba por quem eles estão sendo utilizados. Os serviços têm de ser bem documentados, para que os desenvolvedores saibam sua utilidade, suas formas de integração e as normas para utilização. Existem empresas, por exemplo, que possuem regras tarifárias para a utilização dos serviços e criam métricas de desempenho para garantir que os serviços funcionem bem e não sobrecarreguem a rede corporativa.

Quais os benefícios de um bom processo de requisitos SOA?

Os artefatos de requisitos produzidos a partir de uma estratégia SOA, podem gerar benefícios em termos de documentação não só para o projeto, mas para a empresa como um todo. Na verdade, tais benefícios estão ligados às ações realizadas durante o processo de elicitação, análise e modelagem dos requisitos, tais como:

• Tornar dados acessíveis por meio de uma visão unificada dos negócios;
• Minimizar custos associados à migração da infraestrutura;
• Minimizar a exposição a riscos por meio de análises da qualidade dos dados usados na parametrização dos serviços;
• Aumentar a agilidade da organização, condensando informações estruturadas e não-estruturadas, que podem ser conectadas por meio de aplicativos e processos de negócios.

Porém todos os benefícios de um modelo orientado a serviços devem ser contextualizados. Se uma empresa 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 toda propaganda em torno da SOA, esquece-se facilmente que a metodologia de desenvolvimento não traz em si vantagens, as vantagens são proporcionadas pelo efeito que ela tem sobre uma infraestrutura redundante e com pouca integração.

A criação de um bom aplicativo orientado a serviços normalmente envolve mais trabalho do que integração de aplicativos existentes (atualmente a integração tradicional de aplicativos é o principal projeto SOA em muitas empresas). Assim, um projeto SOA tende a gerar um custo inicial extra e para que este investimento produza benefícios, é preciso eliminar custos em outro ponto qualquer do processo, já que a própria metodologia não gerará benefícios para o negócio. Portanto, o primeiro passo é descobrir se existem aplicativos redundantes e mal integrados que poderiam ser consolidados ou eliminados. Se este for o caso, então podem existir benefícios potenciais.

Conclusão

Neste artigo, viu-se como identificar alguns serviços iniciais como parte de um projeto de SOA, as formas de como elicitar requisitos de negócio para estes serviços e como documentar estes requisitos utilizando técnicas e processos atuais. No próximo artigo, supondo que a prova de conceito (POC) foi bem-sucedida, chegou à hora de lançar um programa SOA generalizado. Para tanto, serão discutidas formas para coletar, gerenciar e comunicar necessidades técnicas, que passam a ser a principal questão na implementação deste tipo de projeto.

Requisitos em SOA – Parte 2

Referências

• [1] Erl, T. “SOA Principles of Service Design (The Prentice Hall Service-Oriented Computing Series from Thomas Erl)”, Prentice Hall PTR, Upper Saddle River, NJ, 2007
  www.thomaserl.com
• [2] Hofmann, H.F. e Lehner, F. “Requirements engineering as a success factor in software projects”, IEEE Software, pp. 58-66 vol. 18, n. 4., 2001
  www.computer.org/portal/web/csdl/abs/mags/so/2001/04/s4058abs.htm
• [3] McKendrick, J. The Rise of the JBOWS Architecture (or Just a Bunch of Web Services
  www.webservices.org/weblog/joe_mckendrick
  /the_rise_of_the_jbows_architecture_or_just_a_bunch_of_web_services.
• [4] STANDISH GROUP. Chaos: pesquisa sobre o desenvolvimento de software e o panorama caótico da indústria de software dos dias de hoje.
  www.standishgroup.com/chaos.html
• [5] Zaidan, P. SOA atinge até 80% do reuso com governança, diz BearingPoint. [S.l.]
  www.decisionreport.com.br