Compilo aqui um pequeno glossário de termos usados dentro do processo de arquitetar software. Estes termos foram compilados a partir de fontes diversas da literatura de arquitetura, da experiência de colegas de trabalho e também da nossa experiência em projetos. Acredito sinceramente que estes termos podem ajudar arquitetos a comunicar conceitos e remover mal-entendidos comuns em projetos de TI, especialmente com leigos na disciplina de arquitetura de software.

Condutor Arquitetural
Uma importante diretriz, de natureza de negócio ou técnica, que conduz e influencia as decisões arquiteturais primordiais de um projeto. Os condutores arquiteturais expressam os principais elementos da estratégia arquitetural a serem observados pelo time de arquitetura.
Como exemplo, um projeto de um novo portal governamental pode ter como condutores a universalização do acesso (padrão EGov), a confidencialidade dos dados dos contribuintes e não repudiação no acesso das informações.
Condutores são negociáveis e devem ser priorizados conforme a sua importância estratégica ou tática dentro do cronograma de um projeto.
Projetos de complexidade média possuem entre seis e doze condutores. Projetos muito complexos podem ter algumas dezenas de condutores.

Princípio Arquitetural
Um princípio arquitetural é um tipo especial de condutor, que se torna tão importante que passa a ser não negociável. Um princípio arquitetural é também chamado de meta-condutor.
Como exemplo, um projeto de um home-banking pode ter como um dos seus princípios arquiteturais o elemento a segurança dos dados de um correntista, enquanto que um projeto de uma promoção de um feriado comemorativo em uma empresa de TELECOM pode ter como princípio arquitetural o tempo de mercado.
Projetos devem ter poucos princípios arquiteturais (Normalmente um número entre três e seis princípios)

Requisito Arquitetural
Um requisito arquitetural é um requisito de alto valor de negócio, alta complexidade e abrangência técnica e que permite detalhar um condutor arquitetural. Requisitos arquiteturais devem ser específicos, mensuráveis, atingíveis, realizáveis e rastreáveis. Por exemplo, no exemplo anterior da segurança para o sistema de home banking, poderíamos identificar um requisito arquitetural de autenticação que requer que usuários sejam corretamente identificados no primeiro acesso a um portal.

Requisitos arquiteturais não são necessariamente requisitos não-funcionais. Requisitos arquiteturais podem advir de requisitos funcionais, desde que estes gerem impacto para a arquitetura. Por um exemplo, um requisito de cadastro de bilhetes em um sistema de bilhetagem de TELECOM pode gerar impacto para a arquitetura de persistência, dado que as bases de dados podem precisar manter e recuperar quase 1 bilhão de registros em alguns exemplos reais no Mercado Brasileiro.

Visão Arquitetural
A visão arquitetural expressa os objetivos primários do esforço arquitetural dentro de um projeto de TI. A visão arquitetural promove o alinhamento das estratégias técnicas à visão de um produto a à estratégia de uma organização.
A visão arquitetural pode ser complementada com um primeiro rascunho ou desenho chamado de visualização de negócio (esboço arquitetural).

Visualização de Negócio
Também chamada de esboço arquitetural ou marketecture, é um diagrama de forma livre e com formas humanizadas que permite comunicar o propósito da arquitetura a todos os envolvidos de um projeto, inclusive gerentes e leigos.
Muitas vezes esta visualização de negócio é denominada, incorretamente, de arquitetura, por leigos na terminologia técnica de arquiteturas de software.

Estratégia Arquitetural
A estratégia arquitetural define a forma de atuação básica do esforço arquitetural. Advinda da escola do pensamento estratégico (OMG BMM e BSC), a estratégia é composta da visão arquitetural, da visualização de negócio e é baseada também nos princípios e condutores arquiteturais.

Tática Arquitetural
Uma estratégia é composta por um conjunto de táticas. Uma tática arquitetural, também chamada de mecanismo arquitetural por alguns autores, define uma preocupação importante no espaço da solução. Exemplos de táticas podem incluir a persistência de objetos, a interoperabilidade entre aplicações ou a auditoria.
Um tática pode ser expressa em nível de análise, nível de desenho ou nível de implementação, à medida que for refinada dentro de um projeto. Por exemplo, o requisito arquitetural que expressa que usuários sejam corretamente identificados pode ser expresso nas seguintes táticas:
• Tática de análise: Autenticação
• Táticas de desenho: Autenticação com LDAP ou Autenticação com Kerberos
• Tática de implementação: Autenticação com os produtos OpenLDAP ou Microsoft AD com Kerberos.

Plano Arquitetural
Reflete o planejamento do projeto referente às ações do time de arquitetura. Este plano é desenhado a quatro mãos pelo arquiteto de software e o gerente do projeto.

Risco Arquitetural
É um risco que pode afetar a arquitetura do projeto e eventualmente gerar um colapso técnico dentro do produto. Por exemplo, dentro de um projeto que envolva a comunicação em tempo real entre dois sistemas, a latência de disco pode ser um risco arquitetural que deve ser identificado e mitigado.

Arquitetura Candidata
É um primeiro desenho da arquitetura, com as principais decisões e estratégia do projeto. É normalmente usada para gerar um processo de viabilidade técnica do produto nas fases preliminares de um projeto. Em projetos ágeis, deveria ser o produto de um primeiro Sprint. Em projetos baseados no UP, deveria ser produzida no primeiro décimo de um projeto.
Em diversos processos e métodos, é formalizada em um documento chamado de Documento de Arquiteutra de Software (DAS).

Arquitetura Executável
Representa uma arquitetura que contenha fragmentos de códigos executáveis, normalmente produzidos para mitigar riscos arquiteturais de táticas e requisitos arquiteturais complexos. Uma arquitetura executável é refinada ao longo de um projeto, embora deva ser trabalhada com mais ênfase nas fases iniciais de um projeto.
Quando uma arquitetura executável consegue mitigar todos os principais riscos de uma arquitetura, esta é chamada de arquitetura executável estável. Em processos baseados no UP, a arquitetura executável estável é o marco de fim de fase de Elaboração.

Recentemente, a arquiteta Ruth Malan, que é co-autora de um dos mais brilhantes métodos de arquitetura de software - o VAP, fez uma defesa enfática da importância das representações visuais no processo de arquitetar aplicações, em uma palestra recente na SATURN 2010 - talvez a melhor conferência de arquitetura de software da atualidade.

Uma das fontes de inspiração do trabalho dela é o excelente livro chamado The Back of The Napkin, que sinceramente recomendo a toda e qualquer pessoa que trabalhe com TI. O conceito e (o livro) são excelentes e podem ser aplicados em qualquer contexto de TI e em especial arquiteturas de software.

Ruth Malan define bem o valor das arquiteturas visuais na frase abaixo.

“The universal fundamental, though, is drawing people in. Getting input, defining the outcomes we want from the whole, designing the parts and their relationships so that we achieve those outcomes, and helping everyone who will build or configure the parts understand how they contribute to the outcomes of the whole.” Creating the pictures that draw people in.

Modelos são usados há bastante tempo na arquitetura e esta idéia não aparenta ter nenhuma novidade. Mas arquiteturas visuais adicionam os seguintes valores:

• Figuras são usadas fundamentalmente para envolver e promover a comunicação de pessoas, remover ambiguidades e promover colaboração;
• Figuras são expressas em elementos simplistas e não necessariamente expressos em nenhuma notação formal como BPMN ou UML, o que traz agilidade ao processo;
• Figuras são usadas para representar o espaço do problema, e não apenas o espaço da solução;
• Figuras estimulam o lado direito do cérebro, o que aumenta o nível de criatividade e intuição na resolução de problemas e que cria um contra-ponto à nossa educação formal, muito tendenciosa ao uso das funções dominantes do lado esquerdo do cérebro.

Métodos ágeis e em particular, o excelente trabalho de comunicações quentes de Allistair Cockburn, enfatizam a força da comunicação através de representações gráficas em quadros brancos.

Acredito profundamente nestes princípios e reconheço que os times de TI conheço, em sua maioria, não usam o potencial das arquiteturas visuais. Para os mais curiosos, recomendo assistir aos princípios básicos do site The Back of The Napkin, que mostra um processo disciplinado para melhorar a comunicação através de metáforas visuais.

Para os interessados em entender este processo na arquitetura de software, recomendo o blog e a apresentação realizada pela Ruth Malan.

P.S. - Post-Scriptum

Para os curiosos sobre a citação sobre lado direito e lado esquerdo do cérebro, segue um teste para determinar o lado dominante do seu cérebro. Olhe a figura abaixo.

Se você ver a dançarina girar conforme os ponteiros do relógio, o seu lado direito está dominando a ação. Caso contrário, o lado esquerdo do cérebro está dominando a ação. É possível ate mesmo mudar a direção da dançarina, se você focar o seu cérebro para isso, conforme o autor deste interessante teste.

Era uma vez, na época em que os animais ainda falavam, três porquinhos que viviam felizes e despreocupados como analistas de sistemas nas suas empresas. Seus nomes eram Fanático, Lunático e Pragmático. Certo dia, os porquinhos foram promovidos a arquitetos de software pelo rei da floresta, o rei Leão.

O rei Leão disse:
- Queridos colaboradores, vocês já estão bem crescidos. Já é hora de terem mais responsabilidades e para isso é bom morarem sozinhos e construírem suas próprias casas.

Os três porquinhos arquitetos, então, partiram pelas florestas corporativas em busca de um bom lugar para construírem as suas casas. Porém, no caminho começaram a discordar sobre como construir as suas casas.
Cada porquinho queria usar um metodologia diferente.

O primeiro porquinho, o porquinho Fanático, um dos preguiçosos, foi logo dizendo:
- Não quero ter muito trabalho! Ouvi falar de um método ágil chamado Screw It! que diz que casas de palhas são mais rápidas. Não precisamos de plantas, nem fundações e por isso são muito rápidas. Basta comprar um monte de palha e empilhá-la.

O porquinho pragmático advertiu:
- Uma casa de palha não é nada segura.

O outro porquinho, o irmão do meio que era chamado de porquinho Lunático também deu seu palpite:
- Prefiro terceirizar a minha casa, que será de madeira. Recebi uma planta arquitetural em um Documento de Arquitetura de Software de 200 páginas da empresa ACME, a preços módicos e condições de financiamento incomparáveis.

Comprar uma casa baseada apenas na planta arquitetural não é nada seguro - comentou o mais velho. Como você vai garantir que os materiais estarão corretos e que a fundação suportará o seu peso? Onde estão as provas de conceito e a arquitetura executável? Esta planta foi assinada por um engenheiro?

Os porquinhos ironizam o porquinho Pragmático, o mais velho, que foi construir a sua casa de tijolos com métodos arquitetônicos provados. Ele montou uma planta arquitetural, organizou os materiais corretos, fez provas de conceito e acompanhou os resultados do trabalho em conformidade com a planta.

Os outros porquinhos também começaram a criar as suas casas. Na primeira semana, o porquinho fanático terminou a sua casa. Já estava descansando quando o irmão do meio, que havia construído a casa de madeira chegou chamando-o para ir ver a sua casa terceirizada, cuja fachada era igualzinha ao prometido na planta arquitetural.

Os porquinhos preguiçosos, o Lunático e o Fanático, foram visitar seu irmão mais velho, o porquinho Pragmático.

O porquinho Fanático disse:
- Nossa! Você ainda não acabou! Não está nem na metade da Fase de Elaboração! Nós agora vamos almoçar com o Rei Leão, que ficou feliz ao receber mais duas casas da sua floresta. Ele está pensando em nos promover a gerentes!! hahaha… Se você fosse agilista como eu, teria terminado a sua casa.

O porquinho mais velho porém não ligou para os comentários e continuou a trabalhar. Ele preparava o cimento e montava as paredes de tijolos. Após quatro semanas de trabalho intenso, a casa de tijolos estava pronta, e era robusta!

Os dias foram passando, até que um lobo, chamado Mudança, percebeu que havia porquinhos morando naquela parte da floresta. O Lobo Mudança foi então bater na porta do porquinho mais novo, o da casa de palha.
Ele soprou, soprou e soprou e as mudanças vieram. A casa do porquinho Fanático sucumbiu e ele correu para a casa do porquinho Lunático.

O Lobo Mudança foi bater agora na casa do porquinho do meio, o Lunático. Ele soprou, soprou e soprou e mais mudanças vieram. A casa terceirizada não tinha uma boa estrutura e a madeira estava infestada de cupins. A casa sucumbiu e então os dois porquinhos correram para a casa do irmão mais velho, o porquinho Pragmático.

O Lobo Mudança foi agora bater finalmente na casa do porquinho Pragmático. Ele soprou, soprou e soprou. Entretanto, a casa era robusta e o lobo Mudança não conseguiu desmontar a casa com a boa arquitetura.

O Rei Leão soube do ocorrido e foi correndo para a casa do porquinho Pragmático. Ele despediu e comeu os porquinhos preguiçosos em um almoço corporativo de lombo com pururuca. O Lobo Mau foi também convidado e se deleitou com a iguaria corporativa fornecida pelo rei Leão.

No fim, o Rei Leão, o Lobo Mudança e o Porquinho Pragmático viveram felizes para sempre!

Qualquer semelhança com fatos e evento reais não é mera coincidência.

O conceito de Arquitetura Corporativa existe já há quase 30 anos na indústria de TI e administração, mas apenas nos últimos anos tem obtido alguma visibilidade no mercado Brasileiro. Mas o que é mesmo uma Arquitetura Corporativa?

Adaptei um meta-modelo de um corpo de conhecimento chave para arquitetura corporativa, o TOGAF, que mostra a visão holística da arquitetura dentro de uma empresa.

Uma arquitetura corporativa tem alguns pontos chave, que destaco aqui:

• ênfase no pensamento estratégico de forma que o time de arquitetura gere uma visão arquitetural para todo projeto, de forma que que todo o esforço do time de arquitetura seja convergente às expectativas de negócio dos gestores;
• a clara necessidade de organizar os requisitos arquiteturais do projeto antes que a solução seja endereçada;
• a decomposição da arquitetura em quatro disciplinas: arquitetura de negócio, arquitetura de aplicações/software, arquitetura de dados e arquitetura tecnológica;
• a governança de todo o esforço arquitetural nos projetos, iniciativas e oportunidades, i.e, um controle dos artefatos arquiteturais gerados, a mensuração do valor gerado por estas iniciativas e o controle dos ciclos de melhoria contínua.

De forma pragmática, a arquitetura corporativa nos ensina que escolher uma tecnologia no primeiro dia do projeto normalmente tende a ser uma má idéia. Isso traz uma profunda implicação para os “arquitetos Java EE” ou os “arquitetos .NET” que usualmente levam a sua tecnologia a tira-colo antes de entender o problema, a estratégia de uma organização e capturar corretamente os requisitos arquiteturais que eles devem endereçar. Em verdade, o próprio termo “arquiteto Java EE” ou “arquiteto .NET” traz uma contradição per se.

O tema arquitetura corporativa é ainda muito vasto e desafiador, mas a internalização dos alguns dos seus princípios fundamentais pode nos ajudar a resolver problemas de TI de forma a gerar maior valor de negócio para as empresas e com soluções mais robustas e assertivas.

Compartilho aqui dois módulos da nossa apresentação realizada ontem no evento Maré de Agilidade. O primeiro módulo fala sobre o papel do arquiteto de software a importância da arquitetura de software. O segundo módulo fala sobre o conceito de arquiteturas ágeis e técnicas de mercado para a criação de arquiteturas evolutivas.

Arquiteturas ágeis partem da premissa que nem todo condutor arquitetural possa ser antecipado e desenvolvido antes que a primeira versão do produto vá para a produção. Normalmente, arquiteturas ágeis procuram implementar os elementos técnicos críticos ao longo das entregas parciais de um produto ou projeto, em conjunto com as funcionalidades de maior valor de negócio para os seus usuários

Esta abordagem é, tecnicamente falando, bem mais arriscada que manter uma fase de elaboração que procure acomodar os riscos técnicos através da realização de todos os condutores arquiteturais importantes. Métodos como o UP usam a abordagem tradicional, enquanto métodos como o XP usam a abordagem ágil.

De volta às arquiteturas ágeis, como lidar com o dilema de intercalar condutores arquiteturais, elementos funcionais e software em produção. A chave para lidar com a antecipação de um investimento arquitetural para uma futura funcionalidade, segundo Nanette Brown, é fazer a você e ao seu time as seguintes perguntas:

• O quão provável que a futura funcionalidade seja realmente necessária no produto? É importante lembrar, conforme pesquisas diversas (ex: Standish Group), que quase metade das funcionalidades solicitadas de um produto são raramente ou nunca usadas.
• Existe um investimento arquitetural que eu possa fazer agora que irá reduzir o custo futuro de implementar esta funcionalidade?
• Qual o custo do investimento arquitetural? (ex: custo da oportunidade, custo de implementação)
• Qual a consequência econômica de no futuro precisar implementar a funcionalidade sem o investimento arquitetural realizado a priori?

A metáfora do cheque especial

O famoso agilista Ward Cunninghan possui uma excelente metáfora, do cheque especial, que compartilho aqui. Ele diz que ao entregarmos um produto com uma arquitetura sub-ótima (ex: não performática ou com uma usabilidade deficitária, caso estes sejam condutores importantes), estamos usando um cheque especial técnico.

Os juros deste cheque especial implicam que futuras melhorias no sistema irão custar mais tempo e esforço para serem atendidas. Por exemplo, é claramente mais simples montar um sistema com um estilo de acessibilidade WCAG AA previamente definido do que refatorar 50 páginas em produção para se adequar a este condutor.

Se as técnicas de refatoração arquitetural não forem usadas para pagar a dívida técnica a tempo, o sistema irá se degradar tecnicamente ao longo do tempo e levar o seu “sistema econômico” à falência.

Como todo empréstimo bancário, devemos avaliar se é prudente “tomar dinheiro emprestado” no banco arquitetural. Se tomarmos dinheiro emprestado, devemos investir tempo e esforço em técnicas de refatoração arquitetural para pagar o débito rapidamente.

Arquiteturas ágeis podem ser excelentes instrumentos de acomodar as pressões de mercado, mas devem ser cuidadosamente elaboradas e pensadas para que o “fluxo de caixa do seu produto” continue saudável e você não tenha graves problemas em produção.

5 Minutos com Ward Cunninghan
Para os mais interessados no assunto, recomendo este pequeno vídeo de 5 minutos do autor.

Um velho paradigma de TI é traduzir o conceito da construção de sistemas de informação (da administração) para a construção de grandes sistemas de informação automatizados de TI. É fácil reconhecer este paradigma, que se manifesta pelos seguintes sintomas:

• grandes especificações de requisitos, que consomem meses (ou anos) para a produção de livros (obsoletos no dia D+1);
• projetos com cronogramas gigantes e orçamentos com 6 dígitos;
• grandes equipes;
• sistemas monolíticos baseados na tecnologia da década (Cobol, Pascal, C, Java, C# ou linguagens dinâmicas);
• sistemas incapazes de gerar valor de negócio e obsoletos antes mesmo de entrar em produção;
• prejuízos proporcionais ao tamanho do desafio e um sentimento de incapacidade.

Pense em capacidades de negócio e serviços
Citando um velho ditado latino chamado “Divide et impera”, a chave para sermos efetivos é quebrar o conceito de “sistemas de TI” e pensar em termos do conceito de capacidades de negócio e também em termos de serviços de negócio. Serviços de negócio são pequenos módulos de negócio que geram algum valor de negócio para a organização. A vantagem desta abordagem é que serviços de negócio podem ser colocados rapidamente em produção, gerar valor real de negócio muito mais rapidamente e permitir uma adaptação do negócio a mudanças do mercado.

Dê menos ênfase em arquiteturas de sistemas de software. Dê mais ênfase em arquiteturas de referência de serviços
Se os serviços de negócio forem criados sem uma fundação, a tendência é que eles gerem um tipo de construção arquitetural chamada “puxadinho de software”. Antes que serviços sejam criados, mantidos e evoluídos, uma fundação para estes serviços deve ser estruturada e criada. Esta fundação é chamada de arquitetura de referência de serviços e opera como um elemento que permite acomodar estes serviços ao longo do tempo em termos dos seus elementos técnicos e de seus elementos de governança.

Pense na ótica de negócio
A TI não existe para o seu próprio fim. O fim da TI é potencializar negócios. Permitir aos decisores, através da agilidade e sustentabildiade dos serviços de negócio, uma rápida tomada de decisão pode fazer toda a diferença nas organizações. O pensamento na ótica de negócio requer uma mudança de filosofia na parte de TI. Sistemas monolíticos com ciclo de vida de meses ou anos podem ser “divertidos empreendimentos técnicos” ou “máquinas de faturamento de fábricas de software”, mas tem comprovadamente e repetidamente gerado fracassos retumbantes.

Todo software instalado possui uma arquitetura que o rege, seja esta tácita ou explicitamente construída por arquitetos de software. Além disso, toda arquitetura tem um estilo associado. Se não pensamos na arquitetura de um software e no estilo desta arquitetura, ela pode ter um estilo diferente do que gostaríamos. Um estilo inadequado pode aumentar sobre-maneira os custos de construção e manutenção de uma aplicação.

Estilo Arquitetural - O padrão primordial para externalização da sua arquitetura

Um estilo arquitetural é um padrão arquitetural primordial que antecede todos os outros padrões arquitetural.Ele define e direciona outros padrões arquiteturais, padrões de desenho e decisões táticas ao longo do projeto. Exemplos de estilos arquiteturais incluem:

• Cliente-Servidor
• Baseado em cadastros Web
• Aplicações Ricas de Internet (RIA)
• Multi-camadas (n-camadas)
• Baseado em integração de aplicações (EAI)
• Baseado em serviços
• Baseado em processos de negócio
• Dirigido por domínio (DDD)
• Baseado em computação em grade (Grid)
• P2P

Normalmente uma aplicação possui apenas um estilo arquitetural, embora em situações incomuns possamos ter estilos combinados ou mesmo um estilo particular. A escolha de um estilo, entretanto, não é escolhida pela conveniência de um arquiteto, mas pelos condutores de negócio do projeto, produto e empresa do contexto onde a arquitetura e o software estejam sendo produzidos.

Se escolhermos um estilo inadequado, o projeto sofrerá sérias dificuldades. Por não pensar no estilo, desenvolvedores são guiados por decisões táticas, o que leva na maioria dos casos a sistemas de informações cadastrais, mesmo quando o estilo tem outra natureza. Acompanhei um colega de profissão que foi comandado a usar um framework de mercado que automatiza padrões cadastrais em um sistema de estilo baseado em fluxos de trabalho. A equipe deste colega de profissão tentou durante alguns meses resolver o projeto, até que o projeto fosse cancelado devido a uma baixíssima produtividade.

Ao começar o seu projeto, então, convoque uma entrevista com os seus usuários e investigue o estilo arquitetural do sistema que você irá construir.

Pensamento do dia: “Bona diagnosis, bona curatio”, (Um bom diagnóstico, uma boa cura)

A abordagem tradicional para SOA está baseada nas premissas da modelagem, simulação, automação, monitoração e gerência de processos de negócio, i.e, o ciclo de vida de BPM (Gerenciamento de Processos de Negócio). Existem diversos cenários, entretanto, onde esta premissa não se torna válida.

Caso a nossa empresa ou o problema em questão apresente a lista de condutores abaixo, uma abordagem arquitetural mais adequada é a orientação por eventos.

Condutores Arquiteturais para CEP (Processamento de Eventos Complexos)

• Agilidade e adaptabilidade.
• Gerenciamento por exceção.
• Respostas imediatas.
• Respostas instantâneas a eventos que ocorrem fora do seu eco-sistema de parceiros.
• Resposta a situações não antecipadas.

O CEP como um contraponto ao BPM tradicional

Dois cenários clássicos deste contexto são aplicações que monitoram fraudes e aplicações que reagem a eventos de mercado para sistemas de suporte a decisão de investidores. Uma abordagem tradicional baseada em BPM geraria um esforço absurdo na tentativa de modelar diversos caminhos e percursos de processos e situações, sendo que muitas destas situações ainda não são conhecidas.

No paradigma CEP (Complex Event Processing), a chave é adaptar software chamados de máquinas de eventos para ouvir a determinados tipos de eventos que necessitem ser monitorados. Estes eventos podem ser capturados de bases de dados, ERPs, CRMs e outros elementos arquiteturais do seu eco-sistema. A partir da sua máquina de eventos, processos podem ser iniciados ou outras ações podem ser disparadas. Por exemplo, se três eventos de uso de cartão de crédito ocorrem em um intervalo de cinco minutos com soma total acima de 500 reais, a máquina de eventos poderia solicitar a um operador do call-center ativo para retornar uma ligação a um cliente.

O CEP não invalida o BPM, assim com um contraponto musical não invalida a melodia central da música. Pelo contrário, o CEP enriquece o BPM, pois permite que processos de negócio sejam invocados de formas inesperadas. No cenário acima, o processo de monitorar compras do cliente pode ser invocado a partir de uma máquina de eventos, gerando maior eficiência e assertividade em uma administradora de cartão de crédito.

Uma arquitetura de TI que suporte o modelo CEP é chamada de EDA, i.e, Event Driven Architecture. Dentro do amplo leque de ferramentas SOA, temos diversos fornecedores com bons produtos EDA/CEP.

Esta é uma tradução pessoal do SOA Manifesto Guiding Principles criado por Ali Arsanjani, Thomas Erl, Grady Booch e outros notáveis.

Bons projetos SOA!