Realizamos recentemente uma palestra na SUCESU-MG sobre Arquiteturas de Negócio no grupo de trabalho de BPMS. Uma arquitetura de negócio é uma peça importante na estruturação e entendimento do modelo de negócio de uma organização e se constitui de ferramenta essecial para analistas de negócio e também arquitetos de TI.

Em particular, discutimos nesta apresentação o conceito de arquiteturas de negócio, modelos operacionais, capacidades corporativas e como estes conceitos são determinantes para facilitar implementações BPMS em organização. Discutimos também o anti-padrão “Ferramentas Primeiro”, onde procuramos mostrar que ferramentas BPMS não podem ser o elemento central de uma programa de melhoria BPM.

Disponibilizo a apresentação abaixo para os interessados no tema.

Arquiteturas de Negócio

Vemos muitos projetos que falham por problemas gerenciais. Um destes problemas é a distância entre o gerente de projeto e a sua equipe. Times que não se sentem orientados e aconselhados diariamente perdem o seu foco e se dispersam. Para combater esta distância, devemos fomentar e incentivar a figura do líder técnico de desenvolvimento (que em muitas empresas também é o arquiteto de sistemas).

O líder técnico de desenvolvimento mantém o time unido e coeso. Ele mantém a consistência técnica do produto de software sendo construído e atua como um coach para todo o time para os problemas técnicos e de ausência de motivação, que são comuns em projetos complexos e com prazos desafiadores.

O líder técnico/arquiteto é o contraponto musical do gerente de projeto. O líder técnico e o gerente de projeto atuam como um par-alfa de lobos em uma alcatéia na caçada pelo sucesso do projeto.

As fronteiras entre o Gerente de Projeto e o Líder Técnico de Desenvolvimento

Adapto abaixo um trecho do livro Applied Software Architecture, de Christine Hofmeister, Robert Nord e Dilipe Soni, que explicita a fronteira entre a gerência de projeto e a liderança técnica de projetos.

Pensamento do dia - Eclesiastes 4:9 Melhor é serem dois do que um, porque tem melhor paga do seu trabalho. 4:10 Porque se um cair, o outro levanta o seu companheiro.

Diversas empresas já possuem iniciativas SOA em andamento ou pensam em fazê-lo em breve. Entretanto, poucas empresas no Brasil tem discutido o conceito do Centro de Excelência. Endereço neste artigo o conceito e a função do centro de excelência em implementações SOA.

Em termos simples, um Centro de Excelência (CDE) é um time multi-disciplinar dentro de uma empresa que promove melhores práticas, conhecimento e a implementação de novas soluções dentro de um determinado escopo. Um escritório de projetos (PMO), como exemplo, é um centro de excelência para gerência de projetos. Um CDE SOA faz este trabalho dentro do universo SOA, que envolve um grande conjunto de conhecimentos e habilidades necessárias para a sua implementação.

Tipos de Centros de Excelência SOA

De acordo com um excelente artigo de auxílio na montagem de centros de excelência SOA, podemos classificar os CDE em três tipos - Acadêmico, Técnico e Técnico Avançado. As principais funções destes CDEs são descritas abaixo:

Membros de um Centro de Excelência SOA
Quem irá participar de um centro de um excelência SOA é decisão do CIO, mas a recomendaçào primária é que arquitetos, times de infra-estrutura, gerentes de produtos e vendas e influenciadores de negócio e técnicos estejam envolvidos, bem como o chefe de tecnologia (CTO) e o próprio CIO.

Pudemos acompanhar um CDE em uma empresa que está iniciando uma implementação SOA recentemente e notamos um forte envolvimento do CIO, CTO e time de arquitetura, bem como pessoas de áreas de negócio e produtos em um modelo similar ao da figura abaixo.

Para os mais interessados, um bom artigo que endereça este tema é discutido na revista CIO Zone. Um webcast a respeito está disponível também no excelente site SearchSOA da TechTarget.

Adapto para o português algumas pérolas extraídas de um bem humorado web site sobre “verdades” SOA, citadas pelo arquiteto de software Neal Ford, da Thought Works.

• SOA é á unica coisa que Chuck Norris não pode matar.
• O livro “SOA in a Nutshell” são dez volumes com 7531 páginas cada um.
• Uma pessoa conseguiu definir SOA com sucesso… e então morreu.
• SOA pode vencer você no jogo da velha, mesmo que você comece!
• Em uma batalha entre um Jedi e um Ninja, o SOA vence.
• SOA viola a primeira e terceira leis da termodinâmica, mas não a segunda, dado que toda a energia vem do SOA.
• No oitavo dia, Deus criou o SOA, e SOA criou o Rock e Roll.
• Plutão não é mais o nono planeta, porque SOA queria o seu lugar.
• SOA é a postura da Yoga que consiste de realizar todas as outras posturas da Yoga ao mesmo tempo.
• Dante tem um nível especial no inferno para consultores que não tenham SOA nos currículos.
• A solução para SOA é 42, que nos leva a questão….
• Se você plugar SOA na sua nuca, você já sabe Kung Fu.
• SOA significa SOA Oriented Architecture.
• Einstein definiu E=mc2 depois de rejeitar a equaçÃo soa = mc2 , que era muito poderosa e volátil.
• Arquitetos de software não usam SOA. SOA usa arquitetos de software.
• Com muito SOA na sala, você nao precisa de desenvolvedores.
• A resposta para a última questão sobre vida, universo e tudo mais é…. SOA.
• Darth Vader disse uma vez, “SOA, eu sou seu pai”. SOA replicou…”Vader, EU sou o lado negro”.
• Não existe governança SOA. SOA governa você.
• O aquecimento global não foi causado por dióxido de carbono, mas pelo calor dos servidores rodando SOA.
• A primeira implementação SOA em uma empresa é o triunfo da imaginação sobre a inteligência.
• A segunda implementação SOA em uma empresa é o triunfo da esperança sobre a experiência.

O último relatório técnico do Gartner Group sobre softwares de infra-estrutura para projetos de EAI (integração de aplicações) traz algumas novidades interessantes:

• Notamos a prevalência técnica e comercial da IBM, Microsoft e TIBCO no quadrante dos líderes. A TIBCO por seu amplo e respeitável histórico técnico neste mercado, a Microsoft por sua grande atuação no mercado de integração de aplicações nos últimos anos e a IBM por sua competência técnica e enorme carteira de clientes.
• A Oracle ganha força com a incorporação realizada em 2008 dos excelentes produtos técnicos da linha AquaLogic da BEA.
• Empresas como SAP, NEC e Hitachi se destacam pela sua atuação comercial e por boas soluções técnicas, o que os credenciam como membros do quadrante desafiantes.
• Produtos Open-Source de EAI da SUN e RedHat JBOSS estão presentes no quadrante mágico. Isso é uma excelente notícia para empresas com orçamentos mais limitados e que ainda não possuam confiança em produtos SOA/ESB. A SUN, neste aspecto, se destaca por estar no quadrante de líder e obter uma excelente pontuação técnica.
• Empresas de nicho como SoftwareAG, Fiorano, iWay, Sterling, entre outras, se mantém firmes nesta acirrada luta que conta com gigantes de TI.

Um breve resumo do mesmo (quadrante mágico) é colocado abaixo:

Figura - Magic Quadrant for Application Infrastructure for Back-End Application Integration Projects - © 2008 Gartner, Inc. and/or its Affiliates.

Recomendo a leitura do artigo completo que traz, para cada fornecedor, pontos fortes e pontos de atenção e outras informações ricas para gerentes e técnicos que trabalhem com projetos EAI.

Agora em Janeiro será lançado a segunda edição do livro SOA for Dummies, da autora Judith Hurwitz.

Não se deixe enganar pelo título. Apesar de ser um livro de introdução ao tema, o livro merece estar na biblioteca de qualquer empresa que trabalhe seriamente com SOA. O livro traz como principal novidade frente à primeira edição estudos de casos com diversas empresas e a coleta de lições aprendidas no período de 2007 a 2008.

Conforme descrito pela autora, as principais lições aprendidas em implementaçòes de projeto SOA foram:

• Projetos e empresas de sucesso começaram com serviços de negócio e processos de negócio antes de pensar em qualquer aspecto de implementação. Em outras palavras, SOA deve ser dirigida por BPM e não através de mecanismos tecnicistas como Web Services, ESB e adaptadores.
• Houve um grande aprendizado das empresas com projetos pilotos. O foco agora é em como melhorar as receitas de negócio através do reuso de serviços.
• As empresas desenharam uma estratégia de longo prazo através de uma implementação iterativa e incremental de serviços.
• Algumas poucas empresas aprenderam como criar serviços de ativos legados (Arqueologia de Software) e como reforçar o reuso destes serviços em novas aplicações (Reuso de Software).
• Companhias praticantes de SOA aprenderam, com um custo muito maior que o imaginado, como criar serviços de negócio com múltiplos usos em diversos processos de negócio.

Outras novidades do livro incluem Gerência de Serviços, Qualidade de Serviço, Componentização e também interação com BPM. Mais informações sobre este lançamento podem ser encontradas aqui.

Acontece hoje em Belo Horizonte o Java Developer’s Day 2008 da ASSESPRO-MG. Tivemos a oportunidade de abrir o evento com uma palestra que disponibilizo aqui (Tecnologias Java para BPM e SOA).

Discutimos nesta palestra os principais padrões Java (WS-*, JBI e SCA) e tecnologias relacionadas (suítes BPM ou BPMS) para o suporte à implementação de projetos BPM e SOA. Para os iniciantes em BPM, recomendo a leitura dos seguintes posts sobre o assunto:

• BPM para Leigos
• Recursos Conceituais BPM

A Fauna BPMS

Ferramentas BPMS Open-Source

• Intalio (Conforme discutido na apresentação, talvez a suíte open-source mais robusta para BPMS).

Ferramentas Open-Source BPMS que suportam o padrão JBI

• Open ESB
• JBOSS ESB
• Apache Service Mix
• Mule
• OpenFuse

Ferramentas BPMS que suportam o padrão SCA

• Apache Tuscany Open-Source
• Eclipse STP Open-Source
• Mule Open-Source
• IBM WebSphere
• BEA AquaLogic

Eu e o Eros Viggiano criamos recentemente um blog dedicado ao assunto arquitetura de software. Diferentemente de outros (excelentes) blogs sobre o tema, o objetivo do nosso canal é fornecer uma visão sócio-técnica sobre arquitetura de software. A abordagem sócio-técnica é uma visão da administração que acredita que processos complexos devem ser compreendidos através da interação de aspectos humanos e aspectos tecnicistas.

Entendemos que uma arquitetura de software não se realiza apenas com ferramentas, técnicas e processos; mas com pessoas motivadas, liderança e times organizados com as ferramentas, técnicas e processos corretos. Entendemos também que a arquitetura de software, que surge como disciplina na engenharia de software no começo dos anos 90, ainda requer de muita investigação e muita discussão para se tornar uma ciência. Esperamos poder contribuir para o fomento desta importante área aqui no Brasil.

Boas Arquiteturas!

DeArchitectura - Uma Visão Sócio Técnica sobre Arquitetura de Software

Li recentemente um artigo que propõe um tema interessante ao discutir a personalidade de arquitetos de software e gerentes de projeto e a sua relação (normalmente tensa) em projetos de software. (The Tense Relation between Architect and Manager, Gerrit Muller).

Arquitetos e gerentes são peças fundamentais para o sucesso de um projeto e devem interagir fortemente em sinergia, como já apontado por Grady Booch em seu excelente livro Object Solutions, de 1995.

Um aspecto que Gerrit Muller endereça são os comportamentos associados a cada papel. Um resumo destas características é colocado abaixo:

• Arquitetos tem um escopo amplo em projeto e pouca autoridade formal. Gerentes, por sua vez, tem um escopo de atuação mais limitado e possuem muita autoridade formal.
• Arquitetos são independentes, criativos e curiosos. Gerentes são pragmáticos e focados em controles.
• Arquitetos encaram mudanças; vindas dos stakeholders, pressões de tempo e análise de problemas; como fatos da vida. Gerentes encaram mudanças como possíveis fontes de problemas e desvios financeiros.
• Arquitetos são motivados pela busca das melhores soluções. Gerentes são motivados por hierarquias e salários.

O autor coloca, finalmente, que arquitetos e gerentes devem buscar, conjuntamente, as seguintes técnicas para a melhoria do relacionamento e resolução destes problemas:

• Maior delegação de tarefas.
• Liderança ao invés de gerenciamento baseado em tarefas.
• Trabalho em time.
• Respeito mútuo.
• Reconhecimento da diversidade.
• Feedbacks contínuos.
• Estímulo à uma comunicação aberta e franca.

Recentemente, escrevi uma compilação de características de liderança de arquitetos de software, inspirados nos comportamentos de liderança descritos por Stephen Covey. Acredito que estas características podem ajudar a resolver este problema e promover como conseqüência maior sucesso aos projetos.

Creio que o maior valor do interessante artigo do Gerrit Muller é tornar claro que arquitetos e gerentes possuem sistemas de crenças e visões de mundo diferentes. Arquitetos e gerentes não podem cometer o erro de assumir que a outra parte irá pensar e agir como ele. Ao invés, gerentes e arquitetos devem conhecer a natureza da outra parte e desenvolver mecanismos pró-ativos para melhorar a comunicação e alinhamento nos projetos.

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.