Service-Oriented Architecture e Modelos de Maturidade - Revisitando o assunto...

Olá pessoal, tudo certo?

Mais um post sobre SOA. Recentemente, tive algumas discussões com arquitetos de diversas empresas de SP e RJ, sobre computação orientada a serviços e economia oientada a serviços. Já falamos algo sobre o assunto em posts passados, como:

The Dark Side of SOA... e ainda sobre modelos de maturidade.
Ref.: https://blogs.msdn.com/wcamb/archive/2007/12/06/the-dark-side-of-soa-e-ainda-sobre-modelos-de-maturidade.aspx

Mas gostaria de ampliar a discussão com alguns tópicos adicionais. Vamos focar a computação orientada a serviços. :)

Apenas para relembrar, usamos uma definição para SOA: estilo de arquitetura onde funcionalidades selecionadas de aplicações são disponibilizadas na forma de serviços. E esses serviços podem ser publicados em barramentos, como Enterprise Service Bus ou Internet Service Bus, este último mais recente.

Mas de fato, a própria definição desperta uma série de perguntas, recorrentes em discussões sobre o tema:

• O que é um serviço?
• Quais são os patterns para criação de serviços?
• Quais os mecanismos de conexão e comunicação?
• Quais funcionalidades serão implementadas?
• Como organizar os sistemas e investimentos já existentes na organização?
• Como publicar os serviços gerados?
• Como consumir os serviços gerados?
• Como administrar os serviços gerados?
• O que é governança de serviços?
• Entre outras...

Responder cada uma das perguntas acima não é fácil. E fazer o mapeamento das necessidades reais de sua empresa com as promessas e desafios de uma arquitetura SOA é ainda mais difícil. De fato, o impacto de uma arquitetura SOA é grande na organização, seja no ambiente de desenvolvimento, no consumo de serviços, no tipo de aplicação front-end ou ainda na administração dessa nova infra-estrutura de componentes, interfaces e camadas.

Considerando a dificuldade da tarefa, o arquiteto deve avaliar ferramentas que o ajudem no momento da definição de uma arquitetura SOA. Entre as ferramentas disponíveis, vamos citar as arquiteturas de referência e os modelos de maturidade.

Note que fica explícito a presença de uma camada de serviços, assim como de uma camada de processos, que pode compor orquestrações, fluxos de atividades ou ainda máquinas de estado a partir dos serviços publicados. Nesse modelo, também observarmos uma série de serviços de utilidades ou suporte, como governança, qualidade de serviço, monitoração, auditoria, etc. Essa separação permite identificar quais serviços implementam funcionalidades de negócio e quais são serviços comuns para toda a infra-estrutura. Seguir uma arquitetura de referência sempre é uma boa prática, pois facilita a defesa e o posicionamento de seus componentes, a partir de uma estrutura bem definida.

Você já deve ter ouvido falar das promessas de SOA, como:

• Diminuição de custos de implantação de produtos e serviços;
• Menor TCO para a infra-estrutura e aplicações;
• Maior lucro, devido geração de novos produtos;
• Menor risco, pelo reuso de serviços maduros e composição de funcionalidades;
• Menor time-to-market, trazendo maior agilidade ao negócio, etc.

Porém, como visto no relatório do "The Dark Side of SOA", a realidade tem sido outra. De fato, muitos erros na definição de uma arquitetura SOA têm provocado falhas em projetos, gerando maior complexidade final, maior custo de projeto, baixa performance na solução implantada, dificuldade na administração de uma infra-estrutura de serviços, para citar alguns. Existe também maior tendência na terceirização do gerenciamento de todo o sistema corporativo. Entretanto, um modelo de terceirização efetivo exige cuidados na definição dos diversos SLA's presentes na arquitetura. Esse é outro fator de impacto na implantação de uma arquitetura de serviços. Atualmente, não existe uma metodologia unificada para gerenciar medições e monitoração de serviços em sistemas corporativos distribuídos, ainda mais para uma arquitetura SOA.

Um dos grandes problemas observados tem sido o roadmap de evolução da arquitetura SOA dentro da organização. Ou seja, quais características ou aspectos de SOA precisamos implementar na empresa afim de obter quais benefícios de negócio. Essa pergunta é chave para o sucesso. Para apoiar essa definição estratégica, a empresa pode utilizar um modelo de maturidade.

Existem diversos modelos de maturidade hoje em dia. O objetivo principal de um modelo de maturidade é traçar uma visão de esforços, durante a evolução da empresa entre os vários estados de adoção de uma tecnologia. Como passos unitários nessa evolução temos as capacidades, que representam aspectos de tecnologia ou de processo que queremos evoluir.

O modelo de maturidade da Microsoft para o mundo SOA tem 4 grandes níveis: básico, padronizado, avançado e dinâmico. Não significa que toda empresa deve alcançar o nível dinâmico ou ainda se lançar num projeto de 3 anos para atingir essa maturidade. Ao contrário, cada empresa deve identificar suas reais necessidades de negócio e mapear que aspectos de SOA irão melhor atender suas necessidades. Também, acredite: sua empresa não está no nível anterior ao básico se ela tem uma TI minimamente estruturada :)

A partir desse mapeamento, utilizar um roadmap de evolução como um modelo de maturidade pode ser muito útil pela taxonomia padronizada, assim como pela facilidade e simplificação do processo. A figura abaixo apresenta os grupos de capacidades do modelo de maturidade SOA da Microsoft, o chamado SOAMM:

Enfim, falamos acima de vários tópicos sobre uma definição de arquitetura SOA e ainda temos assuntos pendentes, como patterns de serviços, ferramentas de monitoração e administração de serviços, ESB, ISB, latência, aplicações compostas, etc.

Para nós arquitetos, creio que o mais importante é continuar a discussão, sempre tendo em mente o papel da TI em sua empresa. Conhecer a natureza do negócio, a demanda de TI presente e futura e como tornar o negócio mais ágil a partir de uma TI flexível é questão chave. Cada vez mais, nossos sistemas e soluções deverão conviver com a mudança constante, com a necessidade de composição de funcionalidades, assim como o suporte para diferentes mundos (web, mobile, desktop, enterprise). A visão Software + Serviços será uma realidade. Falaremos mais sobre S+S em posts futuros.

Por isso, revisitar o assunto é importante, além de um exercício saudável de estudo.

Para maiores informações sobre alguns dos temas acima, veja:

SOA in the Real World
Ref.: https://www.microsoft.com/downloads/details.aspx?familyid=cb2a8e49-bb3b-49b6-b296-a2dfbbe042d8&displaylang=en#filelist

How to get started with SOA
Ref.: https://www.microsoft.com/soa

How to get started with ESB Guidance
Ref.: https://www.codeplex.com/esb

Patterns and Prescriptive Architecture Guidance for Healthcare (um exemplo de solução com aspectos de SOA)
Ref.: https://www.codeplex.com/HCE

BizTalk Services and Internet Service Bus Technologies
Ref.: https://labs.biztalk.net/Overview.aspx

Roadmap “Oslo” (videos e artigos)
Ref.: https://www.microsoft.com/soa/products/oslo.aspx

The Architecture Journal
Ref.: https://msdn2.microsoft.com/en-gb/arcjournal/default.aspx

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

Waldemir.