on 11 de novembro de 2011
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:
- 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.
- 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?”
- 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.
- 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.
[1] John Zachman defende que a última versão de seu framework não se restringe à TI, mas, em minha opinião pelo menos, é difícil ver em seu modelo essa transcendência. Meu argumento é que os elementos adicionais (não-TI) deveriam estar presentes de forma explícita em qualquer metamodelo de Arquitetura Corporativa.
Todo o bom remédio, de tanto uso, um dia pode se tornar um veneno! O “processamento eletrônico de dados” atualmente revestido de TI ou IT é esse remédio.
Muito bom sua iniciativa. TI é uma ferramenta operacional de base assim como a área de Manutenção Industrial e, só.
A cultura de gestão coorporativa será resgatada através de iniciativas tal como a sua. No seu modêlo sugiro aplicar destaque para Competências além Competência e também Competências.
Atila, acredito que atualmente essa seja a maior causa da falta de adesão dos frameworks, as áreas de negócio entendem esses frameworks como algo de TI para a TI, e como você mencionou na prática eles realmente são. Apesar do entendimento teórico dos frameworks, o uso deles na prática pode se tornar complicado e oneroso para muitas empresas, isso se agrava ao considerarmos que alguns dos retornos são difíceis de se quantificar e consequentemente isso dificulta a comprovação dos benefícios que essas práticas trazem.
Com todo respeito ao seu artigo, nao vejo sentido ou legitimidade em seu plano de difusao de metamodelos.
As possiveis limitacoes dos frameworks que vc comentou sao justamente as mesmas limitacoes que os frameworks tentam resolver,
atraves de instrumentizacao incorporada de conceitos classicos da engenharia de software.
A pilha que vc descreve em tempos de cloud computing seria confusa para qualquer organizacao moderna.
Como imaginar a instanciacao de seus “metamodelos” que por si soh carregam visoes incoerentes de problemas que a decadas crescem.
A descricao de tais problemas nao sao metamodelos, pois nao descrevem modelos, apenas descrevem problemas reais ja instanciados.
Isso limitaria muito a reutilizacao do framework, assim como diminuiria o poder de abstracao de novos problemas empresariais descorrentes de novas visoes, limitacoes de recursos e estrategias diversas.
Prezados amigos.
Achei muito boas tanto a colocação quanto a sugestão de evolução da segmentação das camadas arquitetônicas, mas minha percepção de necessidade vai além.
Como tudo nessa vida, é uma questão de maturidade.
Não percebo os gestores querendo utilizar AE e sentindo dificuldades em função da incompletude do ferramental.
Vivemos um momento colaborativo e evolucionista.
Por isso o enorme sucesso das redes e dos wikis.
Por isso o enorme sucesso do conceito aberto para métodos, práticas e ferramentas.
A velocidade pressupõe essas dois processos: colaborar e evoluir e a premissa “aberto”.
Mas nossos gestores de alto nível, que militam a esfera do estratégico estão muito longe da tecnologia.
Sequer sabem do que se trata e até demonstram certa empáfia quando o tema é abordado no nível de funcionalidade.
Isso é fruto de uma geração que acha, pejorativamente, que TI é para técnicos.
Via de regra, nosso CIO não se senta no board de decisão.
Só nas empresas mais maduras é que se vê a figura do Diretor de Tecnologia, assim mesmo ele está lá para traduzir TI e defender com um discurso de negócio, os planos e os orçamentos.
Essas camada técnica é complicada de se explicar e de se entender, e como o conceito de arquitetura é historicamente oriundo da TI, é visto como mais um esforço de explicar o que não quer ser entendido.
Vamos em frente sim, precisamos aprimorar nosso ferramental que tem se mostrado de uma utilidade fabulosa para a TI e para a média gerência das áreas operacionais que estão preocupados em aperfeiçoar e racionalizar.
Ainda sonhamos com decisões estratégicas sendo tomadas com base na análise de cenários dos modelos de AE, mas essa realidade ainda está longe.
É necessário evoluir nosso ferramental e acrescentar esse conhecimento nos treinamentos desde as universidades até os cursos de especialização de executivos.
É necessário aguardar que novas gerações de executivos passem a fazer parte do board com esse modelo mental de tomada de decisão.
Até lá, para nós que estamos um passo à frente do nosso tempo e que somos os mateiros de plantão, resta continuar com nossa pregação e evangelização.
Abraços a todos.
Fernando Botafogo
Atila, considero o metamodelo proposto muito interessante. Ele trata o ambiente sociotécnico de uma organização complexa de forma mais sistêmica e integrada, evitando o viés exagerado de TI. Ele estimula o arquiteto a ver de forma equilibrado o peso dos fatores, humanos, tecnológicos e logísticos na representação da arquitetura de uma organização e parece muito adequado para servir de base para modelagem de empresas de conhecimento/inteligencia. Creio que este é um caminho que merece ser explorado.
Parabéns ao autor deste artigo instigante.
Quero destacar que Sistema de Informação (SI) deve ser entendida como a camada da arquitetura relacionada às necessidades de informação da empresa (e isso é corporativo), independentemente do uso de tecnologias mais antigas (pastas e arquivos físicos) ou mais modernas (cloud computing, web services, mashups, computação móvel, computação ubíqua, data mining etc.). A camada “infraestrutura de TI” é, de fato, o reconhecimento de que muitas necessidades de informação (mapeadas pela camada SI) dependem de uma bem planejada infraestrutura de Tecnologia de Informação, composta por diversos processos de TI, gerenciados e operados por pessoas competentes. Eis alguns exemplos de processos de TI: (ex: suporte a usuário, gerenciamento de contratos de TI, controle da segurança das informações, gerenciamento de backups, manutenção dos computadores, impressoras, equipamentos de rede etc.).
Alguém citou o importante papel da governança de TI nas organizações modernas. Quando ela está restrita aos limites de um departamento ou diretoria (liderado por um CIO), muitas oportunidades de alavancagem dos negócios são perdidas. O desafio dos CIOs é mostrar aos donos da empresa (board) como a TI pode ser usada estrategicamente em benefício da organização. Nesse contexto, quem trabalha com TI deve aprender a linguagem corporativa (nisso, os frameworks de Arquiterura Corporativa podem ajudar).
Muito boa sua visão e abordagem, como sempre. Alias, gostaria de saber: no modelo atual, aonde se posiciona as atividades relacionadas com o desenvolvimento das capacidades, tecnologias operacionais e infraestrutura ? Terão que estar posicionadas na camada de Processos de Negócio, certo ? O que mistura as coisas. Daí ser muito lógico colocar estes referidos Recursos Organizacionais em uma camada separada.
Uma primeira dúvida: no seu modelo, pelo que entendi do artigo você está substituindo duas camadas (Sistema de Informação e Infraestrutura de TI) por uma única chamada Recursos Organizacionais. Abaixo, dela são apenas categorias e não uma nova camada. Assim, seu modelo teria Estrategia, Processos de Negócio e Recursos Organizacionais. É isso ?
A segunda dúvida, ou sugestão segundo meu ponto de vista, exige que primeiro eu faça este posicionamento abaixo.
Os sistemas de informação são na verdade automatizadores dos processos de negócio que, tendo como premissa a boa qualidade do, “apenas” agilizam o atingimento de objetivos de negócio. Por suas capacidades, agregam valor, controle e competitividade. Geram apenas um produto final: a informação atendendo a requisitos de negócio de qualidade, segurança e fiduciários, gerando como benefício um melhor desempenho das unidades de negócio. Ao meu ver, por serem uma representação do próprio processo de negócio na forma automatizada, estão em uma camada própria tambem, tal como aqueles.
Quanto à camada de infraestrutura, esta é a responsável por viabilizar estes sistemas de informação e, quanto mais avançada, mais habilitará os sistemas de informação à entregar automatização e sofisticação na forma de possibilidades, criatividade e competitividade, gerando mais valor para os processos de negócio. Por isto, sua complexidade e importância lhe rendeu uma camada particular.
Quando traço um paralelo com processos de negócios vejo que:
As competências, tecnologias operacionais e infra-estrutura física são os pré-requisitos para a viabilização de cada linha de negócio, produto ou entidade organzacional. Assim, ela viabiliza tecnicamente o processo de negócio. Quero dizer que estes recursos organizacionais são aqueles indispensáveis para a existência do produto final. Por outro lado, a TI poderia nem existir na empresa, em teoria, e mesmo assim aquele produto seria produzido. Neste caso, tambem não existiria a camada de SISTEMAS DE INFORMAÇÃO, pelo menos como é definida hoje. Entretanto acho que essa possibilidade é remota, pois na prática seria impossível competir no mercado atual.
Ainda, os sistemas de informação tambem poderão ser afetados em seu design e funcionalidade pela existência ou não de tais recursos organizacionais, ou pelo grau de complexidade e tecnológico dos mesmos, o que coloca a TI em um nível funcional diferente e abaixo deste recursos organizacionais.
Adicionalmente, tal como os processos de negócio, os processos de TI tambem requerem competências, tecnologias operacionais e infraestrutura física para produzirem sistemas de Informação que no final irão atender aos objetivos de negócio.
Dúvidas: Não seria o caso de, no modelo atual, colocarmos uma nova camada de Infrestrutura de Negócio (nos referindo às competências, tecnologias operacionais e infra-estrutura física) entre Processos de Negócio e Sistemas de Informação, em vez de agruparmos em uma única camada segmentada de Recursos Organizacionais ?