Arquiteturas e Arquitetos

Não é somente no termo "Arquitetura" que há uma profusão de significados quase sempre conflitantes e muitas vezes incompletos dentro do contexto de SOA. O mesmo ocorre para os "Arquitetos". Afinal há diversos tipos de arquitetos: Hardware, Software, Aplicação, Rede, Integração, etc, etc, etc. Para complicar os termos "SOA" e "Arquiteto SOA" encontram-se em uma quantidade enorme de currículos técnicos atualmente. Enfim, a simples palavra "Arquiteto" não indica muita coisa...

Algumas distinções são possíveis, todavia:
Arquiteto de Aplicação: preocupado principalmente com aspectos "intra" aplicação. O popular assunto "aplicação em n-camadas" é o tema aqui. As famosas camadas de "apresentação", "negócio" e "acesso a dados" normalmente são lembradas. Uma ilustração abaixo:

Os conhecimentos esperados deste Arquiteto seriam, por exemplo:

• Tecnologias Java e Java, Enterprise Edition, JBI (Java Business Integration), etc.
• "Frameworks" bem conhecidos de mercado como Struts, JSF, Seam, Spring, Hibernate, etc, etc, etc.
• Web Services
• "Software Design Patterns".
• Na maior parte do tempo, suas preocupações são de ordem funcional apenas.

Arquiteto de Software: normalmente não é o responsável pela arquitetura de aplicações. Sua atuação é voltada a aspectos "inter" aplicações, sistemas e pacotes de mercado (CRMs, ERP, etc). Lida com componentes do ecossistema tecnológico do ambiente incluindo: Servidores de Aplicação, Servidores Web, Servidores de Diretorio (LDAP, MS Active Directory, etc), Portal, ESB, BPM, RDBMS, Mainframes, "Brokers" de Mensagens, Monitores de Transações, Autenticação e Autorização de Usuários, PKI ("Public Key Infrastructure"), etc, etc, etc. Um pequeno exemplo simplificado de uma arquitetura de software está a seguir. Note que neste diagrama há os dois níveis de arquitetura descritos: "inter" e "intra" componentes.


Sua visão é muito mais ampla do ambiente e com nível de detalhe suficiente para a elaboração e evolução de Arquitetura de Sofware. Por exemplo, o fato de uma aplicação ter sido escrita em Java e ter feito uso ou não de EJB ("Enterprise Java Beans") é totalmente irrelevante. Por outro lado, a implementação dos requerimentos não funcionais é de responsabilidade do Arquiteto de Software como Balanceamento de Carga para Servidores Web e Servidores de Aplicação, Alta Disponilidade e/ou Persistência de sessão HTTP, Replicação de Dados em Servidores LDAP, etc, etc, etc.
Claro que há especializações de Arquitetos de Software para aprofundamento de cada um dos componentes. O assunto pertinente a Gerenciamento de Banco de Dados, por exempo, é tão crítico que existem arquitetos que conhecem em detalhes as questões de desenho de banco de dados, otimizações, etc. E também é importante destacar que a "visão do todo" não é uma necessidade exclusiva de projetos SOA mas sim de qualquer ambiente ou projeto.

Arquiteto SOA: Apesar dos perfis de Arquitetos acima (e além deles outros mais) serem fundamentais e igualmente importantes em quaisquer projetos críticos, um novo perfil é preciso. Espera-se que um Arquiteto SOA lide com questões de análise de requerimentos de negócio assim como o desenho técnico de sofware. Em outras palavras, que o Arquiteto SOA possa servir, dentre outras coisas, de "ponte" entre os analistas de negócio e os Arquitetos de Software e de Aplicação. Não é uma boa idéia termos em uma mesa de reunião de um lado analistas de negócio preparados para discutirem Cadeia de Suprimentos em um projeto B2B ou "billing" convergente em um projeto de Telco e de outro desenvolvedores decidindo que Struts é mais eficiente do que JSF.

Os arquitetos SOA tipicamente, então, deveriam estar preparados para a análise, desenho e especificação da Camada de Serviços, estratégias "top-down", "meet in the middle", relacionamento e composição de serviços, etc.

Em resumo, Arquitetos de Software e de Aplicação são absolutamente necessários mas não suficientes. Além deles, e principalmente em projetos críticos como é o caso de SOA, devem existir outros perfis. Os conhecimentos devem ser expandidos para tornar a implementação de SOA realmente voltada às necessidades de negócio. O analista David Linthicum, autor de diversos livros, dentre eles "Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide", escreveu em seu "blog" um artigo sobre consultores SOA chamado "Most SOA Consultants Need a Lesson in SOA". Trata justamente sobre o dano que a difusa compreensão de termos como SOA e Arquitetura causa no montagem de uma equipe para um projeto como esse.