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.