Business Architecture Layer: de onde vem o termo, e o que ele não é

Comecemos pelo conflito de interesse, porque ele determina como você deve ler tudo o que vem a seguir: a BALVOX usa a expressão “Business Architecture Layer” comercialmente. Ela está no nosso posicionamento, no nosso material e no nome do nosso modelo de entrega.

Justamente por isso fomos verificar se o termo existe de verdade — em normas, em literatura revisada por pares e nas publicações dos corpos profissionais da área. O resultado nos obrigou a mudar como falamos dele. Este artigo é o registro público dessa checagem, incluindo a parte que não nos favorece.

O que foi feito

Leitura de texto normativo (ArchiMate, TOGAF, BIZBOK, OMG, ISO), consultas a bases acadêmicas (OpenAlex, Google Scholar, Crossref, DBLP, arXiv) e às publicações abertas dos corpos profissionais. Toda afirmação factual abaixo tem link para a fonte, e cada fonte é marcada pelo seu grau: norma revisado por pares corpo profissional fornecedor/imprensa.

“Business Architecture Layer” não é um termo formalmente definido em nenhuma norma, padrão ou corpo de conhecimento. O que existe são dois conceitos oficiais vizinhos, de origens diferentes, que a expressão funde: a Business Layer do ArchiMate e a Business Architecture do TOGAF e do BIZBOK.

O que o ArchiMate realmente diz

Business Layer elements are used to model the operational organization of an enterprise in a technology-independent manner, whereas strategy elements are used to model the strategic direction and choices of the enterprise.

ArchiMate 3.1 Specification, Cap. 8 (via Internet Archive)

Repare no contraste explícito: no ArchiMate a estratégia está fora da Business Layer, num conjunto próprio de elementos. E “camada”, ali, é um eixo de abstração técnica — negócio, aplicação, tecnologia —, não uma unidade organizacional. O cartão de referência oficial do ArchiMate 3.2 (PDF aberto, sem login) traz a seção como “Business Layer Elements”, sem a palavra “architecture”.

O que o TOGAF realmente diz

Architecture Domain — The architectural area being considered. Note: the TOGAF framework has four primary architecture domains: business, data, application, and technology.

TOGAF 9.2, §3.11 (via Internet Archive)

O TOGAF diz domínio, nunca camada. A própria Business Architecture ele define como uma representação — “a representation of holistic, multi-dimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure” —, ou seja, um artefato de modelagem, não uma camada operacional que se contrata.

Uma nota de atualidade que quase todo texto sobre o assunto erra: a ArchiMate 4 foi publicada em abril de 2026 e o TOGAF 9.2 já foi superado pela 10ª edição. Citar as versões anteriores como “o padrão atual” é erro datado — inclusive neste artigo, cujas citações vêm das edições que puderam ser lidas em texto integral.

Não ser oficial é diferente de ser inédito. A expressão exata já apareceu impressa, e o caso mais forte é anterior em dezesseis anos a qualquer uso nosso.

This chapter describes a framework for modeling the business architecture layer of enterprise architecture.

Rummler, G. A. & Ramias, A. J. (2010), in Handbook on Business Process Management 1, Springer

É o abstract de um capítulo assinado por Geary Rummler — um dos nomes fundadores da disciplina de melhoria de desempenho — numa coletânea da Springer. A frase é exatamente a nossa, no sentido exatamente nosso. revisado por pares

• Hasselbring, W. (2000), na Communications of the ACM, já tratava a arquitetura de negócios como a camada superior de uma pilha de três. revisado por pares
• Em português, uma dissertação de MBA publicada pela biblioteca do BNDES em 2011 usa a construção “a camada de Arquitetura de Negócios”. literatura cinzenta institucional
• E o uso segue vivo no mercado: um artigo da Splunk de 2025 lista literalmente “Business architecture layer” como uma das quatro camadas de arquitetura empresarial. fornecedor

Conclusão honesta: a expressão não tem dono, mas também não é terreno virgem. Quem afirmar tê-la criado está errado — e é verificável em uma busca.

Existe uma definição consensual, e ela não é de nenhum fornecedor: foi ratificada em janeiro de 2017 pela FEAPO, a federação que reúne Business Architecture Guild, IIBA, IEEE, INCOSE, DAMA e outras. É por isso que o TOGAF e o BIZBOK dizem quase a mesma coisa.

Business architecture represents holistic, multidimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.

BIZBOK Guide v15.0, Introdução — Business Architecture Guild

A disciplina se organiza em quatro domínios centrais — mapa de capacidades, cadeia de valor, mapa de informação e mapa organizacional — descritos no metamodelo público da Guild.

E a metáfora canônica da profissão não é camada: é ponte. Whynde Kuehn, uma das vozes mais reconhecidas da área, publicou no Cutter um artigo cujo título é literalmente “Business Architecture: A Bridge Between Strategy and Execution”. Quem fala em “camada” está importando vocabulário do ArchiMate para um campo que escolheu outra palavra.

Há autoridade consolidada no campo adjacente. Nenhuma delas, porém, é autoridade sobre a expressão “Business Architecture Layer” — porque a expressão não tem dono.

Normativas

• The Open Group — mantém ArchiMate e TOGAF. O ArchiMate nasceu na Holanda, entre 2002 e 2004, no Telematica Instituut, sob a liderança de Marc Lankhorst; a versão 1.0 saiu em fevereiro de 2009 e a 4 em abril de 2026.
• OMG — publicou o Business Architecture Core Metamodel (BACM) v1.0 como norma formal em agosto de 2024.
• ISO/IEC/IEEE 42010 — a norma internacional de descrição de arquitetura.

Corpos profissionais

• Business Architecture Guild — a autoridade de fato da disciplina. Publica o BIZBOK Guide (v15 em abril de 2026) e é a provedora da certificação CBA®.
• FEAPO — ratificou a taxonomia comum adotada pelos demais.
• IIBA — trata arquitetura de negócios como uma “Perspective” do BABOK, com saídas chamadas blueprints.

Pessoas

• William Ulrich e Whynde Kuehn — os dois nomes mais citados; coautores de “Dispelling Twelve Common Myths”.
• Marc Lankhorst — Enterprise Architecture at Work, a obra de origem do ArchiMate.
• Robert Winter (Univ. St. Gallen) — o autor que formalizou academicamente a arquitetura empresarial como camadas.
• Ralph Whittle & Conrad Myrick — Enterprise Business Architecture: The Formal Link between Strategy and Results (CRC Press, 2004). Guarde esse subtítulo — ele volta na seção 8.

Nota de método: Gartner e Forrester aparecem em quase todo texto sobre o tema. Não os citamos aqui porque nenhuma das suas páginas foi acessível para verificação em fonte primária.

Se você é desenvolvedor ou arquiteto de software, ao ler “camada de negócio” provavelmente pensou em outra coisa: a camada intermediária de uma aplicação em três camadas. Esse sentido é antigo, canônico e muito mais comum.

Business layer. This layer implements the core functionality of the system, and encapsulates the relevant business logic.

Microsoft patterns & practices — Application Architecture Guide, cap. 5

A linhagem é sólida: o padrão Layers vem de Buschmann e colegas em Pattern-Oriented Software Architecture (1996), e o Service Layer é de Randy Stafford, no catálogo de Martin Fowler (2003).

O tamanho da colisão

É uma diferença de 50 a 120 vezes. Pior: a própria taxonomia ratificada pela FEAPO coloca business logic dentro da Application Architecture — ou seja, no vocabulário oficial da própria disciplina, “lógica de negócio” é assunto de camada de aplicação.

Consequência prática, e é permanente: quem usa a expressão gasta o primeiro parágrafo de toda conversa técnica desfazendo o mal-entendido. Não é um problema de lançamento; é um custo recorrente. Preferimos declará-lo do que fingir que não existe.

O volume é marginal. Todas as consultas abaixo são reproduzíveis; os números oscilam com o tempo, mas a ordem de grandeza não.

A leitura honesta: a expressão é usada de forma descritiva e incidental — “a camada de arquitetura de negócios da pilha de EA” —, nunca como termo de arte com definição própria. Não existe artigo definidor, não existe autoridade acadêmica do termo e não existe revisão sistemática consolidada da disciplina.

As obras que valem citação

• Versteeg & Bouwman (2006), Information Systems Frontiers — a referência canônica para “arquitetura de negócios como elo entre estratégia e TI”. revisado por pares
• Winter & Fischer (2006), EDOCW/IEEE — o artigo que formalizou a arquitetura empresarial como camadas; é o mais citado deste conjunto. revisado por pares
• McDavid (1999), IBM Systems Journal — a primeira tentativa séria de padronizar a descrição de arquitetura de negócios. Vinte e sete anos atrás. revisado por pares
• Roelens, Steenacker & Poels (2017), Software and Systems Modeling — o tratamento recente mais rigoroso da arquitetura de negócios como artefato de alinhamento. revisado por pares
• Polovina, von Rosing & Etzel (2020) — argumenta explicitamente por “restating domains as layers”. Ou seja: a tese intelectual de tratar domínios como camadas já está publicada e revisada — e mesmo esse artigo nunca usa a expressão “business architecture layer”. revisado por pares

Duas armadilhas

1. O artigo mais citado com “business architecture” no título não serve de apoio. Amit & Zott (2015), no Strategic Entrepreneurship Journal, usam o termo como sinônimo de desenho de modelo de negócio — outro referente.

2. A estatística dos “70% das estratégias que falham” é falsa e circula há décadas. Cândido & Santos (2015), no Journal of Management & Organization, rastreiam a origem e concluem que o número não se sustenta. Se você a encontrar num material nosso antigo, é erro nosso. Um dado verificável para o mesmo argumento: numa pesquisa do MIT Sloan Management Review com 124 organizações, apenas 28% dos executivos e gerentes médios conseguiam listar três prioridades estratégicas da própria empresa.

O que não é nosso

A ideia de uma função única, responsável por coordenar a travessia entre estratégia e execução ponta a ponta, já tinha nome em 2005. Kaplan e Norton a chamaram de Office of Strategy Management — uma unidade corporativa nova, distinta do planejamento estratégico, que se torna o ponto central de coordenação. O escopo completo, com nove processos, está no working paper aberto de Harvard.

Três anos depois eles publicaram um livro cujo subtítulo é, essencialmente, o nosso posicionamento: The Execution Premium: Linking Strategy to Operations. E, quatro anos antes disso, Whittle e Myrick já haviam publicado Enterprise Business Architecture: The Formal Link between Strategy and Results.

Portanto: o conceito não é nosso. Dizer o contrário seria fácil de desmentir e nos custaria exatamente o leitor que queremos.

O que é nosso

Em toda a pesquisa não foi encontrada nenhuma definição — normativa ou acadêmica — do arranjo que praticamos: um provedor externo único, contratado sob um contrato de resultado, com um interlocutor e uma métrica auditada, responsável ponta a ponta da estratégia à operação.

O Office of Strategy Management de Kaplan e Norton é interno. A nossa contribuição, se há uma, é tê-lo externalizado e contratualizado. É uma afirmação menor que “criamos uma categoria” — e é verdadeira.

Os dois construtos acadêmicos que dão respaldo a esse arranjo são:

• Performance-based contracting — Hypko, Tilebein & Gleich (2010), Journal of Service Management: uma revisão sistemática de 39 publicações que estende explicitamente o modelo a provedores de serviço independentes. revisado por pares
• Outcome-based contracts — Ng, Maull & Yip (2009), European Management Journal: evidência de caso de que contratos por resultado só funcionam com alinhamento comportamental e informacional dos dois lados. É uma ressalva contra nós, e é honesta. revisado por pares

E como isso difere de BPO? A pergunta é justa e o leitor vai fazê-la sozinho. Terceirização de processos assume o processo como ele é e o opera com métricas de nível de serviço. O arranjo que descrevemos começa antes: decide qual processo deve existir, redesenha-o e responde pelo resultado de negócio, não pelo cumprimento do SLA. Onde essa distinção não se sustentar na prática, é BPO — e o nome honesto é BPO.

1. “Arquitetura de negócios não se compra pronta”

A objeção é dos próprios Ulrich e Kuehn, no documento em que desmontam doze mitos da disciplina. O mito nº 5 é justamente “business architecture can be licensed or acquired”, e a resposta deles é que a arquitetura de um negócio é única daquele negócio, e que perspectivas pré-empacotadas raramente atingem a especificidade necessária.

Concordamos. O que se contrata não é uma arquitetura pronta — é a capacidade de construir a sua, e a responsabilidade contratual por ela funcionar. Se um fornecedor lhe vender um mapa de capacidades genérico, o mito nº 5 está certo e o fornecedor está errado.

2. Ponto único de responsabilidade é uma ilusão

Roger Martin argumenta que a responsabilidade de ponto único só é limpa em contextos estreitos, e que em organizações reais ela costuma ser uma ficção conveniente. É opinião auto-publicada, não evidência — mas vem de uma autoridade de primeira linha em estratégia. opinião

Concordamos em parte. Um contrato único não elimina a interdependência; ele apenas define quem responde quando ela falha. Prometer que um fornecedor absorve toda a complexidade organizacional do cliente seria desonesto.

3. O problema não é alinhamento vertical — é coordenação horizontal

A pesquisa de Sull, Homkes e Sull na Harvard Business Review resume assim um dos mitos da execução: “Execution equals alignment. (Truth: execution equals coordination.)” A falha de execução, mostram, acontece entre unidades que precisam colaborar — não entre a diretoria e a base.

Isso apoia o nosso diagnóstico e enfraquece o discurso simplista. Se o problema é coordenação horizontal, o valor não está em “ter um pescoço para apertar”, e sim em existir alguém com mandato para atravessar fronteiras entre áreas e fornecedores. É uma promessa diferente, e mais modesta.

Esta página é uma sistematização, não uma revisão sistemática. Vale registrar o que ficou de fora, porque isso também é informação.

O que não pôde ser verificado em fonte primária

• Texto normativo do The Open Group. O portal pubs.opengroup.org hoje redireciona para autenticação. As citações de ArchiMate e TOGAF vêm de cópias arquivadas no Internet Archive e do cartão de referência em PDF aberto — por isso os links apontam para lá, e não para o portal.
• ArchiMate 4 (abril de 2026): o texto normativo da versão atual não foi lido. As citações são das edições anteriores, e estão marcadas como tais.
• Winter & Fischer (2006): o texto integral não foi acessível. Por isso citamos o artigo pelo que ele é reconhecidamente — o trabalho que formalizou EA como camadas — sem reproduzir a lista de camadas que fontes secundárias lhe atribuem.
• Whittle & Myrick (2004): só a ficha editorial. Não sabemos se o livro usa a palavra “layer”.
• Analistas de mercado (Gartner, Forrester): nenhuma página acessível. Não citados.
• Bases em português: SciELO e Google Books não responderam. A conclusão de que a literatura lusófona sobre o termo é quase inexistente apoia-se em Google Scholar e OpenAlex — é provavelmente correta, mas é uma medição incompleta.

Um aviso que vale para quem for repetir esta busca

Numa das consultas, o resumo automático de um motor de busca inventou uma seção chamada “Business Architecture Layer Overview” e atribuiu ao TOGAF a definição da Business Layer do ArchiMate. As duas coisas são falsas. É exatamente assim que se fabrica a impressão de que um termo é oficial. Não confie em resumo de busca sobre este assunto — vá ao texto do padrão.

A pesquisa completa que originou esta página, com as consultas reproduzíveis e as contagens por base, está resumida nas referências abaixo. Se você encontrar um erro factual aqui, escreva para contato@balvox.com: corrigimos e registramos a correção.