Este post é um "índice" para os (até então) 8 capítulos que compõem o artigo "Projetos SOA - Novos & Velhos Desafios".

Trata-se de um trabalho em desenvolvimento e sua publicação aqui visa obter outras colaborações, críticas e sugestões. A ToDo-List "What needs to be done?", ao lado, indicará sempre os próximos passos deste trabalho. 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?

Marcadores: arquitetura, gerenciamento_de_projetos, soa

Uma implementação SOA não deve significar a adoção de um conjunto totalmente novo de processos e métodos. Principalmente se a empresa contar com uma equipe relativamente estável e um conjunto de melhores práticas comprovadamente eficazes. O processo existente deveria ser customizado de forma a implementar atividades, perfis e produtos específicos de um programa SOA. A principal barreira para a adoção de um processo atual seria o fato deste não prover um ciclo de vida de desenvolvimento que seja iterativo e incremental. Um modelo waterfall, definitivamente, não é adequado para o desenvolvimento de Serviços SOA. Também é desejável que o processo utilizado seja [13]:

• 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 [16]:


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 PM-BoK (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 [3] :

• 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 [3] :


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 [14]. 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 [14] 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.

Marcadores: arquitetura, gerenciamento_de_projetos, soa

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” [11], 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 [12] . 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 [13]. 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 [14]. 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” [15], 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.

Marcadores: arquitetura, gerenciamento_de_projetos, soa

Outra iniciativa relativamente recente que pode agregar alto valor a uma implementação SOA é a Arquitetura Guiada por Modelos (MDA – Model Driven Architecture), proposta e mantida pelo OMG (Object Management Group) [8]. MDA é um framework para o desenvolvimento e manutenção de aplicações fortemente baseado em modelos e, conseqüentemente, na UML (Unified Modeling Language), que também é um padrão mantido pelo OMG. MDA propõe separar a especificação das funcionalidades de um sistema da especificação de sua implementação. Além da portabilidade obtida, haveria considerável ganho nas tarefas de construção e atualização das soluções. Várias ferramentas realizam, de certa forma, esta visão, automatizando as tarefas de modelagem e, principalmente, a transformação entre modelos. Esta “automatização” do processo de desenvolvimento geraria reduções de até 50% nos esforços e custos de desenvolvimento [9] [10].

Mas o primeiro impacto positivo que a adoção da MDA pode trazer para a implementação de uma Arquitetura Orientada a Serviços é a adoção de modelos que, utilizando variações de um mesmo padrão de linguagem, podem facilitar a visualização e compreensão das arquiteturas vigentes na organização e daquelas a serem realizadas.

Um Serviço em uma SOA, como descrito anteriormente, é a representação fiel de um Processo de Negócio. A correta assimilação deste processo, seus sub-processos e atividades, requerimentos e restrições são cruciais para o seu desenvolvimento na forma de um Serviço. MDA fornece dois tipos de modelos que podem facilitar a absorção, desenho e eventualmente até mesmo o redesenho do processo de negócio. São os modelos CIM (Computation Indenpendent Model) e PIM (Platform Indenpendent Model).

O CIM, como o próprio nome indica, pode representar o processo de negócio em sua forma mais pura, sem a influência da estrutura de sistemas que eventualmente o suporta. Este modelo, também conhecido como Modelo de Domínio, utiliza diretamente o vocabulário do negócio, meta-requerimento fundamental em uma implementação SOA.

Já o PIM pode mostrar o processo de negócio devidamente apoiado por recursos computacionais sem no entanto entrar em detalhes de sua implementação. A indicação dos recursos necessários para a realização do Serviço conforme especificado em seu Contrato pode facilitar o trabalho dos arquitetos na seleção da melhor estratégia de implementação, que é desenhada na forma de um PSM (Platform Specific Model), outro tipo de modelo MDA. O framework MDA possibilita a execução de simulações na conversão dos modelos, o que pode facilitar e apoiar o processo de tomada de decisões pelos arquitetos.



Observação: há um quarto modelo no MDA, chamado PM (Platform Model). Ele provê uma visão de uma plataforma específica, seus elementos e serviços oferecidos. Se devidamente enriquecido de forma a representar as peculiaridades daquela plataforma na empresa ele também pode ser muito útil nas tarefas de simulação citadas acima. Além, é claro, de ser base para a modelagem do Bus que é um dos 4 principais elementos de uma SOA.


>>>>>>>>>> SOA #7 - Os Projetos SOA

8. “MDA Guide V1.0”, OMG – Object Management Group
OMG (2003). (http://www.omg.org/mda)
9. “Executive Justification for Adopting Model Driven Architecture (MDA)”, Stanley J. Sewall
Artigo (2003).
10. “What Senior Management Need to Know About the Value of MDA”, Louis J. Eyermann III
Artigo (2004).

Marcadores: arquitetura, gerenciamento_de_projetos, soa

Da mesma forma que SOA não requer nenhuma nova tecnologia, o mesmo vale quando tratamos de processos ou metodologias para gestão de programas e projetos. A corporação pode e deve reaproveitar os processos existentes, principalmente as práticas com benefícios comprovados.

Mas algumas mudanças podem ser necessárias, visando atender principalmente os meta-requerimentos Agilidade, Flexibilidade e Simplicidade. Um processo burocrático ou resistente a mudanças, como aqueles baseados em modelos waterfall (cascata), é incompatível com tais requisitos. Por outro lado, processos muito “leves” como XP (eXtreme Programming) podem resultar em redundância e retrabalho por não fornecerem uma visão geral da empreitada e por carecerem de atividades gerenciais.

O equilíbrio entre a agilidade de um processo e robustez de seus mecanismos de administração e controle, alvo de vários estudos e propostas, é crítico para a realização das promessas de uma iniciativa SOA. Por isso trata-se de uma definição que deve ocorrer no âmbito do Programa, logo em seus primeiros momentos.

Para um processo ser considerado adequado para a implementação de uma SOA ele deve:

• Promover Agilidade: o que não significa apenas ganho de produtividade dos desenvolvedores. Um processo ágil elimina barreiras e integra atividades visando aumento da qualidade de todos os produtos gerados;
• Absorver Mudanças: e não combatê-las. Um Serviço em uma SOA deve assimilar e refletir as mudanças que ocorrem em um processo de negócio de forma quase imediata. É vital que o processo saiba tratar tal volatilidade;
• Respeitar a Arquitetura: ou seja, garantir que todos os participantes de uma iniciativa SOA tenham uma visão do todo, da Arquitetura, seus padrões e princípios;
• Incentivar o Reuso: valorizando todos os ativos existentes e aqueles produzidos no programa e facilitando sua reutilização e combinação com outros ativos;
• Facilitar a Comunicação: entre todos os participantes do programa e respectivos projetos e destes com as áreas de negócio.

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

Gestão do Portfólio de Serviços

Uma das responsabilidades mais críticas do Comitê Gestor SOA é a administração do portfólio de serviços. A garantia do alinhamento do programa com as estratégias da organização e da satisfação de seus requerimentos são realizadas através de uma correta gestão do portfólio de serviços. Existem no mercado várias ferramentas que apóiam tal atividade, normalmente direcionadas para o acompanhamento de vários projetos. Elas podem ser adaptadas para o gerenciamento de um programa SOA.

Os idealizadores da ferramenta Balanced Scorecard, Robert Kaplan e David Norton, lançaram recentemente um novo conceito que pode agregar considerável valor à gestão de um programa SOA. É o Mapa Estratégico [5], que “é a representação visual da estratégia de uma empresa. Sua principal finalidade é demonstrar a Prontidão de determinado ativo intangível para atendimento dos processos internos críticos: gestão de operações, gestão de clientes, inovação e processos regulatórios e sociais. Ele se torna uma visão consolidada das quatro perspectivas do Balanced Scorecard (Financeira, do Cliente, dos Processos Internos e de Aprendizado e Crescimento). Os ativos intangíveis foram estruturados em 3 grandes grupos: Capital Humano, Capital Organizacional e Capital da Informação. De acordo com os estudos conduzidos pelos autores e parceiros ao redor do globo, para o chamado Capital da Informação, o grande objetivo das empresas é a ‘disponibilidade de sistemas de informação, de infra-estrutura e de aplicativos de gestão do conhecimento necessários para suportar a estratégia’” [6] [5].

A relativa simplicidade desta ferramenta e a clareza com a qual demonstra as estratégias corporativas e sua relação de dependência com ativos de TI, o Capital da Informação, a tornam bastante adequada para a gestão, em alto nível, do portfólio de serviços. Como um serviço em uma SOA é a representação direta de um processo ou atividade de negócio, a comunicação do comitê gestor SOA com as áreas de negócio é bastante facilitada pelos mapas estratégicos.

No entanto, serão necessárias várias alterações no formato original da ferramenta. Os ativos de TI são apresentados na obra em 4 grandes grupos: Sistemas Transacionais, Aplicações Analíticas, Aplicações Transformacionais e Infra-Estrutura de Tecnologia. Tal classificação deve ser trocada pelos 4 tipos de serviços (Básicos, Intermediários, Processos e Públicos) mais o Frontend das Aplicações e a Infra-Estrutura tecnológica.

Uma nova dimensão deve ser criada para indicar a relevância estratégica de determinado serviço. Esta alteração também deveria afetar o modelo original, de forma a possibilitar que sistemas transacionais ou analíticos também possam ser classificados como “Transformacionais”, ou seja, como sistemas que alteram drasticamente um ou mais processos de negócios.

Outra mudança necessária é na escala de avaliação da prontidão dos ativos. O estudo original apresenta seis níveis de prontidão [6]:

1. OK. Ativo atende plenamente os requerimentos do negócio
2. Leves Melhorias são necessárias
3. Novos desenvolvimentos a caminho
4. Novos desenvolvimentos atrasados
5. Grandes Melhorias necessárias
6. Nova Aplicação necessária

A nova escala deveria refletir o ciclo de vida dos serviços, o que a deixaria da seguinte forma [4] :

1. Publicado: em Produção;
2. Classificado: alocado na arquitetura e agendado para publicação;
3. Certificado: aprovado nos testes de qualidade. Atende todos os requisitos especificados no Contrato do Serviço;
4. Submetido: em processo de Certificação;
5. Em Desenvolvimento;
6. Identificado / Especificado: serviço já foi identificado e modelado – encontra-se na fila para início de sua construção.

Deve-se lembrar que a principal utilidade desta ferramenta é a comunicação com o corpo diretivo da empresa. Daí a relativa superficialidade da escala de avaliação do grau de prontidão dos serviços. No entanto nada impede que extensões sejam desenvolvidas de forma a enriquecer o relatório e municiar os processos de tomada de decisão do comitê gestor SOA. As alterações mais desejadas talvez sejam aquelas que propiciem:

• Visibilidade dos prazos de transição entre as etapas do ciclo de vida dos serviços;
• Opções de aquisição ou desenvolvimento do serviço (compra no mercado, desenvolvimento interno, desenvolvimento terceirizado ou utilização de ativo livre e aberto disponível na Internet); e
• Estimativas de custos de cada serviço.


>>>>>>>>>> SOA #6 - MDA (Model Driven Architecture)

4. “Practical Software Reuse”, Michel Ezran, Maurizio Morisio e Colin Tully
Springer (2002).
5. “Gestão Estratégica de Ativos e Portfólios de Projetos de TI”, Paulo F. Vasconcellos
Artigo publicado em Out/2004.
6. “Mapas Estratégicos”, Robert S. Kaplan e David P. Norton
Editora Campus / Elsevier (2004).

Marcadores: arquitetura, gerenciamento_de_projetos, soa

SOA representa uma nova forma para se desenvolver, manter, comprar e vender aplicações de negócios. Ela pode afetar praticamente todos os sistemas de informação de uma empresa. E, quando bem sucedida, não possui um prazo para terminar. Como a construção de cada novo Serviço pode ser gerenciada como um projeto em si, é recomendável que uma iniciativa para implementação de uma SOA seja tratada e gerenciada como um Programa. Como tal, deve possuir definições acerca de sua Estrutura, Processos e Padrões.

Um programa SOA deve ser dirigido por um Comitê Gestor, desenhado e populado especificamente para a iniciativa. Dentre as responsabilidades deste Comitê destacam-se [3]:

• Estabelecimento e revisão das estruturas, processos e padrões utilizados tanto no âmbito do programa quanto no nível dos projetos;
• Acompanhamento da execução de todos os projetos SOA;
• Garantia do apoio e participação das áreas de negócio durante todo o programa;
• Manutenção do plano estratégico e do foco da iniciativa; e
• Execução de atividades de evangelização, como treinamento, coaching e divulgação dos benefícios e restrições do programa para toda a organização.

O Comitê Gestor de um programa SOA possui algumas funções bastante particulares. A figura 3 abaixo apresenta um modelo padrão desta estrutura, destacando seus principais atores:


O Gestor do Programa responde por ele perante toda a organização. Dada sua importância estratégica não será estranho se algumas empresas optarem por alocar o próprio CIO ou Diretor da área de TI nesta função. Ele é apoiado diretamente por um Engenheiro do Processo, que pode ser um representante do Escritório de Projetos (PMO – Project Management Office), caso exista. A uniformidade e respeito aos processos de desenvolvimento e manutenção são fatores críticos de sucesso. O Engenheiro do Processo deve garantir que tanto o programa quanto os projetos SOA estejam sendo executados dentro dos padrões estipulados pela corporação. Também é sua responsabilidade a indicação dos Coordenadores de Projetos, seu acompanhamento e apoio.

No entanto, o “braço direito” do gestor do programa é o Arquiteto SOA. Ele é o principal responsável técnico pela elaboração e implementação da arquitetura orientada a serviços. Devido a abrangência, complexidade e criticidade de tal iniciativa, o Arquiteto SOA compartilha suas responsabilidades com outros 5 arquitetos, cada um especialista em uma parte do programa.

O Arquiteto de Negócio é o principal representante do programa perante as áreas de negócio. Visto de outra maneira, ele também representa as comunidades usuárias no Comitê Gestor. Ele deve coletar, avaliar, apresentar e defender os requerimentos de negócio. Portanto ele faz uso, em alto nível, das disciplinas Modelagem de Negócios e Engenharia de Requerimentos. Se estivessem representadas na figura 3 acima, as áreas de negócio estariam no lado esquerdo do desenho. Entende-se então que os membros do comitê gestor que se relacionam de maneira direta com a comunidade usuária, além do Arquiteto de Negócio, são o Gestor do Programa, o Engenheiro do Processo e o Arquiteto SOA. Mas sua representação é uma atribuição exclusiva do Arquiteto de Negócio.

O Gestor da Biblioteca de Ativos (GBA) é um personagem raríssimo nos ambientes e projetos de TI. Mas sua existência é fundamental para o sucesso de um empreendimento SOA. Além do gerenciamento do Repositório, apresentado anteriormente, o GBA também é responsável pelos principais processos de reutilização de ativos [4], ou seja: publicação e manutenção dos Contratos; introdução e coordenação do reuso de ativos; evolução do processo de reutilização etc. Com o tempo e conseqüente aumento no número de serviços disponíveis cresce também a importância do GBA.

O Arquiteto dos Frontends das Aplicações tem sua alocação no comitê justificada pelo fato destas interfaces serem o único ponto de interação dos usuários com a SOA. São críticas as atividades de padronização das interfaces e garantia de usabilidade, que são atribuições exclusivas deste arquiteto.

O Arquiteto de Serviços, por sua vez, concentra-se na padronização, acompanhamento do desenvolvimento e avaliação dos Serviços. Nos momentos iniciais do projeto são de sua responsabilidade a elaboração de padrões para os quatro tipos de Serviços existentes em uma SOA, ou seja: Básicos, Intermediários, Processos e Públicos.

Por fim, temos o Gestor da Infra-estrutura Tecnológica, o membro do comitê responsável por garantir que os recursos computacionais disponíveis sejam adequados para atender a demanda que SOA e seus serviços gerarão. Além do sizing e estudo de capacidade de carga dos servidores, redes e softwares de infra-estrutura, este Gestor também acompanha os serviços em ambiente de produção visando garantir os níveis de serviço esperados.

Percebe-se que o Comitê Gestor é praticamente uma representação do corpo gerencial de uma organização de TI. Em muitos casos talvez seja uma estrutura ainda mais sofisticada e completa. Acontece que em um “mundo ideal”, quando SOA encontra-se em estágio avançado de maturidade e todos os processos de negócio são representados por Serviços, o comitê gestor do programa SOA torna-se praticamente a equipe de gestão de toda a organização de TI. Apesar de ser um conceito relativamente novo, alguns casos de sucesso [3] comprovam que tal “metamorfose” é uma conseqüência bastante plausível de uma implementação SOA bem sucedida. É curioso notar também que em uma situação onde a empresa decide pela total terceirização de sua área de TI, as 8 funções apresentadas acima talvez sejam as únicas que a empresa decida manter internamente. Para não correr o risco de perder o alinhamento de TI com o negócio.


>>>>>>>>>> SOA #5 - Processos

3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
Prentice Hall (PTR) (2005).
4. “Practical Software Reuse”, Michel Ezran, Maurizio Morisio e Colin Tully
Springer (2002).

Marcadores: arquitetura, gerenciamento_de_projetos, soa

Um dos principais apelos e, porque não dizer, motivo de estranheza quando se analisa uma proposta de implementação de uma SOA, é o fato dela não apresentar ou forçar a utilização de nenhuma nova tecnologia. Pelo contrário. SOA deve promover a sobrevida dos ativos de software de uma organização, tanto das aplicações de negócio quanto dos elementos de infra-estrutura (como servidores de aplicações, middleware para comunicação assíncrona, dentre outros). Martin Frick chega a sugerir que troquemos o termo “sistema legado” por “Sistema Herdado” [3].

O fato é que há muito conhecimento codificado na forma de software e espalhado pelas organizações. Mesmo após a implementação de soluções de integração de larga escala como os ERPs e sistemas CRM, a arquitetura de software das empresas continuou fragmentada, com diversos silos de informação. A característica “monolítica” destas soluções tornou cada esforço de integração uma espécie de barreira para a implementação de mudanças e novas funcionalidades no nível do negócio.

O “ovo de Colombo” de uma proposta SOA está em seu linguajar, totalmente orientado ao Negócio. Os Serviços, suas Interfaces e Contratos são apresentados na língua de seus usuários e clientes. Elimina-se desta forma aquela distância e confusão que sempre caracterizou as interações das áreas de TI com seus usuários. Mas esta nova aproximação requer uma revisão na estrutura e processos da organização de TI, como será apresentada nos capítulos seguintes.

Não é objetivo deste artigo tratar de questões acerca dos aspectos tecnológicos de uma implementação de uma Arquitetura Orientada a Serviços. Mas é importante lembrar que o conceito SOA nasceu logo após o advento dos Web Services. Estes nasceram com escopo relativamente limitado, propondo uma forma de integração de aplicações utilizando padrões abertos da Internet. Apesar de não serem obrigatórios para a realização de uma SOA, os Web Services e os padrões que os viabilizaram, como XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol) e WSDL (Web Service Definition Language), dentre outros, podem favorecer, e muito, a implantação de uma SOA. Mas deve-se lembrar que SOA não é um conjunto de Web Services e, por outro lado, o fato de uma empresa ter uma porção de serviços Web não significa necessariamente que ela possua uma arquitetura de aplicações orientada a serviços.

As organizações de TI têm, talvez pela primeira vez em sua história, a oportunidade de fazer com que seus investimentos e custos tenham claro e inequívoco objetivo de negócio atrelado. Mas o sucesso de uma implementação SOA depende de uma ampla e compartilhada visão de seus objetivos, restrições e roteiro de construção. Como será exposto nos capítulos seguintes, a gestão do Programa SOA e respectivos projetos desempenha papel fundamental nesta realização.


>>>>>>>>>> SOA #4 - O Programa SOA

3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
Prentice Hall (PTR) (2005).

Marcadores: arquitetura, gerenciamento_de_projetos, soa

SOA não é e também não promove uma nova tecnologia. Também é equivocada sua apresentação como uma nova “metodologia”. Trata-se de um conceito ou, como colocado anteriormente, uma Estratégia de TI. A principal motivação para sua implementação é a realização do tão sonhado (e raramente concretizado) Alinhamento Estratégico de TI com o Negócio. Entende-se que tal alinhamento acontece de fato quando [2]:

• TI agrega real valor ao plano de negócios;
• Não resiste às mudanças;
• Combate a resistência às mudanças; e
• É planejado.

Os três primeiros itens da lista são traduzidos em considerável ganho de Agilidade. SOA promete a criação de uma estrutura que reproduz fielmente, em mapeamento um-para-um, os processos e atividades de negócios. Tamanha aproximação deve gerar uma arquitetura flexível, que favorece as mudanças. Mas os ganhos possibilitados pela implementação de uma Arquitetura Orientada a Serviços não ocorrem por acaso ou de forma pontual. Uma implementação SOA é uma iniciativa de longo prazo - é a execução de um bem elaborado Plano Estratégico.

SOA é uma arquitetura de software. Uma arquitetura de software é “um conjunto de definições que descreve componentes de software e associa a funcionalidade do sistema a tais componentes. Descreve a estrutura técnica, restrições e características dos componentes e das interfaces entre eles. A arquitetura é uma ‘planta baixa’ para o sistema e um plano de alto nível para sua construção” [3].

Serviços em uma SOA são a representação direta de entidades, tarefas, atividades ou processos de negócio. Por representação direta entende-se a paridade em sua granularidade e o uso de um vocabulário comum, que deve ser a terminologia padrão do negócio. São características-chave de uma Arquitetura Orientada a Serviços:

• Acoplamento fraco dos serviços;
• Independência de tecnologias e protocolos;
• Uso irrestrito de padrões; e
• Incentivo à reutilização de ativos.

SOA é composta de quatro elementos principais: Frontends de Aplicações, Serviços, um Repositório de Serviços e um Mecanismo de Execução e Comunicação (Bus) para os serviços.



Os Frontends de Aplicações representam a “ponta do iceberg” de uma SOA. Eles são a interface dos serviços para os usuários finais. Portanto são de sua responsabilidade a iniciação e o controle da execução dos Serviços.

Os Serviços são componentes de software que representam um processo, entidade, atividade ou tarefa de negócio. É importante salientar que são componentes de alto nível, diferentes daqueles existentes em plataformas como o J2EE e o Microsoft .NET, que são muito granulares e mais orientados a tecnologia, não ao negócio. Existem quatro tipos de Serviços:

• Básicos: que representam os elementos básicos de um processo de negócio, como Entidades e Tarefas básicas de Negócios;
• Intermediários: são o único tipo de Serviço mais orientados a tecnologia em uma SOA. Fornecem pontes, conversores ou funcionalidades adicionais aos demais serviços;
• Processos: são os serviços que representam de forma direta um processo ou atividade de negócio, do início ao fim.
• Públicos: extensão aos serviços do tipo Processo que possibilita sua exposição para clientes (usuários) que estejam fora das fronteiras da organização.

Todo serviço, independente de seu tipo, é sempre composto por três partes principais, como ilustrado na Figura 1 acima. A primeira parte é um Contrato, um acordo que é fechado entre os consumidores de um serviço e seus provedores. Este documento explica os propósitos do serviço, contexto, regras de utilização, restrições, níveis de serviço esperados, além de apresentar uma definição formal da interface do serviço.

Interface esta que é implementada em separado, sendo o segundo elemento de construção de um serviço. Trata-se do único meio de comunicação com um serviço, seja seu cliente um frontend de uma aplicação ou outro serviço. A terceira e última parte de um Serviço é sua Implementação propriamente dita, através da realização da Lógica do Negócio e acesso e manutenção de seus Dados, de forma a atender todos os objetivos fixados no Contrato.

O Repositório armazena todos os Contratos dos Serviços disponíveis, o que o torna o ponto de partida para utilização destes. Além dos Contratos, o Repositório pode armazenar informações adicionais e mais específicas acerca dos serviços, como localização física, restrições de uso e segurança etc. Apesar de ser apresentado por alguns autores como um elemento opcional em uma SOA, o Repositório pode ser fator crítico de sucesso em grandes implementações, principalmente naquelas que envolverem a disponibilização de serviços do tipo Público.

Por fim temos o Mecanismo de Execução e Comunicação para os Serviços, ou simplesmente Bus, que interconecta todos os participantes de uma SOA, abstraindo a complexidade técnica que existe nas camadas inferiores. Um Bus pode ser constituído de várias tecnologias e/ou produtos, dependendo da infra-estrutura existente e dos requerimentos de distribuição dos serviços.


>>>>>>>>>> SOA #3 - É o Negócio, Estúpido!

2. “The Squandered Computer”, Paul Strassmann
The Information Economics Press (1997).
3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
Prentice Hall (PTR) (2005).

Marcadores: arquitetura, gerenciamento_de_projetos, soa

As organizações de Tecnologia da Informação (TI) lidam há tempos com dois meta-requerimentos conflitantes: ao mesmo tempo em que as áreas de negócio exigem mais e mais agilidade, a pressão por redução de custos se torna mais forte. “Fazer mais com menos” virou regra geral. Mas os ambientes de TI viram, nos últimos 10 anos, sua complexidade aumentar em escala exponencial. Diversas tecnologias, pacotes de software e sistemas desenvolvidos in-house se entrelaçam e se sobrepõem de forma que beira o caos.

Não se trata de má administração, não na maioria dos casos. Acontece que a urgência dos requerimentos de negócio e o relativo curto ciclo de vida de algumas tecnologias levaram as organizações a erguerem verdadeiras torres de Babel. Durante um tempo foi possível apagar fogueiras localizadas com certa agilidade. Mas esse imediatismo também criou uma infra-estrutura de aplicações com muita redundância de funções e responsabilidades, pouco flexível, cara de ser mantida e, principalmente, pouco ágil.

Mesmo as tecnologias que surgiram para promover padronização e integração, particularmente aquelas chamadas Middleware, em pouco tempo passaram a se digladiar na mesma infra-estrutura de TI, acrescentando mais complexidade e heterogeneidade.

Testemunhamos hoje o nascimento de uma série de tecnologias, processos e modelos que visam combater a imensa complexidade das estruturas de TI. Consolidação de servidores, virtualização e grid-computing, dentre outras, miram a racionalização dos recursos. Porém são propostas que visam quase exclusivamente os ativos palpáveis, desconsiderando as principais causas da falta de agilidade e flexibilidade das organizações de TI: as aplicações e os dados.

Por isso que a proposta de implementação de uma Arquitetura Orientada a Serviços (SOA – Service-Oriented Architecture) ganha importância e faz com que alguns institutos, como o Gartner, prevejam que será a arquitetura dominante nas corporações já em 2007[1].

SOA é uma estratégia que propõe a organização dos ativos de software de forma que eles possam representar Processos, Atividades ou Tarefas de Negócio de forma direta. Tais representações são chamadas de Serviços, que devem ser baseados em padrões e facilmente combinados e reutilizados visando a satisfação dos requerimentos do negócio.

A dinâmica do mundo dos negócios exige que as organizações de TI sejam ágeis, flexíveis e simples. São os mesmos meta-requerimentos que governam os Programas e Projetos SOA. Esta série apresenta as particularidades dos projetos SOA, os novos desafios apresentados e a possibilidade de realização, enfim, de antigas promessas como a Reutilização de Ativos de Software.

Apesar do aparente ceticismo e da profusão de definições desencontradas, naturais quando se trata de uma novidade apresentada como “panacéia” pelo mercado de TI, SOA deve se consolidar como uma nova forma de desenvolver, comprar e vender sistemas de informação. Se tal hipótese se confirmar, será a maior evolução da área desde a invenção do COBOL*. Que seja bem-vinda.


>>>>>>>>>> SOA #2 - Conceitos Básicos

* 1964

1. “Service-Oriented Architecture Scenario”, Yefim Natis
Gartner, artigo AV-19-6751 (2003).

Marcadores: arquitetura, gerenciamento_de_projetos, soa

ManagementSpeak: This company is ISO 9000 certified.
Translation: We have documents to prove who screwed up.

Hehe.. Sou fã do Bob Lewis desde que li "IS Survival Guide". No livro ele já tinha essa série, com "falas da gerência" e suas "traduções". Hoje ele mantém o site "IS Survivor" e o mesmo bom humor.

Para o artigo que estou desenvolvendo sobre "Projetos SOA" tive que mergulhar em alguns "Processos Ágeis". Gostei um tanto do Scrum, e agora tento adaptá-lo para o desenvolvimento de Serviços em uma SOA. Trabalho legal.

BTW, muito legal tb é o trabalho do Jeff Sutherland, criador do Scrum. Ele mantém um blog sobre o assunto. Foi lá que surrupiei a charge legalzinha aí de baixo:



Espero voltar ao tema em breve.