A Diferença de EA e Arquitetura de Software

Neste posta venho falar de arquitetura, falando de software existem vários níveis de arquitetura, hoje venho escrever um pouco mais sobre isso. Vou ficar com dois níveis ou tipos de arquiteturas que são a Arquitetura de Sistema e a Arquitetura Corporativa. Ainda pretendo traçar uma pequena relação do tema como SOA.

A Arquitetura de software é uma prática muito saudável, framework de desnevolvimento de software como o RUP e OpenUP são baseados na Arquitetura como suporte ao desenvolvimento. Mas existe um grande diferença da Arquitetura de Sistema e da Arquitetura corporativa.

A Complexidade

A Arquitetura de sistemas além de servir como suporte para o desenvolvimento, isso não significa fazer tudo para o desenvolvedor, mas significa pegar as maiores pedras, ou seja, as coisas mais complexas.

Investir na arquitetura de um sistema é sempre um bom negócio, a arquitetura não será a solução para todos os problemas e nem será feita de uma solução única, soluções homogêneas são cada vez mais difíceis. Principalmente falando de grandes empresas com a necessidade de ter cada vez mais flexibilidade e reaproveitamento, este é um cenário para a utilização de SOA, logo prepare-se para ter que lidar com sistemas legados, diversos tipos de tecnologias e vendors, e tudo isso só aumenta mais e mais a complexidade.



A Arquitetura de um sistema já pode ter a sua parcela de complexidade mas quando falamos no envolvimento de vários sistemas a complexidade aumenta e muito, sendo SOA ou não você irá precisar investir na arquitetura corporativa.

Enterprise Architecture

Também conhecida como Arquitetura Corporativa, de facto esta a um nível superior da arquitetura de sistemas. Quando você mais de um sistemas em uma empresa e o funcionamento do seu negócio precisa usar esses sistemas em conjunto você precisará de um outro nível de arquitetura, que seria a Arquitetura Corporativa ou Arquitetura das Arquiteturas.

A Arquitetura Corporativa é considerada também como uma forma de representação e padronização dos sistemas que servem ao negócio da empresa em questão. Falando de SOA, que são princípios para a construção de uma arquitetura voltada a serviços que por natureza vai ter que ser aplicada a mais de um sistema, está mais para EA do que para arquitetura de um sistema.

SOA é EA ?

Existem vários discursos e pontos divergentes nessa questão. Mas SOA são princípios, não existe nada mais especifico que ficam mais ao nível do "O Que fazer" do que especificamente "Como Fazer". Alguns acham que isso é apénas uma questão de maturidade e que logo SOA iria evoluir ao ponto de chegar a se tornar algo mais completo perto até de um certo nível de governança.

Se isso vai acontecer eu já não sei. Mas o que afirmo é que existe muita pressão dos grandes vendors em cima disso, com certeza SOA está no Hype, apesar do ciclo ter caido muito. Os grandes players estão vendendo SOA como se fosse uma tecnologia ou um ferramental, por isso que a adoção de SOA vem caido e o pessoal de TI não está conseguindo provar o valor de SOA para o negocio.

SOA deve ser implementado com bons conhecimentos de engenharia e desenvolvimento, um excelente expertise de processo e de Design, o ferramental e a tecnologia são menos importantes, mas ao mesmo tempo que as empresas ficarem focando mais em tecnologia e ferramentas do que no expertise na construção de sistemas distribuídos nada vai evoluir.

O Troca Troca de Tecnologia

Você que está na TI pode ver um fenômeno que a cada ano que passa fica maior. Cada vez mais é mais difícil construir um sistema do Zero, cada vez mais é comum a construção de um sistema para migrar de tecnologia, algo que foi feito em clipper que será migrado para Java ou .NET.

Independente da linguagem tem sistemas que devem ter sido migrados de tecnologia umas 3 vezes, tudo isso por que? É por que a tecnologia ficou obsoleta, não é só por isso. Eu não tenho dúvidas que Java é melhor que clipper, mas qual é o problema?

O problema é que são estamos trocando de tecnologia e mudando o problema de lugar, ainda cometemos erros básicos de acoplamento e coesão, erro básicos de design, erros de análise de requisitos e de gestão, logo ao trocar de tecnologia não estamos resolvendo esses problemas.

Quando falo de fazer Arquitetura de Sistemas e Arquitetura Corporativa, não falo de tecnologia, falo de padrões, falo de boas práticas, falo de design, falo de baixo acoplamento e alta coesão, isso pode ser feito com qualquer linguagem de programação.

Soluções de Arquiteturas Corporativas

Existem algumas soluções de arquitetura corporativa(EA), uma delas é o framework do Zachman que prove um meio formal para definir a sua arquitetura corporativa. O Framework é muito completo e cobre quase tudo o problema é o alto grau de formalismo e o preço da solução.

Uma solução mais barata é o TOGAF. É um padrão da Open Group que foi desenvolvido no meio dos anos 90. Essa solução ajuda a você lidar com sistemas complexos que por natureza temo seu nível de independência e em certo ponto acabam se sobrepondo.

Toda solução de arquitetura corporativa tem indiferentemente de sua abordagem o principio de aproximar a TI do negócio através do planejamento estratégico. A Arquitetura corporativa tem que ser dinâmica e flexível. Muitas vezes a arquitetura corporativa se completa quando adicionamos a governança de TI. Mais ai já é assunto para outro post. Em outros posts pretendo falar mais sobre o TOGAF.

Abraços e até a próxima.

Popular posts from this blog

C Unit Testing with Check

Having fun with Zig Language

HMAC in Java