Pensamentos sobre Torrents, Diaspora e SOA

O Diaspora vem com a proposta de descentralizar os dados. Os dados ficarão no próprio computador do usuário ou em algum outro host e serão acessados por APIs (Application Program Interface), onde você controla quem tem acesso ou não aos seus dados, como fotos, videos, tweets etc.

Se o Dispora vai ou não dar certo, em breve teremos a resposta, mas o que fica de lição para nós é o uso de arquiteturas descentralizadas. Essas arquiteturas não encontramos um único servidor que armazena todos os dados e processo do negócio, mas teremos alguma coisa (coisa aqui pode ser qualquer coisa mesmo, celular, browser, cliente dedicado etc.) que acessará os dados de diversas  fontes, ou provedores de serviços.

Quem está mais ligado, já sacou que estou falando de uma arquitetura orientada a serviços, ou SOA. SOA não é uma tecnologia, não é uma linguagem ou até mesmo uma plataforma. SOA é mais um conceito, uma arquitetura que descreve o relacionamento entre duas entidades, os provedores de serviços e consumidores de serviços.

No mundo SAP, a SOA é um dos pilares estratégicos da empresa e grande atenção tem sido dada a ela. Em SOA temos o conceito de orquestração, que no mundo SAP é deixado a cargo do BPM.

Como programadores ABAP, nossa responsabilidade é muito grande. Não é de hoje que venho batendo na tecla da necessidade de se aproximar das pessoas de negócio (lê-se analistas funcionais e usuários). Como programadores não devemos pensar mais em desenvolver programas, mas desenvolver serviços que serão disponibilidados para outros consumidores, sejam eles de dentro ou fora do R/3.

No SOA, assim como o Diaspora ou até mesmo Torrents, as aplicações serão a composição de diversos serviços, espalhados pela empresa cada um provendo um serviço numa cadeia de processos.

No nosso mundo SAP os holofotes estão sobre 3 letras BPM, ou Business Process Management. A idéia do BPM é que o usuário, analista de funcional (ou de negócio) e programador discutem juntos a solução final. Essa foi a idéia inicial da UML, mas que acabou sendo técnica demais. Agora o BPM nasce como mais uma esperança de um mundo onde o próprio usuário desenha o processo (como feito em Microsoft Visios da vida) e magicamente esse desenho é transformado em software.

Para quem está entrando nesse mundo SAP, saiba que há muitas oportunidades para quem investe em SOA e BPM.

Programação Orientada a Serviços

Como programadores devemos estar sempre atentos aos movimentos do mercado e principalmente com os movimentos da SAP. E a SAP já faz tempo que vem sinalizando que a programação orientada a objetos será o carro-chefe da linguagem ABAP.

Como já disse anteriormente, devemos mudar a forma como desenvolvemos aplicações de negócio usando ABAP. Antes pensávamos num relatório isolado, hoje devemos pensar como programar orientado a serviços, ou seja, não mais devemos pensar em aplicações isoladas. Penso que o ideal seria programarmos pensando em APIs. Essas APIs seriam o caminho para um mundo onde usuários e funcionais apenas selecionariam um pool de serviços, que serão orquestrados pelo BPM.

Programação orientado a serviços já!