Como apresentado anteriormente, uma iniciativa SOA deve ser conduzida como um Programa, um conjunto de projetos interdependentes. Mas se trata de um programa bastante particular já que a ligação entre os projetos, assim como ocorre com os serviços que formam uma SOA, deve ser fraca. Quer dizer, é fator crítico de sucesso de uma SOA que seus projetos não criem nenhum tipo de impedimento para a realização de outros.
É natural que cada Serviço seja visto como um Projeto em si. O fato de ser uma tradução direta de um processo de negócio facilita a comunicação com as áreas usuárias. Mas como definir um Serviço?
Normalmente as organizações e seus sistemas são vistos como estruturas hierárquicas. Departamentos são estruturados verticalmente, e os sistemas que os apóiam acabam se transformando em silos de informações. Mas os processos e atividades de negócio ocorrem horizontalmente, podendo envolver várias áreas e departamentos em sua realização completa. Um processo de venda, por exemplo, pode envolver os departamentos financeiro, almoxarifado e logística, além da própria área de vendas.
No início dos anos 90 Michael Hammer e James Champy lançaram o livro “Reengenharia – Revolucionando a Empresa” , onde propunham a visualização da empresa como um conjunto de processos. Partiam do pressuposto que apenas uma visão completa e única dos processos poderia ajudar a organização na otimização destes e, conseqüentemente, na obtenção de vantagens competitivas. Hammer e Champy não criaram esta visão, mas a tornaram popular e presente nas agendas das mais diversas organizações.
Apesar da “onda reengenharia” ter resultado em grandes desastres corporativos, a criação de uma visão da parte realmente dinâmica de uma corporação – seus processos – ainda é um fator de diferenciação no mundo dos negócios. Tanto que além da proposta SOA, outras tendências como BPM (Business Process Management) e BAM (Business Activity Monitoring) são fortemente baseadas nesta visão.
Todo processo de negócio possui uma hierarquia . Ele é composto de sub-processos que são seqüências de atividades que por sua vez são divididas em duas ou mais tarefas. Voltando ao exemplo de um processo de venda, podemos dizer que a elaboração de uma proposta é um sub-processo; a logística de entrega é uma atividade; e a verificação do crédito do comprador é uma tarefa.
Relacionando essa hierarquia com os tipos de Serviços existentes em uma SOA podemos dizer que os serviços Básicos representam as tarefas e atividades, enquanto os serviços dos tipos Processo e Público representam processos e sub-processos de negócio. Portanto, um programa SOA pode ser formado por projetos de portes bastante distintos.
Além do desenvolvimento dos Serviços propriamente ditos há outro projeto em um programa SOA: o desenvolvimento e evolução da Infra-estrutura tecnológica que deve suportar a nova arquitetura. Esta infra-estrutura é composta pelo Repositório e pelo Bus de Serviços.
Equipes de Projetos
As equipes que executam os projetos SOA devem ser formadas a partir do modelo do Comitê Gestor. Uma formatação padrão teria as seguintes funções:
Como será detalhado adiante um dos processos que serviu de base para este estudo foi o Scrum . Portanto a estrutura de equipe apresentada na figura acima reflete, de certa maneira, uma equipe padrão Scrum.
O Dono do Serviço é equivalente ao Product Owner do Scrum, com algumas diferenças. Ele não é escolhido pelo Scrum Master, o Coordenador do Projeto da estrutura sugerida, e sim pelo Comitê Gestor. Ele deve ser um Arquiteto SOA e suas principais responsabilidades são: i) a Elaboração e Negociação do contrato do serviço com as áreas usuárias; ii) Transformação deste contrato em um Service (Product) Backlog, principal meio de controle e comunicação com o Coordenador e os Desenvolvedores alocados no projeto; e, iii) Gerencia o escopo e define as prioridades do projeto. É o Dono do Serviço que responde pelo projeto perante o Comitê Gestor e toda a organização.
Já o Coordenador do Projeto equivale, em termos, ao Scrum Master. Ele é indicado pelo Engenheiro do Processo (PMO) que integra o Comitê Gestor. O Coordenador deve garantir que a equipe esteja respeitando o processo de desenvolvimento. E, como prega a metodologia Scrum, é responsável pela eliminação de qualquer impedimento que esteja impactando na performance da equipe.
Visando facilitar a compreensão dos dois papéis acima, pouco comuns em equipes tradicionais de projetos, Jeff Sutherland apresentou uma feliz analogia com uma equipe de rally . Enquanto o Coordenador do Projeto (Scrum Master) é o “Piloto”, o Dono do Serviço (Product Owner) é o “Navegador”.
O Analista de Negócio é nomeado pelo Arquiteto de Negócio para representar a equipe perante todas as áreas de negócio envolvidas com o serviço em questão. É ele quem captura os requerimentos e os transcreve de forma a facilitar a compreensão pela equipe de desenvolvimento. Assim como o Arquiteto de Negócio no comitê gestor, o Analista de Negócio deve defender e garantir a satisfação dos requerimentos pelo serviço desenvolvido.
O grupo de Apoio é populado por integrantes que são alocados esporadicamente na equipe, visando atender necessidades específicas. Um representante do time de Infra-Estrutura Tecnológica pode ser alocado, por exemplo, para garantir que o Serviço será atendido pelos recursos computacionais existentes.
O Gestor da Biblioteca de Ativos fará uso desta mesma estrutura quando o serviço se encontrar em estágio final de construção, visando sua Certificação (CQ – Controle de Qualidade) e preparação para Publicação, de acordo com o ciclo de vida estipulado no processo.
Os Desenvolvedores são estruturados em dois grupos: Frontend Apps, que trata do desenvolvimento das interfaces para os usuários dos serviços; e Serviços, que é a implementação do serviço propriamente dito. Tal divisão deve fazer sentido na construção de praticamente todos os tipos de serviços, independente de seu porte. Como será apresentado a seguir, é uma boa prática que tais elementos sejam desenvolvidos em separado, dadas as consideráveis diferenças que existem entre eles e a necessidade de agilidade em sua construção.
Considerações sobre as Estruturas Propostas
É interessante notar que uma Equipe de Projeto é um tipo de instanciamento do Comitê Gestor. Assim como é fortemente sugerida a adoção de um Meta-Processo para o Programa que tenha o mesmo formato e atenda os mesmos padrões do Processo adotado para o desenvolvimento e gestão dos projetos, é salutar que as equipes de projetos SOA sejam uma representação (de certa forma abreviada) do Comitê Gestor. Percebem-se duas inequívocas vantagens neste enfoque:
• Clara distribuição de responsabilidades que respeita, principalmente, as áreas de especialização; e
• Formação de “Comunidades de Prática” , ou seja, profissionais são agrupados por área de interesse. A troca de conhecimentos pode se dar de maneira mais natural e freqüente.
>>>>>>>>>> SOA #8 – Processo de Gestão e Desenvolvimento
11. “Reengenharia – Revolucionando a Empresa”, Michael Hammer e James Champy
Editora Campus (1994)
12. “Aperfeiçoando Processos Empresariais”, H. James Harrington
Makron Books (1993)
13. “Agile Software Development Methods – Review and Analysis”, Pekka Abrahamsson, Outi Salo, Jussi Ronkainen e Juhani Warsta
VTT (2002)
14. “Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects”, Jeff Sutherland
Artigo (2005)
15. “Aprendizado Inter-Projetos”, Paulo F. Vasconcellos
Artigo publicado em Out/2004.
