Enterprise Architecture II - Introdução

Como abordei no post anterior, a EA surgiu a aproximadamente 22 anos com o intuito de sanar dois problemas de TI que começaram a ganhar corpo naquela época: Gerenciamento da crescente complexidade dos Sistemas de TI e a dificuldade de produzir valor real para o negócio com aqueles sistemas.

Podemos notar que esses problemas são correlatos, ou seja, quanto mais complexo um sistema, menor probabilidade dele gerar valor real para o negócio, e o contrário também é verdadeiro, quanto melhor administrado a complexidade de um software, maior a possibilidade dele propiciar valor real ao negócio.

Entre os motivos para uma pessoa se interessar por EA podemos citar : Se o controle da complexidade do sistema e a geração de valor para o negócio forem suas principais prioridades; Se estiver preocupado com a manutenção, reforma ou com a credibilidade do setor de TI da sua organização; Se luta para promover o uso da TI para manter uma posição competitiva em seu setor.

Se nenhum dos motivos citados forem de interesse, essas metodologias tem pouco a oferecer.

Em Sistemas da Informação se você estiver construindo um sistema simples, não distribuído e para um único usuário, provavelmente não precisara de um arquiteto, porém se estiver construindo um sistema para utilização de toda empresa, altamente distribuído, de missão crítica, provavelmente precisará de arquitetos de banco de dados, soluções, infra-estrutura, negócio e um arquiteto corporativo.

A responsabilidade por desenvolver toda a visão arquitetural de uma organização é do Enterprise Architect. Ele é o arquiteto especializado na visão mais ampla possível da arquitetura dentro da empresa. Ele é o arquiteto dos arquitetos, o responsável por coordenar o trabalho dos demais arquitetos. Se você precisará ou não de um arquiteto desta categoria dependerá do que você pretende construir.

Construir um sistema de informação de grande porte, complexo, que abranja toda empresa sem um arquiteto corporativo é o mesmo que tentar construir uma cidade sem um urbanista. Você talvez consiga construir uma cidade sem um urbanista, mas gostaria de morar nela? Provavelmente não.

Contratar um urbanista não significa que você terá uma cidade habitável, mas melhora suas chances. Da mesma forma um arquiteto corporativo não garante uma EA bem sucedida.

Segue abaixo algumas definições de palavras que serão utilizadas nos demais post's:

· Arquiteto

o Profissional sob cuja responsabilidade está o projeto de uma arquitetura e a criação de uma descrição arquitetural.

· Artefatos Arquiteturais

o Documento, relatório, análise, modelo especifico ou outro produto tangível que contribui para uma descrição arqutetural.

· Descrição Arquitetural

o Conjunto de artefatos para documentar uma arquitetura.

· Framework Arquitetural

o Estrutura esquematizada que define artefatos arquiteturais sugeridos, descreve qual a inter-relação desses artefatos e fornece definições genéricas para a provável aparência desses artefatos.

· Metodologia Arquitetural

o Termo genérico que pode descrever qualquer abordagem estruturada para resolver alguns ou todos os problemas referentes à arquitetura.

· Processo Arquitetural

o Série definida de ações, cuja finalidade é produzir uma arquitetura ou uma descrição arquitetural.

· Taxonomia Arquitetural

o Metodologia para organizar e categorizar artefatos arquiteturais.

· Arquitetura

o Organização fundamental de um sistema incorporado em seus componentes, as relações desses componentes entre si, com o ambiente, e os princípios que orientam o seu projeto e sua evolução.

· Arquitetura corporativa
o Arquitetura em que o sistema em questão representa toda empresa, especialmente os processos do negócio, as tecnologias e os sistemas de informação da empresa.

No próximo post falarei um pouco sobre o histórico da Enterprise Architecture.

"O trabalho afasta de nós três grandes males: o tédio, o vício e a necessidade." (Voltaire)