SOA, Simples Assim!

Existe existia uma idéia pré-concebida na minha mente que SOA e BPM devem ser iniciativas “casadas”, parte de um processo único. O resultado pode ser catastrófico. Algumas razões:

• SOA é estilo de arquitetura que utiliza fortemente o conceito de serviços para a construção de aplicações compostas
• BPM é sobre análise de processos de negócios e otimização
• A turma de Business Process Management (BPM) encontra na arquitetura orientada a serviços (SOA) a abordagem ideal para colocar em prática os processos de negócio que irão permear por toda a organização
• Quando se fala de Business Process a tecnologia é o menor dos problemas. Política, resistência de alguns departamentos, problemas inevitáveis de comunicação, falta de direcionamento estratégico, áreas ou empresas dispersas geograficamente… …estes são os desafios da implantação de BPM

A utilização de uma arquitetura orientada a serviço pode ser parte de um esforço, de uma estratégia de BPM, porém ter as duas iniciativas de forma concorrente é um forte indício de que você esteja utilizando a abordagem “Big Bang” (que deve ser evitada).

SOA e BPM tem objetivos diferentes e métricas diferentes. Como afirmou J P Morgenthal em seu blog, “The Tech Evangelist“:

…SOA and BPM each have their own metrics of success and their ownbarriers to success. Combining them into one, well, the words “boilingthe ocean” comes to mind

Afinal, qual o papel do Analista de Negócio?

Ele precisa entender de arquitetura orientada a serviço? Não! Seu foco deve ser localizar e extrair dos stakeholders as informações necessária para capturar o “as is” (hoje) e ajudar a definir o “to be” (amanhã). Acredite, é a parte mais difícil.

Para ganhar agilidade no processo e evitar entrevistas desnecessárias com os clientes (internos ou externos), um(a) arquiteto(a) SOA deve acompanhar o(a) analista de negócio.

Se você quiser saber quais as oito competências que todo  Analista de Negócios deve ter, eu aconselho a leitura deste artigo: “Eight Competencies a Business Analyst Needs to Know“.

Bottom-up, Top-down, “Goal-oriented”?

Geralmente (isto não é regra) as equipes com foco na arquitetura SOA utilizam a abordagem “bottom-up“, em que os arquitetos especificam Serviços com base em “capacidades” (capabilities) que já existem. O risco desta abordagem é resultar em implementação de Serviços que não correspondem com os requisitos do processo. É o problema da “visão de poço” ou “visão de profundidade” em que coloca-se muito foco na tecnologia e, por vezes, esquecemos o objetivo maior, que faz parte de um processo de negócio.

Do outro lado, analistas de negócio (BPM), que geralmente utilizam excessivamente abordagens “top-down” irão tentar otimizar processos sem levar em conta o detalhamento que permitirá a implementação de um Serviço.

Qual a solução? A que eu recomendo é a utilização de iterações em que visita-se do topo (“top“) até a base (“bottom“), ou seja, verifica-se o processo “to be” mapeado pela equipe de BPM e a definição do(s) Serviço(s) projetado(s) pela equipe de arquitetos SOA.

Avançando nesta discussão o ideal seria ter definidos objetivos (“Goals“) factíveis e de curta duração, com grande visibilidade, e adotar esta ação conjunta “bottom-up”+”top-down” com um Goal de negócio como meta. A isto eu defino como “Goal-oriented“.

Abraços,

Davi

(atualizado às 08:10 PM para atualização do tópico “Bottom-up, Top-down, “Goal-oriented”?)