In the existing IT environments, I believe we moved from being Server-centric to OS-centric to Application-centric. In the next generation, we become more network-centric but fundamentally (for the first time I might note) start building Information Technology actually around the Information. This is powerful. It means that Information is no longer captive to a single application but can be leveraged across any number of applications.

– Mark S. Lewis, VP da EMC

Vale a pena ler toda a sua série chamada “Flat IT”.

Na 1ª parte ele fixa as 3 áreas que devem ser ‘atacadas’ no início de um programa SOA:

• Gerenciamento do Portfólio
• Arquitetura Corporativa
• Gerenciamento da Informação

No gráfico acima ele mostra o ‘ataque’ e suas derivações mais específicas, ilustrando em alto nível os principais papéis e responsabilidades que existem em uma equipe formada para implementação de uma SOA.

Na 2ª parte ele sugere a criação de um “SOA Steering Comittee”. No desenho abaixo os membros do comitê e respectivas disciplinas:

A sugestão do Schneider tem algumas semelhanças com aquele desenho que apresentei aqui há quase 2 anos:

O Gerenciamento do Portfólio é uma das áreas críticas, segundo Schneider. No meu ponto de vista, deveria ser uma responsabilidade do próprio Gestor do Programa (“SOA Leader” na nomenclatura utilizada por ele). Auxiliam no gerenciamento do portfólio o Arquiteto de Negócio e o Gestor da Biblioteca de Ativos (GBA), além do representante do PMO (Escritório de Projetos). Entendo que portfólio são os projetos e os ativos existentes. É grande demais para uma cabeça só. Aproveito para insistir que uma boa ferramenta de apoio para tal gerenciamento, sintética e objetiva, é o Mapa Estratégico. Desde que devidamente adaptado para o programa.

Alguns princípios que regem o gerenciamento de projetos, por exemplo, precisam ser revistos. Recentemente aconteceu uma boa discussão no grupo CMM-Brasil que envolveu, entre outras coisas, o balanceamento do ‘trio de ferro: Preço x Prazo x Escopo’. Resumindo: quem defende uma abordagem Ágil* diz que, após a negociação e contratação formal, o único item que deveria variar na equação acima é o escopo. Deveríamos eliminar algumas funcionalidades com o intuito de manter intactos o valor e o prazo inicialmente acordados.

De uma maneira geral, e não exclusivamente no caso de um programa SOA, a regra é questionável e polêmica. Agilidade combina com flexibilidade. E regras escritas em pedra não combinam com flexibilidade. Está aí um tipo de princípio que não deveria ser adotado no nível da organização. Alguns projetos podem exigir o total atendimento dos requisitos apresentados. Neste caso, clientes e usuários podem concordar com uma flexibilização dos preços e prazos apresentados. A negociação do(s) ponto(s) de variabilidade do ‘trio de ferro’ deveria fazer parte do acordo inicial, seja ele um contrato ou um convênio. Ao contrário do que foi dito naquela thread do grupo de discussão, não deixo de ser ágil porque concordei com a entrega de todas as funcionalidades requeridas por um cliente. Mesmo que isso signifique algum atraso em relação aos prazos acordados anteriormente.

Agora, quando se trata especificamente de uma iniciativa SOA, a fixação do escopo como o único fator variável do ‘trio de ferro’ pode ser um engano ainda mais nocivo. Um engano bastante comum que, segundo Todd Biske, deriva de uma mentalidade ‘schedule-driven’. Vou surrupiar seus argumentos:

Muitas organizações com as quais trabalho têm a tendência de ser ‘guiadas pelos cronogramas’ (schedule driven). Ou seja, o elemento menos flexível do projeto é o cronograma. Assim, a coisa que mais ‘sofre’ é o escopo. Infelizmente, não se trata do escopo propriamente dito e sim da diferença entre o caminho mais rápido (tático) versus o melhor caminho (estratégico). Se você está tentando implementar uma SOA, saiba que esse tipo de governança de TI tornará sua vida bem difícil. Você está premiando o sucesso do cronograma, não o sucesso da arquitetura.

Todd encerra dizendo que se trata de uma “grande mudança cultural”. É sim, particularmente onde impera o imediatismo. SOA deve, de alguma forma, ser vacinada contra esse mal. E isso não significa, de forma alguma, deixar de ser ágil.

“I think that right now we’re at a stage where the tools and accepted architectures do not fit the job that programmers have to do. We have three factors that are not going to change in the near future, and they all live on the client: HTML, the browser, and Javascript. Everything else is negotiable. It’s up to programmers to figure out how to deliver the best application they can using any back-end they want, as long as it works with those three front-end technologies. Programmers have done some really cool stuff on top of those three technologies, but things are still pretty awkward.”

…

“The big problem, I think, is that the front-end is still very disconnected from the back-end. Because of SOA, people are still thinking very much in terms of sending and receiving messages rather than thinking about how to create a smooth and seamless application that exists both on the client and the server. I don’t know if it’s because of the fact that the Web was very disconnected in the early days, but most programmers still don’t think of the Web browser as a connected client.”

…

“However, there is no longer any good reason to keep the client disconnected from the server in terms of software architecture. Broadband penetration is now 75% of active Internet users in the U.S., and much higher in countries that are not as backwards as we are. For some reason, programming techniques have not yet adapted to this fact. And what’s more, everyone is on their way to becoming an always-on node on the Internet network. One third of Blackberry owners are not using their phones for business. The iPhone from Apple (if it gets to keep its name) is a tiny OS X computer with Internet connectivity. In places where Wi-fi hotspots aren’t present, Wi-Max will be soon. In other words, we can no longer get around the fact that the client is once again part of the architecture equation, and our programming practices need to support that fact.”

– Jason Kolb (em “Network-Oriented Architecture“)

Interessante do estudo da McKinsey é a justificativa apresentada por 48% dos executivos: eles querem implementar uma SOA para facilitar a integração com seus parceiros de negócios. Das duas, uma:

• Seus sistemas internos estão Ok (bem integrados) e não justificariam a adoção de uma SOA; ou
• Trata-se de uma estratégia para facilitar a obtenção de investimentos – aliás, uma boa estratégia. SOA não impõe um ponto de partida, e a priorização de processos de negócios mais críticos pode acelerar o ROI e melhorar a percepção dos benefícios. Processos ‘públicos’ (que ultrapassam as fronteiras da empresa) são sempre críticos. Risco: confundir SOA com um conjunto de web services.

Joe McKendrick, da ZDNet, também elencou uma série de previsões para SOA em 2007: Melhores ferramentas (no “ano da modelagem”) e uma adoção lenta mas consistente estão entre elas. Mas a mais dramática deve preocupar o pessoal daqui também: a falta de profissionais habilitados para trabalhar na implementação e manutenção de uma SOA.

A impressão que tive é que com a quantidade de dinheiro que se está investindo em SOA hoje não dá mais pra chamar de futuro, mas de presente. Claro que há um problema muito grande aí: Este foi o mesmo cenário, por exemplo, com EJBs.

Eu espero sinceramente que tenhamos aprendido a lição e que estudemos os conceitos por trás das coisas antes de sair por aí implementando sistemas que não funcionam utilizando ferramentas caríssimas.

– Philip Calçado (em seu blog Fragmental)

===

Acabei de conhecer o trabalho do Philip. Coisa muito boa, escrita d’uma forma muito legal. Tanto que já tá devidamente assinado e referenciado ali embaixo.

E assim retomo os posts “meme” aqui no finito.

• Pra variar há um descompasso entre fornecedores de tecnologia e seus usuários. Parece que 2006 será um ano ‘chave’ para a consolidação de SOA nos EUA. Pelo que percebi, nós tupiniquins aguardaremos mais 2 ou 3 anos. Os poucos early adopters brasileiros não terão o que mostrar no ano que vem, não ao ponto de motivar adesões.
• Nas palestras, o pessoal com um pouco mais de estrada (desenvolvendo sistemas) percebe rapidamente as vantagens de uma SOA. Como apresento na 1ª parte do evento os conceitos básicos, é natural que se inicie ali um debate sobre “Arquitetura”.
• É uma pena que eu tenha que atirar um balde d’água fria no ânimo do pessoal no mesmo instante. Faço-o (sem querer) ao lembrar que ainda temos muitas pendências (linguagens para os contratos: WS-*; ferramental de desenvolvimento; um processo para gestão e desenvolvimento e as eternas “questões semânticas”).
• E compenso tudo mostrando a maior pendência de todas: o Arquiteto (que não existe). Digo, sem o menor medo de errar, que será a profissão com as melhores ofertas e melhores salários nos próximos 5 anos. E nesse ciclo sádico (1 tapa, 1 beijo), apresento um anúncio real para contratação de um Arquiteto. Desanimo uns e provoco todos ao comentar que no próximo ano a Microsoft lançará a nova certificação MCA (Microsoft Certified Architect), um processo que lembrará (muito) a defesa de uma tese de doutorado. (Com um programa que cita o IBM Websphere mais de 1 vez!!!).
  

Ou seja, só a primeira parte (que dura uns 30-40min) da palestra já gera assunto para 2hs de debate. E, dependendo do público (falo principalmente da estudantada das faculdades), trata-se de uma tsunami de siglas e conceitos novos. Um show de terror ou um show de tédio, dependendo do aluno. Mal sabíamos (na primeira execução pública) que o evento ainda duraria mais 2hs…

• Uma iniciativa SOA deve ser gerida como um Programa, ou seja, um conjunto (nada pequeno) de projetos. Gosto muito da estrutura do Comitê Gestor que sugiro. Mas fiquei devendo um processo de gestão. Cito o Meta-Scrum (que é uma proposta muito recente) e uma série de ferramentas / frameworks / Padrões (Mapas Estratégicos, MDA, RAS). Todos mereciam mais tempo e espaço. E, principalmente, Estudo!
• Mas meu maior erro (no artigo – foi corrigido na apresentação) foi citar o RUP e não o EUP (Enterprise Unified Process) como processo básico. O EUP contempla várias disciplinas (totalmente ignoradas pelo RUP) vitais para a gestão do Programa SOA: Enterprise Business Modeling, Portfolio Management, Enterprise Architecture e Strategic Reuse.
• A audiência parece assimilar bem os conceitos básicos do método Scrum para o gerenciamento dos projetos SOA. Mas deixo (e destaco) aqui outra imensa pendência: um processo “meet-in-the-middle“, fundamental para a análise e projeto (design) dos Serviços. Explico a necessidade: enquanto um Analista de Negócio absorve os requerimentos do projeto, um Analista de Sistemas deve descobrir e mapear todos os ativos de software que podem ser revitalizados pelo novo Serviço. Seu encontro (meet-in-the-middle), intermediado pelo Arquiteto, deve gerar a primeira visão conceitual (lógica?) do Serviço.
  

Conclusão: é muito mb pro meu hd (ou: “muita areia pro meu caminhãozinho”). E olha que nem me meti em temas como “Governança SOA”, “Segurança SOA”, “Gerenciamento de Transações em uma SOA”… urgh! Preciso “focar” (blergh!) meus estudos se eu quiser parar de gerar “nata” (com alguns metros quadrados de área e 2cm de profundidade). Lógico que meus interesses, desde o início dos estudos, são:

• Gestão de Projetos (Gestão do Programa em 2º plano);
• Processos de Gestão e Desenvolvimento;
• Agilidade; e
• Perfil dos futuros projetos de TI (onde SOA se encaixa).
  

Eu e o finito voltamos para eles tratando-os de forma mais específica. Lógico que partindo do ponto que estamos: tudo que sugerimos para Programas e Projetos SOA são úteis em outros tipos de projetos. Vamos maturá-los enquanto SOA não vem…

Trata-se de um trabalho em desenvolvimento e sua publicação aqui visa obter outras colaborações, críticas e sugestões. A intenção é promover um bate-papo (presencial, obviamente, além de uma provável apresentação) até o final do mês de agosto. Seguem abaixo os links para as 8 partes do artigo:

#1 – Introdução
#2 – Conceitos Básicos
#3 – É o Negócio, Estúpido!
#4 – O Programa SOA
#5 – Processos
#6 – MDA (Model Driven Architecture)
#7 – Os Projetos SOA
#8 – Processo de Gestão e Desenvolvimento

Além de uma série de outros motivos que não merecem tratamento aqui, a amplitude e complexidade do tema me levaram a desistir de inscrever o artigo nos eventos “V Seminário Internacional” do PMI e “Gestão de Projetos” da SUCESU-SP, do qual participei nas duas últimas edições. Há muito por fazer!

E estudar. Olhando especificamente para a “Gestão do Programa SOA” e “Gestão de Projetos SOA” dá para destacar as seguintes disciplinas:

. Mapas Estratégicos – Para a Gestão de Portfólios
. MDA (Model Driven Architecture) – Como complemento do Processo de Desenvolvimento e como framework
. RUP (Rational Unified Process) – Como base do Processo de Desenvolvimento.
. Scrum – Que selecionei como processo de Gestão dos Projetos. Um Meta-Scrum seria utilizado para gestão do Programa SOA.
. Formação de Equipes – Apresento duas estruturas, uma para o Comitê Gestor e outra para as Equipes de Desenvolvimento. Há vários perfis (oportunidades?) novos!

Se considerarmos que as “Arquiteturas Orientadas a Serviços” são, em si, uma macro-disciplina bastante nova, instigante e complexa… Pois é: há muita coisa nova (e boa) a ser estudada e, claro, IMPLEMENTADA!

Espero que o Finito seja uma boa ferramenta para que a gente possa trocar idéias e experiências. Espero mais ainda que o conteúdo apresentado seja um bom “estopim”. Let’s talk about it?

• Cooperativo: aproxime a equipe de projeto com os futuros usuários dos serviços;
• Direto: o método deve ser de fácil aprendizado e bem documentado;
• Adaptável: fácil de ser customizado de forma a atender particularidades de determinado projeto;
• Escalável: de forma que possibilite sua adoção em projetos dos mais variados portes e níveis de complexidade;
• Orientado pela Arquitetura: ou seja, pressupõe que os produtos dos projetos em desenvolvimento fazem parte de algo maior e devem, conseqüentemente, respeitar os padrões fixados; e
• Incentivador do Reuso de Ativos: uma conseqüência direta de sua orientação à arquitetura.

Não há um único processo no mercado que, em seu formato padrão, atenda todos os requisitos listados acima. Os 3 primeiros itens da lista mais as características “iterativo e incremental” configuram o que se chama de um “Processo Ágil”. Porém todos os mais conhecidos são indicados para pequenas equipes ou seja, não escalam. Já processos que atendem os 3 últimos requisitos da lista, como o Rational Unified Process (RUP), raramente são considerados “Cooperativos” ou até mesmo “Diretos”.

Uma combinação do RUP, Scrum e eXtreme Programming (XP) pode gerar um excelente processo para a gestão e desenvolvimento de Projetos SOA. Abaixo é apresentada uma visão geral deste modelo customizado.

Visão Geral de um Processo Customizado

Dos 3 processos listados acima, o RUP é o mais completo. Por isso muitas vezes é tido como excessivamente burocrático e “pesado”. Seus críticos, na maioria das vezes, desconsideram o fato dele ser bastante customizável. O RUP é a base desta sugestão exatamente por sua completitude e adaptabilidade. Geralmente ele é apresentado, em alto nível, da seguinte maneira :

As disciplinas do RUP mais afetadas em uma customização para atendimento dos requisitos de um processo SOA são:

• Modelagem de Negócios: que passa a gerar, como principal produto, o Contrato do Serviço que, por sua vez, é a base para elaboração do Backlog do Serviço (Produto, na terminologia Scrum). A captura de indicadores de qualidade e níveis de serviço esperados também merece destaque;
• Implementação: que deve incorporar algumas práticas XP, particularmente a liberação de produtos em ciclos curtíssimos;
• Teste: que incorpora testes específicos de uma Arquitetura Orientada a Serviços, como a validação da abrangência das interfaces expostas, potencial de reuso, dentre outros;
• Implantação: que deve assimilar também todas as atividades de publicação dos Serviços, dentre elas o encapsulamento final dos artefatos e o agendamento da publicação;
• Gerenciamento do Projeto: que é totalmente trocada pelo método Scrum. Veja mais abaixo.

Gerenciamento de um Projeto SOA

Como adiantado no sub-capítulo “Equipes de Projetos” acima, a responsabilidade pelo Gerenciamento de um Projeto SOA é compartilhada pelo Coordenador do Projeto e pelo Dono do Serviço (Product Owner, na terminologia Scrum original). O primeiro cuida de todas disciplinas previstas no PMBoK (Project Management – Body of Knowledge) exceto a “Gestão do Escopo”, que seria de responsabilidade exclusiva do Dono do Serviço*. Mas a adoção do Scrum como método para a gestão de um projeto SOA implica em mudanças ainda mais profundas na rotina de trabalho do coordenador de projetos.

Sua principal atividade pode ser vista como uma “obsessiva (extrema) gestão de riscos”. Ele deve buscar e eliminar todas as barreiras que estejam impedindo a equipe de atingir seu ponto máximo de performance. O diagrama abaixo expõe uma visão geral do processo Scrum adaptado para o desenvolvimento de projetos SOA:

Na etapa de Planejamento é compilada a primeira versão do Contrato do Serviço. Em tempo de desenvolvimento é desejável que este contrato seja a principal ferramenta de controle e acompanhamento do projeto. Para tanto ele deve contemplar também :

• Estimativas de Custos e Prazos para o projeto;
• Plano de Desenvolvimento e das Iterações (Sprints);
• Definições de sincronismo com outros projetos;
• Plano de Testes; e
• Plano de Publicação.

O contrato é desenvolvido a partir dos requerimentos coletados pelo Analista de Negócios e de definições prévias oriundas do Comitê Gestor do Programa SOA. O contrato deve respeitar integralmente os Padrões SOA definidos por este comitê nos momentos iniciais do programa. É parte integrante do Contrato um desenho em alto nível da arquitetura do serviço. Por isso ele é elaborado em conjunto pelo Dono do Serviço e pelo Analista de Negócios.

A negociação final do contrato com as áreas usuárias é conduzida diretamente pelo Dono do Serviço. O processo pode prever uma etapa de revisão de contratos pelo Comitê Gestor, que ocorreria antes da elaboração do Backlog do Serviço. Esse backlog é desenvolvido pelo Dono do Serviço. Sua elaboração é acompanhada pelo Coordenador do Projeto, que pode discutir prioridades e definir a estrutura de divisão de tarefas. É também neste momento que as estimativas de prazos e custos podem ser refinadas, com apoio de integrantes das equipes de desenvolvimento.

A partir do Backlog do Serviço o Coordenador do Projeto elabora o Backlog do Sprint (Iteração), que é o plano de trabalho da próxima iteração a ser executada. Um sprint, na concepção original do método Scrum, é uma iteração com duração fixa de 30 dias. Apesar dos benefícios da fixação de um prazo comum para todas as iterações de todos projetos, entende-se que em muitos casos tal “regra” pode se tornar uma barreira a ser derrubada pelo Coordenador de Projetos. Um serviço, dependendo de sua granularidade, pode demandar ciclos de duração mais curta. No entanto trata-se de um excelente balizador para projetos mais complexos.

Um sprint contempla todas as fases tradicionais de um processo de desenvolvimento de sistemas, ou seja: engenharia de requerimentos, análise, modelagem, codificação, testes e liberação. No entanto, é vital que ao término de cada sprint aja uma nova versão do serviço em condições de uso, mesmo que ainda não estejam satisfeitos todos os seus requerimentos fundamentais.

Como mostrado anteriormente, a construção de um serviço normalmente envolverá o trabalho de dois times distintos: os desenvolvedores dos Frontends das Aplicações e os desenvolvedores dos Serviços propriamente ditos. É crucial que o backlog do Sprint contemple a total sincronização destas duas frentes de trabalho. O gráfico a seguir mostra um zoom de como deve ocorrer o Sprint :

O processo prevê a realização de scrums diários, breves reuniões que ocorreriam sempre no mesmo local e horário. Nelas o Coordenador afere os progressos obtidos desde o dia anterior, refina a lista de riscos e impedimentos e ajusta o planejamento de atividades do dia. Radical, a proposta original do Scrum sugere que estas reuniões tenham a duração máxima de 15 minutos. O coordenador pode optar por realizar duas reuniões diárias, uma com cada time de desenvolvimento.

No último dia do sprint realiza-se uma reunião de revisão com a presença do Dono do Serviço, Analista de Negócios e representantes das áreas usuárias. O Coordenador e a equipe de desenvolvimento apresentam as realizações do último sprint. Neste momento o Dono do Serviço e o Coordenador do Projeto revisam o Backlog do Produto, registrando mudanças ou novas solicitações. A partir desta atualização o Coordenador elabora o Backlog do próximo sprint.

Quando todos os itens do Contrato do Serviço estiverem satisfeitos inicia-se a terceira e última fase do projeto, que na versão original do Scrum é chamada Postgame Phase. Neste momento o Serviço e respectivo Cliente são submetidos ao processo de certificação, que deve garantir a total adequação dos novos artefatos aos Padrões SOA.

Por fim temos o processo de Publicação, que envolverá o encapsulamento de todos os artefatos gerados e o agendamento da publicação do Serviço.

Representantes do Comitê Gestor do Programa SOA envolvem-se em três momentos de um projeto:

• Validando o Contrato elaborado na primeira fase;
• Acompanhando as Reuniões de Revisão, que no formato padrão ocorrem mensalmente; e
• Certificando e Publicando a versão final do Serviço.

O processo Scrum sugere que as equipes de projeto se auto-gerenciem, promovendo a livre interação entre todos os membros. O Coordenador do Projeto, mais que um “controlador”, é um Facilitador. Outra característica marcante do processo é a “blindagem” da equipe, que em seu dia-a-dia fica livre de influências externas. Este desenho valoriza todos os integrantes da equipe e pode representar consideráveis ganhos de produtividade.

Evolução do Processo

O Scrum é um modelo organizacional desenhado para a execução de projetos cuja previsibilidade é limitada . Os princípios básicos que levaram ao seu desenvolvimento foram Flexibilidade, Adaptabilidade e Produtividade. A coincidência com os meta-requerimentos fundamentais de uma iniciativa SOA é total. Mas ambas propostas, tanto o Scrum quanto as Arquiteturas Orientadas a Serviços são relativamente recentes. Praticamente não existem referências do uso do Scrum em projetos SOA.

O trabalho mais recente de Jeff Sutherland descreve a última evolução do Scrum, chamada “Tipo C”. As principais alterações referem-se à adoção de sprints simultâneos e a elaboração de um MetaScrum. Este meta-processo pode ser muito útil na gestão do Programa SOA, como sugerido neste artigo. E a habilidade de gerenciar múltiplos sprints pode ser crucial em uma iniciativa SOA que se encontre em um estágio mais avançado de maturação.

=================

3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
Prentice Hall (PTR) (2005).
14. “Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects”, Jeff Sutherland
Artigo (2005)
16. “Rational Unified Process”, IBM Corp.
http://www-306.ibm.com/software/awdtools/rup/

* Na realidade, a versão original do Scrum prevê a existência de um terceiro gestor, não considerado nesta proposta.

É 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.