SEMAT – Repensando a Engenharia de Software

Recentemente, notáveis do mundo da engenharia de software, liderados por Ivar Jacobson, Bertrand Meyer and Richard Soley, criaram um movimento para rediscutir as bases da engenharia de software.

O “SEMAT (Software Engineering Method and Theory) – Call for Action” sugere que não há organização na engenharia de software, que suas práticas são imaturas e, assim, convoca a comunidade para trabalhar seus fundamentos. O ponto de partida é a definição de uma base mínima conceitual, nomeada pelos idealistas por “Kernel”. A importância deste Kernel está na necessidade de “elencarmos o conjunto de elementos que são essenciais a todos esforços do desenvolvimento de software, um BoK (Body of Knowledge) compartilhado para acadêmicos, pesquisadores e profissionais”.

De fato, um dos pontos elencados pelo grupo como o principal problema da engenharia de software atual é a divergência entre a teoria do mundo acadêmico e a prática nas empresas. Em boa parte, este gap é devido aos apelos de marketing e buzzwords a que nosso “mundo” (de TI) está sujeito e muitas vezes parece até idolatrar (por um tempo).

Além dos já citados Ivar Jacobson, Bertrand Meyer and Richard Soley, outros nomes bem conhecidos que já escreveram vários livros sobre processos, metodologias e melhores práticas na engenharia de software também apoiam a ideia. Para citar alguns: Scott Ambler, Philippe Kruchten, Robert Martin, Alistair Cockburn e Erich Gamma. É relevante notar que alguns destes foram autores de metodologias mais tradicionais e outros de boas práticas ágeis.

O movimento já consta com muitos adeptos mas também já provocou opiniões contrárias, como pode ser acompanhado no post: “Against SEMAT”. O autor é da opinião de que os formalismos comuns das engenharias já consagradas (diferente da jovem engenharia de software, de apenas algumas décadas) não são sempre aplicáveis no desenvolvimento de software.

Não sou adepto às comparações de engenharia de software com engenharia civil. Acho até injusta esta comparação, justamente pela diferença de maturidade entre as duas. Há um artigo interessante que tenta explicar o RUP através de analogia com a produção de um filme: “Introducing the IBM Rational Unified Process essentials by analogy”. Entretanto, dizer que o desenvolvimento de software é uma arte, apesar de poético, é assumir que não há maturidade para entregar software de qualidade e de acordo com as necessidades do cliente. E pior ainda do que assumir isso é não agir.

O movimento SEMAT tenta, de certa forma, colocar ordem no caos. Eliminar o estigma de que software é um produto imprevisível, instável e que bugs são normais.

Como profissional da área, ao ver tantos especialistas se unindo neste movimento, sinto-me na obrigação de participar. Se vc também deseja apoiar, pode se subscrever na página do SEMAT.

Que nós desenvolvedores e a engenharia de software tenhamos prosperidade em 2010!

SOA Manifesto

Após o mundo de TI passar por algumas rodadas de disseminação do conceito SOA, sem esquecer de alguns tumultos “provocados” pelo post “SOA is Dead; Long Live Services”, alguns bam-bam-bans no tema, motivados por Thomas Erl e incluindo a autora do post citado, compilaram o “SOA Manifesto”. Segue uma tradução livre:

 

Manifesto SOA

Orientação a serviço é um paradigma que direciona o que você faz.
Arquitetura orientada a serviço é um tipo de arquitetura que resulta da aplicação de orientação a serviço.

Nós aplicamos orientação a serviço para auxiliar organizações a entregar valor de negócio sustentável de forma consistente, com maior agilidade e eficiência de custo, alinhado às necessidades de mudança do negócio.

Através de nosso trabalho nós priorizaremos:
Valor de negócio acima de estratégia técnica
Objetivos estratégicos acima de benefícios específicos de projeto
Interoperabilidade intrínseca acima de integração customizada
Serviços compartilhados acima de implementações de propósito específico
Flexibilidade acima de otimização
Refinamentos evolutivos acima de busca da perfeição desde o início
Ou seja, enquanto nós valorizamos os itens da direita, nós valorizamos ainda mais os itens da esquerda.

 

Princípios que Guiam o Manifesto SOA

Nós seguimos estes princípios:
Respeitar a estrutura social e de poder de uma organização.
Reconhecer que SOA requer mudança em vários níveis.
O escopo da adoção de SOA pode variar. Manter esforços gerenciáveis e dentro de limites significativos.
Produtos e padrões sozinhos não lhe fornecerão SOA nem aplicarão o paradigma de orientação a serviços para você.
SOA pode ser concretizada através de várias tecnologias e padrões.
Estabelecer um conjunto uniforme de políticas e padrões corporativos baseado em padrões de facto da indústria e da comunidade.
Buscar uniformidade no exterior e permitir diversidade no interior.
Identificar serviços através da colaboração entre interessados de negócio e tecnologia.
Maximizar o uso de serviços considerando o escopo atual e futuro de utilização.
Verificar se os serviços satisfazem os objetivos e requisitos de negócio.
Evoluir os serviços e sua organização em resposta ao seu real uso.
Separar os diferentes aspectos de um sistema que mudam em ritmos diferentes.
Reduzir as dependências implícitas e publicar todas as dependências externas para aumentar a robustez e reduzir o impacto de mudanças.
Em todo nível de abstração, organizar cada serviço em torno de uma unidade de funcionalidade coesa e gerenciável.

 

E ai, concorda? Então vai lá e “assina embaixo”! :-)

Engenharia de Software – Escopo, Prazo, Custo e Qualidade

Sempre que falamos em desenvolvimento de software surge o triângulo:

Não há mágica a ser feita. Para uma mesma área, aumentar um lado implica em diminuir um outro. Mas isto pressupõe que o escopo é (totalmente) conhecido e, o mais importante, não sofrerá mudanças. Já foi esse tempo, não dá mais pra atender ao cliente com escopo fechado. Já dizia o filósofo Heráclito: “a única constante é a mudança”.

No artigo do Ivar Jacobson “Closing the Gap between Business and IT”, ele cita:

“We need to deliver results often and with high quality, on frequent intervals.  IT will have to accept that the business will change its mind about what it wants. This is a natural part of seeing results more frequently, and the feedback obtained is valuable and important. Frequent demonstrations of progress creates confidence and increases productivity, quality and it gives quick results.”

Em resumo, temos que saber lidar com a mudança e demonstrar resultados rapidamente e com qualidade.

Em outro artigo, da Marília Coelho, “Precisamos ser mais psicólogos que engenheiros para ter sucesso com engenharia de software”, a autora fala das dificuldades no entendimento do problema do cliente e cita uma frase de Einstein:

“Einstein certa vez afirmou que se ele tivesse uma hora para salvar o mundo, gastaria 55 minutos definindo o problema e apenas cinco minutos buscando a solução.”

Isto tem a ver com a “pressa” e com a visão míope do “dá pra fazer”, sem buscar o entendimento sobre a real necessidade do cliente e sem explorar as alternativas mais apropriadas.

Ela também cita alguns dados do Standish Group:

“41% dos projetos falham em adicionar valor ao negócio e sobre o Retorno de Investimento – ROI.

49% dos projetos ultrapassam as estimativas iniciais de custo.

Somente 28% dos projetos acontecem no prazo e no orçamento.”

O escopo fechado traz, no início do projeto, a ilusão da certeza do prazo e do custo. Qualquer mudança posterior é temida! A tal da “change request”!

A autora ainda discorre sobre a necessidade de mudança de cultura na engenharia de software e conclui:

“Para que os três pilares – processo, ferramentas e pessoas – funcionem de forma harmônica na organização, o suporte executivo é fundamental, pois as ansiedades, e a pressão do “fazer para ontem” são forças que devem ser gerenciadas corretamente. Os números mostram que continuar como está não é bom para o negócio e não é bom para TI. Pense em fazer algo para mudar o futuro da engenharia de software, conseqüentemente mudando a percepção de que TI não é um centro de custo, mas sim uma área que agrega valor ao negócio através da inovação tecnológica.”

Pensamentos Finais

Escopo muda, é um fato, e assim deveria ser tratado. Com entregas ágeis, frequentes e com qualidade o prazo (final) deixa de ser um “bicho-papão” e a previsibilidade sobre o custo torna-se maior. Ganhar a confiança do cliente, mantendo-o sempre envolvido, aumenta as chances de sucesso pois, no fim das contas, há um relacionamento humano.

Vida longa e próspera à engenharia de software!

Certificação - Análise e Design

Análise e Design são atividades do ciclo-de-desenvolvimento de software que lidam, respectivamente, com o tratamento/entendimento do problema e a "criação" da solução técnica para atender os requisitos de software do projeto.

No contexto do RUP (Rational Unified Process), Análise e Design são apresentadas no formato de uma disciplina. Esta disciplina engloba fluxo de trabalho, atividades, papéis e artefatos que orientam o entendimento do problema e a elaboração da solução técnica do software a ser desenvolvido. É nesta disciplina que um dos assuntos mais relevantes do processo unificado é tratado: Arquitetura de Software.

Este post cita, para os amigos leitores, duas certificações relacionadas a A&D.

A primeira não se trata realmente de uma certificação de A&D, mas de UML. Ou seja, tem o intuito de avaliar o quanto você domina a linguagem visual mais usada para representar os modelos de A&D.

 

Certificação UML - OMG:

Site para certificação UML 2 da OMG:

OMG Certified UML Professional (OCUP)

Há 3 níveis de certificação:

• Fundamental: conceitos básicos, principais elementos e diagramas;
• Intermediate: amplia o escopo e exige conhecimentos mais avançados dos elementos da UML;
• Advanced: amplia ainda mais o escopo chegando a exigir conhecimentos sobre a arquitetura da linguagem, representação de semântica usando UML, relação com MDA, conhecimento da OCL (Object Constraint Language) que é uma linguagem de texto que estende a UML para definições e restrições de modelos e metamodelos que não são simples ou mesmo possíveis de serem feitos por diagramas, etc.

Para nós, reles mortais, não parece valer muito a pena ir além da Intermediate. Talvez a Fundamental já baste.

Apesar de interessante (principalmente para o mercado), a certificação de UML, como já dito acima, é limitada à especificação de UML. No escopo de A&D, UML é uma ferramenta (poderosa) que pode ser usada para representar os modelos, através de seus vários diagramas: caso de uso, classes, sequência, implantação, para citar alguns.

De outra forma, uma certificação que avalie o grau de maturidade de um analista quanto ao emprego da UML como ferramenta, além do conhecimento de padrões de design e boas práticas de A&D (baixo acoplamento, alta coesão, poder de abstração, identificação de interfaces, etc) parece ser mais relevante.

A certificação de A&D da IBM Rational abrange todos estes quesitos. Entretanto, é bom deixar claro que ela é fortemente baseada na disciplina de A&D do RUP. Ou seja, além de avaliar estes quesitos, ela também exige seus conhecimentos específicos na disciplina de A&D do RUP. Não sei se isto pode ser ruim, visto que RUP é um dos processos mais seguidos no mundo. Assim, mesmo que sua empresa não siga o RUP, um profissional com conhecimento profundo sobre esta disciplina só tem a acrescentar. Isto se aplica especialmente para arquitetos de software e designers.

 

Certificação A&D - IBM Rational:

Site para certificação de A&D da Rational:

IBM Certified Solution Designer - Object Oriented Analysis and Design, vUML 2

Para obter a certificação é necessário passar em 2 testes:

1. Test 833 - Object Oriented Analysis and Design - Part 1 (Analysis): trata questões relacionadas ao entendimento do problema;
2. Test 834 - Object Oriented Analysis and Design - Part 2 (Design): exige conhecimentos que afetam a definição da solução técnica para os requisitos de software.

Referências

- Livros sobre o assunto que vale a pena conferir:

• UML Distilled: A Brief Guide to the Standard Object Modeling Language
• Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development
• UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design
• Design Patterns: Elements of Reusable Object-Oriented Software

- Um colega blogueiro postou algumas dicas sobre A&D, confiram em: Análise e Design: Para que serve e como fazer? [José Papo].

 

Dicas

- Estude bem a disciplina de A&D do RUP

- Leia os livros UML Distilled e Applying UML and Patterns

- Entenda a aplicação de design patterns

- Por último, mas talvez o mais importante: pratique A&D!

Boa Sorte!!!

Refatoração em Banco de Dados

Muitos de nós já estamos acostumados com o termo Refactoring, uma boa prática amplamente divulgada por Martin Fowler. 

Refatoração = remodelar (reprojetar) sem alterar comportamento.

O termo tornou-se comum quando falamos em programação orientada a objetos, mas o conjunto de boas práticas pode ser estendido a outros nichos, como programação em banco de dados.

O livro “Refactoring Databases”, do Scott W. Ambler, trata das técnicas de refactoring empregadas em banco de dados (mais informações ao final).

Selecionei deste livro 2 exemplos de Refatoração em Banco de Dados: “Replace Column” e “Merge Columns” . Segue resumo.

 

1 – Replace Column (página 126)

Motivação: O tipo da coluna deve ser alterado (ex.: numérico para alfanumérico).

Exemplo: Para um dado sistema, a informação que identifica um Usuário deve ser mantida no formato Alfanumérico. Atualmente, esta informação é armazenada no BD no formato Numérico. Vejam na figura abaixo os schemas original, do período de transição e o final.

Mecânica de Alteração:

1) Cria-se a nova coluna (CustomerID);

2) Torna-se a coluna que será substituída (CustomerNumber) deprecated. Ou seja, a coluna é marcada para eliminação. No exemplo, isto é representado através da indicação “{drop date = June 14 2007}”

a. Deprecate é um termo comum em Java utilizado para indicar que um método de uma classe está defasado e, possivelmente, será eliminado desta classe em uma próxima versão.

3) Cria-se uma trigger (SynchronizeCustomerIDNumber) para manter as informações das colunas sincronizadas. A trigger deve ser invocada para qualquer mudança nas colunas. Esta trigger já deve “nascer” deprecated. No exemplo, isto é representado através da indicação “{event = update | insert, drop date = June 14 2007}”;

4) Converter os dados da coluna original para a nova coluna (CustomerNumber para CustomerID);

5) Durante o período de transição, deve-se atualizar outras tabelas e os programas que acessam o dado alterado (refatorar os códigos e atualizar validações de dados).

6) Após o período de transição, elimina-se a coluna anterior (CustomerNumber) e a trigger.

Figura 1. Exemplo de alterações em um schema utilizando a Técnica de Refatoração BD “Replace Column”.

 

2 – Merge Columns (página 92)

Motivação: Existência de colunas que guardam a mesma informação (replicação de informação); Informação “quebrada” em várias colunas; Colunas com informações similares que convergiram para uma mesma informação.  

Exemplo: Para um dado sistema, o número de telefone do Usuário deve ser mantido como uma informação única obtida da concatenação de Código de Área e Local. Atualmente, é guardado no BD separando os códigos de País, Área e Local. Vejam na figura abaixo os schemas original, do período de transição e o final.

Mecânica de Alteração:

1) Cria-se a nova coluna (PhoneNumber);

2) Marca-se as colunas anteriores como deprecated. No exemplo, isto é representado através da indicação “{drop date = December 14 2007}”

3) Cria-se uma trigger (SynchronizePhoneNumber) para manter as informações das colunas sincronizadas. A trigger deve ser invocada para qualquer mudança nas colunas. Esta trigger já deve “nascer” deprecated. No exemplo, isto é representado através da indicação “{event = update | insert, drop date = December 14 2007}”;

4) Converter os dados das colunas originais para a nova coluna (PhoneNumber = merge column);

5) Durante o período de transição, deve-se atualizar outras tabelas e os programas que acessam o dado alterado (refatorar os códigos e atualizar validações de dados).

6) Após o período de transição, elimina-se as colunas anteriores (PhoneAreaCode e PhoneLocal) e a trigger.

Figura 2. Exemplo de alterações em um schema utilizando a Técnica de Refatoração BD “Merge Columns”.

 

Mais sobre o livro

Antes de apresentar as técnicas de refatoração em si, o livro explica como a idéia surgiu e evoluiu. Também é apresentado um processo que visa orientar na aplicação destas técnicas. A importância sobre Testes em Banco de Dados é ressaltada.

Várias outras técnicas são apresentadas. Elas são subdivididas nas categorias: Estruturais (os 2 exemplos acima estão aqui), Qualidade de Dados, Integridade Referencial, Arquiteturais e Métodos.

Sobre o Autor:

O autor, Scott W. Ambler, é bem conceituado e já escreveu vários livros sobre os assuntos: Orientação a Objetos, Processo Unificado, Métodos Ágeis, EJB, Bancos de Dados, UML, etc

Ele mantém um site sobre suas obras.

URL: http://www.ambysoft.com/scottAmbler.html

Há também o site do livro que apresenta um “Catálogo de Refatorações de Banco de Dados”.

URL: http://www.agiledata.org/essays/databaseRefactoringCatalog.html

Boa leitura!

WebServices - Integração X SOA

(Depois de um longo tempo sem postar, mas acumulando muita informação, vamos retomar o compartilhamento.)

Uma das primeiras dúvidas que surge quando se inicia o estudo de SOA é se "WebServices e Serviços em SOA" são a mesma coisa. A dúvida é natural, até mesmo por conta do termo "serviço".

Nota: Aliás, o termo "serviço" gera confusões a todo momento, não somente com relação a WebServices, mas porque se trata de um termo com aplicabilidade em vários contextos. E (felizmente ou infelizmente) não costumamos empregar "namespaces" ao estabelecermos diálogos. Assim, enquanto a adoção de SOA se encontra em processo de disseminação na empresa, conversas do tipo "melhorar a eficiência dos serviços da empresa" geram dúvidas sobre se estes "serviços" têm relação com SOA ou não. Pode ser que haja a relação, caso se trate de um processo de negócio automatizado, ou em vias de ser automatizado, que demandará o uso de Tecnologia da Informação para acesso a alguma funcionalidade de negócio, como por exemplo uma "reserva de tickets". Mas, pode ser que os "serviços" a serem melhorados sejam trabalhos operacionais que envolvam, por exemplo, a redistribuição de tarefas entre funcionários. Parece estranho, mas acontece. Vez por outra você estará questionando ou explicando que o "serviço" em questão trata-se ou não de SOA. E não raramente, passará a usar de termos como "Serviços SOA".

Um dos erros mais comuns é achar que o uso de WebService (WS) significa adotar SOA. SOA não se trata de uma tecnologia ou linguagem, mas uma mistura de um estilo arquitetural e método de desenvolvimento refletindo uma estratégia de negócio.

Alguns projetos requerem a integração entre aplicações de diferentes tecnologias. Isto pode ser realizado através de WS. Para projetos suportados por uma estratégia SOA, WS também podem ser utilizados como tecnologia para "concretização" dos serviços.

Segue um quadro comparativo do uso da tecnologia de WebServices nestas abordagens:

	WS para Integração	WS em SOA
Foco	Técnico	Negócio
Requisitos	Interoperabilidade	Consumo (ou exposição) de funcionalidade de negócio
Desafios	Governança TI, Versionamento	Governança SOA, Versionamento, Granularidade
Benefícios	Flexibilidade para alterações na camada de integração	Interoperabilidade, Agilidade na mudança de processos de negócio
Ferramentas	UUDI, ESB	Registry, ESB, BPMS

WS - Integração X SOA

Algumas diferenças são sutis, como a questão da interoperabildiade. Em um problema de integração a interoperabilidade surge como um requisito, uma condição que deve ser atendida. Apesar de também ser importante em SOA, a interoperabilidade, ao utilizar WS, surge mais como um benefício.

A relação entre estas abordagens permeia entre a estratégia de negócio e o uso de tecnologia. Um problema de integração pode não demandar qualquer estratégia orientada a serviços. Entretanto, uma SOA tratará a integração como um de seus pilares.

 

Pensamentos Finais

Há uma diferença crucial na estratégia de uso da tecnologia WebServices para realização de Serviços em SOA e para Integração: "Meio e Fim". Enquanto que para Integração, WS pode ser a solução (fim). Para SOA, WS é o caminho mais apropriado atualmente (meio).

Papéis em SOA - Identificando Serviços

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 Responsabilidades
A 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 Responsabilidades

Há 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ção
O 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ção

• Cliente 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 Finais
O 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 Management
Requiremens Process for SOA Projects
An Introduction to SOA Solution Scenarios
Create the Ideal SOA Team
SOA Project Planning Aspects