Governança SOA

1. O que é governança?
2. Qual o objetivo da governança em um ambiente
orientado a serviços?
3. Quem deve participar da governança?
4. Políticas
5. Garantindo as políticas
ÍNDICE
6. Quem é o dono do serviço?
7. Centro de Excelência SOA
• Desafios do COE
• Perfis que fazem parte do COE
• O que o COE pode oferecer aos projetos
• Checkpoints em tempo de desenho
8. Gerenciamento de Serviços
9. Versionamento
10. Ciclo de vida
Material elaborado por http://vrsbrazil.wordpress.com , uso livre desde que com referência ao blog.

ÍNDICE 1 O que é governança?


A primeira coisa que nos vêm à cabeça quando falamos de governança é um
bloqueio burocrático de dezenas de documentos, formulários e planilhas a preencher
resultando em um quantidade enorme de informação inútil e de difícil acesso.

Uma governança efetiva é algo que muitos tentam implantar em seus
esforços de evolução da empresa, no entanto a maioria acaba falhando devido a
obstáculos que surgem no dia-a-dia forçando com que a tentativa de organização fique
para mais tarde, agravando cada vez mais a situação.

Obviamente não existe uma fórmula mágica para a implantação de uma boa
governança, mas casos de sucesso no mundo fizeram com que alguns
comportamentos fossem identificados de forma que uma boa governança fosse
implantada, mostramos eles a seguir:

• Comportamento esperado:
• O que se espera que o uso de determinada tecnologia atenda.
• Pessoas:
• Envolvimento de responsáveis por TI e projetos.
• Políticas
• Regras que deverão ser seguidas por todos os envolvidos para que o objetivo
seja alcançado.
• Processos: Medir
Definir
Política
• É necessário ter processos claros para:
• Definição de Políticas
• Comunicação
• Educação
• Aplicação
Aplicar Comunicar
• Medição

Educar

ÍNDICE 2 Qual o objetivo de governança
em um ambiente orientado a
serviços?


2. Qual o objetivo de governança em um ambiente orientado
a serviços?
Em um ambiente SOA essas práticas são críticas para um bom
gerenciamento dos serviços disponíveis e novos serviços a serem criados.

Para garantir o sucesso do esforço as pessoas envolvidas devem ser
agentes multiplicadores na empresa que tanto trarão contribuições para o refinamento
e criação de políticas como atuarão na proliferação da informação, educando os
demais e garantido a aplicação das mesmas.

Apesar dos envolvidos atuarem na multiplicação deste esforço, isto não é o
suficiente. Devem existir treinamentos de forma que todo o material humano
responsável pela execução dos projetos na empresa tenha a consciência do objetivo
de reusar, unificar e otimizar a forma que o dado é utilizado na empresa.

ÍNDICE 3 Quem deve participar da
governança?


3. Quem deve participar da governança?
Talvez o ponto mais importantes a se ter em mente quando falamos de
governança é que ela não é um objetivo somente de TI, é uma tarefa trabalhosa que
deve envolver usuários de negócio e parceiros organizacionais que devem interagir
constantemente para o sucesso do esforço.

É crítico que os fornecedores externos da empresa também participem
destas atividades e se certifique que eles têm plena aderência aos padrões da
empresa.

ÍNDICE 4 Políticas


4. Políticas
Regras bem definidas facilitam o gerenciamento da criação e evolução de
serviços, o recomendado é que seja mantido um controle para que durante as várias
fases do projeto seja garantido o bom andamento garantindo que as políticas estão
sendo obedecidas, podemos dar como exemplo as seguintes etapas:

Concepção do Projeto Governança do Projeto
Organograma da empresa Aspectos de contratos

Modelo de domínio Tecnologias

Processo expresso em BPM Repositório

Portfolio de aplicações Segurança

4. Políticas
Concepção do Projeto

Organograma da empresa Modelo de Domínio Processo expresso em BPM Portfolio de Aplicações

Mudanças no Um modelo de domínio bem Um bom indicador de se a Um levantamento maduro
organograma podem definido facilita a definição de equipe de arquitetura poderá das aplicações e serviços
afetar diretamente posse entidades e facilita a procura fazer um bom trabalho na disponíveis, fácil de obter
de serviços e no repositório por serviços identificação de serviço é o se um repositório for
gerenciamento da que atendam a demanda do processo bem expresso e mantido, é crucial para o
iniciativa, sempre projeto ou que precisem de detalhado, deixando claro as bom desenvolvimento das
importante ter ele alguma alteração de forma a interações entre áreas e outras etapas de trabalho.
atualizado . se adaptar ao novo sistemas envolvidos.
consumidor.

4. Políticas
Governança do projeto

Aspectos do contrato Tecnologia Repositório Segurança

• Schemas da As tecnologias e frameworks • Temos responsáveis Os serviços foram
mensagem ; em utilização são os mesmos cadastrados por cada serviço testados e estão
• Versões; e na mesma versão que os dentro do projeto? obedecendo as regras de
• Namespaces; combinados? segurança necessárias?
• Forma de acesso. • Os serviços foram
registrados no repositório?

ÍNDICE 5 Garantindo as políticas


5. Garantindo as políticas
É essencial termos políticas de governança, mas não ter uma medida para
garantir que elas são respeitadas as tornam ineficazes, para isso é necessário que
processos sejam estabelecidos.

O processo deve ser de forma que um processo cíclico seja estabelecido na empresa
incluindo as seguintes tarefas

Definir

Medir
Comunicar
•A análise de como as políticas
definidas se comportam no ambiente •Anunciar a existência
corporativo, onde esta informação das políticas os
será usada para melhorar a definição envolvidos
das políticas

Aplicar
•Auditorias e
Educar
acompanhamento dos •Treinamentos, worksh
projetos ops

ÍNDICE 6 Quem é o dono do serviço?


3. Quem é o dono do serviço?
Parece uma pergunta de resposta óbvia, mas isso só é verdade enquanto
um projeto está em desenvolvimento.

Depois que um projeto é finalizado e cada um dos recursos é realocado em
novos projetos, quem fica responsável por ele?

Definir isso logo na concepção de cada serviço e deixar essa informação
sempre atualizada no repositório é crucial para garantir a manutenção e futuras
adequações dos serviços, tanto regulatórias quanto evolutivas, é muito comum a
adesão de novos clientes ao serviço ou a necessidade de que novos dados sejam
agregados ao mesmo após a finalização do desenvolvimento.

ÍNDICE 7 Centro de Excelência (COE)
SOA

• Desafios do COE
• Perfis que fazem parte do COE
• O que o COE pode oferecer aos projetos
• Checkpoints em tempo de desenho


7. Centro de Excelência (COE) SOA
Desafios do COE
Manter um controle mais eficaz do portfolio de serviços que uma empresa
possui é uma tarefa desafiadora, trabalhosa e que falha com frequência.

Diferente do desenvolvimento voltado a integração sob demanda, uma falha
na governança SOA pode ter consequências catastróficas em vários projetos, tanto em
desenvolvimento como já entregues a muito tempo.

Com base nisso muitas empresas optam por montar uma equipe que será
responsável por garantir a boa evolução do portfolio de serviços e o convívio entre os
vários clientes do barramento, surge aí o Centro de Excelência SOA, ou COE, da sigla
em inglês.

Desafios do COE
Ter um centro de excelência não necessariamente garante sucesso da sua
governança SOA, já que em muitos casos há um equívoco nos perfis que são atraídos
a fazer parte do grupo, já que pelo nome, a escolha certa parece ser somente
arquitetos e analistas de integração.

Algumas empresas julgam que o número de serviços que eles possuem no
barramento não justifica o custo de manter profissionais voltados somente para isso e
a falta de atividades constantes para uma equipe dessa, geralmente altamente
qualificada causa frustrações aos seus participantes.

Existe o risco de o resto da empresa considerar o grupo como uma equipe
elitista na empresa.

Perfis que fazem parte do COE
Arquiteto da
Arquiteto Técnico Arquiteto de Negócio
Informação
• Responsável por • Define quais serviços • Visualiza e
definir como a a companhia administra o ativo de
companhia construirá, afetando informação da
construirá e diretamente a companhia, sendo
integrará serviços. análise de negócios. responsável pelo
modelo da
informação,
tornando-se o
responsável pela
evolução dos
modelos canônicos.


Gerência de TI Gerência de Negócio Desenvolvedores

• Deve definir a equipe de TI • Responsável em buscar e • Essa é o elo forte da
envolvida e definir o financiamento dos corrente que é
responsabilidade por esforços voltados a cada constantemente ignorado
serviços. serviço. quando falamos de
governança.
• É crucial que os grupos de
desenvolvedores estejam
forte e constantemente
envolvidos com o COE, de
forma que as políticas de
desenvolvimento sejam
amplamente conhecidas e
façam parte do dia-a-dia do
desenvolvedor.


Desenvolvedores - continuado Analistas DBAs

• Toda mudança de políticas • Os analistas são os que • O DBA é a contra-parte do
que foram geradas no COE decidem quais serviços serão Arquiteto da Informação, seu
devem ser amplamente construídos, juntamente com conhecimento da
comunicadas aos o Arquiteto de Negócio, o seu representação física dos dados
desenvolvedores e um grupo envolvimento no COE é crítico da empresa e seu
deles deve consultado para para garantir que não existam conhecimento dos efeitos de
um feedback da política antes esforços duplicados na mudanças tornam ele
que ela seja anunciada companhia na construção de essencial para o grupo.
oficialmente, já que a equipe uma necessidade específica.
que define as políticas pode
estar afastada do
desenvolvimento, impedindo
a ela ver as reais
consequências das suas
decisões.

O que o COE pode oferecer aos projetos
Existem algumas formas de se montar um centro de excelência, e a forma
de montá-lo afetará diretamente no que o COE pode oferecer ao resto da
companhia, as duas principais formas são:
Full service outsourcing Fórum

• Funciona como a única equipe especializada em • Também é possível ter o COE como uma equipe de
SOA a qual será responsável pelo desenvolvimento e profissionais chave na empresa, sem que eles
manutenção de todos os serviços na companhia. estejam na mesma equipe diariamente, tendo eles a
• Pode manter uma equipe principal de tarefa de auditar os trabalhos de outros projetos e
desenvolvimento e "emprestar" recursos para ter reuniões periódicas de trabalho.
projetos em execução de forma que o
conhecimento SOA prolifere na companhia de
forma homogênea
• Pode coordenar prestadores de serviços que
implementem serviços no barramento, garantindo a
qualidade destas entregas através de auditorias
constantes

Checkpoints em tempo de desenho

Preparação para
Análise Arquitetura Desenvolvimento Implementação
operação

Análise

É verificado se a análise que foi feita é o suficiente para que o arquiteto do
projeto possa desenhar uma solução inicial e montar uma primeira proposta de
arquitetura.
.
Se isso não for possível o trabalho de análise precisa de refino e é retornada
aos analistas.

Arquitetura

Nessa etapa é verificado se políticas essenciais para a boa convivência dos
serviços estão sendo cumpridas, algumas delas são:

• Se os limites entre serviços e consumidores estão sendo respeitados de acordo
com as políticas definidas;

• Se foram identificados se serviços que já existem no barramento foram utilizados ou
se a necessidade de atualização deles foi identificada;

• Se foram identificados outros possíveis clientes para os serviços e se eles foram
chamados para terem ciência do novo esforço.

Desenvolvimento

Nesta etapa de construção é necessário verificar se o desenho definido e
homologado na fase anterior foi cumprido, as verificações aqui incluem:

• As interfaces estão usando mensagens canônicas?

• Os contratos de serviços foram definidos entre todos os consumidores?

• As entregas prevêem etapa de verificação e autorização dos consumidores?

• As convenções de nomes e versões foram obedecidas?

• Requisitos transacionais foram obedecidos?

Implementação

Com as etapas anteriores bem cumpridas, a verificação de implementação é
bem simples, sendo apenas uma checagem de empacotamento.

A tarefa aqui é garantir que consumidor e serviço façam parte de pacotes
diferentes e se a interface foi realmente desacoplada da implementação.

Preparação para operação

• Todos os serviços possuem um responsável?

• O repositório foi atualizado e todos os elementos cadastrados?

• Todos os consumidores do serviço tem seus contratos sincronizados?

ÍNDICE 8 Gerenciamento de Serviços


Repositório de serviços
Na maioria das publicações que se encontra sobre repositório de serviços,
existe uma recomendação inicial de se manter uma planilha pública onde novos
serviços são adicionados e podem posteriormente ser consultados.

Essa estratégia só é verdade quando a companhia está apenas começando
seus esforços SOA e não é efetivo para companhias que tenham um portfólio de
serviços e precisa aplicar um melhor controle neles agora, tendo vários grupos de
trabalho que dependem dele e o desenvolvem.

Para isso é preciso algumas das ferramentas de mercado para isso, a seguir
mostramos alguns padrões do mercado.

Repositório de serviços – Ferramentas de mercado

Oracle Enterprise IBM WebSphere Service WSO2 Governance Membrane SOA
Repository Registry Registry Registry
• Abordagem Oracle • Solução IBM que • Uma ferramenta de • Ferramenta open-
para governança promete features usabilidade similar aos source leve e com a
• Como todas as outras padrões de mercado closed sources mas de maioria das features
ferramentas de • Promete integração licenciamento livre das soluções padrão
mercado é simples de com portfolio IBM • Amplamente usado no • Possui poucos estudos
usar e auxilia muito no como WebSphere mundo open-source já de caso.
controle e a visão de DataPower, que vem de uma das
serviços que existem WebSphere Enterprise empresas padrão de
disponíveis Service Bus (ESB), mercado em SOA
• Integra com o portfolio WebSphere Message nesse nicho
de produtos Oracle Broker assim como
• Exige licenciamento WebSphere MQ e CICS
• Exige licensiamento

ÍNDICE 9 Versionamento

• Por namespace
• Por URI
• Por políticas de acesso


9. Versionamento
Por namespace
É um versionamento simples onde colocamos a versão do elemento
diretamente no namespace.
É uma das técnicas chamadas de versionamento explícito, que fazemos
aqui, como no exemplo abaixo, pode ser usado para versão de wsdl e schemas:

• Namespace sem versão: http://schemas.empresa.net/Cliente

• Namespace com versão major.minor: http://schemas.empresa.net/Cliente/1.2

• Namespace com versão por data: http://schemas.empresa.net/Cliente/jan-2012

9. Versionamento
Por URI
Mais usado para versão de endpoint de serviços, a versão iria diretamente
na URI, mais um caso de versionamento explícito.
Essa técnica pode ou não ser implementada juntamente com outras
técnicas, um exemplo é:

• URI sem versão: http://endpoint.empresa.net/Cliente/Servico;
• URI com versão: http://endpoint.empresa.net/Cliente/Servico/1.3;

9. Versionamento
Por Políticas de Acesso
Esse é uma forma de versionamento considerada implícita, a qual exige um
maior trabalho de infraestrutura, mas torna a administração de consumidores de uma
determinadas versão de serviços mais fácil ao longo do tempo.
Ela é baseada em autenticação/autorização de usuário, funcionando da seguinte
maneira:

• Serviço é chamado baseado no contrato padrão, sendo enviado usuário e senha de
um determinado usuário.

• Usuário passa pelo processo de autenticação.

• É verificado nos roles do usuário se ele tem autorização de chamar o serviço e qual
versão de pode chamar.

• A Request é roteada para a versão correta do serviço.

9. Versionamento
Por Políticas de Acesso - Benefícios
• Facilita o gerenciamento de clientes do serviço, tornando mais fácil a notificação de
alterações e cálculo de impactos na companhia;

• Possibilita uma migração mais suave entre versões de serviço, já que novas
versões do serviço poderão ser chamadas por clientes sem alteração de código, a
não ser que eles queiram se beneficiar de novos elementos ou novas operações;

• Permite a migração automática de versões após o tempo que o COE determinará
para que a versão entre em desuso;

• Permite a migração parcial de clientes de um determinado serviço, reduzindo riscos
de indisponibilidade.

9. Versionamento
Por Políticas de Acesso - Infraestrutura
Elementos que uma solução orientada a políticas precisa manter:

• Ponto de Gerenciamento de Políticas;

• Ponto de Informação de Políticas: Centro de armazenamento de políticas;

• Ponto de Policy Enforcement: Aqui as políticas são verificadas e aplicadas;

• Ponto de Policy Decision: Após a verificação da política, esse ponto é
responsável pelo correto roteamento, isso pode ser feito com um XML appliance,
como IBM DataPower.

ÍNDICE 10 Ciclo de Vida

• Por namespace
• Por URI
• Por políticas de acesso


10. Ciclo de Vida
Durante o desenvolvimento de um projeto típico, o gerenciamento dos
produtos gerados durante o mesmo tem seu início de controle na análise e termina
com sua publicação em ambiente de produção, no entanto esse não é ciclo de vida de
serviços no barramento, onde seu início também é na fase de análise, no entanto ele
só termina com a retirada da última versão dele em produção.

Por isso o processo de evolução e monitoramento dele é cíclico, e é
recomendado o uso de ferramentas para facilitar o gerenciamento do seu ciclo de vida.

Três pontos são essenciais para o sucesso do gerenciamento do ciclo de
vida de um serviço:

• Monitorar
• Gerenciar
• Divulgar

10. Ciclo de Vida
Monitorar Monitorar
Não só verificar disponibilidade do serviço, mas tempo de resposta e como ela é vista pelos
clientes, picos de processamento e até baixa de utilização, o que pode indicar necessidade de evolução
dos serviços

Gerenciar

Os dados de monitoramento devem ser capturados e discutidos com os clientes dos serviços, é
provável que com o tempo novas necessidades foram identificadas e elas podem ser novas oportunidades
de evolução ou do surgimento de novos serviços, sem esse trabalho os serviços podem se tornar
antiquados e caminhos paralelos aos serviços podem surgir na companhia, isso deve ser evitado
Divulgar Gerenciar
Divulgar

É de responsabilidade do COE ou dos responsáveis pela manutenção dos serviços se manter
informado dos esforços de desenvolvimentos na empresa e identificar novos clientes para os serviços que
já existem e para soluções que já foram implementadas paralelamente trabalhar pela inclusão do mesmo
em novos releases, identificando adaptações que os serviços necessitarão sofrer para encaixar as novas
necessidades

Nome: Vinícius Rodrigo dos Santos
Cargo: Consultor em Arquitetura Orientada a Serviços
Contato: vrsbrazil@gmail.com
Twitter: @vrsbrazil


Governança SOA

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Semelhante a Governança SOA

Semelhante a Governança SOA (20)

Governança SOA