Arquitetura corporativa e TOGAF: o ADM, os domínios e a governança

Arquitetura corporativa é a prática de descrever as capacidades de negócio, as informações, as aplicações e a tecnologia de uma organização como um único panorama conectado, para que as decisões de investimento sejam tomadas com conhecimento de suas consequências. Não é uma versão ampliada da arquitetura de software. Um arquiteto de soluções responde "como devemos construir este sistema?"; um arquiteto corporativo responde "este sistema deveria existir, o que ele duplicaria, o que substituiria e como nos aproxima de onde o negócio precisa estar daqui a três anos?".

A prática se paga em organizações grandes o suficiente para que ninguém consiga manter o cenário inteiro na cabeça — onde os mesmos dados de cliente vivem em nove sistemas, onde duas divisões estão contratando separadamente a mesma capacidade e onde a decisão de desativar uma plataforma tem consequências que ninguém consegue enumerar por completo. Ela fracassa, e sai caro, quando vira um exercício de documentação desconectado das decisões que estão sendo tomadas. O TOGAF é o framework mais adotado para esse trabalho e, como qualquer framework, é uma fonte de estrutura da qual se aproveita o que serve, não um processo a ser seguido ao pé da letra.

Para que serve a arquitetura corporativa

Tirando o vocabulário, os entregáveis servem a um punhado de decisões recorrentes.

• Racionalização do portfólio. Quais das nossas 400 aplicações fazem a mesma coisa, quais estão sem suporte, quais custam mais do que retornam? Responder a isso exige um portfólio de aplicações com responsáveis, status de ciclo de vida, custo e as capacidades que cada uma suporta.
• Priorização de investimentos. Dada uma estratégia — entrar em um novo mercado, reduzir o custo de atendimento, cumprir uma nova regulação —, quais capacidades precisam melhorar e quais sistemas isso implica mudar?
• Análise de impacto. Se desativarmos esta plataforma, o que quebra? Quais interfaces, quais processos, quais relatórios?
• Padrões e reutilização. Quais tecnologias são aprovadas, quais são toleradas, quais estão em processo de saída, para que os times escolham de forma deliberada e não por preferência.
• Coerência em meio à mudança. Vinte programas rodando ao mesmo tempo, cada um sensato isoladamente, produzindo juntos três novos padrões de integração e um quarto cadastro mestre de clientes.

Repare que cada uma é uma pergunta que alguém com orçamento está de fato fazendo. Artefatos de arquitetura que não respondem a nenhuma pergunta desse tipo são custo sem benefício, e a forma mais rápida de avaliar uma prática de arquitetura corporativa é perguntar quais decisões ela mudou no último ano.

Os quatro domínios de arquitetura

O TOGAF organiza a descrição em quatro domínios, muitas vezes abreviados como BDAT (Business, Data, Application, Technology). Eles são visões de uma única arquitetura, não arquiteturas separadas, e o valor está na rastreabilidade entre elas.

É a rastreabilidade que torna o modelo útil. Quando uma capacidade está falhando, você vê quais aplicações a suportam; quando uma aplicação é desativada, você vê quais capacidades e processos são afetados e quais entidades de dados precisam de um novo lar. Um modelo com quatro domínios lindamente desenhados e nenhuma relação entre eles não consegue responder a nenhuma das duas perguntas.

O ArchiMate é a linguagem de modelagem que acompanha o TOGAF, organizada em camadas que correspondem aos domínios, e vale a pena usá-la sempre que você modelar, porque ela dá às relações significados definidos — realização, serviço, atribuição — em vez de setas cujo sentido depende de quem as desenhou.

O ciclo ADM

O Architecture Development Method é o núcleo do TOGAF: um ciclo iterativo para produzir e governar a arquitetura, com o gerenciamento de requisitos no centro alimentando todas as fases.

A fase preliminar estabelece a própria capacidade de arquitetura — quais partes da organização estão no escopo, quais frameworks e ferramentas são usados, os princípios que vão orientar as decisões e como a governança vai funcionar. Os princípios de arquitetura são o resultado mais duradouro desta fase, e os bons têm força: um princípio que diz "o dado é capturado uma única vez, na origem" resolve discussões por anos, enquanto "valorizamos a qualidade" não resolve nada.

Fase A — Visão da arquitetura delimita um ciclo. Ela identifica os stakeholders e suas preocupações, esboça o alvo em alto nível, avalia o valor de negócio e o risco e produz o Statement of Architecture Work que autoriza o esforço. O resultado crítico é o acordo sobre o escopo, porque escopo sem limites é o que transforma um trabalho de arquitetura corporativa em um estudo de dezoito meses.

Fase B — Arquitetura de negócio descreve o estado atual e o alvo para capacidades, cadeias de valor e processos, e faz uma análise de gaps entre eles. Fazer isso direito é o que impede a arquitetura de virar um plano de tecnologia com rótulo de negócio.

Fase C — Arquiteturas de sistemas de informação trata dados e aplicações em conjunto, novamente com estado atual, alvo e gaps. As constatações recorrentes são a titularidade de dados mestres duplicada, aplicações suportando capacidades para as quais nunca foram projetadas, um catálogo de interfaces que nenhuma plataforma de API management expõe ainda e integração ponto a ponto — o problema que SOA e o ESB se propuseram a resolver.

Fase D — Arquitetura de tecnologia define as plataformas e a infraestrutura que materializam a arquitetura de aplicações, e os padrões que restringem as escolhas futuras.

Fase E — Oportunidades e soluções transforma os gaps de B, C e D em pacotes de trabalho, agrupa-os em projetos candidatos e identifica arquiteturas de transição — os estados intermediários pelos quais a empresa passa, cada um dos quais precisa ser um lugar viável para permanecer por um tempo, já que nenhuma organização vai do estado atual ao alvo em um único passo.

Fase F — Planejamento da migração sequencia e orça esses pacotes de trabalho em um plano de implementação e migração, negociado com as áreas de portfólio e finanças em vez de escrito isoladamente.

Fase G — Governança da implementação conecta a arquitetura à entrega. Os projetos são revisados em relação ao alvo, os desvios são registrados como exceções explícitas com responsável e data de validade, e os arquitetos continuam envolvidos em vez de entregar um documento e sair de cena.

Fase H — Gerenciamento de mudanças da arquitetura decide o que fazer quando a realidade muda: uma mudança pequena é absorvida, uma significativa dispara um novo ciclo. É também aqui que o repositório é mantido atualizado.

O gerenciamento de requisitos fica no centro, recebendo e distribuindo requisitos ao longo de todo o ciclo, porque os requisitos não chegam uma única vez no início.

Building blocks e o repositório

Os Architecture Building Blocks (ABBs) descrevem a capacidade necessária em termos independentes de implementação: "gestão de identidades e acessos que fornece autenticação, autorização e federação para usuários internos e parceiros". Os Solution Building Blocks (SBBs) são os itens concretos que os materializam: um produto específico, um serviço específico, um componente interno específico. Manter os dois separados é o que permite substituir um produto sem redesenhar a arquitetura, e é o mesmo instinto de programar para uma interface.

O Architecture Content Framework define quais são os resultados e como eles se relacionam. Vale a pena conhecer seus três níveis, porque eles esclarecem muita conversa vaga sobre "entregáveis":

• Entregáveis (deliverables) são resultados contratuais, formalmente revisados e aprovados — o Architecture Definition Document, o plano de migração.
• Artefatos são os produtos de trabalho individuais dentro deles, de três tipos: catálogos (listas de itens), matrizes (relações entre duas listas) e diagramas (visões gráficas).
• Building blocks são os componentes reutilizáveis que esses artefatos descrevem.

O Architecture Repository é onde tudo isso fica, e as partes que importam na prática são o Architecture Landscape (as descrições do estado atual e do alvo em vários níveis de detalhe), a Standards Information Base (o que é aprovado, tolerado ou está em processo de saída), a Reference Library (padrões e arquiteturas de referência que vale a pena reutilizar) e o Governance Log (decisões, exceções e suas justificativas). O Governance Log é o mais subestimado: um registro pesquisável do porquê de uma decisão poupa a organização de rediscuti-la a cada dezoito meses.

O Enterprise Continuum é o esquema de classificação que permite ir de modelos de referência genéricos do setor a soluções específicas da organização. Ele é mais útil conceitualmente do que usado na prática.

Mapeamento de capacidades

De todos os artefatos de arquitetura corporativa, o mapa de capacidades de negócio é o que tem mais chance de ser realmente usado, porque dá às pessoas de negócio e de tecnologia um vocabulário compartilhado e estável.

Uma capacidade é o que a organização é capaz de fazer, expresso como um sintagma nominal e independente de como ou por quem é feito: "onboarding de clientes", "decisão de crédito", "liquidação de sinistros", "precificação". As capacidades mudam muito mais devagar do que processos, estruturas organizacionais ou sistemas, e é exatamente isso que as torna uma espinha dorsal útil. Normalmente elas são decompostas em dois ou três níveis — além disso, o mapa vira um modelo de processos e perde a estabilidade.

Level 1   Customer Management
  L2      Customer Onboarding            importance: HIGH   health: POOR    apps: 4  ← invest
  L2      Customer Data Management       importance: HIGH   health: POOR    apps: 9  ← invest
  L2      Complaint Handling             importance: MED    health: GOOD    apps: 1
Level 1   Product & Pricing
  L2      Product Definition             importance: MED    health: FAIR    apps: 2
  L2      Pricing & Discounting          importance: HIGH   health: FAIR    apps: 3
Level 1   Order to Cash
  L2      Order Capture                  importance: HIGH   health: GOOD    apps: 1
  L2      Invoicing & Collections        importance: MED    health: POOR    apps: 5  ← rationalise

O mapa conquista seu lugar com o heat mapping: sobrepor avaliações a ele. Quais capacidades são estrategicamente importantes? Quais têm desempenho ruim hoje? Quais são suportadas por sistemas em fim de vida, por cinco aplicações sobrepostas ou por nenhuma? Onde as camadas "estrategicamente crítica" e "mal suportada" se cruzam, você tem um caso de investimento que um executivo sem perfil técnico consegue ler em um único slide — e isso é um uso bem melhor do esforço de arquitetura do que mais um diagrama em camadas.

Governança que ajuda

A governança de arquitetura é o mecanismo que torna o alvo real, e é onde as práticas de arquitetura corporativa mais frequentemente viram aquilo que todo mundo contorna.

O que funciona:

• Princípios e padrões publicados onde os desenvolvedores já estão — no repositório, nos templates de projeto, nas verificações do pipeline — e não em um portal que ninguém abre.
• Um processo de desvios com registro de decisões. Os times vão precisar de exceções. Registre a exceção, a justificativa, o responsável e a data de validade. Uma prática de arquitetura que diz não por padrão é contornada; uma que diz "sim, registrado, revisamos em doze meses" continua informada.
• Conformidade automatizada onde for possível. Regras de dependência, imagens base aprovadas, metadados obrigatórios, linting de APIs segundo as diretrizes da organização. Uma verificação no pipeline escala para mil times; um comitê de revisão, não.
• Revisões leves e no momento certo, nos pontos que importam — antes de adotar uma tecnologia, antes de estabelecer um padrão de integração, antes de uma decisão de construir ou comprar — em vez de um gate a cada release.

O que não funciona: um comitê que revisa cada projeto depois que o design está pronto, padrões sem caminho de conformidade, arquiteturas alvo sem uma rota financiada a partir do estado atual e um esforço de modelagem que ultrapassa a disposição da organização de mantê-lo. Uma governança que acrescenta uma semana de espera a cada mudança é um dos motivos pelos quais as práticas de DevOps se espalharam como reação.

Críticas, apresentadas com justiça

O framework atrai críticas fortes, e boa parte delas é merecida.

Ele é pesado. O padrão completo descreve muito mais artefatos do que qualquer organização deveria produzir. Lido como obrigação e não como cardápio, ele gera documentos que ninguém lê.

Ele pode se desconectar da entrega. Uma arquitetura alvo com horizonte de três anos, produzida por um time central, tende a ser atropelada pelos acontecimentos e silenciosamente ignorada enquanto os times de entrega tomam as decisões reais no sprint planning.

A certificação substitui a competência. O exame avalia vocabulário, que é fácil de testar e não é o que o trabalho exige.

Ele pressupõe um grau de controle central que já não corresponde à forma como o software é construído. Serviços de cloud são contratados com um cartão de crédito, times de produto escolhem as próprias stacks, e uma prática de arquitetura cujo único instrumento é a aprovação tem pouquíssima influência.

Bem usado, ele ainda oferece valor real: um vocabulário compartilhado que impede as pessoas de discutirem sem se entender, uma lista de preocupações que evita omissões óbvias, uma estrutura repetível para a análise de gaps e um modelo de governança que pode ser intensificado ou afrouxado. A abordagem pragmática é aproveitar a estrutura do ADM e a classificação do content framework, produzir o pequeno número de artefatos que respondem a perguntas vivas, automatizar a conformidade, colocar os arquitetos junto dos times de entrega em vez de acima deles e fazer do repositório a memória das decisões, e não um museu de diagramas.

Principais pontos

• A arquitetura corporativa existe para embasar decisões sobre portfólio, investimento, impacto e padrões; artefatos que não respondem a nenhuma pergunta viva são puro custo.
• Os quatro domínios — negócio, dados, aplicações e tecnologia — são visões de um único modelo, e o valor está na rastreabilidade entre eles.
• O ADM é um ciclo iterativo que vai da visão às arquiteturas de domínio e daí a oportunidades, migração, governança da implementação e gerenciamento de mudanças, com o gerenciamento de requisitos no centro.
• Separe os architecture building blocks dos solution building blocks que os materializam, e mantenha catálogos, matrizes e diagramas em um repositório com um registro de governança de decisões e exceções.
• Um mapa de capacidades de negócio com camadas de calor é o artefato com mais chance de mudar uma decisão executiva, e ele se mantém estável enquanto processos e sistemas mudam o tempo todo.
• Governe com padrões publicados, verificações de conformidade automatizadas e um processo de desvios registrado em vez de comitês que barram cada release, e trate o TOGAF como um cardápio — itere no escopo de que a decisão precisa e mantenha os arquitetos perto da entrega.