Architecture Principles

Chamamos de “princípio” toda e qualquer regra geral e/ou orientação que se destina a ser duradoura e raramente alterada. Para a arquitetura corporativa, um princípio informa e apoia a maneira no qual uma organização cumpre sua missão.

Os chamados “Princípios de Arquitetura” são um subconjunto dos princípios de uma empresa e se relacionam com o trabalho de arquitetura. Eles refletem um nível de consenso em toda a empresa e encarnan o espírito e o pensamento da arquitetura corporativa. Os princípios de arquitetura podem ser divididos em:

• Princípios que regem o processo de arquitetura, afetando o desenvolvimento, manutenção e utilização da arquitetura corporativa;
• Princípios que regem a implementação da arquitetura, que estabelece os primeiros princípios e orientação relacionada para projetar e desenvolver sistemas de informação;

Segundo o TOGAF, o formato recomendado para definção de um princípio de arquitetura é o descrito a seguir:

Nome Deve representar a essência da regra, bem como ser de fácil lembrança. Plataformas de tecnologia específica não devem ser mencionadas no nome ou na declaração de um princípio.

Afirmação Deve, de forma sucinta e inequívoca, comunicar a regra fundamental.

Base lógica Deve destacar os benefícios de negócio ao se aderir ao princípio, usando a terminologia de negócios. Também descreve a relação com outros princípios e intenções em relação a uma interpretação equilibrada.

Implicações Deve destacar como os requisitos afetam – em termos de atividades/tarefas – custos e recursos. O impacto nos negócios e consequências da adoção de um princípio deve ser claramente indicado. O leitor deve prontamente discernir a resposta: “Como isso me afeta?”. É importante não simplificar, banalizar ou julgar o mérito do impacto.

Assim, um exemplo de princípio de arquitetura pode ser conferido abaixo:

Nome	Reuse
Statement	Common components in the IT architecture should be used while building an application and enterprise requirements.
Base lógica	Business units have common needs and requirements, yet each business unit has developed their own implementations of these common tasks.
Implicações	- Developing common assets will reduce support costs. - Leads to faster application development. - If not followed, will restrict the ability to integrate or to use systems with functions that new applications could leverage.

Por enquanto, era isso. Em posts futuros, explorarei com mais detalhes o tema.