Marco Mendes´s Blog

A Oracle disponibilizou recentemente um excelente relatório com tendências de adoção do BPM no mundo e também no Brasil.
Resumo aqui para os mais apressados as principais conclusões do relatório:

• O mercado BPM vive um crescimento estupendo, com uma perspectiva de crescimento de quase 10 vezes nos próximos anos, apesar da crise do mercado americano. As projeções indicam um crescimento do mercado de 500 milhões de US$ este ano para quase 6 bilhões até 2011.
• As iniciativas BPM na maior parte das organizações estão maturando, sendo usadas ainda primordialmente dentro de uma área ou unidade.
• O mercado de ferramentas está em franco processo de seleção natural. Ao invés de 150 ferramentas representativas (2006), temos agora apenas 25 ferramentas com representatividade (2008).
• Uso do BPM como ferramenta indireta para integrar aplicações (EAI) e para promover uma cultura de alinhamento a processos e escritórios de processos.
• Uso do BPM como um mecanismo de mudança cultural muito além da questão tecnológica, i.e., uma metodologia para remover silos e promover comunicação e alinhamento.
• Incentivo à combinação de BPM e SOA. Empresas que conjugaram as duas iniciativas tiveram resultados bem mais consistentes que empresas que adotaram apenas BPM.
• Aumento explosivo da colaboração entre pessoas com conceitos como CEP (Complex Event Processing) e ferramentas de EDA (Event Driven Architecture) para a montagem de empresas que respondem aos eventos (internos e externos) em tempo real.
• Dentro de TI, é o segmento que apresenta o maior crescimento no uso de ferramentas. Esta é uma clara mensagem para quem trabalha com TI. Se você nao está pensando em BPM e suítes BPM (BPMS), leia o relatório e repense a sua estratégia.

Para os que dispõe de mais tempo, mais interesse ou ambos em BPM, coloco aqui o link para relatório State of the Business Process Management Market 2008.

Se a sua empresa lembra o programa Zorra Total, talvez seja interessante trocar de canal. A troca de canal significa pensar sua empresa como uma coleção de processos e implementar práticas ágeis de BPM e BPM Enabled by SOA. Experiências a respeito são sempre uma boa fonte de inspiração e por isso compartilho neste brevíssimo blog uma coletânea de dezenas de filmes SOA compilados pela IBM.
Filmes e WebCasts SOA

Acredito que independente da sua escolha de fornecedor, estes vídeos fornecem exemplos, relatos, experiências e casos de sucesso da adoção de BPM e SOA em empresas de toda sorte.

Recomendo também, para complementar estes webcasts, o espaço SOA da IBM (SOA Space). O SOA Space é um mash-up (portal Web 2.0) com dezenas de portlets com conteúdos variados e informativos sobre SOA.

O que é uma arquitetura de referência?

É uma coleção de de boas práticas arquitetônicas para capturar soluções provadas em um problema de um determinado domínio. Em termos simples, ele oferece uma base de onde criamos boas arquiteturas de software em projetos de TI. Um exemplo interessante de uma arquitetura de referência específica para o domínio Java é o Java EE (Java Enterprise Edition), que define um modelo provado para a montagem de aplicações corporativas em tecnologias Java.

Quando falamos de SOA, estamos falando de gerar agilidade para os negócios. O propósito básico de SOA é prover à TI um mecanismo provado de alinhamento com áreas de negócios. Quando somamos SOA e arquiteturas de referência estamos falando, portanto, de um conjunto de mecanismos provados para projetos SOA. Interessante notar que SOA não é uma arquitetura de TI, mas uma arquitetura de negócio. Portanto, uma arquitetura de referência para SOA envolve aspectos técnicos e também aspectos de negócios. Exemplos incluem:

• Camada de Governança
• Camada de Serviços de Apresentação (ex: Portais e Mash-ups)
• Camada de Serviços de Processos de Negócio
• Camada de Serviços de Dados

Desenhar e montar uma arquitetura de referência, entretanto, não é uma tarefa fácil. São necessários anos de práticas e vários projetos para capturar as boas práticas e afastar as más práticas. Felizmente, podemos contar com duas empresas sólidas, com dezenas de anos de experiência no desenvolvimento, entrega e suporte de aplicações corporativas. Destaco aqui a BEA e a IBM. Exemplos de seus produtos incluem os OLTPs de excelente reputação como o BEA’s TUXEDO (desde 1983) e o IBM CICS (desde 1969). Interessante notar, as duas soluções mais maduras de SOA do mercado são da BEA e IBM. Delas vêm também boas arquiteturas de referência, que podem ser usadas até por empresas e pessoas que não usem produtos destas empresas. Destaco, em particular, dois excelentes white papers da BEA e da IBM, respectivamente.

• BEA’s SOA Reference Architecture SOA - Excelente artigo com a montagem de uma arquitetura de referência para SOA.
• Design an SOA solution using a reference architecture - Também um excelente artigo com uma arquitetura de referência em nove camadas.

Embora com visões diferentes, os dois artigos podem e devem ser usados por qualquer técnico interessado em SOA e BPM. Como disse Isaac Newton certa vez sobre o seu trabalho da figura do começo deste artigo: “Eu pude ver mais longe porque estava apoiado nos ombros de gigantes”.

O Apache Tuscany é um servidor (ambiente de execução) baseado na Arquitetura de Componente de Serviços (SCA - novo modelo de componente que facilita a construção de aplicações SOA), e se baseia em um conjunto de especificações inicialmente desenvolvido pela IBM e BEA, que está sendo padronizado pela OASIS, como parte da Arquitetura Aberta de Componente de Serviços (Open CSA). Tecnologicamente, o SCA pode ser comparado a especificações de Web-Services (WS-*), só que um estágio evolutivo à frente.

A versão 1.1 do Tuscany foi lançada recentemente e suporta diversas linguagens de implementação em sua versão atual, tais como:

• Java Beans
• Spring
• Scripting - JSR 223(JavaScript, Groovy, Ruby, Python & XSLT)
• BPEL
• XQuery
• OSGI

Algumas das especificações SCA suportadas por este ambiente incluem:

• SCA Assembly Model V1.0
• SCA Policy Framework V1.0
• SCA Java Common Annotations and APIs V1.0
• SCA Java Component Implementation V1.0
• SCA Spring Component Implementation V1.0
• SCA BPEL Client and Implementation V1.0
• SCA Web Services Binding V1.0
• SCA EJB Session Bean Binding V1.0

A princípio, tudo isso pode parecer muito complexo. Por outro lado, podemos entender o SCA como uma tecnologia muito interessante que permite expor códigos legados ou novas funções dentro de uma arquitetura de serviços 100% SOA.

Uma boa forma de desmitificar esta complexidade é rodar o tutorial abaixo, onde você monta uma aplicação SOA baseado em serviços compostos em apenas dez minutos.

- SOA com SCA em Dez Minutos

Um aspecto muito importante dentro do mundo SOA é que novos papéis emergem e devem ser considerados na montagem de um time de projeto com orientação a SOA. Estes papéis são baseados nos papéis já conhecidos pelo mercado, mas algumas diferenças são notadas.

O ciclo de desenvolvimento SOA pode ser descrito em alto nível como mostrado na figura abaixo.

Dentro deste ciclo de vida, podemos identificar os seguinte papéis primários:

• Analista de Negócio. Descrito no passo (1), este analista é responsável pela modelagem dos processos de negócio da organização e pela exploração de novos cenários de negócios e pela definição e aferição de métricas de negócio (KPIs). Este analista não deve ser confundido com o analista de sistemas ou o analistas de requisitos. O analista de requisitos é responsável por descrever requisitos em modelos de casos de uso, enquanto que o analista de sistemas é responsável por exprimir a solução técnica de TI de um requisito. O analista de negócio, muitas vezes, se encontra fora da área de TI e possui um profundo conhecimento do seu segmento de negócio, como por exemplo o segmento bancário, indústria ou logística. O analista de negócio exprime o seu trabalho em notações como o BPMN ou o XPDL, entre outras. Não é incomum observamos em organizações mais evoluídas a figura do arquiteto de negócio, que tem a responsabilidade primária de organizar e garantir o reuso dos diversos processos de negócio de uma organização.
• Arquiteto de Integração. Este papel é responsável pela orquestração dos processos de negócio descritos pelo analista de negócio. Ele opera sobre modelos BPEL, entre outros, que são linguagens que permitem orquestrar um processo de negócio, i.e., implementar cada passo de um processo como chamadas a Web Services a recursos legados distintos tais como COBOL, ADABAS, MUMPS, SAP e PeopleSoft, entre outros. Para este trabalho, ele conta com o trabalho de desenvolvedores especialistas e arquitetos de sistemas, que a ele provêm adaptadores e conectores para o seu trabalho de integração. Este arquiteto produz códigos executáveis que irão rodar sobre servidores de processo, que são extensões sobre os famosos servidores de aplicação e que usam ESBs e servidores de filas de mensagens para conseguir rodar um processo de negócio.
• Implantador. Este papel é responsável pela implantação e operação dos processos de negócio nos ambientes de execução. Ele pode ser pensado como um papel similar ao *Deployer* Java EE, responsável pelo empacotamente, ajustes finos e garantia do uso dos melhores recursos do servidor de aplicação.
• Usuários e Administradores. Finalmente, conforme mostrado no passo 4, existem os usuários e administradores, que irão operar os processos de negócio. Os processos terão as suas métricas avaliadas em tempo real através dos servidores de processos e retroalimentarão os analistas de negócios com possíveis melhorias nos processos de negócio.

Realizamos esta semana uma palestra sobre SOA no 44 Café Empresarial da ASSESPRO-MG. Neste encontro, pudemos debater sobre aspectos importantes sobre uma arquitetura de serviços e paradigmas que devem ser adotados para a sua correta implementação.

A apresentação realizada neste evento está à disposição aqui para download.

Realizamos hoje uma apresentação na ASSESPRO-MG (35 Cafe Empresarial) sobre a importância de arquiteturas de sistemas para áreas de TI e empresas como um todo. Nesta apresentação discutimos arquiteturas de ambientes móveis, EAI/EDI, ESB, SOA; bem como outros aspectos importantes como o papel do arquiteto de software, processos de software centrados em arquitetura e mecanismos para a formação e capacitação de times de arquitetura.

Anexamos aqui a apresentação realizada para os interessados na área de arquitetura de software.

Cada vez mais temos bons sites sobre o tema arquietura de software, destinados a arquitetos, líderes técnicos e desenvolvedores sênior. Compilo aqui uma lista de bons sites que mantém excelentes conteúdos sobre temas recentes e interessantes, tais como SOA, BPM, arquiteturas corporativas, padrões arquiteturais, processos e ferramentas.

Um aspecto fundamental em arquiteturas orientadas por serviço é a gerência contínua da qualidade em todo o ciclo de desenvolvimento de processos de negócio e serviços. Em um recente evento de SOA organizado pela Squadra, apresentamos um modelo de qualidade contínua para o suporte ao desenvolvimento orientado por serviços baseado em idéias da IBM e da nossa experiência na condução de alguns projetos desta natureza.

Uma conclusão importante apresentada neste trabalho é que a qualidade de software está cada vez mais ancorada no atendimento a processos de negócio ponta a ponta, implementando o conceito de governança de TI, chave para qualquer implementação SOA. Colocamos no final da apresentação também um conjunto de recursos para aqueles que tiverem um interesse de se aprofundar neste instigante tema.

A apresentação realizada está disponibilizada aqui para download.

Hoje (19/04) está ocorrendo o MGJUG Tech Days, evento técnico organizado pelo grupo de usuário de Java de Minas Gerais (MG-JUG).

Apresentamos uma palestra neste evento, sobre integraçào de sistemas, arquitetura SOA e a plataforma Java. Esta palestra está disponível em anexo aqui para download.