A abordagem de modelagem de processos tem sido muito discutida e quase sempre recomendada para iniciativas SOA. A massiva propaganda e momentum BPM parece nos indicar que é sempre interessante modelar processos para resolver um problema. A realidade, entretanto, é diferente da teoria, baseado em um cenário real que discuti hoje no começo da noite em uma empresa que está em uma franca implementação SOA.

Ouvindo John Zachman

A figura abaixo mostra o Zachman Framework. A coluna “How” é o domínio do BPM. A coluna “What” é o domínio das capacidades. A coluna “When” é domínio dos eventos complexos (CEP).

Processos expressam como fazer alguma coisa. Antes de pensar no como, entretanto, devemos pensar no que devemos fazer. Estes quês denotam as capacidades a serem desenvolvidas dentro de uma organização e, surpreendentemente, podem levar a uma abordagem completamente diferente que não implica no como, mas no quando.

Detecção de Fraudes e Processos de Manufatura

Considere uma capacidade de uma seguradora de detectar fraudes. A abordagem tradicional BPM iria buscar modelar os processos que podem detectar uma fraude. Entretanto, modelar a classe de processos que detectam fraudes pode levar uma conjunto extremamente complexo de variações que são muito difíceis de manter na prática. É um caso completamente antagônico ao processo de manufatura fabril, que pode ser classicamente modelado através de um processo discreto com variações conhecidas a priori.

A abordagem de captura de fraudes pode ser endereçada por uma outra dimensão na figura do Zachman Framework, que é a dimensão do quando, ou da modelagem de eventos complexos. A modelagem de eventos complexos nos dá instrumentos matemáticos muito interessantes, que resumo na figura abaixo que retrata as capacidades de um produto open-source popular neste meio, o Drools Fusion.

A figura abaixo mostra padrões intervalares e correlações temporais espaciais que podem ser capturadas através de máquinas de inferência de eventos complexos.

Por exemplo, com eventos complexos, podemos habilitar uma máquina de inferência para monitorar em um cenário de uma seguradora que dispare um alerta na ocorrência de pelo menos três das condições abaixo quando um novo “fato”de Sinisto ocorrer.
- Atraso na denúncia de mais de 72 horas;
- Número excessivo de testemunhas (maior que 3)
- Ausência de testemunhas.
- Sinistro que melhora situação difícil (situação cadastral ruim no SERASA).
- Desproporção entre causas e efeito do sinistro.
- Sinistro acontecido em ambiente familiar ou de amigos.
- Dificuldades ou demora em fornecer os documentos pedidos.
- Excesso de sinistros ou sinistros não compatíveis no período (saúde).

Naturalmente, não advogo que CEP deve ser usado para qualquer cenário. O CEP é indicado para alguns cenários bem específicos e deve ser realizado com bastante cautela.

A regra é que alguns problemas requerem uma abordagem baseada em processos e outros problemas requerem uma abordagem centrada em eventos. Outros problemas requerem as duas abordagens. Entretanto, todos os problemas podem ser modelados dentro do contexto da Arquitetura Corporativa, no contexto do Zachman Framework.

Tales from the Crypt é uma série de TV com contos macabros e de horror, que fez algum sucesso no Brasil nos anos 90. Indo da ficção para o mundo real de TI, vejo contos da cripta de TI que são muito mais assustadores do que aqueles que assistia na minha velha e ultrapassada TV do milênio passado. Compartilho aqui uma (triste) história da cripta de TI.

História de Hoje - O Analista Frankenstein
O analista Frankenstein é um ser puramente tecnológico, que acredita que ferramentas e tecnologias precedem o entendimento de capacidades de negócio, processos, regras e dos conceitos de negócio. Formado a partir de códigos Java, .NET, bancos de dados e outros fragmentos tecnológicos, este ser horrendo, que habita as TIs de todo o Brasil, usa a sua tecnologia para resolver qualquer problema.

Quando ainda criança (na faculdade), o analista Frankenstein foi educado em C++, Java, .NET e engenharia de software por seres de outras dimensões que nunca entregaram uma linha de código em um ambiente de produção no planeta Terra.

No seu primeiro estágio, o analista Frankenstein foi educado em técnicas de escrita de código-spagetti por monstros experientes em repetir os mesmos erros por mais de 20 anos e que se orgulham de não ler um único livro de TI desde que saíram das suas faculdades.

No seu primeiro emprego, o analista Frankenstein aprofundou o seu conhecimento do lado negro da força com a escrita de código lasanha, criando aplicações com 8 camadas lógicas para implementar uma simples aplicação Web corporativa.

Conseguiu a sua primeira promoção com a disseminação do horrendo padrão Modelo de Domínio Anêmico, criando “código OO” com “classes” de dados e “classes” de negócio.

Depois de cinco anos, o analista Frankenstein já se intitulava monstro sênior, e assim era reconhecido por seus pares horrendos. Ele aumentou o seu arsenal tecnológico indicando servidores de aplicação e ESBs para toda e qualquer demanda, mesmo que o problema fosse apenas acessar um banco de dados. Ele somou ao seu curriculum certificações de todos os grandes fornecedores de mercado e usa a sua imensa lista de certificações no seu horrendo email, que tem uma assinatura maior que a mensagem do corpo.

Este monstro horrendo, após dez anos, já havia passado por várias empresas e causado prejuízos gigantescos e contribuído pela má reputação que a TI goza junto às áreas de negócio.

Astuto, este monstro abandona a empresa quando a tecnologia inadequada começa a mostrar os seus resultados ruins e assim vai assombrando outras organizações. Infelizmente ele não é visto desde o ano passado e o seu paradeiro é desconhecido. Felizmente, ele pode ser desmascarado com seis perguntas simples, que compartilho abaixo:

• Você elicitou, desenvolveu e priorizou os condutores de negócio mais importantes para o aumento das capacidades de negócio da sua organização?
• Você desenvolveu uma arquitetura agnóstica de tecnologia para capturar as abstrações chave e mecanismos derivados dos condutores de negócio?
• Você buscou e avaliou as tecnologias que respondem de forma sincera aos requisitos da arquitetura candidata, incluindo as tecnologias já experimentadas e maduras da sua organização?
• Você experimentou e provou a tecnologia com uma ou mais provas de conceito que exercitaram os cenários de negócio mais signicativos para os seus usuários chave?
• Você estaria disposto a aprender e usar outras linguagens de programação, caso estas linguagens se mostrarem mais adequadas à nossa empresa?
• Você fala mal das tecnologias e linguagens de programação que você não usa como se fossem os times de futebol que jogam contra o seu time do coração?

Pensamento do dia: He cried in a whisper at some image, at some vision—he cried out twice, a cry that was no more than a breath—”The horror! The horror!” – Joseph Conrad, Heart of Darkness

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.

Era uma vez, na época em que os animais ainda falavam, três porquinhos que viviam felizes e despreocupados como analistas de sistemas nas suas empresas. Seus nomes eram Fanático, Lunático e Pragmático. Certo dia, os porquinhos foram promovidos a arquitetos de software pelo rei da floresta, o rei Leão.

O rei Leão disse:
- Queridos colaboradores, vocês já estão bem crescidos. Já é hora de terem mais responsabilidades e para isso é bom morarem sozinhos e construírem suas próprias casas.

Os três porquinhos arquitetos, então, partiram pelas florestas corporativas em busca de um bom lugar para construírem as suas casas. Porém, no caminho começaram a discordar sobre como construir as suas casas.
Cada porquinho queria usar um metodologia diferente.

O primeiro porquinho, o porquinho Fanático, um dos preguiçosos, foi logo dizendo:
- Não quero ter muito trabalho! Ouvi falar de um método ágil chamado Screw It! que diz que casas de palhas são mais rápidas. Não precisamos de plantas, nem fundações e por isso são muito rápidas. Basta comprar um monte de palha e empilhá-la.

O porquinho pragmático advertiu:
- Uma casa de palha não é nada segura.

O outro porquinho, o irmão do meio que era chamado de porquinho Lunático também deu seu palpite:
- Prefiro terceirizar a minha casa, que será de madeira. Recebi uma planta arquitetural em um Documento de Arquitetura de Software de 200 páginas da empresa ACME, a preços módicos e condições de financiamento incomparáveis.

Comprar uma casa baseada apenas na planta arquitetural não é nada seguro - comentou o mais velho. Como você vai garantir que os materiais estarão corretos e que a fundação suportará o seu peso? Onde estão as provas de conceito e a arquitetura executável? Esta planta foi assinada por um engenheiro?

Os porquinhos ironizam o porquinho Pragmático, o mais velho, que foi construir a sua casa de tijolos com métodos arquitetônicos provados. Ele montou uma planta arquitetural, organizou os materiais corretos, fez provas de conceito e acompanhou os resultados do trabalho em conformidade com a planta.

Os outros porquinhos também começaram a criar as suas casas. Na primeira semana, o porquinho fanático terminou a sua casa. Já estava descansando quando o irmão do meio, que havia construído a casa de madeira chegou chamando-o para ir ver a sua casa terceirizada, cuja fachada era igualzinha ao prometido na planta arquitetural.

Os porquinhos preguiçosos, o Lunático e o Fanático, foram visitar seu irmão mais velho, o porquinho Pragmático.

O porquinho Fanático disse:
- Nossa! Você ainda não acabou! Não está nem na metade da Fase de Elaboração! Nós agora vamos almoçar com o Rei Leão, que ficou feliz ao receber mais duas casas da sua floresta. Ele está pensando em nos promover a gerentes!! hahaha… Se você fosse agilista como eu, teria terminado a sua casa.

O porquinho mais velho porém não ligou para os comentários e continuou a trabalhar. Ele preparava o cimento e montava as paredes de tijolos. Após quatro semanas de trabalho intenso, a casa de tijolos estava pronta, e era robusta!

Os dias foram passando, até que um lobo, chamado Mudança, percebeu que havia porquinhos morando naquela parte da floresta. O Lobo Mudança foi então bater na porta do porquinho mais novo, o da casa de palha.
Ele soprou, soprou e soprou e as mudanças vieram. A casa do porquinho Fanático sucumbiu e ele correu para a casa do porquinho Lunático.

O Lobo Mudança foi bater agora na casa do porquinho do meio, o Lunático. Ele soprou, soprou e soprou e mais mudanças vieram. A casa terceirizada não tinha uma boa estrutura e a madeira estava infestada de cupins. A casa sucumbiu e então os dois porquinhos correram para a casa do irmão mais velho, o porquinho Pragmático.

O Lobo Mudança foi agora bater finalmente na casa do porquinho Pragmático. Ele soprou, soprou e soprou. Entretanto, a casa era robusta e o lobo Mudança não conseguiu desmontar a casa com a boa arquitetura.

O Rei Leão soube do ocorrido e foi correndo para a casa do porquinho Pragmático. Ele despediu e comeu os porquinhos preguiçosos em um almoço corporativo de lombo com pururuca. O Lobo Mau foi também convidado e se deleitou com a iguaria corporativa fornecida pelo rei Leão.

No fim, o Rei Leão, o Lobo Mudança e o Porquinho Pragmático viveram felizes para sempre!

Qualquer semelhança com fatos e evento reais não é mera coincidência.

O conceito de Arquitetura Corporativa existe já há quase 30 anos na indústria de TI e administração, mas apenas nos últimos anos tem obtido alguma visibilidade no mercado Brasileiro. Mas o que é mesmo uma Arquitetura Corporativa?

Adaptei um meta-modelo de um corpo de conhecimento chave para arquitetura corporativa, o TOGAF, que mostra a visão holística da arquitetura dentro de uma empresa.

Uma arquitetura corporativa tem alguns pontos chave, que destaco aqui:

• ênfase no pensamento estratégico de forma que o time de arquitetura gere uma visão arquitetural para todo projeto, de forma que que todo o esforço do time de arquitetura seja convergente às expectativas de negócio dos gestores;
• a clara necessidade de organizar os requisitos arquiteturais do projeto antes que a solução seja endereçada;
• a decomposição da arquitetura em quatro disciplinas: arquitetura de negócio, arquitetura de aplicações/software, arquitetura de dados e arquitetura tecnológica;
• a governança de todo o esforço arquitetural nos projetos, iniciativas e oportunidades, i.e, um controle dos artefatos arquiteturais gerados, a mensuração do valor gerado por estas iniciativas e o controle dos ciclos de melhoria contínua.

De forma pragmática, a arquitetura corporativa nos ensina que escolher uma tecnologia no primeiro dia do projeto normalmente tende a ser uma má idéia. Isso traz uma profunda implicação para os “arquitetos Java EE” ou os “arquitetos .NET” que usualmente levam a sua tecnologia a tira-colo antes de entender o problema, a estratégia de uma organização e capturar corretamente os requisitos arquiteturais que eles devem endereçar. Em verdade, o próprio termo “arquiteto Java EE” ou “arquiteto .NET” traz uma contradição per se.

O tema arquitetura corporativa é ainda muito vasto e desafiador, mas a internalização dos alguns dos seus princípios fundamentais pode nos ajudar a resolver problemas de TI de forma a gerar maior valor de negócio para as empresas e com soluções mais robustas e assertivas.

Compartilho aqui dois módulos da nossa apresentação realizada ontem no evento Maré de Agilidade. O primeiro módulo fala sobre o papel do arquiteto de software a importância da arquitetura de software. O segundo módulo fala sobre o conceito de arquiteturas ágeis e técnicas de mercado para a criação de arquiteturas evolutivas.

O movimento antropofágico, cunhado por Oswald de Andrade nos anos 20, propunha a “Devoração cultural das técnicas importadas para reelaborá-las com autonomia, convertendo-as em produto de exportação”.

Processos de software, como o AUP, RUP ou o XP são elementos muito complexos, compostos por diversas técnicas, métodos, papéis e pontos de extensão. Não é de se estranhar que a tarefa de implantar processos de software em organizações seja muito complexa e falhe em grandes partes das tentativas. É consenso que um processo deve ser personalizado à sua realidade para que ele funcione. Ao tentarmos personalizar um processo completo, temos muito trabalho e muitos pontos de divergência cultural com a realidade da organização alvo.

Antropofagia de Software

Como engenheiros de software, também devemos praticar a antropofagia dos processos de software e esquartejá-los em “práticas de processo”. Uma prática de processo é uma melhor prática, provada em diversos cenários e projetos. Uma prática de processo tem algumas características importantes, tais como: ser atômica, facilmente implantável e composível com outras práticas.

Exemplos de práticas de processo incluem:

• Projetos iterativos
• Modelagem de casos de uso
• Modelagem arquitetural
• Casos de teste
• Revisão pelos pares
• Planning Poker/Wide Band Delphi)
• Daily Builds (Produtos diários)

As vantagens de adotarmos e implantarmos práticas de processo, ao invés de um processo completo, são várias. Podemos destacar:

• Redução do risco de transformações culturais em times.
• Retorno mais rápido do investimento.
• Adequação a realidade cultural de cada empresa
• Possibilidades de composição com outras práticas para a montagem do um processo personalizado

As escolas mais modernas de processos tem adotado o conceito de práticas de processo em sua essência. Exemplos são o RUP 7.5 e o Essential UP, de Ivar Jacobson. O SCRUM, que tanto sucesso faz atualmente, tem a sua maior força na sua pequena essência, composta de um pequeno conjunto de práticas gerenciais ágeis.

Pensamento do dia: “Menos é mais”, Ludwig Mies van der Rohe

Arquiteturas ágeis partem da premissa que nem todo condutor arquitetural possa ser antecipado e desenvolvido antes que a primeira versão do produto vá para a produção. Normalmente, arquiteturas ágeis procuram implementar os elementos técnicos críticos ao longo das entregas parciais de um produto ou projeto, em conjunto com as funcionalidades de maior valor de negócio para os seus usuários

Esta abordagem é, tecnicamente falando, bem mais arriscada que manter uma fase de elaboração que procure acomodar os riscos técnicos através da realização de todos os condutores arquiteturais importantes. Métodos como o UP usam a abordagem tradicional, enquanto métodos como o XP usam a abordagem ágil.

De volta às arquiteturas ágeis, como lidar com o dilema de intercalar condutores arquiteturais, elementos funcionais e software em produção. A chave para lidar com a antecipação de um investimento arquitetural para uma futura funcionalidade, segundo Nanette Brown, é fazer a você e ao seu time as seguintes perguntas:

• O quão provável que a futura funcionalidade seja realmente necessária no produto? É importante lembrar, conforme pesquisas diversas (ex: Standish Group), que quase metade das funcionalidades solicitadas de um produto são raramente ou nunca usadas.
• Existe um investimento arquitetural que eu possa fazer agora que irá reduzir o custo futuro de implementar esta funcionalidade?
• Qual o custo do investimento arquitetural? (ex: custo da oportunidade, custo de implementação)
• Qual a consequência econômica de no futuro precisar implementar a funcionalidade sem o investimento arquitetural realizado a priori?

A metáfora do cheque especial

O famoso agilista Ward Cunninghan possui uma excelente metáfora, do cheque especial, que compartilho aqui. Ele diz que ao entregarmos um produto com uma arquitetura sub-ótima (ex: não performática ou com uma usabilidade deficitária, caso estes sejam condutores importantes), estamos usando um cheque especial técnico.

Os juros deste cheque especial implicam que futuras melhorias no sistema irão custar mais tempo e esforço para serem atendidas. Por exemplo, é claramente mais simples montar um sistema com um estilo de acessibilidade WCAG AA previamente definido do que refatorar 50 páginas em produção para se adequar a este condutor.

Se as técnicas de refatoração arquitetural não forem usadas para pagar a dívida técnica a tempo, o sistema irá se degradar tecnicamente ao longo do tempo e levar o seu “sistema econômico” à falência.

Como todo empréstimo bancário, devemos avaliar se é prudente “tomar dinheiro emprestado” no banco arquitetural. Se tomarmos dinheiro emprestado, devemos investir tempo e esforço em técnicas de refatoração arquitetural para pagar o débito rapidamente.

Arquiteturas ágeis podem ser excelentes instrumentos de acomodar as pressões de mercado, mas devem ser cuidadosamente elaboradas e pensadas para que o “fluxo de caixa do seu produto” continue saudável e você não tenha graves problemas em produção.

5 Minutos com Ward Cunninghan
Para os mais interessados no assunto, recomendo este pequeno vídeo de 5 minutos do autor.

Neste mês os bancos de dados relacionais completam 40 anos. Após todo este tempo, eles possuem grande popularidade e podem ser posicionados na parte direita da curva abaixo que modela como inovações são difundidas, e que foi popularizada por Everest Rogers em 1962.

Antes que os bancos relacionais se tornassem populares, entretanto, eles passaram por diversos percalços até que fossem reconhecidos e adotados pelo mercado. Uma breve história do tempo reflete isso:

• O artigo “A Relational Model of Data for Large Shared Data Banks,” de Edgar Codd é publicado na ACM em 1970.
• O projeto IBM’s System R e projeto Ingres da Universidade da Califórina traduzem os conceitos dos bancos relacionais em produtos concretos ao longo dos anos 70. O projeto do System R, em particular, padronizou a linguagem conhecida como SQL.
• O artigo seminal “Access Path Selection in a Relational Database Management System,” de Patricia Selinger, pesquisadora do projeto R, permite grandes avanços em termos de escalabilidade através de algoritmos eficientes de uso de memória, disco e CPU.
• No fim dos anos 70 e anos 80, bancos derivados destes projetos, como o IBM DB2 e o banco de dados da Oracle estabelecem as bases técnicas e comerciais para a profusão dos bancos de dados.
• Em 2010, virtualmente toda empresa de médio e grande porte possui bancos de dados relacionais em sua TI.

Novas tecnologias como BPMS, SOA, CEP, BRMS, entre outras, talvez não demorem 40 anos para sempre amplamente utilizadas, mas certamente ainda estão do lado esquerdo da curva de Rogers. Até lá, devemos aprender com os pioneiros de bancos de dados relacionais e ajudar na popularização com casos reais e contribuições para o aumento da sua maturidade em projetos.

Para os mais curiosos sobre os 40 anos dos bancos de dados relacionais, recomendo o excelente artigo publicado mês passado na ACM com a sua história.

Pensamento do dia: “Be patient, for the world is broad and wide.”, William Shakespeare