Enterprise Architecture: O Elo Perdido Entre Negócio e TI
O que é Enterprise Architecture de verdade: a cola entre arquitetura de negócio e de TI, como fugir da torre de marfim e quando EA deixa de ser necessária.
Neste artigo · 8 seções
Você já esteve naquela sala onde o pessoal de negócio está falando sobre market share e o pessoal de TI está preocupado com legacy systems? E vocês estão literalmente falando línguas diferentes? Esse é o problema que vou abordar aqui.
A maioria das organizações tem uma arquitetura de TI razoável. Tem uma arquitetura de negócio que funciona mais ou menos. O que elas não têm é a cola que conecta as duas coisas. E quando você não tem essa conexão, a TI vira um custo. Aí é que entram os problemas.
Gregor Hohpe, no "The Software Architect Elevator", coloca assim: enterprise architecture é precisamente esse elo perdido. Não é IT architecture. Não é business architecture. É a cola que mantém as duas conversando. A questão é, como você constrói essa cola quando tudo ao seu redor quer empurrar você para um lado ou para o outro.
O Problema Real: Mars and Venus
Aqui está a coisa. Você pode ter a mais linda arquitetura de TI, com microsserviços bem desacoplados, pipelines de CI/CD acelerados, tudo automated. Maravilhoso. Mas e se ela resolve o problema errado? E se a estratégia de negócio está caminhando numa direção e a TI vai em outra? Aí você tem um ótimo sistema técnico que ninguém pediu.
Inverso também acontece. O negócio tem uma estratégia impecável, perfeitamente definida. Mas a TI segue um roadmap de dez anos atrás. Talvez por causa de vendors, talvez por causa de legacy, talvez por inércia pura. De qualquer forma, não consegue se mover rápido o bastante para virar a estratégia em realidade.
Hohpe menciona que em grandes organizações é comum ter isso: o pessoal da penthouse (negócio/liderança) e o pessoal do engine room (TI/desenvolvimento) vivem em realidades diferentes. Aquele da penthouse acha que a transformação digital está acontecendo magnificamente. O pessoal do engine room está lá embaixo preso em zombies (legacy) e sabendo que as coisas são muito mais complicadas.
O resultado? A liderança toma decisões com informação distorcida. A TI executa coisas que não fazem sentido para o negócio. Comunicação é péssima. Confiança é pior ainda.
O Que Enterprise Architecture Realmente É
Esqueça a imagem do cara da tower de marfim desenhando diagramas que ninguém pede. Aquele estereótipo existe porque EA foi feito errado tantas vezes que virou piada interna.
Aqui está uma definição que funciona: enterprise architecture é a cola entre a arquitetura de negócio e a arquitetura de TI. Ponto. Não é uma função de TI. Não é uma função de negócio. É o espaço no meio onde as duas conversam, se entendem, e começam a andar na mesma direção.
Isso muda tudo. Se EA é a cola, então os enterprise architects não devem estar enterrados dentro de TI. Devem estar perto da liderança, perto de quem faz as decisões estratégicas, mas com credibilidade técnica suficiente para traduzir isso em termos que os engenheiros entendem.
Eu trabalhou em uma transformação onde a gente descobriu que o negócio queria diversificar seus canais de venda em 18 meses. O time de TI tinha um roadmap que tirava legacy em 5 anos. Quando você coloca esses dois fatos lado a lado num documento, fica claro que tem um problema. Essa é a função de EA, ficar descobrindo essas incongruências e forçando a conversa.
Hohpe observa que a maioria dos digital giants (Google, Amazon, Netflix) não têm departamentos de EA formais. Por quê? Porque a distinção entre negócio e TI não existe. Eles já estão na mesma sala, falando a mesma língua. A necessidade de EA desaparece quando você resolve o problema de alignment. Até lá, precisa de alguém para puxar as coisas junto.
Business Architecture: Sem Ela, EA Vira Só IT
Aqui está um detalhe que muita gente ignora. Se você quer fazer EA direito, precisa que o lado do negócio tenha uma arquitetura também. Uma business architecture que descreve como o negócio está estruturado, qual é o modelo operacional, como as unidades se conectam, qual é a estratégia.
Quando você tem isso, de verdade, você consegue mapear isso para a TI. Você consegue dizer: o negócio segue esse modelo operacional, então precisa de TI configurada desse jeito. Se o negócio é altamente integrado, você precisa de sistemas integrados. Se é um conjunto de unidades independentes, você pode ter arquiteturas muito diferentes por unidade.
Mas na maioria das vezes? A business architecture é... vaga. Ou não existe. O CEO sabe qual é a estratégia. Talvez o CFO saiba. Os arquitetos de TI? Não fazem ideia. Aí eles tentam bolar uma EA baseada em achismo e em conversas de corredor.
Já vi situação onde a empresa falava que era model "diversified" (modelo de negócio descentralizado), e a TI estava tentando construir um sistema monolítico integrado que nunca funcionaria. Ninguém tinha parado para mapear o modelo de operação de verdade. Quando você tira essa ambiguidade, a arquitetura se clarifica.
The Glue is Real Work
Não é romântico. Não é glamorous. Mas conectar esses pontos é trabalho duro. É sentar com C-suite e traduzir strategic intent para decisões técnicas. É sentar com arquitetos e engenheiros e explicar por que aquela escolha de tecnologia que eles queriam não alinha com o roadmap de negócio. É dizer não, às vezes com educação suficiente para que as pessoas entendam o porquê.
Você precisa de credibilidade dos dois lados. Se você aparecer como um IT guy, o negócio não vai levar a sério. Se aparecer como um business guy, a TI não vai confiar que você entende as implications técnicas.
Hohpe menciona o conceito de architects como "super glue". Não é um título bonito, mas é honesto. Você está gluing things together. Architecture, technical details, business needs, people. Tudo junto.
Eu conheci um enterprise architect numa healthcare company que basicamente virou o intérprete entre a área clínica e a área de TI. Clínico queria algo que era clinicamente sensato mas tecnicamente impossível com o budget. Arquiteto sentou com os dois, explicou as constraints, desenhou opções. Ninguém ficou 100% feliz, mas o resultado fez sentido pros dois lados. Isso é EA funcionando.
Quando EA Se Torna Obsoleta
Aqui é o detalhe interessante. A definição de EA como "cola" implica algo muito específico: quando a cola não é mais necessária, EA diminui ou desaparece. Parece contraditório, mas não é.
Conforme o tempo passa e você aumenta o alignment entre negócio e TI, a necessidade de um mediador diminui. As duas áreas começam a falar direto, a entender uma a outra. Em digital companies isso já é a realidade. Google não precisa de um departamento de EA porque o VP de Engineering está conversando direto com o VP de Produto. Eles já estão no mesmo nível e falando a mesma língua.
A maioria das empresas tradicionais, porém, ainda tem vários pisos de separação. Então a cola é necessária. Mas se você fizer seu trabalho certo, vai estar trabalhando para se tornar dispensável. Estranho, mas é assim.
Quando você conecta os elevadores que vão do negócio até TI, quando as conversas começam a fluir mais livremente, quando as decisões começam a fazer sentido pro dois lados, você sabe que funcionou.
O Lado Perigoso: Becoming Useless
Existe um risco real aqui. Se você trabalha em EA e fica muito focado em diagramas bonitos, em governança, em processos, você vira aquela pessoa na tower. Você começa a tomar decisões que ninguém pediu. Você mantém alinhamento em papel, mas na realidade tudo continua desalinhado.
Especialmente em grandes organizações com feedback loops longos, é fácil ficar entrincheirado numa EA que não produz valor. Você faz análise, publica um documento, ninguém implementa. Você documenta a arquitetura do negócio, fica obsoleto em três meses.
Por isso Hohpe é bem claro: EA precisa ter um caminho claro para valor. Qualquer trabalho que você faz tem que se pagar em algo tangível. Se você mapeou a arquitetura de negócio, isso precisa resultar em decisões melhores. Se você fez uma technology roadmap, isso precisa guiar a estratégia de desenvolvimento de verdade. Se não, você é só um documentador caro.
O teste é simples: quando alguém da liderança precisa tomar uma decisão importante de TI, eles buscam a input do seu time de EA? Se a resposta é não, você tem um problema.
Conclusion: The Connection That Matters
Enterprise Architecture, feita certo, resolve um problema real. Não é um exercício de documentação. Não é governance pura. É a tradução entre dois mundos que precisam andar juntos.
A razão pela qual muita organização sofre nessa transformação digital é porque tentam mudar TI sem mudar o modelo de negócio, ou tentam mudar o modelo de negócio sem entender as implications de TI. Sem alguém traduzindo e conectando as peças, vai dar errado.
Digital giants conseguem se mexer rápido porque resolveram isso. As outras? Precisam da cola. E essa cola não é barata, não é fácil de construir, mas quando funciona, muda a velocidade da organização de forma dramática.
Se você trabalha em transformação digital e está notando que o negócio e TI falam línguas diferentes, essa é a sua problem statement. Se você conseguir construir aquela ponte, fazer as duas conversas se ouvirem, o resto fica muito mais simples.
Insights & Takeaways
-
EA é cola, não IT: Enterprise Architecture não é uma função de TI, é a tradução entre estratégia de negócio e implementação técnica. Se trata como IT, você perde a credibilidade com o negócio desde o começo.
-
Sem business architecture, EA é só adivinhar: Você não consegue alinhar TI com negócio se o negócio não consegue articular sua própria arquitetura. O primeiro passo é ajudar a liderança a clarificar o modelo operacional.
-
Digital companies não têm EA formal: Quando negócio e TI estão na mesma sala falando a mesma língua, você não precisa de departamento separado. EA é um sinal de que a organização ainda tem divisão de silos.
-
Valor, não documentação: EA que só produz documentação bonita é EA que está falhando. Toda análise, todo mapeamento, toda decisão arquitetural tem que traduzir em ações que o negócio vê e sente.
-
Trabalhe para se tornar desnecessário: Se você fez sua função de EA corretamente, a liderança técnica vai estar conversando direto com liderança de negócio. Você vai estar menos importante, não mais. Isso é sucesso, não fracasso.
