Freigeben über

The Dark Side of SOA... e ainda sobre modelos de maturidade.

  • Artikel

Olá pessoal, tudo certo?

Conforme prometido, vamos falar um pouco sobre Modelo de Maturidade SOA, um assunto que comentamos um tempo atrás. A Microsoft anunciou recentemente seu modelo de maturidade (SOAMM - SOA Maturity Model), durante o último SOA & Business Process Conference, em Seattle.

Ele contém basicamente 4 níveis de maturidade para uma arquitetura orientada a serviços: básica, padrão, avançada e dinâmica.

Para cada nível, existem capacidades que são importantes e que apoiam a arquitetura. Ao todo são 36 capacidades que a Microsoft e seu time de SOA definiram, que podem ajudar as empresas na definição de um roadmap de evolução numa arquitetura SOA. Veja que num certo momento, uma empresa pode ter capacidades diferentes em níveis diferentes de maturidade. Assim, é possível que sua empresa tenha um nível avançado de monitoração e segurança, mas um nível básico de padronização de serviços em sua arquitetura.

Em linhas gerais, um modelo de maturidade nada mais é do que um guia para a estratégia de evolução de uma arquitetura. A empresa pode utilizar um modelo desses para avaliar seu estado atual e definir, segundo seus próprios critérios de negócio e tecnologia, quais capacidades ou habilidades deverão ser adotadas para se alcançar o próximo nível.

No link a seguir, temos um self-assessment que pode ajudar nessa definição, vale conferir:

https://www.microsoft.com/business/peopleready/appplat/ac/apio.mspx

A partir da definição do roadmap, o próximo passo é a implementação de cada serviços ou capacidade. Nesse ponto, temos discussões sobre diversos aspectos como:

  • Contract Design
  • Instrumentation
  • Deployment
  • Usage Analysis
  • Versioning
  • Brokers
  • Policy Validation
  • Health Modeling
  • Distributed
  • Transactions
  • Model Verification, para ficar em alguns.

Cada um desses fatores deverá se tornar de fato uma implementação ou definição na nova arquitetura. E entre os candidatos para implementações e serviços, podemos citar serviços comuns como:

Serviços de Aplicação
  - Componentes de negócio comuns, como
- Autorização, Autenticação, Autorização, Segurança,
- Utilitários, como Data/Hora

Serviços de Interface
  - UI Framework
- Interface gateways, como FTP, SMTP, etc.
- Tradução, conversão

Serviços de Instrumentação
  - Journaling/Logging
- Alerta e Tratamento de Erros
- Controle de auditoria

Serviços de Dados
  - Enterprise Data Stores
- Data Access Services
- Meta-Data Repository

Serviços de Integração e Controle
  - Gerenciamento de Web Services
- Gerenciamento de Eventos
- Registro/Repositório
- Orquestração

Serviços Especializados
  - Disponibilidade
- Gerenciamento de Carga
- Planejamento de Capacidade

E finalmente, retomamos a discussão sobre como implementar. Decisões sobre quais protocolos deverão ser envolvidos, qual o SLA de cada serviços, templates e patterns adotados, tipos de bindings em serviços WCF, transformações no BizTalk ou uso de MSMQ para comunicação assíncrona, etc, aparecem como próximos passos. No fundo no fundo, nunca devemos esquecer que uma arquitetura SOA ou uma iniciativa voltada para a orientação a serviços deve sempre ser feita de forma INCREMENTAL, de acordo com a real necessidade de negócio da organização.

Enfim, estude muito bem sua arquitetura e o impacto envolvido! E acredite: SOA pode ter um grande impacto na infra-estrutura, desenvolvimento e cultura de uma organização.
 
Para finalizar, segue o link do relatório da Information Week de setembro de 2006. Veja que o título é no mínimo criativo, não é? :)

The Dark Side of SOA
https://www.informationweek.com/software/showArticle.jhtml?articleID=192501102

Por enquanto é só. Até o próximo post! :)

Waldemir.

Comments

  • Anonymous
    February 20, 2008
    Olá pessoal, tudo certo? Mais um post sobre SOA. Recentemente, tive algumas discussões com arquitetos

  • Anonymous
    February 20, 2008
    Olá pessoal, tudo certo? Mais um post sobre SOA. Recentemente, tive algumas discussões com arquitetos