SOA: 10 Erros a Serem Evitados nos Projetos

Mais um lista do que fazer e do que não fazer nos projetos que utilizam SOA como arquitetura? Sim, esta é uma daquelas listas. Entretanto, todos nós temos a ganhar quando compartilhamos este tipo de experiência (What You should do, What You Should not do).

Desta vez Paul Callahan (diretor da empresa NetManage) escreve esta nota para o site da ZDNet.com com suas opiniões sobre os 10 principais erros que você deve evitar ao implementar projetos utilizando a arquitetura orientada a serviços (meus comentários em azul):

1. Taking a shotgun approach: segundo o autor, disponibilizar todos os serviços é desnecessário e vai custar muito. O correto é avaliar quais serviços, de fato, precisam ser disponibilizados. Aqui não tem segredo. Os times de TI, com ajuda dos analistas de negócios, devem mapear antes os processos de negócio, candidatos a tornarem-se serviços. O passo seguinte é priorizar e definir quais deles precisar ser adequados, reescritos (se for o caso) e realizar as implementações necessárias para disponibilizar as informações como serviços.
2. Failing to involve business analysts: sem comentários. Envolva o pessoal de negócios desde o início. Sua prioridade deve ser expor as informações de negócio e não desenvolver Web services.
3. Spending more time on SOA products than SOA Planning: Planejamento e Governança. Produtos e ferramentas são importantes mas eles não servirão de nada sem o devido planejamento prévio e sem Governança desde o 1o. dia.
4. Tackling the largest projects first: Não tente "abraçar o mundo". Projetos pequenos diminuem os risco da implantação e trazem resultados mais rápidos. Discodo do autor apenas no quesito "visibilidade". Na minha opinião um projeto que traga visibilidade é importante para você ganhar apoio da alta direção e mostrar para a empresa um retorno rápido do investimento.
5. Forgetting that SOA is a business Problem: discussões sobre SOA não devem se ater a aspectos técnicos. SOA existe para nos ajudar a resolver problemas de negócio; e o negócio deve ser o mais importante, não os aspectos técnicos.
6. Treating identity as an afterthought: de acordo com o autor, as empresas tendem a adiar questões de controle de acesso. Bom, isto tem a ver com Governança (vide item 3 acima).
7. Buying new products when existing investments suffice: este é um velho problema. As empresas esperam implementar SOA comprando hadware e software. SOA é um estilo de arquitetura, não um produto, e está relacionada com uma "vontade política" de resolver alguns dos problemas de integração de sistemas, agilidade e alinhamento com as áreas de negócio. Porém, muitas decisões de arquitetura não envolvem, necessariamente, investimento direto.
8. Misunderstanding company key players: quem são as áreas afetadas pelos processos? De acordo com o autor, é importante envolver estes departamentos nas discussões, do contrário corremos o risco de ter grandes resistências.
9. Expecting the SOA project to spread quickly: implantar SOA não é como instalar um novo serviço de e-mail. Leva tempo para a empresa "absorver" e entender os benefícios desta nova abordagem.
10. Lacking necessary elements: neste ponto o autor alerta que muitas empresas pequenas não tem pessoal qualificado para implementar uma mudança de arquitetura. Esta é uma decisão de cada empresa. O que eu posso garantir a vocês é que não se aprende sobre SOA apenas lendo revistas (ou blogs como este).