DA Insight: Qual sua atuação junto ao SEI?

Paulo Merson: No SEI eu trabalho no grupo de arquitetura de software e em outro grupo chamado PACC (Predictable Assembly from Certifiable Components).

DA Insight: Atualmente, em quais projetos você está envolvido e quais cursos está ministrando?

Paulo Merson: Acabamos de publicar relatório sobre avaliação de arquiteturas SOA (Arquitetura Orientada a Serviços). Agora estou trabalhando em outros dois relatórios, um sobre SLAs (Service Level Agreements) para SOA e outro sobre técnicas para Architecture Enforcement, isto é, soluções para o seguinte problema: o arquiteto criou e documentou uma arquitetura muito boa, mas como garantir que os desenvolvedores vão seguir o que foi especificado? Como garantir a conformidade do código com a arquitetura anos depois, quando o sistema está em manutenção e há uma rotatividade natural entre os programadores? Uma técnica interessante é usar a programação orientada a aspectos, mas há outras alternativas e ferramentas que estamos avaliando. Além disso, atualmente ministro um dos cursos do nosso currículo de arquitetura de software. Esses cursos, que ocorrem em turmas abertas em Pittsburgh e em turmas fechadas em empresas, são uma ótima oportunidade para interagir com arquitetos experientes da indústria e validar nossas idéias.

DA Insight: Qual a importância de SOA para as empresas?

Paulo Merson: Antes de trabalhar para o SEI, eu era consultor J2EE e trabalhei em projetos onde uma aplicação J2EE precisava falar com transações CICS no mainframe, ou com DLLs, ou com um sistema Delphi na rede, e por aí vai... Essa integração dava muito trabalho! Tínhamos de desenvolver ou adaptar pontes e conectores. Demorava muito para fazer tudo funcionar e a solução era específica, pouco modificável e muito vulnerável a mudanças no ambiente. Com SOA, a integração de ambientes heterogêneos ficou muito mais fácil.

DA Insight: No geral, quais as vantagens e desvantagens do uso de SOA?

Paulo Merson: SOA ampliou o horizonte dos sistemas. Hoje, um arquiteto que precisa de uma informação que está em outra organização pode acessá-la como um serviço usando, por exemplo, tecnologia Web Services. Apesar do grande impacto em ampliar o escopo das aplicações, do ponto de vista técnico SOA não traz grandes inovações. Tecnologias de componentes distribuídos mais antigas - como DCE, CORBA e DCOM - tinham objetivos e conceitos semelhantes, mas nunca atingiram o nível de adoção na indústria e a facilidade de uso de Web Services. Certamente, a interoperabilidade é a principal vantagem de SOA. Contraposto a isso, e eu não diria que são desvantagens, em geral as maiores preocupações são desempenho, testabilidade e segurança.

DA Insight: Qual a relação entre Desenvolvimento Baseado em Componentes (CBD), reúso e SOA?

Paulo Merson: Um serviço é um componente distribuído cuja implementação (na teoria) é irrelevante para o usuário, que só enxerga a interface publicada. Então, quem desenvolve baseado em componentes já possui elementos arquiteturais (os componentes) com encapsulamento adequado para a abordagem SOA. CBD e SOA são abordagens que naturalmente promovem o reúso por que prescrevem a criação de componentes independentes e altamente modulares, ou seja, reutilizáveis. Mas atingir o reúso sistemático de componentes de negócio requer mais. E esse “algo a mais” pode ser uma abordagem de linhas de produto.

DA Insight: Para descrever e documentar uma arquitetura qual seria a melhor forma?

Paulo Merson: O importante é lembrar que a arquitetura consiste de múltiplas estruturas. Então devemos documentar essas diferentes estruturas. Temos, por exemplo, a estrutura das unidades de código (mostrando módulos, pacotes, classes, etc), a estrutura do sistema em tempo de execução (mostrando EJBs, DLLs, repositórios de dados e threads, entre outros), a infraestrutura de hardware e a estrutura dos arquivos de deployment. Até mesmo o modelo de dados é uma estrutura da arquitetura. Uma sugestão prática é criar um template de documento de arquitetura que permita documentar essas várias estruturas - e seguir sempre esse template.

DA Insight: Como se utiliza o Método de Avaliação de Arquitetura ATAM (Architecture Tradeoff Analysis Method) do SEI?

Paulo Merson: O ATAM é um dos métodos mais bem sucedidos do nosso grupo. Uma equipe de avaliação (4 a 5 pessoas) visita a equipe do sistema por 1-2 dias na fase 1 e por mais 1-2 dias na fase 2. Na fase 1, a conversa é basicamente com o pessoal mais técnico. Na fase 2, a participação é aberta para os vários stakeholders do sistema, do usuário final ao DBA. Por meio da identificação de padrões, táticas e abordagens arquiteturais em geral, os avaliadores ATAM analisam a capacidade da arquitetura em atender os requisitos de atributo de qualidade. Esses requisitos são elencados e priorizados pelos próprios stakeholders durante a avaliação. No final, temos uma lista de riscos e recomendações. Outros benefícios do ATAM são a melhor documentação da arquitetura, maior integração entre os stakeholders - sinergia importante para o projeto - e a identificação de requisitos de qualidade essenciais que, às vezes, eram desconhecidos pelo arquiteto.

DA Insight: Um método para avaliação de qualidade de SOA teria algum complicante?

Paulo Merson: O método em si, o processo, não precisa mudar. A diferença é que na abordagem SOA o número de decisões arquiteturais a ser analisado é enorme. Existem várias opções para a comunicação (SOAP, REST, MOM), há a opção de fazer uso de um ESB, usar BPEL, usar um diretório de serviços, há alternativas diferentes para segurança das mensagens, autenticação e autorização, integração com sistemas legados, serviços síncronos ou assíncronos e granularidade das interfaces, só para citar alguns. É difícil lembrar de tudo e, dependendo dos requisitos, uma dessas decisões arquiteturais pode ser crítica para o sucesso.

DA Insight: Para quem quiser se aprofundar em temas como Qualidade de Arquiteturas SOA, qual seria uma boa referência?

Paulo Merson: Pesquise no Google por "CMU/SEI-2007-TR-015" e você vai achar o nosso relatório que contém informações importantes para qualquer arquiteto que está criando ou avaliando uma solução SOA. Pesquise por "quality attributes for service-oriented architectures" e você vai achar um artigo (parece acadêmico, mas é voltado para o pessoal da indústria) que fala sobre quais atributos de qualidade são positivamente ou negativamente afetados pela abordagem SOA.