Papéis em SOA - Identificando Serviços
Autor: Deley | Publicado: 2007-09-30T22:04:00-03:00

No post anterior - "Desenvolvimento de Software e SOA"- , foi abordada a importância da utilização de métodos, como SOMA, na identificação de serviços de negócio.O objetivo deste post é exercitar os desafios do desenvolvimento de software, em uma SOA, quanto aos aspectos de comunicação, estabelecimento de responsabilidades e inter-relacionamentos entre papéis, com foco em identificação de Serviços de Negócio.O relacionamento entre os diferentes papéis dentro de SOA é fator fundamental para que Processos e Serviços de Negócio sejam identificados, elaborados e construídos utilizando-se de forma sábia os recursos do projeto. Uma mesma solução pode ser atingida de formas diferentes. Mas se puder ser otimizada, promovendo reuso e definindo corretamente os Serviços de Negócio, o sucesso da solução de um projeto refletirá na empresa dentro de outros projetos.Para não perder o foco - da identificação de serviços - serão explorados apenas aqueles papéis cujas responsabilidades mais se aproximam das atividades de modelagem de negócio, levantamento de requisitos e definição de serviços.Definição e ResponsabilidadesA tabela abaixo apresenta as definições e responsabilidades dos principais papéis, no que se refere a Identificação de Serviços de Negócio, no contexto de uma SOA.        Papel         Definição         Responsabilidade             Cliente         Interessado maior na solução, dono do processo.         Expor necessidades do negócio, gerenciar o processo   de negócio.             Analista de Negócio         Profissional de TI ou de área de Negócio que atua   como a “ponte” entre cliente e TI.         Entender as necessidades do negócio, auxiliar na   modelagem do negócio (desenho, simulação, otimização).             Analista de Requisitos         Profissional de TI que realiza o levantamento dos   requisitos de software.         Entender as necessidades do negócio e como estas se   traduzem em requisitos de software (funcionais e não-funcionais), procurando   identificar serviços em potencial.             Arquiteto de Solução         Arquiteto com foco em integração de aplicações e   identificação de serviços.         Entender as necessidades do negócio quanto a   integração de soluções, reutilização de serviços, procurando identificar os   serviços candidatos.             Arquiteto de Software         Arquiteto com foco em design de aplicações e de   serviços.         Entender os requisitos de software e de integração,   procurando elaborar o design de aplicações de forma a viabilizar serviços de   aplicação e facilitar a composição de destes em serviços de negócio.      SOA - Papéis x ResponsabilidadesHá outros papéis muito importantes dentro da construção de projetos focados em SOA. Alguns papéis como Gerente de Projetos, Desenvolvedor e Testador são cruciais para qualquer projeto de TI. Também poderíamos explorar papéis novos, como um Administrador de Serviços. Contudo, o foco deste post está na identificação das necessidades do negócio do cliente, no levantamento de requisitos e no mapeamento destas necessidades e requisitos em Serviços e Processos de Negócio.Fluxo de ComunicaçãoO fluxo de comunicação entre os papéis apresentados anteriormente é mostrado na figura abaixo.As principais trocas de informação entre estes papéis são representadas pelas setas. Certamente, algumas interações não apresentadas aqui podem ocorrer. Este fluxo procura ressaltar aquelas comunicações mais relevantes na Identificação de Serviços em uma SOA.Fluxo de comunicaçãoCliente e Analista de Negócios: O Cliente, normalmente, inicia a conversação com um Analista de Negócios. O Cliente expõe seus problemas e necessidades de negócio. O Analista de Negócios precisa ter habilidades de ouvir, interpretar, questionar, conduzir a conversa, auxiliar o Cliente na elaboração do problema, colocar-se na posição do Cliente e identificar oportunidades de Negócio não vislumbradas pelo Cliente.Analista de Negócios e Analista de Requisitos: Após o entendimento das necessidades de negócio do Cliente, o Analista de Negócios precisa interagir com o Analista de Requisitos. Serão repassados ao Analista de Requisitos as necessidades de negócio, os critérios e limitações de regras de negócio. O Analista de Requisitos, então, inicia seu trabalho de levantamento de requisitos funcionais para atender ao negócio.Analista de Requisitos e Cliente: Após ter um entendimento inicial do problema do Cliente e dos principais requisitos de negócios repassados pelo Analista de Negócio, o Analista de Requisitos inicia sua interação diretamente com o Cliente para coletar informações mais específicas. Os requisitos funcionais são refinados e começa a tomar corpo uma visão de sistema para o projeto.Analista de Negócios e Arquiteto de Solução: O Analisa de Negócio necessita interagir com o Arquiteto de Solução a fim de que oportunidades de reuso de serviços sejam identificadas. Também são importantes as informações de negócio que demandarão trabalhos de integração de sistemas. O Arquiteto de Solução inicia seu trabalho de definição das arquiteturas candidatas.Analista de Requisitos e Arquiteto de Solução: O Analista de Requisitos precisa interagir constantemente com o Arquiteto de Solução, principalmente, no início da definição de escopo e visão do projeto, para a definição dos requisitos não-funcionais do projeto. É muito importante nesta fase que os potenciais reusos de serviços e elaboração de novos serviços sejam identificados.Arquiteto de Solução e Arquiteto de Software: Dentro do projeto, é muito importante que as figuras do Arquiteto de Solução e de Software mantenham uma comunicação estreita. O trabalho do Arquiteto de Software deve permitir que os serviços candidatos identificados pelo Arquiteto de Solução possam ser realizados pelos sistemas das camadas de aplicação e de componentes. O Arquiteto de Software deve ter discernimento para elaborar designs flexíveis para as aplicações e propor soluções adequadas para adaptar as aplicações legadas a fim de que estas possam ter o melhor aproveitamento de sua vida útil dentro da plataforma de integração da empesa.Arquiteto de Software e Analista de Requisitos: Uma vez que o Analista de Requisitos e o Arquiteto de Software são os "mais próximos" da solução de software, estes precisam ter um grau alto de relacionamento. O Arquiteto de Software, assim como o Arquiteto de Solução, participam ativamente da definição de requisitos não-funcionais da solução.Pensamentos FinaisO fluxo de comunicação apresentado considera que os papéis serão executados por diferentes pessoas dentro do processo. Todavia, é possível que uma mesma pessoa exerça mais de um papel. Isto seria compreensível para os papéis de Analista de Negócios e Analista de Requisitos, ou Arquiteto de Solução e Arquiteto de Software. Por um lado, o acúmulo de papéis pode acrescentar riscos dentro de um projeto e comprometer a qualidade final do trabalho. Por outro lado, a divisão excessiva de papéis entre pessoas diferentes pode apresentar dificuldades de comunicação. Foi ponderando os benefícios e as dificuldades que apresentei tal configuração.Links de referência:New Techniques for Requirement ManagementRequiremens Process for SOA ProjectsAn Introduction to SOA Solution ScenariosCreate the Ideal SOA TeamSOA Project Planning Aspects