Governança SOA e Kanban


Não é novidade para ninguém que ao seguir uma estratégia de construção de uma Arquitetura Orientada à Serviços em qualquer empresa é necessário endereçar o tema governança soa. Isto acontece devido ao seguinte fato: Não existe mágica!

Toda empresa tem como objetivo aumentar sua margem de lucro e uma das formas de alcançar este objetivo é maximizando o retorno em cima dos investimentos feitos ao comprar ou construir um ativo. E SOA justamente vem para nos ajudar nesta tarefa, com a orientação a serviço começamos a construir diversos serviços atomicos, granulares que ficam disponíveis em um repositório corporativo e que podem atender diversos propósitos diferentes de negócio, por meio da composição do mesmos e outros ativos da empresa. E é neste ponto que as pessoas se iludem e esperam por um truque de mágica, o que acontece é que cada vez mais são feitas ligações entre serviços, dados, aplicações e outros ativos, o que pode sugerir complexidade. Mas isso é bom, pois estamos maximizando o retorno em cima do investimento feito, lembram?

Bom, mas para não criarmos complexidade em demasia, causar confusões e aumentar o custo com operação, precisamos manter este repositório de ativos bem organizado, disponível para toda empresa, e uma parte crucial, que é o foco deste post, os ativos devem estar aderentes aos processos e requisitos de negócio, diretrizes técnicas, de qualidade, segurança, devem ter documentações relativas a implantação, manutenção e uso. E para atender a todos estes pontos é necessário um processo bem definido, com artefatos obrigatórios, papéis, e etapas que endereçem todos os pontos mencionados anteriormente.

O caminho comum de toda a empresa é procurar um software que suporte este processo. Mas existe uma solução alternativa, que está muito aderente ao cenário atual em que várias empresas se encontram, que é o de ter um pensamento Lean e fazer uso de metodos agéis. Esta alternativa é bem mais barata e que dependendo da disciplina do time pode ser bem mais eficaz que um software. Estou falando do Kanban. Para quem não conhece, Kanban segundo Wikipedia

E seguindo na mesma linha em que os sábios do google pregam a muito tempo de experimentar, errar rápido, e baseado nos dados concretos oriundos da experiência evoluir a solução e acertar, criamos em minha empresa uma primeira versão de um quadro Kanban. Ele contempla todo o ciclo de vida de um serviço, desde a análise de uma demanda/projeto e identificação de um serviço até o seu deploy. Cada fase do ciclo de vida vira uma etapa do processo, e consequentemente uma coluna no quadro. Adicionamos também etapas/colunas que são passos de aprovação, QA e acompanhamento pós deploy. Uma ação que está agregando valor,  foi definição de “critérios de pronto” para cada etapa, ou seja, um serviço só sai da fase de modelagem e vai para fase de construção se alguns artefatos forem entregues como por exemplo os cenários de teste e o contrato do serviço.

Um benefício interessante de utilizar o quadro é que temos um “modelo mental coletivo e colaborativo” que fica mais fácil de todos do time seguirem, guardarem e contruibuirem para a evolução do mesmo.Ele ainda  nos ajuda a focar no que é necessário e agrega mais valor para o negócio (Lean) e ainda no momento que é necessário, seguindo a filosofia do just in time.

Se tiverem experiências parecidas com Governança SOA e Kanban ou outras filosofias e metódos ageis, por favor compartilhem!

Http Request
Get /taas/autor/carlosfilho HTTP/1.1
Http Response
HTTP/1.1 410 Gone

As 3 visões da Arquitetura Orientada a Serviços


Durante a edição brasileira do SOA Symposium, que aconteceu em Brasília em Maio de 2011, tive o privilégio de assistir a apresentação de um dos maiores especialistas de Integração e Arquitetura Orientada a Services (SOA). Trata-se do Paul Brown, que é autor de vários livros e atualmente é o “Principal Architect” da TIBCO.

Nessa palestra, Brown relembrou uma definição de Arquitetura contida no livro Software Architecture in Practice publicado em 2003, onde uma Arquitetura compreende 3 visões que são as seguintes:

  • Modelo de Processo: Descreve o processo de negócio na visão do usuário, ou seja, todas as atividades e conceitos envolvidos;
  • Padrão de Arquitetura: Mostra quais sistemas estão envolvidos no processo de negócio, seja por eles possuírem dados ou regras de negócio necessários ao processo, e como eles e seus canais de comunicação colaboram para a execução do processo;
  • Mapeamento Processo x Arquitetura: Descreve em quais sistemas cada atividade do processo é executada. Naturalmente ao fazer esse mapeamento acabamos “explodindo”, ou seja, detalhando algumas atividades do processo.
Um exemplo de cada uma dessas 3 visões

O exemplo que daremos trata de uma questão inspirada num caso real da indústria de mídia relacionado a um projeto que eu estou participando: A extração de entidades a partir de conteúdos editorias.

Antes de apresentar os diagramas, vamos entender um pouco sobre a estruturação de conteúdos em Tópicos usando Extração de Entidades. Para isso, pedi uma ajuda a minha amiga Giselle P. Maia que é especialista no assunto:

Com o crescente volume de informações produzidas por empresas jornalísticas e disponibilizadas em seus sites, a organização tradicional de conteúdo por editorias se torna insuficiente.

Daí surge a necessidade de criar meios para que as essas empreasa possam publicar conteúdo
estruturadamente em páginas chamadas “tópicos editoriais”.

Estas páginas são agrupamentos do conteúdo previamente indexado de acordo com
um “tema” especificado. Nesta visão, um conteúdo poderá pertencer a um ou mais “temas”
simultaneamente, mesmo que associado a uma única editoria. Não é a toa que a organização de conteúdos em Tópicos é um primeiro passo à publicação automática de páginas semânticas.

Uma das formas de organizar conteúdo por Tópicos é (i) identificando Entidades (Ex: pessoas, lugares, empresas etc) relacionadas aos conteúdos e (ii) associando aos tópicos certas entidades. Dessa forma, por um lado a empresa fica com a responsabilidades de criar Tópicos e definir as Entidades a eles associados e por outro se estabelece um mecanismo automático de extrair Entidades a partir dos conteúdos produzidos. Assim, bpara ter uma página de um “tópico editorial” será necessário apenas fazer uma pesquisa no estilo “exiba todos os conteúdos que tenham as entidades existentes no tópico em questão”.

Um exemplo de páginas de tópico editorais é o do Estadão sobre o Pacote de Ajuda aos Bancos e a página de Tópicos do New York Times que na verdade só exibe Entidades.

Agora que sabemos um pouquinho sobre Tópicos e Entidades, temos condições de estabelecer e apresentar suas 3 visões. Para tal, vamos considerar apenas parte da Extração de Entidades, ok!?!?

A figura abaixo mostra um Modelo de Processo simplificado para Extração de Entidades do projeto que estou participando.

Modelo de Processo simplificado de uma Extração de Entidades
Modelo de Processo simplificado de uma Extração de Entidades

Diagramas de Modelos de Processos são uma fonte muito rica para a identificação de serviços numa Arquitetura Orientada a Serviços (SOA). No caso do modelo de processo acima, sinalizei em tom avermelhado quais seriam os candidatos a serviços de negócio.

O Padrão de Arquitetura poderia ser o mostrado na figura a seguir. Nele temos apenas 3 sistemas envolvidos: O Sistema Editorial, o Barramento de Serviçõs (ESB) e o Sistema que possui toda a lógica de Extração de Entidades.

Padrão de Arquitetura que poderia ser utilizado para a Extração de Entidades
Padrão de Arquitetura que poderia ser utilizado para a Extração de Entidades

Ao fazer o Mapeamento do Processo na Arquitetura definida acima inevitavelmente nos leva a “explodir” algumas atividades do processo, o que é perfeitamente normal.

Mapeamento do Modelo de Processo de Extração de Entidades na Arquitetura definida
Mapeamento do Modelo de Processo de Extração de Entidades na Arquitetura definida

É importante observar que os diagramas de mapeamento podem evoluir em nível de detalhamento ao longo do projeto.  Isso se torna mais evidente principalmente se você estiver participando de um projeto que utilize um método ágil de gestão.

Arquitetos devem se preocupar com todas as 3 visões

O primeiro motivo por que Arquitetos de TI devem se preocupar com essas 3 visões é por que quanto mais complexos forem os modelos processos ou os padrões arquiteturas que estão sendo tratadas, maior será o número de possibilidades de mapeamento. Tais possibilidades envolvem diferentes formas de comunicação e diferentes definições de responsabilidades.

Outro motivo é por que mesmo que seja escolhido o melhor padrão de arquitetura um mapeamento inadequado pode comprometer o processo não só no aspecto técnico mas também no aspecto funcional impactando os usuários.

O terceiro motivo é por que somente diante de um mapeamento teremos condições de validar a solução proposta. Apenas o modelo de processo ou o padrão de arquitetura não são suficientes para comprovar (tecnicamente ou funcionamento) a viabilidade da solução ou para que os usuários possa validar a proposta final de solução. Dessa forma, as 3 visões são necessárias e se complementam.

Até o próximo post!