terça-feira, 24 de novembro de 2009

SOA Manifesto

Após o mundo de TI passar por algumas rodadas de disseminação do conceito SOA, sem esquecer de alguns tumultos “provocados” pelo post “SOA is Dead; Long Live Services”, alguns bam-bam-bans no tema, motivados por Thomas Erl e incluindo a autora do post citado, compilaram o “SOA Manifesto”. Segue uma tradução livre:

 

Manifesto SOA

Orientação a serviço é um paradigma que direciona o que você faz.
Arquitetura orientada a serviço é um tipo de arquitetura que resulta da aplicação de orientação a serviço.

Nós aplicamos orientação a serviço para auxiliar organizações a entregar valor de negócio sustentável de forma consistente, com maior agilidade e eficiência de custo, alinhado às necessidades de mudança do negócio.

Através de nosso trabalho nós priorizaremos:
Valor de negócio acima de estratégia técnica
Objetivos estratégicos acima de benefícios específicos de projeto
Interoperabilidade intrínseca acima de integração customizada
Serviços compartilhados acima de implementações de propósito específico
Flexibilidade acima de otimização
Refinamentos evolutivos acima de busca da perfeição desde o início
Ou seja, enquanto nós valorizamos os itens da direita, nós valorizamos ainda mais os itens da esquerda.

 

Princípios que Guiam o Manifesto SOA

Nós seguimos estes princípios:
Respeitar a estrutura social e de poder de uma organização.
Reconhecer que SOA requer mudança em vários níveis.
O escopo da adoção de SOA pode variar. Manter esforços gerenciáveis e dentro de limites significativos.
Produtos e padrões sozinhos não lhe fornecerão SOA nem aplicarão o paradigma de orientação a serviços para você.
SOA pode ser concretizada através de várias tecnologias e padrões.
Estabelecer um conjunto uniforme de políticas e padrões corporativos baseado em padrões de facto da indústria e da comunidade.
Buscar uniformidade no exterior e permitir diversidade no interior.
Identificar serviços através da colaboração entre interessados de negócio e tecnologia.
Maximizar o uso de serviços considerando o escopo atual e futuro de utilização.
Verificar se os serviços satisfazem os objetivos e requisitos de negócio.
Evoluir os serviços e sua organização em resposta ao seu real uso.
Separar os diferentes aspectos de um sistema que mudam em ritmos diferentes.
Reduzir as dependências implícitas e publicar todas as dependências externas para aumentar a robustez e reduzir o impacto de mudanças.
Em todo nível de abstração, organizar cada serviço em torno de uma unidade de funcionalidade coesa e gerenciável.

 

E ai, concorda? Então vai e “assina embaixo”! :-)

Nenhum comentário:

Postar um comentário