Uma das mais importantes limitações da maioria dos principais frameworks de Arquitetura Corporativa hoje usados no mercado é seu excessivo (se não exclusivo) foco em Tecnologia da Informação (TI).

Isso é fácil de entender, se considerarmos a história da disciplina. John Zachman, o “fundador” da Arquitetura Corporativa, é um homem de TI, oriundo da IBM. O TOGAF foi desenvolvido pelo Open Group, que é claramente um consórcio de usuários e fornecedores de TI, e, até sua versão 7, lidava exclusivamente com Tecnologia.

Mas isso não quer dizer que devamos nos restringir à TI só porque “é assim desde o início”. Muitos autores vêm destacando os problemas desse foco limitado, tais como Tom Graves.

Durante muito tempo, afirmou-se que Arquitetura Corporativa era uma forma de “alinhar TI ao Negócio”, uma expressão que já virou chavão e ninguém mais aguenta ouvir, até porque foi aplicada como “frase-bombril” para quase tudo o que se propôs na área de TI nos últimos 20 anos, incluindo a Governança de TI.

Uma definição muito melhor, que vem sendo cada vez mais empregada na comunidade de arquitetos corporativos, é “alinhar Estratégia e Execução”, ou seja, a Arquitetura Corporativa deveria dizer respeito a como a Organização deveria articular seus ativos ou recursos para conseguir alinhar sua Estratégia à Execução, fazendo com que a estratégia deixe de ser apenas uma declaração de boas intenções e seja realmente materializada em processos que levem ao cumprimento das metas estratégicas.

O problema é que, como o foco dos principais frameworks de Arquitetura é mesmo a TI, seus metamodelos excluem praticamente tudo o que não seja TI abaixo dos níveis de Estratégia e Negócio.

Vejamos: quase todos os grandes frameworks disponíveis propõem um metamodelo derivado do Zachman Framework, apresentando uma estrutura similar à apresentada na seguinte figura:

 

Ou seja, supõe-se que, uma vez mapeada a Estratégia Corporativa, o passo seguinte é estabelecer a rastreabilidade desta com os Processos de Negócio. Até aí tudo bem, é disso mesmo que se trata. Toda Organização tem uma Visão e uma Estratégia para alcançá-la, e a implementação da Estratégia se dá através dos Processos de Negócio.

O problema começa agora: os frameworks hoje disponíveis dão a entender que as únicas coisas de que uma Organização precisa para dar suporte aos Processos de Negócio são Sistemas de Informação, o que é, evidentemente, falso. No Zachman Framework, a terceira linha representa os modelos necessários para descrever os sistemas de informação necessários para dar suporte aos modelos de negócio da segunda linha[1]. No TOGAF 9, à Fase B (Arquitetura de Negócio) segue-se a Fase C (Arquitetura de Sistemas de Informação), mais uma vez dando a entender que precisamos apenas de sistemas de informação para dar suporte ao negócio.

Novos processos não exigem apenas novos sistemas

Um exemplo ilustra a limitação dessa visão: suponha que uma Empresa de Petróleo decida, como parte de sua Visão e Estratégia, transformar-se em uma Empresa de Energia. Suponha ainda que essa Estratégia seja detalhada com uma meta de prover produtos e serviços em Energia Eólica. Naturalmente, serão necessários novos processos para o atingimento dessa meta, mas esses novos processos não serão suportados apenas por novos sistemas de informação. Serão necessárias novas competências (engenheiros com conhecimentos e experiência em Energia Eólica), novas tecnologias operacionais (processos industriais, máquinas e equipamentos, patentes etc.) e novas instalações físicas (fazendas eólicas etc.)

Outro exemplo, que todos conhecemos: quando os maiores bancos de varejo brasileiros decidiram entrar no segmento premium (para atender a pessoas físicas de alto poder aquisitivo), eles perceberam que não possuíam as competências necessárias para atender a este segmento de mercado. Foi necessário criar novos processos, mas a principal carência para sua execução não era a falta de sistemas, mas de competências humanas. Tratava-se do fato simples de que o Gerente de Contas tradicional, alocado em uma agência e atendendo grande número de correntistas de baixo poder aquisitivo, não tinha o perfil necessário para atender clientes de alto poder aquisitivo. Além disso, as instalações físicas necessárias também não podiam ser as mesmas. Esses bancos criaram novos processos, contrataram e treinaram Gerentes de Contas com perfis diferenciados, e criaram agências físicas com características exclusivas, com maior privacidade, decoração de primeira etc. Alguns desses bancos simplificaram a questão simplesmente comprando bancos menores que já detinham a “tecnologia” de atender aos clientes do topo da pirâmide. E, por incrível que pareça, a menor das modificações foi justamente em sistemas de informação. Hoje, esses bancos atendem clientes de todos os extratos da sociedade usando os mesmos sistemas de informação, mas com atendimento distinto conforme o poder aquisitivo do cliente, sendo que a distinção no atendimento se dá através de competências distintas (diferentes “tipos” de Gerente de Conta) e instalações físicas distintas (diferentes “tipos” de agência bancária).

Estendendo o TOGAF 9 para incluir outros tipos de Recursos Organizacionais

Embora essa miopia dos frameworks atuais se explique pelas razões históricas apontadas acima, é evidente que precisamos transcender essa limitação. Assim sendo, proponho uma ampliação desses metamodelos clássicos de Arquitetura Corporativa, incluindo mais três tipos de Recursos Organizacionais.

Um dos maiores pontos fortes do TOGAF é sua permeabilidade à customização. O TOGAF não só é customizável, como se espera que seja customizado para cada Organização que o adote como modelo de referência. Tomemos, portanto, partido dessa sua excelente característica para estender o conceito de Arquitetura Corporativa.

Minha proposta é fundir as Fases C e D em uma só, rebatizada de Arquitetura de Recursos Organizacionais. Defino Recursos Organizacionais como tudo aquilo de que a Organização precisa para dar suporte a seus Processos de Negócio, os quais são o instrumento de execução da Estratégia. Proponho quatro categorias de Recursos Organizacionais, que passariam a ser incorporadas ao Metamodelo proposto:

1. Tecnologias da Informação. Este conjunto de recursos organizacionais aparece em primeiro lugar não por ser o mais importante, mas por que já está presente nos modelos atuais. Em minha proposta, essa categoria inclui as linhas 3 e 4 do Zachman Framework, desenvolvidas através das atividades incluídas nas atuais fases C e D do TOGAF 9.
2. Competências. A Organização precisa identificar, mapear e documentar as competências disponíveis (AS-IS) e necessárias (TO-BE) para a execução de seus Processos de Negócio. Isto significa que as áreas de Gestão de Pessoas (RH) devem ser parte fundamental do esforço de Arquitetura Corporativa. Não basta perguntar “Quais sistemas serão necessários?” É necessário também perguntar “De que tipo de profissional precisaremos para executar esses novos processos de negócio?”
3. Tecnologias Operacionais. Uma Estratégia que leve a novos processos pode exigir novas Tecnologias Operacionais, ou seja, aquelas tecnologias necessárias para a execução dos processos-fim da Organização. Se você é uma empresa de Petróleo entrando no mercado de Energia Eólica, vai precisar de Pesquisa e Desenvolvimento nesta área, de novos tipos de máquinas e equipamentos, de novas patentes etc. Isso não tem nada a ver com sistemas de informação. É claro que, naqueles setores onde o produto oferecido é principalmente constituído de informação, como no setor financeiro, pode haver certa sobreposição entre esta categoria e a de tecnologia da informação, mas em outros setores a distinção é muito clara.
4. Infraestrutura Física. Novos processos criados para atender à Estratégia podem exigir novas instalações físicas, como as Agências Bancárias premium criadas para receber os clientes de alto poder aquisitivo, ou fazendas eólicas, ou centros de distribuição, ou novas fábricas etc.

Segundo esta proposta, a estrutura geral no Metamodelo proposto ficaria como na figura abaixo:

 

Essa proposta não pretende ser nem exaustiva nem definitiva. Exorto meus leitores a comentar e propor modificações e acréscimos ao modelo. Minha intenção básica é estimular o debate há muito necessário sobre as limitações dos frameworks de Arquitetura Corporativa atualmente disponíveis. Afinal, para fazer justiça a seu nome, a Arquitetura Corporativa deve ser… Corporativa! Ou seja, deve incluir a Organização inteira, e não só a Tecnologia da Informação.

Artigo escrito por Atila Belloquim em Novembro de 2011.

Copyright © 2011 Atila Belloquim.                     

Este artigo pode ser reproduzido no todo ou em parte, desde que citada a fonte e acompanhado do endereço eletrônico http://blog.gnosisbr.com.br.