Projeto EAGLE

Apresentação

Quando foi que perdemos o com.passo?

Aonde estão as chaves?

De minha primeira Grande Visão

A Informação em Perspectiva

O Projeto EAGLE e os seus Dados

Índice

Quando foi que perdemos o com.passo?

“Nenhum vento é favorável ao marinheiro que não sabe onde vai.”
Sêneca

Houve um tempo – nos primórdios da informática, quando só se falava de ambientes “client-server” – em que era prática comum posicionar a implementação das regras de negócio de nossas corporações (a “lógica da solução”, a “inteligência do sistema”) tanto em camadas de apresentação – ou interfaces do usuário (UI) – como em banco de dados. A UI se encarregava de uma validação inicial [do estado] dos dados, após a sua interação com o usuário (em geral imediatamente antes de submetê-los ao servidor); enquanto os bancos de dados, com seus triggers, functions e stored procedures, além de assegurar a correção (tipo, comprimento etc) e consistência (registros órfãos etc) dos dados, também eram responsáveis por assegurar as “regras do sistema”. No final do dia, nossos bancos de dados tratavam de garantir o cumprimento tanto de suas próprias regras internas quanto as regras de negócio de aplicações e/ou processos de negócios a que serviam de suporte.

Percebeu-se então que o fato da lógica do negócio “vazar” para o database dificultava a manutenção e a transformação (corretiva, evolutiva ou regulatória) de nossos negócios propriamente ditos. Além de dificultar a identificação da localização ou origem de um determinado comportamento do sistema, uma única alteração – por simples que fosse – poderia de fato impactar diversos sistemas e/ou processos, “indadvertidamente”. Não havia como prever ou controlar, com acuidade e segurança, o impacto que uma determinada alteração em um de nossos processos de negócios poderia causar aos demais. Ou seja, os databases passaram a representar – a um só tempo – tanto os ativos corporativos mais valiosos como os mais custosos, e de maior risco.

De início, o surgimento da arquitetura de múltiplas camadas não ajudou muito. As validações que eram executadas na UI ali permaneceram, a fim evitar tráfego desnecessário de rede [o que, a propósito, faz sentido, e ainda hoje é considerado boa prática]. A BLL (Business Logic Layer), no entanto, geralmente servia apenas como uma ponte para a camada DAL (Data Access Layer), que via de regra verificava somente a correção dos dados [cf. definido acima]; mais uma vez, para minimizar o tráfego de rede. O que se via – e infelizmente ainda é muito comum atualmente – é que a lógica do negócio continuava “distribuída” pelas camadas da solução; cuja arquitetura, na prática, se ajustava menos à “programação orientada a objetos – OOP”, e mais a um modelo procedural ou estrutural de programação [agora considerado obsoleto, “arcaico”]; com a lógica do negócio, e suas respectivas regras, “fluindo” (ou vazando) da UI para a BLL, para a DAL, para o database – ainda que o discurso oficial o negasse ou, pior, não o percebesse.

Hoje em dia, talvez em função do ritmo alucinado de nossas atividades [não temos tempo de parar nem para pensar, tudo é “para ontem”], ou por não ousarmos sequer questionar o status quo de nossos ambientes de TI; e a despeito de muitos e pomposos “ismos” [todos muito bem aplicados pelos nossos departamentos de marketing e vendas] como design patterns, melhores práticas, standards etc; parece que ainda não dominamos completamente a “arte” da separação de responsabilidades (separation of concerns – SoC), embora tenhamos avançado, neste sentido.

E isso é extremamente preocupante, principalmente com a crescente popularização de noções e conceitos de solução distribuida, como Cloud Computing, SaaS – Software as a Service etc. Uma vez que qualquer “arquitetura orientada a serviços – SOA [às quais tais noções estão estruturalmente associadas] deve ser, por definição, uma extensão, evolução e aprimoramento da orientação a objetos; é natural e lógico que os equívocos cometidos em OOP contaminem quaisquer nossos esforços investidos em SOA e/ou em Cloud Computing; e, consequentemente, que os nossos erros comecem a ultrapassar as fronteiras de nossas organizações [a “vazar”], o que não é nada bom, estrategicamente ou politicamente falando.

Seja como for, de uma forma ou de outra: ainda que tenhamos conseguido importantes progressos no sentido tanto de uma OOP mais “madura” [DDD, AOP, IoC/DI etc] como, mais recentemente, de uma SOA mais aparentemente mais “padronizada”; ainda é preciso nos certificar – sem sombra de dúvidas – que de fato conseguimos:

  • Identificar e conter [todos] os “vazamentos” pré-existentes;
  • Implementar arquiteturas de software empresariais mais integradas, otimizadas e enxutas (lean); e
  • Construir e disponibilizar soluções de fato mais robustas e confiáveis.

Para tanto, é vital que – de tempos e tempos – revisemos todos os nossos conceitos, mentalidade, conhecimento, posicionamento, postura, disposição, comprometimento etc etc; a fim de nos manter atualizados com “as exigências do momento”. Ainda que isso implique em uma parada estratégica. Ainda que demande alguns passos para trás, para que possamos divisar com mais clareza os caminhos que havemos percorrido, os erros e equívocos que temos cometido, as armadilhas [por nós mesmos preparadas] das quais não temos conseguido evitar.

Na “época” da orientação a objetos (OOP), dizia-se que “tudo é objeto” [e é mesmo]. Com o surgimento da orientação a serviços (SOA), o mote passou a ser “tudo é serviço” [o que também está certo, de uma outra perspectiva]. O que propomos aqui está pelo menos dois passos à frente. Primeiro porque propomos uma abordagem orientada a processos de negócio (“tudo é processo”). E então porque advogamos o gerenciamento de nossos processos de negócio – bem como de seus respectivos recursos de software (produtos, serviços etc) – através de uma metodologia fundamentada em processos de gestão de ativos corporativos (governança de processos de definição, desenvolvimento e manutenção de processos, produtos e serviços).

Não faz sentido?

↑ Topo ↑
 
Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: