O artigo original da ZAPThink vai direto ao ponto: The true "meta-requirement" for SOA is to build an architecture implementation that addresses ever-changing business requirements. Line-of-business must drive such a meta-requirement.

Definitivamente os projetos SOA não podem ser guiados pelas organizações de TI. Vamos deixar claro que por 'projetos SOA' estou falando de cada processo de negócio sendo convertido no tal 'serviço'. Na situação ideal o projeto é capitaneado pelo 'dono' do processo de negócio. Aqui o bicho pega: 96,38% de nossas organizações só enxergam árvores hierárquicas quando se olham no espelho. Os 'capitães' são donos de departamentos, não de processos de negócio. Não entendo a razão de tanta resistência para a implementação de desenhos mais horizontais em nossas organizações. De qualquer forma, o problema aqui é fazer com que uma pessoa "do negócio" seja dona de determinado processo de negócio, futuro "serviço". É uma questão de escalabilidade também. TI nunca dará conta de 20 e poucos processos de negócio. Em empresas médias podemos ter mais de 100 processos candidatos a se transformarem em serviços!!

O desenho geral da arquitetura (subconjuntos 'Aplicações' e 'Arquitetura Tecnológica', como mostrei no 1o post da série) continua sendo responsabilidade exclusiva da área de TI.

A moral da história de ontem era "segura que o filho e seu". Pois bem, lembre-se que TI é a mãe. E os LOB's (linhas de negócios) são os diversos pais da criança. Como ainda não inventaram inseminação artificial para a implementação de SOA, devemos nos lembrar que o principal fator crítico de sucesso de um projeto SOA é o entrosamento entre a turma do 'negócio' e os caras de TI.


Moral da história: "O olho do dono é que engorda o boi."